Livemigration in einem Windows Failover-Cluster schlägt fehl, wenn das Management-Interface nicht verfügbar ist
Bei einem Windows Failover-Cluster, in dem virtuelle Maschinen mit Hyper-V betrieben werden, kommt es bei einem Ausfall des Management-Interfaces auf einem der Knoten zu den folgenden Fehlermeldungen im Eventlog:
- Microsoft-Windows-FailOverClustering – Ereignis-ID 1127 – Netzwerk-Manager – In der Clusternetzwerkschnittstelle “Hyperv12 – Management” für Clusterknoten “Hyperv12” im Netzwerk “Management” ist ein Fehler aufgetreten. Führen Sie den Konfigurationsüberprüfungs-Assistenten aus, um die Netzwerkkonfiguration zu prüfen. Wenn das Problem weiterhin besteht, prüfen Sie, ob Hardware- oder Softwarefehler in Bezug auf den Netzwerkadapter vorliegen. Prüfen Sie auch, ob andere Netzwerkkomponenten fehlerhaft sind, an die der Knoten angeschlossen ist, z.B. Hubs, Switches oder Brücken.
Der Knoten mit dem defekten Interface kann keinen Kontakt mehr mit seiner Domäne aufnehmen, als Fehler wird “Der Clusternetzwerkname ist nicht online” ausgegeben.
Hinweis: Das hier gezeigte Cluster wurde nach unserem Best-Practise eingerichtet und benannt, eine Beschreibung finden Sie hier: Hyper-V-Server.de: Netzwerkkonfiguration im Hyper-V Cluster
Bei solch einem Ausfall möchte man nun alle virtuellen Maschinen, die sich auf dem Knoten mit der defekten Karte befinden, auf andere Knoten verschieben und das System zur Reparatur offline nehmen.
In unserem Fall wird an Hyperv11 ein Netzwerkkabel gezogen, sein Partner ist Hyperv12. Eine Livemigration per Failovercluster-Manager endet allerdings mit dem folgenden Fehler:
Die Lösung ist in diesem Fall eine Livemigration per PowerShell. Wenn man sich nun den entsprechenden Microsoft Technet-Artikel Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 anschaut, findet man den folgenden Befehl:
Get-Cluster “<Cluster Name>” | Move-ClusterVirtualMachineRole -Name “<VM group name>” -Node “<Destination node name>”
Wenn man diesen Befehl nun auf dem Knoten ausführt, erscheint die folgende Meldung:
Wir können erkennen, dass weiterhin der Fehler “Der RPC-Server ist nicht verfügbar” auftritt. Um dies zu umgehen, muss man den Befehl “Get-Cluster “<Cluster Name>” weglassen.
Carsten hat diese Problematik während den Recherchen zu seinem TEC Europe Vortrag 2011 gefunden und auch mit Technikern von Microsoft besprochen, die vorgeschlagene Lösung war die Bildung eines Teams mit mindestens zwei Interfacen, die sich im Management-Netzwerk befinden. Bei dieser Lösung kann eine der beiden Karten ausfallen ohne das dieses Problem hier auftritt, weiterer Vorteil ist eine erhöhte Bandbreite in dem Netz. Nachteil dieser Lösung ist die Nutzung des Teams, dies wird bei Problemen oder Fehlern nicht von Microsoft direkt supported, man muss sich hier an den Hersteller der Netzwerkkarten wenden.
Weitere Möglichkeiten, wie man dieses Problem im Vorfeld umgehen kann:
- Nutzung und Einrichtung eines weiteren Interfaces im Management-Netz, um trotz dem Ausfalls einer Karte weiterhin eine Kommunikation mit dem Domänencontroller zu haben (Mehrere Karten, kein Teaming)
- Der Domänencontroller muss so eingerichtet werden, das neben einer Kommunikation über das Management-Netz eine Kommunikation über ein anderes Netz möglich ist. Diese Lösung empfehlen wir aber nicht!
- Man verwendet das VM-Netz nicht exklusiv für die Gastsysteme, sondern nutzt die Funktion “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen”. Dies empfehlen wir allerdings ebenfalls nicht!
