Grundlegendes zum Cluster- und Pool quorum

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 werden als hoch verfügbar betrachtet, wenn die Knoten, auf denen die Ressourcen gehostet werden, hoch verfügbar sind. Der Cluster erfordert jedoch im Allgemeinen, dass mehr als die Hälfte der Knoten ausgeführt werden. 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 Quorum-Konzept des Failover-Clusterings verhindert, wodurch nur eine dieser Knotengruppen gezwungen wird, weiterzulaufen, sodass nur eine dieser Gruppen online bleibt.

Quorum bestimmt die Anzahl der Fehler, die der Cluster verkraften kann, während er noch online bleiben kann. Quorum wurde entwickelt, um das Szenario zu behandeln, wenn es ein Problem mit der Kommunikation zwischen Teilmengen von Clusterknoten gibt, sodass mehrere Server nicht versuchen, eine Ressourcengruppe gleichzeitig zu hosten und gleichzeitig auf denselben Datenträger zu schreiben. Durch dieses Quorumkonzept zwingt der Clusterdienst den Clusterdienst, in einer der Teilmengen von Knoten zu stoppen, um sicherzustellen, dass nur ein wahrer Besitzer einer bestimmten Ressourcengruppe vorhanden ist. Knoten, die beendet wurden, können erneut mit der Hauptgruppe von Knoten kommunizieren und automatisch wieder am Cluster teilnehmen und ihren Clusterdienst starten.

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

• Cluster quorum: Dies funktioniert auf Clusterebene (d. h. Sie können Knoten verlieren und den Cluster aufstehen lassen)
• Poolquorum: gilt auf Poolebene (d. h., der Pool bleibt erhalten, auch wenn Sie Knoten und Laufwerke verlieren) Speicherpools wurden sowohl in gruppierten als auch in nicht gruppierten Szenarien verwendet, weshalb sie über einen anderen Quorummechanismus verfügen.

Übersicht über das Clusterquorum

In der folgenden Tabelle finden Sie eine Übersicht über die Cluster-Quorum-Ergebnisse pro Szenario.

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

Empfehlungen für das Cluster-Quorum

• Wenn Sie zwei Knoten haben, ist ein Zeugen erforderlich.
• Wenn Sie drei oder vier Knoten haben, wird ein Zeuge dringend empfohlen.
• Wenn Sie fünf Knoten oder mehr haben, wird kein Zeuge benötigt und bietet keine zusätzliche Resilienz.
• Wenn Sie über Internetzugang verfügen, verwenden Sie einen Cloudzeugen.
• Verwenden Sie im Fall einer IT-Umgebung mit anderen Computern und Dateifreigaben einen Dateifreigabezeugen.

Funktionsweise des Cluster quorums

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

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

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

1. Erstens kann es um eins erhöht werden, indem ein Zeuge mit einer zusätzlichen Stimme hinzugefügt wird. Dies erfordert eine Benutzereinrichtung.
2. Es kann auch um eins verringert werden, indem die Stimme eines Knotens widerrufen wird (geschieht automatisch nach Bedarf).

Wenn die überlebenden Knoten erfolgreich überprüfen, dass sie die Mehrheit sind, wird die Definition der Mehrheit aktualisiert, um nur die Überlebenden einzuschließen. Dadurch kann der Cluster einen Knoten verlieren, dann einen weiteren, dann noch einen und so weiter. Dieses Konzept der Gesamtzahl der Stimmen , die sich nach aufeinander folgenden Fehlern anpassen, wird als "Dynamisches Quorum" bezeichnet.

Dynamischer Zeuge

Der dynamische Zeuge schaltet die Stimme des Zeugen um, um sicherzustellen, dass die Gesamtanzahl der Stimmen ungerade ist. Wenn es eine ungerade Anzahl von Stimmen gibt, hat der Zeuge keine Stimme. Wenn es eine gerade Stimmenzahl gibt, hat der Zeuge eine Stimme. Der dynamische Zeuge reduziert das Risiko eines Clusterausfalls aufgrund eines Zeugenfehlers erheblich. Der Cluster entscheidet, ob die Zeugenstimme basierend auf der Anzahl der im Cluster verfügbaren Abstimmungsknoten verwendet werden soll.

Das dynamische Quorum nutzt den dynamischen Zeugen in der unten beschriebenen Weise.

Dynamisches Quorumverhalten

• Wenn Sie eine gerade Anzahl von Knoten und keinen Zeuge haben, wird die Stimme eines Knotens widerrufen. Beispielsweise erhalten nur drei der vier Knoten Stimmen, sodass die Gesamtzahl der Stimmen drei ist und zwei Überlebende mit Stimmen als Mehrheit betrachtet werden.
• Wenn Sie eine ungerade Anzahl von Knoten und keinen Zeugen haben, erhalten alle eine Stimme.
• Wenn Sie eine gerade Anzahl von Knoten plus Zeugen haben, stimmt der Zeuge ab, sodass die Gesamtzahl ungerade ist.
• Wenn Sie eine ungerade Anzahl von Knoten plus einen Zeugen haben, stimmt der Zeuge nicht ab.

Das dynamische Quorum ermöglicht es, einem Knoten dynamisch eine Stimme zuzuweisen, um zu verhindern, dass die Mehrzahl der Stimmen verloren geht, und dem Cluster zu erlauben, mit einem Knoten betrieben zu werden (bekannt als "Last-Man-Standing"). Nehmen wir als Beispiel einen Cluster mit vier Knoten. Gehen Sie davon aus, dass ein Quorum 3 Stimmen erfordert.

In diesem Fall würde der Cluster ausfallen, wenn Sie zwei Knoten verloren gehen.

Das dynamische Quorum verhindert jedoch, dass dies geschieht. Die Gesamtzahl der für das Quorum erforderlichen Stimmen wird nun basierend auf der Anzahl der verfügbaren Knoten bestimmt. Bei dynamischem Quorum bleibt der Cluster also auch dann auf dem Laufenden, wenn drei Knoten verloren gehen.

Das obige Szenario gilt für einen allgemeinen Cluster, der keine direkte Speicherplätze aktiviert hat. 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 Zeuge

Die Stimme eines Knotens ist null, sodass die Mehrheit aus insgesamt 1 Stimmen bestimmt wird. Wenn der Knoten ohne Stimme unerwartet ausfällt, hat der Survivor 1/1, und der Cluster bleibt erhalten. Wenn der Abstimmungsknoten unerwartet ausfällt, hat der Survivor 0/1, und der Cluster fällt aus. Wenn der Abstimmungsknoten ordnungsgemäß heruntergefahren wird, wird die Abstimmung auf den anderen Knoten übertragen, und der Cluster bleibt erhalten. Deshalb ist es wichtig, einen Zeugen zu konfigurieren.

• Kann einen Serverausfall überleben: Fünfzig Prozent Chance.
• Kann einen Serverfehler überleben, dann eine andere: Nein.
• Kann zwei Serverfehler gleichzeitig überleben: Nein.

Zwei Knoten mit einem Zeugen

Beide Knoten stimmen und die Zeugenstimmen, sodass die Mehrheit aus insgesamt 3 Stimmen bestimmt wird. Wenn ein Knoten ausfällt, hat der Survivor 2/3, und der Cluster bleibt erhalten.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Nein.
• Kann zwei Serverfehler gleichzeitig überleben: Nein.

Drei Knoten ohne Zeugen

Alle Knoten stimmen, sodass die Mehrheit aus insgesamt 3 Stimmen bestimmt wird. Wenn ein Knoten ausfällt, haben die Survivor 2/3, und der Cluster bleibt erhalten. Der Cluster wird zu zwei Knoten ohne Zeuge – zu diesem Zeitpunkt befinden Sie sich in Szenario 1.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine weitere: Fünfzig Prozent Chance.
• Kann zwei Serverfehler gleichzeitig überleben: Nein.

Drei Knoten mit einem Zeugen

Alle Knoten stimmen ab, sodass der Zeuge anfangs nicht abstimmt. Die Mehrheit wird aus insgesamt 3 Stimmen bestimmt. Nach einem Fehler verfügt der Cluster über zwei Knoten mit einem Zeugen – zurück zu Szenario 2. Jetzt stimmen beiden Knoten und der Zeuge ab.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Ja.
• Kann zwei Serverfehler gleichzeitig überleben: Nein.

Vier Knoten ohne Zeugen

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

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Ja.
• Kann zwei Serverfehler gleichzeitig überleben: Fünfzig Prozent Chance.

Vier Knoten mit einem Zeugen

Alle Knoten geben ihre Stimmen ab und auch die Zeugen stimmen ab, sodass die Mehrheit aus insgesamt 5 Stimmen bestimmt wird. Nach einem Fehler befinden Sie sich in Szenario 4. Nach zwei gleichzeitigen Fehlern springen Sie zu Szenario 2.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Ja.
• Kann zwei Serverfehler gleichzeitig überleben: Ja.

Fünf Knoten und darüber hinaus

Alle Knoten oder alle Knoten bis auf einen stimmen ab (um eine ungerade Anzahl zu erhalten). Direkte Speicherplätze kann trotzdem nicht mehr als zwei ausgefallene Knoten behandeln, daher ist ein Zeuge zu diesem Zeitpunkt weder erforderlich noch hilfreich.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Ja.
• Kann zwei Serverfehler gleichzeitig überleben: Ja.

Nachdem wir nun verstehen, wie quorum funktioniert, sehen wir uns die Arten von Quorumzeugen an.

Quorumzeugentypen

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

• Cloud Witness – 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.
• Dateifreigabenzeuge: eine SMB-Dateifreigabe, die auf einem Dateiserver unter 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 in der verfügbaren Speichergruppe des Clusters. Dieser Datenträger ist hoch verfügbar und kann ein Failover zwischen Knoten ausführen. Sie enthält eine Kopie der Clusterdatenbank. Ein Datenträgerzeuge wird von „Direkte Speicherplätze“ nicht unterstützt.

Übersicht über das Poolquorum

Wir haben gerade über das Cluster quorum gesprochen, das auf Clusterebene arbeitet. Im Folgenden erfahren Sie mehr über das Poolquorum, das auf Poolebene gilt (d. h., der Pool bleibt erhalten, auch wenn Sie Knoten und Laufwerke verlieren). Speicherpools wurden sowohl in gruppierten als auch in nicht gruppierten Szenarien verwendet, weshalb sie über einen anderen Quorummechanismus verfügen.

In der folgenden Tabelle finden Sie eine Übersicht über die Ergebnisse des Pool quorums pro Szenario:

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

Funktionsweise des Quorums im Pool

Wenn Laufwerke fehlschlagen oder eine Teilmenge von Laufwerken den Kontakt mit einer anderen Teilmenge verliert, müssen Surviving-Laufwerke, die Metadaten hosten, überprüfen, ob sie die Mehrheit des Pools darstellen, um online zu bleiben. Wenn sie dies nicht überprüfen können, gehen sie offline. Der Pool ist die Entität, die offline wechselt oder online bleibt, je nachdem, ob er über genügend Datenträger für das Quorum verfügt (50% + 1). Die Clusterdatenbank kann die +1 sein, solange der Cluster selbst im Quorum ist.

Das Pool-Quorum funktioniert jedoch anders als das Cluster quorum auf folgende Weise:

• Der Pool wählt eine Teilmenge von Laufwerken pro Knoten aus, um Metadaten zu hosten.
• Der Pool verwendet die Clusterdatenbank, um Verknüpfungen 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 einem symmetrischen Layout

Jedes der 16 Laufwerke verfügt über eine Stimme, und Knoten 2 hat ebenfalls eine Stimme (da es sich um den Ressourcenbesitzer des Pools handelt). Die Mehrheit wird aus insgesamt 16 Stimmen bestimmt. Wenn Knoten 3 und 4 ausfallen, verfügt die verbleibende Teilmenge über 8 Laufwerke und den Poolressourcenbesitzer, also über 9/16 Stimmen. Der Pool überlebt also.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Ja.
• Kann zwei Serverfehler gleichzeitig überleben: 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 es sich um den Ressourcenbesitzer des Pools handelt). Die Mehrheit wird aus insgesamt 16 Stimmen bestimmt. Zuerst fällt Laufwerk 7 aus. Wenn Knoten 3 und 4 ausfallen, verfügt die verbleibende Teilmenge über 7 Laufwerke und den Poolressourcenbesitzer, also über 8/16 Stimmen. Der Pool hat also keine Mehrheit mehr und fällt aus.

• Kann einen Serverfehler überleben: Ja.
• Kann einen Serverfehler überleben, dann eine andere: Nein.
• Kann zwei Serverfehler gleichzeitig überleben: Nein.

Empfehlungen für das Poolquorum

• Stellen Sie sicher, dass jeder Knoten in Ihrem Cluster symmetrisch ist (jeder Knoten hat die gleiche Anzahl von Laufwerken)
• Aktivieren Sie die Drei-Wege-Spiegelung oder duale Parität, damit Sie zwei Knotenfehler tolerieren und die virtuellen Datenträger online halten können.
• 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 und werden daher offline genommen und sind nicht verfügbar. Es wird empfohlen, die Server zurückzubringen oder die Datenträger schnell zu ersetzen, um die größte Resilienz für alle Daten im Volume sicherzustellen.

Nächste Schritte

• Konfigurieren und Verwalten des Quorums
• Einrichten eines Clusterzeugen