Windows Server 2012 Hyper-V: Fehlende Features und mögliche Lösungen

Microsoft lässt bei Windows Server 2012 Hyper-V mit Quick Migration und Hot-Add-Funktionen Wünsche beim Management der Virtual Machine offen.

Trotz aller neuen Features und Verbesserungen bei Windows Server 2012 Hyper-V hat die Virtualisierungs-Plattform noch ihre Mängel. Ich selbst arbeite seit den frühen Betaversionen mit Hyper-V und schätze, wie rasch Microsoft hier neue Funktionen hinzufügt. Bei jedem Hyper-V-Release sehe ich allerdings auch weitere Verbesserungsmöglichkeiten, die wichtige Funktionen liefern und die Verwaltung vereinfachen könnten. Hier beschreibe ich drei dieser Mängel in Windows Server 2012 Hyper-V und zeige praktische Lösungsmöglichkeiten dafür auf.

1. Mangelhafte Quick Migration zwischen unterschiedlichen Prozessor-Architekturen

Virtual Machines (VMs) lassen sich zwischen Hyper-V-Hosts mit unterschiedlichen Prozessor-Typen migrieren, solange man innerhalb derselben Familie bleibt (zum Beispiel von Intel auf Intel oder von AMD auf AMD). Nicht möglich ist es aber, VMs zwischen unterschiedlichen Prozessor-Familien zu verschieben, ohne zuvor die VM herunterzufahren und auf den anderen Host umzusetzen. Das Problem dabei: Hat eine VM eine große virtuelle Festplatte, verlängert sich die Ausfallzeit erheblich, weil sie auf den neuen Hyper-V-Host verschoben werden muss.

Wie könnte es funktionieren?

Unter Windows sind gewisse Vorkehrungen hinsichtlich der neuen Prozessor-Architektur nötig, ein bis zwei Neustarts mögen also unvermeidlich sein. Doch folgende Methode würde die Ausfallzeit von Stunden auf Minuten verkürzen:

  1. Microsoft könnte mit der gleichen – oder einer ähnlichen – Methode der Live Migration wie bei der Quick Storage-Migration in Windows Server 2008 R2 SP1 arbeiten. Sie fertigt einen VSS-Writer-Snapshot der Virtual Machine und verschiebt die Daten auf den Ziel-Host, während die Quell-VM weiter ausgeführt wird.
  2. Sind die Daten verschoben, startet die neue Virtual Machine offline, so dass sie die Prozessor-Architektur erkennen kann; danach fährt sie herunter.
  3. Als nächstes wird die Quell-VM heruntergefahren und ein letzter VSS-Writer-Snapshot unter Hyper-V angefertigt. Alle verbleibenden Änderungen werden übertragen, danach die VM auf dem Ziel-Host neu gestartet und online gebracht.

Der Prozess ist einer Migration von einer physischen zu einer virtuellen Umgebung sehr ähnlich, bei der Sie einen Host mit Intel- oder AMD-Architektur online halten und ihn zu einem virtuellen Host mit anderer Prozessor-Familie migrieren.

Vorteile dieser Methode

Gut geeignet wäre dieses Vorgehen zur Migration großer VMs, weil das Verschieben großer VHD-/VHDX-Dateien sehr lange dauern kann. Es wäre auch sinnvoll für Umgebungen mit geringer Bandbreite, weil die Quell-VM während der Migration online bleibt.

2. Unzureichende Live/Quick Migration zwischen verschiedenen Versionen von Hyper-V

Die schnell weiterentwickelten Funktionen von Hyper-V haben mit den Ressourcen-Anforderungen moderner Anwendungen Schritt gehalten. Aber dieses hohe Tempo bringt auch die ständige Notwendigkeit, Hosts und VMs auf die neueste Version von Hyper-V zu migrieren.

Meistens erfordert das die Abschaltung der VMs. Dann müssen Sie sie offline auf den aktualisierten Host migrieren und die neuen Integration-Services installieren.

Wie könnte es funktionieren?

Ähnlich wie beim obigen Szenario erfordert die Migration von VMs zwischen Hyper-V-Versionen wahrscheinlich einen Neustart, um neue Integration Services zu installieren. Lange Ausfallzeiten sollten dabei jedoch möglichst vermieden werden. Für die Zukunft stelle ich mir das so vor:

  1. Hyper-V erzeugt mittels VSS Writer einen Snapshot und verschiebt die Daten von der Quell-VM, während sie weiter läuft, bis alle Daten auf den neuen Host verschoben sind.
  2. Dann startet Hyper-V automatisch die neue Ziel-VM offline (die virtuelle Netzwerk-Karte ist nicht angeschlossen) und installiert die Integration Services.
  3. Hyper-V fährt die Quell-VM herunter, nachdem die Daten des ersten Durchgangs auf dem Ziel-Host angekommen sind.
  4. Hyper-V verschiebt verbleibende Änderungen aus der Quell-VM zur Ziel-VM, so dass beide Virtual Machines synchronisiert sind
  5. Zuletzt startet Hyper-V die Ziel-VM neu.

Vorteile dieser Methode

Die Quell-VM bleibt online, bis alle Daten verschoben sind. Gleichzeitig reduzieren sich Ausfallzeiten und die möglichen Belastungen dadurch.

3. Unbefriedigende Hot-Add-Funktion für Arbeitsspeicher bei laufender Virtual Machines

Es sollte nicht überraschen, dass steigende Server-Workloads von Jahr zu Jahr mehr Ressourcen wie Storage, CPU und RAM verlangen. Ab Windows Server 2008 R2 hat Microsoft Hyper-V mit der Funktion ausgestattet, Festplatten neu zu dimensionieren, und mit Windows Server 2012 ist auch Hot-Add für Arbeitsspeicher hinzugekommen – solange die VM Dynamic Memory nutzt. Nach wie vor nicht möglich ist Hot-Add für Memory aber, wenn die VM eine statische oder feste Speicher-Zuweisung verwendet.

Indem Microsoft Hot-Add für Arbeitsspeicher nur bei VMs mit Dynamic Memory ermöglicht, fehlt die Unterstützung für Workloads, die mit hoher Wahrscheinlichkeit eine unterbrechungsfreie RAM-Erweiterung erfordern, zum Beispiel Datenbanken oder sogar Java-Anwendungen. Für letztere wird der Einsatz von Dynamic Memory weder empfohlen noch unterstützt,  weil sie Speicher-Ressourcen voll nutzen und keinen zusätzlichen Speicher aus dem für die VM vorgesehenen dynamischen Pool abrufen können.

Speicherhungrige Workloads werden in der Regel fest konfiguriert, und gerade sie könnten oft mehr Arbeitsspeicher im laufenden Betrieb gebrauchen. Daher glaube ich, dass die Hot-Add-Funktion unvollständig ist und die Arbeitsbelastung von IT-Profis nicht ausreichend verringert.

Wie könnte es funktionieren?

Unter Verwendung der in Windows Server bereits enthaltenen Funktionen sollte Microsoft die Möglichkeit schaffen, Höchstwerte für feste Speicherzuteilungen anzupassen.

Vorteile dieser Lösung

Diese Funktion würde ein weiteres manuelles Verfahren überflüssig machen, das bisher Ausfallzeiten verursacht. Sie würde zudem automatisierte Anpassungsverfahren (mithilfe von System Center Operations Manager) ermöglichen, die speicherhungrigen Workloads regelmäßig neue Ressourcen zuteilen könnten. Und schließlich käme sie Workloads (etwa Datenbanken) mit unvorhersehbaren Speicher-Anforderungen entgegen, die auf Ausfallzeiten am empfindlichsten reagieren.

Verstehen Sie mich nicht falsch: Windows Server 2012 Hyper-V enthält ein paar hervorragende Ergänzungen. Doch bei jedem neuen Release schaffen es einige Features nicht in das Produkt. Die aufgeführten Optionen könnten den Zeitaufwand für Migration und Verwaltung drastisch reduzieren, aber leider sind sie nicht verfügbar – jedenfalls noch nicht.

Fortsetzung des Inhalts unten

Erfahren Sie mehr über Containervirtualisierung

ComputerWeekly.de

Close