HA Fencing bei Update einer anderen Node

[Falk R.]

Ich habe schon einmal gesehen, das ein Host auf dem Link0 Probleme bekommen hat und trotz verfügbarem Link1 ins Fencing gelaufen ist.
Eventuell haben die anderen Nodes auf link0 geantwortet, da der Link nicht ganz tot war.

Wenn das normales Verhalten von Corosync ist, würde eine Beeinträchtigung von link0 ausreichen.

 

[shanreich]

Ich habe gerade im Monitoring kurz vor dem Fencing ganz kleine Ausreißer bei der Latenz von der Monitoring Probe Richtung PVE03 (Cluster Link 0) gesehen, aber im Syslog ist nichts zu finden. Das kann doch nicht ausreichen, um einen Host komplett aus dem Cluster zu werfen!?

Wenn es, wie hier, nur kurzzeitig auftritt dann sollte das kein Problem sein. Auf Dauer sind >5ms allerdings ein Problem (s. Network requirements Corosync [1]).

Deine Einzeiler setzen aber "nur" den HA-Status aller VMs auf ignored, auch die, die kein HA aktiv haben

Nein, da sollten wirklich ausschließlich VMs auf ignored gesetzt werden, die auch tatsächlich in HA eingetragen sind. Es stimmt allerdings, dass dies ohne Rücksicht auf den aktuellen Status geschieht. Die LRM / CRM Methodik funktioniert in deinem Fall wohl besser.

--------------------------------

Ich habe mir das Ganze noch einmal von vorne mit einem Kollegen angesehen ob der vielleicht noch etwas sieht - man sieht die Problematik in den Logs recht gut, noch einmal etwas ausführlicher erklärt:

OVS-Restart auf pve08 um 16:09:03

Aug 31 16:09:03 pve08 systemd[1]: Starting Open vSwitch...

Auf dem unbeteiligten Node (pve-05) wird danach der Host 8 auf beiden Links als down markiert (Ich gehe mal davon aus, dass das auf den anderen Nodes genauso passiert ist):

Aug 31 16:09:05 pve05 corosync[3517]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:05 pve05 corosync[3517]:   [KNET  ] link: host: 8 link: 1 is down

Auf Nodes 3 / 4 wird jeweils nur Link 0 / 1 down markiert. Dadurch sehen sich die Nodes 3, 4 und 8.

Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] link: host: 8 link: 0 is down
Aug 31 16:09:08 pve03 corosync[1984]:   [KNET  ] host: host: 8 (passive) best link: 1 (pri: 1)

Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] link: host: 8 link: 1 is down
Aug 31 16:09:05 pve04 corosync[1991]:   [KNET  ] host: host: 8 (passive) best link: 0 (pri: 1)

Welcher Node dann welche Partition joined ist etwas racy - da gehts, einfach gesprochen, darum wer schneller ist. Nodes 3 und 4 joinen 8, weil sie den ja auch sehen und bilden dann eine Partition mit dem. Die anderen Nodes können 8 nicht sehen und bilden untereinander eine eigene Partition. Das Verhalten von Corosync in dem Fall ist in der Form absolut zu erwarten. Das Problem ist einfach, dass Node 8 nicht komplett down ist. Das erzeugt dieses - zugegebenermaßen unintuitive - Verhalten.

Das erklärt auch, warum diese Nodes dann mitgerissen wurden - obwohl pve07 sie sehen kann. Interessant wäre das Monitoring von pve07 für den Node 8 - kannst du das auch noch anhängen?

--------------------------------

Am Ende des Tages liegt die Antwort auf die Frage warum die Nodes 3 und 4 mitgerissen wurden in der Antwort auf die Frage warum speziell diese beiden Nodes den Node 8 noch sehen konnten auf zumindest einem Link. Diese Problematik liegt irgendwo im Netzwerkstack vergraben - das kann OVS sein, das kann der Switch sein, das kann ein kaputtes Kabel sein. Das kann ich leider schwer beantworten und diagnostizieren. Die Vermutung liegt nahe dass beim Reload von OVS während dem Update etwas komisch gehandled wurde von OVS - das ist aber nur Spekulation.

--------------------------------

Noch zu euren Netzwerken: Corosync hat zwar ein eigenes VLAN, allerdings teilt es sich immer noch die unterliegende Netzwerk-Infrastruktur mit dem Ceph / VM-Traffic Netzwerk. Das ist definitiv nicht optimal, da diese Netzwerke dann auch Einfluss auf Corosync haben können. Habt Ihr zumindest QoS für das Corosync-VLAN aktiviert? Generell gilt jedoch die starke Empfehlung Corosync ein eigenes Netzwerk zu geben das mit nichts anderem geteilt wird. Die anderen Netzwerke können dann als die entsprechenden Fallback-Netzwerke dienen.


[1] https://pve.proxmox.com/wiki/Cluster_Manager#_cluster_network

 

[TanDE]

Hi Stefan,

vielen Dank für die ausführliche Antwort.

Am Ende des Tages liegt die Antwort auf die Frage warum die Nodes 3 und 4 mitgerissen wurden in der Antwort auf die Frage warum speziell diese beiden Nodes den Node 8 noch sehen konnten auf zumindest einem Link. Diese Problematik liegt irgendwo im Netzwerkstack vergraben - das kann OVS sein, das kann der Switch sein, das kann ein kaputtes Kabel sein. Das kann ich leider schwer beantworten und diagnostizieren. Die Vermutung liegt nahe dass beim Reload von OVS während dem Update etwas komisch gehandled wurde von OVS - das ist aber nur Spekulation.

Ja, das verstehe ich, aber wenn doch PVE03 und PVE04 nur einen link down (von/zu Host 8!) sehen (und laut Log's ca. 50-60s verzögert dann auch den zweiten Link down - warum auch immer), warum verlassen diese beiden Hosts dann trotzdem ihre aktive Partition, da doch alle anderen Hosts im Cluster weiterhin erreichbar sind? Keine Log Meldungen, keine OSD Timeouts. Nichts. Dieser Punkt ist mir nicht klar!

Der Rest ist wahrscheinlich auch nicht mehr nachvollziehbar. Ich glaube selber noch nicht so wirklich an ein Netzwerkproblem, da alle Hosts identisch konfiguriert und angebunden sind und warum haben alle anderen Hosts im Cluster beide Links von Host 8 als down gesehen.

Und am Ende des Tages dürfte eine fehlerhafte NIC / Netzwerkkabel / Switch-Port / OVS Update /etc. an einem einzelnen Host trotzdem nicht andere Hosts im Cluster (wie in diesem Fall) mit runterreißen. Das darf einfach nicht passieren!

Noch zu euren Netzwerken: Corosync hat zwar ein eigenes VLAN, allerdings teilt es sich immer noch die unterliegende Netzwerk-Infrastruktur mit dem Ceph / VM-Traffic Netzwerk. Das ist definitiv nicht optimal, da diese Netzwerke dann auch Einfluss auf Corosync haben können. Habt Ihr zumindest QoS für das Corosync-VLAN aktiviert? Generell gilt jedoch die starke Empfehlung Corosync ein eigenes Netzwerk zu geben das mit nichts anderem geteilt wird. Die anderen Netzwerke können dann als die entsprechenden Fallback-Netzwerke dienen.


[1] https://pve.proxmox.com/wiki/Cluster_Manager#_cluster_network

Cluster Ring 0 und VM Traffic teilen sich einen 2x25 Gbit/s Bond und Cluster Ring 1 und CEPH ebenfalls. Der VM Traffic ist insgesamt vernachlässigbar. Ja, es mag besser und noch sauberer sein, Corosync vollständig zu separieren, aber das muss ja auch in einem wirtschaftlich vertretbaren Verhältnis stehen.

Ist es denn (wie Falk schreibt) wirklich so, das bei mehreren Cluster Links nur einer tatsächlich verwendet wird?

Hier noch die Erreichbarkeit von PVE08 (Cluster Link 0 / aus Sicht von PVE07 mit der Monitoring Probe):






Gibt es evtl. Schwellwerte, die wir in Corosync anpassen können?

Wie kann ich in Zukunft so eine Situation vermeiden? Gibt es irgendwas, was ich beim Upgrade des Clusters noch beachten könnte? Den Neustart von Diensten kann ich selber nicht beeinflussen. Und das Update ohne Netzwerk / Offline via iDRAC / Konsole durchzuführen ist auch schwierig, wenn ich dann nicht mehr an die Paketquellen komme. ;-)

Kann man denn nicht noch irgendwie (unkompliziert) ein Fencing für bestimmte Zeit der Wartung aussetzen??

LG
Tan

 

[TanDE]

Ich habe schon einmal gesehen, das ein Host auf dem Link0 Probleme bekommen hat und trotz verfügbarem Link1 ins Fencing gelaufen ist.
Eventuell haben die anderen Nodes auf link0 geantwortet, da der Link nicht ganz tot war.

Wenn das normales Verhalten von Corosync ist, würde eine Beeinträchtigung von link0 ausreichen.

Hmm, okay. Das wäre ja nicht so schön. :-(

Aber in diesem Fall hatten die beiden Nodes (die fenced wurden) absolut keine Probleme mit Link 0 und/oder 1. In diesem Fall ausschließlich der Host 8, bei dem gerade der OpenVSwitch neu gestartet wurde.

 

[Falk R.]

Mich interessiert das natürlich auch, was die Ursache ist. Ich hatte bisher noch nie bei Clusterupdates Probleme.
Bei mir sieht das Setup in der Regel identisch aus, dass ddr corosync Link0 über die VM Nics läuft und sekundär über Ceph Netzwerk.
Einziger Unterschied, ich habe nirgendwo produktiv OVS im Einsatz.

 

[Falk R.]

Hmm, okay. Das wäre ja nicht so schön. :-(

Aber in diesem Fall hatten die beiden Nodes (die fenced wurden) absolut keine Probleme mit Link 0 und/oder 1. In diesem Fall ausschließlich der Host 8, bei dem gerade der OpenVSwitch neu gestartet wurde.

Das Problem war da aber ein echter Netzwerkfehler, wo der Link nicht down war, aber extreme Latenzen aufgetreten sind.

 

[shanreich]

Ja, das verstehe ich, aber wenn doch PVE03 und PVE04 nur einen link down (von/zu Host 8!) sehen (und laut Log's ca. 50-60s verzögert dann auch den zweiten Link down - warum auch immer), warum verlassen diese beiden Hosts dann trotzdem ihre aktive Partition, da doch alle anderen Hosts im Cluster weiterhin erreichbar sind? Keine Log Meldungen, keine OSD Timeouts. Nichts. Dieser Punkt ist mir nicht klar!

Sobald sich die Membership ändert (was passiert ist, da Node 8 hinausgefallen ist), wird die Membership komplett neu ausgehandelt. Dadurch gibt es zu dem Zeitpunkt dann nicht so etwas wie eine aktive Partition, die muss sich nach einer Änderung der Mitglieder erst wieder bilden.

Es hat dann zu dem Zeitpunkt (vermutlich) folgende Konnektivität gegeben:

• 1,2,5,6,7,9,10 -> sehen 1-7,9,10
• 3,4 -> sehen 1-10
• 8 -> sieht 3,4

Durch diese Konstellation war es möglich, dass 3, 4 und 8 dann eine eigene Partition bilden können. Ohne Debug-Logs von Corosync (müssen explizit aktiviert werden) lässt sich hier auch keine genauere Aussage treffen. Es ist jetzt aber nicht weiter überraschend, dass sich so eine Partition bilden kann wenn sich die 3 Hosts ohne Probleme untereinander sehen können.

 

[TanDE]

Sobald sich die Membership ändert (was passiert ist, da Node 8 hinausgefallen ist), wird die Membership komplett neu ausgehandelt. Dadurch gibt es zu dem Zeitpunkt dann nicht so etwas wie eine aktive Partition, die muss sich nach einer Änderung der Mitglieder erst wieder bilden.

Es hat dann zu dem Zeitpunkt (vermutlich) folgende Konnektivität gegeben:

• 1,2,5,6,7,9,10 -> sehen 1-7,9,10
• 3,4 -> sehen 1-10
• 8 -> sieht 3,4

Durch diese Konstellation war es möglich, dass 3, 4 und 8 dann eine eigene Partition bilden können. Ohne Debug-Logs von Corosync (müssen explizit aktiviert werden) lässt sich hier auch keine genauere Aussage treffen. Es ist jetzt aber nicht weiter überraschend, dass sich so eine Partition bilden kann wenn sich die 3 Hosts ohne Probleme untereinander sehen können.

Hallo Stefan,

vielen Dank für die Erläuterung. Das würde in der Tat solch ein Verhalten erklären (vor allem, wenn es hier um ein Timing im Millisekunden Bereich geht). Ob das in jeder Situation sinnvoll ist, ist eine andere Frage ;-)

Jetzt muss ich aber leider nochmal fragen: Wie lässt sich sowas verhindern? Ich kann den Update Prozess nicht beeinflussen und somit ggf. nicht verhindern, das der Netzwerkstack einen Reload macht. Oder kann man dies mit Parametern steuern, das z.B. OVS und die Proxmox Dienste (CRM/LRM/etc.) nicht automatisch neu starten sondern auf einen Reboot warten?

Ein weiterer Workaround wäre tatsächlich das HA / Fencing im Cluster temporär zu deaktivieren, aber dies scheint ja nicht mal eben möglich zu sein. Gibt es da nicht doch irgendeine einfachere Möglichkeit, ohne auf jeden einzelnen Host im Cluster zu gehen und Dienste nacheinander zu deaktivieren? Vielleicht kann man so einen Cluster-Maintenance Mode einbauen? ;-)

Noch eine Info:
Beim PVE Upgrade 7.1 auf 7.2 wurde auch OVS neu gestartet und damit die SSH Session gekillt. Das Update musste ich dann über die Konsole (iDRAC) vom Server manuell fortsetzen. In diesem Fall habe ich Screen verwendet, um mich bei einem SSH Abbruch wieder mit der jeweiligen Konsole zu verbinden (beim PBS empfehlt ihr das auch schon in der Doku). Kann das einen Unterschied gemacht haben? Konkret: Beim letzten Update 7.1 auf 7.2 wurde dann die SSH Session abgebrochen und das Update gestoppt. Dieses habe ich dann zeitlich versetzt per Hand fortgesetzt. In diesem Fall lief alles innerhalb des Screens trotzdem weiter, d.h. OVS Neustart > Netzwerk temporär weg und direkt danach bzw. vielleicht sogar währenddessen dann der HA-Manager Neustart (und alles andere was am Ende des Updates neu gestartet wird).

Viele Grüße
Tan

 

[ce3rd]

hi, ich dachte genau für solche zwecke (eben zb updates von 1 node) ist der maintenance mode gedacht?!

https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#_maintenance_mode

hab ich da leicht was falsch verstanden - würde das nicht helfen?

thx!

 

[shanreich]

Jetzt muss ich aber leider nochmal fragen: Wie lässt sich sowas verhindern? Ich kann den Update Prozess nicht beeinflussen und somit ggf. nicht verhindern, das der Netzwerkstack einen Reload macht. Oder kann man dies mit Parametern steuern, das z.B. OVS und die Proxmox Dienste (CRM/LRM/etc.) nicht automatisch neu starten sondern auf einen Reboot warten?

Ein weiterer Workaround wäre tatsächlich das HA / Fencing im Cluster temporär zu deaktivieren, aber dies scheint ja nicht mal eben möglich zu sein. Gibt es da nicht doch irgendeine einfachere Möglichkeit, ohne auf jeden einzelnen Host im Cluster zu gehen und Dienste nacheinander zu deaktivieren? Vielleicht kann man so einen Cluster-Maintenance Mode einbauen? ;-)

Ich denke, die beste Variante wäre es wohl HA für die Zeitdauer des Upgrades zu deaktivieren. Anscheinend gibt es auch die Möglichkeit das needrestart Command über eine Umgebungsvariable (NEEDRESTART_SUSPEND bzw NEEDRESTART_MODE) zu konfigurieren, allerdings kann ich nicht sagen wie gut und vollständig das funktioniert. Das müsste man auf jeden Fall ausprobieren auf einem Test-Cluster.

Es gibt bereits Bestrebungen einen entsprechenden Befehl in PVE einzubauen, der es ermöglicht HA temporär zu deaktivieren - das entsprechende Issue findet sich in unserem Bugzilla [2]. Bis dahin gibt es nur die manuelle Möglichkeit, die du bereits erwähnt hast.

hi, ich dachte genau für solche zwecke (eben zb updates von 1 node) ist der maintenance mode gedacht?!

https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#_maintenance_mode

hab ich da leicht was falsch verstanden - würde das nicht helfen?

Der Maintenance Mode dient dazu alle HA-Ressource von einem Node wegzumigrieren. Er deaktiviert das Fencing allerdings cluster-weit, sondern nur auf dem jeweiligen Node der im Status maintenance ist.



[1] https://manpages.ubuntu.com/manpages/jammy/man1/needrestart.1.html
[2] https://bugzilla.proxmox.com/show_bug.cgi?id=2751

 

[TanDE]

Ich denke, die beste Variante wäre es wohl HA für die Zeitdauer des Upgrades zu deaktivieren. Anscheinend gibt es auch die Möglichkeit das needrestart Command über eine Umgebungsvariable (NEEDRESTART_SUSPEND bzw NEEDRESTART_MODE) zu konfigurieren, allerdings kann ich nicht sagen wie gut und vollständig das funktioniert. Das müsste man auf jeden Fall ausprobieren auf einem Test-Cluster.

Es gibt bereits Bestrebungen einen entsprechenden Befehl in PVE einzubauen, der es ermöglicht HA temporär zu deaktivieren - das entsprechende Issue findet sich in unserem Bugzilla [2]. Bis dahin gibt es nur die manuelle Möglichkeit, die du bereits erwähnt hast.



Der Maintenance Mode dient dazu alle HA-Ressource von einem Node wegzumigrieren. Er deaktiviert das Fencing allerdings cluster-weit, sondern nur auf dem jeweiligen Node der im Status maintenance ist.



[1] https://manpages.ubuntu.com/manpages/jammy/man1/needrestart.1.html
[2] https://bugzilla.proxmox.com/show_bug.cgi?id=2751

Wenn ich das richtig verstehe, müsste das "needrestart" Package dafür auch installiert sein, was bei PVE nicht der Fall ist. Somit fällt das wahrscheinlich raus. Ich finde auch keine vernünftige Möglichkeit, den automatisierten Service Restart nach einem Upgrade zu unterbinden.

Dann werde ich leider warten müssen, bis diese Funktionalität implementiert wird. :-/

@shanreich Könnte ich nicht nur auf der Maschine, die gerade aktualisiert wird, corosync (und/oder LRM und CRM) vorher stoppen bzw. temporär deaktivieren? Dann würde dieser Host zumindest nicht versuchen, eine neue Partition mit willkürlichen anderen Hosts zu erstellen?! Oder gibt es dann andere Probleme?