Corosync марсианские исходные сообщения в журналах
У нас есть двухузловой кластер с IP-адресами 10.150.5.179 (trpventus01) и 10.150.5.180 (trpventus02) и виртуальным IP-адресом (ventusproxyVIP) 10.5.150.181. Этими узлами являются Red Hat 7.2 с Corosync 2.3.4
Мы получали сообщения 'martin source' в журналах. Это происходило потому, что сетевая маска этого виртуального IP-адреса была неправильной, это было /24 и должно было быть /16. Это спровоцировало проблемы с сетью, теперь это исправлено.
Но мы все еще видим эти сообщения в наших журналах. Все работает нормально, но обычно около 13:31 (не все дни) эти строки появляются в наших журналах. У нас нет запускающего процесса в этот час, поэтому мы не уверены, почему это происходит.
В этот час, 13:31:11, трафик перемещается из trventus01 в trpventus02, а в 13:31:13 трафик снова перемещается обратно в узел trpventus01.
Apr 17 13:31:06 trpventus01 corosync[2351]: [MAIN ] Corosync main process was not scheduled for 1092.4456 ms (threshold is 800.0000 ms). Consider token timeout increase.
Apr 17 13:31:06 trpventus01 corosync[2351]: [TOTEM ] A processor failed, forming new configuration.
Apr 17 13:31:06 trpventus01 corosync[2351]: [TOTEM ] A new membership (10.150.5.179:2012) was formed. Members
Apr 17 13:31:06 trpventus01 corosync[2351]: [QUORUM] Members[2]: 1 2
Apr 17 13:31:06 trpventus01 corosync[2351]: [MAIN ] Completed service synchronization, ready to provide service.
Apr 17 13:31:13 trpventus01 corosync[2351]: [MAIN ] Corosync main process was not scheduled for 5102.9751 ms (threshold is 800.0000 ms). Consider token timeout increase.
Apr 17 13:31:13 trpventus01 corosync[2351]: [TOTEM ] A processor failed, forming new configuration.
Apr 17 13:31:13 trpventus01 corosync[2351]: [TOTEM ] A new membership (10.150.5.179:2020) was formed. Members joined: 2 left: 2
Apr 17 13:31:13 trpventus01 corosync[2351]: [TOTEM ] Failed to receive the leave message. failed: 2
Apr 17 13:31:13 trpventus01 cib[3029]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now lost (was member)
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: Our peer on the DC (trpventus02) is dead
Apr 17 13:31:13 trpventus01 cib[3029]: notice: Removing trpventus02/2 from the membership list
Apr 17 13:31:13 trpventus01 cib[3029]: notice: Purged 1 peers with id=2 and/or uname=trpventus02 from the membership cache
Apr 17 13:31:13 trpventus01 cib[3029]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now member (was (null))
Apr 17 13:31:13 trpventus01 corosync[2351]: [QUORUM] Members[2]: 1 2
Apr 17 13:31:13 trpventus01 corosync[2351]: [MAIN ] Completed service synchronization, ready to provide service.
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now lost (was member)
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Removing all trpventus02 attributes for attrd_peer_change_cb
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Lost attribute writer trpventus02
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Removing trpventus02/2 from the membership list
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Purged 1 peers with id=2 and/or uname=trpventus02 from the membership cache
Apr 17 13:31:13 trpventus01 stonith-ng[3030]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now lost (was member)
Apr 17 13:31:13 trpventus01 stonith-ng[3030]: notice: Removing trpventus02/2 from the membership list
Apr 17 13:31:13 trpventus01 stonith-ng[3030]: notice: Purged 1 peers with id=2 and/or uname=trpventus02 from the membership cache
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now member (was (null))
Apr 17 13:31:13 trpventus01 stonith-ng[3030]: notice: crm_update_peer_proc: Node trpventus02[2] - state is now member (was (null))
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: State transition S_NOT_DC -> S_ELECTION [ input=I_ELECTION cause=C_CRMD_STATUS_CALLBACK origin=peer_update_callback ]
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: State transition S_ELECTION -> S_PENDING [ input=I_PENDING cause=C_FSA_INTERNAL origin=do_election_count_vote ]
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Updating all attributes after cib_refresh_notify event
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: State transition S_PENDING -> S_NOT_DC [ input=I_NOT_DC cause=C_HA_MESSAGE origin=do_cl_join_finalize_respond ]
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Recorded attribute writer: trpventus02
Apr 17 13:31:13 trpventus01 attrd[3032]: notice: Processing sync-response from trpventus02
Apr 17 13:31:13 trpventus01 IPaddr2(ventusproxyVIP)[2302]: INFO: IP status = ok, IP_CIP=
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: Operation ventusproxyVIP_stop_0: ok (node=trpventus01, call=102, rc=0, cib-update=595, confirmed=true)
Apr 17 13:31:13 trpventus01 IPaddr2(ventusproxyVIP)[2359]: INFO: Adding inet address 10.150.5.181/16 with broadcast address 10.150.255.255 to device eno16780032
Apr 17 13:31:13 trpventus01 IPaddr2(ventusproxyVIP)[2359]: INFO: Bringing device eno16780032 up
Apr 17 13:31:13 trpventus01 IPaddr2(ventusproxyVIP)[2359]: INFO: /usr/libexec/heartbeat/send_arp -i 200 -r 5 -p /var/run/resource-agents/send_arp-10.150.5.181 eno16780032 10.150.5.181 auto not_used not_used
Apr 17 13:31:13 trpventus01 crmd[3035]: notice: Operation ventusproxyVIP_start_0: ok (node=trpventus01, call=103, rc=0, cib-update=596, confirmed=true)
Apr 17 13:31:14 trpventus01 kernel: IPv4: martian source 10.150.5.181 from 10.150.5.181, on dev eno16780032
Apr 17 13:31:14 trpventus01 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 56 83 4e 49 08 06 .......PV.NI..
Apr 17 13:31:15 trpventus01 kernel: IPv4: martian source 10.150.5.181 from 10.150.5.181, on dev eno16780032
Apr 17 13:31:15 trpventus01 kernel: ll header: 00000000: ff ff ff ff ff ff 00 50 56 83 4e 49 08 06 .......PV.NI..
Apr 17 13:33:01 trpventus01 chronyd[1236]: Source 213.251.52.234 replaced with 193.145.15.15
Кажется, это происходит из-за этого: "Основной процесс Corosync не был запланирован на 1092,4456 мс (порог 800,0000 мс). Рассмотрим увеличение времени ожидания токена", в 13:31:06, за которым следует "Основной процесс Corosync не был запланирован на 5102,9751 мс (порог 800,0000 мс). Рассмотрим увеличение времени ожидания токена "в 13:31:11.
Что может быть причиной этого? Любая помощь будет принята с благодарностью.