Fehlertoleranz mit Xen 4 und Remus

hypermania2, 123RF

Lebenszeichen

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 angeblichen 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.

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 Fehlertoleranz

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 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 http://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.

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.

comments powered by Disqus
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe  04/2014