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


    Tags: , ,

    Azure als Cloud-Witness für Cluster von Windows Server 2016Um die Inte­grität eines Clusters fort­während zu gewähr­leisten, kann man das Quorum des Verbundes online mit beeinflussen. Dabei wird auch eine Zeugen­freigabe oder ein Daten­träger­zeuge einge­bunden. Server 2016 erlaubt es, für diese Aufgabe alter­nativ 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 Auseinander­driften ("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 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.).

    Durch einen Zeugen in der Cloud wird die unnötige Abschaltung eines Standorts in einem Stretched Cluster verhindert.

    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.

    Voraussetzung für den Cloud-Zeugen ist ein Azure-Speicherkonto.

    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.

    Über den Failovercluster-Manager erreicht man die Quorum-Konfiguration.

    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.

    Einfügen des Azure-Schlüssels zur Authentifizierung

    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==

    Das Dashboard des Failovercluster-Manager zeigt den Status des Cloud-Zeugen.

    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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Marcel Küppers

    Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infra­structure Architect unter anderem für den japani­schen Konzern JTEKT/TOYODA mit Verant­wortung über die Europa­standorte Krefeld und Paris. Da­rüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Loka­tionen des Kon­zerns mit und ist spezia­lisiert auf hoch­verfügbare virtuali­sierte 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.
    // Kontakt: E-Mail, Twitter, LinkedIn //

    Ähnliche Beiträge

    Weitere Links