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

    Der Inhalt des Arbeitsspeichers wird im laufenden Betrieb auf den Ziel-Host übertragen.Die x86-Virtualisierung entkoppelt Anwen­dungen von der physischen Hardware, so dass man sie einfach auf andere Server übertragen kann. Eine Live Migration zieht VMs sogar unter­brechungs­frei um und eröffnet so neue Mög­lich­keiten für das Server-Management. Im Hyper-V-Cluster muss man dafür aber erst einige Voraussetzungen schaffen.

    Live Migrationen erhöhen die Flexibilität der IT-Infrastruktur und bieten gleich mehrere Vorteile. So vermeiden sie Downtime bei Host-Updates mit folgendem Neustart oder beim Austausch von Servern, weil die Anwendungen vorher im laufenden Betrieb auf alternative Hosts ausgelagert werden können. Sie helfen auch dabei, die Arbeitslast gleichmäßiger zwischen Hosts zu verteilen und so die Ressourcen besser auszulasten. Ein VM Load Balancing im Windows Server 2016 Cluster passiert nach einem bestimmten Algorithmus automatisch.

    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.

    Unterschiede in den CPU-Versionen lassen sich durch Konfiguration der VM die Prozessor­kompatibilität ausgleichen.

    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

    Ein -und ausgehende Live Migration im Hyper-V Manager aktivieren

    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.

    Authentifizierungsprotokoll auswählen und Leistungsoption setzen.

    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.

    Netzwerke und Adapter für den Traffic der Live-Migration auswählen.

    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

    Virtuelle Maschine auf anderen Knoten des Clusters migrieren.

    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.

    Keine Kommentare