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

Ralli

Member
Dec 4, 2022
49
10
13
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.
 
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
Code:
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
 
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... ;-)
 
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.
 
Eventuell mal 3 USB NICs und einen Mini Switch kaufen. Dann hast du den Cluster immer stabil.
 
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.

Code:
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
 
Last edited:
  • Like
Reactions: Max2048 and Falk R.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!