Grundlegendes zu Cluster- und Poolquorum

• 01/18/2019
• 11 minuten zum Lesen
• • ein
  • e
  • v
  • C
  • J
  • +3

Gilt für: Windows Server 2019, Windows Server 2016

Windows Server-Failoverclustering bietet eine hohe Verfügbarkeit für Workloads. Diese Ressourcen gelten als hochverfügbar, wenn die Knoten, auf denen Ressourcen gehostet werden, aktiv sind; für den Cluster muss jedoch im Allgemeinen mehr als die Hälfte der Knoten ausgeführt werden, was als Quorum bezeichnet wird.

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 Arbeitslast zu besitzen und auf dieselbe Festplatte zu schreiben, was zu zahlreichen Problemen führen kann. Dies wird jedoch durch das Quorumkonzept von Failover Clustering verhindert, das nur eine dieser Knotengruppen zur weiteren Ausführung zwingt, sodass nur eine dieser Gruppen online bleibt.

Das Quorum bestimmt die Anzahl der Fehler, die der Cluster aushalten kann, während er noch online bleibt. Das Quorum wurde entwickelt, um das Szenario zu bewältigen, in dem ein Problem mit der Kommunikation zwischen Teilmengen von Clusterknoten auftritt, sodass nicht mehrere Server gleichzeitig versuchen, eine Ressourcengruppe zu hosten und gleichzeitig auf dieselbe Festplatte zu schreiben. Durch dieses Quorumkonzept zwingt der Cluster den Clusterdienst, in einer der Teilmengen von Knoten anzuhalten, um sicherzustellen, dass es nur einen wahren Eigentümer einer bestimmten Ressourcengruppe gibt. Sobald Knoten, die gestoppt wurden, wieder mit der Hauptgruppe von Knoten kommunizieren können, treten sie automatisch wieder dem Cluster bei und starten ihren Clusterdienst.

In Windows Server 2019 und Windows Server 2016 gibt es zwei Komponenten des Systems, die über eigene Quorummechanismen verfügen:

• Cluster-Quorum: Dies funktioniert auf Clusterebene (dh. sie können Knoten verlieren und der Cluster bleibt aktiv)
• Poolquorum: Dies funktioniert auf Poolebene, wenn Storage Spaces Direct aktiviert ist (dh Sie können Knoten und Laufwerke verlieren und der Pool bleibt aktiv). Speicherpools wurden für die Verwendung in Clustered- und Non-Clustered-Szenarien entwickelt, weshalb sie über einen anderen Quorummechanismus verfügen.

Übersicht über das Clusterquorum

Die folgende Tabelle gibt einen Überblick über die Ergebnisse des Clusterquorums pro Szenario:

Serverknoten	Kann einen Serverknotenausfall überleben	Kann einen Serverknotenausfall überleben, dann kann ein anderer	zwei gleichzeitige Serverknotenausfälle überleben
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	Ja	Ja
5 und darüber	Ja	Ja	Ja

Clusterquorumempfehlungen

• Wenn Sie zwei Knoten haben, ist ein Zeuge erforderlich.
• Wenn Sie drei oder vier Knoten haben, wird Witness dringend empfohlen.
• Wenn Sie über einen Internetzugang verfügen, verwenden Sie einen Cloud-Zeugen
• Wenn Sie sich in einer IT-Umgebung mit anderen Computern und Dateifreigaben befinden, verwenden Sie einen Dateifreigabezeugen

Funktionsweise des Clusterquorums

Wenn Knoten ausfallen oder wenn eine Teilmenge von Knoten den Kontakt zu einer anderen Teilmenge verliert, müssen überlebende Knoten überprüfen, ob sie den Großteil des Clusters ausmachen, um online zu bleiben. Wenn sie das nicht überprüfen können, werden sie offline gehen.

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

Es gibt zwei Möglichkeiten, wie der Cluster die Gesamtzahl der Stimmen ungerade machen kann:

1. Erstens kann es eins werden, indem ein Zeuge mit einer zusätzlichen Stimme hinzugefügt wird. Dies erfordert eine Benutzereinrichtung.
2. Oder es kann eins nach unten gehen, indem die Stimme eines unglücklichen Knotens auf Null gesetzt wird (geschieht automatisch nach Bedarf).

Wenn überlebende Knoten erfolgreich überprüfen, dass sie die Mehrheit sind, wird die Definition der Mehrheit aktualisiert, um nur unter den Überlebenden zu sein. Dadurch kann der Cluster einen Knoten verlieren, dann einen anderen, dann einen anderen und so weiter. Dieses Konzept der Gesamtzahl der Stimmen, die sich nach aufeinanderfolgenden Fehlern ändern, wird als dynamisches Quorum bezeichnet.

Dynamischer Zeuge

Dynamischer Zeuge schaltet die Stimme des Zeugen um, um sicherzustellen, dass die Gesamtzahl der Stimmen ungerade ist. Wenn es eine ungerade Anzahl von Stimmen gibt, hat der Zeuge keine Stimme. Wenn es eine gerade Anzahl von Stimmen gibt, hat der Zeuge eine Stimme. Dynamic Witness reduziert das Risiko, dass der Cluster aufgrund eines Zeugenausfalls ausfällt, erheblich. Der Cluster entscheidet anhand der Anzahl der im Cluster verfügbaren Abstimmungsknoten, ob die Zeugenabstimmung verwendet werden soll.

Dynamisches Quorum arbeitet mit Dynamic Witness in der unten beschriebenen Weise.

Dynamisches Quorumverhalten

• Wenn Sie eine gerade Anzahl von Knoten und keinen Zeugen haben, wird die Abstimmung eines Knotens auf Null gesetzt. Beispielsweise erhalten nur drei der vier Knoten Stimmen, sodass die Gesamtzahl der Stimmen drei beträgt und zwei Überlebende mit Stimmen als Mehrheit betrachtet werden.
• Wenn Sie eine ungerade Anzahl von Knoten und keinen Zeugen haben, erhalten alle Stimmen.
• Wenn Sie eine gerade Anzahl von Knoten plus Zeuge haben, stimmt der Zeuge ab, sodass die Summe ungerade ist.
• Wenn Sie eine ungerade Anzahl von Knoten plus Zeuge haben, stimmt der Zeuge nicht ab.

Dynamisches Quorum ermöglicht die Möglichkeit, einem Knoten dynamisch eine Stimme zuzuweisen, um den Verlust der Stimmenmehrheit zu vermeiden und dem Cluster die Ausführung mit einem Knoten zu ermöglichen (bekannt als Last-Man Standing). Nehmen wir als Beispiel einen Cluster mit vier Knoten. Angenommen, das Quorum erfordert 3 Stimmen.

In diesem Fall wäre der Cluster ausgefallen, wenn Sie zwei Knoten verloren hätten.

Das dynamische Quorum verhindert dies jedoch. Die Gesamtzahl der für das Quorum erforderlichen Stimmen wird nun anhand der Anzahl der verfügbaren Knoten ermittelt. Mit dynamischem Quorum bleibt der Cluster also auch dann aktiv, wenn Sie drei Knoten verlieren.

Das obige Szenario gilt für einen allgemeinen Cluster, für den Storage Spaces Direct nicht aktiviert ist. Wenn Storage Spaces Direct aktiviert ist, kann der Cluster jedoch nur zwei Knotenfehler unterstützen. Dies wird im Abschnitt Poolquorum näher erläutert.

Beispiele

Zwei Knoten ohne Zeugen.

Die Stimme eines Knotens wird auf Null gesetzt, sodass die Mehrheitsstimme aus insgesamt 1 Stimme ermittelt wird. Wenn der nicht stimmberechtigte Knoten unerwartet ausfällt, hat der Überlebende 1/1 und der Cluster überlebt. Wenn der Abstimmungsknoten unerwartet ausfällt, hat der Überlebende 0/1 und der Cluster geht aus. Wenn der Abstimmungsknoten ordnungsgemäß heruntergefahren wird, wird die Abstimmung an den anderen Knoten übertragen, und der Cluster überlebt. Aus diesem Grund ist es wichtig, einen Zeugen zu konfigurieren.

• Kann einen Serverausfall überleben: Fünfzig Prozent Chance.
• Kann einen Serverausfall überleben, dann einen anderen: Nein.
• Kann zwei Serverausfälle gleichzeitig überstehen: Nein.

Zwei Knoten mit einem Zeugen.

Beide Knoten stimmen zuzüglich der Zeugenstimmen ab, sodass die Mehrheit aus insgesamt 3 Stimmen ermittelt wird. Wenn einer der Knoten ausfällt, hat der Überlebende 2/3 und der Cluster überlebt.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Nein.
• Kann zwei Serverausfälle gleichzeitig überstehen: Nein.

Drei Knoten ohne Zeugen.

Alle Knoten stimmen ab, sodass die Mehrheit aus insgesamt 3 Stimmen ermittelt wird. Wenn ein Knoten ausfällt, sind die Überlebenden 2/3 und der Cluster überlebt. Der Cluster wird zu zwei Knoten ohne Zeugen – zu diesem Zeitpunkt befinden Sie sich in Szenario 1.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Fünfzig Prozent Chance.
• Kann zwei Serverausfälle gleichzeitig überstehen: Nein.

Drei Knoten mit einem Zeugen.

Alle Knoten stimmen ab, sodass der Zeuge zunächst nicht abstimmt. Die Mehrheit wird aus insgesamt 3 Stimmen ermittelt. Nach einem Fehler verfügt der Cluster über zwei Knoten mit einem Zeugen – was zu Szenario 2 zurückkehrt. Also, jetzt stimmen die beiden Knoten und der Zeuge ab.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Ja.
• Kann zwei Serverausfälle gleichzeitig überstehen: Nein.

Vier Knoten ohne Zeugen

Die Stimme eines Knotens wird auf Null gesetzt, sodass die Mehrheit aus insgesamt 3 Stimmen ermittelt wird. Nach einem Fehler wird der Cluster zu drei Knoten, und Sie befinden sich in Szenario 3.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Ja.
• Kann zwei Serverausfälle gleichzeitig überleben: Fünfzig Prozent Chance.

Vier Knoten mit einem Zeugen.

Alle Knotenstimmen und die Zeugenstimmen, also wird die Mehrheit aus insgesamt 5 Stimmen ermittelt. Nach einem Fehler befinden Sie sich in Szenario 4. Nach zwei gleichzeitigen Fehlern springen Sie zu Szenario 2.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Ja.
• Kann zwei Serverausfälle gleichzeitig überstehen: Ja.

Fünf Knoten und darüber hinaus.

Alle Knoten stimmen ab oder alle bis auf eine Stimme, was auch immer die Summe ungerade macht. Storage Spaces Direct kann sowieso nicht mehr als zwei Knoten verarbeiten, daher ist zu diesem Zeitpunkt kein Zeuge erforderlich oder nützlich.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Ja.
• Kann zwei Serverausfälle gleichzeitig überstehen: Ja.

Nachdem wir nun verstanden haben, wie das Quorum funktioniert, schauen wir uns die Arten von Quorumzeugen an.

Quorum-Zeugentypen

Failover-Clustering unterstützt drei Arten von Quorum-Zeugen:

• Cloud Witness – Blob-Speicher in Azure, auf den alle Knoten des Clusters zugreifen können. Es verwaltet Clustering-Informationen in einem Zeugen.protokolldatei, speichert jedoch keine Kopie der Clusterdatenbank.
• File Share Witness – Eine SMB-Dateifreigabe, die auf einem Dateiserver unter Windows Server konfiguriert ist. Es verwaltet Clustering-Informationen in einem Zeugen.protokolldatei, speichert jedoch keine Kopie der Clusterdatenbank.
• Datenträgerzeuge – Eine kleine Clusterfestplatte, die sich in der verfügbaren Clusterspeichergruppe befindet. Diese Festplatte ist hochverfügbar und kann zwischen Knoten ein Failover durchführen. Es enthält eine Kopie der Clusterdatenbank. Ein Festplattenzeuge wird mit Storage Spaces Direct nicht unterstützt.

Pool-Quorum-Übersicht

Wir haben gerade über das Cluster-Quorum gesprochen, das auf Clusterebene ausgeführt wird. Lassen Sie uns nun in das Pool-Quorum eintauchen, das auf Poolebene arbeitet (dh Sie können Knoten und Laufwerke verlieren und den Pool aufbleiben lassen). Speicherpools wurden für die Verwendung in Clustered- und Non-Clustered-Szenarien entwickelt, weshalb sie über einen anderen Quorummechanismus verfügen.

Die folgende Tabelle gibt einen Überblick über die Poolquorumsergebnisse pro Szenario:

Serverknoten	Kann einen Serverknotenausfall überleben	Kann einen Serverknotenausfall überleben, dann kann ein anderer	zwei gleichzeitige Serverknotenausfälle überleben
2	Nein	Nein	Nein
2 + Zeuge	Ja	Nein	Nein
3	Ja	Nein	Nein
3 + Zeuge	Ja	Nein	Nein
4	Ja	Nein	Nein
4 + Zeuge	Ja	Ja	Ja
5 und darüber	Ja	Ja	Ja

Funktionsweise des Poolquorums

Wenn Laufwerke ausfallen oder wenn eine Teilmenge von Laufwerken den Kontakt zu einer anderen Teilmenge verliert, müssen überlebende Laufwerke überprüfen, ob sie den größten Teil des Pools ausmachen, um online zu bleiben. Wenn sie das nicht überprüfen können, werden sie offline gehen. Der Pool ist die Entität, die offline geht oder online bleibt, je nachdem, ob sie über genügend Festplatten für das Quorum verfügt (50% + 1). Der Poolressourcenbesitzer (aktiver Clusterknoten) kann +1 sein.

Das Poolquorum funktioniert jedoch auf folgende Weise anders als das Clusterquorum:

• Der Pool verwendet einen Knoten im Cluster als Zeugen als Tie-Breaker, um die Hälfte der Laufwerke zu überleben (dieser Knoten, der der Poolressourcenbesitzer ist)
• Der Pool hat KEIN dynamisches Quorum
• Der Pool implementiert KEINE eigene Version zum Entfernen einer Abstimmung

Beispiele

Vier knoten mit symmetrischem Layout.

Jedes der 16 Laufwerke hat eine Stimme und Knoten zwei hat auch eine Stimme (da es der Poolressourcenbesitzer ist). Die Mehrheit wird aus insgesamt 16 Stimmen ermittelt. Wenn Knoten drei und vier ausfallen, hat die überlebende Teilmenge 8 Laufwerke und den Poolressourcenbesitzer, der 9/16 Stimmen beträgt. Der Pool überlebt.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Ja.
• Kann zwei Serverausfälle gleichzeitig überstehen: Ja.

Vier Knoten mit symmetrischem Layout und Laufwerksfehler.

Jedes der 16 Laufwerke hat eine Stimme und Knoten 2 hat auch eine Stimme (da es der Poolressourcenbesitzer ist). Die Mehrheit wird aus insgesamt 16 Stimmen ermittelt. Zuerst geht Laufwerk 7 runter. Wenn Knoten drei und vier ausfallen, hat die überlebende Teilmenge 7 Laufwerke und den Poolressourcenbesitzer, was 8/16 Stimmen entspricht. Also, der Pool hat keine Mehrheit und geht runter.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: Nein.
• Kann zwei Serverausfälle gleichzeitig überstehen: Nein.

Vier Knoten mit einem unsymmetrischen Layout.

Jedes der 24 Laufwerke hat eine Stimme und Knoten zwei hat auch eine Stimme (da es der Poolressourcenbesitzer ist). Die Mehrheit wird aus insgesamt 24 Stimmen ermittelt. Wenn Knoten drei und vier ausfallen, hat die überlebende Teilmenge 8 Laufwerke und den Poolressourcenbesitzer, der 9/24 Stimmen beträgt. Also, der Pool hat keine Mehrheit und geht runter.

• Kann einen Serverausfall überleben: Ja.
• Kann einen Serverausfall überleben, dann einen anderen: **Abhängig **(kann nicht überleben, wenn beide Knoten drei und vier ausfallen, kann aber alle anderen Szenarien überleben.
• Kann zwei Serverausfälle gleichzeitig überstehen: *** ** (kann nicht überleben, wenn beide Knoten drei und vier ausfallen, kann aber alle anderen Szenarien überleben.

Pool-Quorumempfehlungen

• Stellen Sie sicher, dass jeder Knoten in Ihrem Cluster symmetrisch ist (jeder Knoten hat die gleiche Anzahl von Laufwerken)
• Aktivieren Sie Three-Way Mirror oder Dual Parity, damit Sie Knotenfehler tolerieren und die virtuellen Laufwerke online halten können. Weitere Informationen finden Sie auf unserer Volume Guidance-Seite.
• Wenn mehr als zwei Knoten ausgefallen sind oder zwei Knoten und ein Datenträger auf einem anderen Knoten ausgefallen sind, haben Volumes möglicherweise keinen Zugriff auf alle drei Kopien ihrer Daten. Es wird empfohlen, die Server schnell zurückzubringen oder die Festplatten auszutauschen, um die größtmögliche Ausfallsicherheit für alle Daten im Volume zu gewährleisten.