Hochverfügbarkeit

Die XenServer®-Funktion für Hochverfügbarkeit (HA) stellt sicher, dass Ihre VMs mit minimaler Ausfallzeit und ohne Datenbeschädigung weiterlaufen. Wenn Probleme wie Host-Hardwarefehler und Netzwerkunterbrechungen auftreten, reagiert der XenServer-Pool, indem er betroffene VMs auf stabilen Hosts im Pool neu startet. Diese Funktion ermöglicht es Ihnen, Ihre VMs am Laufen zu halten, bis Sie Hardwareprobleme beheben können.

XenServer gewährleistet die Hochverfügbarkeit von VMs durch folgende Maßnahmen:

• Verwendung eines Netzwerk-Heartbeats zur Überprüfung der Konnektivität zwischen Hosts im Pool.
• Verwendung eines Speicher-Heartbeats zur Überprüfung der Konnektivität zwischen den Hosts und dem freigegebenen Speicher.
• Erkennung, ob ein Host ausgefallen ist.
• Erkennung, ob ein Host oder Hosts unerreichbar geworden sind.
• Abschotten von Hosts, die nicht mit der größten Partition von Hosts im Pool kommunizieren können. Ein abgeschotteter Host startet sofort neu, wodurch alle darauf laufenden VMs gestoppt werden. Nach dem Neustart versucht er, dem Ressourcenpool wieder beizutreten. Diese Vorsichtsmaßnahme verhindert, dass VMs auf zwei Hosts gleichzeitig laufen und Datenbeschädigungen riskieren.
• Markieren eines ausgefallenen, abgeschotteten oder unerreichbaren Hosts als nicht mehr Teil des aktiven Satzes von Hosts im Pool.
• Markieren aller VMs, die auf diesem Host liefen, als angehalten.
• Wenn der ausgefallene, abgeschottete oder unerreichbare Host der Pool-Koordinator ist, Neuzuweisung der Koordinatorrolle an einen anderen Host im Pool.
• Neustart aller angehaltenen VMs gemäß dem von Ihnen konfigurierten Failover-Plan.
• Überwachung von Änderungen an der Poolkonfiguration, um zu überprüfen, ob der konfigurierte Failover-Plan umgesetzt werden kann.

Da die HA-Funktion VMs automatisch auf anderen Hosts im Pool neu startet, muss XenServer sicherstellen, dass der ursprüngliche (ausgefallene oder unerreichbare) Host der VM die VM nicht mehr ausführt. Zwei Instanzen derselben VM, die gleichzeitig ausgeführt werden, können zu einer Beschädigung der VM-Daten führen. Um dies zu verhindern, sind XenServer-Hosts in einem HA-fähigen Pool proaktiv beim Selbst-Abschotten, wenn sie sich in Situationen befinden, die dazu führen könnten, dass zwei Instanzen derselben VM ausgeführt werden.

Die HA-Funktion hält Ihre wichtigen VMs am Laufen, bis Sie das zugrunde liegende Hardware- oder Netzwerkproblem beheben können. Wenn Sie feststellen, dass ein HA-Ereignis aufgetreten ist, untersuchen und beheben Sie den zugrunde liegenden Fehler, um Ihren Pool wieder voll funktionsfähig zu machen.

Dieser Artikel beschreibt Konzepte, Anforderungen und erwartetes Verhalten der Hochverfügbarkeit. Informationen zum Konfigurieren und Verwalten der Hochverfügbarkeit finden Sie unter Hochverfügbarkeit konfigurieren.

Anforderungen

Um die Hochverfügbarkeitsfunktion nutzen zu können, benötigen Sie die folgenden Elemente in Ihrer Umgebung:

• Ein XenServer-Pool: Die HA-Funktion arbeitet innerhalb eines einzelnen Ressourcenpools.

  • Wir empfehlen, dass der Pool homogen ist. Jeder Host im Pool stellt den VMs dieselben CPU-Funktionen zur Verfügung und erleichtert so das Neustarten der VMs an beliebiger Stelle im Pool.
  • Damit der Heartbeat-Mechanismus effektiv funktioniert, empfehlen wir, dass der Pool mindestens 3 Hosts hat.
  • Stellen Sie sicher, dass alle Hosts im Pool online sind, bevor Sie HA aktivieren.

• Gemeinsamer Speicher für alle Hosts im Pool: Damit jede VM im Pool nach einem Fehler auf jedem Host im Pool neu gestartet werden kann, müssen alle Hosts im Pool Zugriff auf den SR haben, auf dem die VM-Festplatten gespeichert sind.

• Ein Heartbeat-SR: Dieser SR kann derselbe SR sein, auf dem die VM-Festplatten gespeichert sind. Der Pool speichert Informationen, die es dem Pool ermöglichen, die Fehlererkennung und -wiederherstellung im Falle eines Fehlers zu koordinieren.

  • Der Heartbeat-SR muss sich auf einem iSCSI-, NFS- oder Fibre Channel-LUN befinden. Speicher, der entweder über SMB oder iSCSI mit CHAP-Authentifizierung angeschlossen ist, kann nicht als Heartbeat-SR verwendet werden. Wir empfehlen, dass dieser SR hochzuverlässig und latenzarm ist.

  • XenServer 8.4 benötigt 4 GB für den Heartbeat-SR.

    Die auf dem Heartbeat-SR gespeicherten Informationen umfassen:

    • 4 MB Heartbeat-Volume: Bietet den Speicher-Heartbeat, der überprüft, ob Hosts im Pool Zugriff auf den Speicher haben.
    • Das Metadaten-Volume: Speichert die Metadaten des Pool-Koordinators, die verwendet werden, wenn ein Failover des Pool-Koordinators auftritt. Dieses Volume nimmt den Rest des benötigten Speicherplatzes ein.

• Zuverlässige und redundante Speicherkonnektivität für den Heartbeat-SR: Damit die HA-Funktion die genaueste Ansicht darüber hat, welche Hosts auf den gemeinsam genutzten Speicher zugreifen können, konfigurieren Sie Ihre Umgebung so, dass der Speicherverkehr zuverlässig ist. Konfigurieren Sie für iSCSI- und Fibre Channel-SRs Multipathing. Verwenden Sie für NFS-SRs ein redundantes gebündeltes Netzwerk als Speichernetzwerk.

• Statische IP-Adressen für alle Hosts: HA behandelt eine Änderung der Host-IP-Adresse als Verbindungsverlust des Hosts und geht davon aus, dass das Netzwerk des Hosts ausgefallen ist. Infolgedessen kann der Host gefenced werden. Vermeiden Sie dies, indem Sie nur statische IPs in Ihrem Pool verwenden.

• Eine dedizierte gebündelte Schnittstelle im Verwaltungsnetzwerk: Damit die HA-Funktion die genaueste Ansicht des Pool-Status hat, benötigen Sie eine zuverlässige und redundante Netzwerkkommunikation zwischen den Hosts.

• Das Verwaltungsnetzwerk erlaubt Netzwerk-Heartbeat-UDP-Verkehr über Port 694: Der Netzwerk-Heartbeat überprüft, ob die Hosts im Pool aktiv sind und einander kontaktieren können.

Um eine VM zu schützen, die in Ihrem Hochverfügbarkeitspool ausgeführt wird, richten Sie Ihre VM mit der folgenden Konfiguration ein:

• Speichern Sie die VM-Festplatten auf gemeinsamem Speicher, der allen Hosts im Pool zur Verfügung steht.
• Richten Sie die virtuellen Netzwerkschnittstellen in poolweiten Netzwerken ein.
• Stellen Sie sicher, dass die VM Live-Migration verwenden kann. Weitere Informationen finden Sie unter Anforderungen an die Migrationskompatibilität.
• Verbinden Sie die VM nicht mit einem lokalen DVD-Laufwerk.

Eine VM, die all diese Kriterien erfüllt, wird als agil bezeichnet.

Eine VM, die NVIDIA vGPU oder GPU-Passthrough verwendet, kann nicht durch HA geschützt werden. Der HA-Mechanismus kann jedoch versuchen, diese VM nach bestem Wissen und Gewissen neu zu starten.

Anforderungen für GFS2-Cluster-Pools

Das Hochverfügbarkeitsverhalten für GFS2-Cluster-Pools verwendet einen anderen zugrunde liegenden Mechanismus und hat daher einige unterschiedliche Anforderungen und Verhaltensweisen. Weitere Informationen finden Sie unter GFS2-Cluster-Pools.

HA-Failover-Plan

Der HA-Mechanismus berechnet einen poolweiten Failover-Plan basierend auf den folgenden Kriterien:

• VM-Wiederherstellungsanforderungen: Jede VM kann eine Neustartpriorität und Startreihenfolge definiert haben.
• Verfügbare Pool-Ressourcen: Die wichtigste Ressource, die berücksichtigt wird, ist der Host-Speicher.
• Anzahl der zu tolerierenden Host-Ausfälle: Nachdem Sie HA in Ihrem Pool aktiviert haben, kann XenServer die maximale Anzahl von Hosts berechnen, die im Pool ausfallen können, bevor geschützte VMs nicht mehr neu gestartet werden können. Sie können die Anzahl der zu tolerierenden Host-Ausfälle auf einen Wert kleiner oder gleich diesem Wert festlegen.

Wenn ein Failover-Plan, der diese Kriterien erfüllt, nicht berechnet werden kann, wird der Pool als überlastet betrachtet. Wenn die geschützten VMs im Pool nicht neu gestartet werden können, löst XenServer eine Systemwarnung aus. Diese Warnung wird auch im XenCenter® Benachrichtigungsfeld angezeigt.

Für jede VM in Ihrem Pool können Sie deren Wiederherstellungsverhalten definieren.

Neustartpriorität

Sie können einer VM eine der folgenden Neustartprioritäten zuweisen:

• Geschützt: Wenn die VM oder ihr Host unerwartet offline geht, startet HA die VM auf einem anderen Host neu. Dieser Neustart ist garantiert, vorausgesetzt, der Pool ist nicht überlastet und die VM ist agil. Wenn der VM-Neustart fehlschlägt, versucht HA, die VM zu starten, wenn im Pool zusätzliche Kapazität vorhanden ist. Dieser Wert ist restart in der xe CLI und Neustart in XenCenter.
• Best-Effort: Wenn der Host, auf dem die VM läuft, unerwartet offline geht, versucht HA, die VM auf einem anderen Host neu zu starten. Dieser Versuch wird erst unternommen, nachdem alle geschützten VMs erfolgreich neu gestartet wurden. Hochverfügbarkeit unternimmt nur einen Versuch, eine Best-Effort-VM neu zu starten. Schlägt dieser Versuch fehl, unternimmt die Hochverfügbarkeit keine weiteren Versuche, die VM neu zu starten. Dieser Wert ist best-effort in der xe CLI und Neustart, falls möglich in XenCenter.
• Ungeschützt: Wenn die VM oder ihr Host unerwartet offline geht, versucht HA nicht, die VM neu zu starten. Dies ist die Standardeinstellung. Dieser Wert ist ein leerer String in der xe CLI und Nicht neu starten in XenCenter.

Hochverfügbarkeit stoppt oder migriert niemals eine laufende VM, um Ressourcen für den Neustart einer VM mit höherer Neustartpriorität freizugeben.

Startreihenfolge

Die Startreihenfolge ist die Reihenfolge, in der die Hochverfügbarkeit von XenServer versucht, geschützte VMs bei einem Ausfall neu zu starten. Dieser Wert wird nur für geschützte VMs verwendet. Der Standardwert ist 0, was die höchste Priorität darstellt. Geschützte VMs mit einem Startreihenfolgewert von 0 werden zuerst neu gestartet. Je höher der Startreihenfolgewert, desto später in der Sequenz wird die VM neu gestartet.

Pool-Verhalten

Nachdem Sie HA in Ihrem XenServer-Pool aktiviert haben, zeigt der Pool die folgenden Verhaltensweisen.

Verhalten während der Einrichtung

Wenn Sie HA in einem Pool aktivieren, nimmt der Pool-Koordinator die folgende Einrichtung vor:

• Berechnet den anfänglichen Failover-Plan.
• Konfiguriert die Datenbank, um Updates auf das Heartbeat-SR zu schreiben. Diese Einstellung stellt sicher, dass VM-Konfigurationsänderungen nicht verloren gehen, wenn ein Host ausfällt.
• Richtet die Metadaten des Pool-Koordinators auf dem Heartbeat-SR ein.

Alle Pool-Mitglieder:

• Senden sich gegenseitig Netzwerk-Heartbeats. Dadurch kommt es zu einem geringfügigen Anstieg des Management-Netzwerkverkehrs, da die Hosts im Pool überprüfen, ob sie miteinander kommunizieren können. Dieser Netzwerkverkehr wird fortgesetzt, solange HA aktiviert ist.

Verhalten während des normalen Betriebs

Während des normalen Betriebs führt der Pool-Koordinator eines HA-Pools die folgenden Aktionen aus (zusätzlich zu seinen üblichen Funktionen):

• Verwaltet dynamisch einen Failover-Plan. Dieser Plan beschreibt, was zu tun ist, wenn eine Reihe von Hosts in einem Pool zu einem bestimmten Zeitpunkt ausfällt. Dieser Plan berücksichtigt die maximale Anzahl von Host-Ausfällen, die toleriert werden können, und stellt sicher, dass alle geschützten VMs neu gestartet werden können. Der Plan wird basierend auf VM-Lebenszyklusoperationen und -bewegungen dynamisch neu berechnet. Wenn Änderungen (z. B. das Hinzufügen neuer VMs zum Pool) dazu führen, dass alle geschützten VMs nach der maximalen Anzahl von Host-Ausfällen nicht mehr neu gestartet werden können, kann kein Plan berechnet werden und der Pool ist überbelegt. Wenn der Pool überbelegt wird, löst XenServer einen Alarm über XenCenter, E-Mail, SNMP-Trap oder NRPE-Alarm aus.

Während des normalen Betriebs führt jedes Mitglied eines HA-Pools die folgenden Aktionen aus (zusätzlich zu seinen üblichen Funktionen):

• Überprüft, ob der Pool-Koordinator aktiv ist. Der Host tut dies, indem er versucht, eine „Master-Sperre“ auf dem freigegebenen Speicher zu erwerben. Wenn bereits ein Pool-Koordinator existiert, schlägt dieser Versuch fehl.
• Sendet einen Netzwerk-Heartbeat. Dieser Netzwerk-Heartbeat wird über UDP auf Port 694 im Management-Netzwerk an alle anderen Hosts im Pool gesendet.
• Führt eine Aufzeichnung des Livesets der Hosts im Pool. Das Liveset der Hosts, wie es jeder einzelne Host sieht, ist die Menge der anderen Hosts, die er für aktiv hält. Wenn ein Host innerhalb des durch das HA-Timeout (standardmäßig 60 Sekunden) angegebenen Zeitraums keinen Netzwerk-Heartbeat von einem anderen Host erhalten hat, kommuniziert er mit den anderen Hosts im Pool, um zu vereinbaren, ob das Liveset aktualisiert werden muss.
• Schreibt in die Statusdatei auf dem Speicher-Heartbeat-Volume. Diese Aktion überprüft, ob der Host noch Zugriff auf den Speicher hat. Sie ermöglicht es den Hosts auch, ihren Status miteinander zu kommunizieren (zusätzlich zur Kommunikation über den Netzwerk-Heartbeat).
• Aktualisiert die Datenbank auf dem Heartbeat-SR. Der Host zeichnet alle Änderungen an den VM-Konfigurationen für die von ihm gehosteten VMs auf.

Einige Pool-Operationen sind blockiert oder nicht ratsam, wenn HA aktiviert ist. Deaktivieren Sie die Hochverfügbarkeit vorübergehend, um diese Operationen durchzuführen:

• Hinzufügen eines Hosts zum Pool.
• Entfernen eines Hosts aus dem Pool. Blockiert, wenn diese Aktion dazu führen kann, dass der Pool überbelegt wird.
• Herunterfahren eines Hosts im Pool. Blockiert, wenn diese Aktion dazu führen kann, dass der Pool überbelegt wird.
• Ändern des Management-Netzwerks.
• Ändern des an den Pool angehängten SR.
• Aktivieren von Clustering. Einige Verhaltensweisen und Anforderungen der Hochverfügbarkeit unterscheiden sich bei geclusterten Pools. Weitere Informationen finden Sie unter Geclusterte Pools.

Während des normalen Betriebs aktivieren die folgenden Aktionen im Pool nicht den HA-Failover-Plan:

• Sauberes Herunterfahren einer VM über XenCenter oder die xe-CLI. Der HA-Mechanismus betrachtet diese VM nicht als ausgefallen und versucht nicht, sie neu zu starten. Weitere Informationen zu dieser Aktion finden Sie unter Herunterfahren einer durch Hochverfügbarkeit geschützten VM
• VM-Absturz oder sauberes Herunterfahren innerhalb des Gastbetriebssystems, wenn HA so konfiguriert wurde, dass VMs bei internem Herunterfahren nicht automatisch neu gestartet werden. In diesem Fall betrachtet der HA-Mechanismus die VM nicht als ausgefallen und versucht nicht, sie neu zu starten. Weitere Informationen zu dieser Einstellung finden Sie unter Konfigurieren des Neustartverhaltens für intern heruntergefahrene VMs
• Sauberes Herunterfahren eines Hosts über XenCenter oder die xe-CLI. Der HA-Mechanismus betrachtet diesen Host nicht als ausgefallen und versucht nicht, darauf gehostete VMs neu zu starten. Wenn diese Aktion jedoch dazu führt, dass der Pool überbelegt wird, wird sie von XenServer blockiert. Weitere Informationen zu dieser Aktion finden Sie unter Herunterfahren eines Hosts bei aktivierter Hochverfügbarkeit

Verhalten bei Hardwarefehlern oder Infrastrukturinstabilität

In dieser Phase sind alle Hosts im Pool dafür verantwortlich, ihren eigenen Konnektivitätsstatus zu erkennen und sich über den Konnektivitätsstatus anderer Hosts im Pool zu einigen.

XenServer HA erkennt und behandelt die folgenden Fehlertypen:

• Ausgefallener Host oder Hosts: In dieser Situation bemerken alle verbleibenden Hosts sehr schnell, dass der ausgefallene Host oder die Hosts die Aktualisierung der Statusdatei eingestellt haben und keine Netzwerk-Heartbeats mehr senden. Nach einer angemessenen Verzögerung werden diese Hosts aus dem Liveset entfernt.
• Netzwerkpartition: In dieser Situation können ein oder mehrere Hosts nicht mit einem oder mehreren anderen Hosts kommunizieren. Ein Host bemerkt, dass er innerhalb des definierten Timeouts keine Netzwerk-Heartbeats von einem oder mehreren anderen Hosts empfangen hat, und startet einen Fehlerbehandler. Dieser Fehlerbehandlungsprozess kommuniziert über die Statusdatei und den funktionierenden Netzwerk-Heartbeat und verwendet diese Informationen, um zu bestimmen, welche Netzwerkpartitionen (Gruppen von Hosts, die miteinander kommunizieren können) existieren. Die Hosts in der größten Partition bilden das Liveset und überleben. Wenn es Partitionen gleicher Größe gibt, überleben die Hosts in der Partition, die den Host mit der niedrigsten Host-UUID enthält.
• Fehlgeschlagene Speicherverbindung: In dieser Situation bemerkt ein Host, dass er den Speicher nicht erreichen kann, oder andere Hosts bemerken, dass seine Updates nicht auf dem Speicher vorhanden sind. Die Hosts kommunizieren über die Netzwerk-Heartbeat-Kommunikation, um zu überprüfen, ob andere Hosts den Speicherzugriff verloren haben:
  • Wenn alle Hosts den Speicher, aber nicht das Netzwerk verloren haben, wird dies als vorübergehender Speicherverlust betrachtet, und die Hosts bleiben aktiv, um auf die Wiederherstellung des Speichers zu warten. Bei weiteren Ausfällen werden alle Hosts im Pool gefenced. Diese Regel verhindert, dass der Speicher einen Single Point of Failure darstellt.
  • Wenn nur einige Hosts den Speicherzugriff verloren haben, aber alle Hosts weiterhin Netzwerkzugriff haben, werden diese Hosts aus dem Liveset entfernt.

Wenn ein Host weiß, dass er für die Mehrheit des Pools als ausgefallen oder unerreichbar erscheint, führt dieser Host ein Self-Fencing durch. Fencing ist ein erwartetes Verhalten, das als Schutzmaßnahme für VM-Daten konzipiert wurde. Es stellt sicher, dass eine VM nicht gleichzeitig an zwei Orten ausgeführt wird. Ein Host verwendet die folgenden Kriterien, um zu entscheiden, ob er ein Self-Fencing durchführen muss:

• Wenn der Toolstack des Hosts nicht läuft und nicht neu gestartet werden kann, führt der Host ein Self-Fencing durch.
• Wenn der Host sowohl die Netzwerk- als auch die Speicher-Heartbeats verloren hat, betrachtet sich der Host als unerreichbar und führt ein Self-Fencing durch.
• Wenn der Host den Speicher-Heartbeat verloren hat, aber weiterhin Netzwerk-Heartbeats empfängt:
  • Wenn der Host noch alle anderen Poolmitglieder kontaktieren kann und alle diese Mitglieder ebenfalls den Speicher-Heartbeat verloren haben, bleibt der Host aktiv. Dieser Fall verhindert, dass der Speicher als Single Point of Failure fungiert und den gesamten Pool fenced.
  • Wenn der Host einen oder mehrere andere Hosts im Pool nicht kontaktieren kann, führt er ein Self-Fencing durch.
• Wenn der Host Netzwerk-Heartbeats verloren hat, aber immer noch den Speicher-Heartbeat besitzt, bestimmt er, ob er sich in der größten Netzwerkpartition befindet. Wenn nicht, führt der Host ein Self-Fencing durch.
• Es besteht die Möglichkeit, dass ein Netzwerkausfall den Pool in Partitionen gleicher Größe aufteilt. Wenn ein Host anhand der Informationen in der Statusdatei auf dem Heartbeat-SR weiß, dass er sich in einer solchen Netzwerkpartition befindet:
  • Wenn die Partition den Host mit der niedrigsten UUID enthält, bleibt der Host aktiv.
  • Wenn die Partition den Host mit der niedrigsten UUID nicht enthält, führt der Host ein Self-Fencing durch.

Wenn eine Fencing-Aktion durchgeführt wird, startet der Host sofort und abrupt neu, wodurch alle darauf laufenden VMs gestoppt werden. Der gefenced Host durchläuft eine Neustartsequenz, und wenn er neu gestartet wurde, versucht er, dem Ressourcenpool wieder beizutreten.

Verhalten während der Wiederherstellung

Wenn der Pool-Koordinator der Host ist, der ausgefallen, abgeschottet oder unerreichbar geworden ist, versuchen andere Hosts, die Master-Sperre zu erhalten. Der Host, dem dies gelingt, wird zum neuen Koordinator.

Hosts, die sich selbst abgeschottet haben, starten neu und versuchen, dem Pool wieder beizutreten.

Wenn ein Host als tot markiert und seine VMs angehalten werden, ist der Pool-Koordinator für die folgenden Wiederherstellungsaktionen verantwortlich.

• Alle geschützten VMs gemäß dem Failover-Plan neu starten.
• Wenn nicht genügend Ressourcen vorhanden sind, um alle geschützten VMs zu starten, wartet der Pool-Koordinator, bis Ressourcen verfügbar werden (z. B. wenn zuvor abgeschottete Hosts dem Pool wieder beitreten), und versucht dann, die geschützten VMs zu starten.
• Nachdem alle geschützten VMs erfolgreich gestartet wurden, unternimmt der Pool-Koordinator einen Versuch, jede Best-Effort-VM neu zu starten.