Hohe Verfügbarkeit

Hochverfügbarkeit ist eine Reihe automatischer Funktionen, mit denen Probleme geplant und sicher behoben werden können, die Citrix Hypervisor-Server zum Erliegen bringen oder sie unerreichbar machen. Zum Beispiel bei physisch gestörten Netzwerk- oder Host-Hardwareausfällen.

Übersicht

Hohe Verfügbarkeit stellt sicher, dass, wenn ein Host unerreichbar oder instabil wird, die auf diesem Host laufenden VMs automatisch sicher auf einem anderen Host neu gestartet werden. Dadurch müssen die virtuellen Maschinen nicht mehr manuell neu gestartet werden, was zu minimalen Ausfallzeiten der virtuellen Maschinen führt.

Wenn der Poolmaster nicht mehr erreichbar oder instabil wird, kann die Hochverfügbarkeit auch die administrative Kontrolle über einen Pool wiederherstellen. Hochverfügbarkeit stellt sicher, dass die administrative Kontrolle ohne manuellen Eingriff automatisch wiederhergestellt wird.

Optional kann Hochverfügbarkeit auch den Neustart von VMs auf Hosts automatisieren, die sich ohne manuellen Eingriff in einem guten Zustand befinden. 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 seinem abhängigen SQL-Server).

Warnungen:

Verwenden Sie Hochverfügbarkeit zusammen mit Multipath-Speicher und gebundenem Netzwerk. Konfigurieren Sie Multipathed Storage und Bonded Networking, bevor Sie versuchen, Hochverfügbarkeit einzurichten. Kunden, die keinen Multipath-Speicher und kein Bonded Networking einrichten, können bei einer Instabilität der Infrastruktur ein unerwartetes Verhalten beim Neustart des Hosts (Self-Fencing) feststellen.

Alle Grafiklösungen (NVIDIA vGPU, AMD MxGPU (veraltet) und vGPU-Passthrough) können in einer Umgebung verwendet werden, die Hochverfügbarkeit verwendet. VMs, die diese Grafiklösungen verwenden, können jedoch nicht mit hoher Verfügbarkeit geschützt werden. Diese VMs können nach bestem Ermessen neu gestartet werden, während es Hosts mit den entsprechenden freien Ressourcen gibt.

Übermäßiges Engagement

Ein Pool ist überbelegt, wenn die derzeit laufenden VMs nach einer benutzerdefinierten Anzahl von Hostausfällen nicht an anderer Stelle neu gestartet werden können. Eine Überbelegung kann auftreten, wenn im Pool nicht genügend freier Speicher vorhanden ist, um diese VMs nach einem Ausfall auszuführen. Es gibt jedoch auch subtilere Änderungen, die eine hohe Verfügbarkeit unhaltbar machen können: Änderungen an Virtual Block Devices (VBDs) und Netzwerken können sich darauf auswirken, welche VMs auf welchen Hosts neu gestartet werden können. Citrix Hypervisor kann nicht alle potenziellen Aktionen überprüfen und feststellen, ob sie eine Verletzung der Hochverfügbarkeitsanforderungen verursachen. Es wird jedoch eine asynchrone Benachrichtigung gesendet, wenn die Hochverfügbarkeit nicht mehr nachhaltig wird.

Citrix Hypervisor verwaltet dynamisch einen Failoverplan, in dem detailliert beschrieben wird, was zu tun ist, wenn eine Reihe von Hosts in einem Pool zu einem bestimmten Zeitpunkt ausfällt. Ein wichtiges Konzept, das es zu verstehen gilt, ist der Wert host failures to tolerate, der als Teil der Hochverfügbarkeitskonfiguration definiert wird. Der Wert von host failures to tolerate bestimmt die Anzahl der Hostausfälle, die zulässig sind, ohne dass alle geschützten virtuellen Maschinen neu gestartet werden können. Stellen Sie sich beispielsweise einen Ressourcenpool vor, der aus 64 Hosts host failures to tolerate besteht und auf 3 festgelegt ist. In diesem Fall berechnet der Pool einen Failoverplan, der den Ausfall von drei beliebigen Hosts ermöglicht, und startet dann die VMs auf anderen Hosts neu. Wenn kein Plan gefunden werden kann, gilt der Pool als überbeansprucht. Der Plan wird basierend auf VM-Lebenszyklusvorgängen und -verlagerung dynamisch neu berechnet. Wenn Änderungen (z. B. das Hinzufügen neuer VMs zum Pool) dazu führen, dass der Pool überlastet wird, werden Warnungen entweder über XenCenter oder per E-Mail gesendet.

Warnung vor Überbelegung

Wenn Versuche, eine VM zu starten oder fortzusetzen, dazu führen würden, dass der Pool überbeansprucht wird, wird in XenCenter eine Warnmeldung angezeigt. Sie können dann wählen, ob Sie den Vorgang abbrechen oder trotzdem fortfahren möchten. Wenn Sie fortfahren, wird der Pool überlastet und eine Nachricht wird an alle konfigurierten E-Mail-Adressen gesendet. Dies ist auch als Nachrichteninstanz über die Management-API verfügbar. Die Menge an Arbeitsspeicher, die von VMs mit unterschiedlichen Prioritäten belegt wird, wird auf Pool- und Host-Ebene angezeigt.

Host-Fencing

Manchmal kann ein Server ausfallen, weil die Netzwerkkonnektivität verloren geht oder wenn ein Problem mit dem Control Stack auftritt. In solchen Fällen schützt sich der Citrix Hypervisor-Server selbst, um sicherzustellen, dass die VMs nicht gleichzeitig auf zwei Servern ausgeführt werden. Wenn eine Fence-Aktion ausgeführt wird, wird der Server sofort und abrupt neu gestartet, wodurch alle darauf laufenden VMs gestoppt werden. Die anderen Server stellen fest, dass die VMs nicht mehr laufen, und dann werden die VMs gemäß den ihnen zugewiesenen Neustartprioritäten neu gestartet. Der eingezäunte Server tritt in eine Neustartsequenz ein, und wenn er neu gestartet wurde, versucht er, dem Ressourcenpool wieder beizutreten.

Hinweis:

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

Anforderungen an die Konfiguration

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

• Citrix Hypervisor Pool (diese Funktion bietet Hochverfügbarkeit auf Serverebene innerhalb eines einzigen Ressourcenpools).

  Hinweis:

  Wir empfehlen, die Hochverfügbarkeit nur in Pools zu aktivieren, die mindestens 3 Citrix Hypervisor-Server enthalten. Weitere Informationen finden Sie unter CTX129721 — Hochverfügbarkeitsverhalten, wenn der Heartbeat in einem Pool verloren geht.

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

  • 4 MB Heartbeat-Volume: Wird verwendet, um einen Heartbeat bereitzustellen.
  • 256 MB Metadaten-Volume: Zum Speichern von Poolmaster-Metadaten, die bei einem Master-Failover verwendet werden.

  Hinweis:

  Bisher haben wir empfohlen, ein dediziertes NFS- oder iSCSI-Speicher-Repository als Heartbeat-Disk mit hoher Verfügbarkeit zu verwenden. Dies ist jedoch nur von Vorteil, wenn das Speicher-Repository keine Ressourcen auf der zugrunde liegenden Speicher-Appliance teilt, andernfalls erhöht es lediglich die Komplexität und den Ressourcenverbrauch in der Steuerdomäne (dom0) des Hosts.

  Wenn Ihr Pool ein Clusterpool ist, muss Ihr Heartbeat-SR ein GFS2-SR sein.

  Mit SMB oder iSCSI verbundener Speicher bei der Authentifizierung mit CHAP kann nicht als Heartbeat-SR verwendet werden.

• Statische IP-Adressen für alle Hosts.

  Warnung:

  Wenn sich die IP-Adresse eines Servers ändert, während Hochverfügbarkeit aktiviert ist, geht die Hochverfügbarkeit davon aus, dass das Netzwerk des Hosts ausgefallen ist. Die Änderung der IP-Adresse kann den Host umzäunen und ihn in einem nicht bootfähigen Zustand belassen. Um dieses Problem zu beheben, deaktivieren Sie die Hochverfügbarkeit mit dem Befehl host-emergency-ha-disable, setzen Sie den Poolmaster mit pool-emergency-reset-master zurück und aktivieren Sie dann die Hochverfügbarkeit erneut.

• Für maximale Zuverlässigkeit empfehlen wir die Verwendung einer dedizierten gebundenen Schnittstelle als Hochverfügbarkeitsverwaltungsnetzwerk.

Damit eine VM durch Hochverfügbarkeit geschützt werden kann, muss sie agil sein. Das bedeutet die VM:

• Muss seine virtuellen Datenträger auf freigegebenem Speicher haben. 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 virtuellen Datenträgerspeicher verwendet werden.

• Kann Live-Migration verwenden.

• Es ist keine Verbindung zu einem lokalen DVD-Laufwerk konfiguriert.

• Hat seine virtuellen Netzwerkschnittstellen in poolweiten Netzwerken.

Hinweis:

Wenn Hochverfügbarkeit aktiviert ist, empfehlen wir dringend, eine gebundene Verwaltungsschnittstelle auf den Servern im Pool und Multipath-Speicher für das Heartbeat-SR zu verwenden.

Wenn Sie VLANs und gebundene Schnittstellen über die CLI erstellen, sind sie möglicherweise nicht angeschlossen und aktiv, obwohl sie erstellt wurden. In dieser Situation kann eine VM nicht agil erscheinen und ist nicht durch Hochverfügbarkeit geschützt. Sie können den CLI-Befehl pif-plug verwenden, um das VLAN aufzurufen und PIFs zu binden, damit die VM agil werden kann. Sie können auch genau bestimmen, warum eine VM nicht agil ist, indem Sie den CLI-Befehl xe diagnostic-vm-status verwenden. Dieser Befehl analysiert die Platzierungsbeschränkungen, und Sie können bei Bedarf Abhilfemaßnahmen ergreifen.

Konfigurationseinstellungen neu starten

Virtuelle Maschinen können als geschützt, nach bestem Ermessen oder durch Hochverfügbarkeit ungeschützt betrachtet werden. Der Wert von ha-restart-priority definiert, ob eine VM als geschützt, nach bestem Aufwand oder ungeschützt behandelt wird. Das Neustartverhalten von virtuellen Rechnern in jeder dieser Kategorien ist unterschiedlich.

Geschützt

Hochverfügbarkeit garantiert den Neustart einer geschützten VM, die offline geht oder deren Host offline geht, vorausgesetzt, der Pool ist nicht überlastet und die VM agil ist.

Wenn eine geschützte VM nicht neu gestartet werden kann, wenn ein Server ausfällt, versucht Hochverfü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, sind jetzt möglicherweise erfolgreich.

ha-restart-priority Wert: restart

Beste Bemühung

Wenn der Host einer VM mit bestem Aufwand offline geht, versucht Hochverfügbarkeit, die VM mit der besten Leistung auf einem anderen Host neu zu starten. Dieser Versuch wird erst unternommen, nachdem alle geschützten VMs erfolgreich neu gestartet wurden. Hochverfügbarkeit macht nur einen Versuch, eine VM mit bestem Aufwand neu zu starten. Schlägt dieser Versuch fehl, unternimmt Hochverfü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, angehalten wird, versucht High Availability nicht, die VM neu zu starten.

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

Hinweis:

Hochverfügbarkeit stoppt oder migriert niemals eine laufende VM, um Ressourcen für einen Neustart einer geschützten oder nach besten Kräften verfügbaren VM freizugeben.

Wenn im Pool Serverausfälle auftreten und die Anzahl der tolerierbaren Ausfälle auf Null sinkt, kann nicht garantiert werden, dass die geschützten VMs neu gestartet werden. In solchen Fällen wird eine Systemwarnung generiert. Tritt ein weiterer Fehler auf, verhalten sich alle VMs mit festgelegter Neustartpriorität entsprechend dem Bestleistungsverhalten.

Bestellung starten

Die Startreihenfolge ist die Reihenfolge, in der Citrix Hypervisor High Availability versucht, geschützte VMs neu zu starten, wenn ein Fehler auftritt. Die Werte der order-Eigenschaft für jede der geschützten VMs bestimmen die Startreihenfolge.

Die order-Eigenschaft einer VM wird von der Hochverfügbarkeit und auch von anderen Funktionen verwendet, die VMs starten und herunterfahren. Bei jeder VM kann die order-Eigenschaft festgelegt werden, nicht nur die VMs, die für Hochverfügbarkeit als geschützt gekennzeichnet sind. Bei hoher Verfügbarkeit wird die order-Eigenschaft jedoch nur für geschützte VMs verwendet.

Der Wert der order-Eigenschaft ist eine Ganzzahl. Der Standardwert ist 0, was die höchste Priorität ist. Geschützte virtuelle Maschinen mit einem order-Wert von 0 werden zuerst durch Hochverfügbarkeit neu gestartet. Je höher der Wert der order-Eigenschaft ist, desto später wird die VM in der Reihenfolge neu gestartet.

Sie können den Wert der Eigenschaft order einer VM über die Befehlszeilenschnittstelle festlegen:

xe vm-param-set uuid=<vm uuid> order=<int>
<!--NeedCopy-->

Oder setzen Sie in XenCenter im Bereich Startoptionen für eine VM die Startreihenfolge auf den erforderlichen Wert.

Ermöglichen Sie Hochverfügbarkeit in Ihrem Citrix Hypervisor-Pool

Sie können die Hochverfügbarkeit in einem Pool aktivieren, indem Sie entweder XenCenter oder die Befehlszeilenschnittstelle (CLI) verwenden. In beiden Fällen geben Sie eine Reihe von Prioritäten an, die festlegen, welche VMs die höchste Neustartpriorität erhalten, wenn ein Pool überlastet ist.

Warnungen:

• Wenn Sie Hochverfügbarkeit aktivieren, werden möglicherweise einige Vorgänge deaktiviert, die den Plan für den Neustart virtueller Maschinen beeinträchtigen (z. B. das Entfernen eines Servers aus einem Pool). Sie können die Hochverfügbarkeit vorübergehend deaktivieren, um solche Vorgänge durchzuführen, oder alternativ, VMs, die durch Hochverfügbarkeit geschützt sind, ungeschützt machen.

• Wenn Hochverfügbarkeit aktiviert ist, können Sie kein Clustering in Ihrem Pool aktivieren. Deaktivieren Sie vorübergehend Hochverfügbarkeit, um Clustering zu ermöglichen. Sie können Hochverfügbarkeit in Ihrem Clusterpool aktivieren. Ein gewisses Hochverfügbarkeitsverhalten, wie z. B. Self-Fencing, unterscheidet sich bei Clusterpools. Weitere Informationen finden Sie unter Clustered-Pools.

Ermöglichen Sie Hochverfügbarkeit über die CLI

1. Stellen Sie sicher, dass ein kompatibles Storage Repository (SR) an Ihren Pool angeschlossen ist. iSCSI-, NFS- oder Fibre-Channel-SRs sind kompatibel. Informationen zum Konfigurieren eines solchen Speicherrepositorys über die CLI finden Sie unter Verwalten von Speicherrepositories.

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

   xe vm-param-set uuid=<vm uuid> ha-restart-priority=restart order=1
   <!--NeedCopy-->
   

3. Aktivieren Sie Hochverfügbarkeit im Pool und geben Sie optional einen Timeout an:

   xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
   <!--NeedCopy-->
   

   Alternativ können Sie ein Standard-Timeout für Ihren Pool festlegen. Weitere Informationen zum Festlegen eines Timeouts finden Sie unter Timeout für hohe Verfügbarkeit.

4. Führen Sie den Befehl pool-ha-compute-max-host-failures-to-tolerate aus. Dieser Befehl gibt die maximale Anzahl von Hosts zurück, die ausfallen können, bevor nicht genügend Ressourcen zur Ausführung aller geschützten VMs im Pool vorhanden sind.

   xe pool-ha-compute-max-host-failures-to-tolerate
   <!--NeedCopy-->
   

   Die Anzahl der tolerierten Fehler bestimmt, wann eine Warnung gesendet wird. Das System berechnet einen Failoverplan neu, wenn sich der Status des Pools ändert. Mit dieser Berechnung wird die Poolkapazität ermittelt und wie viele weitere Ausfälle möglich sind, ohne dass die Nutzungsgarantie für geschützte VMs verloren geht. Eine Systemwarnung wird generiert, wenn dieser berechnete Wert unter den angegebenen Wert für fällt ha-host-failures-to-tolerate.

5. Geben Sie den Parameter ha-host-failures-to-tolerate an. Der Wert muss kleiner oder gleich dem berechneten Wert sein:

   xe pool-param-set ha-host-failures-to-tolerate=2 uuid=<pool uuid>
   <!--NeedCopy-->
   

Timeout für hohe Verfügbarkeit konfigurieren

Ein Timeout für hohe Verfügbarkeit ist der Zeitraum, in dem die Hosts in Ihrem Pool nicht auf Netzwerk oder Speicher zugreifen können. Wenn ein Citrix Hypervisor-Server innerhalb des Timeout-Zeitraums nicht auf das Netzwerk oder den Speicher zugreifen kann, kann er sich selbst abgrenzen und neu starten. Das Standard-Timeout ist 60 Sekunden. Sie können diesen Wert jedoch mit dem folgenden Befehl ändern.

Legen Sie ein Standard-Timeout für Hochverfügbarkeit für Ihren Pool fest:

xe pool-param-set uuid=<pool uuid> other-config:default_ha_timeout=<timeout in seconds>
<!--NeedCopy-->

Wenn Sie Hochverfügbarkeit mithilfe von XenCenter anstelle der XE-CLI aktivieren, gilt diese Standardeinstellung weiterhin.

Alternativ können Sie einen Timeout festlegen, wenn Sie die Hochverfügbarkeit aktivieren:

xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
<!--NeedCopy-->

Beachten Sie, dass, wenn Sie bei der Aktivierung der Hochverfügbarkeit ein Timeout festlegen, dies nur für diese spezielle Aktivierung gilt. Wenn Sie die Hochverfügbarkeit deaktivieren und später wieder aktivieren, verwendet die Hochverfügbarkeitsfunktion daher wieder das Standard-Timeout.

Entfernen des Hochverfügbarkeitsschutzes von einer VM über die CLI

Um Hochverfügbarkeitsfunktionen für eine VM zu deaktivieren, verwenden Sie den Befehl xe vm-param-set, um den Parameter ha-restart-priority auf eine leere Zeichenfolge festzulegen. Durch Festlegen des Parameters ha-restart-priority werden die Einstellungen für die Startreihenfolge nicht gelöscht. Sie können die Hochverfügbarkeit für eine VM wieder aktivieren, indem Sie den Parameter ha-restart-priority nach Bedarf auf restart oder best-effort festlegen.

Stellen Sie einen nicht erreichbaren Host wieder her

Wenn ein Host aus irgendeinem Grund nicht auf die Hochverfügbarkeitsstatusdatei zugreifen kann, ist es möglich, dass ein Host nicht mehr erreichbar ist. Um Ihre Citrix Hypervisor-Installation wiederherzustellen, müssen Sie möglicherweise die Hochverfügbarkeit mit dem Befehl host-emergency-ha-disabledeaktivieren:

xe host-emergency-ha-disable --force
<!--NeedCopy-->

Wenn der Host der Poolmaster war, wird er wie gewohnt mit deaktivierter Hochverfügbarkeit gestartet. Poolmitglieder verbinden sich erneut und deaktivieren automatisch die Hochverfügbarkeit. Wenn der Host ein Poolmitglied war und den Master nicht kontaktieren kann, müssen Sie möglicherweise eine der folgenden Aktionen ausführen:

• Erzwinge den Neustart des Hosts als Poolmaster (xe pool-emergency-transition-to-master)

   xe pool-emergency-transition-to-master uuid=<host uuid>
   <!--NeedCopy-->
  

• Sagen Sie dem Host, wo der neue Master ist (xe pool-emergency-reset-master):

   xe pool-emergency-reset-master master-address=<new master hostname>
   <!--NeedCopy-->
  

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

xe pool-ha-enable heartbeat-sr-uuid=<sr uuid>
<!--NeedCopy-->

Herunterfahren eines Hosts bei aktivierter Hochverfügbarkeit

Achten Sie beim Herunterfahren oder Neustarten eines Hosts besonders darauf, dass der Hochverfügbarkeitsmechanismus davon ausgeht, dass der Host ausgefallen ist. Um einen Host sauber herunterzufahren, wenn Hochverfügbarkeit aktiviert ist, deaktivieren Sie den Host, evakuieren Sie den Host und fahren Sie den Host schließlich mit XenCenter oder der CLI herunter. Führen Sie die folgenden Befehle aus, um einen Host in einer Umgebung herunterzufahren, in der Hochverfügbarkeit aktiviert ist:

xe host-disable host=<host name>
xe host-evacuate uuid=<host uuid>
xe host-shutdown host=<host name>
<!--NeedCopy-->

Fahren Sie eine VM herunter, die durch hohe Verfügbarkeit geschützt ist

Wenn eine VM durch einen Hochverfügbarkeitsplan geschützt und für einen automatischen Neustart eingerichtet ist, kann sie nicht heruntergefahren werden, solange dieser Schutz aktiv ist. Um eine VM herunterzufahren, deaktivieren Sie zuerst ihren Hochverfügbarkeitsschutz und führen Sie dann den CLI-Befehl aus. XenCenter 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 Bedingungen des Hochverfügbarkeitsausfalls automatisch neu gestartet. Durch den automatischen Neustart wird sichergestellt, dass ein Bedienerfehler nicht dazu führt, dass eine geschützte VM versehentlich heruntergefahren wird. Wenn Sie diese VM herunterfahren möchten, deaktivieren Sie zuerst ihren Hochverfügbarkeitsschutz.