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.