Windows Server 2016: Cluster ohne AD in einer Workgroup erstellen

So muss seit der Version 2012 für die Hochver­fügbarkeit von virtuellen Maschinen beim Boot-Vorgang der Cluster-Knoten kein Domänen-Controller mehr erreichbar sein (Cluster Bootstapping). Damit löste Microsoft das Henne-Ei-Problem bei voll virtua­lisierten Umgebungen und Domänen-Controllern.

Windows Server 2012 R2 brachte dann zusätzlich die Möglichkeit, einen Detached Cluster für die wichtigsten Workloads zu formen, ohne dass man dafür Computer-Objekte im AD (Cluster Name Object, CNO und Virtual Computer Objects, VCO) anlegen musste. Für die Cluster-Knoten war die Mitgliedschaft in einer AD-Domäne aber weiterhin erforderlich.

Windows Server 2016 geht noch einen Schritt weiter und benötigt für die Bildung eines Clusters kein AD mehr. Nun ist es möglich, Cluster in Arbeitsgruppen (Workgroups) oder bei Knoten­mitgliedschaft über mehrere Domänen hinweg (Multi-domain Cluster) zu erstellen. Der Cluster-Netzwerkname (Administrative Access Point) wird auch hier nur über DNS registriert.

Gründe für eine AD-Unabhängigkeit

Welche Gründe für ein vom Active Directory unabhängiges Cluster gibt es aber nun? Folgende Einsatzszenarien lassen sich daraus ableiten:

• Die Möglichkeit zur Erstellung kleinerer Umgebungen (Beispiel: Außen­stellen)
• Eine Konfiguration in der DMZ
• Die Nichterreichbarkeit einer Kundendomäne
• Domäne aus Sicherheitsgründen nicht zugänglich
• Ein Azure Deployment mit IaaS-Maschinen fällt kleiner aus, da Domänen-VMs nicht benötigt werden
• AlwaysOn Availibility Groups (AG) über verschiedene Domänen und Workgroup Nodes

Unterstützte Workloads für unabhängige Cluster

Betrachten wir speziell die Hochver­fügbarkeit von virtuellen Maschinen mit Hyper-V, dann lässt sich erkennen, dass man die Unabhängigkeit vom Active Directory und dem Kerberos-Protokoll mit Funktionsverlusten bezahlen muss. Die folgende Tabelle enthält die unterstützten Workloads bei losgelösten Clustern und zeigt Einschränkungen im Betrieb:

Bereitstellen eines Clusters in einer Arbeitsgruppe

Die Knoten des unab­hän­gigen Ver­bundes werden Mit­glied in der gleichen Arbeits­gruppe, ein Domänen­beitritt ist wie bereits erwähnt nicht erfor­der­lich.

Über System­steuerung => System lassen sich diese Ein­stel­lungen wie ge­wohnt anpas­sen. Mein Labor-Cluster besteht aus zwei Knoten.

Es ist darauf zu achten, dass die Nodes ein DNS-Suf­fix mit ange­hängt be­kom­men, die­ses lässt sich über die Schalt­fläche Weitere konfi­gu­rieren.

Um den Cluster zu formen, er­hal­ten die Knoten das Feature Failover­clustering über den Server-Manager => Rollen und Features hinzufügen oder mit dem PowerShell-Befehl

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Zusätzlich erstelle ich am DNS-Server in der Forward-Lookup Zone zwei Host (A)-Einträge für die zukünftigen Cluster-Nodes. Die Netzwerk­konfiguration der Knoten muss natürlich dem DNS-Eintrag entsprechen.

Nachdem das Feature Failoverclustering auf den beiden Laborknoten installiert wurde, starte ich den Failovercluster-Manager und validiere den Verbund grundlegend auf Tauglichkeit (Konfiguration überprüfen).

Dabei fällt die Nichtzuge­hörigkeit zu einer Domäne sofort auf. Nachdem alle Warnungen und Fehler überprüft und korrigiert wurden, kann der Cluster mit Cluster erstellen konfiguriert werden. Beide Knoten werden mit aufgenommen und bereits über die GUI-Bestätigung lässt sich erkennen, dass die Registrierung nur über DNS erfolgt.

Der analoge PowerShell Befehl in diesem Beispiel lautet:

New-Cluster -Name DetachedCluster -Node IndeNode01, IndeNode02 -AdministrativeAccessPoint DNS

Ein

Get-Cluster | fl *

kann hier nach erfolgreicher Erstellung unteranderem die Methode für den Access Point anzeigen.