Neustart aller Nodes zur selben Zeit

[kev1904]

Hallo Zusammen,

am 21.08 um 3 Uhr nachts sind alle 8 Nodes in unserm Cluster zur gleichen Zeit neugestartet.

Hier der Syslog Eintrag von einem System. Dieser ist auf allen System gleich

Spoiler: Syslog

Aug 21 03:28:20 prox04 pvedaemon[9826]: VM 186 qmp command failed - VM 186 qmp command 'guest-ping' failed - got timeout
Aug 21 03:28:31 prox04 corosync[1963]: [KNET ] link: host: 2 link: 0 is down
Aug 21 03:28:31 prox04 corosync[1963]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Aug 21 03:28:31 prox04 corosync[1963]: [KNET ] host: host: 2 has no active links
Aug 21 03:28:32 prox04 corosync[1963]: [TOTEM ] Token has not been received in 177 ms
Aug 21 03:28:33 prox04 corosync[1963]: [TOTEM ] A processor failed, forming new configuration.
Aug 21 03:28:39 prox04 corosync[1963]: [TOTEM ] A new membership (1.36d1) was formed. Members left: 2
Aug 21 03:28:39 prox04 corosync[1963]: [TOTEM ] Failed to receive the leave message. failed: 2
Aug 21 03:28:39 prox04 pmxcfs[1859]: [dcdb] notice: members: 1/1744, 3/1776, 4/1859, 8/1952, 9/432629, 10/23079, 11/2859678
Aug 21 03:28:39 prox04 pmxcfs[1859]: [dcdb] notice: starting data syncronisation
Aug 21 03:28:39 prox04 pmxcfs[1859]: [status] notice: members: 1/1744, 3/1776, 4/1859, 8/1952, 9/432629, 10/23079, 11/2859678
Aug 21 03:28:39 prox04 pmxcfs[1859]: [status] notice: starting data syncronisation
Aug 21 03:28:39 prox04 corosync[1963]: [QUORUM] Members[7]: 1 3 4 8 9 10 11
Aug 21 03:28:39 prox04 corosync[1963]: [MAIN ] Completed service synchronization, ready to provide service.
Aug 21 03:28:39 prox04 pmxcfs[1859]: [dcdb] notice: received sync request (epoch 1/1744/00000007)
Aug 21 03:28:39 prox04 pmxcfs[1859]: [status] notice: received sync request (epoch 1/1744/00000007)
Aug 21 03:28:39 prox04 kernel: [269552.250700] cfs_loop[1860]: segfault at 7fb0eaca59ac ip 000055f3de83c7b0 sp 00007fb07e44f318 error 4 in pmxcfs[55f3de823000+1b000]
Aug 21 03:28:39 prox04 kernel: [269552.250708] Code: 10 48 89 c6 48 89 ef 48 89 10 48 8b 53 08 48 89 50 08 48 89 c2 e8 50 74 fe ff b8 01 00 00 00 e9 4a ff ff ff 66 0f 1f 44 00 00 <8b> 47 0c 8b 56 0c 39 d0
75 0d 48 8b 47 10 48 8b 56 10 48 39 d0 74
Aug 21 03:28:39 prox04 systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Aug 21 03:28:39 prox04 systemd[1]: Started Process Core Dump (PID 12552/UID 0).
Aug 21 03:28:40 prox04 pvedaemon[9826]: VM 186 qmp command failed - VM 186 qmp command 'guest-ping' failed - got timeout
Aug 21 03:29:00 prox04 systemd[1]: Starting Proxmox VE replication runner...
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Aug 21 03:33:15 prox04 sys
temd-modules-load[631]: Inserted module 'iscsi_tcp'
Aug 21 03:33:15 prox04 kernel: [ 0.000000] Linux version 5.4.44-2-pve (build@pve) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP PVE 5.4.44-2 (Wed, 01 Jul 2020 16:37:57 +0200) ()

Spoiler: pveversion

pveversion -v
proxmox-ve: 6.2-1 (running kernel: 5.4.44-2-pve)
pve-manager: 6.2-10 (running version: 6.2-10/a20769ed)
pve-kernel-5.4: 6.2-4
pve-kernel-helper: 6.2-4
pve-kernel-5.3: 6.1-6
pve-kernel-5.0: 6.0-11
pve-kernel-5.4.44-2-pve: 5.4.44-2
pve-kernel-5.4.41-1-pve: 5.4.41-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
pve-kernel-5.3.18-1-pve: 5.3.18-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
pve-kernel-4.10.17-2-pve: 4.10.17-20
ceph-fuse: 12.2.13-pve1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.4
libpve-access-control: 6.1-2
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.1-5
libpve-guest-common-perl: 3.1-1
libpve-http-server-perl: 3.0-6
libpve-storage-perl: 6.2-5
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.2-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.2-9
pve-cluster: 6.1-8
pve-container: 3.1-12
pve-docs: 6.2-5
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-2
pve-firmware: 3.1-1
pve-ha-manager: 3.0-9
pve-i18n: 2.1-3
pve-qemu-kvm: 5.0.0-11
pve-xtermjs: 4.3.0-1
qemu-server: 6.2-11
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.4-pve1

 

[aaron]

Waren auf allen Nodes HA Gäste?

Aus irgendwelchen Gründen hat Corosync die Verbindung zu den anderen Nodes verloren. Wenn HA Gäste auf der Node laufen (oder seit dem letzten Boot gelaufen sind) fenced sich die Node selbst (hard reset) nachdem sie für 2 Minuten die Verbindung zu dem quoraten Teil des Clusters verliert.

Grund für sowas, vor allem wenn es den ganzen Cluster betrifft, ist meistens ein instabiles Netz für Corosync. Gab es eine Unterbrechung im Netz? Dann kann man mit weiteren Corosync Links, die am besten auf einen anderen Switch gehen, das verhindern.

Wenn sich Corosync das physikalische Netz mit anderen Diensten teilt, kann dieses Verhalten auch auftreten. Dabei passiert es meistens das andere Dienste das Netz auslasten und die Latenz für die Corosync Pakete so weit steigt, dass die Verbindung als unterbrochen erkannt wird. Storage oder Backups sind wahrscheinliche Kandidaten.

Corosync braucht konstant niedrige Latenzen. Deshalb ist die Empfehlung, Corosync auf ein eigenes physikalisches Netz zu legen. Am besten auf 2 NICs (mit zwei Corosync Links) die auf verschiedene Switches gehen. Dann kann Corosync auch selbst auf den anderen Link umschalten, sollte der Switch Probleme machen.

 

[kev1904]

Hi Aaron,

wir haben für Management extra eigene Physikalische Schnittstellen (Bond mit 2x1G LACP), abgetrennt vom Ceph Traffic oder Backups.
Alle vms's bei uns sind im HA also läuft auch auf jedem Node mindestens eine VM mit HA.
Ich finde es dennoch merkwürdig das alles Nodes neustarten. Wir hatten solche Probleme vor dem Update auf Version 6 nicht.

 

[aaron]

Taucht diese Zeile

 Aug 21 03:28:39 prox04 kernel: [269552.250700] cfs_loop[1860]: segfault at 7fb0eaca59ac ip 000055f3de83c7b0 sp 00007fb07e44f318 error 4 in pmxcfs[55f3de823000+1b000]

in ähnlicher Form bei allen Nodes auf?

 

[kev1904]

Genau, hier mal vom prox1 node

Aug 21 03:28:39 prox01 kernel: [269471.572438] cfs_loop[1745]: segfault at 7ff382cefd2c ip 000055e79819d7b0 sp 00007ff314a4f318 error 4 in pmxcfs[55e798184000+1b000]

 

[aaron]

Sind unter /var/lib/systemd/coredump Coredumps vorhanden? Wenn ja, kannst du die uns zukommen lassen? Am besten hochladen und mir den Link in einer privaten Nachricht zukommen lassen.

 

[kev1904]

Leider nein. Kein Node hat einen Coredump aufgezeichnet, die Ordner sind überall leer.
Aber was mir noch aufgefallen ist, 3 von den 8 Nodes sind reine Ceph Nodes, auf diesen laufen also keine VM's sind aber trotzdem rebootet

 

[aaron]

Kann es sein, dass die 3 Ceph Nodes irgendwann seit dem letzten Boot einen HA Gast lokal laufen hatten? Vielleicht auch nur ganz kurz? Das wäre eigentlich die einzige Erklärung wieso der Watchdog aufgezogen war.

Wegen dem gecrashten pmxcfs (das ein weiteres aufziehen des Watchdogs verhindert hat und somit zum Fencing führte) muss ich schauen, ob ich herausfinden kann, was das potenziell verursacht hat. Ich melde mich, sobald ich was weiß. Das kann aber ein bisschen dauern.

 

[kev1904]

Kein Gast aber Templates.
Wir lassen alle paar Stunden einen Cronjob laufen, der alle Gäste in die HA Gruppe schmeißt, weil ich ja nicht generell sagen kann, dass alle Gäste HA by Default an haben sollen. Aus irgendeinem Grund wurden auf alle 3 Ceph Nodes jeweils ein Template gespeichert die auch in das HA gelangt sind durch den Cronjob. Allerdings laufen diese ja nicht weil es nur Templates sind und wurde in der HA Config auch als State: Error angezeigt.

 

[kev1904]

Hallo,

letze Nacht sind erneut alle Server bis auf zwei ceph Nodes neugestartet.

Spoiler: syslog

Aug 24 20:34:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
Aug 24 20:34:01 prox01 systemd[1]: pvesr.service: Succeeded.
Aug 24 20:34:01 prox01 systemd[1]: Started Proxmox VE replication runner.
Aug 24 20:34:18 prox01 corosync[1765]: [TOTEM ] Token has not been received in 177 ms
Aug 24 20:34:21 prox01 corosync[1765]: [TOTEM ] A new membership (1.377a) was formed. Members
Aug 24 20:34:21 prox01 corosync[1765]: [QUORUM] Members[8]: 1 2 3 4 8 9 10 11
Aug 24 20:34:21 prox01 corosync[1765]: [MAIN ] Completed service synchronization, ready to provide service.
Aug 24 20:34:26 prox01 pveproxy[29937]: worker exit
Aug 24 20:34:26 prox01 pveproxy[1821]: worker 29937 finished
Aug 24 20:34:26 prox01 pveproxy[1821]: starting 1 worker(s)
Aug 24 20:34:26 prox01 pveproxy[1821]: worker 26590 started
Aug 24 20:34:27 prox01 pveproxy[26590]: Clearing outdated entries from certificate cache
Aug 24 20:34:38 prox01 smartd[1014]: Device: /dev/bus/4 [megaraid_disk_11] [SAT], SMART Prefailure Attribute: 190 Airflow_Temperature_Cel changed from 79 to 76
Aug 24 20:34:38 prox01 smartd[1014]: Device: /dev/bus/4 [megaraid_disk_11] [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 21 to 24
Aug 24 20:34:40 prox01 pmxcfs[1694]: [dcdb] notice: data verification successful
Aug 24 20:35:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
Aug 24 20:35:01 prox01 systemd[1]: pvesr.service: Succeeded.
Aug 24 20:35:01 prox01 systemd[1]: Started Proxmox VE replication runner.
Aug 24 20:36:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
Aug 24 20:36:01 prox01 pvesr[28048]: trying to acquire cfs lock 'file-replication_cfg' ...
Aug 24 20:36:02 prox01 systemd[1]: pvesr.service: Succeeded.
Aug 24 20:36:02 prox01 systemd[1]: Started Proxmox VE replication runner.
Aug 24 20:36:22 prox01 corosync[1765]: [TOTEM ] Retransmit List: 83b
Aug 24 20:36:22 prox01 corosync[1765]: [TOTEM ] Retransmit List: 844
Aug 24 20:36:22 prox01 corosync[1765]: [TOTEM ] Retransmit List: 850
Aug 24 20:36:23 prox01 corosync[1765]: [TOTEM ] Retransmit List: 85c
Aug 24 20:37:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
Aug 24 20:37:01 prox01 systemd[1]: pvesr.service: Succeeded.
Aug 24 20:37:01 prox01 systemd[1]: Started Proxmox VE replication runner.
Aug 24 20:37:15 prox01 corosync[1765]: [TOTEM ] Retransmit List: bb5
Aug 24 20:37:29 prox01 pvedaemon[12005]: <root@pam> successful auth for user 'jschwarz@RGFI'
Aug 24 20:38:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
Aug 24 20:38:01 prox01 systemd[1]: pvesr.service: Succeeded.
Aug 24 20:38:01 prox01 systemd[1]: Started Proxmox VE replication runner.
Aug 24 20:38:33 prox01 corosync[1765]: [KNET ] link: host: 2 link: 0 is down
Aug 24 20:38:33 prox01 corosync[1765]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Aug 24 20:38:33 prox01 corosync[1765]: [KNET ] host: host: 2 has no active links
Aug 24 20:38:35 prox01 corosync[1765]: [TOTEM ] Token has not been received in 177 ms
Aug 24 20:38:44 prox01 corosync[1765]: [TOTEM ] A new membership (1.377e) was formed. Members left: 2
Aug 24 20:38:44 prox01 corosync[1765]: [TOTEM ] Failed to receive the leave message. failed: 2
Aug 24 20:38:44 prox01 pmxcfs[1694]: [dcdb] notice: members: 1/1694, 3/1783, 4/2000, 8/1991, 9/3128, 10/2239, 11/2147
Aug 24 20:38:44 prox01 pmxcfs[1694]: [dcdb] notice: starting data syncronisation
Aug 24 20:38:44 prox01 corosync[1765]: [QUORUM] Members[7]: 1 3 4 8 9 10 11
Aug 24 20:38:44 prox01 corosync[1765]: [MAIN ] Completed service synchronization, ready to provide service.
Aug 24 20:38:44 prox01 pmxcfs[1694]: [dcdb] notice: cpg_send_message retried 1 times
Aug 24 20:38:44 prox01 pmxcfs[1694]: [status] notice: members: 1/1694, 3/1783, 4/2000, 8/1991, 9/3128, 10/2239, 11/2147
Aug 24 20:38:44 prox01 pmxcfs[1694]: [status] notice: starting data syncronisation
Aug 24 20:38:44 prox01 pmxcfs[1694]: [dcdb] notice: received sync request (epoch 1/1694/00000003)
Aug 24 20:38:44 prox01 pmxcfs[1694]: [status] notice: received sync request (epoch 1/1694/00000003)
Aug 24 20:38:44 prox01 kernel: [320665.675411] cfs_loop[1696]: segfault at 7f8633cdb74c ip 000056108ca837b0 sp 00007f85d5d38318 error 4 in pmxcfs[56108ca6a000+1b000]
Aug 24 20:38:44 prox01 kernel: [320665.675421] Code: 10 48 89 c6 48 89 ef 48 89 10 48 8b 53 08 48 89 50 08 48 89 c2 e8 50 74 fe ff b8 01 00 00 00 e9 4a ff ff ff 66 0f 1f 44 00 00 <8b> 47 0c 8b 56 0c 39 d0 75 0d 48 8b 47 10 48 8b 56 10 48 39 d0 74
Aug 24 20:38:44 prox01 systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Aug 24 20:38:44 prox01 systemd[1]: Started Process Core Dump (PID 31630/UID 0).
Aug 24 20:39:00 prox01 systemd[1]: Starting Proxmox VE replication runner...
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Aug 24 20:44:36 prox01 dmeventd[549]: dmeventd ready for processing.
Aug 24 20:44:36 prox01 systemd[1]: Starting Flush Journal to Persistent Storage...
Aug 24 20:44:36 prox01 systemd[1]: Mounted RPC Pipe File System.
Aug 24 20:44:36 prox01 systemd[1]: Started udev Coldplug all Devices.

Ist es möglich das System vor einem Neustartet auszuschließen ? Scheinbar werden diese so schnell resettet, dass das System keine Zeit hat um einen Coredump zu schreiben

 

[aaron]

Kein Gast aber Templates.

Das reicht. Schlussendlich ist ein Template auch nur eine VM, wenn auch eine etwas besondere.

Wenn das so regelmäßig Probleme macht, wäre es wohl gut, wenn man vorläufig HA deaktiviert.
Dazu müssen der LRM und CRM [0] auf allen Nodes gestoppt werden.

Zuerst auf allen Nodes den LRM stoppen:

systemctl stop pve-ha-lrm

Dann auf allen Nodes den CRM stoppen:

systemctl stop pve-ha-crm

Danach sollten im Datacenter->HA panel alle Nodes nicht mehr active oder idle sein sondern auf old timestamp stehen.

Wenn das Problem das nächste mal auftaucht wird es wahrscheinlich so sein, dass der Cluster kein Quorum mehr hat, die Nodes sollten sich aber nicht neu gestartet haben.
Um den Cluster wieder in Ordnung zu bekommen wirst du auf allen Nodes den Dienst pve-cluster neu starten müssen.

systemctl restart pve-cluster

.

Und es sollte hoffentlich Coredumps geben.

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_how_it_works_2

 

[kev1904]

Also ich hab jetzt erst mal alle templates wieder auf Computing nodes geschoben und werde die kommende Nacht mal abwarten was passiert

 

[aaron]

Also ich hab jetzt erst mal alle templates wieder auf Computing nodes geschoben und werde die kommende Nacht mal abwarten was passiert

Die HA Dienste (LRM, CRM) wurden auch gestoppt bzw. die reinen Ceph Nodes neu gestartet? Im HA Panel sollten die Nodes nicht active sein.

 

[kev1904]

Die Dienste hab ich jetzt noch nicht gestoppt, ich wollte erst einmal abwarten ob es was bringt die Templates von den ceph nodes weg zu schieben.
Die Ceph nodes sind natürlich nicht in der HA Group. Neugestartet letze nach sind alle nodes bis auf 2 der 3 ceph nodes.

 

[aaron]

Alle Nodes die im Datacenter -> HA Panel für den Type `lrm` den Status `active` haben, werden sich voraussichtlich neu starten, wenn das Problem wieder auftritt.

 

[kev1904]

Ich hab jetzt HA komplett entfernt. Die Gruppe ist gelöscht und keine vm wird mehr überwacht. Aktuell stehen allerdings noch immer alle nodes, bis auf die ceph nodes auf active. Die ceph nodes sind auf dem Status idle. Ich habe nun zum testen mal auf prox01 lrm und crm gestoppt nun steht dort "old timestamp - dead ?)

 

[aaron]

Aktuell stehen allerdings noch immer alle nodes, bis auf die ceph nodes auf active

Das ist zu erwarten, da beim ersten Starten eines HA Gastes die HA Dienste aktiv werden und den Watchdog aufziehen. Beim Stoppen der Dienste (LRM, CRM) wird der Watchdog wieder abgeschaltet.

Deshalb habe ich heute Früh vorgeschlagen, zuerst den LRM und dann den CRM auf allen Nodes zu stoppen (die Reihenfolge ist wichtig). Dann starten diese nicht neu, wenn das Problem wieder auftritt und die Coredumps können geschrieben werden.