© Tina Koch, Photocase.com

Virtualisierungspraktiker, die ein ordentliches Budget haben, versilbern es gern in ESX-Lizenzen beim Marktführer VMware. ESX-virtualisierte Gastsysteme zu migrieren ist aber keine Glückssache.

Mit 1500 Euro startet die nach oben offene “VMware Infrastructure Foundation”-Preisliste. Dafür bekommt man ESX-Server [1] für zwei Prozessoren, Werkzeuge und ein Jahr Support an fünf Tagen pro Woche. Die betriebliche IT-Praxis vielerorts zeigt, dass VMware trotz proprietären Modells und vorhandener Konkurrenz sich wacker am Markt behauptet – so leistungsfähig ist die Lösung.

Gleichwohl bleibt für den Admin genug Arbeit, beispielsweise wenn er einen Host abschalten muss. Sei es temporär, weil System- oder Hardwarewartungen anstehen, sei es permanent, da er ihn ersetzt. Die VMware-Gäste, die der Host gerade beherbergt, müssen also umziehen, zeitweise auf eine weitere ESX-Maschine oder dauerhaft auf neue Hardware. Drei Wege bieten sich an:

• Backup der Images und Restore auf dem anderen Host
• Kalte Migration, also Umzug in ausgeschaltetem Zustand
• Heiße Migration, also Umzug bei laufendem Betrieb

Je nach geforderter Verfügbarkeit und Hardware-Umständen eignet sich mal die eine, mal die andere Variante besser.

Backup und Restore

Wenn eine Downtime der virtuellen Maschinen akzeptabel ist, nachts vielleicht, ist die Variante mit Sichern und Wiederherstellen der Gast-Abbilder wenig fehleranfällig und recht simpel. Zuerst schreibt der Admin Gast für Gast aufs Backup – natürlich im laufenden Betrieb. Das passiert ohnehin regelmäßig, auch wenn gerade keine Migration ansteht. (Sinnvoll sind ein zwei Vollsicherungen wöchentlich auf einem extra VMFS-Volume. Die Versionsverwaltung steuert am besten ein Skript, das auch Vollsicherungen löscht, die älter als zwei Wochen sind.)

Dazu gibt es mehrere Möglichkeiten: Zum Beispiel ließe sich auf jedem Gast ein Backupprogramm installieren, wie das bei nicht-virtualisierten Servern Standard ist. Für virtuelle Maschine existieren jedoch bessere Methoden, so ist kostenlos unter [2] ein Skript namens Visbu erhältlich, das unter VMware ESX (aber nicht ESXi) mehrere Sicherungsschritte durchführt (Abbildung 1).

Abbildung 1: Das kostenlose Skript Visbu, das Virtual Infrastructure Backup Utility, ist eine intelligente Möglichkeit, virtuelle VMware-Maschinen zu sichern.

Als Erstes erstellt es einen Snapshot des Gastes im laufenden Betrieb. Dabei schaltet es dessen Dateisystem, die VMDK (VMware Virtual Disk) in den Read-only-Modus. Alle Schreibzugriffe landen daraufhin in einer so genannten Delta-VMDK, die früher Redo Log hieß. Jetzt schreibt Visbu die eigentliche VMDK, die keine Schreibzugriffe erhält, auf das Backupvolume. Später wird es sie um die Daten der Delta-VMDK ergänzen. Es entsteht ein vollständiger Snapshot der virtuellen Maschine, die sich auf den neuen Host per Restore einspielen lässt.

Eine Fußangel lauert im Storage: Wenn die virtuelle Maschine viele und/oder große Schreibzugriffe durchführt, bläht das die Delta-VMDKs gehörig auf. Insbesondere wenn die Snapshot-Prozedur für mehrere Gäste läuft, sollte der Admin den verfügbaren Plattenplatz großzügig bemessen. Gleiches gilt, wenn er außer der Reihe einen Snapshot anfertigt, beispielsweise wenn auf der virtuellen Maschine kaum getestete Updates anstehen. Schlägt dies fehl oder funktioniert nicht wie erhofft, kann der Admin in sehr kurzer Zeit den Snapshot wieder reaktivieren. Generell sinnvoll ist es, daran zu denken, nicht mehr benötigte Snapshots zu löschen – andernfalls läuft auch das weitläufigste Filesystem irgendwann voll.

Consolidated Backup

Eine weitere Möglichkeit, Backups unterbrechungsfrei zu schreiben, eröffnet VMware Consolidated Backup (VCB, [3]). Dabei greift ein Backupserver auf den Storage des ESX-Servers zu und sichert – auch nach dem Snapshot-Verfahren – intelligent die VMDKs nebst Metadaten. Windows-Gästen eröffnet VCB zudem die Möglichkeit, auf die Gast-Dateisysteme zuzugreifen und so Standard-Backups anzufertigen. Vorteil: Die Images liegen nicht auf dem Storage des ESX-Servers, falls dort ein Platteninfarkt passiert.

Der Luxus erkauft sich mit dem Nachteil, einen Backupserver beschaffen zu müssen – und eine Windows-Server-Lizenz. Denn im Gegensatz zu den ESX-Servern ist VCB ein reines Windows-Produkt. Auch kümmert sich VCB nur ums Backup, beim Restore der Images ist Handarbeit angesagt, zum Beispiel per SCP.

Heiße Migration

Während Backup und Restore eine langsame Art ist, einen Gast auf ein neues Hostsystem zu bringen, ist die Hot Migration die schnellste. VMware nennt den Vorgang VMotion [4]. Er kopiert den Inhalt des Arbeitsspeichers des Gastes von einem Host zum anderen, um anschließend als Gast auf dem anderen Host weiterzulaufen. Die Migration findet bei laufendem (hot) Betrieb statt.

Leider ist die heiße ESX-Migration bei den eingesetzten CPUs Beschränkungen unterworfen. Problemlos funktioniert das nur zwischen Hosts, deren CPUs nicht nur vom selben Hersteller, sondern auch aus derselben Prozessorfamilie stammen. So ist es nicht ohne Weiteres möglich, VM-Gäste zwischen Hosts mit Dualcore- und Quadcore-Chips zu migrieren, ebensowenig wie zwischen 32-Bit- und 64-Bit-Systemen. Selbst bei Dualcore-CPUs desselben Herstellers kommt es noch auf die konkrete Familienzugehörigkeit an.

Um diese unbefriedigende Situation ein wenig zu entschärfen, gibt es CPU-Masken. Sie maskieren einen Teil der CPU-Features auf einen gemeinsamen Nenner, beispielsweise die SSE-Version, und sorgen so dafür, dass VMotion auf beiden Hosts funktioniert. Eines Tools zum Definieren der Masken bedarf es nicht. Der Admin spezifiert die CPU entweder über die Eigenschaften des Gastes (Abbildung 2) oder trägt die Masken im VMX-File via Editor ein. Die notwendigen Zeilen erfährt er beim Verschieben des Gastes, in Abbildung 3 hinter »required«.

Abbildung 2: Die CPU-Identifikationsmaske kommt bei VMware dann ins Spiel, wenn Gäste zur Laufzeit zwischen nicht ganz identischen Hosts umziehen müssen.

Abbildung 3: Wie die CPU-Maske als kleinster gemeinsamer Nenner zwischen zwei Hosts aussieht, erfährt der Admin beim Verschieben eines Gastes.

Allheilmittel sind aber auch die CPU-Masken nicht. Die Design-Unterschiede zwischen Dual- und Quad-Cores oder zwischen Intel- und AMD-Chips sind zu groß, als dass sie sich maskieren ließen. Wer allerdings Hosts mit kompatiblen Prozessoren hantiert, kann mit VMotion nicht nur Gäste kontrolliert verschieben, sondern auch den Distributed Resource Scheduler [5] einsetzen. Der DRS verfrachtet Gäste automatisch von einem Host auf einen anderen, um die vorhandenen Ressourcen möglichst effizient zu nutzen. Meldet ein Gast plötzlich einen hohen CPU-Bedarf an, schiebt der DRS ihn auf den Host, dessen Prozessoren im Moment am wenigsten belastet sind.

Kalte Migration

Ist eine heiße Migration nicht möglich, kann der Gast kalt umziehen. Dazu kopiert der Admin die Imagedatei bei heruntergefahrenem Gastsystem auf den anderen Host und bootet den Gast wieder. Wenn beide ESX-Hosts auf dem gleichen Versionsstand sind, wird der Gast ohne Weiteres auf der neuen Hardware starten. Läuft auf der neuen Hardware jedoch zugleich eine neuere ESX-Version als auf der ursprünglichen Hardware, sollte der Admin die so genannten VMware-Tools auf dem Gast aktualisieren, um die neuesten Treiber (Netzwerkkarte, Grafikkarte und so weiter) zu erhalten.

Bei kalter wie heißer Migration wichtig: Das Setup der LUN-IDs der Storage-Einheit muss auf beiden ESX-Servern gleich sein, damit die Gäste im neuen Haus klarkommen. Gleiches gilt für die Netzinterfaces sowie VLANs, soweit eingerichtet.

Den Datastore austauschen

Was tun, wenn der Datastore, auf welchen sich alle Dateien eines Gastes befinden, abgelöst werden muss? In diesem Fall empfiehlt sich, das Feature “Storage VMotion” zu verwenden, das ESX seit Version 3.5 beiliegt. Das Tool ist in der Lage, alle Dateien eines Gastes im laufenden Betrieb von einem Datastore zum anderen zu verschieben, ohne den Gast dabei anzuhalten.

Eigentlich nur als Befehl angeboten, hat sich jemand die Mühe gemacht, ein kleines GUI [6] dafür zu entwerfen (Abbildung 4). Mit SVmotion steht dem Sysadmin eine problemlose Möglichkeit offen, per Mausklick Gäste von Datastore A nach B heiß zu verschieben. (jk)

Abbildung 4: Wenn der ganze Datastore umziehen soll, ist Storage VMotion angesagt. Zu sehen ist SVmotion, ein grafisches VMotion-Frontend.