Hohe Verfügbarkeit

Hohe Verfügbarkeit ist eine Reihe von automatischen Funktionen, die entwickelt wurden, um Probleme zu planen und sicher zu beheben, die HASH (0x2e68218) Server ausschalten oder sie unerreichbar machen. Beispielsweise bei physisch gestörten Netzwerk- oder Host-Hardwarefehlern.

Übersicht

Hohe Verfügbarkeit stellt sicher, dass VMs, die auf diesem Host ausgeführt werden, heruntergefahren und auf einem anderen Host neu gestartet werden, wenn ein Host nicht erreichbar oder instabil wird. Durch das Herunterfahren und Neustarten von VMs auf einem anderen Host wird verhindert, dass die VMs (manuell oder automatisch) auf einem neuen Host gestartet werden. Irgendwann später wird der ursprüngliche Host wiederhergestellt. Dieses Szenario kann zu zwei Instanzen derselben VM führen, die auf verschiedenen Hosts ausgeführt werden, und zu einer entsprechenden hohen Wahrscheinlichkeit von VM-Festplattenbeschädigung und Datenverlust führen.

Wenn der Poolmaster nicht erreichbar oder instabil wird, kann die hohe Verfügbarkeit auch die administrative Kontrolle eines Pools wiederherstellen. Hohe Verfügbarkeit stellt sicher, dass die administrative Kontrolle automatisch ohne manuellen Eingriff wiederhergestellt wird.

Optional kann die hohe Verfügbarkeit auch den Neustart von VMs auf Hosts automatisieren, die bekanntermaßen in einem guten Zustand sind, ohne manuellen Eingriff. Diese VMs können für den Neustart in Gruppen geplant werden, damit die Dienste gestartet werden können. Damit können Infrastruktur-VMs vor ihren abhängigen VMs gestartet werden (z. B. ein DHCP-Server vor dem abhängigen SQL-Server).

Warnungen:

Nutzen Sie hohe Verfügbarkeit zusammen mit Multipathed Storage und Bonded Networking. Konfigurieren Sie Multipathed Storage und Bonded Networking, bevor Sie versuchen, Hochverfügbarkeit einzurichten. Kunden, die keinen Multipathed Storage und Bonded Networking einrichten, können unerwartetes Host-Neustartverhalten (Self Fencing) sehen, wenn eine Infrastrukturinstabilität vorliegt.

Alle Grafiklösungen (nVidia vGPU, Intel GVT-D, Intel GVT-G, AMD MxGPU und vGPU-Pass-Through) können in einer Umgebung verwendet werden, die hohe Verfügbarkeit nutzt. VMs, die diese Grafiklösungen verwenden, können jedoch nicht mit hoher Verfügbarkeit geschützt werden. Diese VMs können nach bestem Aufwand neu gestartet werden, während Hosts mit den entsprechenden kostenlosen Ressourcen vorhanden sind.

Überbegehen

Ein Pool wird übermäßig festgeschrieben, wenn die derzeit ausgeführten VMs nach einer benutzerdefinierten Anzahl von Hostfehlern an anderer Stelle neu gestartet werden können.

Überfestschreiben kann auftreten, wenn im Pool nicht genügend freier Speicher vorhanden ist, um diese VMs nach einem Fehler auszuführen. Es gibt jedoch auch subtilere Änderungen, die Hochverfügbarkeitsgarantien untragbar machen können: Änderungen an Virtual Block Devices (VBDs) und Netzwerken können beeinflussen, welche VMs auf welchen Hosts neu gestartet werden können. HASH (0x2c1a078) kann nicht alle potenziellen Aktionen überprüfen und feststellen, ob sie Verstöße gegen hohe Verfügbarkeitsanforderungen verursachen. Eine asynchrone Benachrichtigung wird jedoch gesendet, wenn die hohe Verfügbarkeit nicht nachhaltig wird.

HASH (0x2c1a078) verwaltet dynamisch einen Failoverplan , der beschreibt, was zu tun ist, wenn eine Gruppe von Hosts in einem Pool zu einem bestimmten Zeitpunkt fehlschlägt. Ein wichtiges Konzept, das zu verstehen ist, sind die Hostfehler, um Wert zu tolerieren , die als Teil der Hochverfügbarkeitskonfiguration definiert wird. Der Wert der zu tolerierenden Hostfehler bestimmt die Anzahl der Fehler, die ohne Dienstverlust zulässig sind. Betrachten Sie beispielsweise einen Ressourcenpool, der aus 64 Hosts besteht und die tolerierten Fehler auf 3 festgelegt ist. In diesem Fall berechnet der Pool einen Failoverplan, mit dem drei Hosts fehlschlagen und die VMs auf anderen Hosts neu starten können. Wenn ein Plan nicht gefunden werden kann, wird der Pool als übermäßig festgeschrieben. Der Plan wird basierend auf VM-Lebenszyklusvorgängen und -verlagerung dynamisch neu berechnet. Wenn Änderungen, z. B. die Hinzufügung neuer VMs zum Pool, dazu führen, dass Ihr Pool übermäßig festgeschrieben wird, werden Warnungen gesendet (entweder über HASH (0x2e6c8e8) oder per E-Mail).

Warnung zu Überverpflichtung

Wenn Versuche, eine VM zu starten oder fortzusetzen, dazu führen, dass der Pool übermäßig festgeschrieben wird, wird eine Warnmeldung angezeigt. Diese Warnung wird in HASH (0x2e6c8e8) angezeigt und ist auch als Nachrichteninstanz über die Management-API verfügbar. Wenn Sie eine E-Mail-Adresse konfiguriert haben, kann auch eine Nachricht an die E-Mail-Adresse gesendet werden. Sie können den Vorgang dann abbrechen oder trotzdem fortfahren. Fortfahren bewirkt, dass der Pool übermäßig festgeschrieben wird. Die Menge des Arbeitsspeichers, der von VMs mit unterschiedlichen Prioritäten verwendet wird, wird auf Pool- und Hostebene angezeigt.

Host-Fechten

Manchmal kann ein Server aufgrund des Verlustes der Netzwerkverbindung oder wenn ein Problem mit dem Steuerstapel auftritt, fehlschlagen. In solchen Fällen stellt sich der HASH-Server (0x2e68218) fest, um sicherzustellen, dass die VMs nicht gleichzeitig auf zwei Servern ausgeführt werden. Wenn eine Fencing-Aktion ausgeführt wird, wird der Server sofort und abrupt neu gestartet, wodurch alle auf ihm ausgeführten VMs gestoppt werden. Die anderen Server erkennen, dass die VMs nicht mehr ausgeführt werden und die VMs entsprechend den ihnen zugewiesenen Neustartprioritäten neu gestartet werden. Der eingezäunte Server tritt in eine Neustartsequenz ein, und wenn er neu gestartet wurde, versucht er erneut, dem Ressourcenpool beizutreten.

Hinweis:

Hosts in geclusterten Pools können sich auch selbst festlegen, wenn sie nicht mit mehr als der Hälfte der anderen Hosts im Ressourcenpool kommunizieren können. Weitere Informationen finden Sie unter Clustered Pools.

Konfigurationsanforderungen

Um die Hochverfügbarkeitsfunktion zu nutzen, benötigen Sie:

  • HASH-Pool (0x2e68218) (diese Funktion bietet hohe Verfügbarkeit auf Serverebene innerhalb eines einzelnen Ressourcenpools).

    Hinweis:

    Es wird empfohlen, Hochverfügbarkeit nur in Pools zu aktivieren, die mindestens drei HASH-Server (0x2e68218) enthalten. Weitere Informationen finden Sie unter CTX129721 - Hochverfügbarkeitsverhalten, wenn der Heartbeat in einem Pool verloren geht.

  • Gemeinsamer Speicher, einschließlich mindestens einer iSCSI-, NFS- oder Fibre Channel-LUN mit einer Größe von 356 MB oder mehr — der Heartbeat SR. Der Hochverfügbarkeitsmechanismus erstellt zwei Volumes auf der Heartbeat-SR:

    4 MB Heartbeat-Volume: Wird für Herzschlag verwendet.

    256 MB Metadaten-Volume: Speichern Sie Pool-Master-Metadaten, die verwendet werden sollen, wenn ein Master-Failover vorliegt.

    Hinweise:

    • Für maximale Zuverlässigkeit empfehlen wir Ihnen, ein dediziertes NFS- oder iSCSI-Speicher-Repository als Hochverfügbarkeits-Heartbeat-Festplatte zu verwenden. Verwenden Sie dieses Speicher-Repository nicht für andere Zwecke.
    • Wenn es sich bei Ihrem Pool um einen Cluster-Pool handelt, muss Ihr Heartbeat SR eine GFS2 SR sein.
    • Speicher, der mit SMB oder iSCSI verbunden ist, wenn er mit CHAP authentifiziert wird, kann nicht als Heartbeat-SR verwendet werden.
    • Wenn Sie eine NetApp oder EqualLogic SR verwenden, stellen Sie manuell eine NFS- oder iSCSI-LUN für das Array zur Verwendung als Heartbeat-SR bereit.
  • Statische IP-Adressen für alle Hosts.

    Achtung:

    Wenn sich die IP-Adresse eines Servers ändert, während die hohe Verfügbarkeit aktiviert ist, geht die hohe Verfügbarkeit davon aus, dass das Netzwerk des Hosts fehlgeschlagen ist. Die Änderung der IP-Adresse kann den Host umgrenzen und in einem nicht startbaren Zustand belassen. Um diese Situation zu beheben, deaktivieren Sie die hohe Verfügbarkeit mit demhost-emergency-ha-disable Befehl, setzen Sie den Poolmaster mit zurückpool-emergency-reset-master , und aktivieren Sie dann die hohe Verfügbarkeit erneut.

  • Für maximale Zuverlässigkeit empfehlen wir Ihnen, eine dedizierte gebundene Schnittstelle als Hochverfügbarkeitsverwaltungsnetzwerk zu verwenden.

Damit eine VM durch hohe Verfügbarkeit geschützt werden kann, muss sie agil sein. Es bedeutet die VM:

  • Die virtuellen Laufwerke müssen auf freigegebenem Speicher vorhanden sein. Sie können jede Art von gemeinsam genutztem Speicher verwenden. iSCSI, NFS oder Fibre-Channel-LUN ist nur für den Speicher-Heartbeat erforderlich und kann für die Speicherung virtueller Festplatten verwendet werden.

  • Kann Livemigration verwenden

  • Keine Verbindung zu einem lokalen DVD-Laufwerk konfiguriert

  • Hat seine virtuellen Netzwerkschnittstellen in poolweiten Netzwerken

Hinweis:

Wenn die hohe Verfügbarkeit aktiviert ist, empfehlen wir dringend, eine gebundene Management-Schnittstelle auf den Servern im Pool und Multipathed-Speicher für die Heartbeat-SR zu verwenden.

Wenn Sie VLANs und gebundene Schnittstellen über die CLI erstellen, sind sie möglicherweise nicht eingesteckt und aktiv, obwohl sie erstellt wurden. In diesem Fall scheint eine VM nicht agil zu sein und ist nicht durch hohe Verfügbarkeit geschützt. Mit dem CLI-pif-plug Befehl können Sie VLAN und Bond-PIFs aufrufen, damit die VM agil werden kann. Sie können auch genau bestimmen, warum eine VM nicht agil ist, indem Sie denxe diagnostic-vm-status CLI-Befehl verwenden. Mit diesem Befehl werden die Platzierungsbedingungen analysiert, und Sie können bei Bedarf Abhilfemaßnahmen ergreifen.

Konfigurationseinstellungen neu starten

Virtuelle Maschinen können durch hohe Verfügbarkeit als geschützt, bestmöglich oder ungeschützt angesehen werden. Der Wert vonha-restart-priority definiert, ob eine VM als geschützt, best-effort oder ungeschützt behandelt wird. Das Neustartverhalten für VMs in jeder dieser Kategorien ist unterschiedlich.

Geschützt

Hohe Verfügbarkeit garantiert einen Neustart einer geschützten VM, die offline geschaltet wird oder deren Host offline geht, sofern der Pool nicht zu viel festgeschrieben ist und die VM agil ist.

Wenn eine geschützte VM nicht neu gestartet werden kann, wenn ein Server ausfällt, versucht die hohe Verfügbarkeit, die VM zu starten, wenn zusätzliche Kapazität in einem Pool vorhanden ist. Versuche, die VM zu starten, wenn zusätzliche Kapazität vorhanden ist, könnten nun erfolgreich sein.

ha-restart-priority Wert:restart

Best-Aufwand

Wenn der Host einer VM mit bestem Aufwand offline geschaltet wird, versucht die hohe Verfügbarkeit, die bestmögliche VM auf einem anderen Host neu zu starten. Dieser Versuch wird erst ausgeführt, nachdem alle geschützten VMs erfolgreich neu gestartet wurden. Hohe Verfügbarkeit macht nur einen Versuch, eine bestmögliche VM neu zu starten. Wenn dieser Versuch fehlschlägt, unternimmt die hohe Verfügbarkeit keine weiteren Versuche, die VM neu zu starten.

ha-restart-priority Wert:best-effort

Ungeschützt

Wenn eine ungeschützte VM oder der Host, auf dem sie ausgeführt wird, gestoppt wird, versucht die hohe Verfügbarkeit nicht, die VM neu zu starten.

ha-restart-priority Wert: Wert ist eine leere Zeichenfolge

Hinweis:

Hochverfügbarkeit stoppt niemals oder migriert eine laufende VM auf freie Ressourcen, damit eine geschützte oder bestmögliche VM neu gestartet werden kann.

Wenn der Pool Serverausfälle aufweist und die Anzahl der tolerierbaren Fehler auf Null sinkt, wird der Neustart der geschützten VMs nicht garantiert. In solchen Fällen wird eine Systemwarnung generiert. Wenn ein anderer Fehler auftritt, verhalten sich alle VMs, für die eine Neustartpriorität festgelegt wurde, entsprechend dem Best-Effort-Verhalten.

Bestellung starten

Die Startreihenfolge ist die Reihenfolge, in der HASH (0x2c1a078) hohe Verfügbarkeit versucht, geschützte VMs neu zu starten, wenn ein Fehler auftritt. Die Werte derorder Eigenschaft für die einzelnen geschützten VMs bestimmen die Startreihenfolge.

Dieorder Eigenschaft einer VM wird von hoher Verfügbarkeit und auch von anderen Funktionen verwendet, die VMs starten und herunterfahren. Für jede VM kann dieorder Eigenschaft festgelegt werden, nicht nur die VMs, die für hohe Verfügbarkeit als geschützt gekennzeichnet sind. Bei hoher Verfügbarkeit wird dieorder Eigenschaft jedoch nur für geschützte VMs verwendet.

Der Wert derorder Eigenschaft ist eine ganze Zahl. Der Standardwert ist 0, was die höchste Priorität hat. Geschützte VMs mit demorder Wert 0 werden zunächst durch hohe Verfügbarkeit neu gestartet. Je höher der Wert derorder Eigenschaft ist, desto später wird die VM neu gestartet.

Sie können den Wert derorder Eigenschaft einer VM mithilfe der Befehlszeilenschnittstelle festlegen:

xe vm-param-set uuid=VM_UUID order=int

Oder legen Sie in HASH (0x2e6c8e8) im Bedienfeld Startoptionen für eine VM Startreihenfolge auf den erforderlichen Wert fest.

Hochverfügbarkeit für Ihren HASH (0x2e68218) Pool aktivieren

Sie können die hohe Verfügbarkeit in einem Pool aktivieren, indem Sie entweder HASH (0x2e6c8e8) oder die Befehlszeilenschnittstelle verwenden. In beiden Fällen geben Sie einen Satz von Prioritäten an, die bestimmen, welche VMs die höchste Neustartpriorität erhalten, wenn ein Pool übermäßig festgeschrieben wird.

Warnungen:

  • Wenn Sie die hohe Verfügbarkeit aktivieren, können einige Vorgänge deaktiviert werden, die den Plan zum Neustart von VMs beeinträchtigen, z. B. das Entfernen eines Servers aus einem Pool. Sie können die hohe Verfügbarkeit vorübergehend deaktivieren, um solche Vorgänge auszuführen, oder auch VMs, die durch hohe Verfügbarkeit geschützt sind, ungeschützt machen.

  • Wenn die hohe Verfügbarkeit aktiviert ist, können Sie das Clustering in Ihrem Pool nicht aktivieren. Hochverfügbarkeit vorübergehend deaktivieren, um Clustering zu aktivieren. Sie können Hochverfügbarkeit für Ihren Cluster-Pool aktivieren. Einige Hochverfügbarkeitsverhalten, z. B. Selbst-Fencing, unterscheiden sich bei Clusterpools. Weitere Informationen finden Sie unter Clustered Pools

Hochverfügbarkeit mithilfe der Befehlszeilenschnittstelle aktivieren

  1. Stellen Sie sicher, dass ein kompatibles Storage Repository (SR) an Ihren Pool angeschlossen ist. iSCSI, NFS oder Fibre Channel-SRs sind kompatibel. Hinweise zur Konfiguration eines solchen Speicher-Repository mithilfe der CLI finden Sie unterVerwalten von Speicher-Repositories.

  2. Legen Sie für jede VM, die Sie schützen möchten, eine Neustartpriorität und die Startreihenfolge fest. Sie können die Neustartpriorität wie folgt festlegen:

    xe vm-param-set uuid=vm_uuid ha-restart-priority=restart order=1
    
  3. Aktivieren Sie die hohe Verfügbarkeit für den Pool, und geben Sie optional ein Timeout an:

    xe pool-ha-enable heartbeat-sr-uuids=sr_uuid ha-config:timeout=timeout in seconds
    

    Timeout ist der Zeitraum, in dem die Hosts in Ihrem Pool nicht auf Netzwerke oder Speicher zugreifen können. Wenn Sie beim Aktivieren der Hochverfügbarkeit kein Timeout angeben, verwendet HASH (0x2e68218) das Standard-Timeout für 30 Sekunden. Wenn ein HASH (0x2e68218) Server innerhalb der Zeitüberschreitung nicht auf Netzwerk oder Speicher zugreifen kann, kann er sich selbst Fencing und neu starten.

  4. Führen Sie den Befehl auspool-ha-compute-max-host-failures-to-tolerate. Dieser Befehl gibt die maximale Anzahl von Hosts zurück, die fehlschlagen können, bevor nicht genügend Ressourcen vorhanden sind, um alle geschützten VMs im Pool auszuführen.

    xe pool-ha-compute-max-host-failures-to-tolerate
    

    Die Anzahl der zu tolerierenden Fehler bestimmt, wann eine Warnung gesendet wird. Das System berechnet einen Failoverplan neu, wenn sich der Status des Pools ändert. Es verwendet diese Berechnung, um die Poolkapazität zu ermitteln und wie viele weitere Ausfälle ohne Verlust der Betriebslebensgarantie für geschützte VMs möglich sind. Eine Systemwarnung wird generiert, wenn dieser berechnete Wert unter den angegebenen Wert für fälltha-host-failures-to-tolerate.

  5. Geben Sie die Anzahl der Fehler an, die Parameter toleriert werden sollen. Der Wert muss kleiner oder gleich dem berechneten Wert sein:

    xe pool-param-set ha-host-failures-to-tolerate=2 uuid=pool-uuid
    

Entfernen des Hochverfügbarkeitsschutzes von einer VM mithilfe der CLI

Verwenden Sie denxe vm-param-set Befehl, um Hochverfügbarkeitsfunktionen für eine VM zu deaktivieren, um denha-restart-priority Parameter als leere Zeichenfolge festzulegen. Durch das Setzen desha-restart-priority Parameters werden die Startreiheneinstellungen nicht gelöscht. Sie können die hohe Verfügbarkeit für eine VM erneut aktivieren, indem Sie denha-restart-priority Parameter aufrestart oder nachbest-effort Bedarf einstellen.

Wiederherstellen eines nicht erreichbaren Hosts

Wenn ein Host aus irgendeinem Grund nicht auf die Hochverfügbarkeitsstatusdatei zugreifen kann, ist es möglich, dass ein Host nicht erreichbar ist. Um Ihre HASH (0x2c1a078) -Installation wiederherzustellen, müssen Sie möglicherweise die hohe Verfügbarkeit mit demhost-emergency-ha-disable Befehl deaktivieren:

xe host-emergency-ha-disable --force

Wenn der Host der Pool-Master war, startet er wie gewohnt mit deaktivierter Hochverfügbarkeit. Pool-Mitglieder verbinden sich wieder und deaktivieren automatisch Hochverfügbarkeit. Wenn der Host ein Poolmitglied war und sich nicht an den Master wenden kann, müssen Sie möglicherweise eine der folgenden Aktionen ausführen:

  • Erzwingen eines Neustarts des Hosts als Poolmaster (xe pool-emergency-transition-to-master)

     xe pool-emergency-transition-to-master uuid=host_uuid
    
  • Sagen Sie dem Host, wo sich der neue Master befindet (xe pool-emergency-reset-master):

     xe pool-emergency-reset-master master-address=new_master_hostname
    

Wenn alle Hosts erfolgreich neu gestartet wurden, aktivieren Sie die hohe Verfügbarkeit erneut:

xe pool-ha-enable heartbeat-sr-uuid=sr_uuid

Herunterfahren eines Hosts bei aktivierter Hochverfügbarkeit

Achten Sie beim Herunterfahren oder Neustarten eines Hosts besonders darauf, um zu verhindern, dass der Hochverfügbarkeitsmechanismus davon ausgeht, dass der Host ausgefallen ist. Um einen Host sauber herunterzufahren, wenndisable die hohe Verfügbarkeit aktiviert ist,evacuate verwenden Sie entweder HASH (0x2e6c8e8) oder die CLI.shutdown Führen Sie die folgenden Befehle aus, um einen Host in einer Umgebung mit aktivierter Hochverfügbarkeit herunterzufahren:

    xe host-disable host=host_name
    xe host-evacuate uuid=host_uuid
    xe host-shutdown host=host_name

Herunterfahren einer VM, die durch hohe Verfügbarkeit geschützt ist

Wenn eine VM unter einem Hochverfügbarkeitsplan geschützt ist und auf einen automatischen Neustart festgelegt ist, kann sie nicht heruntergefahren werden, solange dieser Schutz aktiv ist. Um eine VM herunterzufahren, deaktivieren Sie zunächst den Hochverfügbarkeitsschutz und führen Sie dann den CLI-Befehl aus. HASH (0x2e6c8e8) bietet Ihnen ein Dialogfeld zum automatischen Deaktivieren des Schutzes, wenn Sie die Schaltfläche Herunterfahren einer geschützten VM auswählen.

Hinweis:

Wenn Sie eine VM innerhalb des Gastes herunterfahren und die VM geschützt ist, wird sie unter den Hochverfügbarkeitsfehlerbedingungen automatisch neu gestartet. Durch den automatischen Neustart wird sichergestellt, dass der Bedienerfehler nicht dazu führt, dass eine geschützte VM versehentlich heruntergefahren wird. Wenn Sie diese VM herunterfahren möchten, deaktivieren Sie zuerst den Hochverfügbarkeitsschutz.