HADES. Ein hochverfügbares, verteiltes Main-Memory-Datenmanagementsystem. Vom Fachbereich Informatik der Technischen Universität Darmstadt genehmigte

Transkript

1 HADES Ein hochverfügbares, verteiltes Main-Memory-Datenmanagementsystem Vom Fachbereich Informatik der Technischen Universität Darmstadt genehmigte Dissertation zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) von Diplom-Informatiker Matthias Meixner aus Fulda Referenten: Prof. Alejandro Buchmann, Ph. D. Prof. Dr.-Ing. Felix Gärtner Tag der Einreichung: 4. Mai 2004 Tag der mündlichen Prüfung: 17. Dezember 2004 Darmstädter Dissertationen D17

2

3 Inhaltsverzeichnis 1 Einführung Publish/Subscribe IP-Übernahmemechanismen Ziele und Ergebnisse dieser Arbeit Überblick über die Arbeit Annahmen über die Systemumgebung Grundlagen der Fehlertoleranz Fehlermodelle Fehlerabdeckung Fehlertoleranz, Redundanz und Hochverfügbarkeit Verteilte Systeme und Fehlertoleranz Die HADES-Systemumgebung HADES-Fehlermodell Hardwareplattform Speicherressourcen Netzwerkressourcen Zusammenfassung i

4 ii INHALTSVERZEICHNIS 3 Überblick: Aufbau von HADES Fehlertolerante Kommunikationsschicht HADES-API HADES-DB Beispiel Fehlertolerante Kommunikationsschicht Überblick über die Implementierung Designentscheidungen Aufbau der Kommunikationsschicht Client-Programmierschnittstelle Verwaltung der Rechner im Cluster Hinzufügen von Clusterknoten Entfernen von Clusterknoten Abfragen der Clusterknoten Ausfallerkennung Versenden von Nachrichten und Antworten Signale Zusammenfassung HADES-Konzepte Management globaler Daten Datenverteilung und Adressierung Zweistufige Adressierung Berechnung der Servertabelle Zusammenfassung

5 INHALTSVERZEICHNIS iii 6 Verteiltes Datenmanagementsystem Client-Programmierschnittstelle Datenoperationen Konsistenzeigenschaften Verteilung der Servertabelle Absicherung von Änderungen an globalen Daten Datentabellen anlegen und löschen Servertabelle auslesen Adressierung Daten schreiben Daten Lesen Daten Löschen Selektieren und Sortieren Erweiterbarkeit Umkopieren für Redundanz oder Lastverteilung Transaktionen Arbeiten ohne Transaktionen Arbeiten mit Transaktionen Inter-Cluster-Transaktionen Audit-Logging und Backup Audit-Logging Backup Zusammenfassung

6 iv INHALTSVERZEICHNIS 7 Leistungsmessung Testumgebung Testablauf Benchmark Lesen und Schreiben von Daten außerhalb von Transaktionen Lesen und Schreiben von Daten innerhalb von Transaktionen Vergleich zwischen writepage/readpage und writepageset/read- PageSet Transaktionen Verteilte Transaktionen Selektieren Auswirkung der Slice-Anzahl Operationen während einer Datenneuverteilung Auswirkungen der Prozessorleistung Vergleich mit PostgreSQL Berkeley DB Zusammenfassung Vergleich mit anderen Systemen Bestehende Datenbanksysteme Konventionelle Datenbanksysteme Main-Memory-Datenbanksysteme PRISMA/DB TimesTen Distributed Hash-Tables

7 INHALTSVERZEICHNIS v 8.3 LH* Schema Scalable Distributed Data Structure LH* LH*m LH*s LH*g und LH*RS Distributed Shared Memory Shared Virtual Memory Fehlertolerantes DSM Checkpointing mit Parity Distributed Reliable Cache Middleware Mediated Transactions und X 2 TS Active Disks ISIS Toolkit Zusammenfassung Zusammenfassung und Ausblick Anforderungen und Ergebnisse Weitere Arbeiten und Verbesserungen Sensornetze A Grundlagen von Speichertechnologien 163 A.1 Festplatten A.2 RAID A.2.1 RAID-Level A.2.2 RAID-Level A.2.3 RAID-Level A.2.4 RAID-Fazit A.3 Solid State Disks A.4 Zusammenfassung

8 vi INHALTSVERZEICHNIS B Algorithmen 171 B.1 Gesamtalgorithmus zur Erkennung ausgefallener Knoten B.2 Berechnung der Servertabelle C Schnittstellenkurzreferenz 175 C.1 Programmierschnittstelle zur Kommunikationsschicht C.2 HADES Programmierschnittstelle Literaturverzeichnis 181

9 Kapitel 1 Einführung In den letzten Jahren haben sich durch den Fortschritt die technischen Voraussetzungen dramatisch geändert: Hauptspeicher ist billiger geworden und kostet heute soviel wie vergleichbarer Plattenplatz vor 10 Jahren. Die Festplattenkapazität ist um den Faktor 100 gestiegen, während der Durchsatz nur um den Faktor 10 gesteigert werden konnte und die Zugriffszeit noch weiter zurückblieb. Damit verschlechtert sich das Verhältnis aus Festplattenkapazität und Durchsatz bzw. Zugriffszeit alle 10 Jahre um den Faktor 10 [GS00]. Gleichzeitig ist die verfügbare Rechenleistung dramatisch angestiegen und die Schere zwischen Rechenleistung und Zugriffszeiten geht immer weiter auseinander. Für viele Anwendungen stellt nicht mehr die Rechenleistung einen Flaschenhals dar, sondern die hohe Zugriffszeit von Festplatten. Deshalb ist es notwendig alternative Speichersysteme zu untersuchen, wenn man insgesamt zu schnelleren Systemen kommen möchte. Konventionelle Speichersysteme sind der Flaschenhals, müssen also neu überdacht werden. Diese Arbeit entwickelt daher ein Speichersystem, das diesen Flaschenhals nicht besitzt und darüberhinaus weitere interessante Eigenschaften aufweist. In den folgenden Abschnitten möchte ich zunächst an ausgewählten Beispielen die Probleme aufzeigen und im weiteren Verlauf dieser Arbeit eine Lösung erarbeiten. 1.1 Publish/Subscribe Publish/Subscribe-Systeme gehören zu den eventbasierten Systemen. Diese werden verwendet, um größere verteilte Systeme aufzubauen, die die Eigenschaft haben, daß 1

10 2 KAPITEL 1. EINFÜHRUNG Client Event Broker F1 F2 F3 F1 F2 DB F1 Event Notification System F2 DB F1 F1 F2 F3 F2 F3 F1 F2 DB Abbildung 1.1: Eventbasiertes System die beteiligten Komponenten nur relativ lose miteinander gekoppelt sind [CNRW98]: Eine Komponente benötigt kein Wissen darüber, welche anderen Komponenten im System existieren, sie braucht nur die Formate und Strukturen der Events zu kennen, die für sie interessant sind. Man kann Komponenten hinzufügen und entfernen, ohne daß die anderen Komponenten direkt davon betroffen sind. Die verschiedenen Komponenten kommunizieren über Notifications (Benachrichtigungen), die das Auftreten eines bestimmten Ereignisses signalisieren. Abbildung 1.1 zeigt ein Beispiel für ein solches System. Das Event Notification System übernimmt dabei die Aufgabe, Benachrichtigungen, die von Produzenten erzeugt und publiziert werden, an Konsumenten weiterzuleiten. Da ein Produzent auch gleichzeitig Konsument für eine andere Art von Benachrichtigungen sein kann, werden Produzenten und Konsumenten in der Abbildung gleichermaßen als Client bezeichnet. Innerhalb des Event Notification Systems übernehmen Event-Broker die Aufgabe, Benachrich-

11 1.1. PUBLISH/SUBSCRIBE 3 tigungen weiterzuleiten und dabei mit Filtern bereits so zu filtern, daß Benachrichtigungen nur an die Stellen weitergeleitet werden, an denen es auch Konsumenten für diese Benachrichtigungen gibt. Damit dies möglich ist, geben Konsumenten dem Event Notification System per Subscription bekannt, für welche Ereignisse sie sich interessieren. Der Name Publish/Subscribe leitet sich aus eben dieser Funktionsweise von Publizieren und Abonnieren von Nachrichten ab. Eine weitere wichtige Möglichkeit die Datenmenge zu reduzieren und nur benötigte Informationen weiterzuleiten, besteht darin, Events zu aggregieren, d.h. mehrere Events auszuwerten und zusammenzufassen [BBC + 04]. Im Unterschied zu einfachen Filtern ist hierfür aber die Speicherung von Zustandsinformationen notwendig: Es müssen mehrere Benachrichtigungen angesammelt und gespeichert werden, bevor sie aggregiert werden können. Das Publish/Subscribe Prinzip wurde bereits in mehreren Systemen umgesetzt. Beispiele sind: Rebecca [Müh02], Jedi [CNF01], Siena [CRW01], Gryphon [Cen], und Hermes [PB02] Unterschiede zwischen den Systemen liegen in der Art der Subscription (channel based, topic based, content based), im Event-Dispatching (zentral, verteilt, broadcast) sowie den eingesetzten Filter- und Routingverfahren. Der interne Aufbau dieser Systeme sowie deren Unterschiede spielen in der weiteren Betrachtung aber keine Rolle. Produzent Filter1 Filter2 Filter3 Konsument Abbildung 1.2: Datenfluß in einem eventbasierten System Abbildung 1.2 zeigt ein Beispiel für den Datenfluß von einem Produzenten zu einem Konsumenten. Dabei werden jeweils nur die aktiven, für diesen Datenfluß relevanten Filter gezeigt. Da man die Aggregation von Events ebenfalls als Filter auffassen kann, z.b. das Zusammenfassen mehrerer zeitlich aufeinanderfolgender Events als Filtern im Zeitbereich, möchte ich im folgenden beliebige Transformationen von Benachrichtigungen als Filter bezeichnen und nicht zwischen den verschiedenen Möglichkeiten, Daten zu bearbeiten, unterscheiden. In dieser einfachen Ausführung kann keine Garantie gegeben werden, ob bzw. wie oft Benachrichtigungen ausgeliefert werden. Falls z.b. ein Filter ausfällt, gehen alle Benachrichtigungen verloren, die von diesem Filter empfangen aber noch nicht weitergeleitet wurden. Es ist auch möglich, daß Benachrichtigungen vervielfältigt werden, wenn Empfangsquittungen für Benachrichtigung verloren gehen und Benachrichtigungen deshalb wiederholt werden. Im Unterschied zu verbindungsorientierten Protokollen wie z.b. TCP ist keine Ende-zu-Ende Fehlerkorrektur möglich, da die Identität der beteiligten Komponenten und noch nicht

12 4 KAPITEL 1. EINFÜHRUNG einmal deren Anzahl bekannt sind. Eine Fehlerkorrektur kann jeweils nur während der Übertragung einer Benachrichtigung zwischen zwei benachbarten Komponenten eingesetzt werden. Dieses Verhalten ist für Anwendungen nicht tolerabel, die davon abhängen, daß Benachrichtigungen exakt einmal übertragen werden, wie z.b. Anwendungen, die das Auftreten von Ereignissen zählen. Besonders wichtig wird die Eigenschaft, daß Benachrichtigungen exakt einmal übertragen werden, sobald Aggregate eingesetzt werden, da ein einzelnes Aggregat sehr viele einzelne Benachrichtigungen repräsentieren und so ein Verlust dementsprechend eine große Auswirkung haben kann. Produzent Filter1 Filter2 Filter3 Konsument DB1 DB2 DB3 verteilte Transaktion einfache Transaktion Abbildung 1.3: Transaktionelle Nachrichten Dieses Problem läßt sich durch den Einsatz von Transaktionen und persistenter Speicherung also z.b. durch den Einsatz von Datenbankmechanismen lösen (Abbildung 1.3). Wichtige Benachrichtigungen werden weitergegeben, indem sie innerhalb einer (verteilten) Transaktion aus einer Datenbank bzw. Tabelle gelöscht werden und in die nächste eingefügt werden. Da Transaktionen immer komplett oder gar nicht ausgeführt werden, wird so sichergestellt, daß Benachrichtigungen immer exakt einmal weitergegeben werden. Auch beim Ausfall eines Knotens bleiben Nachrichten sicher gespeichert und stehen nach einem Neustart des Knotens wieder zur Verfügung. Je nach Fall werden sowohl einfache als auch verteilte Transaktionen eingesetzt. In diesem Aufbau vereinfachen sich auch die Anforderungen an die eingesetzten Filter: Da alle Zustandsinformationen in den Datenbanken gehalten werden, brauchen die Filter selbst keine Zustandsinformation mehr speichern und werden somit zustandslos. Dies betrifft auch die Speicherung der Events, die für eine Aggregation benötigt werden. Auf diese Weise vereinfacht sich der Aufbau der Filter: Eine aufwendige Zustandsspeicherung, Fehlererkennung und Behandlung ist nicht notwen-

13 1.1. PUBLISH/SUBSCRIBE 5 dig, bei einem Ausfall kann ein Filter einfach neu gestartet werden. Der Einsatz von Transaktionen verhindert, daß Daten mehrfach bearbeitet werden. Somit können auch mehrere identische Filter parallel gestartet werden, um auf diese Weise sehr einfach Fehlertoleranz zu erreichen: Wenn ein Filter ausfällt, wird dessen Arbeit automatisch von einem identischen anderen Filter erledigt; eine eventuell vor dem Ausfall begonnene Transaktion wird automatisch abgebrochen. Dieses Vorgehen ist sehr ähnlich zu der Funktionsweise von Middleware Mediated Transactions, wie sie z.b. von X 2 TS zur Verfügung gestellt werden [LMB00, LT01]. Allerdings beschränken sich diese Systeme darauf Transaktionen zur Verfügung zu stellen, während sie den Aspekt der persistenten Speicherung an angeschlossene Datenbanken auslagern. Durch dieses Vorgehen ergeben sich jedoch auch Probleme: Die Zeit, die für ein Commit benötigt wird, limitiert die Ende-zu-Ende Laufzeit, da der nächste Filter Daten erst dann lesen kann, wenn das Commit des vorangegangenen Filters abgeschlossen ist. Auch der Einsatz von optimistischen Verfahren bringt nur teilweise eine Verbesserung: Zwar könnte der Lesezugriff bereits früher stattfinden, aber auch in diesem Fall kann ein Commit erst dann abgeschlossen werden, wenn alle vorangegangenen Transaktionen erfolgreich mit Commit beendet werden konnten, denn falls ein Commit fehlschlägt darf auch das Commit der nächsten Filterstufe nicht durchgeführt werden, da diese dann ungültige Daten gelesen hat. Somit wird das Problem nur bis zum nächsten Commit aufgeschoben, aber nicht gelöst. Aus diesen Gründen wird ein Datenmanagementsystem benötigt, das ein Commit möglichst schnell abschließen kann. Fällt das Datenmanagementsystem aus, so gehen zwar keine Benachrichtigungen verloren, aber der Datenfluß ist unterbrochen und auf gespeicherte Benachrichtigungen kann bis zum Neustart nicht zugegriffen werden. Um dies zu vermeiden wird ein Datenmanagementsystem benötigt, das eine hohe Verfügbarkeit und Zuverlässigkeit bereitstellt, so daß auch bei einem Ausfall von einzelnen Komponenten oder Rechnern weiterhin ein gesicherter Betrieb ohne Unterbrechung gewährleistet ist. Steht ein solches Datenmanagementsystem zur Verfügung, so bietet es aber auch für andere Anwendungen innerhalb von eventbasierten Systemen Vorteile. Ein Beispiel hierfür ist mobile Publish/Subscribe [CFC + 03]: Viele eventbasierte Applikationen zeichnen sich dadurch aus, daß sie eine Initialisierungsphase benötigen, in der sie Notifikationen beobachten, um in einen konsistenten Zustand zu gelangen. In mobilen Szenarios wird diese Phase hauptsächlich benötigt, um die Applikation an die aktuellen Kontextinformationen anzupassen, die nur lokal verfügbar sind. Diese Phase läßt sich beschleunigen, wenn die benötigten Informationen von den Brokern

14 6 KAPITEL 1. EINFÜHRUNG in einem Cache auf Vorrat zwischengespeichert werden, von wo sie bei einer Subscription abgerufen werden können, um so die Initialisierungsphase zu beschleunigen. Werden diese Daten in einem hochverfügbaren Datenmanagementsystem gehalten, so läßt sich die Qualität dieser Daten gegenüber einem System verbessern, das bei einem Ausfall diese Daten verliert. Mit einem Ähnlichen Problem beschäftigt sich [Spi00]: Möchte man nicht nur aktuell auftretende Ereignisse betrachten, sondern wie sie sich über die Zeit verändern, wie sie zusammenhängen und voneinander abhängen so wird eine Historie der Ereignisse benötigt. Wird diese Historie im eventbasierten System gespeichert, so kann sie allen interessierten Clients zur Verfügung gestellt werden, ohne daß jeder Client eine eigene Historie verwalten müßte. 1.2 IP-Übernahmemechanismen Client Request IP Adresse IP Adresse Server Server Abbildung 1.4: IP-Übernahme bei zustandslosen Diensten Wird für Dienste eine hohe Verfügbarkeit benötigt, so ist es erforderlich diese redundant auszulegen. IP-Übernahmemechanismen stellen eine weit verbreitete Möglichkeit dar, dies zu realisieren [FHS03]. Ein Dienst wird in diesem Ansatz durch eine IP-Adresse (und Portnummer) repräsentiert. Clients verwenden diese Adresse, um mit dem Dienst via UDP oder TCP zu kommunizieren. Fällt der Dienst aus, so übernimmt ein anderer identischer Dienst die IP-Adresse. Zusammen mit der Eigenschaft, daß viele Clients eine Verbindung wieder aufbauen wenn sie unterbrochen wurde, um auf diese Weise Kommunikationsunterbrechungen im WAN auszugleichen, kann der Ausfall des Dienstes maskiert werden. Ganz so einfach funktioniert

15 1.2. IP-ÜBERNAHMEMECHANISMEN 7 Client Request IP Adresse IP Adresse Server Server zuverlässiges Datenmanagement system Abbildung 1.5: Auslagerung der Zustandsinformation das aber nur mit zustandslosen Diensten, die keine Informationen zu einer Client- Verbindung speichern (Abbildung 1.4). Einfache Webserver sind ein Beispiel für diesen Fall. Viele Dienste benötigen jedoch Zustandsinformationen, um Anfragen korrekt beantworten zu können. Fällt ein Server aus, so geht diese Information verloren. Um dies zu vermeiden kann der Dienst so modifiziert werden, daß der Zustand auf ein zuverlässiges, ausfallsicheres Speichersystem ausgelagert wird, womit der eigentliche Dienst zustandslos wird (Abbildung 1.5). Die Antwortzeit dieses Systems hängt ganz entscheidend vom eingesetzten Speichersystem ab, da jede Operation, die den Zustand ändert, der einem Client zugeordnet ist, zunächst abgespeichert werden muß, bevor eine Antwort an den Client gesendet werden kann, damit nach einem Serverausfall ein anderer Server nahtlos an der gleichen Stelle die Arbeit wieder aufnehmen kann. Damit dies möglich ist, muß von mehreren Rechnern auf das Speichersystem zugegriffen werden können. Von besonderer Wichtigkeit ist die Verfügbarkeit des Speichersystems, da die Verfügbarkeit des Gesamtsystems nicht besser als die Verfügbarkeit des Speichersystems sein kann.

16 8 KAPITEL 1. EINFÜHRUNG Insgesamt wird für diesen Anwendungszweck also ein sehr schnelles, ausfallsicheres Speichersystem benötigt. 1.3 Ziele und Ergebnisse dieser Arbeit Die soeben vorgestellten Anwendungsgebiete stellen sehr ähnliche Anforderungen an das Datenmanagementsystem: Die Menge der zu speichernden Daten ist nicht besonders groß (weit weniger als ein Gigabyte). Gleichzeitig haben die Daten nur eine geringe Lebensdauer und werden sehr oft geändert. In Publish/Subscribe-Systemen zum Beispiel brauchen sie nur solange gespeichert werden, bis sie erfolgreich an den oder die nächsten Broker weitergereicht werden konnten. Allen gemeinsam ist auch, daß die geforderten Eigenschaften nur unzureichend von festplattenbasierten Speichersystemen erfüllt werden können (vgl. Anhang A). Ein Einsatz von Festplatten in Publish/Subscribe-Systemen oder in hochverfügbaren Systemen, die stateless-server mit zusätzlichem hochverfügbarem Speicher für Zustandsinformationen einsetzen, führt aufgrund der hohen Zugriffszeiten von Festplatten zu hohen Ende-zu-Ende Verzögerungen bzw. zu langen Antwortzeiten. Den Flaschenhals stellt hierbei der Schreibzugriff auf die Festplatte dar. Erst nachdem dieser abgeschlossen ist, sind die Daten persistent gespeichert. Damit muß als Teil der Speicherung der Daten mindestens auf einen Schreibzugriff gewartet werden, was die hohe Zugriffszeit verursacht. Dabei spielt es keine Rolle, welche Mechanismen eingesetzt werden, also ob z.b. ein DBMS zur Verwaltung der Daten verwendet wird oder ob die Daten direkt von der Anwendung verwaltet werden. Die Zeit für diesen Schreibzugriff dominiert die insgesamt benötigte Zeit. Selbst bei den derzeit schnellsten Platten (IBM Ultrastar, U/min) fallen durchschnittlich 3, 4ms Positionierzeit und 2ms Latenz (rotational delay) an [IBM]. RAID-Systeme, die in anderen Fällen zur Steigerung der Leistung verwendet werden, helfen hier nicht weiter, da sie zwar den Durchsatz erhöhen und die Verfügbarkeit verbessern können, aber keine Vorteile beim Schreiben für die Zugriffszeit bringen. Bei RAID-Level 5 steigt sie sogar an, da zur Berechnung der neuen Parity-Prüfsumme vor dem Schreiben der Daten zusätzlich die alten Daten und Parity-Prüfsumme gelesen werden müssen. Mit Solid State Disks (SSD) gibt es zwar alternative Speichertechnologien, die niedrigere Zugriffszeiten bieten, jedoch sind diese entweder wenig geeignet oder sehr teuer: Flash-ROM basierte SSDs sind vergleichsweise billig, aber der darin verwendete Flash-Speicher kann nicht beliebig oft beschrieben werden. Typische Werte liegen bei Lösch-Schreib-Zyklen, z.b. für StrataFlash Memory (J3) [Int]. Auf eine

17 1.3. ZIELE UND ERGEBNISSE DIESER ARBEIT 9 Log-Datei finden im normalen Betrieb aber viele Schreibzugriffe statt (mind. ein Zugriff pro Transaktion), so daß diese Zahl innerhalb weniger Tage erreicht werden kann. Somit sind Flash-ROM SSDs für diesen Einsatz ungeeignet. DRAM-basierte SSDs unterliegen keiner Limitierung der Schreib-Lösch-Zyklen, sind aber um zwei Größenordnungen teurer als herkömmliche Festplatten. Für den Preis einer Athena-2 plus SSD mit 800MBytes bekommt man etwa 8 komplette Rechner mit insgesamt 8GBytes Hauptspeicher, wobei für ein hochverfügbares System mindestens zwei Platten notwendig sind. Ziel dieser Arbeit war es deshalb, ein hochverfügbares Datenmanagementsystem zu entwickeln, das auf den Einsatz von Festplatten zur sicheren Speicherung verzichten kann. HADES (Highly available distributed main-memory data management system) basiert daher auf der Idee, Persistenz nicht durch den Einsatz von externen Speichermedien, sondern durch den Einsatz von Redundanz zu erreichen. Daten werden im Hauptspeicher von mehreren Knoten eines Clusters gespeichert. Bei einem Rechnerausfall existiert somit noch eine Kopie und es kann weiterhin ohne Unterbrechung auf die Daten zugegriffen werden. Dies verspricht insgesamt niedrige Zugriffszeiten und eine hohe Verfügbarkeit. Da als Speichermedium keine externen Speichermedien eingesetzt werden, besteht keine Einschränkung auf blockorientierte Schreib- und Lesezugriffe, sondern es können beliebige Operationen mit beliebiger Datengranularität implementiert werden. Darüberhinaus bietet die Verteilung auf mehrere Rechner Möglichkeiten zur Parallelisierung. Auf diese Weise können als Nebeneffekt weitere Optimierungen eingesetzt werden, um die Bearbeitung von Daten weiter zu beschleunigen. In dieser Arbeit entwickle ich ein hochverfügbares Datenmanagementsystem, wie es von den vorgestellten Anwendungen benötigt wird. Im einzelnen enthält diese Arbeit folgende Beiträge: Beschreibung einer neuen Lösung (HADES). Beschreibung einer Implementierung auf Standard-Hardware. Evaluation eines Prototypen. Vergleich mit anderen Arbeiten. HADES stellt erstmals ein Datenmanagementsystem zur Verfügung, das Daten verteilt im Hauptspeicher eines Clusters ablegt, Persistenz durch Fehlertoleranz garantiert und dabei für niedrige Zugriffszeiten optimiert wurde. HADES benötigt keine spezielle Hardware, sondern kommt mit preiswerter Standard-Hardware aus. Die

18 10 KAPITEL 1. EINFÜHRUNG niedrigen Zugriffszeiten werden ausschließlich durch Kommunikations- und Datenmanagementstrategien erreicht, die dafür sorgen, daß möglichst direkt mit wenigen Netzwerkzugriffen auf die Daten zugegriffen werden kann. Mit dem erstellten Prototypen wurden mehrere Meßreihen durchgeführt, die die Vorteile von HADES aufzeigen. U.a. konnte damit belegt werden, daß die Zugriffszeiten etwa eine Größenordnung unter den Zugriffszeiten von schnellen Festplatten liegen. Es gibt verschiedene Systeme, die auf den ersten Blick eine große Ähnlichkeit zu HADES zu haben scheinen, die aber im Detail große Unterschiede aufweisen, die dazu führen, daß sie für Anwendungen ungeeignet sind, die niedrige Zugriffszeiten benötigen. 1.4 Überblick über die Arbeit Kapitel 2 gibt eine kurze Einführung in die Grundlagen der Fehlertoleranz, leitet daraus die Anforderungen an die Hardware ab und legt fest, welche Fehler vom System toleriert werden können. Kapitel 3 gibt einen Überblick über den Aufbau von HADES und die eingesetzten Komponenten. Kapitel 4 beschreibt die in HADES eingesetzte Kommunikationsschicht, die die Kommunikation im Cluster steuert, den Cluster verwaltet sowie dessen Konten überwacht. Kapitel 5 beschäftigt sich damit, wie die Daten im Cluster verteilt werden und welche Probleme bei der Verteilung gelöst werden mußten. Kapitel 6 stellt die Implementierung des Prototypen vor und beschreibt die zur Verfügung stehenden Operationen. In Kapitel 7 werden die Ergebnisse vorgestellt, die bei der Evaluation des Prototypen gewonnen wurden. Den Vergleich mit anderen Systemen und Arbeiten gibt Kapitel 8. Kapitel 9 schließt die Arbeit mit einer kurzen Zusammenfassung und gibt einen Ausblick auf weitere Themen. Anhang A gibt einen ausführlichen Überblick über Zugriffslatenzen und wie sie sich nicht vermeiden lassen. Der Pseudocode der in der Arbeit vorgestellten Algorithmen findet sich in Anhang B. Eine Kurzreferenz in Anhang C stellt die wichtigsten zur Verfügung stehenden Methoden der Programmierschnittstelle von HADES vor.

19 Kapitel 2 Annahmen über die Systemumgebung Bevor man beginnt ein System zu implementieren, muß nicht nur festgelegt werden, was das System leisten können soll, sondern es müssen auch verschiedene Annahmen über die Randbedingungen gemacht werden. Im Falle von HADES sind die zwei wichtigsten: Mit welchen Fehlern muß HADES umgehen können? Welche Hardware kann/soll eingesetzt werden? Diese beiden Punkte sind nicht unabhängig, sondern sie beeinflussen sich stark gegenseitig. Die gewünschte Fehlertoleranz bestimmt, welche Hardware-Umgebung eingesetzt werden muß, und umgekehrt limitieren die Kosten der Hardware welche Fehlertoleranz erreicht werden kann. Darüberhinaus wird von diesen beiden Punkten auch die Leistungsfähigkeit des Gesamtsystems mitbestimmt, so daß hier ein Kompromiß zwischen Leistungsfähigkeit, Fehlertoleranz und Kosten gefunden werden muß. In diesem Kapitel möchte ich daher erläutern, welcher Kompromiß für HADES gewählt wurde und auf welchen Grundlagen er basiert. 2.1 Grundlagen der Fehlertoleranz Fehlertoleranz ist die Eigenschaft eines Systems, auch beim Auftreten von Fehlern noch korrekt zu funktionieren. Genauer unterscheidet man dabei zwischen dem Defekt (fault) und dem von diesem Defekt verursachte Fehler (error), der dann zum 11

20 12 KAPITEL 2. ANNAHMEN ÜBER DIE SYSTEMUMGEBUNG Ausfall (failure) eines Systems führen kann [Gär01, Lap92]. Fehlertolerante Systeme können zwar keine Defekte verhindern, jedoch können sie die Auswirkungen von Defekten begrenzen, so daß ein Ausfall des Systems verhindert werden kann. Ein fehlertolerantes System kann allerdings nicht beliebige Fehler tolerieren, es gibt immer Fehler die schlimmer in ihrer Auswirkung sind als alle Fehler, die man beim Entwurf des Systems berücksichtigt hat. Gleichzeitig kann es aber einen erheblichen Mehraufwand bedeuten, wenn man einen zusätzlichen Fehler tolerieren können möchte. Daher muß ein Kompromiß gefunden werden, der einerseits hinreichend viele Fehler abdeckt, die in der Realität auftreten können, andererseits aber nur Fehler berücksichtigt, die mit vertretbarem Aufwand abgefangen werden können. Voraussetzung dafür, daß ein Fehler abgefangen werden kann, ist, daß nicht das komplette System ausfällt, sondern nur Teile davon, so daß die verbliebenen Komponenten die Aufgaben weiterhin erfüllen können. Während dieser Fall bei einzelnen Rechnern nur in Sonderfällen vorkommt, da Rechner nach einem Defekt normalerweise komplett ausfallen, ist dies in verteilten Systemen die Regel. In verteilten Systemen ist es unwahrscheinlich, daß alle Rechner gleichzeitig ausfallen. Normalerweise ist nur ein Teil der Komponenten betroffen, während der andere Teil weiterhin funktioniert. Diese inhärente Redundanz in verteilten Systemen kann daher gut ausgenutzt werden, um fehlertolerante Systeme zu bauen Fehlermodelle Bevor man sich mit Fehlertoleranz beschäftigen kann, gilt es zunächst einmal zu klären: Was ist ein Fehler? [Gär01, S. 34f] gibt hierfür eine nützliche Klassifikation von formalisierten Fehlermodellen: Fail-Stop: Prozesse können anhalten und senden danach nur noch Fehlermeldungen als Antwort. Dies ist z.b. der Fall falls ein einzelner Prozeß auf einem Rechner abstürzt. Für alle folgenden Versuche mit diesem Prozeß zu kommunizieren, wird vom Betriebssystem eine Fehlermeldung generiert (vgl. hierzu auch [SS83]). Crash: Prozesse können abstürzen (crash) und antworten danach nicht mehr. Im Unterschied zum vorangegangenen Fall werden keine Fehlermeldungen als Antwort generiert. Dies passiert z.b. wenn ein kompletter Rechner abstürzt. General Omission: Zusätzlich zu Crash können beliebig viele Nachrichten auf den Kommunikationsverbindungen z.b. durch Störungen verloren gehen.