layout: doc—

Hohe Verfügbarkeit

Hinweis:

XenCenter yyyy.x.x wird noch nicht für die Verwendung mit Citrix Hypervisor 8.2 CU1 in Produktionsumgebungen unterstützt. Verwenden Sie XenCenter 8.2.7, um Ihre Citrix Hypervisor 8.2 CU1-Produktionsumgebung zu verwalten. Weitere Informationen finden Sie in der XenCenter 8.2.7-Dokumentation.

Sie können XenCenter 8.2.7 und XenCenter yyyy.x.x auf demselben System installieren. Die Installation von XenCenter yyyy.x.x überschreibt Ihre XenCenter 8.2.7-Installation nicht.

Dank der hohen Verfügbarkeit von XenServer können VMs bei einem zugrunde liegenden Hardwarefehler oder dem Verlust eines Servers automatisch neu gestartet werden. Bei hoher Verfügbarkeit geht es darum sicherzustellen, dass wichtige VMs immer in einem Ressourcenpool ausgeführt werden. Wenn die Hochverfügbarkeit aktiviert ist und einer Ihrer Server ausfällt, werden die VMs auf anderen Servern im selben Pool neu gestartet. Diese Funktion ermöglicht die Wiederherstellung wesentlicher Dienste mit minimaler Betriebsunterbrechung im Falle eines System- oder Komponentenausfalls.

Wenn der Poolkoordinator-Server ausfällt, wählt XenServer High Availability einen neuen Server aus, der die Position des Poolkoordinators übernimmt. Jeder Server in einem Pool kann ein Poolkoordinatorserver sein. XenServer repliziert die Pooldatenbank ständig auf allen Knoten. Außerdem wird für zusätzliche Sicherheit ein Backup der Datenbank auf dem freigegebener Speicher auf dem Heartbeat SR angelegt.

Die Hochverfügbarkeit von XenServer hat zwei Hauptaspekte:

Serverausfall zuverlässig erkennen
Erstellung eines Ausfallplans für eine schnelle Wiederherstellung

Herzschläge für Verfügbarkeit

Das zuverlässige Erkennen eines Serverausfalls ist schwierig, da Sie remote zwischen einem Server, der für eine Weile verschwindet, und einem katastrophalen Ausfall unterscheiden müssen. Wenn die Hochverfügbarkeit fälschlicherweise feststellt, dass ein Poolkoordinatorserver defekt ist, und einen neuen Poolkoordinator wählt, kann es zu unvorhersehbaren Ergebnissen kommen, wenn der ursprüngliche Server zurückkehrt. Wenn ein Netzwerkproblem dazu führt, dass der Pool in zwei gleiche Hälften aufgeteilt wird, müssen wir sicherstellen, dass nur die Hälfte auf den gemeinsam genutzten Speicher zugreift und nicht beide gleichzeitig. XenServer löst all diese Probleme mit zwei Mechanismen: einem Speicher-Heartbeat und einem Netzwerk-Heartbeat.

Wenn Sie Hochverfügbarkeit in einem Pool aktivieren, benennen Sie ein iSCSI-, Fibre Channel- oder NFS-Speicherrepository als Heartbeat-SR. XenServer erstellt automatisch ein paar kleine virtuelle Datenträger in dieser SR. Der erste Datenträger wird von jedem Server im Ressourcenpool als gemeinsam genutzter Quorumdatenträger verwendet. Jeder Server weist sich einen eindeutigen Block auf dem freigegebenen Datenträgers zu und schreibt regelmäßig in den Block, um anzuzeigen, dass er am Leben ist. Wenn die Hochverfügbarkeit gestartet wird, tauschen alle Server Daten sowohl über Netzwerk- als auch über Speicherkanäle aus. Diese Aktion zeigt an, welche Server sie über beide Kanäle sehen können, und zeigt, welche E/A-Pfade funktionieren und welche nicht. Diese Informationen werden ausgetauscht, bis ein Fixpunkt erreicht ist und sich alle Server im Pool einig sind, was sie sehen können. Wenn diese Vereinbarung zustande kommt, wird Hochverfügbarkeit aktiviert und der Pool ist geschützt. Dieser Hochverfügbarkeits-Aktivierungsprozess kann einige Minuten dauern, um sich mit größeren Pools zufrieden zu geben, ist jedoch nur erforderlich, wenn Sie die Hochverfügbarkeit zum ersten Mal aktivieren.

Nachdem die hohe Verfügbarkeit aktiv ist, schreibt jeder Server regelmäßig SpeicherUpdates auf das virtuelle Heartbeat-Laufwerk und Netzwerkpakete über die Verwaltungsschnittstelle. Stellen Sie sicher, dass Netzwerkadapter für Ausfallsicherheit gebunden sind und dass Speicherschnittstellen dynamisches Multipathing verwenden, wo es unterstützt wird. Diese Konfiguration stellt sicher, dass einzelne Adapter oder Verkabelungsfehler keine Verfügbarkeitsprobleme verursachen.

Weitere Informationen:

Server-Fencing

Das schlimmste Szenario für Hochverfügbarkeit ist ein Szenario, bei dem ein Server als offline angesehen wird, aber immer noch in den gemeinsam genutzten Speicher schreibt. Dieses Szenario kann zur Beschädigung persistenter Daten führen. XenServer verwendet Server-Fencing, um diese Situation zu verhindern. Der Server wird automatisch ausgeschaltet und vom Zugriff auf freigegebene Ressourcen im Pool isoliert. Das Fencing verhindert, dass der ausgefallene Server auf freigegebene Datenträger schreibt. Dieses Verhalten verhindert Schäden an den gespeicherten Daten während eines automatisierten Failovers, wenn geschützte virtuelle Maschinen auf andere Server im Pool verschoben werden.

Server selbst Fencing (d. h. Ausschalten und Neustart) im Falle eines Herzschlagfehlers, es sei denn, eine der folgenden Punkte gilt:

Der Speicher-Heartbeat ist für alle Server vorhanden, aber das Netzwerk wurde partitioniert (sodass es jetzt zwei Servergruppen gibt). In diesem Fall werden alle Server, die Mitglieder der größten Netzwerkpartition sind, weiter ausgeführt, und die Server in der kleineren Netzwerkpartition verfügen über einen Selbstzaun. Hier wird davon ausgegangen, dass der Netzwerkausfall die VMs isoliert hat und sie auf einem Server mit funktionierendem Netzwerk neu gestartet werden müssen. Wenn die Netzwerkpartitionen die gleiche Größe haben, wird nur eine von ihnen gemäß einer stabilen Auswahlfunktion selbst eingezäunt.
Wenn der Speicher-Taktschlag verschwindet, der Netzwerk-Taktschlag jedoch bestehen bleibt, überprüfen die Server, ob sie alle anderen Server im Netzwerk sehen können. Wenn diese Bedingung zutrifft, werden die Server weiterhin unter der Annahme ausgeführt, dass der Speicher-Taktserver nicht mehr verfügbar ist. Diese Aktion beeinträchtigt nicht die VM-Sicherheit, aber Netzwerkstörungen führen zu Fechten, da dies bedeuten würde, dass beide Heartbeats verschwunden sind.

Kapazitätsplanung bei Ausfall

Das Heartbeat-System gibt uns eine zuverlässige Benachrichtigung bei Serverausfällen, und so fahren wir mit dem zweiten Schritt der Hochverfügbarkeit fort: der Kapazitätsplanung für einen Ausfall.

Ein Ressourcenpool besteht aus mehreren Servern (z. B. 32), die jeweils mit potenziell unterschiedlichen Speichermengen und einer unterschiedlichen Anzahl ausgeführter VMs ausgestattet sind. Die hohe Verfügbarkeit von XenServer berechnet dynamisch einen Ausfallplan, der die Maßnahmen berechnet, die bei einem Serverausfall zu ergreifen sind. Dieser Ausfallplan stellt sicher, dass kein einzelner Serverausfall es unmöglich macht, seine VMs auf einem anderen Server neu zu starten (z. B. aufgrund unzureichenden Speichers auf anderen Servern). Die hohe Verfügbarkeit von XenServer kann nicht nur den Ausfall eines einzelnen Servers bewältigen, sondern auch den Verlust mehrerer Server in einem Pool bewältigen. Hochverfügbarkeit kann beispielsweise auftreten, wenn bei einem Ausfall einer Netzwerkpartition eine ganze Gruppe von Servern zerstört wird.

Zusätzlich zur Berechnung der ergriffenen Maßnahmen berücksichtigt der Ausfallplan die Anzahl der Serverausfälle, die im Pool toleriert werden können. Bei der Berechnung des Hochverfügbarkeitsplans für einen Pool sind zwei wichtige Überlegungen zu berücksichtigen:

Maximale Ausfallkapazität. Dieser Wert ist die maximale Anzahl von Servern, die ausfallen können, bevor nicht genügend Ressourcen vorhanden sind, um alle geschützten VMs im Pool auszuführen. Bei der Berechnung der maximalen Ausfallkapazität berücksichtigt XenServer:
- Die Neustartprioritäten der VMs im Pool
- Die Anzahl der Server im Pool
- Die Server-CPU und die Speicherkapazität
Serverausfallgrenze. Sie können diesen Wert als Teil der Hochverfügbarkeitskonfiguration definieren, die die Anzahl der im Pool zulässigen Serverausfälle innerhalb des Plans angibt. Wenn das Serverausfalllimit für einen Pool beispielsweise 3 beträgt, berechnet XenServer einen Failover-Plan, der den Ausfall von 3 beliebigen Servern ermöglicht und alle geschützten VMs weiterhin im Pool ausgeführt werden können. Sie können die Serverausfallgrenze auf einen Wert konfigurieren, der niedriger ist als die maximale Ausfallkapazität, wodurch es weniger wahrscheinlich ist, dass der Pool zu viel festgeschrieben wird. Diese Konfiguration kann in einer Umgebung mit aktiviertem RBAC nützlich sein. Mit dieser Einstellung können RBAC-Benutzer mit niedrigeren Berechtigungen als Pool-Operator beispielsweise mehr VMs online schalten, ohne den Hochverfügbarkeitsplan zu verletzen. Weitere Informationen finden Sie im Abschnitt Hochverfügbarkeit und rollenbasierte Zugriffssteuerung (RBAC) .

Eine Systemwarnung wird generiert, wenn der Wert für die maximale Ausfallkapazität unter den für die Serverausfallgrenze angegebenen Wert fällt.

Overcommit-Schutz

Wenn Hochverfügbarkeit zum ersten Mal in einem Pool aktiviert wird, wird ein Ausfallplan basierend auf den dann verfügbaren Ressourcen berechnet. Die hohe Verfügbarkeit von XenServer berechnet dynamisch einen neuen Ausfallplan als Reaktion auf Ereignisse, die sich auf den Pool auswirken würden, z. B. beim Starten einer neuen VM. Wenn ein neuer Plan aufgrund unzureichender Ressourcen im Pool nicht berechnet werden kann, wird der Pool überlastet. Beispiele für unzureichende Ressourcen sind möglicherweise nicht genügend freier Speicher oder Änderungen an virtuellen Datenträgern und Netzwerken, die sich darauf auswirken, welche VMs auf welchen Servern möglicherweise neu gestartet werden.

Hochverfügbarkeits-Neustartpriorität wird verwendet, um zu bestimmen, welche VMs gestartet werden sollen, wenn ein Pool überschrieben ist. Wenn Sie die Neustartpriorität für die zu schützenden VMs im Dialogfeld “ HA-Konfiguration “ oder im Assistenten zum Konfigurieren von HA konfigurieren, wird die maximale Ausfallkapazität für den Pool dynamisch neu berechnet. Mit diesen Informationen können Sie je nach Ihren Geschäftsanforderungen verschiedene Kombinationen von VM-Neustartprioritäten ausprobieren. Sie können feststellen, ob die maximale Ausfallkapazität dem Schutzniveau entspricht, das Sie für die kritischen VMs im Pool benötigen.

Wenn Sie versuchen, eine VM zu starten oder fortzusetzen und diese Aktion dazu führen würde, dass der Pool überschrieben wird, wird in XenCenter eine Warnung angezeigt. Die Nachricht kann auch an eine E-Mail-Adresse gesendet werden, sofern konfiguriert. Sie haben die Möglichkeit, den Vorgang abzubrechen oder trotzdem fortzufahren, wodurch der Pool zu stark festgeschrieben wird.

Arbeiten mit einem HA-fähigen Pool

Die beste Methode für Hochverfügbarkeit besteht darin, keine Konfigurationsänderungen am Pool vorzunehmen, während die Hochverfügbarkeit aktiviert ist. Stattdessen soll es der “Schutz um 2 Uhr morgens” sein, der Server im Falle eines Problems neu startet, wenn sich kein menschlicher Administrator in der Nähe befindet. Wenn Sie aktiv Konfigurationsänderungen im Pool vornehmen, z. B. Softwareupdates anwenden, deaktivieren Sie die hohe Verfügbarkeit während dieser Änderungen.

Wenn Sie versuchen, eine geschützte VM von XenCenter aus herunterzufahren, bietet XenCenter die Möglichkeit, die VM aus dem Ausfallplan zu entfernen und sie dann herunterzufahren. Diese Option stellt sicher, dass versehentliches Herunterfahren der VM nicht zu Ausfallzeiten führt, dass Sie jedoch eine geschützte VM anhalten können, wenn Sie dies wirklich möchten.
Wenn Sie einen Server neu starten müssen, wenn Hochverfügbarkeit aktiviert ist, verwendet XenCenter automatisch die VM-Neustartprioritäten, um zu ermitteln, ob durch diesen Neustart der Pool-Ausfallplan ungültig wird. Wenn es keinen Einfluss auf den Plan hat, wird der Server normal heruntergefahren. Wenn der Plan verletzt wird, die maximale Ausfallkapazität jedoch größer als 1 ist, bietet XenCenter die Option, die Serverausfallgrenze des Pools um 1 zu senken. Diese Aktion reduziert die allgemeine Ausfallsicherheit des Pools, stellt jedoch immer sicher, dass mindestens ein Serverausfall toleriert wird. Wenn der Server wieder hochgeladen wird, wird der Plan automatisch neu berechnet, und gegebenenfalls wird das ursprüngliche Serverausfalllimit wiederhergestellt.
Wenn Sie Softwareupdates mit dem Assistenten zum Installieren von Updates installieren, müssen Sie die Hochverfügbarkeit im Pool deaktivieren, indem Sie HA ausschaltenauswählen. Sie können die Hochverfügbarkeit wieder aktivieren, nachdem das Update installiert wurde. Wenn Sie die Hochverfügbarkeit nicht deaktivieren, wird das Update nicht fortgesetzt. Überwachen Sie den Pool manuell, während Updates installiert werden, um sicherzustellen, dass Serverausfälle den Betrieb des Pools nicht stören.
Wenn die hohe Verfügbarkeit aktiviert ist, sind einige Vorgänge, die den Plan für den Neustart von VMs gefährden können, möglicherweise deaktiviert, z. B. das Entfernen eines Servers aus einem Pool. Deaktivieren Sie vorübergehend die Hochverfügbarkeit, oder Sie können die geschützten VMs herunterfahren, bevor Sie fortfahren.

Hochverfügbarkeit und rollenbasierte Zugriffskontrolle (RBAC)

In XenServer-Umgebungen, in denen die rollenbasierte Zugriffskontrolle (RBAC) implementiert ist, dürfen nicht alle Benutzer die Einstellungen für die Hochverfügbarkeitskonfiguration eines Pools ändern. VM-Operatoren verfügen beispielsweise nicht über ausreichende Berechtigungen, um die Failoverkapazität für einen HA-aktivierten Pool anzupassen. Wenn das Starten einer VM die maximale Anzahl zulässiger Serverausfälle auf einen niedrigeren Wert als den aktuellen Wert reduziert, kann ein VM-Betreiber die VM nicht starten. Nur Benutzer auf Pooladministrator- oder Pooloperatorebene können die Anzahl der zulässigen Serverausfälle konfigurieren.

In diesem Fall kann der Pool-Administrator oder Pool-Operator die Serverausfallbegrenzung auf eine Zahl festlegen, die unter der maximal zulässigen Anzahl von Ausfällen liegt. Diese Einstellung erstellt Pufferkapazität und stellt so sicher, dass weniger privilegierte Benutzer neue VMs starten können. Dadurch wird die Failover-Kapazität des Pools reduziert, ohne den Ausfallplan zu gefährden.