Windows Server 2016 Hyper-V Cluster: VMs in bestimmter Reihenfolge starten

Die Konfiguration dieser simplen Start-Priorisierung erfolgt typischerweise über den Failovercluster-Manager im Kontext der virtuellen Maschine und bewirkt, dass zum Beispiel beim Failover der Domänen-Controller mit hoher Priorität vor dem Datenbank-Server mit mittlerer Priorität startet.

VM Start Order in Windows Server 2016 Failovercluster geht zusätzlich noch einen Schritt weiter im Umgang mit dem Startverhalten hochverfügbarer virtueller Maschinen. Es gewährleistet einen Start in definierter Reihe mit Abhängigkeiten, indem es auch die Vorgänge in der VM und das Verhalten des OS berücksichtigt.

VM Start Order im Überblick

Hinzu kommt in Server 2016 die Option, Gruppen aus hochver­fügbaren VMs zu bilden. Demnach lassen sich zusammen­gehörige Applikationen in Ebenen (Tiering) organisieren, und schließlich können dann Abhängigkeiten zwischen diesen Ebenen festgelegt werden.

Auch die Abhängigkeit einer Tier Group von bestimmten einzelnen VMs, beispielweise eines Infrastruktur-Servers, kann definiert werden. Komplexe Anwendungen, die auf unterschiedliche VMs verteilt und Infrastruktur­dienste benötigen, lassen sich somit granular in Gruppen mit Abhängigkeit organisieren.

Konfiguration über PowerShell

Aktuell dienen eine ganze Reihe von Funktionen der Konfiguration dieses Features im Hyper-V Cluster 2016. Mit dem Aufruf von

Get-Command *ClusterGroup*

gibt der Server auch die notwendigen Befehle hierzu preis.

In meinem Hyper-V-Labor besteht die Testkon­figuration aus zwei Cluster-Nodes mit drei hoch­verfügbaren virtuellen Maschinen. Auf den Host-Knoten und in den HA-VMs installiere ich Windows Server 2016. Die virtuellen Maschinen enthalten den Domänen-Controller, einen SQL Server sowie eine Applikations-VM.

Eine einfach definierte Aufgabe ist nun, die Infrastruktur­dienste vor dem Datenbank-Server und der Applikation zu booten. Das Balancing mittels Node Fairness habe ich in diesem Beispiel für den Verbund ausgeschaltet. Start ordering berücksichtigt jedoch VMs des kompletten Verbundes.

Sets erstellen und Mitglieder hinzufügen

Dieses Beispiel fügt die drei virtuellen Maschinen in Sets von Gruppen ein und zwischen diesen Sets konfiguriere ich dann die Abhängigkeiten in dieser Reihenfolge:

[Set Apps] ist abhängig vom [Set Databases] welches abhängig ist vom [Set Infrastructure].

Zuvor werden die Sets mit

New-ClusterGroupSet -Name Apps

erstellt und daraufhin die Mitglieder-VMs mit

Add-ClusterGroupToSet -Name Apps -Group HA-VM-03

hinzugefügt. Ein

Remove-ClusterGroupSet -Name Apps

entfernt die eingezogenen Ebenen bei Bedarf wieder. Wann der Auslöser für den Folgestart stattfindet, zum Beispiel wenn das OS gestartet ist, beeinflusst dann:

Set-ClusterGroupSet -Name Apps -ReadySetting OS_Heartbeat

Wurde ein Set mit dem PowerShell-Befehl erstellt, erkennt man, dass die geschweiften Klammern keine Inhalte zeigen. Sobald eine Gruppe aber Mitglieder enthält, erscheinen diese dann unter GroupNames. Abhängigkeiten (Dependencies) von anderen Sets lassen sich unter ProviderNames ausmachen.

Abhängigkeiten konfigurieren

Im Anschluss an die Erstellung logischer Sets und der Konfiguration von zugehörigen Mitgliedern definiere ich die Abhängig­keiten mit dem Befehl

Add-ClusterGroupSetDependency -Name Apps -ProviderSet Databases

Gibt es alleinstehende virtuelle Maschinen außerhalb von Sets, wird eine Abhängigkeit mit

Add-ClusterGroupDependency -Group HA-VM-03 -ProviderSet Databases

festgelegt. Diese separate VM kann eine Applikation sein, die zuvor gestartete Infrastruktur- und Datenbank­dienste benötigt.

Abschließend führe ich das Cmdlet Get-ClusterGroupSet aus, um zu verifizieren, dass alle VMs der richtigen Gruppe angehören und diese Gruppen die erforderlichen Abhängigkeiten aufweisen. Hier wird auch deutlich, dass für das Infrastruktur-Set die Abhängigkeit (in ProviderNames {}) fehlt, weil dieses den Kopf der Reihenfolge bildet.

In Reihenfolge starten

Die VM Start Order ist jetzt einsatzbereit und kann über den Failovercluster-Manager (FCM) einmal auf die Probe gestellt werden. Durch Ausführen von cluadmin.msc starte ich den FCM und stelle mich auf VM Nr. 3 mit der auszuführenden Applikation.

In ihrem Kontextmenü fährt der Befehl Starten nicht unmittelbar Nr. 3 hoch, sondern erwartungsgemäß zu Beginn VM Nr. 1 inklusive Active Directory mit DNS Infrastruktur­diensten, danach VM Nr. 2 mit der SQL Datenbank und erst dann die VM mit der Applikation. Da die StartupConfig hier mit online definiert wurde, wartet der Trigger nicht auf einen OS Heartbeat.