Mit dem Verschieben von virtuellen Computern (VMs, Virtual Machines) im  laufenden Betrieb, der Live Migration, hat Microsofts Hyper-V zu VMwares Virtualisierungs-Lösungen auf der Basis von ESX3 oder vSphere 4 (kombiniert mit Vmotion) aufgeschlossen. Auf Hyper-V-Knoten, die in einem Cluster verbunden sind, lassen sich allerdings nur eine Verschiebeaktionen zu einem Zeitpunkt ausführen.

Wer in seiner IT-Umgebung mit Hilfe der Server-Virtualisierung ein Verschieben von laufenden virtuellen Maschinen (VMs) von einem Virtualisierungs-Host zu einem anderen durchführen kann, der kann geplante Wartungsfenster ohne Betriebsunterbrechung realisieren. In einem derartigen fall lassen sich die VMs von dem System, auf dem die Wartung ausgeführt werden muss, auf ein andere Virtualisierungs-Host verlagern – wenn dort genügend Ressourcen (CPU, Arbeitsspeicher und auch Netzwerk-Bandbreite) zur Verfügung stehen. Abgesehen von den durch die IT-Umgebung vorgegebenen Parametern – wie etwa die für ein Verschieben verfügbare Bandbreite zwischen den beiden physischen Systemen, stellt sich auf die Frage: Wie viele VMs lassen sich in einem Hyper-V-Cluster von einem Knoten auf den anderen gleichzeitig verschieben.

Bei der Live Migration auf Systemen mit »Hyper-V« kann jeder Satz von Knoten, die in diese Aktion eingebunden sind (also jedes Quell- und Zielsystem) immer nur eine Live Migration zu einem Zeitpunkt ausführen. Angenommen es befinden sich 16 Knoten in einem Cluster, besteht de Möglichkeit, bis acht gleichzeitige »«Live Migrations« auszuführen.

Es gibt andere Hypervisoren, die mehr als nur einen Umzug einer VM gleichzeitig abhandeln könne. Doch wer sich genau vor Augen führt, was in dieser Aktion alles abläuft, wird schnell erkennen, dass mit nur einer gleichzeitigen Migration zugleich auch die bestmögliche Durchsatz für diese Aktion erzielt wird.

Anzeige

Eine Live Migration nach der anderen

 Zieht eine VM von einem Host auf einen anderen um, muss der komplette Speicher der VM auf das Zielsystem übertragen werden – und zwar während die ursprüngliche VM, also die Datenquelle, aktiv bleibt. Ein derartiger Kopiervorgang dauert seine Zeit – abhängig von der Größe des Speichers und der verfügbaren Bandbreite im Netzwerk. Dabei nutzt der Hyper-V die Netzwerkverbindung komplett aus – sprich die Netzwerkanbindung wird zum Flaschenhals in dieser Aktion.

Im Verlauf des Kopiervorgangs bleibt de VM aktiv am Laufen. Damit ändern sich einige Speicherbereiche und diese Bereiche müssen erneut kopiert werden, damit der aktuelle Zustand auf dem Zielsystem vorliegt. Dabei wird im zweiten Kopierlauf weitaus weniger zu übertragen sein als beim ersten Mal, doch auch die zweite Übertragung erfordert Zeit. Und auch in dieser Zeitspanne kann es zu Änderungen in der laufenden VM kommen. Und dann ist die nächste Iteration nötig.

Dies wird einige Male nötig sein, bis die Datenmenge für das Kopieren so gering ist, dass in der Zwischenzeit keine Änderungen an der VM mehr auftreten und die VM dann auch angehalten werden kann. Dann werden der restliche Speicherbereich sowie die Einstellungen in der CPU und der Gerätestatus auf das Zielsystem übertragen und dann die VM auf dem neuen Host gestartet. Da aber beim Übertragen das Netzwerk voll ausgenutzt wird, und je schneller man den Speicher transferieren kann, und je weniger Änderungen in der Zwischenzeit auf dem Quellsystem eintreffen, umso schneller laufen die darauf folgenden Kopierzyklen ab.

Mehrere Live Migrations gleichzeitig sind unproduktiv

 Würde man mehrere Live Migrations gleichzeitig zwischen zwei Knoten ablaufen lassen, würde die Netzwerkbandbreite zwischen diesen Migrationen aufgeteilt werden müssen. Angenommen man würde zwei gleich große VMs gleichzeitig umziehen, würde schon das erste Kopieren der VM doppelt so lange dauern. Damit würden auch noch mehr Änderungen an der laufenden Maschine auf dem Quellsystem aufzunehmen sein – und das würde dann auch wieder länger dauern – und so weiter. Daher kann man schon sehen, dass die Migration umso schneller läuft, je weniger Änderungen an einer laufenden VM zu berücksichtigen sind. Damit ist der Ansatz, nur eine gleichzeitige Migration auszuführen die beste Variante, da in diesem Kontext weniger nachfolgende Kopieraktionen nötig werden.
Rainer Huttenloher