Grundlegendes zum Cluster- und Poolquorum
Gilt für: Azure Stack HCI, Versionen 22H2 und 21H2; Windows Server 2022, Windows Server
Wichtig
Azure Stack HCI ist jetzt Teil von Azure Local. Die Umbenennung der Produktdokumentation wird ausgeführt. Ältere Versionen von Azure Stack HCI, z. B. 22H2, verweisen jedoch weiterhin auf Azure Stack HCI und spiegeln die Namensänderung nicht wider. Weitere Informationen
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 mit dem Konzept des Quorums des Failoverclusterings verhindert, das nur eine dieser Knotengruppen 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 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 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 | Nr. | Nein |
| 3 | Ja | 50/50 | Nein |
| 3 + Zeuge | Ja | Ja | Nein |
| 4 | Ja | Ja | 50/50 |
| 4 + Zeuge | Ja | Ja | Ja |
| 5 und mehr | Ja | Ja | 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:
- 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.
- 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 die Ü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 Stimmenzahl gibt, hat der Zeuge eine Stimme. Der dynamische Zeuge reduziert das Risiko, dass der Cluster aufgrund eines Zeugenfehlers heruntergeht. 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.
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. 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, 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.
- Ü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.
- Ü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.
- Ü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.
- Ü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.
- Ü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.
- Ü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. Speicherplätze Direct kann trotzdem nicht mehr als zwei Knoten nach unten verarbeiten, daher ist an diesem Punkt kein Zeugen erforderlich oder nützlich.
- Ü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 "Verfügbarer Clusterspeicher" 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 | Nr. | Nein |
| 2 + Zeuge | Ja | Nr. | Nein |
| 3 | Ja | Nr. | Nein |
| 3 + Zeuge | Ja | Nr. | Nein |
| 4 | Ja | Nr. | Nein |
| 4 + Zeuge | Ja | Ja | Ja |
| 5 und mehr | Ja | Ja | Ja |
Funktionsweise des Poolquorums
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. 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 die +1 sein, solange der Cluster selbst quorate ist.
Das Poolquorum funktioniert jedoch anders als das Clusterquorum:
- 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 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.
- Ü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.
- Ü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 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 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ößte Resilienz für alle Daten im Volume sicherzustellen.