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

    VMs im Hyper-V Cluster priorisierenIn 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.

    Priorität von VMs im Failovercluster-Manager ändern

    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.

    Im Failovercluster-Manager erkennt man die Priorisierung der hochver­fügbaren Maschinen.

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

    Wert in
    PowerShell
    Priorität bei Failover, Knoten-Start, Knoten-Wartung (Node Drain)
    0 Kein automatischer Start
    1000 Niedrig
    2000 Mittel
    3000 Hoch

    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.

    Bei Ausfall des ersten Knotens erfolgt der Failover nach vorgegebener Priorisierung.

    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)

    2 Kommentare

    Bild von Christian Wimmer
    Christian Wimmer sagt:
    8. August 2016 - 12:50

    Da ist glaube ich ein Fehler drin.

    Auf einem 2012R2 Cluster werden auch VMs mit Prio niedrig, soweit möglich, bei Wartungsarbeiten bzw. bei Node Drain (Node Neustart) per Live Migration verschoben, nicht per Quick Migration. Da hat sich von 2012 auf 2012R2 Failover Cluster Level technisch was geändert.

    Bild von Marcel Küppers
    8. August 2016 - 13:14

    Genau, bei 2012R2 hat sich was geändert mit Blick auf LM/QM. Steht aber im letzten Abschnitt. Der Threshold wurde von 2000 auf 1000 per Default geändert. Unterhalb dieses Wertes wird "schnell migriert".