Grundlegendes zum Cluster- und Poolquorum

Gilt für: Azure Stack HCI, Versionen 22H2 und 21H2; Windows Server 2022, Windows Server

Windows Server-Failoverclustering bietet hohe Verfügbarkeit für Workloads, die auf Azure Stack HCI- und Windows Server-Clustern ausgeführt werden. Diese Ressourcen gelten als hochverfügbar, wenn die Knoten, die Ressourcen hosten, online sind. In der Regel erfordert der Cluster jedoch, dass mehr als die Hälfte der Knoten ausgeführt wird. Dies wird als Quorum bezeichnet.

Quorum wurde entwickelt, um Split-Brain-Szenarien zu verhindern, die auftreten können, wenn eine Partition im Netzwerk vorhanden ist und Teilmengen von Knoten nicht miteinander kommunizieren können. Dies kann dazu führen, dass beide Teilmengen von Knoten versuchen, die Workload zu besitzen und auf denselben Datenträger zu schreiben, was zu zahlreichen Problemen führen kann. Dies wird jedoch durch das Quorumkonzept des Failoverclusterings verhindert, das nur eine dieser Knotengruppen dazu zwingt, weiterhin ausgeführt zu werden, sodass nur eine dieser Gruppen online bleibt.

Das Quorum bestimmt, wie viele Ausfälle der Cluster überstehen und dabei online bleiben kann. Quorum ist für das Szenario konzipiert, wenn ein Problem mit der Kommunikation zwischen Teilmengen von Clusterknoten besteht, sodass mehrere Server nicht versuchen, gleichzeitig eine Ressourcengruppe zu hosten und gleichzeitig auf denselben Datenträger zu schreiben. Durch dieses Quorumkonzept erzwingt der Cluster den Clusterdienst, in einer der Teilmengen von Knoten anzuhalten, um sicherzustellen, dass es nur einen wahren Besitzer einer bestimmten Ressourcengruppe gibt. Knoten, die beendet wurden, können erneut mit der Standard Gruppe von Knoten kommunizieren und automatisch wieder dem Cluster beitreten und ihren Clusterdienst starten.

In Azure Stack HCI und Windows Server 2019 verfügen zwei Systemkomponenten über eigene Quorummechanismen:

  • Clusterquorum: Dieses Quorum wird auf der Clusterebene angewendet (d. h. der Cluster bleibt auch bei einem Ausfall von Knoten verfügbar).
  • Poolquorum: Dieses Quorum wird auf der Poolebene angewendet (d. h. der Pool bleibt auch bei einem Ausfall von Knoten und Laufwerken verfügbar). Speicherpools sind zur Verwendung in Szenarien mit und ohne Cluster konzipiert und haben daher einen anderen Quorummechanismus.

Übersicht über das Clusterquorum

In der folgenden Tabelle finden Sie eine Übersicht über die Ergebnisse des Clusterquorums für verschiedene Szenarien:

Serverknoten Übersteht einen Serverknotenausfall Übersteht zwei nacheinander auftretende Serverknotenausfälle Übersteht zwei gleichzeitige Serverknotenausfälle
2 50/50 Nein Nein
2 + Zeuge Ja Nein Nein
3 Ja 50/50 Nein
3 + Zeuge Ja Ja Nein
4 Ja Ja 50/50
4 + Zeuge Ja Yes Ja
5 und mehr Ja Yes Ja

Empfehlungen für das Clusterquorum

  • Wenn Sie zwei Knoten haben, ist ein Zeuge erforderlich.
  • Wenn Sie drei oder vier Knoten haben, wird ein Zeuge ausdrücklich empfohlen.
  • Bei mindestens fünf ist kein Zeuge erforderlich, und er bietet keine zusätzliche Resilienz.
  • Verwenden Sie einen Cloudzeugen, wenn Sie über Internetzugriff verfügen.
  • Verwenden Sie im Fall einer IT-Umgebung mit anderen Computern und Dateifreigaben einen Dateifreigabezeugen.

Funktionsweise des Clusterquorums

Wenn Knoten ausfallen oder bei einer Teilmenge von Knoten die Verbindung mit einer anderen Teilmenge unterbrochen wird, müssen die verbleibenden Knoten nachweisen, dass sie die Mehrheit des Clusters darstellen, damit sie online bleiben. Können sie dies nicht, werden sie offline geschaltet.

Das Konzept der Mehrheit funktioniert jedoch nur, wenn die Gesamtanzahl von Knoten im Cluster ungerade ist (z. B. drei Knoten in einem Cluster mit fünf Knoten). Was geschieht also bei Clustern mit einer geraden Anzahl von Knoten (z. B. vier Knoten)?

Es gibt zwei Möglichkeiten, wie der Cluster für eine ungerade Gesamtanzahl von Stimmen sorgen kann:

  1. Die Anzahl von Stimmen kann durch Hinzufügen eines Zeugen mit einer zusätzlichen Stimme erhöht werden. Hierfür muss der Benutzer einige Einrichtungsschritte durchführen.
  2. Die Anzahl von Stimmen kann durch Löschen der Stimme eines Knotens verringert werden (dies erfolgt bei Bedarf automatisch).

Wenn überlebende Knoten erfolgreich überprüfen, ob sie die Mehrheit sind, wird die Definition der Mehrheit aktualisiert, um nur unter den Überlebenden zu sein. So kann ein Knoten des Clusters ausfallen, dann ein weiterer, noch ein weiterer usw. Diese Anpassung der Gesamtzahl von Stimmen nach aufeinander folgenden Ausfällen wird als dynamisches Quorum bezeichnet.

Dynamischer Zeuge

Der dynamische Zeuge schaltet die Stimme des Zeugen ein oder aus, um sicherzustellen, dass die Gesamtanzahl von Stimmen ungerade ist. Bei einer ungeraden Anzahl von Stimmen hat der Zeuge keine Stimme. Wenn es eine gerade Anzahl von Stimmen gibt, hat der Zeuge eine Stimme. Der dynamische Zeuge verringert das Risiko, dass der Cluster aufgrund eines Zeugenfehlers ausfällt, erheblich. Der Cluster entscheidet je nach Anzahl von Abstimmungsknoten, die im Cluster verfügbar sind, ob die Stimme des Zeugen verwendet wird.

Wie das dynamische Quorum mit dem dynamischen Zeugen funktioniert, wird im Folgenden beschrieben.

Verhalten des dynamischen Quorums

  • Wenn Sie eine gerade Anzahl von Knoten und keinen Zeugen haben, wird die Stimme eines Knotens gelöscht. Beispielsweise erhalten nur drei der vier Knoten eine Stimme, sodass die Gesamtzahl von Stimmen drei ist und zwei verbleibende Knoten mit Stimme als Mehrheit gelten.
  • Wenn Sie eine ungerade Anzahl von Knoten und keinen Zeugen haben, erhalten alle Knoten eine Stimme.
  • Wenn Sie eine gerade Anzahl von Knoten und einen Zeugen haben, stimmt der Zeuge ab, sodass die Gesamtanzahl ungerade ist.
  • Wenn Sie eine ungerade Anzahl von Knoten und einen Zeugen haben, stimmt der Zeuge nicht ab.

Mithilfe des dynamischen Quorums kann einem Knoten dynamisch eine Stimme zugewiesen werden, damit die Stimmenmehrheit nicht verloren geht und der Cluster mit einem Knoten (dem so genannten „Last Man Standing“) ausgeführt werden kann. Nehmen wir als Beispiel einen Cluster mit vier Knoten. Angenommen, das Quorum erfordert drei Stimmen.

In diesem Fall wäre der Cluster beim Ausfall von zwei Knoten nicht mehr verfügbar.

Diagramm mit vier Clusterknoten, von denen jeder eine Stimme erhält.

Das dynamische Quorum verhindert jedoch, dass dies geschieht. Die Gesamtanzahl von Stimmen, die für das Quorum erforderlich ist, wird jetzt basierend auf der Anzahl verfügbarer Knoten bestimmt. Mit dem dynamischen Quorum bleibt der Cluster also auch dann aktiv, wenn Sie drei Knoten verlieren.

Diagramm mit vier Clusterknoten, die nacheinander ausfallen, und der nach jedem Ausfall angepassten Anzahl erforderlicher Stimmen

Das obige Szenario gilt für einen allgemeinen Cluster, für den „Direkte Speicherplätze“ nicht aktiviert ist. Wenn „Direkte Speicherplätze“ aktiviert ist, toleriert der Cluster nur zwei Knotenausfälle. Weitere Informationen dazu finden Sie im Abschnitt zum Poolquorum.

Beispiele

Zwei Knoten ohne einen Zeugen

Die Stimme eines Knotens wird gelöscht, sodass die Stimmenmehrheit anhand einer Gesamtanzahl von einer Stimme bestimmt wird. Wenn der Knoten, der nicht abstimmt, unerwartet ausfällt, hat der verbleibende Knoten die 1/1-Mehrheit, und der Cluster bleibt online. Wenn der Knoten, der abstimmt, unerwartet ausfällt, hat der verbleibende Knoten die 0/1-Mehrheit, und der Cluster ist nicht mehr verfügbar. Wenn der Knoten, der abstimmt, korrekt heruntergefahren wird, wird die Stimme an den anderen Knoten übertragen, und der Cluster bleibt online. Aus diesem Grund ist es wichtig, einen Zeugen zu konfigurieren.

Das Quorum wird im Fall mit zwei Knoten ohne Zeuge erläutert.

  • Übersteht einen Serverausfall: Chance von 50 Prozent.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Nein.
  • Übersteht zwei gleichzeitige Serverausfälle: Nein.

Zwei Knoten mit einem Zeugen

Beide Knoten und der Zeuge stimmen ab, sodass die Mehrheit anhand einer Gesamtanzahl von drei Stimmen bestimmt wird. Wenn ein Knoten ausfällt, hat der verbleibende Knoten die 2/3-Mehrheit, und der Cluster bleibt online.

Das Quorum wird in dem Fall mit zwei Knoten mit einem Zeugen erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Nein.
  • Übersteht zwei gleichzeitige Serverausfälle: Nein.

Drei Knoten ohne einen Zeugen

Alle Knoten stimmen ab, sodass die Mehrheit anhand einer Gesamtanzahl von drei Stimmen bestimmt wird. Wenn ein Knoten ausfällt, haben die verbleibenden Knoten die 2/3-Mehrheit, und der Cluster bleibt online. Der Cluster besteht dann aus zwei Knoten ohne einen Zeugen. Somit gilt das obige Szenario 1.

Das Quorum wird in dem Fall mit drei Knoten ohne Zeuge erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Chance von 50 Prozent.
  • Übersteht zwei gleichzeitige Serverausfälle: Nein.

Drei Knoten mit einem Zeugen

Alle Knoten stimmen ab, sodass der Zeuge zunächst nicht abstimmt. Die Mehrheit wird anhand einer Gesamtanzahl von drei Stimmen bestimmt. Nach einem Ausfall verfügt der Cluster über zwei Knoten mit einem Zeugen. Somit gilt wieder Szenario 2. Jetzt stimmen daher beide Knoten und der Zeuge ab.

Das Quorum wird in dem Fall mit drei Knoten mit einem Zeugen erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Ja.
  • Übersteht zwei gleichzeitige Serverausfälle: Nein.

Vier Knoten ohne einen Zeugen

Die Stimme eines Knotens wird gelöscht, sodass die Mehrheit anhand einer Gesamtanzahl von drei Stimmen bestimmt wird. Nach einem Ausfall verfügt der Cluster über drei Knoten, und es gilt Szenario 3.

Das Quorum wird in dem Fall mit vier Knoten ohne Zeuge erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Ja.
  • Übersteht zwei gleichzeitige Serverausfälle: Chance von 50 Prozent.

Vier Knoten mit einem Zeugen

Alle Knoten und der Zeuge stimmen ab, sodass die Mehrheit anhand einer Gesamtanzahl von fünf Stimmen bestimmt wird. Nach einem Ausfall gilt Szenario 4. Nach zwei gleichzeitigen Ausfällen gilt wieder Szenario 2.

Das Quorum wird im Fall mit vier Knoten mit einem Zeugen erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Ja.
  • Übersteht zwei gleichzeitige Serverausfälle: Ja.

Fünf und mehr Knoten

Alle Knoten oder alle bis auf einen Knoten stimmen ab, je nachdem, wodurch eine ungerade Gesamtanzahl erreicht wird. Direkte Speicherplätze kann sowieso nicht mehr als zwei Knoten nach unten verarbeiten, sodass an diesem Punkt kein Zeuge benötigt oder nützlich ist.

Das Quorum wird in dem Fall mit fünf Knoten und darüber hinaus erläutert.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Ja.
  • Übersteht zwei gleichzeitige Serverausfälle: Ja.

Nachdem Sie nun wissen, wie das Quorum funktioniert, befassen wir uns jetzt mit den Typen von Quorumzeugen.

Typen von Quorumzeugen

Failoverclustering unterstützt drei Typen von Quorumzeugen:

  • Cloudzeuge : BLOB-Speicher in Azure, auf den alle Knoten des Clusters zugreifen können. Dieser Zeuge verwaltet Clusteringinformationen in einer Datei „witness.log“, speichert aber keine Kopie der Clusterdatenbank.
  • SMB-Dateifreigabe: Eine SMB-Dateifreigabe, die auf einem Dateiserver mit Windows Server konfiguriert ist. Dieser Zeuge verwaltet Clusteringinformationen in einer Datei „witness.log“, speichert aber keine Kopie der Clusterdatenbank.
  • Datenträgerzeuge : Ein kleiner gruppierter Datenträger, der sich in der Gruppe Cluster Verfügbarer Speicher befindet. Dieser Datenträger ist hoch verfügbar und kann zwischen Knoten failovern. Er enthält eine Kopie der Clusterdatenbank. Ein Datenträgerzeuge wird von „Direkte Speicherplätze“ nicht unterstützt.

Übersicht über das Poolquorum

Bisher ging es um das Clusterquorum auf der Clusterebene. Als Nächstes befassen wir uns mit dem Poolquorum, das auf der Poolebene angewendet wird (d. h. der Pool bleibt auch bei einem Ausfall von Knoten und Laufwerken verfügbar). Speicherpools sind zur Verwendung in Szenarien mit und ohne Cluster konzipiert und haben daher einen anderen Quorummechanismus.

In der folgenden Tabelle finden Sie eine Übersicht über die Ergebnisse des Poolquorums für verschiedene Szenarien:

Serverknoten Übersteht einen Serverknotenausfall Übersteht zwei nacheinander auftretende Serverknotenausfälle Übersteht zwei gleichzeitige Serverknotenausfälle
2 Ja Nein Nein
2 + Zeuge Ja Nein Nein
3 Ja Nein Nein
3 + Zeuge Ja Nein Nein
4 Ja Nein Nein
4 + Zeuge Ja Yes Ja
5 und mehr Ja Yes Ja

Funktionsweise des Poolquorums

Wenn Laufwerke ausfallen oder eine Teilmenge von Laufwerken den Kontakt mit einer anderen Teilmenge verliert, müssen überlebende Laufwerke, die Metadaten hosten, überprüfen, ob sie den Großteil des Pools ausmachen, um online zu bleiben. Können sie dies nicht, werden sie offline geschaltet. Der Pool ist die Entität, die je nachdem, ob ausreichend Datenträger für das Quorum verfügbar sind, offline geschaltet wird oder online bleibt (50 % + 1). Die Clusterdatenbank kann +1 sein, solange der Cluster selbst quorate ist.

Das Poolquorum funktioniert jedoch anders als das Clusterquorum:

  • Der Pool wählt eine Teilmenge der Laufwerke pro Knoten aus, um Metadaten zu hosten.
  • Der Pool verwendet die Clusterdatenbank, um Verbindungen zu unterbrechen.
  • Der Pool verfügt nicht über ein dynamisches Quorum.
  • Der Pool implementiert keine eigene Version des Entfernens einer Abstimmung.

Beispiele

Vier Knoten mit symmetrischem Layout

Jedes der 16 Laufwerke verfügt über eine Stimme, und Knoten 2 hat ebenfalls eine Stimme (da er der Besitzer der Poolressource ist). Die Mehrheit wird anhand einer Gesamtanzahl von 16 Stimmen bestimmt. Wenn die Knoten 3 und 4 ausfallen, besteht die verbleibende Teilmenge aus acht Laufwerken und dem Besitzer der Poolressource, was 9/16 Stimmen entspricht. Der Pool ist daher weiterhin verfügbar.

Poolquorum 1.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Ja.
  • Übersteht zwei gleichzeitige Serverausfälle: Ja.

Vier Knoten mit symmetrischem Layout und Laufwerkausfall

Jedes der 16 Laufwerke verfügt über eine Stimme, und Knoten 2 hat ebenfalls eine Stimme (da er der Besitzer der Poolressource ist). Die Mehrheit wird anhand einer Gesamtanzahl von 16 Stimmen bestimmt. Zuerst fällt Laufwerk 7 aus. Wenn die Knoten 3 und 4 ausfallen, besteht die verbleibende Teilmenge aus sieben Laufwerken und dem Besitzer der Poolressource, was 8/16 Stimmen entspricht. Der Pool hat somit keine Mehrheit und ist nicht mehr verfügbar.

Poolquorum 2.

  • Übersteht einen Serverausfall: Ja.
  • Übersteht zwei nacheinander auftretende Serverausfälle: Nein.
  • Übersteht zwei gleichzeitige Serverausfälle: Nein.

Empfehlungen für das Poolquorum

  • Stellen Sie sicher, dass alle Knoten im Cluster symmetrisch sind (über die gleiche Anzahl von Laufwerken verfügen).
  • Aktivieren Sie drei-Wege-Spiegel oder duale Parität, damit Sie zwei Knotenfehler tolerieren und die virtuellen Datenträger online halten können.
  • Wenn mehr als zwei Knoten oder zwei Knoten und ein Datenträger auf einem anderen Knoten ausfallen, haben die Volumes möglicherweise keinen Zugriff auf alle drei Kopien der Daten, sodass sie offline geschaltet werden und nicht verfügbar sind. Es wird empfohlen, die Server zurückzubringen oder die Datenträger schnell zu ersetzen, um die größtmögliche Resilienz für alle Daten im Volume sicherzustellen.

Nächste Schritte