XCP-ng High availability
Konfiguration
Den Pool vorbereiten
Sie können überprüfen, ob Ihr Pool HA aktiviert hat oder nicht. In Xen Orchestra sehen Sie ein kleines "Wolken"-Symbol in der Ansicht "Home/Pool" für jeden Pool mit aktivierter HA.
Sie können es mit diesem xe CLI-Befehl aktivieren:
xe pool-ha-enable heartbeat-sr-uuids=<SR_UUID>
Tipp
Denken Sie daran, dass Sie ein gemeinsames SR verwenden müssen, um HA zu aktivieren.
Maximale Anzahl von Host-Ausfällen
Wie viele Host-Ausfälle können Sie tolerieren, bevor Ihnen die Optionen ausgehen? Für 2 Hosts in einem Pool ist die Antwort ziemlich einfach: 1 ist die maximale Anzahl. Warum? Nun, nach dem Verlust eines Hosts wird es unmöglich sein, eine HA-Politik sicherzustellen, wenn auch der letzte Host ausfällt.
Dieser Wert kann von XCP-ng berechnet werden, und in unserem Beispiel:
xe pool-ha-compute-max-host-failures-to-tolerate
1
Aber es könnte auch 0 sein. Denn selbst wenn Sie 1 Host verlieren, gibt es nicht genug RAM, um die HA-VM auf dem letzten zu starten? Wenn nicht, können Sie deren Überleben nicht sicherstellen. Wenn Sie die Anzahl selbst festlegen möchten, können Sie dies mit diesem Befehl tun:
xe pool-param-set ha-host-failures-to-tolerate=1 uuid=<Pool_UUID>
Wenn mehr Hosts ausfallen als dieser Wert, wird eine Systemwarnung ausgelöst: Sie befinden sich in einer Überbeanspruchungssituation.
Eine VM für HA konfigurieren
Dies ist mit Xen Orchestra ganz einfach. Gehen Sie auf Ihre VM-Seite und bearbeiten Sie das erweiterte Panel: Sie müssen nur das HA-Kontrollkästchen aktivieren.
Sie können diese Konfiguration auch mit der xe CLI durchführen:
xe vm-param-set uuid=<VM_UUID> ha-restart-priority=restart
Updates/Wartung
Vor jedem Update oder Wartungsarbeiten am Host, geplanten Neustarts und so weiter, müssen Sie Ihren Host IMMER in den Wartungsmodus versetzen. Wenn Sie dies nicht tun, wird XAPI es als ungeplanten Ausfall betrachten und entsprechend handeln.
Wenn Sie genügend Speicher haben, um einen Host in den Wartungsmodus zu versetzen (alle seine VMs auf andere Mitglieder des Pools zu migrieren), ist das in Ordnung. Wenn nicht, müssen Sie die VMs manuell von einem XAPI-Client (Xen Orchestra oder xe) herunterfahren und NICHT aus dem Betriebssystem heraus.
WARNUNG
Sie müssen vor JEGLICHEN Wartungsarbeiten sehr vorsichtig sein, da sonst HA eingreifen und unangenehme Überraschungen verursachen kann. Sie wurden gewarnt.
Verhalten
VM herunterfahren
Wenn Sie sich entscheiden, die VM mit Xen Orchestra oder xe herunterzufahren, wird die VM normal gestoppt, da XCP-ng weiß, dass dies Ihr Wunsch ist.
Wenn Sie sie jedoch direkt im Gastbetriebssystem (über die Konsole oder SSH) herunterfahren, ist XCP-ng NICHT darüber informiert, was vor sich geht. Für das System scheint es, als wäre die VM ausgefallen, und das ist eine Anomalie. Daher wird die VM automatisch neu gestartet! Dieses Verhalten verhindert, dass ein Operator das System herunterfährt und die VM für eine lange Zeit nicht verfügbar bleibt.
Beispiel
Hostausfall
Wir betrachten 3 verschiedene Szenarien für den Host, mit einem Beispiel von 2 Hosts, lab1 und lab2:
- Physisches "hartes" Herunterfahren des Servers
- Physisches Entfernen der Speicherverbindung
- Physisches Entfernen der Netzwerkverbindung
lab1 ist nicht der Pool-Master, aber die Ergebnisse wären die gleichen (nur länger zu testen, da die Zeit benötigt wird, bis der andere Host selbst zum Master wird).
Bleiben wir bei unserem Beispiel von 2 Hosts in einem einzigen Pool. Wir haben die VM Minion 1 für HA konfiguriert, und diese VM läuft auf dem Host lab1.
Nach jedem Test geht Minion 1 zurück zu lab1, um unter den exakt gleichen Bedingungen zu starten.
Den Netzstecker ziehen
Nun werden wir uns entscheiden, den Stecker für meinen Host lab1 zu ziehen: Genau hier läuft meine VM derzeit. Nach einiger Zeit (wenn XAPI den Verlust des Hosts erkennt und meldet, in der Regel 2 Minuten), können wir sehen, dass lab1 als angehalten gemeldet wird. Gleichzeitig wird die VM Minion 1 auf dem anderen laufenden Host, lab2, gestartet:
Wenn Sie sich entscheiden, den Host lab1 wieder anzuschließen, wird der Host wieder online sein, ohne dass eine VM darauf läuft, was normal ist.
Das Speicherkabel ziehen
Ein weiteres Szenario: Diesmal ziehen wir den iSCSI/NFS-Link auf lab1, obwohl Minion 1 darauf läuft.
Was passiert? Minion 1 verliert den Zugriff auf seine Festplatten und nach einiger Zeit stellt lab1 fest, dass es nicht auf die Heartbeat-Festplatte zugreifen kann. Die Fencing-Schutzfunktion wird aktiviert! Die Maschine wird neu gestartet, und danach wird jede xe CLI-Befehlsausführung auf diesem Host Ihnen diese Nachricht geben:
The host could not join the liveset because the HA daemon could not access the heartbeat disk.
Unmittelbar nach dem Fencing wird Minion 1 auf dem anderen Host neu gestartet.
INFO
lab1 ist nicht physisch angehalten, Sie können über SSH darauf zugreifen. Aber aus der Sicht von XAPI ist es tot. Jetzt versuchen wir, das Ethernet-Kabel wieder einzustecken ... und einfach abzuwarten! Alles wird wieder normal!
Das Netzwerkkabel ziehen
Schließlich der schlimmste Fall: Der Speicher bleibt betriebsbereit, aber die (Management-)Netzwerkschnittstelle wird "getrennt". Gleiches Verfahren: Stecken Sie das Kabel physisch ab und warten Sie ... Da lab1 keinen anderen Host im Pool kontaktieren kann (in diesem Fall lab2), entscheidet es sich, das Fencing-Verfahren zu starten. Das Ergebnis ist genau das gleiche wie beim vorherigen Test. Es wird für den Pool-Master als "angehalten" angezeigt, bis wir das Kabel wieder einstecken.