Failover-Cluster in Windows Server 2016: Azure als Quorum-Zeuge

Windows Server 2012 R2 brachte unter anderem zusätzliche Dynamik in das Quorum-Modell und erreichte durch automatische Stimmenzuteilung für Datenträger- oder Freigabezeugen eine Mehrheits­entscheidung. Daraus resultiert die Empfehlung, grundsätzlich einen Zeugen einzubinden, da der Cluster automatisch entscheidet, ob der Zeuge eine Stimme im Quorum erhält oder nicht.

Wann macht der Cloud-Zeuge einen Sinn?

In Windows Server 2016 kommt die Option hinzu, die Azure-Cloud als Zeugen (Witness) im Failovercluster-Manager zu ernennen. Ein solcher Cloud-Zeuge erweist sich vor allem bei Stretched Clustern über zwei Standorte, Gebäude oder Räume als nützlich. Hier hilft er dabei, einen dritten Standort einzusparen, wenn dieser nur dazu dienen würde, einen Witness zu implementieren.

Eine Beispiel­konfiguration könnte in diesem Fall aus drei Knoten an Standort A und drei an Standort B bestehen. Bei dieser Konstellation wäre ein dritter Rechnerraum nötig, um eine Zeugenstimme zu ermöglichen. Somit würde beim Ausfall eines Standortes dem daraus resultierenden Abschalten des anderen vorgebeugt (3 + 3 + 1 Stimmen = 7; Standort mit 3 Stimmen darf ausfallen, da 4 Stimmen die Mehrheit bilden, siehe auch Abb.).

Desweiteren ist es bei einem Workgroup oder Multi-Domain Cluster nur möglich einen Cloud- oder Datenträgerzeugen einzubeziehen, der Freigabezeuge wird hier aktuell nicht unterstützt. Dies erlaubt auch kleinere Cluster-Konfigurationen inklusive Cloud Witness, beispielsweise in Zweigstellen.

Ein Azure-Speicherkonto als Basis

Grundsätzlich wird für die Formung eines Clusters mit Zeuge in der Cloud ein Azure-Account samt Speicherkonto benötigt. Ein solches lässt sich über das Azure Portal => Neu => Daten und Speicher => Speicherkonto anlegen. Die nötigen Zugriffs­schlüssel zur Authentifizierung von der On-Prem-Site aus werden anschließend über dieses Speicherkonto ausgegeben.

Cloud-Zeugen über den Failovercluster-Manager bestimmen

Um die Quorum-Konfiguration zu modifizieren, stelle ich mich im Failovercluster-Manager auf den Cluster-Namen und erreiche mit der rechten Maustaste dann das Kontextmenü. Über weitere Aktionen => Cluster­quorum­einstellungen konfigurieren öffnet sich der Wizard für die Quorum-Anpassung.

Nachdem ich die Vorbemerkungen zur Kenntnis genommen habe, setze ich den Radiobutton auf Quorumzeugen auswählen. Im Unterschied zu Windows Server 2012 (R2) erscheint hier anschließend zusätzlich die Möglichkeit, einen Cloud-Zeugen zu konfigurieren.

Wählt man diese Option, dann werden danach die oben angesprochenen Authenti­fizierungs­daten abgefragt. Aus dem Azure-Portal und den Informationen des Speicher­kontos lassen sich hier der Name des Kontos und der Schlüssel einsetzen. Der Azure-Dienstendpunkt muss für diese Lokation nicht angepasst werden.

Wird der Dialog mit Weiter bestätigt, zeigt sich nach einer Zusammen­fassung samt Bericht der Status des Cloud-Zeugen im Dashboard des Failovercluster-Managers.

Ein analoges Setup mittels PowerShell sieht wie folgt aus:

Set-ClusterQuorum –CloudWitness –AccountName mkcasestudy –AccessKey cAFLGxxxxxxxxxHSBOw==

Werfen wir jetzt einen Blick in das Azure Portal unterhalb der Blob Dienste des Speicherkontos, dann lässt sich ein Container namens msft-cloud-witness inklusive einer Blob-Datei mit der eindeutigen ID unseres Clusters ausmachen. Die Ausgabe der ID über das Cmdlet

(Get-Cluster).ID

im eigenen Rechenzentrum sollte hier eine Übereinstimmung zeigen. Es ist demzufolge möglich, mehrere Cluster samt Cloud-Zeugen unterhalb eines Speicherkontos anzusiedeln.