Tags: Azure, Windows Server 2016, Cluster
Um die Integrität eines Clusters fortwährend zu gewährleisten, kann man das Quorum des Verbundes online mit beeinflussen. Dabei wird auch eine Zeugenfreigabe oder ein Datenträgerzeuge eingebunden. Server 2016 erlaubt es, für diese Aufgabe alternativ Azure als Zeugen zu konfigurieren.
Ein Cluster-Verbund wird bei einem Fehler beispielsweise eines Knotens solange aufrechterhalten, als die verbliebenen Knoten ggf. samt Zeugen die Mehrheit der Stimmen im Quorum besitzen. Das bewahrt den Verbund speziell auch vor dem Auseinanderdriften ("Split Brain"), bei dem alle Knoten für sich intakt sind, ihre Kommunikation untereinander jedoch gestört sein kann (siehe dazu: Quorum für Hyper-V Failover-Cluster konfigurieren).
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 Mehrheitsentscheidung. 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 Beispielkonfiguration 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 Zugriffsschlü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 => Clusterquorumeinstellungen 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 Authentifizierungsdaten abgefragt. Aus dem Azure-Portal und den Informationen des Speicherkontos 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 Zusammenfassung 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris.
Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions.
Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
Verwandte Beiträge
- Azure Stack HCI Single-Node-Cluster installieren
- Microsoft stellt Server Management Tools ein, arbeitet an Nachfolger für RSAT
- Anleitung: Storage Spaces Direct auf Cluster mit zwei Knoten einrichten
- Überblick: Windows Server 2016 Storage Spaces Direct im 2-Node-Cluster
- Backup und Monitoring: Veeam gibt die Availability Suite 9.5 frei
Weitere Links