© iofoto, 123RF.com

Die neue Xen-Version 4.0, an Features sowieso nicht arm, nimmt mit Remus auch die fehlertolerante HA-Integration in ihren Schoß auf .

Der Legende nach starb Remus, als ihn sein Zwillingsbruder Romulus nach Streitigkeiten über die Gründungsmodalitäten Roms erschlug. So martialisch geht es in der Virtualisierungsbranche heute nicht zu, aber dass Auguren einen Teilnehmer für tot erklären, passiert häufiger.

Am häufigsten dürfte wohl Xen das Opfer tödlicher Nachrede geworden sein, insbesondere immer dann, wenn der Code es wieder nicht in den Linux-Kernel schaffte [1]. Doch die im April 2010 erschienene Version 4.0 glänzt mit vielen Features, darunter auch die Hochverfügbarkeits-Erweiterung Remus [2].

Remus

Die Entwickler haben sich offensichtlich Mühe gegeben, um dem vermeintlichen Trend hin zu KVM etwas entgegenzusetzen. Xen 4 bringt ein eigenes Festplattenbackend namens Blktap2 mit, das Netzwerkbackend Netchannel2, verbessertes PCI-Passthrough auch für VGA-Karten, Memory Page Sharing und deutlich erhöhte Arbeitsgeschwindigkeit.

Neben dem klassischen Xen-Kernel 2.6.18 unterstützt Xen 4 jetzt auch 2.6.31 und 2.6.32. Dies war bisher unmöglich, da die Entwickler die von dem Xen-Dom-0-Kernel benötigten Funktionen in neuen Kerneln durch die Paravirt-Ops-Schnittstelle (Pvops, [3]) ersetzt und verändert hatten. Dank Entwickler Jeremy Fitzhardinge verwendet Xen jetzt Pvops direkt als Dom-0-Kernel. Trotzdem bleibt 2.6.18 aber immer noch der Referenzkernel, auf dem einige der Neuerungen laufen, zum Beispiel Remus.

Nonstop

Im HA-Umfeld kommt Xen typischerweise in Kombination mit einem SAN, DRBD, Heartbeat oder Pacemaker als Hochverfügbarkeitslösung zum Einsatz. Der Admin installiert den gewünschten Netzwerkdienst in einer virtuellen Maschine, die er auf einem Xen-Host startet. Ein zweiter Host greift über das Storagebackend auf die Festplatte zu. Pacemaker oder Heartbeat prüfen fortlaufend die Verfügbarkeit. Fällt der aktive Xen-Host aus, startet die Clustersoftware die virtuelle Maschine auf dem zweiten Virtualisierungsserver. So minimieren Admins schon heute die Ausfallzeit auf die wenigen Minuten oder Sekunden, die das Booten der virtuellen Maschine auf dem neuen Host benötigt.

Viele Anwendungen überleben jedoch selbst den Ausfall für wenige Minuten nicht. Speziell in der produzierenden Industrie legt der Ausfall eines Steuerungsrechners unter Umständen eine komplette Produktionslinie still, was hohe Kosten nach sich zieht. Hier brauchen Unternehmen so genannte Nonstop- oder fehlertolerante Systeme.

Kommerzielle FT-Software

Hardwarehersteller Stratus Technologies [4] beispielsweise stellt unter dem Namen Ftserver derartige Maschinen her, die im Wesentlichen aus zwei miteinander gekoppelten Systemen bestehen, die exakt synchronisiert die gleichen Programme ausführen. Lediglich eines der beiden Systeme kommuniziert dabei mit der Außenwelt, das zweite verarbeitet als Schattensystem (Shadow) exakt die gleichen Daten und identischen Code. Erkennt das aktive System einen Hardwarefehler, dann übernimmt das zweite System die Kommunikation.

VMware bietet mit Vsphere (siehe eigenen Artikel) ab der Ausbaustufe Advanced eine ähnliche Fehlertoleranz in einer virtualisierten Umgebung an, verlangt dafür aber gut 2000 Euro pro Prozessor. Für Xen gibt es seit Jahren externe Lösungen wie Kemari [5], Second Site [6] und Remus. Die Software mit dem Namen von Romulus\’ Bruder ist seit Xen 4.0.0 fester Bestandteil des Xen-Code.

Für die Implementierung von Fehlertoleranz gibt es zwei verschiedene Ansätze. Entweder stellt die Lösung mit CPU-Lockstepping [7] sicher, dass beide CPUs immer exakt denselben Befehl ausführen. Wenn dann beide Prozessoren sich in einer identischen Umgebung befinden und über gleichen Code und Daten verfügen, kann jede Instanz die andere ersetzen. Zwar erzeugt dieses Vorgehen echte Fehlertoleranz, der benötigte Aufwand ist jedoch enorm.

Remus beschreitet einen anderen Weg: Es geht davon aus, dass die beiden virtuellen Maschinen nicht exakt denselben Zustand besitzen müssen, sondern dass es nur auf die Außenwirkung ankommt. Wenn ein Client keinen Unterschied zwischen dem aktiven System und seinem Schattensystem erkennt, ist das Gesamtsystem im Falle eines Fail-over fehlertolerant, da das zweite System sich exakt genauso verhält wie das erste.

Synchronisation

Remus erreicht dieses Ziel, indem es in 200-Millisekunden-Abständen Migrationen der aktiven virtuellen Maschine auf einen zweiten Host anstößt. Die so gewonnene Kopie der virtuellen Maschine steht als Schattenkopie bereit, während die originale Maschine weiterläuft und nicht wie bei einer Xen-Livemigration zerstört wird. Damit sich der Aufwand in Grenzen hält, überträgt Xen nach der ersten kompletten Migration nur die Dirty Pages, nicht die ganze VM.

Da die Schattenkopie nur alle 200 Millisekunden identisch mit dem aktiven System ist, haben sich die Remus-Entwickler einen Trick einfallen lassen. Zwar arbeitet das aktive System in den 200 Millisekunden weiter, aber der Server puffert alle Netzwerkverbindungen und hält die Pakete zurück, aus Sicht des Clients steht die Antwort also noch aus.

Fällt der aktive virtuelle Gast aus, kann die Schattenkopie die Funktion genau an dieser Stelle übernehmen. Pakete bestehender TCP-Verbindungen, die der Client in der Zeit an den ehemals aktiven Gast versandt hat, fordert die TCP-Protokollschicht automatisch erneut an, diesmal gelangen sie zur Shadow-Instanz.

Im Normalfall jedoch synchronisiert Xen die Schattenkopie nach 200 Millisekunden wieder mit dem aktiven System. Ist die Synchronisation abgeschlossen, erhalten Clients die zurückgehaltenen und für die 200 Millisekunden gepufferten Pakete. Wem diese Reaktionszeiten nicht ausreichen, der kann die Synchronisationsabstände auf bis auf 50 Millisekunden reduzieren Ob sich allerdings der Aufwand mit dem Ressourcenhunger seiner Anwendungen verträgt, muss jeder Admin selbst herausfinden.

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.

Neue Backends

Für diese Synchronisation verwendet Xen das neue Festplattenbackend Blktap2 mit dem Userprozess »tapdisk2«. Sobald der Admin die Synchronisation mit dem Kommandozeilen-Werkzeug »remus –no-net Meine-VM 192.168.0.2« gestartet hat, darf die aktive Maschine ihre Festplatte auch schreibend nutzen und die virtuelle Maschine bootet weiter.

Um das Setup zu testen, kann der Admin die Xen-Konsole zur virtuellen Maschine öffnen (»xm console Meine-VM«) und den Befehl »top« aufrufen. Anschließend zerstört er die Instanz mit »xm destroy Meine-VM« auf dem aktiven Xen-Dom-0-Host oder zieht einfach den Stecker.

Verbindet er sich anschließend mit der Konsole der Schattenkopie, sollte dort der Befehl »top« laufen. Damit sich dieser Schutz auch auf die Netzwerkverbindungen erstreckt, muss der Befehl »remus« ohne die Option »–no-net« gestartet werden. Dann funktioniert der Trick mit dem »top«-Befehl auch über SSH.

Natürlich ist die Fehlertoleranz mit Remus nicht umsonst. Die konstante Synchronisation im Hintergrund verlangsamt auch die virtuelle Maschine. Wie viel Geschwindigkeit verloren geht, hängt von der virtuellen Maschine ab. Je mehr Änderungen im Arbeitsspeicher und auf der Festplatte erfolgen, desto mehr Zeit wird für die Synchronisation aufgewandt und umso weniger Zeit steht der virtuellen Maschine zur Verfügung.

Performance

Im Zweifelsfall muss ein Test zeigen, ob die Geschwindigkeitsverluste durch Remus für den produktiven Einsatz vertretbar sind. Zur Optimierung empfehlen die Entwickler, die automatische Verteilung der Dom-0 und Dom-Us über mehrere Kerne durch den Xen-Scheduler abzuschalten und die Dom-0 und Dom-Us spezifischen Kernen zuzuweisen

Aber trotzdem muss ein Admin den Einsatz von Remus genau abwägen. Die Fehlertoleranz funktioniert nur genau einmal. Ist die Schattenkopie aktiv, existiert keine weitere Instanz, die deren Ausfall abfangen könnte. Xen kann bisher im laufenden Betrieb keinen neuen Shadow anlegen, dies erfordert bisher einen Neustart der Dom-U. Der sollte aber in einem geplanten Wartungsfenster erfolgen, wo er keinen Schaden anrichten kann. Zuvor muss der Admin auch noch die virtuelle Festplatte der Dom-U mit der neuen Schattenkopie synchronisieren.

Wie geht es weiter?

Die Remus-Entwickler haben noch viel vor. Aktuell kann Remus die Fehlertoleranz (auf einem 2.6.18-Dom-0-Kernel) für paravirtualisierte (PVM) und vollvirtualisierte (HVM) Gäste bieten. In zukünftigen Versionen will das Projekt den Quelltext aufräumen und das externe Kommando »remus« in das »xm«-Frontend für die Steuerung aufnehmen. Auch Libvirt-Unterstützung wollen sie anbieten. Für die Realisierung der Hochverfügbarkeit nutzt Remus noch einen eigenen, sehr einfachen Heartbeat-Mechanismus, während Corosync [8] und Pacemaker viel mächtigere Funktionen bieten. Künftige Xen-Versionen sollen deren Integration erlauben.

Noch lange nicht tot

Es bleibt abzuwarten, ob jene Linux-Distributionen, die in der Vergangenheit ihre Unterstützung für Xen als Dom-0 eingestellt haben, es nun wieder integrieren. Genauso spannend ist es zu beobachten, ob die neue Version den Druck auf die Kernelentwickler erhöht, Xen in den Linux Kernel aufzunehmen.

Grundsätzlich bietet KVM ähnliche oder gleichwertige Funktionen wie Xen und wahrscheinlich werden deren Entwickler die neue Xen-Version als Herausforderung sehen, auch Fehlertoleranz anzubieten. Ein größeres Problem für den Einsatz von Remus in produktiven Umgebungen stellt sicherlich der Mangel an administrativen Oberflächen mit Remus-Unterstützung dar. Xen abzuschreiben, wäre aber auf jeden Fall verfrüht. (mfe)