Categories
Allgemein

Start-Reihenfolge von VMs unter Hyper-V: PowerShell to the rescue!

Wer heutzutage eine IT-Infrastruktur in den eigenen Räumlichkeiten (on-premises) betreibt, wird in den meisten Fällen auf die Virtualisierung setzen. Wenn wir hierbei auf das Microsoft-Produktportfolio blicken, lockt die Virtualisierung mit Hyper-V-Technologie. In vielen Fällen werden dann zur Erhöhung von Redundanz und Verwaltbarkeit Windows Failover Cluster mit Hyper-V eingesetzt.

Bei der Konkurrenz ist zum Beispiel VMware vSphere mit ESXi als Virtualisierer weit verbreitet – ebenfalls meist hochverfügbar ausgelegt (High Availability, HA).

Beim Betrieb von virtuellen Maschinen (VMs) besteht in der Betriebspraxis oftmals ein Interesse daran, Kontrolle darüber zu haben, in welcher Reihenfolge VMs starten (oder „failovern“). Weil es eben oft Abhängigkeiten der VMs untereinander gibt: Die Funktion eines SQL-Datenbank-Servers zum Beispiel hängt von einem betriebsbereiten Domain Controller (DC) ab. Ein Applikationsserver mag wiederum von SQL-Servern abhängen.

Unter Hyper-V gibt es in der grafischen Verwaltungsoberfläche (Failover Cluster Manager, FCM bzw. Hyper-V Manager) ein paar Möglichkeiten, Einfluss auf den Start von VMs bzw. im Falle eines Failovers auf einen anderen Knoten (Node) im Cluster zu nehmen.

Diese „Start Priority“ bietet aber in der GUI nur recht wenige Optionen zur Ausgestaltung. Entweder stuft man die Start-Prio der VM als High, Medium oder Low ein oder man verzichtet auf den automatischen Start der VM gänzlich. Über die PowerShell kann man zwar hier die Abstufung der Priorität auch granularer wählen – aber welche VMs nun Voraussetzung für den erfolgreichen Betrieb anderer VMs sind, lässt sich auch damit bei mehr als einer Hand voll VMs kaum sinnvoll regeln.

Bei der VMware-Konkurrenz bieten sich in der entsprechenden GUI (vCenter) da mehr Möglichkeiten, um auch Abhängigkeiten von VMs untereinander zu modellieren.

Selbst in den neueren Versionen des Windows Servers bleiben den Administratoren in der GUI solcherlei weitergehende Eingriffsmöglichkeiten verwehrt. Und neidisch schielt man auf die Konkurrenz. Es gibt aber durchaus eine – u. a. durch Nicht-Sichtbarkeit in der GUI wenig beachtete – Möglichkeit, hier präzisere Stellschrauben zu benutzen: Schon seit Windows Server 2016 gibt die PowerShell da ein logisches Konstrukt her, mit dem man dem Hyper-V-Cluster in Bezug auf diese Modellierung auf die Sprünge helfen kann. Das Stichwort heißt hier: ClusterGroupSet.

Die Dokumentation dazu ist dürftig, die Logik etwas sperrig und die Nomenklatur eigenwillig. Wenn man die vor allem zu Beginn so störenden Hürden aber überwindet, hat man durchaus ein nützliches Werkzeug an der Hand.

Wie funktioniert das also nun? Die Idee basiert auf den ClusterGroupSets und der ClusterGroupSetDependency. Im Kommandozeilen-Cluster-Sprech sind VMs (bzw. das, was VMs im Cluster ausmacht) eigentlich ClusterGroups. Da hier der Begriff der Group im Cluster also schon reserviert ist, heißen die Gruppierungen, die wir hier und jetzt betrachten eben ClusterGroupSets. Diese Sets beinhalten die ClusterGroups (die VMs) als Mitglieder. So gesehen steckt man nun also VMs in diese Sets. Mit den zugehörigen Dependencies lassen sich nun die Abhängigkeiten abbilden. Dazu gibt man bei der ClusterGroupSetDependency für ein ClusterGroupSet einen „Provider“ an. Mit Provider ist hier konkret dasjenige ClusterGroupSet gemeint, von dem das mittels Provider konfigurierte nun denn abhängen soll. Am besten ein Beispiel: Sieben VMs, nämlich drei DCs (DC01 bis DC03), zwei SQL-Server (SQL01, SQL02), zwei AppServer (AppSrv01 und AppSrv02). Die beiden App-Server hängen von den SQL-Server-VMs ab und diese wiederum von mindestens zwei der drei DC-VMs.

Im Bild die zugehörigen PowerShell-Befehle:

Wir erstellen zuerst die „Gruppierungen“, also die ClusterGroupSets, wie zum Beispiel die DomainControllers. Dann stecken wir die VMs, repräsentiert durch die „Group“, in das jeweils passende Set hinein.

Zuletzt geben wir an, dass das Set für die AppServers von dem Set für die SQLServers abhängt und dieses wiederum von den DomainControllers. Die Abhängigkeiten und die logische Verschachtelung sind damit gebaut.

Nun noch ein paar Details: StartupDelayTrigger und StartupCount. Die Option „Delay“ beim Trigger bedeutet, dass auf den Heartbeat gewartet wird – und dann erst die Zeit für den Delay (StartupDelay) zum Start abhängiger Sets losläuft. Die Option „online“ beim Trigger bedeutet, dass es bereits dann weitergehen darf, wenn die VM-Rollen überhaupt erfolgreich gestartet wurden, aber ebenfalls erst nach Ablauf eines StartupDelay.  Beim ein oder anderen mag das nicht dem ersten Instinkt zur Bedeutung der Optionen entsprechen.
Die Anzahl beim StartupCount gibt für das Set an, wie viele der enthaltenen VMs zur Erfüllung der Regeln laufen müssen.

Hier im Beispiel also sollen zwei der drei DCs laufen, um als ausreichend vollständig laufendes Set zu gelten. Es empfiehlt sich, zumindest für das letzte Set in der Kette der Abhängigkeiten diesen Wert auf die Anzahl der enthaltenen VMs zu setzen, um das recht eigenwillige Verhalten beim Starten der zweiten AppServers-VM zu vermeiden. Die genaue Logik dahinter wird bestimmt wohlbegründbar sein, scheint aber wohl anfangs schwer zu durchschauen.

Für eigene Tests sei empfohlen, auf dem Beispiel aufzubauen.

Nun das Resultat im einfachsten Szenario also im Bild: Wenn alles ausgeschaltet ist und wir schalten über den FCM eine der AppServers-VMs (z. B. AppSrv01) ein, dann startet diese zunächst nicht direkt, sondern wirft zuerst das Set am Ende der Abhängigkeitskette mit den DCs an. Noch laufen ja nicht ausreichend viele.  Da das ganze Set gestartet wird, werden kurz danach im Allgemeinen also drei DCs laufen. Das sind genug zur Erfüllung der Regeln für dieses Set. Dann starten, nach einem (einstellbaren) Verzug von 20 Sekunden (so der Default für den StartupDelay) auch die SQL-Server-VMs. Wenn beide laufen, darf dann auch der AppSrv01 wirklich starten… so soll es sein.

Fazit:

Microsoft sorgt durch Weglassen eines GUI-Zugriffs und bestenfalls mäßige Dokumentation durchaus selbst dafür, dass die ClusterGroupSets weniger bekannt oder in Vergessenheit geraten sind. Ob das Zeichen für technische Schwierigkeiten MS-seitig bei der Umsetzung sind oder man gar überhaupt auf das Feature setzen sollte, mag sicherlich kontrovers diskutiert werden. Wer auf eine genauere Regelung der Startreihenfolge von VMs im Cluster Wert legt, sollte sich aber ruhig einmal mit den Möglichkeiten rund um dieses Feature durch Testing beschäftigen und entscheiden, ob dies zur produktiven Nutzung in der eigenen Hyper-V-Welt in Frage kommt.

Wer das zum Einsatz vorsieht, sollte aber über etwas Frustrationstoleranz verfügen und die Admin-Kollegen mit einbeziehen: Wenn man VMs im Cluster starten möchte, und stattdessen starten andere (nur manchmal genau diejenige nicht, die man wollte), rauft man sich schnell die Haare, wenn man so gar nicht ahnt, wo das Verhalten herkommt.

Viel Erfolg bei eigenen Experimenten!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

nach oben