High Availability stoppt alle LXCs/VMs

[ThomasKT]

Ich bin auf ein für mich sehr unschönes HA-Verhalten gestoßen.

Als Vorbereitung einer größeren Serverinstallation in unserer Firma habe ich einen kleinen Testcluster aufgesetzt, welcher ansonsten auch gut funktioniert.


Mein noch Test Cluster besteht aus 2 Nodes + Quorum Device.

Es gibt einen HA-LXC und mehrere nicht-HA-LXCs.



Problem:

Wenn ich nun den Node auf dem der HA-LXC läuft im Netzwerk isoliere, wird der HA-LXC gestoppt und wie gewollt auf dem andern Node neu gestartet.

Aber alle anderen nicht-HA-LXCs werden ebenfalls gestoppt, was von mir nicht gewollt ist!



Wenn ich im Gegenzug den Node isoliere auf dem der HA-LXC nicht läuft, laufen die nicht-HA-LXCs weiter.



Ich habe dann auch testweise die eigentlichen nicht-HA-LXCs für HA konfiguriert aber auf State "ignored" gesetzt - oh Wunder State "ignored" wird ignoriert nicht der LXC.



Gibt es da irgendeine Einstellung dieses Verhalten abzustellen.



Das Ziel ist die nicht-HA-VMs/LXCs sollen auf dem Node wirklich weiterlaufen, da diese

eine abgeschlossene Simulationsumgebung bilden,

ohne Kontakt zum äußeren Netzwerk (nur Monitoring und Konfigurieren) laufen,

aus mehreren VM/LXC (10-20+) bestehen wird

und es sehr unschön wäre diese nach einem Netzwerkfehler (wie auch immer) alle in Abhängigkeit neu zu starten.

 

[dakralex]

Hi!

Wenn ich nun den Node auf dem der HA-LXC läuft im Netzwerk isoliere, wird der HA-LXC gestoppt und wie gewollt auf dem andern Node neu gestartet.

Aber alle anderen nicht-HA-LXCs werden ebenfalls gestoppt, was von mir nicht gewollt ist!

Wenn "im Netzwerk isoliere" bedeutet, dass die Node keine Verbindung mehr zu den anderen Nodes in dem Cluster hat, dann würde das bedeuten, dass dadurch die ganze Node gefenced wird auf der die HA-Container laufen. Das bedeutet dann wiederum, dass auch Nicht-HA Gäste durch das Fencing gestoppt werden, da die ganze Node neugestartet wird.

Der Grund dahinter ist, dass ab dem Zeitpunkt der Netzwerkisolierung die restlichen Cluster-Nodes den Zustand der HA-Gäste nicht abfragen können. Da diese Gäste HA sein sollen aber gleichzeitig verhindert werden muss, dass die gleichen HA-Gäste nicht mehrfach laufen (Split-Brain, z.B. kann die isolierte Node möglicherweise immer noch auf das shared storage schreiben) wird die isolierte Node gefenced und neugestartet, sodass diese HA-Gäste auf einer anderen Node gestartet werden können, wenn sicher ist dass die andere Node neu gestartet wurde und somit die HA-Gäste nicht mehr laufen.

Der Grund warum das bei einer Node ohne HA-Gästen nicht passiert liegt daran, dass das LRM dieser Node 'idle' ist, da es keine aktiven HA-Gäste gibt und dadurch auch kein Fencing benötigt.

Eine Möglichkeit dies zu umgehen ist es die Nicht-HA-Gäste auf einer eigenen Node laufen zu lassen und die HA-Gäste von dieser Node auszuschließen, z.B. durch HA Node Affinity-Regeln.

 

[ThomasKT]

Hi dakralex,

danke. Sozusagen sorgt der Neustart dafür, dass auch wirklich alle HA-Gäste aus sind.

wenn sicher ist dass die andere Node neu gestartet wurde und somit die HA-Gäste nicht mehr laufen.

Aber wie bekommen nun die restlichen Nodes mit, dass der isolierte auch wirklich zumindest runtergefahren ist? Bzw. rechtzeitig unten ist?


LG,
Thomas

 

[dakralex]

Aber wie bekommen nun die restlichen Nodes mit, dass der isolierte auch wirklich zumindest runtergefahren ist? Bzw. rechtzeitig unten ist?

Das wird durch den Fencing-Mechanismus sichergestellt: Standardmäßig verwendet der HA Stack das softdog Kernel Modul, welches unter Normalbedingungen in regelmäßigen Abständen diesen Watchdog resettet. Das kann aber nur passieren, wenn das LRM der Node auch das Node-eigene LRM-Lock besitzt, welches aber über das pmxcfs geht. Sprich, wenn es keinen Netzwerkzugriff mehr zu dem pmxcfs gibt, dann wird auch nicht der Watchdog resettet und damit fällt die Node standardmäßig nach 60 Sekunden aus.

Der HA Manager erkennt dass die Node seit einer bestimmten Zeit kein Update mehr gesendet hat und markiert diese dann mit dem Status fence, wo der HA Manager versucht das LRM-Lock (welches nach ~120 Sekunden ausläuft) zu bekommen. Wenn das gelingt kann sich der HA Manager sicher sein, dass die Node bereits neugestart wurde und das Lock nicht mehr halten kann und kann somit die HA-Gäste auf anderen laufenden Nodes recoveren.

In der Proxmox VE HA Doku gibt es da noch mehr dazu: https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#ha_manager_fencing