Hohe Verfügbarkeit

Die Hochverfügbarkeitsfunktion (HA) von XenServer stellt sicher, dass Ihre VMs mit minimalen Ausfallzeiten und ohne Datenbeschädigung weiterlaufen. Wenn Probleme wie Host-Hardwarefehler und Netzwerkstörungen auftreten, reagiert der XenServer-Pool, indem er die betroffenen VMs auf stabilen Hosts im Pool neu startet. Mit dieser Funktion können Sie Ihre VMs am Laufen halten, bis Sie sämtliche Hardwareprobleme behoben haben.

XenServer gewährleistet die Hochverfügbarkeit von VMs auf folgende Weise:

• Verwenden eines Netzwerk-Heartbeats, um die Konnektivität zwischen Hosts im Pool zu überprüfen.
• Verwenden eines Speicher-Heartbeats, um die Konnektivität zwischen den Hosts und dem gemeinsam genutzten Speicher zu überprüfen.
• Erkennen, ob ein Host ausgefallen ist.
• Erkennen, ob ein oder mehrere Hosts nicht mehr erreichbar sind.
• Einzäunen von Hosts, die nicht mit der größten Hostpartition im Pool kommunizieren können. Ein eingezäunter Host wird sofort neu gestartet, wodurch alle darauf ausgeführten VMs gestoppt werden. Nach dem Neustart versucht es, sich wieder dem Ressourcenpool anzuschließen. Diese Vorsichtsmaßnahme verhindert, dass VMs auf zwei Hosts gleichzeitig ausgeführt werden und das Risiko einer Datenbeschädigung besteht.
• Markieren eines ausgefallenen, eingezäunten oder nicht erreichbaren Hosts als nicht mehr Teil der Live-Hostgruppe im Pool.
• Markieren aller auf diesem Host ausgeführten VMs als angehalten.
• Wenn der ausgefallene, eingezäunte oder nicht erreichbare Host der Poolkoordinator ist, wird die Koordinatorrolle einem anderen Host im Pool neu zugewiesen.
• Neustarten aller angehaltenen VMs gemäß dem von Ihnen konfigurierten Failover-Plan.
• Überwachen Sie alle Änderungen an der Poolkonfiguration, um zu überprüfen, ob der konfigurierte Failoverplan umgesetzt werden kann.

Da die HA-Funktion VMs auf anderen Hosts im Pool automatisch neu startet, muss XenServer sicherstellen, dass der ursprüngliche (ausgefallene oder nicht erreichbare) Host der VM die VM nicht mehr ausführt. Wenn zwei Instanzen derselben VM gleichzeitig ausgeführt werden, kann dies zu einer Beschädigung der VM-Daten führen. Um sich vor dieser Möglichkeit zu schützen, ergreifen XenServer-Hosts in einem HA-fähigen Pool proaktiv Maßnahmen zur Selbstumzäunung, 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 wichtigsten 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 die volle Kapazität Ihres Pools wiederherzustellen.

In diesem Artikel werden Konzepte, Anforderungen und erwartete Verhaltensweisen im Zusammenhang mit hoher Verfügbarkeit beschrieben. Informationen zum Konfigurieren und Verwalten von Hochverfügbarkeit finden Sie unter Konfigurieren von Hochverfügbarkeit.

Anforderungen

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

• Ein XenServer-Pool: Die HA-Funktion wird innerhalb eines einzelnen Ressourcenpools ausgeführt.

  • Wir empfehlen einen homogenen Pool. Jeder Host im Pool stellt den VMs dieselben CPU-Funktionen zur Verfügung und erleichtert den Neustart der VMs überall im Pool.
  • Damit der Heartbeat-Mechanismus effektiv funktioniert, empfehlen wir, dass der Pool über mindestens 3 Hosts verfügt.
  • Stellen Sie sicher, dass alle Hosts im Pool online sind, bevor Sie HA aktivieren.

• Gemeinsam genutzter 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, in dem die VM-Festplatten gespeichert sind.

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

  • Der Heartbeat SR muss sich auf einem iSCSI-, NFS- oder Fibre Channel-LUN befinden. Bei der Authentifizierung per CHAP kann über SMB oder iSCSI angeschlossener Speicher nicht als Heartbeat-SR verwendet werden. Wir empfehlen, dass dieser SR sehr zuverlässig ist und eine geringe Latenz aufweist.

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

    Zu den auf dem Heartbeat SR gespeicherten Informationen gehören:

    • 4 MB Heartbeat-Volume: Stellt den Speicher-Heartbeat bereit, der überprüft, ob Hosts im Pool Zugriff auf den Speicher haben.
    • Das Metadatenvolume: Speichert die Metadaten des Poolkoordinators, die bei einem Failover des Poolkoordinators verwendet werden sollen. Dieses Volumen nimmt den restlichen benötigten Platz ein.

• Zuverlässige und redundante Speicherkommunikation für den Heartbeat SR: Damit die HA-Funktion eine möglichst genaue 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 ausfallsicheres verbundenes Netzwerk als Speichernetzwerk.

• Statische IP-Adressen für alle Hosts: HA behandelt eine Änderung der Host-IP-Adresse so, als ob der Host die Verbindung verliert, und geht davon aus, dass das Netzwerk des Hosts ausgefallen ist. Der Gastgeber kann dadurch fechten. Vermeiden Sie dies, indem Sie in Ihrem Pool nur statische IPs verwenden.

• Eine dedizierte verbundene Schnittstelle im Verwaltungsnetzwerk: Damit die HA-Funktion eine möglichst genaue Ansicht des Poolstatus erhält, benötigen Sie eine zuverlässige und redundante Netzwerkkommunikation zwischen den Hosts.

• Das Verwaltungsnetzwerk lässt Netzwerk-Heartbeat-UDP-Verkehr über Port 694 zu.: Der Netzwerk-Heartbeat überprüft, ob die Hosts im Pool aktiv sind und miteinander Kontakt aufnehmen 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-Datenträger auf einem gemeinsam genutzten 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 Livemigration verwenden kann. Weitere Informationen finden Sie unter Migrationskompatibilitätsanforderungen.
• Verbinden Sie die VM nicht mit einem lokalen DVD-Laufwerk.

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

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

Anforderungen für Clusterpools

Das Hochverfügbarkeitsverhalten für Cluster-Pools verwendet einen anderen zugrunde liegenden Mechanismus und weist daher einige andere Anforderungen und Verhaltensweisen auf. Weitere Informationen finden Sie unter Clustered Pools.

HA-Failover-Plan

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

• VM-Wiederherstellungsanforderungen: Für jede VM können eine Neustartpriorität und eine Startreihenfolge definiert werden.
• Verfügbare Poolressourcen: Die wichtigste Ressource, die berücksichtigt wird, ist der Hostspeicher.
• Die Anzahl der zu tolerierenden Hostausfä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 Hostfehler kleiner oder gleich diesem Wert festlegen.

Wenn kein Failover-Plan berechnet werden kann, der diese Kriterien erfüllt, gilt der Pool als überlastet. Wenn die geschützten VMs im Pool nicht neu gestartet werden können, gibt XenServer eine Systemwarnung aus. Diese Warnung wird auch im XenCenter Benachrichtigungsbereich angezeigt.

Sie können für jede VM in Ihrem Pool ihr 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, sofern der Pool nicht überlastet ist und die VM agil ist. Wenn der VM-Neustart fehlschlägt, versucht HA, die VM zu starten, wenn im Pool freie Kapazität vorhanden ist. Dieser Wert ist Neustart auf 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. Bei hoher Verfügbarkeit wird nur ein Versuch unternommen, eine Best-Effort-VM neu zu starten. Wenn dieser Versuch fehlschlägt, unternimmt die Hochverfügbarkeit keine weiteren Versuche, die VM neu zu starten. Dieser Wert beträgt Best-Effort auf der Xe-CLI und Neustart, wenn 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 eine leere Zeichenfolge in der Xe-CLI und . Starten Sie in XenCenter nicht neu.

Durch die hohe Verfügbarkeit wird eine laufende VM niemals gestoppt oder migriert, um Ressourcen freizugeben und eine VM mit einer höheren Neustartpriorität neu zu starten.

Reihenfolge starten

Die Startreihenfolge ist die Reihenfolge, in der XenServer High Availability versucht, geschützte VMs neu zu starten, wenn ein Fehler auftritt. Dieser Wert wird nur für geschützte VMs verwendet. Der Standardwert ist 0, was der höchsten Priorität entspricht. 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.

Poolverhalten

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

Verhalten während der Einrichtung

Wenn Sie HA in einem Pool aktivieren, führt der Poolkoordinator die folgende Einrichtung durch:

• Berechnet den anfänglichen Failover-Plan.
• Konfiguriert die Datenbank zum Schreiben von Aktualisierungen in den Heartbeat SR. Diese Einstellung stellt sicher, dass VM-Konfigurationsänderungen nicht verloren gehen, wenn ein Host ausfällt.
• Richtet die Metadaten des Poolkoordinators auf dem Heartbeat SR ein.

Alle Poolmitglieder:

• Senden Sie sich gegenseitig Netzwerk-Heartbeats. Dies führt zu einer leichten Zunahme des Verwaltungsnetzwerkverkehrs, da die Hosts im Pool überprüfen müssen, ob sie miteinander kommunizieren können. Dieser Netzwerkverkehr wird fortgesetzt, solange HA aktiviert ist.

Verhalten im Normalbetrieb

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

• Verwaltet dynamisch einen Failover-Plan. Dieser Plan beschreibt detailliert, was zu tun ist, wenn eine Gruppe von Hosts in einem Pool zu einem bestimmten Zeitpunkt ausfällt. Dieser Plan berücksichtigt die maximal tolerierbare Anzahl von Hostausfällen und stellt sicher, dass alle geschützten VMs neu gestartet werden können. Der Plan wird basierend auf VM-Lebenszyklusvorgängen und -Bewegung dynamisch neu berechnet. Wenn aufgrund von Änderungen (beispielsweise dem Hinzufügen neuer VMs zum Pool) alle geschützten VMs nach der maximalen Anzahl an Hostausfällen nicht mehr neu gestartet werden können, ist keine Planberechnung möglich und der Pool ist überlastet. Wenn der Pool überlastet ist, löst XenServer eine Warnung über XenCenter, E-Mail, SNMP-Trap oder NRPE-Warnung aus.

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

• Überprüft, ob der Poolkoordinator aktiv ist. Der Host tut dies, indem er versucht, eine „Hauptsperre“ für den gemeinsam genutzten Speicher zu erhalten. Wenn bereits ein Pool-Koordinator vorhanden ist, schlägt dieser Versuch fehl
• Senden Sie einen Netzwerk-Heartbeat. Dieser Netzwerk-Heartbeat wird per UDP über Port 694 im Verwaltungsnetzwerk an alle anderen Hosts im Pool gesendet.
• Führt eine Aufzeichnung des Livesets der Hosts im Pool. Der Livesatz von Hosts ist für jeden einzelnen Host die Menge der anderen Hosts, von denen er annimmt, dass sie live sind. Wenn ein Host innerhalb der durch das HA-Timeout angegebenen Zeitspanne (standardmäßig 60 Sekunden) keinen Netzwerk-Heartbeat von einem anderen Host empfangen 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 weiterhin Zugriff auf den Speicher hat. Darüber hinaus können die Hosts sich gegenseitig ihren Status mitteilen (zusätzlich zur Kommunikation über den Netzwerk-Heartbeat).
• Aktualisiert die Datenbank auf dem Heartbeat SR. Der Host zeichnet alle Änderungen an VM-Konfigurationen für die von ihm gehosteten VMs auf.

Wenn HA aktiviert ist, werden einige Poolvorgänge blockiert oder nicht empfohlen. Deaktivieren Sie die Hochverfügbarkeit vorübergehend, um diese Vorgänge auszuführen:

• Einen Host zum Pool hinzufügen.
• Entfernen eines Hosts aus dem Pool. Wird blockiert, wenn diese Aktion zu einer Überlastung des Pools führen kann.
• Herunterfahren eines Hosts im Pool. Wird blockiert, wenn diese Aktion zu einer Überlastung des Pools führen kann.
• Ändern des Verwaltungsnetzwerks.
• Ändern des an den Pool angeschlossenen SR.
• Clustering aktivieren. Einige Verhaltensweisen und Anforderungen in Bezug auf hohe Verfügbarkeit unterscheiden sich bei Cluster-Pools. Weitere Informationen finden Sie unter Clusterpools.

Während des Normalbetriebs wird durch die Ausführung dieser Aktionen im Pool der HA-Failoverplan nicht aktiviert:

• Sauberes Herunterfahren der VM von XenCenter oder der 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 hohe Verfügbarkeit geschützten VM
• Sauberes Herunterfahren des Hosts von XenCenter oder der XE-CLI. Der HA-Mechanismus betrachtet diesen Host nicht als ausgefallen und versucht nicht, die darauf gehosteten VMs neu zu starten. Wenn diese Aktion jedoch dazu führt, dass der Pool überlastet wird, wird er von XenServer blockiert. Weitere Informationen zu dieser Aktion finden Sie unter Herunterfahren eines Hosts, wenn Hochverfügbarkeit aktiviert ist

Verhalten bei Hardwarefehlern oder Infrastrukturinstabilität

Während dieser Phase sind alle Hosts im Pool dafür verantwortlich, ihren eigenen Verbindungsstatus zu erkennen und den Verbindungsstatus anderer Hosts im Pool abzustimmen.

XenServer HA erkennt und behandelt die folgenden Fehlertypen:

• Ausgefallener Host oder Hosts: In dieser Situation bemerken alle verbleibenden Hosts sehr schnell, dass der oder die ausgefallenen Hosts die Aktualisierung der Statusdatei eingestellt haben und keine Netzwerk-Heartbeats mehr senden. Nach einer entsprechenden 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 stellt fest, dass er innerhalb des definierten Timeouts keine Netzwerk-Heartbeats von einem oder mehreren anderen Hosts empfangen hat und startet einen Fehlerhandler. 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) vorhanden sind. Die Hosts in der größten Partition sind das Liveset und überleben. Wenn Partitionen gleich groß sind, bleiben die Hosts in der Partition erhalten, 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 ihre Updates auf dem Speicher nicht vorhanden sind. Die Hosts kommunizieren über die Netzwerk-Heartbeat-Kommunikation, um zu prüfen, ob andere Hosts den Speicherzugriff verloren haben:
  • Wenn bei allen Hosts der Speicher verloren geht, nicht jedoch das Netzwerk, wird dies als vorübergehender Speicherverlust betrachtet und die Hosts bleiben aktiv und warten auf die Wiederherstellung des Speichers. Bei weiteren Ausfällen alle Gastgeber im Poolzaun. Diese Regel verhindert, dass der Speicher einen einzelnen Ausfallpunkt darstellt.
  • Wenn nur einige Hosts den Speicherzugriff verloren haben, alle Hosts aber weiterhin über Netzwerkzugriff verfügen, werden diese Hosts aus dem Liveset entfernt.

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

• Wenn der Toolstack des Hosts nicht ausgeführt wird und nicht neu gestartet werden kann, führt der Host eine Selbstabschottung durch.
• Wenn der Host sowohl die Netzwerk- als auch die Speicher-Heartbeats verloren hat, betrachtet sich der Host als nicht erreichbar und führt eine Selbstabschottung durch.
• Wenn der Host den Speicher-Heartbeat verloren hat, aber weiterhin Netzwerk-Heartbeats empfängt:
  • Wenn der Host weiterhin Kontakt zu allen anderen Poolmitgliedern aufnehmen kann und alle diese Mitglieder ebenfalls den Speicher-Heartbeat verloren haben, bleibt der Host aktiv. In diesem Fall wird verhindert, dass der Speicher als einzelner Ausfallpunkt fungiert und den gesamten Pool einzäunt.
  • Wenn der Host einen oder mehrere andere Hosts im Pool nicht kontaktieren kann, führt er eine Selbstbegrenzung durch.
• Wenn der Host Netzwerk-Heartbeats verloren hat, aber immer noch über den Speicher-Heartbeat verfügt, wird ermittelt, ob er sich in der größten Netzwerkpartition befindet. Ist dies nicht der Fall, führt der Host eine Selbstverteidigung durch.
• Es besteht die Möglichkeit, dass ein Fehler bei der Netzwerkkommunikation den Pool in gleich große Partitionen aufteilt. Wenn ein Host anhand der Informationen in der Statusdatei des 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 nicht den Host mit der niedrigsten UUID enthält, führt der Host eine Selbstbegrenzung durch.

Wenn eine Zaunaktion ausgeführt wird, wird der Host sofort und abrupt neu gestartet, was dazu führt, dass alle darauf ausgeführten VMs gestoppt werden. Der eingezäunte Host führt eine Neustartsequenz durch und versucht nach dem Neustart, sich wieder dem Ressourcenpool anzuschließen.

Verhalten während der Wiederherstellung

Wenn der Pool-Koordinator der Host ist, der ausgefallen ist, eingezäunt ist oder nicht erreichbar ist, versuchen andere Hosts, die Hauptsperre zu erhalten. Der erfolgreiche Host wird der neue Koordinator.

Hosts mit Selbsteingrenzung werden neu gestartet und versuchen, dem Pool wieder beizutreten.

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

• Starten Sie alle geschützten VMs gemäß dem Failover-Plan neu.
• 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 eingezäunte Hosts dem Pool wieder beitreten) und versucht dann, die geschützten VMs zu starten.
• Nachdem alle geschützten VMs erfolgreich gestartet wurden, unternimmt der Poolkoordinator einen Versuch, jede Best-Effort-VM neu zu starten.