Hyper-V: Shared Nothing Live Migration ohne Cluster


    Tags: ,

    Shared Nothing Live Migration in Hyper-VDie Live Migration von virtu­ellen Maschinen in einem Hyper-V-Cluster ist ein bewährtes Feature, um die Verfüg­barkeit und Performance von Anwen­dungen zu verbessern. Doch VMs lassen sich auch zwischen Stand­alone-Hosts ohne SAN im laufen­den Betrieb ver­schieben.

    Windows 2012 führte die Shared Nothing Live Migration ein und das Release 2 erlaubte sogar den VM-Umzug von 2012 nach 2012 R2, andersherum jedoch nicht. Diese Form der Migration gehört sicher­lich nicht zum täglich genutzten Werkzeug, weil dabei nicht nur der Arbeitsspeicher übertragen wird, sondern auch die virtuellen Festplatten. In bestimmten Situationen macht sie jedoch das Leben im virtuellen Rechenzentrum um einiges leichter.

    Vorbereitung für die Live Migration

    Einzige Voraussetzungen für die Live Migration ohne gemeinsamen Speicher sind mindestens zwei Hyper-V-Hosts mit gleichen Prozessor­typen, einer gemeinsamen Netzwerk­verbindung und Zugehörigkeit zur gleichen AD-Domäne. Unterschiedliche Prozessor­versionen lassen sich ausgleichen, indem man in der Konfiguration der VM die Prozessor­kompatibilität aktiviert. Coreinfo hilft bei der CPU Featureanalyse.

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

    Die Hyper-V-Hosts müssen für die Live Migration aktiviert werden, um die virtuellen Maschinen verschieben zu können. In meinem Artikel zur Live Migration in einer Cluster-Umgebung habe ich den technischen Ablauf einer Migration beschrieben, um auch im Troubleshooting-Fall gerüstet zu sein. Schauen Sie sich diesen Beitrag dazu einmal an, da die Shared Nothing Live Migration keine großen Abweichungen im Ablauf hat. Einzige Ausnahme ist die zusätzliche Migration der virtuellen Festplatten.

    Der Virtual Machine Management Service (VMMS.exe) baut eine Verbindung zum Ziel-Host auf und der Firewall-Port TCP 6600 muss auch hier entsprechend frei sein.

    Im Ressourcenmonitor sieht man, dass vmms.exe bei der Migration eine Verbindung zu Port 6600 aufbaut.

    Ist der Firewall-Port analog nicht eingehend geöffnet, dann erhalten Sie den Fehler beim Herstellen einer Verbindung mit dem Host… (0x8007274C).

    Aktivierung der Live-Migration

    Damit die beidseitige Live Migration funktioniert, wird diese auf den Hyper-V-Hosts über die GUI des Hyper-V Manager oder über die entsprechenden Cmdlets in PowerShell aktiviert. Klicken Sie dazu im Hyper-V Manager mit der rechten Maustaste auf den entsprechenden Server und wandern zum Punkt Livemigrationen. Aktivieren Sie anschließend die Checkbox für Ein- und ausgehende Livemigrationen ermöglichen.

    Die Aktivierung der Live Migration erfolgt pro Host.

    Über PowerShell schaltet folgender Befehl die Live Migration ein:

    Enable-VMMigration -Computername <HOSTNAME>, <HOSTNAME2>

    Kerberos Constrained Delegation, KCD

    In den Einstellungen für den Hyper-V-Host ist es erforderlich, nach Aktivierung der Live Migration auch das Authentifizierungs­protokoll zu wählen. CredSSP ist für schnelle Tests und kurze Konfigurationswege ausreichend, jedoch müssen Sie sich lokal am Server anmelden um eine Live Migration einzuleiten. Eine Remote-Administration kommt somit nicht in Frage.

    Die Sicherheit von CredSSP ist im Vergleich zu Kerberos niedriger, da bei Kompromittierung des Systems die Anmelde­informationen für viele Dienste missbraucht werden können. Kerberos bedarf jedoch für Remote Live Migrationen (größer einem HOP, Kerberos Design) eine granulare Delegation der Authentifi­zierungs­daten.

    Wenn Sie Kerberos einschalten und versuchen, ohne Delegierung eine Live Migration auf einem benachbarten Host einzuleiten, laufen Sie in den Fehler beim Herstellen einer Verbindung mit dem Host “HOSTSERVER“: Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. (0x8009030E).

    Die Lösung besteht in der Konfiguration einer eingeschränkten Delegation (Kerberos Constrained Delegation, KCD). Öffnen Sie dafür Active Directory Benutzer und -Computer und dort den Kontexteintrag Eigenschaften des Host-Computerobjektes in der entsprechenden OU (Standard: Computers). Wandern Sie dann zur Registerkarte Delegierung und fügen Sie die Diensttypen

    • cifs (erweiterte Version von SMB)
    • Microsoft Virtual System Migration Service

    für alle Hosts ein, denen vertraut werden soll, hinzu. Ein abschließender Neustart der Hosts ist nötig.

    Granulare Delegierung nur für bestimmte Dienste

    Gleichermaßen erfolgt die Aktivierung des Authentifizierungs­protokolls und der Leistungsoption via PowerShell:

    Set-VMHost –Computername HV-STAND-A, HV-STAND-B `
    -MaximumVirtualMachineMigrations 2 `
    -VirtualMachineMigrationAuthenticationType Kerberos `
    –VirtualMachineMigrationPerformanceOption Compression

    Und jene für KCD mit:

    Get-ADComputer HostA | Set-ADObject -Add `
    @{"msDS-AllowedToDelegateTo"="Microsoft `
    Virtual System Migration Service/HostB.Domain.xy", ` 
    "cifs/HostB.Domain.xy", "Microsoft Virtual System ` 
    Migration Service/HostB", "cifs/HostB"}

    Live Migration zwischen Standalone-Hosts

    Für Live Migrationen wird ein separates Netzwerk empfohlen, ist jedoch nicht zwingend notwendig. Die Leistungsoption Kompression können Sie aktivieren, um den Migrationsvorgang zu beschleunigen.

    Eingeleitet wird die Live Migration dann über einen Rechtsklick auf die entsprechende virtuelle Maschine und Auswahl von Verschieben. Der nun folgende Wizard fragt den Typ der Migration ab, verschieben Sie hier den virtuellen Computer komplett, anschließend muss ein Zielsystem angegeben werden.

    Shared Nothing Live Migration des virtuellen Computers starten.

    Danach haben Sie nun die Möglichkeit, verschiedene Optionen für die Migration zu wählen. Virtuelle Computer bestehen aus der Konfiguration, VHD(X) Dateien und Snapshots. Diese können gezielt auf den zweiten Host in verschiedenen Ordnern abgelegt werden.

    Liegen die VHD(X) Dateien auf einer SMB3 Freigabe, dann können Sie nur die VM ohne die virtuellen Festplatten verschieben, jedoch sprechen wir hier nicht mehr von einer Shared Nothing Migration. In diesem Beispiel schieben wir die VM jedoch einfach an einen einzigen Zielspeicherort. Dieser lässt sich remote am Ziel suchen und auswählen.

    Nach dem Anzeigen der Zusammenfassung wird die Maschine zum Ziel-Host im laufenden Betrieb übertragen. Dieser Vorgang dauert je nach Netzwerkleistung und Größe der VHD(X) Files entsprechend länger als eine Migration im Cluster.

    Die PowerShell hält zum Verschieben das Cmdlet Move-VM bereit, dem man sowohl den Quell- und Ziel-Host als auch die neuen Speicherorte für die VM als Parameter übergibt.

    Mit dem folgenden Script lässt sich Move-VM etwas aufpeppen, und Sie haben die Möglichkeit, interaktiv VMs mit gedrückter Strg-Taste für die Live-Migration auszuwählen. Es ist auch für die Migration im Cluster hilfreich, jedoch ohne den Parameter DestinationStoragePath.

    Get-VM -Computername <QUELLHOST> | Out-GridView `
    -Title "Wählen Sie die VMs für die LM" -PassThru | `
    Move-VM -DestinationHost <ZIELHOST> -DestinationStoragePath <ZIELPFAD>

     

    Keine Kommentare