Quorum-Effekte auf das Systemverhalten

Ein Quorumserver in einem SplitSite-System wirkt sich auf die Verfügbarkeit und das Wiederherstellungsverhalten des Systems aus. Um den Quorum-Effekt auf das Systemverhalten zu verstehen, muss man sich zunächst klarmachen, wie sich ein System ohne Quorumserver verhält.

Voraussetzung: Planen und erstellen Sie eine SplitSite-Konfiguration, indem Sie zunächst Erstellen einer SplitSite-Konfiguration lesen und die entsprechenden Anweisungen befolgen, falls Sie dies noch nicht getan haben.

Ein everRun-System ist so konzipiert, dass es hohe Verfügbarkeit für eine oder mehrere Gast-VMs bietet. Dadurch können die VMs weiterhin ausgeführt werden, auch wenn es zu einem Fehler kommt, der andernfalls zum Ausfall der Anwendungen führen würde. Das everRun-System kann Gast-VMs auch dann weiterhin ausführen, wenn zum Beispiel eine einzelne Netzwerkverbindung, eine Festplatte oder sogar ein ganzer Computer ausfällt.

Wenn es jedoch zu einem schwerwiegenderen Fehler kommt (zum Beispiel Ausfall aller Netzwerkpfade), versucht das everRun-System, den allgemeinen Zustand des Gesamtsystems zu bestimmen. Das System führt dann die notwendigen Maßnahmen aus, um die Integrität der Gast-VMs zu schützen.

Die folgenden Beispiele veranschaulichen den Systemprozess bei einem katastrophalen Fehler.

Beispiel 1: Split-Brain-Zustand in einem System ohne Quorumserver

In diesem SplitSite-Beispiel enthält das everRun-System Knoten0 und Knoten1, aber keinen Quorumserver. Der Betrieb ist normal, es werden keine Fehler erkannt. Die beiden Knoten kommunizieren ihren Zustand und ihre Verfügbarkeit über die A-Link-Verbindungen, wie immer im normalen (fehlerfreien) Betrieb. Die folgende Abbildung zeigt die normalen Verbindungen.

Ein katastrophaler Fehler

Ein unaufmerksamer Gabelstapler-Fahrer durchstößt eine Wand. Dabei werden alle Netzwerkverbindungen (Unternehmensnetzwerke und A-Links) durchtrennt, während die Stromversorgung intakt bleibt und das System weiterhin läuft. Die folgende Abbildung zeigt den Fehlerzustand.

Fehlerbehandlung

Die beiden Knoten gehen folgendermaßen mit dem Fehler um:

Aus der Sicht eines Anwendungs-Clients oder eines externen Beobachters sind beide Gast-VMs aktiv und generieren Netzwerkmeldungen mit derselben Rückgabeadresse. Beide Gast-VMs generieren Daten und erkennen unterschiedliche Mengen an Kommunikationsfehlern. Die Zustände der Gast-VMs weichen im Laufe der Zeit immer mehr voneinander ab.

Wiederherstellung und Reparatur

Nach einiger Zeit ist die Netzwerkkonnektivität wiederhergestellt, die Wand wurde repariert und die Netzwerkkabel wurden erneuert.

Wenn jede AX des AX-Paars erkennt, dass der Partner wieder online ist, wählt das AX-Paar anhand der Fehlerbehandlungsregeln die AX aus, die weiterhin aktiv bleibt. Diese Auswahl ist nicht vorhersagbar und berücksichtigt nicht, welcher Knoten während des Split-Brain-Zustands die genauere Performance zeigte.

Die Daten, die von dem Knoten, der jetzt der Standby-Knoten ist, generiert wurden, werden durch die Resynchronisierung des aktiven Knotens überschrieben. Somit sind die Daten auf dem (derzeitigen) Standby-Knoten unwiderruflich verloren.

Nach einem Split-Brain-Zustand benötigt das System mehrere Minuten für die Resynchronisierung. Dieser Zeitraum ist davon abhängig, wie viel Festplattenaktivität an den Standby-Knoten übermittelt werden muss. Wenn mehrere Gast-VMs mit unterschiedlichen aktiven Knoten ausgeführt werden, kann Synchronisierungsdatenverkehr in beide Richtungen erfolgen.

Hinweis: Unter Umständen kann das everRun-System nicht ermitteln, wie nach einem katastrophalen Fehler am besten vorzugehen ist. In diesem Fall muss das System manuell wiederhergestellt werden. Die empfohlene Wiederherstellungsmethode ist dann, mit der everRun Availability Console einen Knoten herunterzufahren und neuzustarten, während der andere Knoten weiterhin ausgeführt wird. Diese Methode erzwingt normalerweise, dass der ausgeführte Knoten der primäre Knoten wird und die AX an diesem Knoten aktiv wird. Nachdem der ausgeführte Knoten der primäre Knoten ist, kann der andere Knoten durch einen Mitarbeiter eingeschaltet werden. Wenn die Resynchronisierung bereits ausgeführt wird, darf keiner der beiden Knoten heruntergefahren werden.

Beispiel 2: Ein SplitSite-System mit einem Quorumserver vermeidet einen Split-Brain-Zustand

In diesem SplitSite-Beispiel enthält das everRun-System Knoten0 und Knoten1 mit Verbindungen wie beim System in Beispiel 1. Zusätzlich enthält das System in Beispiel 2 jedoch einen Quorumserver. Diese Abbildung veranschaulicht diese Verbindungen.

Ein katastrophaler Fehler

Der unaufmerksame Gabelstapler-Fahrer durchstößt schon wieder eine Wand. Dabei werden alle Netzwerkverbindungen durchtrennt, während die Stromversorgung intakt bleibt und das System weiterhin läuft. Die folgende Abbildung zeigt den Fehlerzustand.

Fehlerbehandlung

Die beiden Knoten gehen folgendermaßen mit dem Fehler um:

Hinweis: Falls die Knoten1-AX zuvor nicht aktiv war und die Gast-VM eine HV-VM ist, muss die Gast-VM auf Knoten1 möglicherweise von der Festplatte von Knoten1 gestartet werden. In diesem Fall kommt es bei der Anwendung zu einem kurzen Ausfall, während die Gast-VM gestartet wird. (FT-VMs werden weiterhin ausgeführt.)

Aus der Sicht eines Anwendungs-Clients oder eines externen Beobachters bleibt die Gast-VM auf Knoten1 aktiv und generiert Daten, während die VM auf Knoten0 heruntergefahren wird. Es kommt zu keinem Split-Brain-Zustand.

Wiederherstellung und Reparatur

Nach einiger Zeit ist die Netzwerkkonnektivität wiederhergestellt, die Wand wurde repariert und die Netzwerkkabel wurden erneuert.

Wenn die Knoten1-AX erkennt, dass der Partner wieder online ist, wird die Knoten0-AX zum Standby-Knoten. Da Knoten0 zuvor nicht ausgeführt wurde, beginnt die Datensynchronisierung von Knoten1 zu Knoten0.

Da es nicht zu einer Split-Brain-Situation kam, sind keine Daten verloren gegangen.

Das System benötigt mehrere Minuten für die Resynchronisierung. Dieser Zeitraum ist davon abhängig, wie viel Festplattenaktivität an den Standby-Knoten übermittelt werden muss.

Beispiel 2, Variante: Der Quorumserver ist während des katastrophalen Fehlers nicht erreichbar

In einem SplitSite-System mit einem Quorumserver ist der Quorumserver möglicherweise offline oder aus anderen Gründen nicht erreichbar, wenn bei dem katastrophalen Fehler alle Netzwerkverbindungen getrennt werden, obwohl die Stromversorgung erhalten bleibt und das System weiterhin läuft. Die folgende Abbildung zeigt ein System in dieser Situation, während der Quorumserver offline ist.

Die Fehlerbehandlung ist ähnlich wie in Beispiel 2 – mit einem wichtigen Unterschied für Knoten1:

Die AX an Knoten1 erkennt ebenfalls den Verlust beider A-Links, ibiz0 bleibt jedoch verfügbar. Die Knoten1-AX versucht, den Quorumserver zu erreichen, die Kommunikation gelingt jedoch nicht. Die AX beendet die Gast-VM.

In diesem Fall wird die Gast-VM auf Knoten0 und Knoten1 heruntergefahren. Somit kommt es nicht zu einem Split-Brain-Zustand. Der Nachteil dabei ist, dass die Gast-VM nicht verfügbar ist, solange die Verbindung zu Knoten0 oder zum Quorumserver nicht wiederhergestellt wird.

In diesem Fall müssen Sie den Knoten bestimmen, der nicht in Betrieb sein soll, und ihn herunterfahren. Starten Sie den Knoten, der in Betrieb sein soll, und dann die VM. Informationen zum Herunterfahren und Starten einer VM finden Sie unter Verwalten des Betriebs einer virtuellen Maschine.

Beispiel 2, Variante: Der Quorumserver ist nicht erreichbar, ohne dass ein katastrophaler Fehler auftritt

Unter Umständen ist der Quorumserver nicht erreichbar, ohne dass ein katastrophaler Hardwarefehler aufgetreten ist. Dies ist zum Beispiel der Fall, wenn für Quorumcomputer aufgrund routinemäßiger Wartungsarbeiten (z. B. Anwendung von Betriebssystem-Patches) ein Neustart ausgeführt werden muss. In diesem Fall erkennt die AX, dass der Quorumserver nicht antwortet, und setzt den Synchronisierungsdatenverkehr aus, bis die Verbindung zum Quorumserver wiederhergestellt wird. Die Gast-VM wird weiterhin auf dem Knoten ausgeführt, der aktiv war, als die Verbindung unterbrochen wurde. Die Gast-VM wechselt jedoch nicht in den Standby-Modus, da möglicherweise weitere Fehler auftreten können. Nachdem der Quorumserver wiederhergestellt wurde, setzt die AX die Synchronisierung und die normale Fehlerbehandlung fort, solange die Verbindung zum Quorumserver erhalten bleibt.

Wiederherstellung nach einem Stromausfall

Wenn die Stromversorgung nach einem Stromausfall oder dem Ausschalten des Systems wiederhergestellt wird, wartet das everRun-System für unbegrenzte Zeit darauf, dass sein Partner startet und antwortet, bevor das System Gast-VMs startet. Wenn die AX, die zuvor aktiv war, den Quorumserver erreichen kann, startet die AX die Gast-VM sofort, ohne darauf zu warten, dass der Partnerknoten gestartet wird. Wenn die AX, die zuvor der Standby-Knoten war, zuerst startet, wartet sie auf ihren Partnerknoten.

Falls das System eine Antwort vom Partnerknoten oder vom Quorumserver erhält, wird der normale Betrieb aufgenommen und die VM startet. Dabei gelten dieselben Fehlerbehandlungsregeln wie in anderen Situationen.

Falls das System keine Antwort vom Quorumserver erhält oder das System über keinen Quorumserver verfügt, muss ein Mitarbeiter eine Gast-VM starten und damit alle Entscheidungen der AX oder der Fehlerbehandlung übergehen. Sie müssen dafür sorgen, dass nicht zwei Personen gleichzeitig dieselbe Gast-VM auf Knoten0 und Knoten1 starten. Dies würde unbeabsichtigt einen Split-Brain-Zustand schaffen.