HA-Cluster 3 Nodes an einem Switch, best-practice bei Switch-Update?

[Ralli]

Hallo zusammen,

folgende Situation ist gegeben: ein Homelab-Cluster mit 3 Nodes (mit je einer NIC) an einem Switch. Auf zwei der Nodes laufen VMs und LXCs in HA, auf einem der Nodes lediglich zwei LXCs ohne HA.

Nun kommt es hin und wieder vor, dass der Switch ein Update braucht und deswegen auch mal kurzzeitig außer Betrieb genommen werden muss. Dabei ist es für mich absolut hinnehmbar, dass kurzzeitig die VMs und LXCs nicht im Netz erreichbar sind.

Bei der letzten Switch-Wartung habe ich folgendes Vorgehen gewählt: Node 3 herunterfahren, Node 2 herunterfahren (alle HA-VMs und LXCs wurden dadurch auf Node 1 migriert, so weit das erwartete Verhalten). Node 1 habe ich mit den laufenden VMs und LXCs in Betrieb gelassen - Node 2 und Node 3 konnte er nicht mehr sehen, da diese heruntergefahren waren - alle LXCs und VMs liefen weiter. Danach habe ich das Switch-Update gestartet - der Verlust der Netzwerkanbindung von Node 1 hat aber dazu geführt, dass dieser nun etwas ratlos war und neu gestartet ist - die VMs und LXCs sind dabei nicht hochgekommen.

Meine Frage nun: muss ich zukünftig auch Node 1 herunterfahren oder was kann/muss/sollte ich tun, um das gezeigte Verhalten (Neustart von Node 1, LXCs und VMs werden gestoppt und nicht neu gestartet) zu vermeiden - ich würde mir wünschen, dass Node 1 hier einfach unbeeindruckt weiter läuft.

 

[UdoB]

Man kann manuell im WebGui die relevanten VMs von "started" auf "ignored" stellen. Wenn man das bei allen VMs getan hat, zeigt die Status-Tabelle für alle Nodes/lrm "idle" statt "active". Ausschliesslich die Nodes mit aktivem lrm sind "reboot-gefähred".

Wenn ich das richtig sehe, ist dies ein alternatives Vorgehen: man kann auf allen Nodes

systemctl stop pve-ha-lrm.service
systemctl stop pve-ha-crm.service

ausführen. Fencing/Reboot findet dann nicht mehr statt. (Ich habe das jetzt gerade _nicht_ getestet, man findet dies per Suche hier im Forum.)

Man testet so etwas ja selten - man möge ich korrigieren, falls ich das falsch dargestellt habe...

Viele Grüße

 

[Falk R.]

Du musst deinem Cluster mit pvecm expected 1 sagen, dass auch ein Knoten allein leben darf.
https://pve.proxmox.com/wiki/Cluster_Manager

 

[sb-jw]

Bei Updates beende ich auch immer diese Services um ein Reboot zu verhindern, hat bisher wunderbar funktioniert.

Es gibt da mittlerweile aber auch den Maintenance Mode https://pve.proxmox.com/wiki/High_Availability#ha_manager_node_maintenance

 

[UdoB]

Du musst deinem Cluster mit pvecm expected 1 sagen, dass auch ein Knoten allein leben darf.

Das kann man aber erst tun, nachdem die Netzwerkverbindung bereits gekappt wurde. Solange noch mehr als ein Node lebt, verweigert sich dieser Befehl - korrekterweise, wie ich meine.

Und: verhindert das einen Reboot? HA ist ja definitiv bereits tot, wenn nur noch ein Node lebt.

Es gibt Unterschiede zwischen "normalem Quorum Anforderungen", welches man per "expected" beeinflussen kann und "HA"-Effekten. "Man sollte" das mal testen... ;-)

 

[Falk R.]

Ich teste das nicht, da ich meine Cluster immer Redundant auslege und diese Bastellei für mich keinen Lerneffekt hat.
Sogar mein kleinster (Minisforum GX41) mit Quad Celeron hat zwei Netzwerkkarten. Ich würde gar keinen Rechner mehr ohne 2 NICs kaufen.
Also bei der nächsten Beschaffung mal drauf achten.

 

[Ralli]

Vielen Dank für eure Beiträge!

 

[Falk R.]

Eventuell mal 3 USB NICs und einen Mini Switch kaufen. Dann hast du den Cluster immer stabil.

 

[Ralli]

Kurze Rückmeldung:

Die Varianten mit dem Stoppen der Dienste lrm und crm sowie mit pvmce expected 1 haben nicht zum gewünschten Verhalten geführt.

Da ich lösungsorientiert und weniger budgetorientiert bin, bin ich dem Vorschlag von Falk gefolgt und habe drei USB-NICs besorgt und einen zweiten Corosync-Ring konfiguriert. Klappt - works as designed.

Grundsätzlich habe ich einen ring0 mit Prio 20 auf der fest verbauten NIC konfiguriert, im folgenden Log erkennt man, dass Corosync auf den ring1 mit Prio 10 bei dem Node pve-n3 ausweicht, bei dem ich für eine knappe Minute das Netzwerkkabel der fest verbauten NIC abgezogen habe. Während der Zeit blieb das Votum bei drei im Cluster. Nach dem Wiederanstecken des Netzwerkkabels wurde auf ring0 zurückgeschwenkt.

Jan 23 08:16:28 pve-n3 corosync[1285]:   [KNET  ] link: host: 2 link: 0 is down
Jan 23 08:16:28 pve-n3 corosync[1285]:   [KNET  ] link: host: 1 link: 0 is down
Jan 23 08:16:28 pve-n3 corosync[1285]:   [KNET  ] host: host: 2 (passive) best link: 1 (pri: 10)
Jan 23 08:16:28 pve-n3 corosync[1285]:   [KNET  ] host: host: 1 (passive) best link: 1 (pri: 10)
Jan 23 08:17:27 pve-n3 corosync[1285]:   [KNET  ] rx: host: 2 link: 0 is up
Jan 23 08:17:27 pve-n3 corosync[1285]:   [KNET  ] link: Resetting MTU for link 0 because host 2 joined
Jan 23 08:17:27 pve-n3 corosync[1285]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 20)
Jan 23 08:17:27 pve-n3 corosync[1285]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Jan 23 08:17:28 pve-n3 corosync[1285]:   [KNET  ] rx: host: 1 link: 0 is up
Jan 23 08:17:28 pve-n3 corosync[1285]:   [KNET  ] link: Resetting MTU for link 0 because host 1 joined
Jan 23 08:17:28 pve-n3 corosync[1285]:   [KNET  ] host: host: 1 (passive) best link: 0 (pri: 20)
Jan 23 08:17:28 pve-n3 corosync[1285]:   [KNET  ] pmtud: Global data MTU changed to: 1397