Integration von Speicher
Cluster Shared Volumes (CSV) erlauben dem Hypervisor endlich, unter einer Logical Unit Number (LUN) mehrere VMs abzulegen. Bislang musste für jede virtueller Maschine eine separate LUN eingerichtet werden, was den Verwaltungsaufwand unnötig erhöhte.
Zugleich leisten CSV einen zentralen Beitrag zur Hochverfügbarkeit. Mittels Dynamic I/O Redirection lässt sich der Ausfall einer SAN- oder Netzwerkverbindung bei einem Hyper-V-Server oder einer VM kompensieren, indem der Traffic über einen benachbarten Cluster-Knoten geleitet wird.
Bislang sind CSV ausschließlich für die Speicherung und Bereithaltung von Hyper-V-VMs (in Form von .vhd-Dateien) gedacht. Es wird ausdrücklich davor gewarnt, diese Laufwerke für normales File-Sharing zu verwenden, da früher oder später Datenverluste drohen.
Live Migration und High Availibility
Die lang erwartete Migration von VMs während des laufenden Betriebs auf einen anderen Server stellt einige Anforderungen an die technische Umgebung. Es setzt zum einen mindestens Windows 2008 Server R2 Enterprise Edition oder die Standalone-Version von Hyper-V ("Hyper-V Server 2008 R2"). Darüber hinaus müssen sich die beteiligten Rechner im selben TCP/IP-Subnetz befinden und Zugriff auf ein Netzwerklaufwerk (SAN, NFS, NAS) haben, auf welchem die virtuellen Maschinen abgelegt sind. Microsoft sieht für die Speicherung die neuen Cluster Shared Volumes (CSV) vor, eine Erweiterung des NTFS-Dateisystems, um konkurrierenden Zugriff von verschiedenen VMs auf dasselbe Laufwerk zu ermöglichen.
Die CPUs der beteiligten Rechner müssen vom selben Hersteller und aus derselben Prozessorfamilie stammen sowie über den gleichen Funktionsumfang verfügen, damit die Übertragung - ob "Live" oder "Quick" (mit Systemabschaltung) - funktioniert. Darüber hinaus muss die Hardware nicht unbedingt völlig identisch sein.
Zusätzlich müssen die Hyper-V-Server das Microsoft Failover Clustering installiert und konfiguriert haben. Maximal 16 Hosts (Knoten) können zu einem Cluster zusammengeschaltet werden - nur zwischen diesen Rechner lassen sich dann VMs im laufenden Betrieb verschieben. Hierfür empfiehlt der Hersteller ein dediziertes Gigabit-Netzwerk mit redundanter Auslegung der Komponenten.
Die Live Migration lässt sich aus dem Failover Cluster Manager steuern, sie kann jedoch auch remote mittels PowerShell- oder WMI-Script ausgeführt werden. Außerdem kann auch der SCVMM den Vorgang anstoßen.
Die Live Migration legt zunächst auf dem Zielrechner eine neue VM an, kopiert dann die Konfiguration von der Quelle zum Ziel und überträgt schließlich den Speicherinhalt der VM. Zuletzt wird die Quell-VM angehalten und korrespondierende VM auf den Zielrechner gestartet. Dieser Übergang macht sich schlimmstenfalls durch einige wenige Ping-Aussetzer bemerkbar. Dies ist ein spürbarer Fortschritt gegenüber der bisher verfügbaren Quick Migration, bei der die VM während des Transfers pausieren muss, wobei einige Minuten vergehen und Netzwerkverbindungen abreißen.
In unseren Tests erwies sich der Vorgang als unerwartet langwierig. Eine nicht beschäftigte VM mit 1 GB Hauptspeicher zu migrieren nahm dabei fast zehn Minuten in Anspruch, wobei dem Rechnerverbund aus Hyper-V-Hosts und iSCSI-Storage jedoch kein dediziertes und für den SAN-Verkehr optimiertes Netzwerk zur Verfügung stand.
Das Management erweist sich als nicht gut gelungen: Um eine einzige VM hochverfügbar zu machen und sie für Live Migration vorzubereiten, bedarf es einer Vielzahl von Schritten in unterschiedlichen Werkzeugen - iSCSI-Initiator, Festplatten-Manager, Failover Cluster Manager, Hyper-V-Manager. Wird die Reihenfolge nicht eingehalten, liefert der Cluster Validator zwar entsprechende Fehlermeldungen, die eine Diagnose durch den Administrator jedoch nicht ersetzen.
Hier finden Sie einen Screencast zum Thema "Live Migration Demo unter Hyper V-2.0 Beta".