Tags: Hyper-V, Windows Server, Disaster Recovery, Cluster
In einem Hyper-V Cluster lassen sich hochverfügbare virtuelle Maschinen priorisieren, um bei einem Host-Ausfall mit anschließendem Failover die Startreihenfolge festzulegen. Eine solche Priorisierung kann das Verhalten der VMs aber auch im Wartungsfall beeinflussen.
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 beispielsweise Applikationen erst nach virtuellen Infrastruktur-Maschinen hochfahren.
Auswirkungen der VM-Priorisierung
Darüber hinaus gibt es einen Wert, welcher bei Ressourcenknappheit eines Hyper-V-Hosts bestimmte VMs im Fall des Failover erst einmal offline belässt. Die Priorisierung gilt aber nicht nur dem Startverhalten 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 hochverfügbarer Maschinen zusätzlich mitbestimmt. Diese berücksichtigt im Gegensatz zur Priorisierung auch ein Anschaltverhalten 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ätsstatus 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 Knotenversagen, 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) unterbrechungsfrei verschoben, zusätzlich spielt dabei eine Rolle, wieviel gleichzeitige 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)
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris.
Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions.
Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
Ähnliche Beiträge
- Virtuelle Maschine vollständig mit PowerShell erstellen (am Beispiel von Azure Stack HCI)
- Hochverfügbare VMs im Hyper-V-Cluster erstellen mit dem Windows Admin Center
- Updates für Server-Cluster mit Windows Admin Center installieren
- Hyper-V-Cluster erstellen mit dem Windows Admin Center
- Physische Windows-Server sichern mit Nakivo Backup & Replication v9
2 Kommentare
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.
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".