Hardware-Fehlertoleranz mit Hochverfügbarkeit

Transkript

1 Hardware-Fehlertoleranz mit Hochverfügbarkeit Seminar: Softwarebasierte Fehlertoleranz Lars Rademacher TU Dortmund - Fakultät für Informatik LS12 - Arbeitsgruppe Eingebettete Systemsoftware Prof. Dr.-Ing. Olaf Spinczyk 1 Einleitung Hardware-Fehlertoleranz findet seine Anwendung in unterschiedlichsten Bereichen. Ein wachsendes Feld liegt bei den Internet-Dienst-Anwendungen, welche auf Hochverfügbarkeit ausgelegt sind. Tritt hier innerhalb eines Jahres nur ein Fehler auf, der ein System zum Absturz bringt, so können vereinbarte Anforderungen an die Verfügbarkeit teilweise nicht mehr erfüllt werden. Aus diesem Grund ist bei hochverfügbaren Systemen Fehlertoleranz ein wichtiges Mittel zur Einhaltung derartiger Anforderungen. Virtuelle Maschinen (im Folgenden auch kurz: VM) lassen sich gut zur Verteilung von Hardware-Ressourcen eines Hardware-Systems auf mehrere Rechensysteme verwenden, wobei sie trotzdem voneinander isoliert sind. Daher finden derartige Systeme einen besonders großen Anwendungsbereich bei Server- Anwendungen. Aus den genannten Gründen ist es sinnvoll, die Anwendung von Hardware- Fehlertoleranz auf virtuellen Maschinen zu untersuchen. Diese Seminarausarbeitung beschäftigt sich mit Remus [3], einem System, welches Verfügbarkeit durch VM-basierte Fehlertoleranz erhöht. Es wird zunächst in Abschnitt 2 auf die Grundlagen der Hardware-Fehlertoleranz eingegangen, wobei schwerpunktmäßig das System Checkpointing and Rollback Recovery thematisiert wird. Hierbei werden die Grundbegriffe der Fehlertoleranz und die an sie gestellten Anforderungen erläutert. In Abschnitt 3 wird darauf aufbauend Remus in seinen technischen Details diskutiert und es wird eine Evaluation vorgestellt auf deren Basis eine Bewertung des Systems erfolgt. Abschließend werden in Abschnitt 4 die gewonnenen Erkenntnisse zusammengefasst. 2 Hardware-Fehlertoleranz Um Hardware-Fehlertoleranz betreiben zu können, muss zunächst untersucht werden, welche Arten von Fehlern in einem System auftreten können. Hierbei wird einerseits nach der Lokalität des Fehlers und andererseits nach der Dauer seiner Auswirkung unterschieden. Mechanismen für Fehlertoleranz betrachten oft schwerpunktmäßig Fehler im Arbeitsspeicher und dem Prozessorzustand [1].

2 2 Hardware-Fehlertoleranz mit Hochverfügbarkeit Allerdings treten Fehler auch an anderen Orten, wie beispielsweise dem Cache- Speicher oder in der System-Peripherie auf. Fehler können sich von den verschiedensten Orten des initialen Auftretens in den Rest des Systems propagieren und somit in weiteren Lokalitäten Fehler einbringen, wenn keine frühzeitige Erkennung erfolgt. In Hardware auftretende Fehler werden nach der Dauerhaftigkeit ihres Bestehens in die drei Typen der transienten, permanenten und diskontinuierlichen Fehler unterteilt [1]. Bei transienten Fehlern handelt es sich um einmalig fehlerhafte Zustände, welche nach einer Korrektur nicht weiterbestehen [1]. Es liegt somit kein dauerhafter Defekt, sondern ein temporärer Fehlzustand vor. Transiente Fehler können beispielsweise durch elektromagnetische Interferenzen hervorgerufen werden. Permanente Fehler sind ab dem Zeitpunkt ihres Auftretens dauerhaft vorhanden [1]. Sie können nur bewältigt werden, indem der betroffene Teil der Hardware für zukünftige Nutzung ausgeschlossen bzw. repariert wird. Derartige Fehler werden durch physikalische Defekte der Hardware, wie beispielsweise der Auftrennung einer Leiterbahn, hervorgerufen. Schließlich handelt es sich bei diskontinuierlichen Fehlern um permanente Fehler, die sich jedoch nur zu einem Teil der Zeit ihres Bestehens auswirken [1]. Sie wechseln zwischen einem aktiven und einem ruhenden Zustand. Eine Ursache für derartiges Fehlverhalten ist beispielsweise eine fehlerhafte Steckverbindung oder ein defekter Lötkontakt. Verfahren zur Steigerung der Hardware-Fehlertoleranz gehen im Allgemeinen von einem Fehlermodell aus, welches Teile dieser Klassen und ein Modell für ihr Auftreten berücksichtigt [1]. Das Modell wird mittels einer initialen Analyse des Systems angefertigt. Durch die Verwendung eines solchen Fehlermodells können Einschränkungen getroffen werden, durch welche die Aufgaben eines Verfahrens für Fehlertoleranz reduziert werden können. Tritt ein Hardware-Fehler auf, der im Modell nicht berücksichtigt ist, so wird dieser vom fehlertoleranten System nicht berücksichtigt. Sieht das Modell beispielsweise nur die Korrektur transienter Fehler vor, so kann ein permanenter Fehler vom Verfahren in der Regel nicht korrigiert werden. Es hängt demnach von der Systemanalsye ab, wie gut das Fehlermodell die tatsächlich auftretenden Fehler beschreibt und ob alle tatsächlich auftretenden Fehler vom System korrigiert werden können. Fehlertoleranz kann mittels Verfahren der zwei Klassen der Rückwärts-Fehlerbehebung und der Vorwärts-Fehlerbehebung gewährleistet werden [2], wobei der Unterschied darin liegt, ob erst nach dem Auftreten eines Fehlers eine Korrektur ausgeführt wird (Rückwärts-Fehlerbehebung), oder ob im Fehlerfall bereits ein weiteres fehlerfreies System vorhanden ist (Vorwärts-Fehlerbehebung), mit dem weitergearbeitet werden kann [1]. Ein Beispiel für Rückwärts-Fehlerbehebung ist das im Folgenden noch genauer betrachtete Checkpointing. Hierbei werden regelmäßig Systemabbilder gesichert und im Fehlerfall wieder in das System eingespielt. Ein Fehler muss bei diesen Systemen demnach erkannt und entfernt werden. Vertreter der Vorwärts-Fehlerbehebung sind beispielsweise sogenannte Triple Modular Redundant-Strukturen, welche ein abzusicherndes (Hardware-

3 Hardware-Fehlertoleranz mit Hochverfügbarkeit 3 oder Software-)Modul dreifach instanziieren und zeitgleich ausführen [1]. Anschließend wird mittels eines Mehrheitsentscheids das fehlerfreie Ergebnis bestimmt, auch wenn in einem der drei Module ein Fehler aufgetreten ist, welcher potenziell die Berechnung eines falschen Ergebnisses hervorrufen könnte. Die grundsätzlichen Aufgaben eines fehlertoleranten Systems liegen in der Detektion von aufgetretenen Fehlern und in der Wiederherstellung eines fehlerfreien Zustands. Nachfolgend werden Anforderungen an diese Operationen erläutert. Da Hardware-Fehler wie bereits erwähnt an verschiedenen Orten im System auftreten können, sollte eine Fehlerdetektion Fehler in den verschiedenen Bereichen erkennen können. Eine weitere Anforderung an die Fehlerdetektion besteht darin, dass Fehler frühzeitig gefunden werden, um ihre Propagation durch das System zu verhindern und eine aufwendige Reparatur des Zustands zu vermeiden. Die Wiederherstellung eines fehlerfreien Zustands und die dafür nötigen Absicherungsvorgänge sollten einen möglichst geringen Ressourcenverbrauch aufweisen, damit der Einsatz von Fehlertoleranz keinen zu hohen Mehraufwand erzeugt. Auch sollte der Zeitaufwand für eine Wiederherstellung minimal sein, um die Verfügbarkeit des Systems nicht zu stark zu beeinträchtigen. Den bereits beschriebenen verschiedenen Fehlertypen kann mit unterschiedlichen Wiederherstellungsmaßnahmen begegnet werden. Während transiente Fehler nur die Korrektur der befallenen Daten erfordern, muss bei permanenten Fehlern die defekte Hardware als nicht weiter benutzbar identifiziert werden [1]. Bei der Wiederherstellung muss darauf geachtet werden, dass aus ihren Maßnahmen kein inkonsistenter Gesamtzustand des Systems resultiert [1]. Dies ist insbesondere bei verteilten Systemen und bei Systemen mit externer Kommunikation zu beachten, da in diesen Fällen der interne Systemzustand per Nachrichtenversand in die anderen Systeme übergeben wird. Bei einer Zurücksetzung auf einen alten Zustand sind somit die Zustände nicht mehr konsistent. Im Folgenden wird in Abschnitt 2.1 zunächst auf das Verfahren Checkpointing and Rollback Recovery eingegangen. Daran anschließend wird in Abschnitt 2.2 der Begriff der Systemverfügbarkeit erläutert, wobei es sich um eine Anforderung an Rechensysteme handelt, die durch Fehlertoleranz verbessert werden kann. Abschließend werden in Abschnitt 2.3 Techniken zur Erzeugung von Fehlertoleranz vorgestellt, die auf der Ausführung auf einer virtuellen Maschine basieren. 2.1 Checkpointing and Rollback Recovery Checkpointing and Rollback Recovery im Folgenden auch als Checkpointing abgekürzt ist ein Verfahren der Rückwärts-Fehlerbehebung, bei dem in regelmäßigen Abständen Abbilder des Systemzustands die sogenannten Checkpoints angelegt werden, um im Fehlerfall einen Checkpoint wiederherzustellen und von diesem aus die Berechnung erneut auszuführen. Ein Checkpoint besteht im Allgemeinen aus dem Inhalt des Hauptspeichers und dem Prozessorzustand zu einem Zeitpunkt [1], kann aber noch weitere Systeminhalte enthalten. Zum

4 4 Hardware-Fehlertoleranz mit Hochverfügbarkeit Anlegen des Checkpoints muss der Rechner angehalten werden, da sich der Zustand ohne diese Maßnahme potenziell während seiner Aufnahme ändern könnte. Das Fehlermodell, welches beim Checkpointing im Allgemeinen zugrunde gelegt wird, sieht nur transiente Fehler vor. Durch diese Annahme ist legitimiert, dass bei erneuter Ausführung der Software auf unveränderter Hardware angenommen wird, dass transiente Fehler entfernt wurden [1]. Jedoch kann Checkpointing auch bei permanenten und diskontinuierlichen Fehlern eingesetzt werden, wenn bei der Systemwiederherstellung die Ausführungshardware gewechselt wird. Es ist ebenfalls vom Fehlermodell abhängig, wie viele Checkpoints gleichzeitig im System vorgehalten werden. Wird davon ausgegangen, dass die Fehlerdetektion Fehler erst spät erkennt, so müssen auch ältere Checkpoints vorgehalten werden. Der vorhandene Speicherplatz stellt die einzige Begrenzung der Anzahl gleichzeitig gesicherter Checkpoints dar. Anwendung Sicherung CP n CP n+1 Latenz Mehraufwand Abbildung 1. Schematische Darstellung von Latenz und Mehraufwand aufeinanderfolgender Checkpoints nach [1] Der Erstellungsaufwand für Checkpoints lässt sich in die zwei Teile der Latenz und des Mehraufwands auftrennen [1]. Während es sich bei der Latenz um die Gesamtzeit der Erstellung handelt, bezeichnet der Mehraufwand die Zeitspanne, für die die laufende Anwendung zur Erstellung des Abbildes angehalten werden muss. Die restliche Verarbeitung beispielsweise eine Sicherung des Checkpoints auf einem Festspeicher kann simultan zum Fortlauf des Prozesses durchgeführt werden. Abbildung 1 zeigt eine schematische Darstellung der aufeinander folgenden Generierung zweier Checkpoints (n und n + 1). Hierbei ist ist die Latenz durch die Gesamtlänge eines Sicherungs-Blocks und der Mehraufwand durch dessen roten Anteil dargestellt. Der Mehraufwand ist zu minimieren, da er sich direkt auf die Gesamtlaufzeit der zu sichernden Anwendung addiert und da er die Verfügbarkeit der Applikation reduziert. Die Größe der Gesamtlatenz hat einen weniger kritischen Einfluss auf die Performanz des Systems, da der vom Mehraufwand verschiedene Anteil parallel zur Systemausführung durchgeführt werden kann.

5 Hardware-Fehlertoleranz mit Hochverfügbarkeit 5 Es existieren verschiedene Techniken zur Reduktion des Mehraufwands, von denen im Folgenden das Incremental Checkpointing vorgestellt wird, da es bei dem in Abschnitt 3 vorgestellten Verfahren zur Anwendung gebracht wird. Bei dieser Technik wird nicht in jedem Checkpoint der gesamte zu sichernde Speicherbereich gesichert, sondern es werden nur die seit der Erstellung des vorherigen Checkpoints veränderten Anteile des Speichers in Form von Inkrementen gespeichert [1]. Durch dieses Verfahren kann die vom Auslesen des Speichers dominierte Zeit für das Anlegen eines Checkpoints deutlich verringert werden. Zusätzlich wird der Speicherbedarf deutlich reduziert. In regelmäßigen Abständen werden vollständige Speicherabbilder sogenannte primäre Checkpoints angelegt, auf die eine festgelegte Anzahl an Inkrementen sekundäre Checkpoints folgt. Im Fehlerfall wird zunächst der aktuellste primäre Checkpoint in den Speicher zurückgeladen, um dann zusätzlich in zeitlich fortschreitender Sortierung die Inkremente wiederherzustellen. Durch die regelmäßige Anfertigung von primären Checkpoints wird erreicht, dass im Fall einer Wiederherstellung nicht alle Inkremente von Beginn der Ausführung an in den Speicher geladen werden müssen, da dadurch die Wiederherstellung potenziell sehr zeitintensiv ausfallen würde. Eine Variation des Verfahrens besteht in dem Speichern eines einzigen Checkpoints, welcher mit den neu erstellten Inkrementen regelmäßig aktualisiert wird. Dieses Verfahren finder bei Remus Anwendung [3]. Es kann somit Speicherplatz und Berechnungszeit bei der Wiederherstellung gespart werden, allerdings ist immer nur der aktuellste Checkpoint im System vorhanden. Das Verfahren besitzt den Parameter der Granularität, welcher sich dadurch auszeichnet, dass die Elemente der Inkremente eine definierte Größe aufweisen. Insbesondere hängt diese Größe oft von der Methodik zur Detektion von Schreibvorgängen ab. Teilweise können dazu Hardware-Funktionen der virtuellen Speicherverwaltung genutzt werden, wobei der Granularitätsgrad bei der Größe einer Speicherseite liegt [3]. Allgemein ist bei diesem Parameter ein Kompromiss aus Genauigkeit und Geschwindikeit der Detektion von Speicherzustandsänderungen zu finden. 2.2 Systemverfügbarkeit Systemverfügbarkeit ist insbesondere für Serveranwendungen eine kritische Anforderung. In der Praxis werden von Dienst-Anbietern Verfügbarkeiten in Form sogenannter Service Level Agreements (kurz: SLA) garantiert. Daraus resultiert eine harte Bedingung an Serversysteme. Ein System wird als hochverfügbar bezeichnet, wenn es eine jährliche Ausfallzeit von etwa fünf Minuten nicht überschreitet, was einer Verfügbarkeit von ca. 99,999 % entspricht [6]. Im Hinblick auf die Einhaltung von SLA s ist es nicht sinnvoll, im Falle eines Hardware-Fehlers eine zeitaufwendige Wiederherstellung des Zustands durchzuführen, da somit die Bedingungen an die Systemverfügbarkeit potenziell nicht eingehalten werden können. Im Idealfall ist die durch eine Wiederherstellung hervorgerufene Latenz des Dienstes bei den Service-Nutzern nicht bemerkbar. Es sollten demnach im Fehlerfall auch keine Anteile der Kommunikation verloren gehen, die somit eine wiederholte Sendung von Nachrichten bedingen würde.

6 6 Hardware-Fehlertoleranz mit Hochverfügbarkeit Dienstausführung Fehler Dienstunterbrechung Detektion Melden, korrigieren, reparieren Latenz Abbildung 2. Schematische Darstellung der Zustände eines fehlertoleranten Servers mit Anzeige der durch einen Fehler bedingten Latenz nach [6] Abbildung 2 stellt die Arbeitsweise eines fehlertoleranten Servers schematisch dar. Im Normalfall befindet sich das System im Zustand der Dienstausführung, geht jedoch im Fehlerfall in einem Unterbrechungszustand über. In diesem Zustand wird je nach der benötigten Zeit für die Detektion des Fehlers und seine Behebung eine Latenz generiert. Bei der Wiederherstellung von Checkpoints wird der Zustand des Systems zusätzlich zu der Ausfallzeit noch auf einen früheren Zustand zurückgesetzt, wodurch die Latenz weiter erhöht wird. Dies hat zwei Konsequenzen. Zunächst muss die Frequenz der Erstellung von Checkpoints möglichst hoch sein, damit der durch die Wiederherstellung bedingte Rücksprung möglichst kurz ausfällt. Außerdem müssen aus gleichen Gründen Hardware-Fehler frühzeitig erkannt werden. Da die hier beschriebene Verfügbarkeits-Latenz direkt von der durch die Wiederherstellung verursachte Ausfallzeit des Systems abhängt, sind typische Checkpointing-Verfahren schlecht für hochverfügbare Systeme geeignet, da die Wiederherstellung mit dem Einspielen eines Systemabbildes sehr zeitaufwendig ist. 2.3 VM-basierte Systeme Fehlertoleranz mithilfe von Systemen auf Basis von virtuellen Maschinen bietet den Vorteil, dass Komplettsysteme ohne Anpassung des Betriebssystems gesichert werden können [3]. Ein VM-basiertes fehlertolerantes System ist für Anwendungen und Betriebssystem vollständig transparent. Demnach muss für den Einsatz lediglich der Hypervisor modifiziert werden, Betriebssystem und Anwendung bleiben in ihrer ursprünglichen Form. Beispielsweise ermöglicht das vsphere Fault Tolerance-System [7] für vmware die Replizierung einer virtuellen Maschine (primäre VM ) auf einem anderen Hardware-Host, der sogenannten sekundären VM. Die sekundäre VM erhält die Netzwerk- und Benutzereingaben, asynchrone Ein-/Ausgaben, CPU-Timer und Ereignisse der primären VM, wodurch beide Maschinen exakt synchronisiert werden. Im Fehlerfall kann die sekundäre VM die Aufgabe des Originals unmittelbar übernehmen. Anschließend wird eine neue sekundäre VM gestartet, um

7 Hardware-Fehlertoleranz mit Hochverfügbarkeit 7 den fehlertoleranten Zustand wiederherzustellen. Durch dieses Verfahren wird besonderer Wert auf die Systemverfügbarkeit gelegt, jedoch werden somit alle Berechnungen redundant ausgeführt und es entsteht ein hoher Synchronisationsaufwand. In [3] wird auf die Schwächen derartiger Systeme eingegangen. Für die Synchronisation beider Hosts wird ein sehr exaktes Wissen über die Reaktion auf Ereignisse auf Instruktionsebene vorrausgesetzt. Zusätzlich wird durch die Synchronisation ein nicht akzeptabler Mehraufwand erzeugt, wenn das Verfahren auf einem Multikern-System eingesetzt werden soll, da hier jede Kommunikation zwischen den Kernen auf dem geteilten Speicher detektiert und übertragen werden muss. Diese Problematik wird bei Remus, dem im Folgenden betrachteten VM-basierten System, mittels einer anderen Sicherungsstrategie umgangen. 3 Remus Remus, ein Verfahren zur Steigerung von Fehlertoleranz in VM-basierten Systemen, wurde als Erweiterung für den Xen virtual machine monitor [5] einem quelloffenen Hypervisor entwickelt [3]. Zur Steigerung werden komplette virtuelle Maschinen auf einem zweiten Hardware-System repliziert und im Fehlerfall wird die Ausführung auf diesem Sicherungs-Rechner fortgeführt. Die Sicherung erfolgt auf Ebene des Hypervisors und ist damit vollständig transparent für die zu sichernde Maschine und die darauf laufenden Anwendungen. Es werden Prozessor-Zustand, Speicherinhalt und Festplattenspeicher gesichert. In seiner grundlegenden Arbeitsweise entspricht Remus dem bereits vorgestellten Incremental Checkpointing. Der Systemzustand wird allerdings auf einem zweiten Host-Rechner gesichert [3], sodass Remus nicht nur gegen transiente, sondern auch gegen permanente und diskontinuierliche Hardware-Fehler tolerant ist. Es wird nur der aktuellste Checkpoint gesichert. Dieser liegt immer bereits im Arbeitsspeicher vor, damit er sehr schnell ausgeführt werden kann. Somit wird die Unterbrechung der Verfügbarkeit im Fehlerfall minimiert. Remus liegt ein Fehlermodell zugrunde, welches vorsieht, dass Fehler unmittelbar nach ihrem Auftreten erkannt werden, da es keine Möglichkeit gibt, ältere Checkpoints ins System einzuspielen [3]. Es wird davon ausgegangen, dass sowohl transiente, als auch diskontinuierliche und permanente Fehler auftreten können. Es gibt keine Einschränkung bezüglich des Orts des Auftretens. Im Folgenden wird in Abschnitt 3.1 zunächst die Architektur von Remus erläutert, um anschließend in Abschnitt 3.2 auf die Funktion der Sicherung und in Abschnitt 3.3 auf die Wiederherstellung im Fehlerfall einzugehen. Anschließend wird in Abschnitt 3.4 ein Vergleich zur Xen-Live-Migration einem System zum Hostwechsel während der Ausführungszeit gezogen. Schließlich wird eine Evaluation und Bewertung des Systems bezüglich seiner Performanz und der Erfüllung bereits vorgestellter Anforderungen in Abschnitt 3.5 vorzustellen.

8 8 Hardware-Fehlertoleranz mit Hochverfügbarkeit 3.1 Architektur Die Architektur von Remus wird in Abbildung 3 in einem schematischen Überblick dargestellt. Das Grundsystem besteht aus zwei Rechnern, die per Ethernet verbunden sind [3]. Der sogenannte Active Host ist das System, auf dem die abzusichernde virtuelle Maschine ausgeführt wird und der Backup Host ist ein Empfänger für Checkpoints, auf dem sich potenziell mehrere Backup VM s befinden können. Jede Backup VM ist das Replikat einer Protected VM. Die Sicherung mehrere virtueller Maschinen auf einem Backup Host ist möglich, da dieser einer geringeren Belastung als der Active Host ausgesetzt ist. Durch diese Möglichkeit erlangen Systemadministratoren ein Werkzeug, um einen individuellen Kompromiss zwischen Redundanz und Ressourcenkosten für eine Menge von Hardware-Hosts zu finden. Im Fehlerfall in einer Protected VM wird die entsprechende Backup VM gestartet und diese übernimmt die Ausführung nach einer minimalen Unterbrechungszeit [3]. Aufgrund der Annahme, dass Hardware-Fehler selten auftreten, ist die Wahrscheinlichkeit für zeitgleiche Fehler auf verschiedenen Hosts sehr gering. Daher ist es legitim, einen Backup Host als Sicherung für mehrere Active Hosts zu verwenden. Durch diese Maßnahme lässt sich der zusätzlich nötige Hardware-Aufwand zur Sicherung zahlreicher Rechensysteme, soweit Netzwerkbelastung und Ressourcenverbrauch es erlauben, minimieren. (Weitere) Active Hosts Protected VM Replication Engine Replication Server Backup VM's Heartbeat Heartbeat Speicher Speicher Externe Geräte Festspeicher Hypervisor Hypervisor Externes Netzwerk Active Host Backup Host Abbildung 3. Schematische Übersicht der Remus-Architektur nach [3] Für die Realisierung der Zustandssicherung wird auf dem Active Host eine sogenannte Replication Engine eingesetzt. Der zugehörige Empfänger von Sicherungspaketen ist auf dem Backup Host als Replication Server realisiert. Beide sind mittels einer Ethernet-Verbindung gekoppelt [3]. Die Registrierung eines Fehlers erfolgt durch einen Austausch von sogenannten Heartbeat-Nachrichten. Empfängt einer der Hosts innerhalb einer Zeitbeschränkung keine Heartbeat- Nachricht, ist aber selber noch laufbereit, so wird angenommen, dass der andere

9 Hardware-Fehlertoleranz mit Hochverfügbarkeit 9 Host aufgrund eines Fehlers nicht mehr arbeitet. Ein Fehler auf der Verbindungsstrecke wird mittels einer redundanten Auslegung der Ethernet-Verbindung zwischen Replication Server und Replication Engine minimiert. Die Details von Sicherung und Wiederherstellung werden in den folgenden Abschnitten genauer erläutert. 3.2 Sicherung Remus repliziert den Prozessorzustand sowie Speicher- und Festplatten-Inhalt. Auf eine Replizierung von ausgehenden Netzwerkpaketen wird verzichtet, da Netzwerke im Gegensatz zu interner Rechner-Hardware als fehleranfällig ausgelegt sind. Die Sicherung des Speichers erfolgt auf dem Granularitätsgrad von Speicherseiten [3]. Zur Detektion von Schreibvorgängen im Speicher wird eine Technik der Xen-Live-Migration verwendet. Auf die Xen-Live-Migration wird in Abschnitt 3.4 noch genauer eingegangen. Es wird eine sogenannte Shadow Page Table angelegt, welche eine Kopie der Seitentabelle des Gastsystems darstellt. Die Shadow Page Table zeigt mittels sogenannter Dirty Flags an, ob auf einer Seite seit der letzten Generierung eines Checkpoints geschrieben wurde. Das automatisierte Setzen des Dirty Flags kann mittels einer Funktion der virtuellen Speicherverwaltung erzielt werden, bei der der gesamte Speicher als nicht beschreibbar markiert wird, was bei einem Schreibvorgang eine abfangbare Unterbrechung auslöst. Als Unterbrechungsbehandlung wird das Setzen des entsprechenden Dirty Flags implementiert. Somit ist beim Anlegen eines Checkpoints eine Liste zu sichernder Speicherseiten vorhanden, die das Inkrement beschreibt. Nachdem ein Checkpoint angelegt wurde, werden alle Dirty Flags wieder deaktiviert. Um einen konsistenten Zustand bei aktiver ausgehender Kommunikation garantieren zu können, darf kein ausgehender Netzwerkverkehr freigegeben werden, bis der folgende Checkpoint auf dem Backup Host gesichert ist [3]. Würde diese Einschränkung nicht eingehalten werden, so könnte der Server ausgehende Nachrichten versenden und anschließend fehlschlagen, sodass eine Wiederherstellung auf einen Zustand vor dem Nachrichtenversand durchgeführt wird. In diesem Fall wäre die Konsistenz des Gesamtsystems nicht mehr gegeben. Daher wird ein Puffer mit ausgehenden Netzwerkpaketen solange gefüllt bis eine Bestätigung vom Backup Host über den erfolgreichen Empfang eines konsistenten Checkpoints eintrifft. Dann werden alle im Puffer befindlichen Nachrichten sofort versendet. Das Vorgehen hat den weiteren Vorteil, dass keine fehlerhaft berechneten Ergebnisse nach außen abgegeben werden. Um auch den Zustand der Festspeicher von Active und Backup Host zu synchronisieren, muss dieser ebenfalls übertragen werden. Schreibvorgänge auf der Festplatte des Primary Host werden unmittelbar asynchron an den Backup Host übertragen, wo sie bis zum Eintreffen eines Checkpoints gepuffert werden [3]. Nach einer Prüfung des Checkpoints auf Daten-Konsistenz wird der gepufferte Festplatteninhalt auf die Backup-Festplatte geschrieben. Durch die Pufferung

10 10 Hardware-Fehlertoleranz mit Hochverfügbarkeit der Festplatteninhalte bleibt der Zustand auf dem Backup Host weiterhin konsistent. Die asynchrone Übertragung von Festplatteninhalten kann ohne Anhalten des Primary Host durchgeführt werden. Eine Konsequenz aus den in Abschnitt 2.2 erläuterten Anforderungen an hochverfügbare Systeme ist, dass im Fehlerfall ein zeitlich nicht weit zurückliegender Checkpoint vorhanden sein muss, um eine möglichst kurze Wiederherstellungslatenz zu garantieren. Daher wurde die Frequenz für das Checkpointing bei Remus in der Größenordnung von bis zu 40 Checkpoints pro Sekunde gewählt [3]. Ein weiterer Grund für das sehr kurze Checkpointing-Intervall liegt in der Pufferung des ausgehenden Netzwerkverkehrs. Dieser Puffer muss hochfrequent abgearbeitet werden, damit das System aus Sicht des Client reaktiv bleibt. Active Host Vollendete Ausführung Backup Host Gesicherter Zustand 1 Spekulative Ausführung 2 3 Aktualisierter Zustand 1 Checkpoint 2 Übertragung 3 Synchronisation 4 Freigabe Sicht des Client 4 Vorheriger Zustand Aktualisierter Zustand Zeit Abbildung 4. Darstellung der spekulativen Ausführung nach [3] Die Zustandssicherung erfolgt in vier Schritten, die in Abbildung 4 schematisch dargestellt werden [3]. Im ersten Schritt wird die Ausführung des Active Host unterbrochen und die zu übertragenden Daten (Speicher-Inkremente und Prozessorzustand) werden in einen Puffer ausgelesen. Schritt 2 stellt die Übertragung des Puffers zum Backup Host dar, wobei zu Beginn dieses Schrittes der Active Host bereits wieder aktiviert wird und mit der sogenannten spekulativen Ausführung fortfährt. Die Ausführung wird spekulativ genannt, da zu dem Zeitpunkt noch nicht klar ist, ob der übertragene Checkpoint vom Backup Host (aufgrund seiner Konsistenz) akzeptiert wird. Im dritten Schritt werden die übertragenen Daten auf dem Backup Host überprüft und das vorliegende VM-Abbild wird aktualisiert. Zusätzlich werden die Änderungen am Festplattenzustand in die Backup-Festplatte eingepflegt. Im letzten Schritt wird eine Bestätigung an den Active Host übertragen, welcher umgehend beginnt, den Puffer für ausgehende Netzwerkkommunikation abzuarbeiten. Es wird deutlich, dass die spekulative Ausführung gegenüber einer Blockierung bis zur erfolgreichen Einpflegung des aktuellen Checkpoints einen klaren zeitlichen Vorteil bietet.

11 Hardware-Fehlertoleranz mit Hochverfügbarkeit Wiederherstellung Da die Entwicklung von Remus nicht schwerpunktmäßig die Entwicklung einer spezielle Technik zur Fehlerdetektion vorsah, wurde zu diesem Zweck ein naiver Mechanismus verwendet [3]. Die implementierte Fehlerdetektion besteht in der Überwachung der Kommunikation zwischen Active Host und Backup Host. Da in festen Intervallen Checkpoints vom Active Host übertragen werden und die Einpflegung jedes Checkpoints vom Backup Host mit einer Nachricht bestätigt wird, ist ein Nachrichtenversand pro Checkpoint-Intervall in beiden Richtungen garantiert. Es wird auf beiden Seiten untersucht, ob innerhalb eines festgelegten Zeitintervalls eine Nachricht vom Kommunikationspartner erhalten wurde. Ist dies nicht der Fall, so wird angenommen, dass der andere Host aufgrund eines aufgetretenen Hardware-Fehlers nicht mehr lauffähig ist. Somit wurde eine Heartbeat- Funktion implementiert, die ohne zusätzliche Belastung der Netzwerkverbindung auskommt. Mittels dieser Fehlerdetektion können nur Systemabstürze detektiert werden. Allerdings führen Hardware-Fehler oft nicht (unmittelbar) zu einem Absturz des Systems. Eine weitere Schwachstelle dieses Verfahrens liegt bei der Netzwerkverbindung beider Hosts. Fällt die Ethernet-Verbindung aus, so können keine Datenpakete mehr übertragen werden. Beide Hosts gehen dann davon aus, dass der jeweils andere Host ausgefallen ist. Somit stellt der Active Host das Checkpointing ein und der Backup Host startet die Ausführung. In diesem Fall laufen zwei Instanzen des Systems, was zu einem undefinierten Gesamtverhalten führt [3]. Um die Wahrscheinlichkeit für einen Netzwerkausfall zu reduzieren, ist die Ethernet-Verbindung redundant ausgelegt. Dennoch besteht die Möglichkeit, dass der Problemfall eintritt. Da auf dem Backup Host durch die regelmäßige Sicherung ein ausführbereites VM-Abbild vorliegt, kann dieses direkt ausgeführt werden, wenn ein Fehler auf dem Active Host detektiert wurde. Somit kann erreicht werden, dass die Wiederherstellung nur minimale Zeit in Anspruch nimmt, was in Abschnitt 3.5 evaluiert wird. 3.4 Vergleich: Xen-Live-Migration Remus nutzt Teile der in Xen eingebetteten Xen-Live-Migration. Um Ähnlichkeiten und Unterschiede beider Verfahren zu beschreiben, wird ein kurzer Vergleich der Systeme durchgeführt. Bei der Xen-Live-Migration handelt es sich um ein Verfahren für einen schnellen manuellen Wechsel des Hosts einer VM während des Betriebs [3]. Ein solcher Hostwechsel kann beispielsweise für Wartungsarbeiten an der Rechner-Hardware nötig sein, während derer diese Hardware nicht für die Ausführung der virtuellen Maschine genutzt werden kann. Es wird besonderer Wert auf die Verfügbarkeit des Systems gelegt, weshalb eine möglichst minimale Unterbrechung des Dienstes nach außen angestrebt wird. Remus hingegen führt regelmäßige Replizierungen durch, um nach der Erkennung eines Fehlers automatisch das bereits übertragene VM-Replikat zu starten.

12 12 Hardware-Fehlertoleranz mit Hochverfügbarkeit Wird die Xen-Live-Migration von einem Systemadministrator aktiviert, so wird zunächst der Speicher der virtuellen Maschine während ihrer Ausführung auf den neuen Host kopiert [3]. Schreibvorgänge auf dem Speicher während dieses Vorgangs werden auf Seitenebene registriert, wie bereits in Abschnitt 3.2 beschrieben wurde. Die entsprechenden Seiten werden zusätzlich übertragen. Da der laufende Prozess potenziell viele schreibende Speicherzugriffe durchführen kann, ist es im Allgemeinen nicht möglich mit diesem Verfahren die Speicher beider Systeme zu synchronisieren [3]. Nach einer definierten Anzahl an Übertragungsintervallen wird daher die laufende VM angehalten, um den restlichen beschriebenen Speicher zu übertragen. Hierbei wird zusätzlich der Zustand des Prozessors übertragen. Da nach dem Anhalten nur noch ein kleiner Anteil des gesamten Hauptspeichers übertragen werden muss, ist die Unterbrechung als kurz anzunehmen. Nach vollendeter Übertragung kann das Abbild der virtuellen Maschine auf dem neuen Host gestartet und von dem alten Host entfernt werden. Die Zeit, in der das zu sichernde System nicht verfügbar ist, ist abhängig von der Größe des Speichers, der nach dem Anhalten noch übertragen werden muss. Untersuchungen in [3] haben gezeigt, dass diese Zeit im Mittel bei etwa 100 ms liegt. Bei Remus lag die Zeit für eine Übernahme durch den Backup Host immer unter einer Sekunde, womit die Ausfallzeit höher ist als bei der Xen-Live-Migration. Es zeigt sich, dass der grundsätzliche Ansatz von Xen-Live-Migration und Remus sehr ähnlich sind. In beiden Fällen wird eine virtuelle Maschine auf einen anderen Host transferiert und ausgeführt, wobei die Ausfallzeit minimiert wird. Der Unterschied liegt in der Motivation zur Systemreplizierung. So wird bei Remus das Auftreten eines Fehlers erwartet, während die Xen-Live-Migration davon ausgeht, ein funktionierendes System auf einen anderen Host zu übertragen. Aus dieser unterschiedlichen Erwartung resultiert, dass bei Remus während der gesamten Systemlaufzeit regelmäßig Replizierungen durchgeführt werden, da ein nachträgliches Übertragen eines VM-Abbildes im Fehlerfall auch die Übertragung von fehlerhaften Systemteile beinhalten würde. Aus diesem Grund ist das Verfahren besonders auf niedrigen Mehraufwand ausgelegt [3]. So werden bei Remus die Speicher-Inkremente nicht während der Ausführung angelegt, sondern die virtuelle Maschine wird direkt für das Puffern der zu kopierenden Elemente angehalten. Dieses Verfahren kann durchgeführt werden, weil die Sicherung so hochfrequent durchgeführt wird, dass keine großen Speichervorgänge zwischen zwei Checkpoints erwartet werden. Bei der Xen-Live-Migration erfolgt die Übertragung nur nach manueller Aktivierung, wodurch diese ein seltenes Ereignis darstellt und somit zeitaufwendiger sein kann, als bei Remus. Die Anforderung liegt hier bei einer minimierten Umschaltzeit zwischen altem und neuem Host. Aus diesem Grund wird zunächst versucht, während der Ausführung möglichst viel Speicherinhalt zu übertragen, um die Zeit für das Anhalten der aktiven virtuellen Maschine zu minimieren. Im Vergleich zu dem in Abschnitt 2.3 beschriebenen vsphere Fault Tolerance- System wird bei Remus die Belastung des Backup-Host reduziert, da dieser nur

13 Hardware-Fehlertoleranz mit Hochverfügbarkeit 13 VM-Abbilder aktualisieren, nicht jedoch die gesamte Berechnung des Active Host redundant durchführen muss. Auch müssen beide Hosts nicht exakt synchronisiert werden. Dieses System sieht demnach eine andere Sicherungsstrategie vor, die sich stark von der Xen-Live-Migration unterscheidet. Ein Vorteil von vsphere liegt allerdings in der minimalen Ausfallzeit, da hier auf dem Backup Host das zu sichernde System bereits ausgeführt wird und im Fehlerfall lediglich eine Umschaltung der externen Kommunikation auf den Backup Host erfolgen muss. Zusätzlich ist die Sicherung auf Instruktions-Granularität wesentlich feiner, als bei Remus, wodurch bei einer Wiederherstellung prinzipiell kein Rückfall in der Ausführung auftritt. 3.5 Evaluation und Bewertung Im Folgenden wird die Evaluation von Remus aus [3] vorgestellt und es wird eine Bewertung des Systems anhand der in Abschnitt 2 erarbeiteten Anforderungen vorgenommen. In der Evaluation aus [3] wurde zunächst die beschriebene Funktion des Verfahrens praktisch bestätigt. Für diesen Versuch wurde ein System mit Active und Backup Host aufgebaut. Der Active Host betrieb eine virtuelle Maschine mit Schutz durch Remus. Prozessor, externes Netzwerk und CPU des Active Host wurden durch ein Testprogramm stark belastet. In allen vier Phasen der Replizierung wurden Netzwerk-Fehler injiziert, um den Ausfall des Active Host zu simulieren. In jedem Fall übernahm der Backup Host nach etwa einer Sekunde die Aufgabe des Active Host. Nach der Übernahme durch den Backup Host wurde diese Maschine abgeschaltet und eine Festplatten-Überprüfung durchgeführt, welche in jedem Fall einen konsistenten Zustand anzeigte. Zur Untersuchung der Performanz von Remus wurde in [3] ein Testsystem erstellt, welches innerhalb eines Checkpointing-Intervalls auf unterschiedlichen Anzahlen von Speicherseiten Schreibvorgänge durchführte. Bei der Erstellung von Checkpoints wurden dann die Zeiten der Blockierung des Active Host sowie der Übertragung der Inkremente gemessen. Es hat sich gezeigt, dass die Zeit für das synchrone Auslesen des Speichers bei bis zu 1024 beschriebenen Speicherseiten im Bereich von etwa 5 mslag. Die Zeit für die asynchrone Übertragung hingegen stieg bei Erhöhung der Anzahl an beschriebenen Seiten stark an. Lag sie bei einer Seite noch bei etwa 1 ms, so stieg sie bis auf einen Mittelwert von etwa 57 ms bei der Übertragung von 1024 Seiten an, wobei Extremwerte von über 80 ms gemessen wurden. Da in diesem Zeitbereich potenziell bereits neue Checkpoints angelegt werden, wird eine zusätzliche Mehrbelastung des Verbindungskanals generiert, was die Zeiten weiter erhöhen sollte. Da ausgehende Kommunikation erst nach der Übertragung freigegeben werden kann, können sich deutliche Latenzen bei der Inanspruchnahme von Server-Diensten ergeben. Die Werte zeigen, dass die Belastung des Verbindungsnetzwerks für das Verfahren ein kritischer Faktor ist und dass sich dieser Punkt bei Applikationen, die viel auf dem Speicher arbeiten potenziell noch weiter verstärkt. Anschließend wurde in [3] der von Remus erzeugte Mehraufwand mittels der Ausführung dreier Benchmarks getestet. Hierbei wurde jeweils eine Testserie

14 14 Hardware-Fehlertoleranz mit Hochverfügbarkeit ohne Checkpointing und mit Checkpointing bei den Frequenzen von zehn bis 40 Checkpoints pro Sekunde untersucht. Die Benchmark-Programme wurden so ausgewählt, dass jeweils unterschiedliche Systemkomponenten besonderen Belastungen ausgesetzt waren. Die drei Testprogramme werden nachfolgend kurz beschrieben: Kompilierung eines Linux-Kernels: Diese Anwendung erzeugt eine etwa ausgeglichene Belastung von Prozessor, Speicher und Festplatte ohne die Netzwerk-Schnittstelle zu nutzen. SPECweb2005 : Dieser Benchmark simuliert einen Web-Server, einen Anwendungs-Server und einen oder mehrere darauf zugreifende Clients auf unterschiedlichen Hosts. Der Web-Server wird durch Remus geschützt und seine Performanz wird von dem Benchmark gemessen. Bei diesem Test wird eine besondere Belastung auf Netzwerk und Festplatte ausgeübt. SPECweb2005 berechnet eine Punktzahl für die Systemleistung, wobei eine höhere Punktzahl einer besseren Leistung entspricht. Postmark: Dieses Testsystem generiert eine hohe Belastung für die System- Festplatte. Für die Untersuchung mit Postmark wurde die Absicherung von Speicher- und Prozessor gegen Fehler abgeschaltet, um ausschließlich die Performanz des Festplattenpuffers zu untersuchen. Auch Postmark berechnet eine Punktzahl, bei der eine höhere Punktzahl einer besseren Leistung entspricht. Die Kompilierung eines Linux-Kernels bietet nicht, wie die anderen Benchmarks die Angabe von Performanz-Punkten, somit wurde hier lediglich die Gesamtlaufzeit gemessen. Es zeigte sich, dass sich der generierte Laufzeit-Mehraufwand im Vergleich zur ungeschützten Ausführung bei den Sicherungs-Frequenzen von zehn bis 40 Checkpoints pro Sekunde im Bereich zwischen 31 % und 103 % bewegte. Dieser Mehraufwand liegt in einem Bereich, welcher als tolerierbar anzusehen ist [3]. Somit zeigte sich in diesem Test, dass Remus für ähnliche Systeme gut geeignet ist. SPECweb2005 berechnet einen Punktestand anhand der Performanz des Gesamtsystems. Aufgrund dieses Punktestands lässt sich die Qualität einer Infrastruktur für Web-Dienste bemessen [3]. Dieser Benchmark passt gut in das Profil typischer Remus-Anwendungen, da Hochverfügbarkeit insbesondere bei Web-Diensten nötig sein kann. Da der Benchmark auch Reaktionszeiten auf Anfragen des Webdienstes misst, wurde evaluiert, welchen Einfluss die Pufferung von ausgehendem Datenverkehr auf den Punktestand hat. Es zeigt sich, dass bei Verwendung der Pufferung bei einer niedrigen Frequenz von zehn Checkpoints pro Sekunde etwa eine Drittelung der Bewertungspunkte im Vergleich zur ungeschützten Ausführung erfolgt. Bei steigender Checkpointing-Frequenz steigt der Punktestand zwar an, bleibt aber etwa im Bereich der halbierten Punktzahl. Bei der Untersuchung mit SPECweb2005 hat sich weiterhin gezeigt, dass der Benchmark eine hohe Speichernutzung aufweist, weshalb aufgrund der Netzwerk- Pufferung die effektive Checkpointing-Frequenz deutlich unter der konfigurierten lag, da die Checkpoints nicht schnell genug übertragen werden konnten [3]. Es

15 Hardware-Fehlertoleranz mit Hochverfügbarkeit 15 zeigt sich, dass Remus nur begrenzt für Dienste einsetzbar ist, die eine kurze Reaktionszeit voraussetzen und dennoch hohe Speicher-Aktivitäten aufweisen. Bei der Untersuchung mit Postmark wurde lediglich die von Remus durchgeführte Festplatten-Replizierung aktiviert, um den Einfluss auf die Performanz einer lokalen Festplatte festzustellen. Die Ergebnisse zeigen allerdings, dass Remus nur einen minimalen Einfluss auf die Performanz der Festplatte ausübt. Remus ist daher für Anwendungen, die eine hohe Performanz der verwendeten Festspeicher benötigen, gut geeignet [3]. Die in Abschnitt 2 beschriebenen Anforderungen an fehlertolerante Systeme setzen sich aus Fehlererkennung, Wiederherstellung und Systemkonsistenz zusammen und werden nachfolgend mit den Leistungen von Remus abgeglichen. Bei Remus wurde nur eine minimale Fehlerdetektion implementiert. So werden lediglich durch Fehler verursachte Systemabstürze erkannt [3]. Eine detaillierte Untersuchung des Systemzustands ist allerdings in Form einer Implementierung eines zusätzlichen Fehlerdetektions-Dienstes leicht möglich. Wie sich in diesem Abschnitt zeigte, konnten sowohl der Zustand von Speicher und Prozessor, als auch der Festplatten-Inhalt nach Auftreten eines Fehlers korrekt wiederhergestellt werden. Dabei werden nicht nur transiente Fehler, sondern auch permanente und diskontinuierliche Fehler behandelt, da im Fehlerfall ein Hostwechsel durchgeführt wird [3]. Solange nur in einer Komponente des Systems ein Fehler auftritt, kann dieser von Remus behandelt werden. Fallen allerdings beide Rechensysteme gleichzeitig aus, dann ist das System nicht mehr verfügbar, jedoch bleibt der Systemzustand auf dem Backup-Host persistent gespeichert [3]. Transiente Fehler können daher durch einen unmittelbaren Neustart des Systems umgangen werden, jedoch wird dadurch potenziell eine längere Nicht-Verfügbarkeit ausgelöst. Fallen beide Verbindungen zwischen den Hosts aus, so ist das Verhalten des Systems undefiniert. Die Evaluation in [3] hat gezeigt, dass der Zustand zwischen Active Host und Backup Host zu jeder Zeit konsistent ist. Zu jedem Zeitpunkt können Fehler im Active Host auftreten, ohne Inkonsistenzen auf dem Backup Host hervorzurufen. Der Festplattenzustand auf dem Backup Host ist zu jedem Zeitpunkt in sich konsistent und mit dem Zustand des Active Host synchronisiert. Auch die externe Kommunikation wird durch das Puffern ausgehender Nachrichten immer mit dem aktuellsten Checkpoint konsistent gehalten. Größtenteils erfüllt Remus demnach die Bedingungen, die an ein System für Fehlertoleranz gestellt werden. Es bestehen Mängel in der Fehlerdetektion, welche allerdings mittels der Einbringung zusätzlicher Software zu umgehen sind. Es wird eine gute Performanz geboten, wenn die verwendete Applikation nicht gleichzeitig Arbeitsspeicher und Netzwerkverbindung intensiv belastet. 4 Zusammenfassung In dieser Ausarbeitung wurde Hardware-Fehlertoleranz als Mittel zur Erreichung von Hochverfügbarkeit vorgestellt. Zunächst wurden die Grundbegriffe

16 16 Hardware-Fehlertoleranz mit Hochverfügbarkeit von Hardware-Fehlertoleranz erläutert, um darauf aufbauend Remus, ein VMbasiertes System für die Schaffung von Fehlertoleranz, zu untersuchen. Das System bietet einen Ansatz zur Replizierung von virtuellen Maschinen auf einem speziell dafür ausgelegten Host-Rechner. Das System bietet zwar eine sehr hochfrequente Erzeugung von Checkpoints bei einem moderaten Mehraufwand, kann allerdings nicht jede Art von Fehler erkennen. Eine frühzeitige Erkennung ist ebenfalls nicht zu garantieren. Wird auf dem abzusichernden System eine Applikation mit hoher Belastung von Arbeitsspeicher und Netzwerkverbindung ausgeführt, so wird die Systemleistung durch Remus stark eingeschränkt. Da Systeme, die auf Hochverfügbarkeit ausgelegt sind, oft diese diesem Belastungsschema entsprechen, ist es allerdings nicht in jedem Fall sinnvoll, Remus zur Steigerung von Hardware-Fehlertoleranz in Server-Systemen mit Hypervisor einzusetzen. Literatur 1. Koren, I., Krishna, C. M.: Fault-Tolerant Systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, Echtle, K.: Fehlertoleranzverfahren. Studienreihe Informatik. Springer, Cully, B., Lefebvre, G., Meyer, D., Feeley, M., Hutchinson, N., Warfield, A.: Remus: High availability via asynchronous virtual machine replication. In: NSDI, Clark, C., Fraser, K., Hand, S., Hansen, J. G., Jul, E., Limpach, C., Pratt, I., Warfield, A.: Live migration of virtual machines. In: Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation - Volume 2. USE- NIX Association, Berkeley, CA, USA, pp , Barham, P., Dragovic, B., Fraser, K., Hand S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., Warfield, A.: Xen and the art of virtualization. In: Proceedings of the nineteenth ACM symposium on Operating systems principles (SOSP 03), ACM, New York, NY, USA, pp , Gray, J., Siewiorek, D.P.: High-availability computer systems. In: Computer, vol.24, no.9, pp , Sept VMware, Inc.: Handbuch zur Verfügbarkeit in vsphere, http: //pubs.vmware.com/vsphere-50/topic/com.vmware.icbase/pdf/ vsphere-esxi-vcenter-server-501-availability-guide.pdf, 2012