computerwoche.de

Software-Infrastruktur

Unter die Lupe genommen

Oracle VM versus VMware ESX Server

18.06.2008
Von Björn Bröhl

Live-Migration

Die Live-Migration unter Oracle VM beziehungsweise VMotion von VMware ist ein Feature, um eine virtuelle Maschine im laufenden Betrieb von einer physikalischen Maschine unterbrechungsfrei (zumindest aus Benutzersicht) auf eine andere zu migrieren. Dies ist zum Beispiel der Fall, wenn Hardwarewartungen nötig sind oder man einen Server entlasten will. Damit die Migration funktioniert, muss die virtuelle Maschine permanenten Zugriff auf ihr Dateisystem haben, was durch ein Netzwerk-Dateisystem wie NFS oder Fibre Channel gewährleistet ist. Als günstige Alternative bietet sich hier auch iSCSI an.

Voraussetzungen für eine erfolgreiche Live-Migration sind:

  • Beide Hosts müssen identische Hardware (CPU, RAM, Mainboard) haben.

  • Beide Hosts müssen Zugriff auf das gleiche Dateisystem haben.

  • Beide Hosts sollten sich im gleichen Subnetz befinden, und die virtuelle Maschine sollte ein Bridge Network Setup haben.

  • Unter Oracle VM müssen sich beide Systeme im gleichen Server-Pool befinden.

Um die Netzverbindung unter Oracle VM auf das neue System zu übertragen, wird von dem zu migrierenden Host ein ARP-Request generiert, der ankündigt, dass die IP-Adresse der virtuellen Maschine an einen neuen Ort gewechselt hat. Es geht dabei nur eine kleine Menge an Paketen verloren, die gerade "in-flight" sind und automatisch neu angefordert werden.

Bei Oracle VM erfolgt eine Live-Migration in fünf Schritten:

  • Pre-Migration: Auf Host A läuft eine virtuelle Maschine. Ein Ziel auf Host B wird ausgewählt.

  • Reservation: Host B überprüft die notwendigen Ressourcen und stellt anschließend einen Container bereit, der der virtuellen Maschine von Host A entspricht.

  • Iterative Pre-Copy: Alle Pages (Arbeitsspeicherinformationen) werden transferiert.

  • Stop-and-Copy: Die virtuelle Maschine auf Host A wird gestoppt und der Netzverkehr auf Host B umgeleitet. Danach werden der CPU-Zustand und die noch zuletzt geänderten Speicher-Pages transferiert. Die Ausfallzeit des Systems beträgt bei einem 1-Gigabit-Ethernet-Netz zirka 200 Millisekunden.

  • Commitment-and-Activation: Host B bestätigt den Vorgang und setzt die Ausführung des Systems fort. Dabei wird Host B der primäre Host, und A beendet seine Prozesse.

Ein noch großes Problem von Oracle VM ist die kaum vorhandene Fehlererkennung während der Migration sowie der Umstand, dass das Zielsystem mindestens die Hardwarevoraussetzungen des alten Hosts erfüllen muss. Im Gegensatz zu den VMware-Mechanismen prüft Oracle VM Manager vor der Migration nicht, ob zum Beispiel auf dem neuen System genügend Ressourcen (Platten, Arbeitsspeicher, CPUs etc.) verfügbar sind. Ist dies nicht der Fall, versucht Oracle VM die virtuellen Maschinen dennoch zu transferieren, stoppt den alten Host, kann die VMs auf dem Zielsystem allerdings nicht starten, so dass die Migration ohne Fehlermeldung gescheitert ist und der alte Server manuell neu in Betrieb genommen werden muss. Solange man nicht sicher sein kann, dass die Migration unterbrechungsfrei stattfindet, ist der Sinn des Systems eher fragwürdig, da man immer eine Ausfallzeit einplanen muss. Außerdem hat Oracle in der Version 2.1 einen kleinen Bug verbaut: Der Manager entfernt die CD-Laufwerke vor der Migration nicht aus der virtuellen Maschine, so dass in vielen Fällen die Migration misslingt (siehe bugzilla.oracle.com #4785).

Diese Kinderkrankheiten gibt es in VMware ESX nicht mehr, da die Systeme wesentlich toleranter in den Anforderungen an die Hardware sind und eine Migration auch nur dann stattfindet, wenn die Rahmenbedingungen gegeben sind und die Maschine unterbrechungsfrei betrieben werden kann. Hier hat der ESX Server eindeutig die Nase vorn, während Oracle VM im jetzigen Zustand noch nicht für den Produktiveinsatz nutzbar ist.