Hardware-Fehlertoleranz mit Hochverfügbarkeit

Größe: px
Ab Seite anzeigen:

Download "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

Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit

Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit Seminarvortrag: Hardware-Fehlertoleranz mit Hochverfügbarkeit Agenda Motivation Hardware-Fehlertoleranz Checkpointing and Rollback Recovery Systemverfügbarkeit VM-basierte Systeme Remus Architektur Sicherung

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Band M, Kapitel 5: Server

Band M, Kapitel 5: Server Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr

Fehlertoleranz auf Basis des Hypervisors

Fehlertoleranz auf Basis des Hypervisors Fehlertoleranz auf Basis des Hypervisors Hendrik Borghorst 6. März 2013 Hendrik Borghorst Fehlertoleranz auf Basis des Hypervisors 1/45 1 Einleitung Fehlertoleranz durch Replikation 2 Replikation durch

Mehr

Wiederherstellung (Recovery)

Wiederherstellung (Recovery) Fragestellungen Aufgaben der Komponenten für das Recovery: Sicherstellung der Dauerhaftigkeit der gespeicherten Daten, d.h. Daten, die in einer Transaktion einmal bestätigt wurden (commit), bleiben auch

Mehr

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11.

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11. slosungen 11. Mai 2009 Inhaltsverzeichnis Uberlegungen slosungen 1 Uberlegungen Grunduberlegungen Vorteile Hardware-Emulation Nachteile 2 Servervirtualisierung Clientvirtualisierung 3 slosungen 4 5 Uberlegungen

Mehr

Einblick in die VMware Infrastruktur

Einblick in die VMware Infrastruktur Einblick in die VMware Infrastruktur Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer

Mehr

1. Download und Installation

1. Download und Installation Im ersten Teil möchte ich gerne die kostenlose Software Comodo Backup vorstellen, die ich schon seit einigen Jahren zum gezielten Backup von Ordnern und Dateien einsetze. Diese Anleitung soll auch Leuten,

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

Intelligentes Backup/Recovery für virtuelle Umgebungen

Intelligentes Backup/Recovery für virtuelle Umgebungen Intelligentes Backup/Recovery für virtuelle Umgebungen Mario Werner Sales Syncsort GmbH Calor-Emag-Straße 3 40878 Ratingen mwerner@syncsort.com Abstract: In den letzten Jahren haben sich die Situation

Mehr

(früher: Double-Take Backup)

(früher: Double-Take Backup) (früher: Double-Take Backup) Eine minutengenaue Kopie aller Daten am Standort: Damit ein schlimmer Tag nicht noch schlimmer wird Double-Take RecoverNow für Windows (früher: Double-Take Backup) sichert

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

VMware. Rainer Sennwitz.

VMware. Rainer Sennwitz. <Rainer.Sennwitz@andariel.informatik.uni-erlangen.de> VMware Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer Sennwitz VMware Inhalt Inhalt

Mehr

Schnell wieder am Start dank VMware Disaster Recovery Ausfallzeiten minimieren bei der Wiederherstellung von VMs mit Veeam Backup & Replication v6

Schnell wieder am Start dank VMware Disaster Recovery Ausfallzeiten minimieren bei der Wiederherstellung von VMs mit Veeam Backup & Replication v6 Schnell wieder am Start dank VMware Disaster Recovery Ausfallzeiten minimieren bei der Wiederherstellung von VMs mit Veeam Backup & Replication v6 Florian Jankó LYNET Kommunikation AG Vorhandene Tools

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13.

Vorlesung Verteilte Systeme Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13. Verteilte Systeme 13. Fehlertoleranz Motivation Kunde () Verteiltes System = Redundanz Rechnern Kommunikationsnetzen Grundidee Einzelne Komponente k fällt mit einer Wahrscheinlichkeit p aus Ausfallwahrscheinlichkeit

Mehr

Virtualisierung in der Automatisierungstechnik

Virtualisierung in der Automatisierungstechnik Virtualisierung in der Automatisierungstechnik Ihr Referent Jürgen Flütter on/off engineering gmbh Niels-Bohr-Str. 6 31515 Wunstorf Tel.: 05031 9686-70 E-Mail: juergen.fluetter@onoff-group.de 2 Virtualisierung

Mehr

Verteilte Systeme F. Fehlertoleranz

Verteilte Systeme F. Fehlertoleranz Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software!

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

VoIPcom Supportpakete

VoIPcom Supportpakete VoIPcom Supportpakete bietet drei verschiedene Supportpakete an. Anrecht auf das Supportpaket Silber haben grundsätzlich alle Kunden, welche eine VoIPcom Telefonanlage im Einsatz haben. Für Firmenkunden

Mehr

Hardware-basierte Virtualisierung

Hardware-basierte Virtualisierung Hardware-basierte Virtualisierung Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2014/2015 V. Sieh Hardware-basierte

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

Virtualisierung in der Automatisierungstechnik

Virtualisierung in der Automatisierungstechnik Virtualisierung in der Automatisierungstechnik Ihr Referent Jürgen Flütter on/off engineering gmbh Niels-Bohr-Str. 6 31515 Wunstorf Tel.: 05031 9686-70 E-Mail: juergen.fluetter@onoff-group.de 2 Virtualisierung

Mehr

Datenträgerverwaltung

Datenträgerverwaltung Datenträgerverwaltung Datenträgerverwaltung 1/9 Datenträgerverwaltung Inhaltsverzeichnis Vorgangsweise...2 Umwandeln einer Basisfestplatte in eine Dynamische Festplatte... 2 Spiegelung erstellen... 4 Partitionen

Mehr

Hyper-V Replica in Windows Server 2012 R2. Benedict Berger Microsoft MVP Virtual Machine

Hyper-V Replica in Windows Server 2012 R2. Benedict Berger Microsoft MVP Virtual Machine Hyper-V Replica in Windows Server 2012 R2 Benedict Berger Microsoft MVP Virtual Machine Ihr Referent bb@elanity.de http://blog.benedict-berger.de Hyper-V Replica VM Mobility Möglichkeiten Replica Flexibilität

Mehr

PARAGON SYSTEM UPGRADE UTILITIES

PARAGON SYSTEM UPGRADE UTILITIES PARAGON SYSTEM UPGRADE UTILITIES VIRTUALISIERUNG EINES SYSTEMS AUS ZUVOR ERSTELLTER SICHERUNG 1. Virtualisierung eines Systems aus zuvor erstellter Sicherung... 2 2. Sicherung in eine virtuelle Festplatte

Mehr

2 Virtualisierung mit Hyper-V

2 Virtualisierung mit Hyper-V Virtualisierung mit Hyper-V 2 Virtualisierung mit Hyper-V 2.1 Übersicht: Virtualisierungstechnologien von Microsoft Virtualisierung bezieht sich nicht nur auf Hardware-Virtualisierung, wie folgende Darstellung

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Preis- und Leistungsverzeichnis der Host Europe GmbH. Virtual Backup V 1.0. Stand: 01.01.2013

Preis- und Leistungsverzeichnis der Host Europe GmbH. Virtual Backup V 1.0. Stand: 01.01.2013 Preis- und Leistungsverzeichnis der Host Europe GmbH Virtual Backup V 1.0 Stand: 01.01.2013 INHALTSVERZEICHNIS PREIS- UND LEISTUNGSVERZEICHNIS VIRTUAL BACKUP... 3 Produktbeschreibung Virtual Backup...

Mehr

I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte

I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte I N F O R M A T I O N V I R T U A L I S I E R U N G Wir schützen Ihre Unternehmenswerte Wir schützen Ihre Unternehmenswerte Ausfallsicherheit durch Virtualisierung Die heutigen Anforderungen an IT-Infrastrukturen

Mehr

Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011

Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011 ANLAGE 3 Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011 Allgemein Um den Support des DV-Systems sicher und effektiv gewährleisten zu können ist es unerlässlich,

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT

Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT Produkte und Systeme der Informationstechnologie ENERGIE- MANAGEMENT Folie 1 VDE-Symposium 2013 BV Thüringen und Dresden Virtualisierung von Leittechnikkomponenten Andreas Gorbauch PSIEnergie-EE Folie

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

RICHTLINIEN UND ANTRAG FÜR DIE EINRICHTUNG UND BETRIEB EINES VIRTUELLEN RECHNERS (VM) IM VMWARE- CLUSTER DES RECHENZENTRUMS

RICHTLINIEN UND ANTRAG FÜR DIE EINRICHTUNG UND BETRIEB EINES VIRTUELLEN RECHNERS (VM) IM VMWARE- CLUSTER DES RECHENZENTRUMS Rechenzentrum Stand 13.11.2012 Prof. Jan Münchenberg Wissenschaftlicher Leiter RICHTLINIEN UND ANTRAG FÜR DIE EINRICHTUNG UND BETRIEB EINES VIRTUELLEN RECHNERS (VM) IM VMWARE- CLUSTER DES RECHENZENTRUMS

Mehr

Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V

Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V Ausgewählte Kapitel der Systemsoftware Virtualisierung Betrachtung aktueller Hypervisor wie Xen, KVM und Hyper-V Guilherme Bufolo Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik

Mehr

Hardware-basierte Virtualisierung

Hardware-basierte Virtualisierung Hardware-basierte Virtualisierung Dr.-Ing. Volkmar Sieh Department Informatik 3: Rechnerarchitektur Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2011/2012 Hardware-basierte Virtualisierung 1/22

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Testdokumente Semesterarbeit von: Juli 2005 Mobile Data Monitor Seite 71 / 106 5.3 Testing Folgende Tests wurden durchgeführt.

Mehr

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Fakultät Informatik Institut für Systemarchitektur, Professur Betriebssysteme VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Henning Schild Dresden, 5.2.2009 Definition Einführung von Abstraktionsschichten

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

IT-Lösungsplattformen

IT-Lösungsplattformen IT-Lösungsplattformen - Server-Virtualisierung - Desktop-Virtualisierung - Herstellervergleiche - Microsoft Windows 2008 für KMU s Engineering engineering@arcon.ch ABACUS Kundentagung, 20.11.2008 1 Agenda

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Datensicherheit und Hochverfügbarkeit

Datensicherheit und Hochverfügbarkeit Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall

Mehr

Leistungsbeschreibung vserver

Leistungsbeschreibung vserver Leistungsbeschreibung vserver Stand: 17.08.2011 1 Anwendungsbereich...2 2 Leistungsumfang...2 2.1 Allgemein...2 2.2 Hardware und Netzwerkanbindung...2 2.3 Variante Managed...2 2.4 Variante Unmanaged...3

Mehr

... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 2... Konzeption virtualisierter SAP-Systeme... 87

... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 2... Konzeption virtualisierter SAP-Systeme... 87 ... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 1.1... Einführung in die Virtualisierung... 23 1.2... Ursprünge der Virtualisierung... 25 1.2.1... Anfänge der Virtualisierung... 25 1.2.2...

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

KVM Performance Optimierungen auf Hypervisor / Linux Eben

KVM Performance Optimierungen auf Hypervisor / Linux Eben KVM Performance Optimierungen auf Hypervisor / Linux Ebene UnFUG WS12/13 17. Januar 2013 1 / 32 Agenda Einleitung 1 Einleitung 2 3 4 5 2 / 32 Hintergrund / Motivation Seminararbeit für die WPV Cloud Computing

Mehr

IT Storage Cluster Lösung

IT Storage Cluster Lösung @ EDV - Solution IT Storage Cluster Lösung Leistbar, Hochverfügbar, erprobtes System, Hersteller unabhängig @ EDV - Solution Kontakt Tel.: +43 (0)7612 / 62208-0 Fax: +43 (0)7612 / 62208-15 4810 Gmunden

Mehr

In 12 Schritten zum mobilen PC mit Paragon Drive Copy 11 und Microsoft Windows Virtual PC

In 12 Schritten zum mobilen PC mit Paragon Drive Copy 11 und Microsoft Windows Virtual PC PARAGON Technologie GmbH, Systemprogrammierung Heinrich-von-Stephan-Str. 5c 79100 Freiburg, Germany Tel. +49 (0) 761 59018201 Fax +49 (0) 761 59018130 Internet www.paragon-software.com Email sales@paragon-software.com

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Fehlertoleranzmechanismen in hochverfügbaren Clustersystemen

Fehlertoleranzmechanismen in hochverfügbaren Clustersystemen Holger Sattel Seminar Rechnerarchitektur WS 2003/04 Universität Mannheim Lehrstuhl Rechnerarchitektur Prof. Dr. U. Brüning Inhaltsverzeichnis Grundlagen / Begriffe Fehlertoleranz Fehlertoleranz in (Rechen-)Clustern

Mehr

vsphere 5.1 Upgrade & Best Practices Tristan P. Andres Senior IT Consultant

vsphere 5.1 Upgrade & Best Practices Tristan P. Andres Senior IT Consultant vsphere 5.1 Upgrade & Best Practices Tristan P. Andres Senior IT Consultant Event-Agenda 09:00 09:10 Begrüssung 10 Min. Hr. Walter Keller 09:10 09:40 News from VMware Partner Exchange 30 Min. Hr. Daniele

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

MySQL Community Server 5.1 Installationsbeispiel

MySQL Community Server 5.1 Installationsbeispiel MySQL Community Server 5.1 Installationsbeispiel Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der untermstrich-datenbank

Mehr

Claus PFLEGER Systems Engineer CEMEA claus.pfleger@veeam.com

Claus PFLEGER Systems Engineer CEMEA claus.pfleger@veeam.com Claus PFLEGER Systems Engineer CEMEA claus.pfleger@veeam.com Blickwinkel Abteilungsleiter & Vorgesetzte Sicherungslösung bewährt und passend für Virtualisierung? Backupkosten? Kostenentwicklung? Gegenwert

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Fehlertolerante und Selbstheilende Systeme.

Fehlertolerante und Selbstheilende Systeme. Fehlertolerante und Selbstheilende Systeme. Inhalt 1. 2. Fehlermodelle 3. Fehlertoleranztechniken 4. DCE (Dual Core Execution) 5. Fehlertoleranz 6. Zusammenfassung 2/29 Motivation Computer Aufgaben immer

Mehr

DEN TSM SERVER HOCHVERFÜGBAR MACHEN. Tipps zur Realisierung

DEN TSM SERVER HOCHVERFÜGBAR MACHEN. Tipps zur Realisierung DEN TSM SERVER HOCHVERFÜGBAR MACHEN Tipps zur Realisierung AGENDA 01 Ist eine HA-Lösung für TSM erforderlich 02 Besonderheiten bei TSM Version 6 03 Methoden der Absicherung des TSM-Betriebs 04 Entscheidungskriterien

Mehr

Backup und Restore. in wenigen Minuten geht es los. KEIN VOIP, nur Tel: 069 / 25511 4400 www.webex.de Sitzungsnr.: 956 738 575 #

Backup und Restore. in wenigen Minuten geht es los. KEIN VOIP, nur Tel: 069 / 25511 4400 www.webex.de Sitzungsnr.: 956 738 575 # in wenigen Minuten geht es los Backup und Restore In virtuellen Umgebungen KEIN VOIP, nur Tel: 069 / 25511 4400 www.webex.de Sitzungsnr.: 956 738 575 # Backup und Restore In virtuellen Umgebungen BACKUP

Mehr

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh Fault-Konzepte Fehlermanagement in Rechnernetzen Übersicht 1. Rückblick auf FCAPS (Netzwerkmanagement) und SNMP (Netzwerkprotokoll) 2. Fehlermanagement (Definition, Struktur) 3. Fehlerbehandlung -Fehlererkennung

Mehr

Hidden Automa-c Navigator your gateway to electronic resources. Markus Libiseller M.A. Technical Product Manager

Hidden Automa-c Navigator your gateway to electronic resources. Markus Libiseller M.A. Technical Product Manager Hidden Automa-c Navigator your gateway to electronic resources Markus Libiseller M.A. Technical Product Manager E- Ressourcen in modernen Bibliotheken Moderne Bibliotheken stellen nicht nur klassische,

Mehr

united hoster GmbH Service Level Agreement (SLA)

united hoster GmbH Service Level Agreement (SLA) united hoster GmbH Service Level Agreement (SLA) Inhaltsverzeichnis Service Level Agreement (SLA)... 1 Inhaltsverzeichnis... 2 1 Einleitung... 3 1.1 Ziel... 3 1.2 Inkraftsetzung und Gültigkeitsdauer...

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Hochverfügbare Virtualisierung mit Open Source

Hochverfügbare Virtualisierung mit Open Source Hochverfügbare Virtualisierung mit Open Source Gliederung DRBD Ganeti Libvirt Virtualisierung und Hochverfügbarkeit Hochverfügbarkeit von besonderer Bedeutung Defekt an einem Server => Ausfall vieler VMs

Mehr

Unterrichtseinheit 13

Unterrichtseinheit 13 Unterrichtseinheit 13 Konfigurieren einer unterbrechungsfreien Stromversorgung Die Konfiguration erfolgt unter : Start Einstellungen Systemsteuerung Energieoptionen USV Implementieren von Fehlertoleranz

Mehr

Handbuch Version 1.02 (August 2010)

Handbuch Version 1.02 (August 2010) Handbuch Version 1.02 (August 2010) Seite 1/27 Inhaltsverzeichnis 1. Einleitung 1.1. Begrüßung 03 1.2. Was ist PixelX Backup FREE / PRO 03 1.3. Warum sollten Backups mittels einer Software erstellt werden?

Mehr

IRS in virtualisierten Umgebungen

IRS in virtualisierten Umgebungen Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München IRS in virtualisierten Umgebungen Seminar: Future Internet Christian Lübben Betreuer: Nadine Herold, Stefan

Mehr

Übersicht der VMware vsphere Komponenten und sonstigen Zusatzprodukten.

Übersicht der VMware vsphere Komponenten und sonstigen Zusatzprodukten. 2 Übersicht VMware vsphere Übersicht der VMware vsphere Komponenten und sonstigen Zusatzprodukten. 2.1 Übersicht Themen des Kapitels Übersicht VMware vsphere Themen des Kapitels Übersicht Virtualisierung

Mehr

Server virtualisieren mit Hyper-V Nils Kaczenski, Teamleiter Microsoft-Consulting

Server virtualisieren mit Hyper-V Nils Kaczenski, Teamleiter Microsoft-Consulting Server virtualisieren mit Hyper-V Nils Kaczenski, Teamleiter Microsoft-Consulting Hypervisoren im Vergleich VM1 VM2 VM3 VM4 Hypervisor Treiber VM Parent Treiber VM2 VM3 VM4 Hypervisor Hardware Hardware

Mehr

NAS 251 Einführung in RAID

NAS 251 Einführung in RAID NAS 251 Einführung in RAID Ein Speicher-Volume mit RAID einrichten A S U S T O R - K o l l e g Kursziele Nach Abschluss dieses Kurses sollten Sie: 1. Ü ber ein grundlegendes Verständnis von RAID und seinen

Mehr

Erstellen einer Wiederherstellungskopie

Erstellen einer Wiederherstellungskopie 21 Sollten Sie Probleme mit Ihrem Computer haben und Sie keine Hilfe in den FAQs (oft gestellte Fragen) (siehe seite 63) finden können, können Sie den Computer wiederherstellen - d. h. ihn in einen früheren

Mehr

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION

Prof. Dr.-Ing. Dagmar Meyer Architekturen verteilter SW-Systeme 5 SYNCHRONISATION Prof. Dr.-Ing. Dagmar Meyer 5 SYNCHRONISATION Warum braucht man Synchronisation? Ausgangssituation Prozesse müssen sich koordinieren / synchronisieren, z. B. beim Zugriff auf gemeinsame Ressourcen. Alle

Mehr

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Verwendung der bereitgestellten Virtuellen Maschinen»Einrichten einer Virtuellen Maschine mittels VirtualBox sowie Zugriff auf

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Ausfallsicherheit maßgeschneidert

Ausfallsicherheit maßgeschneidert Wir unternehmen IT. Ausfallsicherheit maßgeschneidert Bringen Sie Kosten und Nutzen in Einklang! Henning von Kielpinski Head of Business Development Henning.von.Kielpinski@consol.de Hochverfügbarkeit Risiken

Mehr

20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2.

20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2. 20 Vorgehensweise bei einem geplanten Rechnerwechsel... 2 20.1 Allgemein... 2 20.2 Rechnerwechsel bei einer Einzelplatzlizenz... 2 20.2.1 Schritt 1: Datensicherung... 2 20.2.2 Schritt 2: Registrierung

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung http:// www.pcinspector.de Verzichtserklärung Wir haben unser Bestes getan um sicherzustellen, dass die aufgeführten Installationsanweisungen in korrekter Weise wiedergegeben wurden

Mehr

Sophos Mobile Control Benutzerhandbuch für Android

Sophos Mobile Control Benutzerhandbuch für Android Sophos Mobile Control Benutzerhandbuch für Android Produktversion: 2 Stand: Dezember 2011 Inhalt 1 Über Sophos Mobile Control... 3 2 Einrichten von Sophos Mobile Control auf einem Android-Mobiltelefon...

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

CloneManager Für Windows und Linux

CloneManager Für Windows und Linux bietet ein leicht zu bedienendes, automatisches Verfahren zum Klonen und Migrieren zwischen und innerhalb von physischen oder virtuellen Maschinen oder in Cloud- Umgebungen. ist eine Lösung für die Live-Migrationen

Mehr

dogado Support Policies Stand: 01. Dezember 2014, Version 1.06

dogado Support Policies Stand: 01. Dezember 2014, Version 1.06 dogado Support Policies Stand: 01. Dezember 2014, Version 1.06 Version 1.06 - Seite 1 von 10 Inhaltsverzeichnis dogado Support Policies... 3 dogado Geschäftszeiten und Erreichbarkeit... 3 Schweregrade

Mehr

Citrix Personal vdisk 5.6.5 - Administratordokumentation

Citrix Personal vdisk 5.6.5 - Administratordokumentation Citrix Personal vdisk 5.6.5 - Administratordokumentation Inhalt Inhalt Info über Personal vdisk 5.6.5...3 Neue Features in Personal vdisk 5.6.5...3 Behobene Probleme...3 Bekannte Probleme...4 Systemanforderungen

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

Host Europe Suisse AG. Service Level Agreement

Host Europe Suisse AG. Service Level Agreement Host Europe Suisse AG Service Level Agreement Inhaltsverzeichnis 1. Präambel... 3 2. Definitionen und Berechnungen... 3 3. Allgemeine Service Level... 5 3.1. Verfügbarkeit der Rechenzentren... 5 3.1.1.

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Verwaltungsdirektion Informatikdienste Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Inhaltsverzeichnis Einleitung... 3 Installation WSUS Server... 4 Dokumente... 4 Step by Step Installation...

Mehr

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst

Der Parameter CLOSE bewirkt, dass sich das Sicherungsprogramm am Ende der Sicherung automatisch schliesst 1 Sicherung 1.1 Einleitung Die Applikation WSCAR basiert auf der Datenbank-Engine Firebird 1.5.5 / 2.5.2. Beide Programme sind nur auf der Hauptstation(Server) installiert und dürfen nie deinstalliert

Mehr

KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG DER GLOBAL THREAT INTELLIGENCE REPORT 2015 :: COPYRIGHT 2015 NTT INNOVATION INSTITUTE 1 LLC

KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG DER GLOBAL THREAT INTELLIGENCE REPORT 2015 :: COPYRIGHT 2015 NTT INNOVATION INSTITUTE 1 LLC KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG 1 DDOS-ANGRIFF AUF EINE WEBANWENDUNG LEHRE AUS DER FALLSTUDIE Im Falle eines Angriffs zahlt sich eine DoS-/DDoS-Abwehrstrategie aus. SZENARIO Das

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

RAID Redundant Array of Independent [Inexpensive] Disks

RAID Redundant Array of Independent [Inexpensive] Disks RAID Redundant Array of Independent [Inexpensive] Disks Stefan Wexel Proseminar Algorithms and Data Structures im WS 2011/2012 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik

Mehr

Konsistente Navision Datensicherung

Konsistente Navision Datensicherung Konsistente Navision Datensicherung Dokumentation Hintergrund Die Möglichkeit, Datensicherungen durchzuführen, ist in jedem Navision System gegeben. Diese eingebaute Routine ist eine sehr anspruchsvolle

Mehr

Paravirtualisierung (2)

Paravirtualisierung (2) Paravirtualisierung (2) Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2014/2015 V. Sieh Paravirtualisierung (2)

Mehr