Live Migration: VMs im Hyper-V-Cluster auf andere Hosts verschieben

Die Migration von VMs im laufenden Betrieb funktioniert in einer Cluster-Umgebung mit Shared Storage und seit Windows Server 2012 auch zwischen Standalone-Hosts als Shared Nothing Live Migration. Mit der Version 2012 R2 kamen außerdem Features zur Verbesserung der Leistung bei TCP/IP-Verbindungen hinzu, wie beispielsweise die Komprimierung des Speichers vor dem Umzug.

Wie verläuft eine Live Migration?

Um für ein eventuelles Troubleshooting das nötige Verständnis zu erlangen, skizziere ich hier rudimentär den Ablauf der Live Migration von virtuellen Maschinen. Sie erfolgt in mehreren Schritten:

• TCP Verbindungsaufbau vom Quell- zum Ziel-Host (Die Firewall-Ausnahme MIG-TCP-In für Port 6600 muss am Ziel-Server aktiv sein)
• Übertragung der VM-Konfiguration und Allokieren des Arbeitsspeichers am Ziel-Server
• Erstellen einer VM am Ziel-Host auf Basis der übertragenen Konfiguration
• Transfer des Arbeitsspeichers zum Ziel-Host als 4KB-Seiten
• Zwischenzeitliche Veränderungen im RAM werden differentiell übertragen
• Übertragung von CPU- und Gerätestatus der virtuellen Maschine
• VM am Quell-Host wird gestoppt und der Ziel-Host übernimmt die Ausführung
• Freigabe der VHD(X) Dateien durch den Quell-Host und Übernahme durch den Ziel-Host
• Wechsel des Netzwerk-Switches mit dem Verlust von bestenfalls einem Ping (virtuelle Switches müssen den gleichen Namen tragen)

Damit Migrationen erfolgreich verlaufen, sind auf den Cluster-Knoten gleiche Prozessortypen nötig. Generationsunterschiede zwischen CPUs des gleichen Herstellers lassen sich ausgleichen, indem die Option Zu einem physischen Computer mit einer anderen Prozessorversion migrieren aktiviert wird. Zusätzliche CPU-Features bleiben der VM somit verborgen und daraus resultierend können Leistungseinbußen eintreten, abhängig von der genutzten Anwendung im Gast.

Die Option findet sich im Failovercluster-Manager, wenn man die Einstellungen der zu migrierenden virtuellen Maschine öffnet und dann zu Prozessor => Kompatibilität wechselt.

Aktivierung der Live Migration

Grundvoraussetzung für eine Live Migration ist, dass sie pro Knoten im Hyper-V Manager oder mittels PowerShell aktiviert wird. Per Default sollte das bei einem Failover-Cluster Verbund der Fall sein. Ich beschreibe hier trotzdem die entsprechenden PS Cmdlets und überprüfe anschließend in der GUI die vorgenommenen Einstellungen.

Generell lässt sich die ein- und ausgehende Live Migration aktivieren, indem Enable-VMMigration eine durch Komma getrennte Liste von Hostnamen übergeben wird:

Enable-VMMigration -Computername H-CLUSTER-N1, H-CLUSTER-N2

Anschließend legt man die zulässige Anzahl der gleichzeitigen Live Migrationen, das Authentifizierungsprotokoll und die Leistungsoption fest. Das folgende Beispiel konfiguriert maximal zwei gleichzeitige Migrationen, Kerberos zur Authentifizierung in der Domäne und die Kompression des Arbeitsspeichers als Leistungsoption:

Set-VMHost -Computername H-CLUSTER-N1, H-CLUSTER-N2 `
-MaximumVirtualMachineMigrations 2 `
-VirtualMachineMigrationAuthenticationType Kerberos `
-VirtualMachineMigrationPerformanceOption Compression

In der GUI des Hyper-V Manager gelangt man über das Kontextmenü der Hosts in die generellen Einstellungen und kann auch hier entsprechend die oben genannten Anpassungen überprüfen bzw. korrigieren.

Gut zu wissen: CredSSP oder Kerberos?

Die Authentifizierung über Credential Security Support Provider (CredSSP) gilt im Vergleich zu Kerberos als weniger sicher und komfortabel und ist eher suboptimal für Produktivumgebungen. Im Fall von CredSSP ist es erforderlich, sich am Server anzumelden, damit eine Live Migration ausserhalb von Clustern überhaupt ausgeführt werden kann. Ein Remote-Management ist daher nicht möglich.

Während für eine Shared Nothing Migration nun die Konfiguration einer eingeschränkten Delegation (Kerberos Constrained Delegation, KCD) anstünde, ist diese für eine homogene Cluster-Umgebung nicht erforderlich. Hier teilen sich die Hyper-V-Knoten ein Cluster-Konto, das für die Authentifizierung untereinander zuständig ist.

Netzwerke für die Live Migration

Microsoft empfiehlt, für die Live Migration ein eigenes performantes Netzwerk bereitzustellen und ihren unverschlüsselten Traffic von anderen Netzwerken fernzuhalten. Leistungsoptionen wie die Kompression (Einsatz bei 1 GBit-NICs empfohlen) oder SMB mit Remote Direct Memory Access (RDMA), empfohlen ab 10 Gbit-NICs, verbessern die Performance der Migration. Kommt ein converged Design zum Einsatz, lassen sich hier durch QoS und VLANs entsprechende Netzwerkpakete besser separieren und managen.

Im Failovercluster-Manager findet man im Kontextmenü von Netzwerke die Einstellungen für die Livemigration, wo die Netze für dieses Feature festgelegt werden. In unserem Beispiel verwenden wir ein dediziertes Netzwerk für die Live Migration sowie zusätzlich das Netzwerk der Cluster-Kommunikation, um die Maschinen später zügig zu migrieren.

Bevorzugte Netzwerke können auch per GUI nach oben sortiert werden. Konfiguriert man die Migrationsnetzwerke im Failovercluster-Manager, dann können diese im Hyper-V Manager nicht mehr modifiziert werden.

Live Migration über den Failovercluster-Manager

Sind alle nötigen Einstellungen und Empfehlungen berücksichtigt, lässt sich eine Migration auf einem Shared Storage mit Cluster Shared Volumes (CSV) in wenigen Sekunden erledigen. Kommt PowerShell hier zum Einsatz, dann reicht ein Aufruf von Move-ClusterVirtualMachineRole nach diesem Muster:

Move-ClusterVirtualMachineRole "VM-2016-CORE" H-CLUSTER-N2

Auf der GUI hingegen starten wir über das Kontextmenü der virtuellen Maschine mit dem Befehl Verschieben die Live Migration. Wir können entweder automatisiert einen Knoten wählen lassen oder legen manuell fest, wo die Maschine künftig ihren Dienst verrichtet.