Info zu XenServer HA

XenServer High Availability (HA) ermöglicht den automatischen Neustart virtueller Maschinen im Falle eines zugrunde liegenden Hardwarefehlers oder eines Verlustes eines verwalteten Servers. HA soll sicherstellen, dass wichtige VMs immer in einem Ressourcenpool ausgeführt werden. Wenn HA aktiviert ist, werden die VMs im Falle eines Ausfalls eines Ihrer Server intelligent auf anderen Servern im selben Pool neu gestartet, sodass wesentliche Dienste bei System- oder Komponentenausfällen mit minimaler Serviceunterbrechung wiederhergestellt werden können. Wenn der Pool-Masterserver ausfällt, wählt XenServer HA automatisch einen neuen Server aus, der als Master übernommen werden soll, sodass Sie den Pool weiterhin verwalten können. Jeder Server in einem Pool kann ein Masterserver sein, und die Pooldatenbank wird ständig über alle Knoten repliziert und für zusätzliche Sicherheit auch auf freigegebenen Speicher auf dem Heartbeat-SR gesichert.

Für XenServer HA gibt es zwei wichtige Aspekte: die zuverlässige Erkennung von Serverausfällen und die Erstellung eines Ausfallplans, um eine schnelle Wiederherstellung zu ermöglichen. Diese werden im Folgenden ausführlich behandelt.

Heartbeats für Verfügbarkeit

Das zuverlässige Erkennen von Serverausfällen ist schwierig, da Sie zwischen einem Server, der für eine Weile verschwindet, und einem katastrophalen Ausfall aus der Ferne unterscheiden müssen. Wenn wir fälschlicherweise entscheiden, dass ein Master-Server defekt ist und einen neuen Master an seiner Stelle wählen, kann es unvorhersehbare Ergebnisse geben, wenn der ursprüngliche Server ein Comeback machen würde. Wenn es ein Netzwerkproblem gibt und sich ein Ressourcenpool in zwei gleiche Hälften teilt, 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 durch zwei Mechanismen: einen Speicher-Heartbeat und einen Netzwerk-Heartbeat.

Wenn Sie HA in einem Pool aktivieren, benennen Sie ein iSCSI-, Fibre Channel- oder NFS-Speicher-Repository als Heartbeat-SR. XenServer erstellt automatisch einige kleine virtuelle Laufwerke in diesem SR. Der erste Datenträger wird von jedem Server im Ressourcenpool als freigegebener Quorumdatenträger verwendet. Jeder Server weist sich einen eindeutigen Block auf der freigegebenen Festplatte zu und schreibt regelmäßig in den Block, um anzuzeigen, dass er aktiv ist. Wenn HA gestartet wird, tauschen alle Server Daten über Netzwerk- und Speicherkanäle aus und geben an, welche Server sie über beide Kanäle sehen können - also welche E/A -Pfade funktionieren und welche nicht. Diese Informationen werden ausgetauscht, bis ein fester Punkt erreicht ist und alle Server im Pool davon überzeugt sind, dass sie sich darüber einig sind, was sie sehen können. In diesem Fall ist HA aktiviert und der Pool ist geschützt. Dieser HA-Scharfvorgang kann einige Minuten dauern, um größere Pools zu begleichen, ist jedoch nur erforderlich, wenn HA zum ersten Mal aktiviert wurde.

Sobald HA aktiv ist, schreibt jeder Server regelmäßig Speicheraktualisierungen auf das virtuelle Heartbeat-Laufwerk und Netzwerkpakete über die Verwaltungsschnittstelle. (Es ist wichtig, sicherzustellen, dass Netzwerkadaptergebunden/en-us/xencenter/current-release/hosts-nics.html[()]für Ausfallsicherheit sind und dass SpeicherschnittstellenDynamisches Multipathing[]/en-us/xencenter/current-release/storage-pools-multipathing.htmlwo unterstützt.) Dadurch wird sichergestellt, dass einzelne Adapter oder Verkabelungsfehler nicht zu Verfügbarkeitsproblemen führen.

Server-Fencing

Das schlimmste Szenario für HA ist die Situation, in der ein Server als offline betrachtet wird, aber tatsächlich noch in den gemeinsam genutzten Speicher schreibt, da dies zu einer Beschädigung der persistenten Daten führen kann. Um diese Situation zu verhindern, verwendet XenServer Server-Fencing, d. h. der Server wird automatisch ausgeschaltet und vom Zugriff auf freigegebene Ressourcen im Pool isoliert. Dadurch wird verhindert, dass der ausfallende Server auf freigegebene Datenträger schreibt und die Konsistenz der gespeicherten Daten während des automatisierten Failovers beschädigt wird, wenn geschützte virtuelle Maschinen auf andere, fehlerfreie Server im Pool verschoben werden.

Server werden sich im Falle eines Heartbeat-Ausfalls automatisch ausschalten und neu starten, es sei denn, Folgendes gilt:

  • Der Speicher-Heartbeat ist für alle Server vorhanden, aber das Netzwerk hat partitioniert (so dass es jetzt zwei Gruppen von Servern gibt). In diesem Fall bleiben alle Server, die Mitglieder der größten Netzwerkpartition sind, und die Server in der kleineren Netzwerkpartition Self-Fence ausgeführt. Es wird davon ausgegangen, dass der Netzwerkausfall die VMs isoliert hat und sie auf einem Server mit funktionierender Netzwerkverbindung neu gestartet werden sollten. Wenn die Netzwerkpartitionen genau die gleiche Größe haben, dann wird nur eine von ihnen nach einer stabilen Auswahlfunktion selbstzäunt.
  • Wenn der Speicher-Heartbeat verschwindet, aber der Netzwerk-Heartbeat bleibt, überprüfen die Server, ob sie alle anderen Server über das Netzwerk sehen können. Wenn diese Bedingung erfüllt ist, bleiben die Server unter der Annahme ausgeführt, dass der Speicher-Heartbeat-Server verschwunden ist. Dies beeinträchtigt die Sicherheit der virtuellen Maschine nicht, aber alle Netzwerkstörungen führen zu Fechten, da dies bedeuten würde, dass beide Heartbeats verschwunden sind.

Kapazitätsplanung für Ausfälle

Das Heartbeat-System gibt uns zuverlässige Benachrichtigung über Serverausfälle, und so gehen wir in den zweiten Schritt von HA: Kapazitätsplanung für Ausfälle.

Ein Ressourcenpool besteht aus mehreren Servern (z. B. 32), die jeweils mit potenziell unterschiedlichen Speichermengen und einer unterschiedlichen Anzahl ausgeführter VMs ausgestattet sind. Um sicherzustellen, dass kein einzelner Serverausfall es unmöglich macht, seine VMs auf einem anderen Server neu zu starten (z. B. aufgrund eines unzureichenden Arbeitsspeichers auf einem anderen Server), berechnet XenServer HA dynamisch einen Fehlerplan, der die Aktionen berechnet, die bei einem Serverausfall ausgeführt werden würden. Neben dem Ausfall eines einzelnen Servers kann XenServer HA mit dem Verlust mehrerer Server in einem Pool umgehen, beispielsweise wenn eine Netzwerkpartition eine ganze Gruppe von Servern ausfällt.

Neben der Berechnung, welche Aktionen durchgeführt werden, berücksichtigt der Fehlerplan die Anzahl der Serverausfälle, die im Pool toleriert werden können. Es gibt zwei wichtige Überlegungen bei der Berechnung des HA-Plans für einen Pool:

  • Maximale Ausfallkapazität. Dies ist die maximale Anzahl von Servern, die fehlschlagen können, bevor nicht genügend Ressourcen vorhanden sind, um alle geschützten VMs im Pool auszuführen. Dieser Wert wird von XenServer unter Berücksichtigung der Neustartprioritäten der VMs im Pool und der Poolkonfiguration (Anzahl der Server, CPU und Arbeitsspeicher) berechnet. Kapazität).
  • Grenzwert für den Serverausfall. Dies ist ein Wert, den Sie als Teil der HA-Konfiguration definieren können, der die Anzahl der Serverfehler angibt, die Sie im Pool im HA-Plan zulassen möchten. Wenn Sie beispielsweise in einem Ressourcenpool von 16 Servern den Grenzwert für den Serverausfall auf 3 festlegen, berechnet XenServer einen Failoverplan, der einen Ausfall von 3 Servern ermöglicht und dennoch alle geschützten VMs im Pool ausführen kann. Sie können das Serverausfalllimit auf einen Wert konfigurieren, der niedriger als die maximale Ausfallkapazität ist, wodurch es weniger wahrscheinlich ist, dass der Pool übermäßig festgeschrieben wird. Dies kann in einer Umgebung mit aktiviertem RBAC nützlich sein, um beispielsweise RBAC-Benutzern ohne Pool-Operator-Berechtigungen zu ermöglichen, mehr VMs online zu schalten, ohne den HA-Plan zu brechen. SieheHA und rollenbasierte Zugriffskontrolle (RBAC)unten.

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

Überschreitungsschutz

Wenn HA für einen Pool zum ersten Mal aktiviert wird, wird ein Fehlerplan basierend auf den zu diesem Zeitpunkt verfügbaren Ressourcen berechnet. XenServer HA berechnet dynamisch einen neuen Fehlerplan 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 gesamten Pool nicht berechnet werden kann (z. B. nicht genügend freier Arbeitsspeicher oder Änderungen an virtuellen Laufwerken und Netzwerken, die Auswirkungen darauf haben, welche VMs auf welchen Servern neu gestartet werden können), wird der Pool übermäßig festgeschrieben.

Die HA-Neustartpriorität wird verwendet, um zu bestimmen, welche VMs gestartet werden sollen, wenn ein Pool übermäßig festgeschrieben wird. Wenn Sie die Neustartpriorität für die VMs konfigurieren, die Sie schützen möchten, im Dialogfeld HA-Konfiguration oder im Assistenten zum Konfigurieren von HA konfigurieren , sehen Sie die maximale Ausfallkapazität für den Pool, der dynamisch neu berechnet wird, sodass Sie verschiedene Kombinationen von VM-Neustart ausprobieren können. -Prioritäten abhängig von Ihren geschäftlichen Anforderungen, und prüfen Sie, ob die maximale Ausfallkapazität dem Schutzniveau entspricht, den 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 übermäßig festgeschrieben wird, wird in XenCenter eine Warnung angezeigt. Die Nachricht kann auch an eine E-Mail-Adresse gesendet werden, wenn sie konfiguriert ist. Sie können dann den Vorgang abbrechen oder trotzdem fortfahren, wodurch der Pool übermäßig festgeschrieben wird.

Arbeiten mit einem HA-fähigen Pool

Die beste Vorgehensweise für HA besteht darin, keine Konfigurationsänderungen am Pool vorzunehmen, während HA aktiviert ist. Stattdessen soll es sich um die „2:00 Uhr“ handeln, die Server im Falle eines Problems neu starten wird, wenn kein menschlicher Administrator in der Nähe ist. Wenn Sie aktiv Konfigurationsänderungen im Pool vornehmen, z. B. Softwareupdates anwenden, sollte HA für die Dauer dieser Änderungen deaktiviert werden.

  • Wenn Sie versuchen, eine geschützte VM von XenCenter herunterzufahren, bietet Ihnen XenCenter die Möglichkeit, die VM zuerst aus dem Pool-Fehlerplan zu entfernen und sie dann herunterzufahren. Dadurch wird sichergestellt, dass versehentliches Herunterfahren von VM keine Ausfallzeiten zur Folge haben, aber dass Sie eine geschützte VM trotzdem stoppen können, wenn Sie es wirklich möchten.
  • Wenn Sie einen Server neu starten müssen, wenn HA aktiviert ist, verwendet XenCenter automatisch die Neustartprioritäten für VM, um festzustellen, ob dadurch der Poolausfallplan ungültig wird. Wenn sich dies nicht auf den Plan auswirkt, wird der Server normal heruntergefahren. Wenn der Plan verletzt würde, aber die maximale Ausfallkapazität größer als 1 ist, bietet XenCenter die Möglichkeit, die Serverausfallgrenze des Pools um 1 zu senken. Dies 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 das ursprüngliche Fehlerlimit für den Server wiederhergestellt.
  • Wenn SieSoftwareupdatesmit dem Update-Assistenten installieren installieren installieren, müssen Sie HA für den Pool deaktivieren, indem Sie auf die Option HA deaktivierenklicken, bis das Update installiert wurde. Wenn Sie HA nicht deaktivieren, wird das Update nicht fortgesetzt. Sie müssen den Pool während der Installation von Updates manuell überwachen, um sicherzustellen, dass Serverfehler den Betrieb des Pools nicht stören.
  • Wenn HA aktiviert ist, werden möglicherweise einige Vorgänge deaktiviert, die den Plan zum Neustart von VMs gefährden würden, z. B. das Entfernen eines Servers aus einem Pool. Um diese Vorgänge auszuführen, sollten Sie HA vorübergehend deaktivieren, oder Sie können die geschützten VMs herunterfahren, bevor Sie fortfahren.

HA und rollenbasierte Zugriffskontrolle (RBAC)

In XenServer-Umgebungen, in denen rollenbasierte Zugriffssteuerung (RBAC) implementiert ist, dürfen nicht alle Benutzer die HA-Konfigurationseinstellungen eines Pools ändern. Benutzer, die z. B. VMs (VM-Operatoren) starten können, verfügen nicht über ausreichende Berechtigungen, um die Failoverkapazität für einen HA-fähigen Pool anzupassen. Wenn das Starten einer VM beispielsweise die maximale Anzahl von Serverfehlern auf einen Wert reduziert, der niedriger ist als die aktuelle maximale Ausfallkapazität, kann der VM-Operator die VM nicht starten. Nur Benutzer auf Pooladministrator- oder Pool-Operator-Ebene können die Anzahl der zulässigen Serverfehler konfigurieren.

In diesem Fall kann der Benutzer, der HA aktiviert (mit einer Pooladministrator- oder Pool-Operatorrolle), die Serverausfallgrenze auf eine Zahl festlegen, die tatsächlich niedriger ist als die maximal zulässige Anzahl von Fehlern. Dadurch wird eine Pufferkapazität geschaffen und gewährleistet, dass weniger privilegierte Benutzer neue VMs starten und die Failoverkapazität des Pools reduzieren können, ohne den Fehlerplan zu bedrohen.