Migration

Auch sollte er prüfen, ob die Livemigration in seiner Xen-Umgebung einwandfrei funktioniert. Hierzu benötigt er zunächst ein Speicherbackend für die virtuelle Maschine, das zwei Xen-Dom-0-Hosts erreichen können. Für einen Test reicht da eine einfache NFS-Freigabe, später kümmert sich Remus selbst darum.

Es genügt, auf einem dritten Rechner ein Verzeichnis per NFS freizugeben, das der Admin auf den beiden Xen-Dom-0-Hosts unter demselben Pfad mountet. Dann prüft der Befehl »xm migrate --live Meine-VM Ziel-Dom-0-IP«, ob eine virtuelle Maschine, deren virtuelle Festplatte auf diesem NFS-Verzeichnis liegt, migrieren kann.

Funktioniert das, folgt der erste Test mit Remus. Schlägt es jedoch fehl, sollte der Admin prüfen, ob der Xend-Relocation-Server in der Datei »/etc/xen/xend-config.sxp« freigeschaltet ist und der Parameter »xend-relocation-hosts-allow« den Zugriff erlaubt.

Remus testen

Die Entwickler empfehlen, zunächst nur die Kopie einer VM zu verwenden, da deren virtuelle Festplatte in diesem ersten Test Schaden nimmt. Hierfür kopiert der Admin das Diskimage auf beide Xen-Dom-0-Hosts, startet die virtuelle Maschine auf einem der beiden Systeme und ruft Remus mit dem folgenden Befehl auf: »remus --no-net Meine-VM Ziel-Dom-0-IP«. Dieser Befehl startet Remus ohne Schutz der Netzwerkverbindungen oder der Festplatte. Die oben erwähnte Pufferung und Synchronisation der Netzwerkpakete entfällt.

Der Bildschirm müsste jetzt ähnliche Meldungen zeigen wie Abbildung 1. Gleichzeitig sollte ein »xm list« auf dem zweiten Xen-Dom-0-System die synchronisierte und pausierte VM anzeigen (Abbildung 2). Hat auch dies funktioniert, kann der Admin im nächsten Test die Replikation der Festplatte hinzunehmen.

Abbildung 1: Alle 200 Millisekunden synchronisiert Remus die virtuellen Maschinen, ein Netzwerkpuffer hält derweil alle Verbindungen zurück.

Abbildung 2: Die Remus-Schattenkopie läuft brav im Hintergrund.

Manche Leser mögen sich schon gefragt haben, wie die Synchronisation der Festplatte in diesem Setup erfolgen soll. Da Remus die Schattenkopie nur in Abständen von 200 Millisekunden synchronisiert, dürfen die aktive virtuelle Maschine und die Schattenkopie nicht dieselbe virtuelle Festplatte nutzen. Remus muss sich also auch um diese Synchronisation kümmern. Dies hat aber auch Vorteile, weil der ITler bei der Planung einer hochverfügbaren Xen-Lösung sich nicht ums SAN oder DRBD kümmern muss.

Die virtuellen Platten sollten sich für Remus auf beiden Xen-Dom-0-Hosts im identischem Pfad befinden. Dabei ist es unerheblich, ob die Dom-U als Festplatte ein Logical Volume, eine Datei oder eine eigene Partition nutzt. Es zählt nur der Eintrag in der Xen-Konfiguration. Für eine einfache Datei erfolgt der Zugriff auf die virtuelle Festplatte über Remus:

disk = [ 'tap:remus:192.168.0.2:9000|aio:\
/images/disk.img,sda1,w' ]

»192.168.0.2:9000« gibt den Ziel-Rechner und -Port für den Abgleich der Festplatte an. Diesen Anschluss erzeugt Remus aber erst während der Synchronisation der Schattenkopie. Die VM kann also nicht auf die Festplatte schreiben, bevor der Admin die Synchronisation mit Remus anwirft. Sie bleibt daher üblicherweise nach der Prüfung der Dateisysteme stehen (Abbildung 3).

Abbildung 3: Erst wenn die Synchronisation mit Remus anläuft, kann die Schattenkopie auf das Festplattenimage zugreifen.