Eines der wichtigsten Features der Virtualisierung mit Hyper-V ist die Live Migration. Diese ermöglicht es, virtuelle Maschinen (VM) von einem Hostserver auf einen anderen zu verschieben, ohne diese VM außer Betrieb zu nehmen. Das ist nützlich, wenn man etwa Wartungsarbeiten auf diesem Host ausführen muss, z.B. die Installation eines Updates mit anschließendem Neustart. Verschiebt man hierbei vorher die VMs von diesem Host auf einen anderen, können die Anwender unterbrechungsfrei weiterarbeiten. Auch zur Lastverteilung kann diese Funktion hilfreich sein.
Voraussetzung für die Live Migration ist unter Windows Server 2008 R2, dass die beiden Hosts einem Cluster angehören und auf ein gemeinsames Speichersystem (SAN) zugreifen können. Auf diesem Speichersystem liegen die VHD-Dateien, die die virtuellen Festplatten der VM-Server darstellen. Erst mit Windows Server 2012 wird die Live Migration auch ohne Cluster und ohne gemeinsamen Speicher möglich sein.
In vielen Darstellungen liest man, dass die Cluster-Shared Volumes (CSV), die seit Windows Server 2008 R2 verfügbar sind, eine zwingende Voraussetzung für die Live Migration seien. Andere bestreiten dies. Wie ist es denn nun?
Schauen wir uns zur Beantwortung dieser Frage an, wie eine Live Migration abläuft. Damit eine VM von einem Host auf einen anderen ohne Betriebsunterbrechung verschoben werden kann, müssen beide Hosts über eine leistungsfähige Netzwerkverbindung kommunizieren können. Zu Beginn des Vorgangs erzeugt – vereinfacht dargestellt – der Ziel-Host eine virtuelle Maschine, deren Konfiguration identisch zu der VM auf dem Quell-Host ist. Danach überträgt der Quell-Host an den Ziel-Host den Inhalt des Arbeitsspeichers der laufenden VM. Das gelingt normalerweise auch dann gut, wenn die VM über einen großen Arbeitsspeicher von mehreren Gigabytes verfügt, weil der Anteil des Arbeitsspeichers, der tatsächlich gerade in aktiver Benutzung ist, meist recht gering ist. Alle Inhalte des RAM (die in so genannte “Seiten” oder “Pages” aufgeteilt sind), die gerade nicht manipuliert werden, kann das System einfach über das Netzwerk übertragen. Schwieriger ist dies nur bei Pages, die gerade geändert werden (das so genannte “Working Set”). Diese muss das System sich bis zum Schluss aufsparen. Sollte eine bereits übertragene Seite während des Vorgangs erneut geändert werden, so muss Hyper-V diese noch mal kopieren. Irgendwann ist nur noch ein kleiner Anteil an Seiten übrig, die noch nicht übertragen sind. Ist die Datenmenge klein genug, so setzt das System die VM auf dem Quell-Host kurz aus, kopiert den Rest zum Ziel und schaltet die nun vollständige VM dort online. Die Quell-VM entfernt das System.
Das funktioniert normalerweise problemlos. Da die Konfiguration der betroffenen VM als erstes übertragen wird, ist die VM so praktisch arbeitsfähig. Bleibt noch eine wichtige Ressource übrig: Die Festplatte der VM. Diese ist ja als VHD-Datei auf dem SAN gespeichert. Da grundsätzlich beide Host-Server Zugriff auf das SAN-Volume (die so genannte “LUN”, Logical Unit Number) haben, bedarf es nur eines kurzen Umschaltens, damit der Ziel-Host den Speicherbereich übernimmt.
Dies klappt problemlos ohne CSV. Das Problem dabei: Eine LUN kann immer nur vollständig einem Host-Server “gehören”. Liegen auf dieser LUN nun aber mehrere VHD-Dateien, die zu unterschiedlichen VMs gehören, so müssten alle diese VMs gleichzeitig vom Quell-Host zum Ziel-Host übertragen werden. Anderenfalls wäre es nicht möglich, dem Ziel-Host den Besitz an der LUN zu übergeben, denn sonst könnte der Quell-Host auf die VHD-Dateien der nicht migrierten VMs nicht mehr zugreifen. Diese VMs würden dann plötzlich stehen bleiben. Dasselbe gälte übrigens auch beim Failover, also dem Umschalten von einem Host auf einen anderen bei einem plötzlichen Ausfall: Auch hierbei müsste die gesamte LUN mit allen gespeicherten VMs den Host wechseln, auch wenn der Ausfall vielleicht nur eine der VMs beträfe.
Als Konsequenz bedeutet das, dass man im klassischen Verfahren nicht mehrere VMs auf derselben LUN im SAN ablegen könnte. Stattdessen wäre es erforderlich, für jede VM eine eigene LUN im SAN zu reservieren und diese jeweils einem Host-Server zuzuweisen. Nur so könnte man erreichen, dass einzelne VMs unabhängig voneinander den Host wechseln, weil hierbei ja auch der exklusive Zugriff auf die LUN wechseln müsste.
Stellt man sich nun eine größere Host-Umgebung mit -zig VMs oder noch mehr vor, wäre die Anzahl der zu verwaltenden LUNs schnell sehr unhandlich. Daher hat Microsoft als neue Ebene die Technik der Cluster-Shared Volumes eingeführt. Diese umgehen einige Beschränkungen des NTFS-Dateisystems, denn genau dieses bildet die Ursache für das Erfordernis, eine LUN komplett genau einem Server zuzuweisen. NTSF selbst ist nicht clusterfähig, weil es so entworfen wurde, dass immer nur ein Server ein gesamtes Volume verwaltet. Durch die CSV-Technik ist es möglich, dass mehrere Server gleichzeitig dieselbe LUN nutzen – dabei darf jeder aber nur allein auf bestimmte Daten zugreifen, also etwa eine VHD-Datei. Darüber wacht ein “Coordinating Node” im Cluster, der den konkreten Zugriff durch einzelne Server auf bestimmte Datenbereiche steuert.
Eine zwingende Voraussetzung für die Live Migration sind CSV also nicht. Verzichtet man auf die Technik, so kann man jeder VM eine eigene LUN zuweisen und dann auch ohne CSV Live Migrations ausführen. Praktikabel ist dies aber nicht: Schnell ist man bei diesem Ansatz bei einer Systemkomplexität, die eher stört als nützt. Berücksichtigt man dabei, dass CSV sehr einfach einzurichten sind und kaum nennenswerte Nachteile haben, gibt es kaum einen Grund, in der Praxis auf die CSV-Technik zu verzichten. Dabei sollte man auch berücksichtigen, dass das Prinzip “eine LUN pro VM” deutlich mehr Speicher auf dem SAN erfordert und damit die Speicherkosten in die Höhe treibt.
Weitere Details dazu bietet dieser Blog-Artikel:
http://faq-o-matic.net/?p=4065