Windows Server Hyper-V Cluster: Priorität hochverfügbarer VMs

In einem Hyper-V Cluster lassen sich hoch­verfügbare virtuelle Maschinen priori­sieren, um bei einem Host-Ausfall mit an­schließendem Fail­over die Start­reihen­folge festzu­legen. Eine solche Priori­sierung kann das Ver­halten der VMs aber auch im Wartungs­fall beein­flussen.

Seit Windows Server 2012 gibt es Schalter, um hochverfügbare VMs auf einem Hyper-V Host zu priorisieren und deren Startverhalten speziell beim Failover zu beeinflussen. Somit können bestimmte Szenarien gestaltet werden, in denen beispiels­weise Applikationen erst nach virtuellen Infrastruktur-Maschinen hochfahren.

Auswirkungen der VM-Priorisierung

Darüber hinaus gibt es einen Wert, welcher bei Ressourcen­knappheit eines Hyper-V-Hosts bestimmte VMs im Fall des Failover erst einmal offline belässt. Die Priorisierung gilt aber nicht nur dem Start­verhalten beim Failover, sondern kann generell auf den Transfer von virtuellen Maschinen zwischen Hosts einwirken.

Ein konfigurierbarer Schwellenwert bestimmt dann, ob Maschinen live migriert oder weniger wichtige VMs per Quick Migration (Schnellmigration) verschoben werden. Auf diese Weise verbleibt im Netzwerk genügend Kapazität für die Live Migration wichtiger Maschinen. Im Fall der Knotenwartung (Draining), wenn VMs evakuiert werden müssen, wirkt sich der Prioritätswert daher ebenfalls aus.

Auch bei Aktivierung und Konfiguration dynamischen Arbeitsspeichers, starten hoch priorisierte Maschinen bevorzugt und niedrig priorisierte werden bei fehlenden Ressourcen in den gespeicherten Zustand versetzt.

Als Hinweis abseits von Failover-Szenarien sei erwähnt, dass in Windows Server 2016 die VM Start Order eine generelle Startsequenz hochver­fügbarer Maschinen zusätzlich mitbestimmt. Diese berück­sichtigt im Gegensatz zur Priorisierung auch ein Anschalt­verhalten basierend auf einem Delay oder mit Blick in die VM und dem Gast-OS.

Festlegen der Priorität von virtuellen Maschinen

Prioritäten lassen sich über den Failovercluster-Manager (FCM) oder in PowerShell definieren.

Die Werte für hochverfügbare virtuelle Maschinen können hier bei Niedrig, Mittel, Hoch oder Kein automatischer Start liegen und werden im Kontextmenü der VM festgelegt. Der Standardwert ist Mittel und ein entsprechender PowerShell-Wert dann 2000.

Analog zum FCM würde mit dem PowerShell Befehl

(Get-ClusterGroup HA-VM-01).Priority=3000

eine hohe Priorität erzielt.

Folgende Tabelle übersetzt den Prioritäts­status in den entsprechenden PowerShell-Wert:

Um sich eine Übersicht der konfigurierten Prioritätswerte für Cluster-VMs zu verschaffen, gibt man folgendes PowerShell-Kommando ein:

Get-ClusterGroup | Where {$_.GroupType -eq "VirtualMachine"} | Select Name, Priority

Auswirkungen nach dem Failover

Im Labor simuliere ich ein Knoten­versagen, indem ich die Maschine "hart" abschalte und danach in der Lage bin, das Resultat zu analysieren. Virtuelle Maschinen eines Windows Server 2016 Clusters gelangen erst in den Status Nicht überwacht, resultierend aus VM Compute Resiliency und werden nach einer definierten Zeit übernommen.

Aufgrund der festgelegten Prioritäten erfolgt die Anschaltung in der Reihenfolge von Hoch (3000) bis absteigend nach Niedrig (1000). Zuerst starten die VMs mit hoher Priorität, welche zum Beispiel das Active Directory inklusive DNS enthalten, und darauf folgend die Maschinen mit mittlerer Priorität. Diese führen eventuell Exchange oder SQL Server aus. In meinem Beispiel bleibt die VM mit definiertem Kein automatischer Start (0) erwartungsgemäß offline.

Wirkung bei Knotenwartung

Über das Kontextmenü der Knoten in einem Hyper-V Cluster ist es möglich, diese mit Anhalten => Rollen ausgleichen in einen Wartungszustand zu versetzen. Beim Node Draining werden dann die VMs vorzugsweise per Live Migration (LM) unter­brechungs­frei verschoben, zusätzlich spielt dabei eine Rolle, wieviel gleich­zeitige LMs maximal zugelassen wurden.

Vorzugsweise bedeutet dann, dass hier ebenfalls die Priorisierung eine Rolle spielt und bei Windows Server 2012 ein Schwellenwert ab 2000 (Mittel) virtuelle Maschinen live migrieren lässt. Der Wert unter Windows Server 2012 (R2) oder 2016 ist hier per Default bei 1000 (Niedrig).

Alles darunter wird demnach durch eine Quick Migration erst in den gespeicherten Zustand versetzt, um die VM anschließend mit Unterbrechung der Dienste zu verschieben. Der angesprochene Schwellenwert kann durch das PowerShell Kommando

Get-ClusterResourceType "Virtual Machine" | Get-ClusterParameter MoveTypeThreshold

überprüft und mit folgendem Befehl dann angepasst werden:

Get-ClusterResourceType "Virtual Machine" |
Set-ClusterParameter @(MoveTypeThreshold=1000)