Quorum für Hyper-V Failover-Cluster konfigurieren

Bei Erstellung eines 2-Knoten-Clusters wird empfohlen, einen gemeinsamen Speicherbereich auf einem zentralen Storage für das Quorum zu schaffen. Ausreichend ist hier eine 1GB LUN, auf die beide Knoten Zugriff erhalten müssen. Windows Server 2012 (R2) erkennt bei der Einrichtung eines Failover-Clusters automatisch diese LUN und konfiguriert sie für das Quorum.

Außerdem wird daraus ein Zeugendatenträger (Disk Witness), der wie die Knoten im Cluster eine Stimme für das Quorum erhalten kann. Statt eines möglichen Zeugendatenträgers gibt es auch die Option, eine Zeugenfreigabe auf einem Server außerhalb des Clusters einzurichten. Ein Vorteil des Datenträgerzeugen ist auch, dass dieser im Unterschied zur Freigabe eine Kopie der Clusterdatenbank speichert.

Bei dieser Ausgangslage erhalten die beiden Knoten und der Zeugendatenträger je eine Stimme, also insgesamt drei Stimmen im Quorum. Angenommen, nun fällt der Cluster-Interconnect (Heartbeat; TCP/UDP 3343) aus und die Knoten können sich nicht mehr gegenseitig erreichen, um sich abzustimmen.

Jeder Knoten ist aber weiter intakt und nimmt Client-Anfragen entgegen. In diesem aufgespaltenen Zustand kann es leicht zum Auseinanderdriften der Daten kommen, die Integrität wäre gefährdet.

Da in diesem Fall der Zeugendatenträger Informationen über die Cluster-Knoten hat, wird dieser mit jeder einzelnen Stimme der Server-Knoten entscheiden, welcher Teil am Leben bleiben darf. Der Datenträgerzeuge plus ein Knoten halten zwei Stimmen, und das ist die Mehrheit, um den Cluster mit einem Knoten fortbestehen zu lassen. Bei gestörtem Heartbeat deuten auch Events mit der ID 1135 auf dieses Problem hin.

Der Cluster-Quorum-Modus

Im Beispiel-Cluster hat Windows Server 2012 (R2) automatisch den sinnvollsten Modus für uns gewählt, in diesem Fall den Typ Knoten- und Datenträgermehrheit. Werden Knoten hinzugefügt oder entfernt, geschieht diese Auswahl dynamisch. Es ist jedoch möglich, die Einstellung im laufenden Betrieb über das Kontextmenü des Failoverclusters und dann Weitere Aktionen => Clusterquorumeinstellungen konfigurieren manuell anzupassen.

Mit dem PowerShell Cmdlet Get-ClusterQuorum |fl lässt sich feststellen, welcher Quorumtyp aktiv genutzt wird. Dabei unterscheidet man folgende Quorumtypen:

Knotenmehrheit (Node Majority)

Für einen Cluster mit ungerader Anzahl an Knoten wird dieser Typ automatisch gewählt. Bei einem 3-Knoten-Cluster darf ein Knoten ausfallen, um weiter die Mehrheit der Stimmen zu behalten. Bei diesem Quorumtyp wird ein Zeugendatenträger oder Zeugenfreigabe nicht verwendet.

Knoten- und Datenträgermehrheit (Node and Disk Majority)

Bei einer geraden Anzahl von Cluster-Knoten und einer gemeinsamen LUN als Zeugendatenträger wird dieser Quorumtyp automatisch gewählt. Die Knoten und der Zeugendatenträger haben je eine Stimme. Wird beispielsweise ein 4-Knoten Cluster konfiguriert, ist die Gesamtstimmen­anzahl somit fünf und in diesem Fall dürfen zwei Knoten ausfallen, um weiter die Stimmen­mehrheit für die Cluster-Fortführung zu behalten.

Das entsprechende PowerShell Cmdlet lautet:

Set-ClusterQuorum -NodeAndDiskMajority "Shared LUN for Quorum"

Knoten- und Dateifreigabemehrheit (Node and File Share Majority)

Dieser Quorumtyp verhält sich ähnlich wie die Knoten- und Datenträgermehrheit mit der Ausnahme, dass es sich nicht um eine gemeinsame LUN, sondern um eine Dateifreigabe handelt.

Ein praktisches Beispiel für die Verwendung einer Freigabe ist ein Multi-Site-Cluster. Ein Standort hält einen Teil der Knoten und ein zweiter den anderen und der dritte dann die für beide erreichbare Zeugenfreigabe. Hinweis: Die Zeugenfreigabe enthält keine Kopie der Clusterdatenbank.

Das Computerobjekt des Clusters muss Schreibberechtigungen für die Freigabe besitzen, sonst läuft man in den Fehler beim Ändern der Quorumeinstellungen. […] Fehler beim Konfigurieren des Dateifreigabezeugen […] Zugriff verweigert.

Im Fall der Freigabe lautet das PowerShell Cmdlet:

Set-ClusterQuorum -NodeAndFileShareMajority "\\fileshare\foldername"

Keine Mehrheit, nur Datenträger (No Majority: Disk Only)

In diesem Fall erhalten die Knoten keine Votes und nur der Datenträgerzeuge erhält eine Stimme. Somit verliert der Cluster-Verbund seine Integrität, wenn diese Stimme ausfällt. Es dürfen bei diesem Quorumtyp alle Knoten bis auf einen ausfallen, solange der Datenträgerzeuge weiter online ist. Dieser Modus muss manuell konfiguriert werden.

Mehr Dynamik seit Windows Server 2012

Durch Dynamic Quorum seit Windows Server 2012 wird der Cluster-Verbund noch belastbarer in Bezug auf ein Voting für das Quorum und gegen das Abschalten. Wurde ein Cluster-Knoten beispielsweise zu Wartungszwecken aus dem Verbund genommen, wird automatisch auch seine Stimme dem Verbund entzogen. Kommt er wieder zurück, votet er auch erneut für das Quorum (siehe Grafik weit oben, Spalte: Aktuelles Votum). Demnach verändern sich dynamisch immer wieder die nötigen Mehrheitsstimmen für den Fortbestand des Clusters. Das kann soweit gehen, bis nur noch ein Knoten übrig bleibt (Last man standing). Ob diese Dynamik aktiv ist, lässt sich mit folgendem PowerShell Cmdlet abfragen:

(Get-Cluster).DynamicQuorum

Und abschalten, wenn nötig, mit:

(Get-Cluster).DynamicQuorum = 0

Windows Server 2012 R2 bringt noch mehr Flexibilität in das Quorum-Modell und verleiht dem Zeugen zusätzlich eine dynamische Stimme. Bei gerader Anzahl der Knotenstimmen erhält er eine Stimme, um ein ungerades Voting zu erreichen. Bei ungerader Knotenanzahl dagegen wird dem Zeugen die Stimme entzogen.

Daraus resultierend lautet die Empfehlung für die Version R2, bei jeder Cluster-Konfiguration einen Zeugen mit einzubinden. 

Ob der Zeuge aktuell eine Stimme hält, darüber gibt der PowerShell-Aufruf

(Get-Cluster).WitnessDynamicWeight

Auskunft.

Azure als Zeuge seit Windows Server 2016

Neben dem Disk- und File Share Witness ist es mit Windows Server 2016 nun auch möglich, ein Azure Speicherkonto als Cloud-Zeugen zu etablieren. Das macht vor allem dann Sinn, wenn ein Disk-Zeuge nicht möglich ist oder ein File Share-Zeuge beispielsweise zu hohe Wartungskosten an einem separaten Standort verursacht. Der Cloud-Zeuge ist hochverfügbar und kostengünstig. Alles weitere dazu im Beitrag: Failover-Cluster in Windows Server 2016: Azure als Quorum-Zeuge.