Open Source im professionellen Einsatz
Linux-Magazin 05/2013
© Michael Edward, 123RF.com

© Michael Edward, 123RF.com

Livemigration für virtuelle Maschinen

Migrationshintergrund

Ein großer Vorteil von Virtualisierungen ist die Möglichkeit, Systeme von einem Host auf einen anderen umzuziehen, ohne dass für den Anwender eine längere Downtime entsteht. Damit das reibungslos klappt, müssen sowohl der Hypervisor als auch der verwendete Storage mitspielen.

843

Effizient und flexibel sei die Cloud, erzählen Experten gebetsmühlenartig. Aber weder Virtualisierung noch die Abrechnung nach Ressourcennutzung sind neu, die Konzepte stammen aus der Urzeit der IT. Mittlerweile gelten die Cloudlösungen als Mainstream. Planer und Consultants gehen in IT-Unternehmen davon aus, dass die Admins eine neue Serverplattform nur mehr virtualisiert betreiben.

Das spart Kosten für Hardware und den laufenden Betrieb und bringt quasi im Vorbeigehen zahlreiche weitere Vorteile. Einer davon ist das Live-Migrieren laufender Systeme. Was bei echter Hardware unmöglich wäre, gelingt mit virtualisierten Systemen ganz leicht. Eine auf einem Host laufende VM "einzufrieren", sie auf einen der anderen Virtualisierungs-Gastgeber zu verschieben und dort fortzusetzen, ohne dass für die Nutzer des in der VM laufenden Dienstes ein spürbarer Aussetzer entsteht, das ist immer noch die hohe Schule der Virtualisierungskunst, und hier trennt sich Spreu von Weizen.

Spiele ohne Grenzen

In der Tat sind die Ergebnisse beeindruckend. Furore machte vor einigen Jahren ein archetypisches Demo-Setup, bei dem Spieler des 3-D-Egoshooters Quake 3 während des Spiels nichts davon mitbekamen, dass die VM mit ihrem Server gerade von einem auf den anderen Host umgezogen war. Die effektive Downtime beim Client lag bei wenigen Sekunden, sodass problemlos auch ein Schluckauf im Netzwerk die Ursache hätte sein können.

Admins freuen sich freilich auch aus anderen Gründen über eine Livemigration, denn sie erlaubt es, ohne lange Downtime Wartungsarbeiten auf Virtualisierungshosts zu erledigen. Bevor die Arbeit auf einem Computing-Knoten losgeht, migriert der Admin alle VMs auf andere Server und kann dann mit dem Update-Kandidaten tun und lassen, was er will. Dass das allerdings zwischen verschiedenen Produkten, Architekturen oder CPU-Varianten leider immer noch nicht geht, zeigt der Kasten "Gelingt nicht ohne Downtime".

Gelingt nicht ohne Downtime: Den Hypervisor wechseln

Die wichtigste Komponente bei einer Livemigration ist der Hypervisor. Mit dessen Wahl legt sich der Administrator allerdings fest, denn die Livemigration von einem zu einem anderen Hypervisor ist unter Linux derzeit unmöglich. Wer eine Virtualisierungsumgebung baut, sollte sich also vor Augen halten, dass homogene Setups grundsätzlich leichter zu warten sind als solche, in denen verschiedene Hypervisoren zum Einsatz kommen.

Das Prinzip der Homogenität lässt sich in gleicher Weise übrigens auch auf das Thema Architektur anwenden. Bereits die Migration von einer VM, die auf einem 32-Bit-Host läuft, auf einen 64-Bit-Hypervisor ist eine Herausforderung. 64-Bit-VMs können auf 32-Bit-CPUs gar nicht ordentlich laufen. Wer plant, Architekturen in Virtualisierungs-Setups zu kombinieren, muss sich also mit dem kleinsten gemeinsamen Nenner abfinden, nicht selten also mit 32-Bit-Systemen.

Livemigration zu anderen Hypervisoren?

Schließlich ist ein oft anzutreffendes Prozedere der Umstieg von einem Hypervisor auf einen anderen, kombiniert mit dem typischen Wunsch nach so wenig Downtime wie möglich. Wer solch eine Aufgabe zu erledigen hat, muss sich über die entsprechenden Fähigkeiten der künftigen Lösung informieren. KVM und Qemu bringen jede Menge Werkzeuge zum Konvertieren von Images mit, die sich auch ohne langes Studium der Manpages leicht bedienen lassen.

Aber die Idee, eine Qemu-KVM-VM ohne Downtime auf einen Hypervisor-Host mit Windows zu migrieren, schlägt schon deshalb fehl, weil Livemigration mit KVM zum großen Teil direkt in Qemu passiert, Qemu aber zum Beispiel mit Microsofts Hyper-V nicht kommunizieren kann. Eine solche Lösung wäre zwar technisch elegant, fällt im Moment aber leider in die Geht-nicht-Kategorie.

Auch eine Migration von Xen hin zu KVM lässt sich kaum sinnvoll ohne eine – wenn auch kurze – Unterbrechung erledigen. Wer zu einer kommerziellen Virtualisierungssoftware, also zum Beispiel VMware, greift, hat mehr Glück. So bietet VMware eine Migrationsfunktion namens Virtual to Virtual an, die eine beliebige virtuelle Maschine in eine neue VMware-VM umbaut. Ganz ohne Downtime geht das zwar auch nicht, aber die Zeitspanne ist dennoch deutlich kürzer, als es bei einem händischen Umwandeln der Fall wäre.

Der technische Hintergrund

Mittlerweile existieren einige fertige Lösungen zur Livemigration, die das Feature ab Werk mitbringen und oft gar per GUI die Option bieten, Livemigration per Mausklick zu aktivieren. Der technische Hintergrund der meisten Lösungen ist der gleiche. Die im RAM abgelegten Inhalte einer virtuellen Maschine, die auf Host A läuft und im laufenden Betrieb auf einen anderen Host wandern soll, kopiert die verwendete Virtualisierungslösung auf den Zielhost und ruft dort bereits den Virtualisierungsprozess auf, während das System auf Host A noch weiterhin funktioniert.

Erst wenn der RAM-Inhalt vollständig auf dem Zielhost angekommen ist, hält der Virtualisierer die VM am Quellhost kurz an, kopiert das inzwischen entstandene Delta ebenfalls zum Ziel und beendet schließlich den Emulator auf dem Quell-Host. Diese kurze Zeit ist im Idealfall die einzige Downtime, die entsteht.

Damit das Prinzip so funktioniert, sind ein paar Bedingungen zu erfüllen. Die wichtigsten Fragen betreffen den Storage. Denn damit die virtuelle Maschine gleichzeitig auf zwei Hosts laufen kann, ist eine Grundvoraussetzung, dass ihr Storage zum genannten Zeitpunkt auf beiden Rechnern lesend und schreibend zur Verfügung steht. Wie das in der Realität funktioniert, hängt von der genutzten Storage-Technologie und der Architektur der Virtualisierungslösung ab.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • DRBD 9

    Das Wiener Unternehmen Linbit löst das wirklich in die Jahre gekommene DRBD 8 durch die neue Version 9 ab – und lässt dabei kaum einen Stein auf dem anderen. Ein erster Test zeigt: DRBD 9 kann sich gegen Objektspeicher gerade beim Thema Latenz behaupten.

  • Storage-HA

    Admins, deren Telefonnummer nach dem Ausfall des Fileservers hundertmal in einer Minute gewählt wird, wissen: Verfügbarkeit ist mehr als nur eine theoretische Kenngröße. Die Wahl der richtigen Architektur, Clustersoftware und Filesysteme hilft das Schlimmste vermeiden.

  • Storage-Cluster

    Wer Cloudumgebungen baut, braucht nicht nur eine skalierbare Infrastruktur, sondern auch eine performante Storagekomponente. Zu den relevanten Speicherlösungen, die dieser Schwerpunkt vorstellt, gehört auch der Newcomer Ceph, der als Objectstore für die Cloud ein schönes Paar mit Open Stack abgibt.

  • LVM-Unterstützung für DRBD-Management-Console

    Mit der aktuellsten Version der DRBD-Management-Console können Administratoren nun auch logische Volumes verwalten.

  • KVM-HA-Monitoring

    Gerade im Notfall will der Admin schnell informiert sein, wenn ein System in der privaten Wolke streikt. Weder Monitoring- noch Hochverfügbarkeits-Konfiguration müssen dabei kompliziert sein, auch ein einfaches Setup mit KVM, Pacemaker, DRBD und Opsview hilft in den meisten Fällen.

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.