Failover-Cluster einrichten mit Windows Server 2012 R2

    Failover-Cluster mit Windows Server 2012 R2 Windows Server bietet ein Failover-Clustering, das bei Hardware­defekten oder auch nur bei einem erforderlichen Neustart eines Servers automa­tisch auf einen anderen Knoten umschaltet. Dieser folgen­de Artikel beschreibt die grundlegende Erstellung eines Failover-Clusters mit zwei Knoten und einer 1GB-LUN für das Quorum auf einem iSCSI-Target.

    Der Clusterverbund ist ein komplexes System, welches Planung und Vorbereitung braucht. Er besteht aus mindestens zwei physikalischen oder virtuellen Maschinen, Knoten genannt, welche zusammenarbeiten und über dedizierte Signale ("Heartbeat") ihren Zustand abfragen. Zusammengefasst, konfiguriert und verwaltet wird eine solche Konstellation von Windows Servern im Failovercluster-Manager, mittels PowerShell oder dem Virtual Machine Manager.

    Planung und Vorbereitung

    Ein Cluster unter Windows Server benötigt zertifizierte Hardware, um eine supportfähige Ausgangslage und den unterbrechungsfreien Betrieb zu gewährleisten. CPUs, RAM, Netzwerkadapter usw. sollten für jeden Knoten möglichst identisch sein. Zudem werden mehrere Netzwerkkarten für unterschiedliche Anforderungen integriert und konfiguriert.

    Eine dient für das LAN, gegebenenfalls eine weitere für die Anbindung an das zentrale Speichersystem, eine für die Live Migration virtueller Maschinen im Fall der Hochverfügbarkeit von Hyper-V, eine für den VM-Datenverkehr und eine für die Cluster-Kommunikation. Nach Best Practices sollen diese NICs redundant und im Team geplant werden, um einen Single Point of Failure zu vermeiden.

    Die Planungen für ein Windows-Cluster sollten noch folgende Punkte berücksichtigen:

    • Alle Mitglieder des Verbundes müssen der gleichen AD-Domäne angehören. Microsoft hat seit Windows Server 2012 die Abhängigkeit vom Active Directory reduziert, weil ein Cluster seitdem seine Services auch dann starten kann, wenn es keine Verbindung zu einem Domänen-Controller hat. In Windows Server 2016 wurden die Abhängigkeiten weiter reduziert.
    • Die Knoten werden für hochverfügbare Rollen, etwa bei Hyper-V, an ein zentrales Storage angebunden. Storage Spaces Direct des Server 2016 nutzt in einem hyper-converged Design sogar lokalen Speicher.
    • Auf allen Nodes ist ein identischer Update-Stand erforderlich.
    • Kommen Virenscanner zum Einsatz, ist es wichtig, Ausnahmen speziell für Cluster-Knoten zu definieren.
    • Bevor die Cluster-Bildung erfolgt, sollten die Knoten dem Cluster-Validierungsprozess standhalten und möglichst keine Fehler im Abschlussbericht in Bezug auf Hard- und Softwarekonfiguration aufweisen.
    • Zu Überlegungen, welches Cluster-Konzept später bei der Installation von Rollen eingesetzt wird, siehe: Hyper-V Failover-Cluster: Einsatzgebiete, aktiv/aktiv versus aktiv/passiv.

    Installation des Cluster-Features und Knotenvalidierung

    Nachdem alle Vorbereitungen getroffen wurden, muss auf allen Knoten das Feature Failoverclustering installiert werden. Dazu startet man über den Server Manager den Assistenten Rollen und Features hinzufügen und wählt die Server aus, die das Feature erhalten sollen.

    Das Hinzufügen des Features Failoverclustering im Server Manager ist auch für entfernte Server möglich.

    Nach der erfolgreichen Installation, die keinen Reboot erfordert, startet man über das Tools-Menü im Server Manager den Failovercluster-Manager, um die grundlegende Cluster-Konfiguration einzuleiten. Zuerst jedoch ist es wichtig die zukünftigen Knoten des Verbundes vom Validierungsassistenten anhand eines von Microsoft erstellten Katalogs prüfen zu lassen.

    Zu diesem Zweck startet man Konfiguration überprüfen über das Dashboard des Failovercluster-Managers oder führt alternativ das PowerShell-Cmdlet Test-Cluster <Serverknoten1>, <Serverknoten2> aus. Hierdurch werden Hard- und Software-Voraussetzungen, also Netzwerke, Speicher usw. auf Cluster-Tauglichkeit untersucht. Der abschließende Bericht dient auch im Supportfall als Grundlage und Voraussetzung für Microsoft.

    Prüfen der Hard- und Software auf Cluster-Tauglichkeit.

    Nach der abschließenden Ausführung von Bericht anzeigen werden die monierten Fehler behoben. Wenn man sich die detaillierten Informationen zu den Warnungen genauer ansieht, kann leichter beurteilt werden, ob Maßnahmen ergriffen werden müssen, um diese zu beseitigen. Sind alle Voraussetzungen erfüllt, ist es möglich nun mit aktivierter Checkbox und dem Klick auf Fertig stellen den Cluster zu formen.

    Abschließender Prüfbericht und Einleitung der Cluster-Erstellung.

    Cluster-Erstellung

    Im Anschluss an den erfolgreichen Validierungsprozess wird ein Cluster-Name und eine IP aus dem Segment LAN/Management-Netzwerk festgelegt. Mit Erstellung dieses Zugriffspunktes legt der Wizard im Active Directory ein virtuelles Computerobjekt (CNO) an und in der DNS Forward-Lookupzone einen Host-A-Eintrag.

    Cluster-Name und Erreichbarkeit aus dem LAN.

    Nach der Bestätigung wird der Cluster erstellt und automatisch die kleinste vorhandene LUN für das Quorum konfiguriert. Überprüfen sollte man im Failovercluster-Manager, ob der Datenträger richtig zugeordnet wurde, auch wird empfohlen diesen beispielsweise in Quorum oder Witness umzubenennen.

    Analog bietet PowerShell für diesen Vorgang das Cmdlet

    New-Cluster –Name LabCluster –Node Serverknoten1, Serverknoten2 –StaticAddress 192.168.1.35.

    LUN für das Cluster-Quorum

    Abschließend müssen die Netzwerke im Failovercluster-Manager überprüft, konfiguriert und gegebenenfalls umbenannt werden. Über die Eigenschaften des jeweiligen Netzwerkes lassen sich der Name und die Cluster-Verwendung einstellen. Die Netzwerkkommunikation für Cluster (Heartbeat) findet in meinem Lab über die dedizierte NIC ClusterCom statt, wichtig ist es zusätzliche Netzwerke für diese Aufgabe redundant zu bestimmen.

    Netzwerkübersicht im Failovercluster-Manager

    Bevor nun die Hochverfügbarkeitsrollen konfiguriert werden, zum Beispiel Hyper-V, ist ein Blick in die Cluster-Ereignisse empfehlenswert, um mögliche Fehler zu erkennen und zu beseitigen. Prüfen Sie auch im Punkt Knoten, ob alle konfigurierten Server den Status Aktiv besitzen.

    5 Kommentare

    Bild von Helmut Lasser
    20. Juli 2016 - 8:53

    Sie schreiben:
    Microsoft hat seit Windows Server 2012 die Abhängigkeit vom Active Directory reduziert, weil ein Cluster seitdem seine Services auch dann starten kann, wenn es keine Verbindung zu einem Domänen-Controller hat.

    Das heißt, man kann in einem Windows 2012 R2 Cluster alle Server einer Domäne virtualisieren, auch den DC und der Cluster startet dann auch, obwohl der DC noch nicht gestartet ist.
    Also nicht so wie bei einem 2008 R2 Cluster, wo man einen DC außerhalb des Clusters virtualisiert oder nativ brauchte.

    Können sie mir sagen, ob es egal ist wenn die beiden Clusternotes starten (sind zwei 2012R2, natürlich Domämnenmitglieder), der DC virtuallisiert sich im Cluster befinden, der natürlich erst nach den Clusternotes startet, ob das ein 2003, 2008 oder 2012 DC sein kann/muss?
    Grundsätzlich gehen alle Server im Cluster ja ab 2012R2, aber wie hoch die Active Directory-Domänen und -Gesamtstruktur der gesamten Domäne sein muss (eben 2003, 2008 oder 2012), habe ich bisher nirgens erfahren.

    Bild von Marcel Küppers
    20. Juli 2016 - 13:00

    Hallo Herr Lasser,
     
    Das heißt, man kann in einem Windows 2012 R2 Cluster alle Server einer Domäne virtualisieren, auch den DC und der Cluster startet dann auch, obwohl der DC noch nicht gestartet ist.
     
    Das sogenannte AD-less Cluster Bootstrapping erlaubt eine Vollvirtualisierung ohne physikalischen DC. Die Node inkl. Cluster-Service kann auch ohne online Verbindung zum AD starten und das Quorum bilden. Eine Mitgliedschaft der Knoten im AD wird aber weiter nötig sein.
     
    Oder man geht den Weg eines Detached Clusters mit Einschränkungen (Kerberos, Live migration). Windows Server 2016 (in etwa zwei Monaten verfügbar) wurde hier noch weiterentwickelt. Lesen Sie den o.g. Artikel dazu einmal durch.
     
    Empfehlenswert ist meistens erstmal eine Testumgebung aufzusetzen um diese Fragen nachstellen zu können, auch bekommt man so ein Gespür für seine Umgebung.
     
    Können sie mir sagen, ob es egal ist wenn die beiden Clusternotes starten (sind zwei 2012R2, natürlich Domämnenmitglieder), der DC virtuallisiert sich im Cluster befinden, der natürlich erst nach den Clusternodes startet, ob das ein 2003, 2008 oder 2012 DC sein kann/muss?
     
    Einen 2003 DC würde ich nicht mehr empfehlen auch aus Gründen des outdated Supports. 2012 brachte die VM-GenerationID.
    Ab hier sollte IMHO die sichere Basis für die vDC´s sein, Stichwort auch: USN rollback
     
    Viele Grüße, Marcel Küppers

    Bild von Helmut Lasser
    10. August 2016 - 15:51

    (Einen 2003 DC würde ich nicht mehr empfehlen auch aus Gründen des outdated Supports. 2012 brachte die VM-GenerationID, ab hier sollte IMHO die sichere Basis für die vDC´s sein, Stichwort auch: USN rollback)

    1. Frage:
    Das heißt also, ab einem Windows Server 2008 als DC sollte es funktionieren. Besser wäre aber ein Windows Server 2012 R2?

    2. Frage:
    In der alten 2008 Variante hatten wir zwei DC einen nativ außerhalb des Clusters (zum sicheren starten des Clusters) und einen virtuallisiert innerhalb des Clusters.
    Macht ein zweiter DC wenn alles virtuallisiert ist überhaupt noch Sinn?
    Sollte man nur mehr auf einen DC in der virtuellen Welt setzten oder sind zwei doch noch besser?

    Vielen Dank
    Mfg
    HL

    Bild von Marcel Küppers
    12. August 2016 - 8:45

    1. Frage: Das heißt also, ab einem Windows Server 2008 als DC sollte es funktionieren. Besser wäre aber ein Windows Server 2012 R2?

    Diese Frage sollte oben beantwortet sein.

    2. Frage:
    In der alten 2008 Variante hatten wir zwei DC einen nativ außerhalb des Clusters (zum sicheren starten des Clusters) und einen virtuallisiert innerhalb des Clusters.
    Macht ein zweiter DC wenn alles virtuallisiert ist überhaupt noch Sinn?
    Sollte man nur mehr auf einen DC in der virtuellen Welt setzten oder sind zwei doch noch besser?

    Diese Frage wurde auch oben beantwortet. Ein zweiter DC macht grundsätzlich natürlich Sinn, vor allem aus Gründen der Ausfallsicherheit beim AD. Mit 2012 (R2) ist eine Vollvirtualisierung möglich, somit könnte ein physikalischer ("nativer") DC entfallen.

    Ich hoffe das hilft weiter :)

    Bild von Helmut Lasser
    12. August 2016 - 9:19

    Ja, vielen Dank.
    MFG
    HL