unmotivierte reboots 3Node-Cluster

[swoop]

Hallo,

ich habe seit etwa einem halben Jahr ein Proxmox-Cluster mit 3 Notes laufen, das hat bis auf ein paar kleinere Schwierigkeiten bisher wunderbar funktioniert.
Seit gestern hat das Cluster drei Mal neu gebootet. Das heißt alle 3 Nodes, haben zur selben Zeit einen Neustart ausgeführt. Ohne, dass mir etwas aufgefallen wäre weder Hardware- noch Netzwerkmäßig. In mein Netzwerk ist nicht viel los (Datentransfährmäßig)
Ich sehe diese Fehler aber ich weiß nicht was ich damit anfangen soll.

Das sind die letzten chronosync-Meldungen bevor die Server neustarten.

Sep 16 17:47:50 node2 corosync[1255363]:   [KNET  ] link: host: 3 link: 0 is down
Sep 16 17:47:50 node2 corosync[1255363]:   [KNET  ] host: host: 3 (passive) best link: 0 (pri: 1)
Sep 16 17:47:50 node2 corosync[1255363]:   [KNET  ] host: host: 3 has no active links
Sep 16 17:47:51 node2 corosync[1255363]:   [TOTEM ] Token has not been received in 2737 ms
Sep 16 17:47:52 node2 corosync[1255363]:   [KNET  ] rx: host: 3 link: 0 is up
Sep 16 17:47:52 node2 corosync[1255363]:   [KNET  ] host: host: 3 (passive) best link: 0 (pri: 1)
Sep 16 17:47:53 node2 corosync[1255363]:   [QUORUM] Sync members[3]: 1 2 3
Sep 16 17:47:53 node2 corosync[1255363]:   [TOTEM ] A new membership (1.a625b) was formed. Members
Sep 16 17:48:00 node2 systemd[1]: Starting Proxmox VE replication runner...
Sep 16 17:48:02 node2 corosync[1255363]:   [TOTEM ] Token has not been received in 2737 ms

Nicht ganz eine halbe Minute Später wird neugestartet.

Alle 3 Nodes sind Proxmox 7.0.11 aktueller Patchstand (17.9.21)

Im Anhang ist ein Syslogauszug vom 1. Neustart von gestern, etwa 10 Minuten davor und ein paar danach.

Nach dem Neustart finde ich, auf allen Nodes, mit dmesg folgende Meldungen:

[   21.265727] FS-Cache: Duplicate cookie detected
[   21.265731] FS-Cache: O-cookie c=000000009ccd1912 [p=000000002f65047a fl=222 nc=0 na=1]
[   21.265734] FS-Cache: O-cookie d=00000000df226891 n=00000000ca5007fe
[   21.265735] FS-Cache: O-key=[6] '4261636b7570'
[   21.265739] FS-Cache: N-cookie c=00000000c40906c2 [p=000000002f65047a fl=2 nc=0 na=1]
[   21.265741] FS-Cache: N-cookie d=00000000df226891 n=0000000013f592c0
[   21.265742] FS-Cache: N-key=[6] '4261636b7570'
[  132.045016] device tap109i0 entered promiscuous mode

Hat das etwas zu bedeuten?

Netzwerkmäßig sind 3 Netzwerkkarten verbunden. 1 eingebaute 2 USB, wobei ich mit der 2. USB-Netzwerkkarte hin und wieder probleme habe. Auf dieser sind aber nur VMs.
Clusterverkehr läuft über die eingebaute Netzwerkkarte, Replizierung über die 1. USB.

root@node1:~# pvecm status
Cluster information
-------------------
Name:             blits
Config Version:   9
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Sep 17 19:23:44 2021
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.a70eb
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2 
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.14.201 (local)
0x00000002          1 10.10.14.202
0x00000003          1 10.10.14.206

Welche Infos braucht ihr noch, um mir bei der Lösung des Problems zu helfen?

Danke für eure Rückmeldung.

 

[swoop]

gerade eben war wieder ein Neustart. Der vierte in etwa einem Tag.

Anbei ein Auszug aus dem Syslog.

 

[swoop]

Guten Morgen,

In anderen Post war die Rede von HA.
Ja, ich verwende HA bei einigen VMs, nicht bei allen.

Ich hoffe diese Info hift.

SG

 

[swoop]

Hallo an alle,

gerade eben ist mein Cluster wieder abgeschmiert.
In der Zwischenheit habe ich Ceph auf Pazific upgedated, dabei hat alles einwandfrei funktioniert.
Langsam wird es lästig, gibts jemand der mich in die richtige Richtung weisen kann?
Danke schonmal für eure Hilfe.

PS:
Bevor das alles gestartet hat, habe ich die neuesten Packete installiert.
Das sind die Pakete die ich zuletzt upgegradet habe, beor die Neustarts begonnen haben:

:~# grep " upgrade " /var/log/dpkg.log
2021-09-16 12:32:54 upgrade libcorosync-common4:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade libcfg7:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade libcmap4:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade libcpg4:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade libknet1:amd64 1.21-pve1 1.22-pve1
2021-09-16 12:32:54 upgrade libnozzle1:amd64 1.21-pve1 1.22-pve1
2021-09-16 12:32:54 upgrade libquorum5:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade libvotequorum8:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade corosync:amd64 3.1.2-pve2 3.1.5-pve1
2021-09-16 12:32:54 upgrade pve-firewall:amd64 4.2-2 4.2-3

Anschließend, gestern, das ceph-Upgrade

Die Reboots haben zu diesen Zeiten stattgefunden, vielleicht hilft das:

Sep 16 17:49:16
Sep 17 13:39:16
Sep 17 18:02:10
Sep 17 18:30:04
Sep 17 19:34:53
Sep 18 04:35:01
Sep 18 11:44:44
Sep 18 14:02:14
Sep 19 09:16:54

SG

 

[UdoB]

Moin,

ich habe keine Antwort.

Aber ich habe ein Homelab, mit ursprünglich zwei "echten" und einem zusätzlichem "Quota-Node". Und ich hatte diverse, unerklärliche Reboots. In meinem Fall war die Ursache mit hoher Wahrscheinlicheit immer hohe Netzwerklast durch Backups und Replikationen, die dann für Zunahme der Latenzen für Corosync sorgte. Corosync scheint in diesem Sinn echt empfindlich zu sein, sicher mit Absicht. Die Empfehlung ist ja ganz klar "separates Netz für Corosync!". Ich hatte dem folgend dann einen zweiten "Ring" für Corosync etabliert - anderes Netz, anderes Kabel - (und aus anderen Gründen weitere Nodes hinzugefügt). In letzter Zeit hatte ich keine unmotivierten Neustarts mehr...

Viele Grüße

 

[swoop]

Danke für den Tipp, ich hatte gerade wieder einen Reboot des Clusters. Danach lief zwar alles wieder, bis auf die Starts der Server die nicht per HA konfiguriert sind, aber gut.
Der Netzwerkverkehr auf der Corosync Netzwerkschnettstelle war nicht sehr hoch. Zwischen 300 bis 600 Mbps und das auch nur kurzfristig.
Seit ich das letzte Update gemacht habe, vor dem Ceph-upgrade, war Wochenweise keine Änderung und es hat alles so funktioniert wie es soll, daher verstehe ich das jetzt nicht ganz.

Aber trotzdem danke für deinen Hinweis, ich werde das mal testen und eine zusätzliche USB-Netzwerkkarte anhängen.

Übrigens:
bei den Hosts handelt es sich um Intel NUCs i7 der 10. Generation.

SG

 

[zylon]

Hallo,

Wir habben unsere proxmox ve 6 cluster upgraded nach 7. Zeit denn upgrade, diese woche, habben wir gleiche probleme mit reboots. Der netwerkverkehr wahr beim erste reboot an der netwerk grenze beim backup. Aber auch nach backup mit idle netwerkverkehr vermist corosync die andere nodes. Und reboot das cluster. Ich verdenke das etwas im corosync oder neue proxmox ve das verursacht

PS: mein Deutsch is nicht 100% hoffenlich verstehen sie mir.

 

[swoop]

Hallo,

danke für die Rückmeldungen.
Ich habe jetzt seit dreieinhalb Tagen keine reboots mehr.
Allerdings habe ich HA für allen meine VMs abgeschaltet. Also keine HA mehr.
Zusätzlich habe ich für Corosync ein eigenes USB-Netzwerk, mit separatem Switch, eingerichetet und sogar Redundant ausgelegt. Aber trotzdem waren Neustarts zu vermelden.

Da mein Cluster soweit wieder läuft, wede ich jetzt nach und nach HA wieder aktivieren und beobachten. Ich berichten euch.

Meine Vermutung ist, dass dieses Verhalten durch eines der Updates verursacht wurde, die am 16.9.2021 gemacht wurden. Vielleicht kann das Proxmox-Team sich das anschauen und einen Tipp geben, was hier zu beachten ist, oder vielleicht gibt's irgendwelche Timeouts die man ändern kann/soll/muss.

@zylon:
Englisch geht zur Not auch

SG

 

[zylon]

Wir habben diese wochenende wieder reboots. Wir habben fur corosync eine zweiten ring auf eine seperate vlan gemacht und habe keine reboots mehr.

 

[jsterr]

Corosync sollte immer auf separatem Netzwerkinterfaces betrieben werden + Fallback. Das heißt eine eigene NIC NUR für Corosync, damit die Latenz nicht zu hoch wird. Ist die Latenz zu hoch, fenced sich der Host und startet sich neu. Wenn alle 3 Server gleichzeitig eine hohe Latenz (wegen zuviel Storage, Backup, VM-Traffic... ) haben dann sehen sich die Hosts nicht mehr vernünftigt.

Kann man gut simulieren wenn man corosync z.B. komplett die nic down (ifdown enXYZ) nimmt auf einem Host, der Host wird sich selbsständig rebooten. So ungefähr ist das auch wenn die Latenz zu hoch ist.