layout: doc description: Configure high availability in your XenServer pool to ensure that VMs continue to run in the case of disrupted networking or host hardware failures.—
Bei Hochverfügbarkeit handelt es sich um eine Reihe automatischer Funktionen, mit denen Probleme, die XenServer-Hosts ausfallen oder nicht erreichbar sind, geplant und sicher behoben werden können. Zum Beispiel bei physisch gestörten Netzwerk- oder Host-Hardwareausfällen.
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 Poolkoordinator nicht mehr erreichbar oder instabil wird, kann 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, Intel GVT-D, Intel GVT-G und vGPU Passthrough) können in einer Umgebung mit hoher Verfügbarkeit verwendet werden. 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.
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. XenServer kann nicht alle potenziellen Aktionen überprüfen und feststellen, ob sie zu einer Verletzung der Hochverfügbarkeitsanforderungen führen. Es wird jedoch eine asynchrone Benachrichtigung gesendet, wenn die Hochverfügbarkeit nicht mehr nachhaltig wird.
XenServer verwaltet dynamisch einen Failover-Plan, der detailliert beschreibt, was zu tun ist, wenn eine Gruppe 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.
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.
Manchmal kann ein Host aufgrund eines Verlusts der Netzwerkkonnektivität ausfallen oder wenn ein Problem mit dem Control Stack auftritt. In solchen Fällen grenzt sich der XenServer-Host selbst ab, um sicherzustellen, dass die VMs nicht auf zwei Hosts gleichzeitig ausgeführt werden. Wenn eine Fence-Aktion ausgeführt wird, wird der Host sofort und abrupt neu gestartet, wodurch alle darauf laufenden VMs gestoppt werden. Die anderen Hosts erkennen, dass die VMs nicht mehr laufen, und dann werden die VMs gemäß den ihnen zugewiesenen Neustartprioritäten neu gestartet. Der eingezäunte Host geht in eine Neustartsequenz über und versucht nach dem Neustart, wieder dem Ressourcenpool 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.
Um die Hochverfügbarkeitsfunktion nutzen zu können, benötigen Sie:
XenServer-Pool (diese Funktion bietet Hochverfügbarkeit auf Hostebene innerhalb eines einzelnen Ressourcenpools).
Hinweis:
Wir empfehlen, Hochverfügbarkeit nur in Pools zu aktivieren, die mindestens 3 XenServer-Hosts 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:
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 Hosts ä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 Poolkoordinator mitpool-emergency-reset-masterzurück und aktivieren Sie dann wieder die Hochverfügbarkeit.
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.
Darüber hinaus können VMs mit angehängtem vTPM nicht durch Hochverfügbarkeit geschützt werden.
Hinweis:
Wenn Hochverfügbarkeit aktiviert ist, empfehlen wir dringend, eine gebündelte Verwaltungsschnittstelle auf den Hosts im Pool und Multipath-Speicher für den 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.
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.
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 Host ausfällt, versucht High Availability, die VM zu starten, wenn in einem Pool zusätzliche Kapazität vorhanden ist. Versuche, die VM zu starten, wenn zusätzliche Kapazität vorhanden ist, sind jetzt möglicherweise erfolgreich.
ha-restart-priority Wert: restart
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
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 Hostausfä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.
Die Startreihenfolge ist die Reihenfolge, in der XenServer 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.
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 einige Vorgänge, die den Plan für den Neustart von VMs gefährden (z. B. das Entfernen eines Hosts aus einem Pool), möglicherweise deaktiviert. 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. Anschließend können Sie die 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.
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.
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-->
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-->
Das Timeout ist der Zeitraum, in dem das Netzwerk oder der Speicher für die Hosts in Ihrem Pool nicht zugänglich ist. Wenn Sie bei der Aktivierung der Hochverfügbarkeit kein Timeout angeben, verwendet XenServer das Standardtimeout von 60 Sekunden. Wenn ein XenServer-Host innerhalb des Timeout-Zeitraums nicht auf Netzwerk oder Speicher zugreifen kann, kann er sich selbst abgrenzen und neu starten.
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.
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-->
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.
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 XenServer-Installation wiederherzustellen, müssen Sie möglicherweise die Hochverfügbarkeit mit dem host-emergency-ha-disable folgenden Befehl deaktivieren:
xe host-emergency-ha-disable --force
<!--NeedCopy-->
Wenn der Host der Poolkoordinator 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 Poolkoordinator nicht kontaktieren kann, müssen Sie möglicherweise eine der folgenden Aktionen ausführen:
Erzwingen des Hostneustarts als Poolkoordinator (xe pool-emergency-transition-to-master)
xe pool-emergency-transition-to-master uuid=host_uuid
<!--NeedCopy-->
Teilen Sie dem Host mit, wo sich der neue Poolkoordinator befindet (xe pool-emergency-reset-master):
xe pool-emergency-reset-master master-address=new_pool_coordinator_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-->
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-->
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.