Tags: Hochverfügbarkeit, Windows Server 2012 R2, Cluster
Windows Server bietet ein Failover-Clustering, das bei Hardwaredefekten oder auch nur bei einem erforderlichen Neustart eines Servers automatisch auf einen anderen Knoten umschaltet. Dieser folgende 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.
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.
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.
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.
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.
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.
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.
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
- Anleitung: Hyper-V-Cluster einrichten und VMs hochverfügbar machen
- Failover-Cluster: Windows Server 2012 R2 als hochverfügbares iSCSI Target
- Hochverfügbare File-Shares in Windows Server 2022 einrichten
- VMs bei Absturz des Gast-OS über vSphere HA Application Monitoring neu starten
- VMware vSphere DRS: Affinitätsregeln
Weitere Links
5 Kommentare
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.
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 physischen 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
(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
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 physischer ("nativer") DC entfallen.Ich hoffe das hilft weiter :)
Ja, vielen Dank.
MFG
HL