Verteilte Systeme 2011

Verteilte Systeme
Oliver BRAUN (Hrsg.)
Fakultt Informatik a Fachhochschule Schmalkalden
Wintersemester 2011/2012
Inhaltsverzeichnis
1 Fehlertoleranz in verteilten Systemen Ricardo Hohmann . . . . . . . . . . . . . . . 1
2 Das Google File System . . . . . . . . . . . . . . . . . . . . . . . Oliver Wolf 3 Verteilte Multimediasysteme . . . . . . . . . . . . . . . . . . . . Philipp Richardt 4 OpenCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roger Jger a 5 Peer-to-Peer-Systeme . . . . . . . . . . . . . . . . . . . . . . . . Tim Achtert 6 Sicherheit in verteilten Systemen . . . . . . . . . . . . . . . . . . Mario Fhr o 7 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markus Schramm 8 Verteilte Transaktionen . . . . . . . . . . . . . . . . . . . . . . . Christian Reibeholz
11
23
35
47
49
61
71
IV
Inhaltsverzeichnis
Fehlertoleranz in verteilten Systemen
Ricardo Hohmann
Inhaltsverzeichnis
1.1 Grundlagen . . . . . . . . . . . . . . . . . 1.1.1 Denition . . . . . . . . . . . . . . 1.1.2 Grundlegende Konzepte . . . . . . 1.1.3 Fehlermodelle . . . . . . . . . . . 1.1.4 Fehlermaskierung durch Redundanz Prozesselastizitt . . . . . . . . . . . . . . a 1.2.1 Entwurfsaspekte . . . . . . . . . . 1.2.2 Fehlermaskierung und Replikation . 1.2.3 k-Fehlertoleranz . . . . . . . . . . RPC-Semantik beim Vorliegen von Fehlern 1.3.1 Client ndet Server nicht . . . . . 1.3.2 Verlorene Anforderungsnachricht . 1.3.3 Server-Absturz . . . . . . . . . . . 1.3.4 Verlorene Antwortnachricht . . . . 1.3.5 Client-Absturz . . . . . . . . . . . Wiederherstellung . . . . . . . . . . . . . . 1.4.1 Einfhrung . . . . . . . . . . . . . u 1.4.2 Prfpunkte . . . . . . . . . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 3 3 3 4 5 5 6 6 6 7 8 9 9 9
1.2
1.3
1.4
Kennzeichnend fr verteilte Systeme ist der partielle Ausfall. Dieser tritt auf, u wenn eine Komponente in einem verteilten System ausfllt. Andere Komponenten a knnen ihre Arbeit fortsetzen und so ggf. weiterhin Anforderungen bearbeiten. o Ein Entwurfsziel beim Aufbau eines verteilten Systems sollte es daher sein, dass das System nach partiellen Ausfllen automatisch wiederhergestellt werden kann a und auch bei auftretenden Fehlern weiterhin funktionsfhig bleibt. a Was es fr ein verteiltes System bedeutet, fehlertolerant zu sein und wie eben u dies umgesetzt werden kann, wird auf den folgenden Seiten beschrieben.
1 Fehlertoleranz in verteilten Systemen
1.1
Grundlagen
In diesem Kapitel werden Begrie erlutert, die fr das Verstndnis fehlertolerana u a ter Systeme notwendig sind.
1.1.1
Denition
Fehlertoleranz (von lat. tolerare, erleiden, erdulden) ist die Eigenschaft eines technischen Systems, seine Funktionsweise auch aufrechtzuerhalten, wenn unvorhergesehene Eingaben oder Fehler in der Hardware oder Software auftreten.[1]
1.1.2
Grundlegende Konzepte
Ein verteiltes System mit hoher Fehlertoleranz ist auch gekennzeichnet durch eine hohe Verlsslichkeit. Diese deckt vier praktische Anforderungen ab, die an a verteilte Systemen gestellt werden. Verfgbarkeit ist die Eigenschaft, dass ein System unmittelbar zur Nutzung beu reitsteht, wenn ein Zugri erfolgt. Im Allgemeinen drck die Verfgbarkeit u u die Wahrscheinlichkeit aus, dass ein System zu einer bestimmten Zeit zur Verfgung steht und funktioniert. u Zuverlssigkeit ist die Eigenschaft, dass ein System fortlaufend fehlerfrei ausa gefhrt werden kann. Dabei bezieht sich die Zuverlssigkeit auf einen zusamu a menhngenden Zeitintervall, whrend die Verfgbarkeit sich auf Zeitpunkt a a u bezieht. Sicherheit ist die Eigenschaft, die besagt, dass nichts katastrophales passieren darf, wenn ein System vorbergehend nicht korrekt funktioniert. u Wartbarkeit ist die Eigenschaft, die besagt, wie einfach oder schwierig es ist, ein ausgefallenes System zu reparieren. Von einem Ausfall ist die Rede, wenn ein System seine Zusagen nicht mehr einhalten kann. Die Ursache eines Ausfalls wird als Fehler bezeichnet. Es gibt verschiedene Mglichkeiten der Klassikation von Fehlern in verteilten Syso temen. Folgend sind Fehler nach chronologischen Aspekten klassiziert, whrend a im nchsten Kapitel 1.1.3 Fehler nach ihrem Typ klassiziert werden. a Vorbergehende Fehler treten einmalig auf. Bei Wiederholung der Operatiu on tritt kein Fehler mehr auf. Derartige Fehler knnen auftreten, wenn o Ubertragungswege gestrt werden. o
1.1 Grundlagen
Periodischer Fehler treten mehrfach auf, ohne dass sich ein Muster abzeichnet. Diese Fehler sind schwierig zu Diagnostizieren. Mgliche Ursache ist ein o Wackelkontakt in einem Stecker. Permanente Fehler treten auf, wenn eine Komponente im verteilten System nicht mehr funktioniert. Eine Fehlerbehebung ist nur durch Ersatz der fehlerhaften Komponente mglich. o
1.1.3
Fehlermodelle
Die folgende Auistung soll ein Gefhl dafr vermitteln, wie schwerwiegend veru u schiedene Fehler sind. Der Bezeichnung eines Fehlertyps folgt jeweils eine kurze Beschreibung. Absturzfehler: Ein Server wurde unterbrochen, hat aber bis zu diesem Zeitpunkt korrekt gearbeitet. Auslassungsfehler: Ein Server reagiert nicht auf eingehende Anforderungen. Empfangsauslassung: Ein Server erhlt keine eingehenden Anforderungen. a Sendeauslassung: Ein Server sendet keine Nachrichten. Timing-Fehler: Die Antwortzeit eines Servers liegt auerhalb eines festgelegten Zeitintervalls. Antwortfehler: Die Antwort des Servers ist falsch. Wertfehler: Der Wert der Antwort ist falsch. Statusbergangsfehler: Der Server weicht vom korrekten Steueruss ab. u Zufllige Fehler: Ein Server erzeugt zu zuflligen Zeiten zufllige Antworten. a a a Die zuflligen Fehler sind am schwierigsten zu beheben. Sie werden auch Bya zantinische Fehler1genannt. So kann es vorkommen, dass ein Server Ausgaben erzeugt, die nie erzeugt werden sollten, aber nicht als fehlerhaft erkannt werden. Noch schlimmer wird es, wenn dies in Zusammenarbeit mit anderen Servern geschieht.
1.1.4
Fehlermaskierung durch Redundanz
Redundanz ist die wichtigste Technik zur Maskierung von Fehlern. Maskierung ist das Verbergern von Fehlern vor anderen Prozessen. Es gibt 3 Arten von Redundanz.
1 Der Begri byzantinischbezieht sich auf das byzantinische Reich, Zeit (330 - 1435) und Ort (der Balkan und die heutige Trkei) endloser Verschwrungen und Intrigen, die in Herrscheru o kreisen als ublich galten.
Informationsredundanz: Durch das Hinzufgen von Prfbits wird die Herstelu u lung von Daten ermglicht. o zeitliche Redundanz: Eine Aktion wird ausgefhrt und ggf. wiederholt. Ein Beiu spiel ist die Verwendung von Transaktionen. Besonders praktisch ist diese Form der Redundanz bei vorbergehenden und periodischen Fehlern. u physische Redundanz: Der Verlust / die Fehlfunktion bestimmter Komponenten wird durch Replikation kompensiert. Dies kann mithilfe von Software oder Hardware erfolgen.
1.2
Prozesselastizitt a
In diesem Kapitel wird sich mit der Frage befasst, wie Fehlertoleranz realisiert werden kann, wenn die Prozesse an sich fehlerhaft sind.
1.2.1
Entwurfsaspekte
Der wichtigste Ansatz zum Schutz gegen Prozessfehler ist die Replikation identischer Prozesse in Gruppen. Alle Prozesse, die sich in einer Gruppe benden, empfangen die Nachrichten, die an die Gruppe gesendet werden. Wenn ein Prozess fehlerhaft ist, so kann ein anderer Prozess seine Arbeit ubernehmen. Die Prozessgruppen knnen dynamisch sein. Neue Gruppen knnen erzeugt oder o o alte zerstrt werden. Weiterhin ist es jederzeit mglich, dass Prozesse Gruppen o o beitreten oder sie verlassen. Ein Prozess kann in mehreren Gruppen gleichzeitig sein. Ein mglicher Ansatz zur Verwaltung der Gruppen und Prozesse ist die o Verwendung eines Gruppenservers. Weiterhin lassen sich die Prozessgruppen in ache und hierarchische Gruppen einteilen (siehe Abbildung 1.1). In der achen Gruppe (a) sind alle Prozesse identisch. Entscheidungen werden gemeinsam getroen und jeder Prozess der Gruppe kommuniziert mit jedem anderen. In einer hierarchischen Gruppe (b) hingegen gibt es einen Koordinator, den Chef der Gruppe. Die Arbeiter kommunizieren nicht untereinander, sondern nur mit dem Koordinator. Beide Einteilungen haben ihr Vor- und Nachteile. Ein Vorteil einer achen Gruppe liegt darin, dass sie keinen Ausfallpunkt hat, whrend eine hierarchische Gruppe a nicht mehr weiterarbeiten kann, wenn der Koordinator ausfllt. Ein Nachteil eia ner achen Gruppe ist die komplizierte Entscheidungsndung per Abstimmung, whrend bei hierarchischen Gruppen Entscheidungen allein durch den Koordinator a getroen werden knnen. o
1.2 Prozesselastizitt a
Abbildung 1.1: Kommunikation in Prozessgruppen
1.2.2
Fehlermaskierung und Replikation
Prozessgruppen sind ein Teil der Lsung zum Aufbau fehlertoleranter Systeme. o Einzelne Prozesse werden repliziert, um einen einzigen (ungeschtzten) Prozess u durch eine (fehlertolerante) Gruppe zu ersetzen. Es gibt zwei Mglichkeiten fr o u eine solche Replikation, nmlich primrbasierte Protokolle und Protokolle mit a a repliziertem Schreiben. Primrbasierte Protokolle basieren auf hierarchischen Gruppen. Anforderungen a werden an einen primren Prozess weitergeleitet. Fllt dieser aus, wird auf einen a a Backup-Prozess zugegrien, der die Anforderung erfllt. u Protokolle mit repliziertem Schreiben basieren auf achen Gruppen. Anforderungen knnen von jedem der Gruppenmitglieder erfllt werden. o u
1.2.3
k-Fehlertoleranz
Die folgenden Ausfhrungen beziehen sich auf Systeme mit repliziertem Schreiu ben. Der Wert kgibt ein Ma an, wie fehlertolerant eine Prozessgruppe ist. Er lsst sich wie folgt beschreiben. Ein System ist k-fehlertolerant, wenn es a Fehler in k Komponenten kompensieren und seine Aufgaben dennoch erledigen kann.[2]Eine Prozessgruppe mit k+1 replizierten Prozessen ist somit auch bei Ausfall von k Prozessen noch funktionsfhig. Dies gilt jedoch nicht, wenn die feha lerhaften Prozesse byzantinische Fehler aufweisen. Dann werden 2k+1 Prozesse bentigt, um ein System k-fehlertolerant zu machen. o
1.3
RPC-Semantik beim Vorliegen von Fehlern
Nachdem das letzte Kapitel von Fehlern handelt, die bei fehlerhaften Prozessen auftreten knnen, soll es in diesem um den Umgang mit fehlerhafter Kommuo nikation gehen. Ein Kommunikationskanal kann dabei Absturz-, Auslassungs-, Timing- und zufllige Fehler aufweisen. a Bei der Punkt-zu-Punkt-Kommunikation knnen Fehler teilweise durch die o Verwendung eines zuverlssigen Transportprotokolls wie TCP maskiert wera den. So werden Auslassungsfehler mithilfe von Besttigungen und erneuten a Ubertragungen maskiert. Nicht maskiert werden Absturzfehler. Meist wird allerdings der Client durch das Werfen einer Ausnahme uber den Absturz des Servers informiert. Die einzige Mglichkeit der Maskierung ist die automatische Einricho tung einer neuen Verbindung. Auf einer hheren Ebene der Client-Server-Kommunikation sind Kommunikatio onsfunktionen wie RPC (Remote Procedure Calls) angesiedelt. RPCs beschreiben entfernte Prozessaufrufe, die wie lokale Prozessaufrufe aussehen und sich auch, bei korrekt funktionierendem System, genauso verhalten. Die Kommunikation wird verborgen. In den folgenden Kapiteln werden fnf Fehlerklassen unterschieden, u die in RPC-Systemen auftreten knnen. Es werden die auftretenden Probleme o und mgliche Lsungen beschrieben. o o 1. Der Client ndet den Server nicht 2. Die Anforderungsnachricht vom Client an den Server geht verloren. 3. Der Server strzt ab, nachdem er eine Anforderung empfangen hat. u 4. Die Antwortnachricht vom Server an den Client geht verloren. 5. Der Client strzt ab, nachdem er eine Anforderung gesendet hat. u
1.3.1
Client ndet Server nicht
Die Ursache fr einen solchen Fehler kann sein, dass der Server nicht mehr luft u a oder sich in Wartung bendet. Auch kann Server-seitig eine neue Schnittstelle installiert worden sein, welche die alte ablst und fr den Client nicht aundbar o u ist. Eine mgliche Lsung ist das Werfen einer Ausnahme. Nachteil dieses Ano o satzes ist, dass die Transparenz verloren geht. Ein Fehler wie Kann Server nicht nden.knnte in einem lokalen System gar nicht auftreten. o
1.3.2
Verlorene Anforderungsnachricht
Dieser Fehler ist einfach zu beheben. Eine mgliche Lsung ist der Einbau eines o o Client-seitigen Timers. Ist nach Zeit t noch keine Antwort auf die Anforderung
1.3 RPC-Semantik beim Vorliegen von Fehlern
gekommen, sendet der Client eine Neuanforderung. Server-seitig treten keine Probleme auf. Nur die Neuanforderung wird vom Server erkannt und entsprechend bearbeitet. Client-seitig knnen Probleme auftreten, die in Kapitel 1.3.4 erklrt o a werden.
1.3.3
Server-Absturz
Abbildung 1.2: Server-Absturz in der Client-Server-Kommunikation
Zur vereinfachten Anschauung soll die Abbildung 1.2 dienen. In (a) ndet die normale Ereignisabfolge statt. Eine Anforderung trit ein, wird ausgefhrt, und u eine Antwort wird gesendet. (b) und (c) zeigen Fehlerflle, bei denen der Server a abstrzt. Dabei strzt in (b) der Server erst nach Ausfhrung der Anforderung ab, u u u whrend er in (c) vor der Ausfhrung abstrzt. Problematisch ist, dass die korrekte a u u Behandlung des Absturzes sich in beiden Fllen unterscheidet. In (b) muss das a System den Fehler an den Client zurckmelden, whrend in (c) die Anforderung u a einfach erneut ubertragen werden kann. Fr den Client gibt es keinen Unterschied u bei (b) oder (c), er erhlt in beiden Fllen keine Antwort. a a Im folgenden soll ein Beispiel vorgestellt werden, das verdeutlicht, welche Konsequenzen ein Serverabsturz (Crash) bei verschiedenen Fehlerfall-Strategien von Client und Server haben kann. Uber einen RPC soll ein Text ausgedruckt werden. Der Client sendet die Anforderung, einen Text zu drucken. Der Server reagiert, indem er den Text ausdruckt (Print) und eine Besttigungsnachricht (Message) a an den Client sendet. Nach einem Crash sendet der Server die Nachricht an den Client, dass er abgestrzt ist und jetzt wieder luft. u a Der Server kann zwei Strategien verfolgen. Erstens kann er erst den Text drucken (P) und danach die Besttigung senden (M). Zweitens kann er aber auch erst a die Besttigung senden (M) und danach den Text drucken (P). a Der Client kann vier Strategien verfolgen, wenn er vom Server die Absturznachricht erhlt (C). Erstens kann er immer eine neue Anforderung absetzen. Zweitens a kann er nie eine neue Anforderung absetzen. Drittens kann er nur dann eine neue Anforderung absetzen, wenn er eine Besttigung erhalten hat und viertens kann a er nur dann eine neue Anforderung absetzen, wenn er keine Besttigung erhalten a
hat. Die Konsequenzen der acht sich ergebenden Strategiekombinationen verdeutlicht Abbildung 1.3.
Abbildung 1.3: Unterschiedliche Kombinationen von Client-/Server-Strategien bei Server-Absturz
Die Klammern zeigen an, dass das Ereignis nicht mehr eintreten kann. Es ist klar ersichtlich, dass es keine Kombination aus Client- und Server-Strategie gibt, die fr alle mglichen Ereignisabfolgen korrekt funktioniert. Der Client kann nie u o wissen, ob der Server nach oder vor Ausdruck des Textes abgestrzt ist. u
1.3.4
Verlorene Antwortnachricht
Wie auch schon in Kapitel 1.3.2 ist auch in diesem Kapitel das Hauptproblem, dass der Client nicht wei, warum er vor Ablauf seines Timers keine Antwort erhalten hat. Er wei nicht, ob die Anforderung oder die Antwort verlorengegangen oder ob der Server schlichtweg zu langsam ist. Das standardisierte Verhalten ist die Neuanforderung. Bei Operationen, die beliebig oft wiederholt werden knnen, o hat eine Neuanforderung keine negativen Auswirkungen. Eine Anforderung ohne Seiteneekte, die beliebig oft ausgefhrt werden kann, wird auch als idempotent u bezeichnet. Allerdings gibt es auch Anforderungen, die Seiteneekte hervorru fen. Ein berhmtes Beispiel ist die Uberweisung. Diese darf nur genau einmal u ausgefhrt werden. u
1.4 Wiederherstellung
Eine mgliche Lsung ist, jeder Anforderung des Clients eine Folgenummer zuo o zuweisen, sodass der Server den Unterschied zwischen einer Originalanforderung und einer Neuanforderung erkennen und sich weigern kann, diese Anforderung ein zweites Mal auszufhren. Zudem kann ein Wchter verwendet werden, dau a her ein Bit im Nachrichtenheader, das bei einer Neuanforderung gesetzt wird. Die Idee dahinter ist, dass die Ausfhrung einer Originalanforderung immer sicher u ist, whrend bei einer Neuanforderung seitens des Servers eine hhere Sorgfalt a o notwendig ist.
1.3.5
Client-Absturz
Die letzte Fehlerklasse beschreibt einen Client, der abstrzt, nachdem er eine Anu forderung an einen Server gesendet hat. Die Folge ist, dass eine Berechnung aktiv ist, auf deren Ergebnis niemand mehr wartet. Eine solche Berechnung wird auch als Waise bezeichnet. Fr den Umgang mit Waisen gibt es die vier Mglichkeiten u o der Exterminierung, Reinkarnation, gndigen Reinkarnation und den Ablauf. Keia ne der genannten Mglichkeiten ist wnschenswert. Besonders kritisch werden o u Waisen, wenn sie Sperren fr Dateien oder Datenbankstze angefordert haben, u a die nicht mehr aufgehoben werden knnen. Zudem kann ein Waise bereits meho rere Prozesse in Auftrag gegeben haben, sodass auch ein Lschung des Waisen o seine Spuren nicht vollstndig verwischt. a
1.4
Wiederherstellung
In diesem Kapitel sollen Verfahren beschrieben werden, die ein System nach einem Fehler wieder in einen korrekten Status uberfhren. u
1.4.1
Einfhrung u
Fr die Wiederherstellung eines korrekten Status gibt es zwei Mglichkeiten. u o Bei der Rckwrts-Wiederherstellung (Backward Recovery) wird das System u a aus dem aktuellen, fehlerhaften Status in einen vorherigen, korrekten Status uberfhrt. Voraussetzung sind Prfpunkte (Checkpoints), welche im folgenden u u Kapitel 1.4.2 erlutert werden. a Bei der VorwrtsWiederherstellung (Forward Recovery) wird das System aus a dem aktuellen, fehlerhaften Status in einen neuen, korrekten Status uberfhrt. u Voraussetzung ist, dass mgliche Fehler vorher bekannt sind. o
10
1.4.2
Prfpunkte u
Fr die Rckwrts-Wiederherstellung ist es notwendig, dass das System seinen u u a Status regelmig in einen stabilen Speicher schreibt. Diese Aufzeichnung von a Prfpunkten kann sehr kostspielig sein und zu Leistungseinbuen fhren. Daher u u wird sie oft in Kombination mit der Nachrichtenprotokollierung verwandt. Zudem ist es erforderlich, einen konsistenten, globalen Status des verteilten Systems aufzuzeichnen, auch als verteilte Momentaufnahme bezeichnet. Die letzte verteilte und konsistente Momentaufnahme wird auch als Wiederherstellungsverlauf bezeichnet.
Abbildung 1.4: Suche nach dem Wiederherstellungsverlauf von zwei Prozessen
Die Abbildung 1.4 soll der Veranschaulichung dienen. P1 und P2 sind Prozesse, von denen regelmig Prfpunkte erstellt werden. Nun tritt in P2 ein Fehler auf a u und der Wiederherstellungsverlauf soll ermittelt werden. Der letzte Prfpunkt von u P2 (P2**) passt nicht zu (P1**), weil die Nachricht (N2) in (P2**) gespeichert ist, nicht aber in (P1**). Daher kann (P2**) nicht als Prfpunkt verwendet weru den. Der vorige Prfpunkt (P2*) passt nicht zu (P1**), weil (N1) nur in (P1**) u gespeichert ist. (P1*) und (P2*) sind allerdings konsistent und somit der Wiederherstellungsverlauf der Prozesse P1 und P2.
Literaturverzeichnis
[1] Wikipedia, Fehlertoleranz http://de.wikipedia.org/wiki/Fehlertoleranz, 2012 [2] A. Tannenbaum und M. van Steen, Verteilte Systeme: Grundlagen und Paradigmen. Pearson Studium, 2003.
Das Google File System
Oliver Wolf
Inhaltsverzeichnis
2.1 2.2 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . Design des GFS . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Annahmen von Google an das Design . . . . . . . 2.2.2 Architektur des GFS . . . . . . . . . . . . . . . . 2.2.3 Konsistenzmodell . . . . . . . . . . . . . . . . . Systeminteraktionen des GFS . . . . . . . . . . . . . . . 2.3.1 Kontrollrechte und Mutationsreihenfolge . . . . . 2.3.2 Datenuss . . . . . . . . . . . . . . . . . . . . . 2.3.3 Record Append-Operation . . . . . . . . . . . . . 2.3.4 Snapshot-Operation . . . . . . . . . . . . . . . . Masteroperationen . . . . . . . . . . . . . . . . . . . . . 2.4.1 Management des Namensraumes . . . . . . . . . 2.4.2 Verteilung, Erstellung und Reproduktion von Kopien 2.4.3 Garbage Collecion . . . . . . . . . . . . . . . . . Fehlertoleranz, Zuverlssigkeit und Verfgbarkeit . . . . . a u Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 11 12 12 13 15 15 15 16 16 17 17 17 17 18 19 20
2.3
2.4
2.5 2.6
2.1
Einleitung
Google deckt fast 80 % aller Suchanfragen (200.000.000 pro Tag) ab und ist damit die mit Abstand bedeutendste Suchmaschine. Mit dem erfolgreichen Brsengang o in 2004 stellt Google eine der bedeutendsten success stories des Internet dar.1 Durch die immer strkere Nutzung der Suchmaschine, sowie die komplexer wera denden Google-Applikationen ist die zu verwaltende Datenmenge in den letzten Jahren stark angewachsen. Dies war die Ursache fr die Entwicklung neuer Konu zepte, um eine konsistente Datenhaltung und -verwaltung, sowie eine schnelle Datenrettung zu ermglichen. Im Mittelpunkt dieser Entwicklung steht die Sio cherung der Performance des Systems, das Milliarden von Dokumenten verwaltet
1
Vgl. LivingLogic, Suchmaschinen-Optimierung fr Google ohne Tricks u
12
2 Das Google File System
und mehrere tausende Treer pro Suchanfrage nach Relevanz ordnet. Der Umfang und die Komplexitt des Systems stellen dabei sowohl besondere Herausforderuna gen an die einzusetzende Hardware, als auch an die Konzepte der Datenverteilung und -sicherung. Ein unerwarteter Ansatz ist dabei der Verzicht auf teure Spezialhardware. Alle Anwendungen laufen auf gewhnlicher PC-Hardware und o sind somit sehr wirtschaftlich im Vergleich zu teurerer Spezialhardware. Durch den Einsatz gewhnlicher PC-Hardware sind Ausflle von Festplatten oder ganzer o a Server wesentlich wahrscheinlicher, es wird sogar mit dem Ausfall von Systemen gerechnet. Dass Anwendungen dennoch so zuverlssig und schnell funktionieren, a liegt an der Struktur des von Google entwickelten Dateisystems dem Google File System (GFS). Dieses wurde entwickelt, um den wachsenden Anforderungen der Datenverarbeitung von Google zu begegnen. Es bietet eine hohe Fehlertoleranz, sodass Fehler automatisch entdeckt und Wiederherstellungen automatisiert ausgefhrt werden. Nachteile der Hardwarekonguration knnen damit abgefanu o gen werden. Eine weitere strukturelle Besonderheit des GFS stellt die Verwaltung von Schreibzugrien dar. Bestehende Dateien werden nicht durch schwer zu kontrollierende Schreiboperationen, sondern vielmehr durch leichter zu verwaltende Append-Operationen erweitert. Es ist somit mglich, dass viele Nutzer gleichzeitig o auf grere Dateien schreibend zugreifen, ohne dass eine stndige Synchronisation o a zwischen diesen Nutzern stattnden muss. Die vorliegende Arbeit soll einen Einblick in die Funktionsweise und Komplexitt des GFS geben sowie die strukturelle Umsetzung der Anforderungen aufa zeigen. Dazu wird im zweiten Kapitel zunchst das Design des GFS ausfhrlich a u diskutiert. Das dritte Kapitel wird die Systeminteraktion des GFS aufzeigen. Im vierten Kapitel stehen die Masteroperationen des GFS im Mittelpunkt. Die aus den Vorkapiteln realisierten Vorteile bezglich Fehlertoleranz, Zuverlssigkeit und u a Verfgbarkeit werden im fnften Kapitel aufgegrien und evaluiert. Das letzte u u Kapitel stellt eine Zusammenfassung der evaluierten Informationen dar.
2.2
2.2.1
Design des GFS

Annahmen von Google an das Design
Beim Entwurf moderner Datenverarbeitungssysteme werden immer diverse Annahmen getroen, welche die Designentscheidungen leiten, wie auch fr das GFS. u Folgende vier Annahmen sind fr das GFS essentiell: u 1. Ausflle von Computer-Komponenten sind die Regel. Das Dateisystem a besteht aus tausenden, preiswerten Computern von denen nicht alle durchweg funktionsfhig arbeiten knnen und manche nach ihren Ausfllen sich a o a
2.2 Design des GFS
13
nicht wiederherstellen lassen. Probleme knnen auftreten bei Anwendungs-, o Betriebssystem und menschlichen Fehlern sowie das Versagen von Festplatten, Speichern, Anschlssen, Netzwerken und Netzgerten. Daher ist eine stndige u a a Uberwachung, Fehlererkennung, Fehlertoleranz und die automatische Wiederherstellung integraler Bestandteil des GFS. 2. Die Dateigre wchst. Jede Datei enthlt viele Anwendungsobjekte wie o a a z. B. Web-Dokumente. Bei wachsenden Datenmengen von vielen TBs mit Milliarden von Objekten ist es unhandlich Milliarden KB groe Dateien zu verwalten. 3. Die meisten Dateien sind verndert durch Anhngen neuer Daten ana a statt dem Uberschreiben vorhandener Daten. 4. Erhhung der Flexibilitt. Das GFS Konsistenz Modell wurde entspannt, o a um das Dateisystems zu vereinfachen ohne dass es zu Belastungen fr die u Anwendungen kommt. Weiterhin wurde eine atomare Append-Operation eingefhrt, so dass mehrere Clients gleichzeitig an eine Datei anhngen knnen u a o ohne zustzliche Synchronisation zwischen den Clients. a
2.2.2
Architektur des GFS
Um groe Datenmengen zu speichern sowie die Verfgbarkeit zu erhhen setzt u o Google auf alt bewhrte Computercluster. Ein Computercluster bezeichnet den a Verbund von Computern zur Steigerung der Rechenleistung und Ausfallsicherheit. Ein GFS-Cluster besteht dabei aus einem Master-Server sowie mehreren Chunk-Servern auf denen Dateien gespeichert werden. Jeder dieser Server ist in der Regel ein gewhnlicher Linux-Server. Die Dateien werden in einzelne Chunks o gesplittet und auf den Chunk-Servern lokal gespeichert. Sie werden in Chunks fester Gre unterteilt. Jeder Chunk ist identizierbar durch einen vom Master o unvernderlichen 64-Bit-Schlssel, dem Chunk-Handle, der zum Zeitpunkt der Era u stellung zugeordnet wird. Zum Zwecke der Zuverlssigkeit werden Replikationen a jedes Chunks auf mehreren Chunk-Servern gespeichert. Der Master-Server ist fr die Organisation aller Metadaten des Dateisystems u zustndig. Dies beinhaltet: die Verwaltung von Namensrumen und Zugrinfora a mationen, das Mapping von Dateien zu den Chunks sowie die Information uber die aktuelle Position der Chunks. Weiterhin koordiniert der Master-Server Systemaktivitten wie Chunk-Lease-Management, Garbage Collection und Chunka Migration zwischen den einzelnen Chunk-Servern. Der Master-Server kommuniziert in regelmigen Abstnden mit den Chunk-Servern uber HeartBeat-Massages a a um ihnen Instruktionen zu ubergeben und ihren Status abzufragen. Clients kom munizieren mit dem Master-Server und den Chunk-Servern um Daten fr eine u Anwendung lesen oder schreiben zu knnen. Dabei interagiert der Client mit dem o
14
Master, um Metadaten-Operationen auszufhren, der Datenuss hingegen luft u a direkt uber die Chunk-Server. Der Master-Server selbst ist nicht mit den Lese oder Schreibvorgngen mit den Clients beschftigt, er hlt lediglich die Position a a a der Chunk-Server fr die Clients bereit. Somit entsteht kein Engpass im System. u Daten werden in Chunks gespeichert. Jede Chunk-Datei ist auf einem ChunkServer mit einer festen Gre von 64MB gespeichert und kann bei Bedarf erweitert o werden. Die Wahl dieser Dateigre bietet mehrere Vorteile: o 1. Es reduziert die Notwendigkeit der Interaktion zwischen dem Client- und dem Master-Server, da nur wenige Informationen bezglich der Lage des Chunku Servers zur Verfgung gestellt werden mssen. u u 2. Clients fhren eher viele Operationen auf einem bestimmten Chunk aus. Dies u kann den Netzwerk-Overhead reduzieren durch das Halten einer persistenten TCP-Verbindung zum Chunk-Server uber einen lngeren Zeitraum. a 3. Es reduziert die Gre der Metadaten die auf dem Master gespeichert werden. o Dies erlaubt die Metadaten im Speicher zu halten. Im Speicher eines Masters werden drei Arten von Metadaten gehalten: 1. Datei- und Chunk-Namensrume a 2. Adressierung der Dateien auf die Chunks 3. Standorte jeder Chunk-Kopie Die ersten beiden Typen, die Datei- und Chunk-Namensrume sowie die a Adressierung der Dateien auf die Chunks, werden persistent gehalten, indem Vernderungen in einem Operation-Log protokoliert werden, welches auf einer a lokalen Festplatte des Masters gespeichert und zustzlich noch auf anderen Recha nern repliziert wird. Mit Hilfe eines Operation-Logs kann der Zustand des Masters einfach und zuverlssig aktualisiert werden, ohne Inkonsistenzen bei einem Aba sturz des Masters zu riskieren. Der Master speichert Informationen zu den Standorten der Chunk-Dateien nicht persistent ab. Stattdessen wird jeder Chunk-Server uber seine Chunk-Dateien bei dem Start des Masters und wenn ein Chunk-Server das Cluster betritt abgefragt. Fr jeden dieser 64 MB Chunks werden nur 64 u Byte fr die Adressierung bentigt, sodass Kapazittserweiterungen durch eine u o a Speichervergrerung des Masters realisierbar sind. Da die gesamten Metadao ten im Speicher stehen, sind sie nicht nur sehr schnell zugnglich, es ermglicht a o dem Master auch die Erstellung von Kopien, Chunk-Migration, Lastverteilung und Festplattenplatz im Hintergrund zu managen. Aufgrund dieses Designs sind die auf dem Master vorliegenden Daten nicht immer konsistent, da stndig Chunk-Server hinzukommen, sich abmelden, ihren Namen a
2.2 Design des GFS
15
a a ndern, neustarten oder ausfallen. Diese stndigen Anderungen werden durch regelmige Scans aktualisiert. Der Master kann whrend eines Scanprozesses uber a a eine HeartBeat-Massage den aktuellen Stand eines Chunk-Servers abfragen. Diese Verbindung umfasst nur sehr wenige Daten und ist in sehr kurzer Zeit abgeschlossen. Da diese HeartBeat-Massage nur sehr kurz aufgebaut wird, hat sie keinen groen Einuss auf die Performance des Servers. Der Zeitpunkt dieser Verbindung wird vom Master nach Kriterien der optimalen Lastverteilung gewhlt. Um a vernderte Metadaten zu protokollieren, werden ebenfalls Operation-Log-Files im a Speicher des Masters gehalten. Es werden darin die Versionsnummern von Dateien und Chunks gespeichert, weiterhin wird eine logische Zeitlinie festgelegt, welche fr die eindeutige Identikation der Chunks bentigt wird. Durch das Operationu o Log kann der Master das Chunk-Dateisystem sehr schnell wiederherstellen. Dieses Dateisystem wird hierbei in Form eines Binrbaumes abgelegt. Durch das Festlea gen von Checkpoints innerhalb dieses Binrbaumes kann der Server immer wieder a in einen konsistenten Zustand zurckgesetzt werden. Sobald ein neuer konsisu tenter Checkpoint ermittelt wurde, knnen vorher festgelegte Checkpoints sowie o zugehrige Logles gelscht werden. Die Schlssel der Knoten des Binrbaums o o u a werden durch eine Dateiadresse, auch Chunk-Handle genannt, mit einem Zeitstempel speziziert. Das Operation-Log ist die einzige persistente Speicherung der Metadaten. Ein Verlust wrde zu einem Verlust des ganzen Dateisystems u fhren. Es wird daher auf mehreren Rechnern gesichert. u
2.2.3
Konsistenzmodell
Das Konsistenzmodell bildet die Grundlage fr eine konsistente Datenspeicherung. u Dabei werden Namenskonventionen sowie die Reihenfolge von Datenoperationen festgelegt. Da die Dateinamensrume ausschlielich durch den Master verwala tet und die zeitliche Reihenfolge der Datenspeicherung durch das Operation-Log deniert werden, kann Atomaritt und Korrektheit garantiert werden. Wird eine a Datei verndert, so wird von einer Mutation gesprochen. Eine Datei ist konsistent, a wenn alle Clients nach einer Mutation auf allen Kopien dieselben Daten sehen. Mutationen werden auf allen Kopien in derselben Reihenfolge ausgefhrt und die u Versionsnummern protokolliert. Auch nach erfolgreichen Mutationen knnen Koo pien beschdigt sein, diese werden mit Hilfe von Checksummen identiziert. Wie a Datenverluste konkret vermieden werden, soll im nchsten Kapitel nher beleucha a tet werden.
16
2.3
2.3.1
Systeminteraktionen des GFS

Kontrollrechte und Mutationsreihenfolge
Jede Mutation verndert die Chunk-Daten und wird auf allen Chunk-Kopien a durchgefhrt. Leases (Kontrollrechte) werden hierbei benutzt, um eine konsisu tente Reihenfolge der Mutationen zu garantieren. Der Master whlt dabei eine a primre Kopie aus und gibt ihr das Chunk-Lease, das Recht der Wahl der Mua tationsreihenfolge, auf allen untergeordneten Chunk-Kopien. Die globale Mutationsreihenfolge ist somit durch die Lease-Rechte des Masters sowie durch die von der primren Kopie festgelegte Mutationsreihenfolge unter den anderen Kopien a deniert. Diese Vorgehensweise verringert den Verwaltungs-Overhead des Masters. Ein Lease hat typischerweise einen Timeout von 60 Sekunden, kann aber auf Anfrage der primren Kopie verlngert werden, falls eine Mutation lnger als der a a a Timeout dauert. Diese Anfragen an den Master werden an die Heartbeat- Massage gekoppelt. Falls das Lease abluft oder die Kommunikation mit der primren a a Chunk-Kopie verloren geht, kann der Master einfach einer anderen Kopie das Lease gewhren. a
2.3.2
Datenuss
Whrend der Kontrolluss vom Client uber den primren zu den sekundren a a a Chunk-Servern luft, werden die Daten durch Pipelining mit einer festgelegten a Reihenfolge zwischen den Chunk-Servern transferiert. Der Grund fr diese Voru gehensweise ist das Ziel der ezienten Nutzung der Bandbreite der jeweiligen Server sowie der Vermeidung von Engpssen. Durch die Linearitt des Datenusa a ses kann die Bandbreite besser als in anderen Topologien genutzt werden, da auf Splitting und somit Performanceverlust verzichtet wird. Werden die Daten auf den Chunk-Server transferiert, so ist er in diesem Zeitraum fr Clients nicht eru reichbar. Die zu schreibenden Daten werden somit in einer Operation geschrieben, und dadurch die Ausfallzeit des Chunk-Servers minimiert sowie die Erreichbarkeit und Performance des Gesamtsystems vergrert. Weiterhin werden Daten auf o den naheliegendsten Chunk-Server transferiert, wobei die Entfernung durch die IP Adressen ermittelt wird, um Engpsse im Netzwerk zu vermeiden. Der Transa fer uber TCP-Verbindungen ermglicht die Minimierung der Latenzzeit, da ein o Chunk-Server, kurz nachdem er Daten empfangen hat, diese sofort weiterleitet. Durch diese Struktur ist es mglich 1 MB in etwa 80 ms auf alle Chunk-Server o des Clusters zu verteilen.
2.3 Systeminteraktionen des GFS
17
2.3.3
Record Append-Operation
Bei einer Schreib-Operation, bei der mehrere Clients zeitgleich auf die gleiche Datei schreibend zugreifen, wird die Operation Record Append benutzt, um eine komplizierte Synchronisationen zu umgehen. Dabei wurden einige Koordinationsmechanismen auf dem primren Chunk-Server eingebaut. Der primre Chunka a Server checkt, ob die vom Client auszufhrende Schreiboperation die maximale u Gre eines Chunks von 64 MB uberschreitet. Ist dies der Fall, gibt der primre o a Chunk-Server den sekundren Chunk-Server den genauen Oset, an den die Daten a zu schreiben sind und gibt eine Erfolgsmeldung an den Client zurck. Falls dies u nicht der Fall ist, gibt der primre Chunk-Server die Anweisung an alle sekundren a a Chunk-Server, die Chunks aufzufllen. Falls die Schreiboperation auf einer Kou pie fehlschlgt, wird diese vom Client wiederholt, so dass auch Duplikate der a Daten auf den Chunk-Servern vorliegen. Das GFS garantiert nicht, dass alle Kopien bitweise ubereinstimmen, aber die Schreiboperation wurde mindestens einmal atomar auf allen Kopien ausgefhrt. Der wesentliche Vorteil der Record Appendu Operation, im Vergleich zu einer normalen Schreiboperation, besteht in dem geringeren Synchronisationsaufwand bei Clientzugrien. Whrend der Ausfhrung a u der Operation wird lediglich ein Oset am Ende der Datei verndert. Bei einer a normalen Schreibaktion werden alle Speicheradressen gesperrt, die grer sind als o die zu beschreibende Speicheradresse. Durch diese Vorgehensweise sind immer nur Teile der Datei fr Leseoperationen verfgbar. u u
2.3.4
Snapshot-Operation
Die Operation Snapshot ermglicht dem Master unverzglich eine Kopie des o u Dateisystems und des Verzeichnisbaums zu erstellen, ohne dass stattndende Mutationen gestrt werden. Wenn der Master einen Snapshot-Befehl erhlt, werden o a zuerst alle an die primren Kopien vergebenen Lease widerrufen, um sicherzustela len, dass Schreibbefehle von Clients eine Interaktion mit dem Master bentigen. o Nachdem das Lease widerrufen oder abgelaufen ist, kann das im Speicher bendliche Quellverzeichnissystem kopiert werden. Sobald ein Client nun diesen, durch den Snapshot betroenen, Chunk A anfordert, wird von dem Master ein neuer Chunk-Handle A erschaen. Nun fordert der Master die Chunk-Server auf, eine lokale Kopie des Chunks A anzulegen und diese A zu ubergeben. Da die Kopie auf demselben Chunk ausgefhrt wird, kann sie lokal, nicht uber das Netzwerk, u stattnden. Einer Kopie wird nun das Lease gewhrt und die Interaktion mit dem a Client kann fortgesetzt werden. Das Anlegen einer Kopie fr den Zweck eines u Rollbacks ist somit sehr ezient implementiert.
18
2.4
2.4.1
Masteroperationen
Management des Namensraumes
Viele Masteroperationen beanspruchen eine lange Zeit, wie die bereits beschriebene Snapshot Operation. Um die Performance des Masters durch diese Operationen nicht zu verringern, knnen multiple Operationen gleichzeitig aktiv sein. Um seo rielle Zugrie sicher zu stellen, werden mit Hilfe von Locks bestimmte Bereiche des Namensraums gesperrt. Die logische Reprsentation des GFS ist eine Looka Up-Table, in dem die Pfadnamen auf ihre Metadaten abgebildet werden, wobei diese Tabelle im Speicher gehalten wird. An jedem Knoten im Verzeichnisbaum kann ein eigener Lese-Schreib-Lock, also eine Sperre fr Lese- oder Schreibzuu grie gesetzt werden. Durch diesen Lock werden auch auf alle ubergeordneten Verzeichnisse Read-Locks gesetzt.
2.4.2
Verteilung, Erstellung und Reproduktion von Kopien
Die Hauptaufgaben der Verteilung von Kopien, sind die Maximierung der Datenerreichbarkeit und -zuverlssigkeit und die eziente Nutzung der Netzwerka bandbreite. Es reicht somit nicht aus, Kopien uber verschiedene Maschinen zu verteilen, es muss auch eine Verteilung uber verschiedene Racks erfolgen. Somit kann gesichert werden, dass Kopien bestehen bleiben, auch wenn ganze Racks ausfallen. Soll ein neuer Chunk erstellt werden, muss zunchst die Verteilung der Kopien a bestimmt werden. Die Auswahl erfolgt anhand folgender Kriterien: 1. Um eine gleichmige Speicherplatzausnutzung zu garantieren, werden Maa schinen mit unterdurchschnittlicher Speicherplatzauslastung favorisiert. 2. Da nach der Erzeugung eines Chunks gewhnlich groe Schreiboperationen o folgen, wird die Anzahl neuer Chunks auf einem Chunk-Server begrenzt. 3. Eine Verteilung auf multiplen Racks wird angestrebt. Der Master repliziert Kopien, sobald eine festgelegte Anzahl unterschritten wird. Dies knnte aus zwei Grnden geschehen: o u 1. Ein Chunk-Server ist nicht mehr erreichbar 2. Eine Kopie oder eine Festplatte ist beschdigt. a Jeder Chunk, der repliziert werden muss, wird auf Basis von bestimmten Faktoren priorisiert. Eine Entscheidungsgrundlage ist, wie weit die Chunkanzahl vom Limit
2.5 Fehlertoleranz, Zuverlssigkeit und Verfgbarkeit a u
19
der Anzahl der Kopien entfernt ist. Eine weitere Priorisierung erfhrt ein Chunk, a wenn er einen Clientprozess blockiert. Der Master ordnet dann die Kopie des Chunks an, wobei die Verteilung der Kopie auf Basis der bereits beschriebenen Faktoren erfolgt. Um die Netzwerkbelastung zu minimieren, werden die Zahl der Kopieprozesse und die verwendete Bandbreite eingeschrnkt. a
2.4.3
Garbage Collecion
Wird eine Datei von einem Client gelscht, erfolgt das Lschen des genutzten o o Speicherplatzes nicht sofort. Es wird lediglich ein Eintrag im Logle des Masters vorgenommen. Die Ressourcen werden im GFS in einen versteckten Dateinamen umbenannt, um weitere Clientzugrie zu verhindern. Whrend der regelmigen a a - vom Master durchgefhrten - Scans werden versteckte Dateien, die lter als u a drei Tage sind, aufgesprt und permanent gelscht. Innerhalb dieser drei Tage u o kann die betreende Datei ohne Probleme auf allen Chunks wiederhergestellt werden. Whrend der Scans des Namensraums knnen weiterhin verwaiste Chunks, a o Chunks ohne Referenz, identiziert und entfernt werden. Durch die bereits beschriebene HeartBeat-Massage knnen alle Chunks erkannt werden, die nicht o lnger in der Datei-Metadaten-Verknpfung des Masters vorhanden sind. Diea u se Chunks knnen nun selbstndig durch den jeweiligen Chunk-Server gelscht o a o werden. Zur Identikation von veralteten Kopien werden die Versionsnummern herangezogen und mit der aktuellen Nummer verglichen. Diese veralteten Kopien knnen ebenfalls gelscht werden, da gehaltene Daten nicht mehr relevant sind. o o Die Aktualitt einer Kopie kann bei einer Anfrage eines Clients durch die Versia onsnummer garantiert werden. Diese Mechanismen der Garbage Collection sind in einem stark verteilten System, mit einer hohen Ausfallwahrscheinlichkeit von Komponenten, besonders wichtig.
2.5
Fehlertoleranz, Zuverlssigkeit und a Verfgbarkeit u
Eine der grten Herausforderungen an das GFS stellen die regelmigen Ausflle o a a von Komponenten dar. Fehler in Komponenten knnen sowohl unerreichbare Syso teme als auch fehlerhafte Daten nach sich ziehen. In einem GFS Cluster mit mehreren hunderten Rechnern sind Ausflle die Regel und nicht die Ausnahme. Um a dennoch eine hohe Verfgbarkeit sicher zu stellen, stehen die Strategien werden u die schnelle Wiederherstellung sowie die schnelle Kopieerstellung im Mittelpunkt. Master und Chunk-Server sind in der Lage, sich innerhalb von Sekunden neu zu starten und ihren Status wiederherzustellen, wobei diese schnelle Wiederherstel-
20
lung unabhngig von der Terminierung der Server ist. Auch wenn ein Timeout a uberschritten wurde, und der Chunk-Server eine neue Verbindung zum Master aufbauen muss, geschieht dies innerhalb von Sekunden. Die Anzahl der Kopien kann festlegen werden, wobei im Regelfall von 3 Kopien ausgegangen wird. Die Kopieerstellung eines Masters ist fr die Verfgbarkeit des u u Systems entscheidend. Das Operation-Log und die Checkpoints werden auf verschieden Maschinen repliziert. Aus Grnden der Vereinfachung ist nur ein Masteru prozess fr alle Mutationen sowie Hintergrundoperationen verantwortlich. Wenn u dieser Prozess abbricht, wird sofort ein Masterprozess auf einer Kopie gestartet mit dem vorher replizierten Operation-Log. Clients benutzen bei der Interaktion mit dem Master stets einen DNS Alias, welcher gendert werden kann, falls der a Master ausfllt. Um das Lesen von Dateien zu erleichtern, die nur unregelmige a a Mutationen erfahren, wurden so genannte Shadow-Master bereitgestellt, welche nur einen Lesezugri bereitstellen. Weiterhin sind diese Master um Bruchteile einer Sekunde langsamer als der primre Master und knnen unter Umstnden a o a veraltete Resultate liefern. Ein Shadow-Master erhlt Informationen bezglich a u Chunkkopien und Mutationsreihenfolge vom primren Master und speichert so a Namensrume, wenn auch zeitlich versptet, identisch ab. a a Jeder Chunk-Server benutzt das bereits erklrte Checksumming, um fehlerhafte a Daten zu identizieren. Aufgrund der Operation Record Append sind Kopien auf verschieden Chunk-Servern nicht unbedingt identisch. Aus diesem Grund muss jeder Chunk-Server seine eigene Integritt mittels Checksumming uberprfen. Jeder a u 64 KB Block eines Chunks wird durch eine 32 bit Checksumme deniert. Bei einer Leseanfrage eines Clients werden zunchst die Blcke uberprft, die uber die Lea o u sestrecke des Chunk-Servers hinausgehen. Durch dieses Vorgehen wird verhindert, dass fehlerhafte Checksummen zu spt aufgedeckt und fehlerhafte Daten bereits a gesendet werden. Kommt es nicht zu einer Ubereinstimmung der Checksummen, wird ein Fehler an den Client zurckgegeben und ebenfalls dem Master berichtet. u Der Master veranlasst, wie bereits beschrieben, dass eine korrekte Kopie dupliziert wird.
2.6
Zusammenfassung
Diese Arbeit gibt einen Einblick in die komplexen Fragestellungen und Anforderungen an das GFS. Aufgrund der Analyse lsst sich sagen, dass trotz einer a fast unbegrenzten Skalierbarkeit des Systems, der wachsende Datenindex und die Anzahl an Zugrien auch zuknftig organisiert werden knnen. Selbst mit u o dem Einsatz von handelsblicher Hardware werden Dezite wie Unzuverlssigkeit u a und Nichtverfgbarkeit durch geschickte Datenhaltung ausgeglichen. Durch eine u
21
stndige Uberwachung, Replikation wichtiger Daten und eine schnelle sowie aua tomatische Wiederherstellung ist das GFS sehr fehlertolerant. Auch im Hinblick auf den Gesamtdurchsatz an gleichzeitigen Lese- und Schreibvorgngen, wurden a innerhalb des GFS Mechanismen entwickelt, welche die Daten persistent sowie konsistent halten. Die stetig wachsende Datenmenge im Internet erschwert die Suche zunehmend. Neue Konzepte der Informationsverarbeitung und -strukturierung werden immer wichtiger. Diese Arbeit zeigt auf, dass das Google File System eine stabile Datenhaltung bietet die dieser Aufgabe gerecht werden kann.
[1] Ghemawat S., Gobio H., Leung S.-T., The Google File System, http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf, 2003, 2003
[2]
Leyh M., Das Google File System, http://www.wi.unimuenster.de/pi/lehre/ss05/seminarSuchen/Ausarbeitungen/MichaelLe 2005 LivingLogic AG, Suchmaschinen-Optimierung fr Google ohne u Tricks, http://www.livinglogic.de/xist4c/web/SuchmaschinenOptimierung id 247 .htm Moritz M., Verteilte Dateisysteme in der Cloud, http://dbs.unileipzig.de/le/seminar 0910 maria moritz ausarbeitung.pdf, 2010 Schmidt J., Verteilte Dateisysteme, http://www.minet.unijena.de/dbis/lehre/ss2010/saas/material/Ausarbeitung05Schmidt.pdf
[3]
[4]
[5]
22
Verteilte teme
Multimediasys-
Philipp Richardt
Inhaltsverzeichnis
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Allgemeines . . . . . . . . . . . . . . . . . . 3.1.2 Verteilte Systeme . . . . . . . . . . . . . . . 3.1.3 QoS (Dienstgte) . . . . . . . . . . . . . . . u 3.1.4 Best-Eort . . . . . . . . . . . . . . . . . . . Verteilte Multimediasysteme . . . . . . . . . . . . . . 3.2.1 Streaming Video und Audio . . . . . . . . . . 3.2.2 Interaktives Video und Audio in Echtzeit . . . 3.2.3 Zuknftige Weiterentwicklungen im Internet u Ubertragung Multimedialer Anwendungen . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . zur . . . . 23 23 24 25 26 26 27 30 30 33
3.2
3.3
3.1
3.1.1
Einleitung
Allgemeines
In unserem heutigen Zeitalter ist von immer schneller wachsender Vernetzung die Rede. Dabei werden sowohl einzelne Rechner als auch ganze Unternehmensbereiche vernetzt. Moderne Kommunikationsmechanismen erlauben es verschiedene multimediale Inhalte beispielsweise Bilder, Filme und Audiodateien uber ein Rech nernetz zu verbreiten. Daraus bilden sich immer mehr multimediale Anwendungen wie zum Beispiel verteilte Informationsdienste, Videokonferenzsysteme aber auch Systeme, die ein Kooperatives Arbeiten erlauben. Client-Server Interaktionen, die nach dem Anfrage-Antwort Prinzip agieren treten ebenso, wie kontinuierlichen Datenstrme auf. Beispiele dafr stellen Abrufdienso u te, wie z.B. Zugrie auf multimediale Inhalte aus Datenbanken genauso wie Kooperatives Arbeiten unter verschiedenen Benutzern, die in einem verteilten Work-
24
3 Verteilte Multimediasysteme
ow Managementsystem sich untereinander austauschen. Dabei werden nicht selten asymetrische Strukturen nachgewiesen, welche durch eine Anfrage geringe Datenmengen an den Server senden. Im Zuge dessen kann es unter Umstnden a zu groen Datenmengen von Seiten des Servers in Richtung Client kommen. Als eigentliches Grundlage dieser Art der Kommunikation ist der Remote Procedur Call zu nennen. Bei der Rechnerkommunikation spielt dieser Mechanismus eine immer grere Rolle. Mit der Entstehung des Internets wurde ein weltweites o Rechnernetz erschaen, welches die unterschiedlichsten Technologien verbindet und den angeschlossenen Rechnern die Basis dieser Interaktionen bietet. Technologien sind sowohl unterschiedliche Medienzugrisverfahren wie Token Ring, Token Bus, ATM oder auch CSMA/CD, darauf aufgesetzte transportorientierte Protokolle, sowie physikalische Medien wie Lichtwellenleiter, Kupfer- und Glas faserkabel. Ein Flaschenhals entsteht, meist bei der Ubertragung multimedialer Inhalte uber verschiedenartige Netze, hug an den Netzbergngen. Die Nacha u a richten mssen so oft umkodiert werden, damit uberhaupt eine Weiterleitung in u ein anderes Netz ermglicht werden kann. o Meist kennen die Anwendungen, welche uber solche Netzwerke eingesetzt werden, die zugrunde liegenden Parameter des verwendeten Netzwerkes nicht genau. Bei spiele solcher Parameter sind Schwankungsbreite oder die Ubertragungsrate des zugrunde liegenden Netzwerkes. Dabei werden von vielen Anwendungen konstan te Ubertragungsraten vorausgesetzt. Dies trit in den meisten aller Flle jedoch a nicht zu. Sind der Anwendung genaue Angaben uber den zu ubertragenden Datenstrom vorhanden, wird dieser jedoch zumeist nur auf die Anwendungsebene bezogen. Bei Video ist es beispielsweise die Eigenschaft der Bildrate, der Abtastrate oder der Bildqualitt. Da das vorliegende Medium nicht bekannt ist, innerhalb der Ana wendung, entstehen folglich Schwierigkeiten bei der Ubergabe dieser Daten an ein Netzwerk. Dies gilt besonders in der Transportschicht und der des entsprechenden Netzwerkprotokolls.
3.1.2
Verteilte Systeme
Als verteiltes System bezeichnet man einen Verbund von mehreren unabhngigen a Systemen, welche durch den Zusammenschluss uber ein Netzwerk und einer oft integrierten Softwareschicht dem Benutzer als ein einzeln arbeitendes System erscheinen. Es existiert keine allgemeingltige Denition fr verteilte Systeme. Jeu u doch kann man die folgende als Charakterisierung der Begriichkeit verwenden. Ein verteiltes System ist eine Menge voneinander unabhngiger Computer, die a dem Benutzer wie ein einzelnes, kohrentes System erscheinen. [1] a Im folgenden sind die Ziele aufgefhrt, welche ein verteiltes System verfolgt: u
3.1 Einleitung
25
Benutzer und Ressoucen verbinden: Hierbeit geht es darum Benutzer und Ressourcen so einfach und so ezient wie mglich miteinander zu verbinden. Dem Benutzer wird dadurch durch eine o kontrollierte Art und Weise der Zugang und die gemeinsame Nutzung einer entfernten Ressource mit anderen Benutzern ermglicht. o Transparenz: Die Transparent spiegelt die Fhigkeit des verteilten Systems wieder, sich dem a Benutzer oder einer Applikation so darzustellen, als ob es aus lediglich einem System besteht und dennoch alle anderen Ressourcen die es nutzt so ezient wie nur mglich einsetzt. o Oenheit: Dienste in verteilten Systemen sollen bestimmten Standardregeln entsprechend angeboten werden, welche auch den Semantik und Syntax dieser Dienste beschreibt. Skalierbarkeit: Die Skalierbarkeit eines Systems spiegelt die Erweiterbarkeit und die somit verbundene Vergrerung dar. Dabei sollte das Hinzufgen von neuen Beo u nutzern und Ressourcen in das gesamte System ohne jegliche administrativen Aufwand erfolgen.
3.1.3
QoS (Dienstgte) u
Quality of Service oder auch Dienstgte stellt die zur Verfgung stehenden Eigenu u schaften einer Dienstleistung dar. Alle Verfahren, die dafr verwandt werden um u einen Dienst mit bestimmter Qualitt beim Empfnger ankommen zu lassen um a a somit die Anforderungen des Kunden bzw. Empfngers zu gewhrleisten. Folgende a a Parameter werden in IP-Netzen an unterschiedliche Anwendungen gestellt: Jitter: Der Jitter steht fr die Schwankung bei der Ubertragung von Digitalsignau len. Dabei ist dieser Eekt unerwnscht und fhrt bei der Ubertragung von u u multimedialen Inhalten zu unerwnschten Nebeneekten. Ein zu frhes oder u u zu sptes Eintreen des Signals ist beispielsweise bei Internet-Telefonie sehr a strend. Man spricht auch von einer Abweichung der Laufzeit von Datenpao keten. Latenzzeit: Die Latenzzeit oder auch Verzgerungszeit spaltet sich in zwei unterschiedliche o Eekte. Zum einen in die gewnschte Verzgerungszeit , dem sogenannten u o
26
Delay, und in die unerwnschte Laufzeitverzgerung. u o Paketverlustrate: Die Paketverlustrate gibt einen prozentualen Wert der verloren gegangenen Pakete wieder. Dieser Prozentsatz spiegelt bei einem Datenstrom die Rate wieder, wie viele IP-Pakete bei der Ubertragung von einem Sender zu einem Empfnger nicht angekommen sind. Es wird dabei davon ausgegangen, dass a bei der IP-Telefonie Raten bis zu 5 Prozent Verlust noch in akzeptabler Qualitt bei Empfnger ankommen. Der Idealfall ist eine Paketverlustrate von 0. a a Datendurchsatz: Der Datendurchsatz stellt die Gre da, welche im Mittel bei einer o Ubertragung pro Zeiteinheit erreicht wird. Sie spiegelt anders als die Datenbertragungsrate den reinen Durchsatz dar. u [2]
3.1.4
Best-Eort
Der heute im Internet durch das IP-Protokoll erbrachte Best-Eort-Dienst gewhrleistet das Weiterleiten eintreender Pakete, solange das Netz noch a freie Ubertragungskapazitten bietet. Es werden dabei keine Garantien fr a u die vollstndige und fehlerfreie Ubertragung gemacht. Kommt es zu einem a Stau, nachdem ein Pfad bei der Ubermittlung uberlastet ist, so bleibt dem ubergeordneten Protokoll beispielsweise TCP bzw. dem Benutzer es uberlassen die Ubertragung und damit auch die Kommunikation wieder herzustellen. [3]
3.2
Verteilte Multimediasysteme
In den voran gegangenen Abschnitten wurden die grundlegenden Begriichkeiten nher erlutert. Multimedia-Anwendungen stellen im heutigen Internet hohe a a Dienstanforderungen im Gegensatz zu traditionellen und elastischen Anwendungen. Hierbei sind E-Mail, World Wide Web, Remote Login, Filesharing oder auch das herunterladen von Dateien als elastische Vertreter zu nennen. Bei ihnen spielt es keine Rolle wie hoch die End-zu-End Verzgerung ist bzw. ist es kaum von o nten, dass die Daten ich annhernder Echtzeit beim Empfnger ankommen. Auf o a a der anderen Seite knnen traditionelle und elastische Anwendungen anders als o Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Verteilte Multimediasysteme In den voran gegangenen Abschnitten wurden die grundlegenden Begriichkeiten nher erlutert. Verteilte Multimedia-Anwendungen stellen a a im heutigen Internet hohe Dienstanforderungen im Gegensatz zu traditionellen
3.2 Verteilte Multimediasysteme
27
und elastischen Anwendungen. Hierbei sind E-Mail, World Wide Web, Remote Login, Filesharing oder auch das herunterladen von Dateien als elastische Vertreter zu nennen. Bei ihnen spielt es keine Rolle wie hoch die End-zu-End Verzgerung ist o bzw. ist es kaum von belangen, dass die Daten nicht annhernder in Echtzeit beim a Empfnger ankommen. Auf der anderen Seite knnen traditionelle und elastische a o Anwendungen anders als Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Somit stellen Multimedia-Anwendungen in ihren verschiedensten Ausprgungen unterschiedlichste Netz- und Qualittsanforderungen. In den fola a genden Abschnitten soll dabei zunchst anhand von zwei unterschiedlichen Klasa sen die Anwendung von verteilten Multimediasystemen erlutert werden. Hierbei a geht es zum einen um die Klasse des Streaming von Live-Video und -Audio, welche mit einem konkreten Beispiel belegt werden sollen und zum anderen die Klasse der interaktiven Video und Audio Echtzeitanwendungen.
3.2.1
Streaming Video und Audio
Ahnlich wie bei traditionellen Fernseh- oder Radiosendungen ndet das Streaming von Live-Video und Audio ausschlielich im Internet statt. Somit werden weltwei te Ubertragungen von Sendungen an mehrere Millionen Zuschauen und Zuhrer o mglich. Da sich das Senden der Inhalte uber das Internet abspielt sind diese o Multimedia-Anwendungen auch unter IPTV oder Internetradio bekannt. Aufgrund der Tatsache, dass die empfangenen Inhalte nicht vorher aufgezeichnet wurden und somit Live ubermittelt werden mssen kann der Client keine vorluge Speiu a cherung der Inhalte durchfhren. u Beispiel: IPTV Fernsehinhalte werden heutzutage nicht mehr nur noch traditionell uber Satelliten oder Glasfaser-/ Koaxialkabel, sondern besteht sehr groes Interesse dem Endverbraucher das Fernsehen uber das Internet zu senden. Hierbei werden jedoch extrem groe Bandbreiten vorausgesetzt. Diese hohe Bandbreite ist vor allem serverseitig von Nten. Wir gehen davon aus, dass ein sportliches Groereignis o wie die Fuball Weltmeisterschaft 2014 uber das Internet ubertragen werden soll. Nehmen wir nun noch an,dass mittels eines Servers an 500 Millionen Zuschauer gesendet werden soll. Bei einer Videorate von sehr geringen 1Mbps wrde eiu ne Serverbandbreite von 500 Terabit/Sekunde bentigt werden. Eine klassische o Server-Client-Verteilung ist somit aufgrund der bentigten Serverbandbreite vllig o o unzureichend. Eine angebrachte Verteilung knnte man durch IP-Multicast erreio chen. Ebenfalls besteht die Alternative ein Multicast-Overlay-Netzwerk zu bilden und darber die Inhalte zu verteilen. Solche Mglichkeiten werden durch Content u o Distribution Networks bereits zur Verfgung gestellt. Weitere Mglichkeiten der u o Verbreitung wre die Verteilung uber Peer to Peer. Hierbei wrde jeder Peer auch a u
28
gleichzeitig dazu beitragen die Empfangenen Pakete weiter an andere Peers zu geben. Wrden alle Peers entsprechend viel Upload- Bandbreite liefern wrde der u u Server eine weitaus geringere Bandbreite bentigen. o Eine weitere Streaming Methode ist das Streamen von bereits aufgenommenen Inhalten, welche auf einem Server bereit liegen.ANders als bei der vorher beschriebenen vorgehensweise fordert hier der Client fordern komprimierte Audio und Videodateien von einem Server an. Dem Benutzer steht durch die vorhergehende Speicherung der Inhalte auf dem lokalen Rechner die Mglichkeit oen im o Film zu spulen, anzuhalten oder weiterzuspringen. Bei den Servern, welche die Video/Audio Inhalte zur Verfgung stellen kann es sich zum einen um einfach u Webserver handeln und zum anderen um einen Streamingserver. Streaming uber einen Webserver 1. Der Benutzer besucht eine Webseite mit einem entsprechenden Hyperlink auf die Videodatei. Die enthaltene Header-Zeile in der HTTP-Response-Nachricht enthlt die verwendete Video-/Audio-Codierung. a 2. Der Browser des Clients untersucht die Header-Zeile der Response-Nachricht und startet den zugehrigen Medienplayer und ubermittelt den Datenbereich o der Response-Nachricht an diesen. 3. Durch Kontaktierung des Medienplayers und dem HTTP-Server direkt uber eine TCP-Verbindung wird die Audio-/Videodatei an den Medienplayer ubertragen.
Abbildung 3.1: Streaming uber einen Webserver [4]
29
Streaming uber einen Streamingserver Das Streamen uber einen Streamingserver teilt sich auf in drei unterschiedliche Methoden. Mit einer konstanten Rate wird die Audio-/Videodatei uber UDP ver sandt. Diese entspricht genau der Abspielrate beim Empfnger. Treen die kompria mierten Daten aus dem Netz beim Empfnger ein, werden sie dort dekomprimiert a und abgespielt. Eine zweite Methode beschreibt wie bei der ersten Vorgehensweise die Ubertragung mittels UDP. Ahnlich wie bei der ersten Streamingmethode wird hierbei eine Verzgerung im Medien Player hervorgerufen. Dieser verzgert die o o Ausgabe des Videos um wenige Sekunden. Dies dient zur Entfernung von netzwerkbedingten Jitter. Die komprimierten Daten werden in einem sogenannten Client-Puer abgelegt und nach Ansammlung einiger Sekunden im Voraus von dort abgespielt. Die dritte Methode ubertrgt die Inhalte vom Server mittels TCP. Die Media endateien werden hierbei vom Server so schnell es geht auf dem TCP-Socket abgelegt. Der Medien Player liest den TCP-Socket aus. Die komprimierten Daten werden im Medienpuer gespeichert. Erneut nach einer Anfangsverzgerung o gibt der Medienplayer den Puer wieder aus und leitet die komprimierten Daten zur Wiedergabe und Dekompression weiter. Da die hier angewandte Methode TCP, verworfene Pakete nochmals ubertrgt wird somit ein besserer Ton und ein a besseres Bild erzielt.
Abbildung 3.2: Streaming uber einen Streamingserver [5]
30
3.2.2
Interaktives Video und Audio in Echtzeit
In dieser Klasse der Multimedia-Anwendungen wird es dem Anwender ermglicht o mit anderen Anwendern weltweit in Echtzeit zu kommunizieren. Dabei erfolgt wie im vorhergehenden Beispiel schon beschrieben die Kommunikation unter den Endanwendern uber das Internet. Diese Anwendungen werden meist auch Internette lefonie genannt. Ahnlich wie bei traditionellen leitungsvermittelnden Fernsprechdiensten ist es dadurch dem Anwender gestattet weltweit mit anderen Anwendern in Kontakt zu treten. Sowohl das Audio, als auch das Videosignal wird dabei durch das IP-Netz ubertragen. Neue Dienste die sich dadurch ermglichen sind Grupo penkommunikationen, Anrulterung, Erkennung ob Anwender anwesend sind und die damit verbundene Integration von webbasierten Anrufen. Bekannte Beispiele fr die voran gegangenen Dienste sind: Skype oder Microsoft NetMeeting u Bei beiden Conferencing-Tools wird es dem Benutzer ermglicht mit andeo ren Benutzern audiovisuell in Kontakt zu treten. Hierbei sollte idealerweise die Verzgerung zwischen Bild und Ton des Senders und Empfngers nicht hher sein o a o als 150ms. Sobald es hhere Abweichungen bei der Verzgerung gibt kann dies zu o o indiskutablen Gesprchsstrungen oder zu asynchronen Bild/Ton Ubertragungen a o fhren. Somit stellen diese Anwendungen ein hohe Anforderung an Paket-Jitter u und Paketverzgerung. Der Paket-Jitter beschreibt dabei eine Vernderung eio a ner Paketverzgerung im selben Strom von Paketen. Solange der Echtzeitano wendung gengend Bandbreite zur Verfgung steht ist eine gute Ubertragung u u von Video und Audio gewhrleistet, da dadurch die Verzgerung und der Jitter a o niedrig gehalten werden kann. Sobald jedoch der Paket-Strom auf einen ausgelasteten Pfad trit kann sich die Qualitt extrem verschlechtern. Da das heutige a Internet keine Klassizierung bzw. eine Priorisierung von Paketen in erster und zweiter Klasse zulsst, ist die Weiterentwicklung von Multimedia-Anwendungen a schwierig. Die Paketverarbeitung erfolgt somit ohne jegliche Gewichtung fr u verzgerungsempndliche Anwendungen. Alle Pakete werden somit gleich behano delt und auch gleich abgearbeitet. Somit muss man zunchst mit diesem Besta Eort-Dienst auskommen.
3.2.3
Zuknftige Weiterentwicklungen im Internet zur u Ubertragung Multimedialer Anwendungen
Bereits in der Einfhrung wurde auf die Bedeutung von Dienstgte in IPu u Netzwerken eingegangen. Diese spielt auch in der Weiterentwicklung des Inter nets und besonders bei der Ubertragung multimedialer-Anwendungen eine sehr groe Rolle. Es gibt eine Reihe von Forschern, welche es fordern grundlegen de Anderungen am Internet vorzunehmen. Diese Anderungen zielen dahin, dass zuknftig Anwendungen End-zu-End Bandbreite reservieren knnen. Dadurch u o
31
wird eine garantierte Leistung zwischen beiden Endpunkten sichergestellt. Eine Unterscheidung in feste und weiche Garantie bietet der Anwendung eine sichere bzw. hohe Wahrscheinlichkeit das die angeforderte Dienstgte eingehalten wird. u Es soll nach Meinungen dieser Forschergruppe mglich sein, dass beispielsweise o bei einem Anruf zwischen zwei Hosts, eine Reservierung vorgenommen werden kann, die den Hosts Bandbreite zusichert egal auf welchem Pfad entlang der Route sich bewegt wird. Um dies jedoch in die Tat umzusetzen und diese Ga rantierte Dienstgte zu gewhrleisten bedarf es groen Anderungen. Folgende u a Anderungen msste dabei bercksichtigt werden. Zum einen wrde man ein Prou u u tokoll bentigen das in der Lage ist die Bandbreite auf dem Pfad zwischen Sender o und Empfnger zu reservieren.Darber hinaus msste man eine Priorisierung der a u u zu behandelnden Pakete einfhren. Somit wrden Pakete, welche sich in der Rouu u tingwarteschlage benden und eine hohe Prioritt aufweisen zuerst abgearbeitet a und andere mit niedrigerer spter. Die Pakete die mehr reserviert haben werden a folglich schneller abgearbeitet. Die Anwendungen mssen dafr dass ihre Reservieu u rungen bercksichtigt werden dem Netz eine Ubersicht uber ihren Verkehr geben. u Welchen sie beabsichtigen ins Netzwerk zu senden. Das Netz wiederum ist dann verpichtet den Verkehr jeder Anwendung zu uberwachen. Damit wird sicherge stellt, dass die getroenen Abmachungen mit Anwendung und Netz eingehalten werden. Eine weitere Methode die noch angefhrt werden muss ist ein Mechau nismus mit der das Netzwerk entscheiden kann ob genug Bandbreite vorhanden ist um die neue Reservierungen vorzunehmen. Um diese neuen Mechanismen zu realisieren bentigt es neuer und komplexer Software, die sowohl auf den Hosts, o als auch auf den Routern sowie den Diensten installiert werden muss. Eine andere Gruppe von Forschern argumentiert, dass es ohne grundlegende Anderungen am Best-Eort-Dienst und vorhandener Internetprotokolle keiner notwendigen Vernderung bedarf. Sie sind somit Befrworter des sogenannten a u Laissez-faiere-Ansatzes. Dieser besagt folgendes: Sobald der Bedarf steigt sollen in diesem Fall auch die Internet Service Provider ihre Netzwerke so anpassen, dass der Bedarf wieder erfllt werden kann. Somit mssen die ISPs lediglich ihre u u Bandbreite und die Switching-Kapazitt so angleichen, dass die bentigte Leisa o tung hinsichtlich der Verzgerung und des Paketverlust im Rahmen bleibt. Durch o den gettigten Angleich der Leistung durch die ISps werden folglich die Kunden a zufrieden gestellt und somit laut Aussage der Befrworter dieses Ansatzes auch u mehr Kunden zum ISP kommen. Folglich ist eine Steigerung der Einnahmen fr u den ISP gewhrleistet. Um auch wirklich zu gewhrleisten, dass Multimedia- Ana a wendungen auch zu Hchstlastzeiten in guter Qualitt im ausreichenden Mae o a zur Verfgung stehen, sollte der ISP deutlich mehr Bandbreite und Switchingu Kapazitt bereithalten als aktuell bentigt. Dieses Overprovisioning bietet dem a o Kunden die Mglichkeit weiche Dienstgte-Garantien uber den Verkehr zu geben. o u
32
Durch Content Distribution Networks werden Inhalte durch Kopien an unterschiedlichen Standorten (am Rand des Internets) gespeichert. Kopien werden angefertigt und auf weiteren CDN-Knoten verteilt. Somit knnen durch CDNs o Datenaufkommen im inneren des Internets verringert werden. Somit ist auch bei CDN oft eine schnellere Lieferung der Inhalte an den Endanwender mglich. Die o Nachfolgende Abbildung zeigt eine Verteilung von Inhalten zunchst auf einen a Server, der wiederum die Inhalte verteilt auf die CDN Knoten-Server. Von diesen knnen die meist multimedialen Inhalte durch den Anwender abgerufen werden. o
Live-Streaming-Verkehr wie im voran gegangenen Kapitel anhand von IPTV erlutert muss an mehrere hundert Millionen Menschen (Beispiel WM 2014) a uber das Internet live ubertragen werden. Die Live-Ubertragungen knnen mittels o Multicast-Overlay-Netzwerken realisiert werden. In diesen Netzwerken bestehen die Verteilerknoten aus Hosts und dedizierten Servern. Diese werden uber das ge samte Internet verstreut. Server,Hosts und logische Links dazwischen bilden dann das Overlay-Netzwerk, in welchem der Datenverkehr mittels Multicast von Quelle zu den Benutzern ubertragen wird. Dieses wird nicht wie bei IP-Multicast von Routern auf der IP-Schicht durchgefhrt, sondern auf der Anwendungsschicht. u Es knnte so durch kontinuierliche Weitergabe des Stroms an Overlay-Server und o Hosts ein Verteilungsbaum entstehen. Somit kann die gesamte Verkehrslast im Internet aufgeteilt werden. Eine dritte Forschergruppe untersttzen die Ansichten der geringen Vernderung u a an Netzwerk- und Transportschicht. Sie wollen lediglich einfache Uberwachungsund Preisschemata am Rand des Netzwerkes einfhren. Diese sollen an der u Schnittstelle zwischen Benutzer und ISP installiert werden. Der sogenannte DiServ Ansatz beschreibt somit einen Service bei dem im Grundgedanke einige wenige Verkehrsklassen eingefhrt werden, welche in Routingwarteschlangen unu
Abbildung 3.3: Ursprungsserver ubertrgt Inhalte an CDN Verteilerknoten [6] a
3.3 Zusammenfassung
33
terschiedlich behandelt werden sollen. Somit knnen Benutzer durch verschiedene o Preismodelle ihren Internetzugang an die Pakete mit den verschiedenen Klassen anpassen. Somit werden Pakete vom ISP angeboten, die ein schnelleres Routing gewhrleisten und somit preislich teurer sind. a In den voran gegangen Methoden und Anstzen wurden unterschiedlichste Hera angehensweisen und teilweise auch Lsungen dargestellt, um mit dem immer weio ter wachsenden Datenaufkommen und den wachsenden Anforderungen an neue multimedialen Anwendungen fertig zu werden. Das IP-Netzwerkprotokoll des Internets bietet somit einen Best-Eort-Dienst, der sein bestes tut um jedes noch so unterschiedliche Datagramm schnellstmglich zum Ziel zu ubertragen. o
3.3
Zusammenfassung
In den voran gegangenen Kapiteln haben wir zum einen durch eine Einfhrung u und durch Begriserklrungen einen Einblick in das Thema der verteilten Mula timediasysteme bekommen. In weiteren Abschnitten wurde das Thema anhand von technisch eingesetzten Beispielen im Internet weiter Ausgefhrt. Zum Schluss u wurden einige Anstze und Methoden dargestellt, welche zur Verbesserung des aka tuellen Best-Eort-Internets beitragen sollen und auch zuknftig die Verbreitung u Multimedialer-Anwendungen uber verteilte Systeme steuern knnen und sollen. o Dabei spielt zuknftig die Dienstgte, welche von einer Anwendung gefordert ist u u und dessen Erfllungsgrad eine wichtige Rolle um das immer hher werdenden u o Datenaufkommen und die wachsende Zahl der Benutzer des Internets steuern zu knnen. o
34
[1] Andrew S. Tanenbaum, Maarten van Steen: Verteilte Systeme: Prinzipien und Paradigmen. Pearson Studium; Auage: 2., aktualisierte Auage., November 2007. [2] Wikipedia, Quality of Service. Quality_of_Service,12.01.2012 http://de.wikipedia.org/wiki/
[3] Wikipedia, Best-Eort. http://de.wikipedia.org/wiki/Best_Effort, 14.01.2012 [4] James F Kurose, Keith W. Ross:Computernetzwerke: Der Top-DownAnsatz.S. 644 Pearson Studium; Auage: 4., aktualisierte Auage., September 2008. [5] James F Kurose, Keith W. Ross:Computernetzwerke: Der Top-DownAnsatz. S. 642 Pearson Studium; Auage: 4., aktualisierte Auage., September 2008. [6] Cslongwang, Content Distribution Network - Grak http://www. cslongwang.com/Images/Cdn_Product.gif, 16.01.2012
OpenCL
Roger Jger a
Inhaltsverzeichnis
4.1 4.2 4.3 4.4 Einfhrung zum Thema - Taktfrequenzen stagnieren u OpenCL - Hintergrund . . . . . . . . . . . . . . . . Voraussetzungen fr OpenCL . . . . . . . . . . . . . u OpenCL - Aufbau/Architektur . . . . . . . . . . . . 4.4.1 Host . . . . . . . . . . . . . . . . . . . . . 4.4.2 Compute Devices/Units . . . . . . . . . . . 4.4.3 Kernel . . . . . . . . . . . . . . . . . . . . 4.4.4 Program . . . . . . . . . . . . . . . . . . . 4.4.5 Command Queue . . . . . . . . . . . . . . 4.4.6 Program Object . . . . . . . . . . . . . . . 4.4.7 Context . . . . . . . . . . . . . . . . . . . . 4.4.8 Memory Object . . . . . . . . . . . . . . . OpenCL C und Besonderheiten . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 37 38 39 40 40 40 41 41 41 41 42 43 44
4.5 4.6
4.1
Einfhrung zum Thema - Taktfrequenzen u stagnieren
Mit der rasanten Entwicklung der Computertechnologie wuchsen schnell die Aufgaben und somit auch die Anforderungen an die Systeme. Lange Zeit galt die Taktrate, nicht nur aus PR Zwecken, als grobes Ma fr die Leistung einer CPU. u Sie gibt auch die Geschwindigkeit an, mit der die Einzelnen Transistoren schalten. Damit trgt sie entscheidend dazu bei, wie schnell Berechnungen durchgefhrt a u werden knnen. Lange Zeit stellten die anwachsenden Taktraten kein greres o o Problem, fr die Entwicklung immer leistungsfhiger Chips, dar. Auch die u a immer feiner werdenden Strukturen, wurden durch die Entwicklung neuer Verfahrenstechniken und den Einsatz neuer Materialien im Fertigungsprozess ermglicht. Zur Einfhrung des Pentium 4 Prozessor warb der US-amerikanische o u Halbleiterhersteller Intel noch damit, die Taktraten bei Prozessoren in den
36
4 OpenCL
kommenden Jahren noch auf 10Ghz steigern zu knnen[1]. Allerdings bestehen o grundstzliche physikalische Hindernisse bei der Steigerung der Taktrate. Bei a jedem Stromuss muss ein Wiederstand uberwunden werden der in thermische Energie umgewandelt wird. Bei immer kleiner werdenden Strukturen und Chipchen wurde die somit erzeugte Abwrme der Prozessor bald zu einem a a Problem. Die Chiphersteller wie Intel und AMD lassen fr ihre CPU maximal u 150 Watt Abwrme zu. Zwar gibt es seit 2007 mittlerweile von IBM speziell a fr Serversysteme Power6-Prozessoren mit bis zu 5Ghz Taktrate[2], doch lassen u sich noch hhere Werte nur noch schwer zuverlssig mit Luftkhlen. Aus diesem o a u Grund suchte man nach neuen Wegen um die Leistung weiter zu steigern. Das Ziel war es nicht mehr uber die Taktung des CPU an Schnelligkeit zu gewinnen, sondern mittels parallelem rechnen. Aus diesem Grund entschloss man sich mehrere Kerne auf einem Prozessor zu verbauen. Allerdings reicht selbst die aktuellste und schnellste Multi-Core-CPU fr einige anspruchsvolle Anwendung u nicht aus. Vor allem im medizinischen und wissenschaftlichen Bereich, der Signalverarbeitung, bei Audio- Bild- und Videoverarbeitung, der Kryptographie oder bei Physik-Simulation/Eekte stoen aktuelle Mehrkern-Prozessoren an ihre Grenzen. Aus diesem Grund versucht man seit kurzem auf andere leistungsfhige a Systemressourcen zurckzugreifen. u Im Zuge der rasanten Entwicklung in der Spieleindustrie wuchs auch die Leistung der Grakkarten mit den Anforderungen. Immer mehr grasch anspruchsvollere spiele Titel veranlasste Hersteller wie ATI und NVIDIA Grakprozessoren zu entwickeln, die so viele Berechnung wie mglich parallel ausfhren konnten, um o u die Inhalte ssig darzustellen. Diese wurden ursprnglich zur Untersttzung u u u und Entlastung von Grakberechnung der CPU genutzt. Doch durch gestiegene Leistung und Flexibilitt, sowie der hohen Parallelitt an Aufgabenbearbeitung, a a boten Grakkarten immer mehr das Potential fr den Einsatz als Co-Prozessor. u NVIDIA entwickelt erstmals mit der API CUDA(Compute Unied Device Architecture) eine Schnittstelle Programmteile zur Berechnung auf Hersteller eigenen Grakkarten auszulagern. Es bietet der Anwendung den Vorteil, von der meist auerhalb von Videospielen und Grakanwendung genutzten und brach liegende Rechenleistung der GPU zu protieren. Dabei bieten vor allem neuere GPUs durch die hohe Anzahl an Kernen im Vergleich CPUs die Mglichkeit, Programme mglichst schnell parallel abzuaro o beiten. Wie auf Abb. 4.1 zu erkennen ist, besitzt ein Multi-Core CPU deutlich weniger ALUs (Arithmetic Logic Unit) als eine GPU, die aktuell weit uber 500 von Stream-Prozessoren enthalten kann. CPUs haben zwar den Vorteil einen umfangreicheren Befehlssatz und greren Speicher zu besitzen, der o
4.2 OpenCL - Hintergrund
37
Abbildung 4.1: Vergleich Aufbau einer mehr Kern CPU und GPU mit dazugehrigem o Speicheraufbau[5]
es ihnen ermglich komplexere Befehle abzuarbeiten, allerdings sind in ihrer o Parallelitt relativ begrenzt. Diesen Nachteil haben Grakprozessoren nicht. Sie a bieten zwar nur einen begrenzten Befehlssatz an, weien dabei aber eine hohe Parallelitt von Aufgabenabarbeitung auf. Ermglicht wird dies durch mehrere a o kleine Control Units die uber einen eigenstndigen Cache verfgen. Die Berecha u nung ist zwar hnlich der eines Threads bei einer CPU, jedoch deutlich ezienter. a Zur Programmierung von CUDA Fhigen Grakkarten wird C for CUDA a eine C Version mit NVIDIA-Erweiterung genutzt. Weiterhin existieren auch ein Wrapper fr Perl, Phyton, Java, Fortan und .NET und auch eine Anbindung u fr Matlab. Ein Entscheidender Nachteil bei der Entwicklung von CUDA ist, u das diese Schnittstelle auf die NVIDIA eigenen Grakkarten beschrnkt ist. Aus a diesem Grund begann Apple mit der Entwicklung einer eignen Schnittstelle.
4.2
OpenCL - Hintergrund
Apple entwickelte in Zusammenarbeit mit Firmen wie AMD, Intel und NVIDIA einen ersten Entwurf fr uneinheitliche Parallelrechner. Dieser Entwurf ist ein Frau mework namens OpenCL und verfolgt das Ziel aus mehreren unterschiedlichen Systemkomponenten wie CPU, GPU und anderen Signalprozessoren fr Berechu nung notwendige Systemleistung zu kombinieren. OpenCL welches ursprnglich u
38
4 OpenCL
von Apple entwickelt worden war, wurde schlielich im Juni 2008 zur Standardisierung eingereicht. Verantwortlich fr die Entwicklung ist seitdem die im Jahr u 2000 gegrndete Khronos Group. Das Konsortium wird gebildet aus einem Zuu sammenschluss einer Vielzahl von namenhaften Herstellern- und Dienstleistungskonzernen der IT-Branche. Darunter bekannte Unternehmen wie Intel, AMD/ATI, Nvidia, Sun, Apple, Mozilla, Opera, Adobe und Google. Unter anderem betreut die Khronos Group noch weitere bekannte Projekte, wie zum Beispiel die Weiterentwicklung von OpenMAX, OpenGL und den Ableger OpenGL ES, sowie WebGL. Dadurch das OpenCL nun als oener und Standard entwickelt wird, bietet es im Vergleich zu CUDA nun die Mglichkeit an, fr jeden Hardware- und Betriebssyso u temhersteller eigene Implementierungen und Erweiterungen zu entwickeln, welche sich allerdings im Rahmen der Spezikationen bewegen mssen. Die Khronos u Group verentlichte die erste Spezikation von OpenCL am 8. Dezember 2008. o Die Aktuellste und neuste Version ist OpenCL 1.2, welche auch abwrtskompatibel a ist und im November 2011 erschien.
4.3
Voraussetzungen fr OpenCL u
Um die Voraussetzungen fr aufgabenparalleles bzw. datenparalleles Rechnen fr u u OpenCL zu erfllen, bentigt man allerdings einige Hardware und Softwareseitige u o Implementierungen. Das Betriebssystem muss, um eine Beschleunigung mit OpenCL nutzen zu knnen, uber folgende Bestandteile verfgen. o u Implementierung in BS notwendig: OpenCL Application Programming Interface (API) OpenCL Runtime Engine OpenCL Compiler Auch auf der Hardwareseite mssen einige Voraussetzungen erfllt werden. Es u u kann fr die Berechnung nur auf Hardware zurckgegrien werden, wie CPUs u u und GPUs, bzw. Schaltkreise, die die notwendigen Spezikationen erfllen. Eine u der wesentliche Bestandteil liegt in den neuen Funktionen und Frameworks. Bei der Verwendung dieser mssen die neuen Mglichkeiten zum Datenparallel rechu o nen auch ausgenutzt werden. Bisherige Software wird somit durch die fehlende OpenCL Tauglichkeit nicht von einem Performance-gewinn protieren. Es mssen u als Ressourcen intensive programmteile OpenCL konform und API konform ausgelagert werden, um die erforderliche Beschleunigung zu erreichen. Sobald alle Voraussetzungen erfllt sind: u
4.4 OpenCL - Aufbau/Architektur
39
Betriebssystem OpenCL tauglich Hardwarekomponenten OpenCL tauglich Software OpenCL konform ist die Beschleunigung von Programmteilen durch Auslagerungen mglich. Wenn o allerdings nur eine der drei Bedingungen nicht erfllt ist, kann kein OpenCL u Code auf dem System ausgefhrt werden. u Wie bereits erwhnt, bentigt das OpenCL-Framework zur Ausfhrung a o u drei Komponenten: die OpenCL-API, die OpenCL-Runtime und den OpenCLCompiler. Bei Betriebssystemen auf denen die OpenCL-Runtime implementiert ist, trennt die Runtime die unterliegende Hardware vom Betriebssystem. Der Compiler wandelt die auf C basierende Sprache in OpenCL C um. Diese, mit der C verwandte Programmiersprache, kann auf jeder Recheneinheit die den OpenCL-Standard erfllt, kompiliert und nativ ausgefhrt werden. Sie enthlt u u a zustzlich zu den normalen Befehlen einige Erweiterungen mit mathematischen a Zusatzfunktionen, die die Implementierung von wissenschaftlicher sowie und ingenieur-spezischer Problemlsungen vereinfacht. Durch die Integrierung des o Compilers in das OpenCL-Framework wird es ermglicht, Programme erst zur o Laufzeit am Zielrechner kompiliert zu lassen. Diese schat die Voraussetzung fr das Speichern des Programmcodes, der somit nicht bei jedem Start des u Programms neu am Zielrechnerneu kompiliert werden muss. Es ist von daher nicht ntig fr den Entwickler im Vorfeld zu wissen, ob und wie viele verschiedene o u OpenCL taugliche Komponenten im Zielsystem verfgbar sind, da durch die u externe Verarbeitung eine Vorkompilierung auf unterschiedliche Version der Anwendung uberssig ist. u
4.4
OpenCL - Aufbau/Architektur
Eine OpenCL Anwendung besteht im Wesentlichen aus folgenden Bestandteilen: Hosts, Devices, Compute Units, Command Queues, Program Objects, Kernel Functions, Memory Objects und Context, Abb. 4.2.
4.4.1
Host
Als Host-Applikation wird das Programm bezeichnet das die Funktionen von OpenCL aufruft, den dafr notwendigen Context erstellt und die Kernel an die u Warteschlangen weitergibt. Die dazugehrigen Host Devices(beispielsweise CPU), o sind Gerte auf denen die Host-Applikation ausgefhrt werden kann. Um jedoch a u
40
4 OpenCL
Abbildung 4.2: Plattform-Modell einer OpenCL Anwendung[6]
ein Kernel starten zu knnen, muss die Anwendung folgende Schritte ausfhren: o u Bestimmung der verfgbaren Devices(CPU, GPU...) u Whlen der geeigneten Devices, die fr die Berechnung in Frage kommen a u Befehlswarteschlangen fr die gewhlten Devices erstellen u a Allokieren des Speichers (Memory Objects) der fr die gemeinsame Nutzung u der Kernel-Ausfhrung bentigt wird u o
4.4.2
Compute Devices/Units
Jede Baugruppe die rechentaugliche Aufgaben im Sinne der OpenCL Spezikationen ausfhren kann, wird als Device bezeichnet. Innerhalb jedes Devices knnen u o sich ein oder mehrere Recheneinheiten benden. Diese werden auch als Compute Units bezeichnet, in der die Berechnungen mithilfe von Befehls-Sets abgearbeitet werden. Unter Compute Units versteht man im Allgemeinen nicht anderes als beispielsweise bei einem Mehrkernprozessor, die einzelnen Kerne. Daraus ergibt sich bei CPUs eine theoretische Abarbeitungsparallelitt, die der Anzahl der a zur Verfgung stehenden Kerne entspricht. Im Vergleich zu GPUs bieten CPUu Modelle mit ihrer geringen Anzahl an Compute Units allerdings weniger potential um Anwendungen mittels parallel Verarbeitung zu beschleunigen
4.4 OpenCL - Aufbau/Architektur
41
4.4.3
Kernel
Der Begri Kernel steht im Allgemeinen fr eine Funktion innerhalb einer Sprau che. Als Kernel werden in OpenCL Programme bezeichnet die zur Ausfhrung u auf OpenCL tauglichen Devices kompiliert wurden. Auch wenn die Kernels in die Host-Applikation implementiert und in C oder C++ geschrieben sind, mssen u diese auf dem Zielrechner separat erzeugt werden. Nur so knnen die verfgbaren o u Devices angesprochen und optimal an das jeweilige System angepasst werden. Der so entstandene Quellecode kann entweder extra in einer Datei gespeichert oder in den Code der Host-Applikation eingebettet werden. Zwei Arten von Kerneln[3]: OpenCL-Kernel, sind in der Programmiersprache OpenCL C geschrieben(OpenCL C basiert auf ISO C99 und wurde um Funktionen und Datentypen zur parallelen Verarbeitung erweitert) Native Kernel: Diese Kernel sind optional und implementierungsspezisch
4.4.4
Program
Ein Program in OpenCL besteht aus einer Menge von Kerneln, sowie dazugehriger Hilfsfunktionen und Konstanten. Diese knnen innerhalb des Kernels o o aufgerufen und verwendet werden.
4.4.5
Command Queue
Die Ausfhrung einiger Befehle wird in OpenCL mittels Command Queue abgeu arbeitet. Diese Befehle dienen zur Ausfhrung von Kerneln, fr den Transfer von u u Daten zwischen Hauptspeicher und dem Speicher des Compute Devices. Weiterhin knnen Befehlswarteschlangen genutzt werden, um anstehende Befehle an o ein konkretes Gert zu ubermitteln. Diese fhren den Kernel auf dem Gert in a u a der Reihenfolge aus, in der sie in die Warteschlange abgelegt wurden. Zustzlich a gibt es Synchronisationsbefehle mithilfe derer man den Kernel auf die Ausfhrung u eines Datentransfers warten lassen kann.
4.4.6
Program Object
Als Program Object werden in OpenCL Datentypen bezeichnet, die eine OpenCLAnwendung reprsentieren. Folgende Informationen knnen somit gekapselt wera o den: Eine Referenz auf den aktuellen Context
42
4 OpenCL
Programmcode oder auch das Binary Die zuletzt erfolgreich kompilierte Version des Programms Eine Liste der Gerte, bei der letzten erfolgreich kompilierte Programm Version a und der zugehrigen Kompilier-Parametern und Logles o
4.4.7
Context
Mit dem Context wird eine Systemumgebung beschrieben, in der ein Kernel ausgefhrt werden kann. Dazu gehren die Anzahl der Devices, die Angabe der u o verfgbaren Speicherbereiche im System, sowie Befehlswarteschlangen zur Abaru beitung der Programmbefehle. Er ist auerdem notwendig um gemeinsame Speicherobjekte zwischen den einzelnen Devices aufzuteilen, Abb. 4.3.
Abbildung 4.3: OpenCL Speicher Modell[7]
4.4.8
Memory Object
Eine Memory Object enthlt eine Referenz auf einen lokalen Speicherbereich a und dient so zur Bereitstellung von Arbeitsspeicher fr die Applikation. In u OpenCL werden zwei Arten von Speicherobjekten unterschieden. Buer-Objects
4.5 OpenCL C und Besonderheiten
43
die alle Arten von Daten beinhalten knnen und Image-Objects die nur auf o Bildinformationen spezialisiert sind. Die Host-Applikation verwaltet diese und reiht sie in die Befehlswarteschlange zum Lesen und Schreiben ein. In OpenCL gibt es verschiedene Arten von Adressrumen: a Private fr Daten die zu einem Work-Item gehren u o Local fr Daten die zu einer Work-Group gehren u o Global fr Daten auf die von allen Work-Items und Work-Groups aus zugeu grien werden kann constant fr read-only Daten u In OpenCL wird versucht die jeweilige Implementierung der Hierarchie so gut wie mglich auf die zur Verfgung stehende Hardware anzupassen. Zu beachten o u ist, dass die Konsistenz der Daten im Speicher nicht immer garantiert ist. So knnen zwar innerhalb einer Work-Group, nach einer Synchronisation, die Daten o aus lokalen und globalen Speicherbereich konsistent sein. Jedoch wird auf die global zugreifbaren Daten keine Konsistenz uber die Grenzen einer Work-Group hinweg garantiert. OpenCL bietet die Mglichkeit mehrere Instanzen eines Kernels gleichzeitio ge auf einem oder mehreren OpenCL-Gerten auszufhren. Jede Kernel-Instanz a u wird dabei als Work-Item bezeichnet und besitzt zu dem eine globale ID. Sobald ein Entwickler den Kernel zu Abarbeitung an ein Device ubergibt, kann er die Anzahl der Kernel-Instanzen fest denieren, auch Index-Spaces genannt. Diese knnen sowohl ein- zwei, als auch dreidimensional sein. Damit eine o synchronisierte Berechnung der einzelnen Kernel-Instanzen erfolgen kann, wird es ermglicht die Work-Items in sogenannten Work-Groups zusammenzufassen. o Eine Synchronisation zwischen Work-Groups ist allerdings nicht mglich. o
4.5
OpenCL C und Besonderheiten
In OpenCL wird die Sprache OpenCL C verwendet, welche auf der Syntax von ISO C99 beruht. OpenCL C gehrt zwar zur Obermenge der Sprache C, o enthlt aber auch einige Absonderungen und Ausnahmen zu dieser. Zustzlich a a zu C, wurden weiter Funktionen und Datentypen zu parallelen Verarbeitung hinzugefgt, beispielsweise ein Datentypen fr zwei- und dreidimensionale u u Bilder. Es gibt allerdings auch einige Einschrnkungen die z.B. den Aufruf von a Funktionspointern und rekursiven Kernel Aufrufen verbietet. Ebenso werden
44
4 OpenCL
Array mit variabler Lnge und Structs nicht untersttzt. a u nicht enthalten: Funktionspointer Rekursion Arrays variabler Lnge a structs optional: Gleitkommazahlen mit doppelter Genauigkeit Atomare Funktionen (z.B. increment) Zustzlich zu den in C99 verwendeten Datentypen, werden die weiteren folgenden a Datentypen in OpenCL C benutzt[4]: half: 16 Bit Gleitkommazahlen nach IEEE 754r Vektordatentypen: Char, uchar, short, ushort, int, uint, long, ulong und float als Vektoren mit 2, 4, 8 und 16 Elementen, mit OpenCL 1.1 wurden zustzlich Vektoren mit 3-dimensionen eingefhrt a u image2d t: zweidimensionales Bild image3d t: dreidimensionales Bild sampler t: sampler, der deniert, wie ein Bild abgetastet wird event t: Event Handler
4.6
Fazit
Da mittlerweile fast alle aktuell verkauften Systeme neben einer MehrkernCPU, auch eine leistungsfhige Grakkarte besitzen und diese bei den meisa ten Anwendungen zur Verfgung stehende Leistung nicht genutzt wird, bieten u sich im Bereich verteiltes und paralleles Rechnen mit OpenCL beeindruckende Mglichkeiten der Performance Steigerung von Applikationen an. Im Vero gleich zu CUDA welches speziell nur auf NVIDIA Grakkarten anwendbar ist, bietet OpenCL die Mglichkeit frei den Hersteller zu whlen. So knnen uno a o abhngig vom Hersteller des Betriebssystem und der Grakkarte OpenCL kona forme Programme ausgefhrt werden. Dazu zhlen auch spezielle Lsungen die u a o
45
die OpenCL Spezikationen erfllen, wie z.B. Embedded und Mobile Devices mit u Prozessoren die sowohl CPU als auch GPU auf einem Chip vereinen. Die Anwendungsbereich in denen durch GPUs in Zukunft besonders viel Leistung durch parallele Berechnung erzeugt werden kann und in denen es bereits Umsetzung solcher Verfahren gibt, sind vor allem im Bereich von Video und Bildbearbeitung, beim Video decodieren bzw. encodieren, sowie bei der Berechnung von komplexen Gen- und Moleklforschung zu nden. u
[1] CHIP Magazin - Ausgabe 05/2011, Artikel Die Grenzen der PCTechnik, Seite 36-39, Verlag: CHIP Communications GmbH und Internetartikel: http://www.chip.de/news/Intel-quot-10-GHz-Prozessoren-im-Jahr-2005quot 34160520.html, Aubgerufen am 08.01.2012 [2] http://de.wikipedia.org/wiki/IBM Power#Power5, abgerufen am 08.01.2012 [3] http://de.wikipedia.org/wiki/OpenCL, abgerufen am 13.01.2012 [4] The OpenCL Specication - Khronos OpenCL Working Group, Ver. 1.2 , Doc Rev. 15, Seite: 199-200, 219, Autor: Aaftab Munshi, http://www.khronos.org/registry/cl/specs/opencl-1.2.pdf, abgerufen am 13.01.2012 [5] Abb. 1, http://www.keremcaliskan.com/wp-content/uploads/2011/01/CPUGPU-Structures1.png, abgerufen am 08.01.2012
[6] Abb. 2, http://upload.wikimedia.org/wikipedia/de/thumb/9/96/Platform architectu 11-08.svg/800px-Platform architecture 2009-11-08.svg.png, abgerufen am 13.01.2012
[7] Abb. 3, http://upload.wikimedia.org/wikipedia/de/d/d1/OpenCL Memory model.sv abgerufen am 13.01.2012
46
4 OpenCL
Peer-to-Peer-Systeme
Tim Achtert
48
5 Peer-to-Peer-Systeme
Sicherheit Systemen
in
verteilten
Mario Fhr o
Inhaltsverzeichnis
6.1 6.2 6.3 6.4 Einleitung . . . . . . . . . . Angrie . . . . . . . . . . . Delegation . . . . . . . . . Vertrauenswrdiges System . u 6.4.1 Verschlsselung . . u 6.4.2 Authentizierung . . 6.4.3 Kerberos . . . . . . Secure Sockets Layer . . . . Firewall . . . . . . . . . . . Intrusion Detection System . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 50 51 51 52 53 54 55 56 57 58
6.5 6.6 6.7 6.8
6.1
Einleitung
Die Sicherheit in verteilten Systemen wird immer mehr zu einem wichtigen Thema in den Medien. Ereignisse der Vergangenheit zeigen, dass Computer immer huger zu Zielen von Angrien werden. Es wird fast tglich von Angrien auf a a die Computersysteme von Firmen, prominenten Personen oder sogar von Regierungen berichtet. Sogar Unternehmen, welche selber im IT-Sicherheits Gebiet angesiedelt sind, werden zu Zielen von Angrien. Ein verteiltes System ist hier vermeintlich besonders anfllig, da es aus mehreren Systemen besteht. Jea des weitere System ist ein potenzieller Angrispunkt fr Angreifer und bedeutet u zustzlichen Aufwand zur Absicherung. Schaut man sich die Vielzahl der Angrie a und die Gre/Bekanntheit der angegrienen Ziele an, so knnte man zu dem o o Schluss kommen, es gibt keine Techniken, um sich gegen Angreifer zu verteidigen. Diese Ausarbeitung soll aufzeigen, dass dies nicht der Fall ist und es durchaus Mglichkeiten gibt, sich gegen einen Angreifer zu wehren. o
50
6 Sicherheit in verteilten Systemen
Abschnitt eins nennt und erlutert mgliche Angrie auf ein verteiltes System. a o Abschnitt zwei erlutert den Begri der Delegation, der prgend fr ein verteiltes a a u System ist, da Aufgaben nur selten direkt am Eintrittspunkt des Anwenders ausgefhrt werden. u Der dritte Abschnitt erlutert die Merkmale, welche ein System aufweisen muss, a dem vertraut werden kann. Die dazu bentigten Techniken werden vorgestellt. o Im vierten Abschnitt wird der Secure Socket Layer erlutert und auf seine Wicha tigkeit zur Absicherung einer Verbindung zwischen zwei Systemen hingewiesen. Abschnitt fnf erlutert das Vorgehen, um ein sicheres Netz von einem unsicheren u a Netz abzutrennen und somit das sichere verteilte System vom unsicheren Internet zu schtzen. u Es werden ebenfalls Techniken zur Analyse, Erkennung und Vermeidung von Angrien bentigt. Mit diesem Thema befasst sich das sechste Kapitel. o Im letzten Kapitel wird der Autor ein Fazit zu allen erluterten Techniken ziehen. a
6.2
Angrie
Es werden vier Arten von Angrien unterschieden. 1. Unterbrechen: Dabei handelt es sich um eine bewusste Strung des o Ubertragungssystems durch Trennung vom Netz. Es handelt sich um einen Angri auf die Verfgbarkeit des Systems. u 2. Abhren und Mitschneiden: Abhren erfolgt durch nicht autorisierte Teilneho o mer. Es erfolgt ein Angri auf die Vertraulichkeit der Nachricht. 3. Flschen: Die Nachricht wird whrend des Transport verndert. Dies ist ein a a a Angri auf Integritt der Nachricht. a 4. hinzufgen / generieren: Der Angreifer ahmt das Verhalten eines autorisieru ten Teilnehmers nach und erzeugt falsche Daten. Dies ist ein Angri auf Glaubwrdigkeit der Nachricht. u Es werde fnf Angrisformen unterschieden. Davon sind vier passiv und eine u aktiv. Aktive und passive Angrisformen unterscheiden sich dadurch, dass fr u einen aktiven Angri ein Programm in das System eingeschleust werden muss. 1. Lauschangri (passiv): Die Informationen werden unbemerkt mitgeschnitten und nicht verndert. Der Angreifer hat keine Kontrolle darber, was er mita u schneiden kann. 2. Maskerade (passiv): Der Angreifer gibt sich als jemand anders aus z.B: durch geklaute Zugangsdaten.
6.3 Delegation
51
3. Intigrieren (passiv):Die Nachricht wird bei der Ubertragung verflscht, sodass a der Angreifer ein anderes Verhalten beim Empfnger erzeugt, als vom Absena der gewollt. 4. Wiederholen (passiv): Die Nachrichten knnen mitgeschnitten und spter uno a verndert erneut gesendet werden. Der Angreifer muss dazu die Nachricht a nicht entschlsseln knnen. u o 5. Verweigerung (aktiv): Eine eingeschleuste Komponente verhindert, dass der angeforderte Dienst erbracht werden kann, weil Nachrichten nicht mehr weitergeleitet oder verarbeitet werden. Auch Netzberutung mit willkrlichen u u Nachrichten kann zur Verweigerung fhren. u Zur Durchfhrung eines Angri werden bekannte Zugangsdaten verwendet. Diese u Zugangsdaten knnen durch eine geflschte Login-Oberche gesammelt werden. o a a Des Weiteren kann ein Angri durchgefhrt werden, indem die Autorisierung umu gangen wird, oder bekannte Sicherheitslcken ausgenutzt werden. Eine weitere u Mglichkeit ist das Tarnen eines Programms als legitimes Programm und es per o Mail verschicken, um den Empfnger zu inzieren. a
6.3
Delegation
In verteilten Systemen muss eine Aufgabe zwischen den Servern delegiert werden. Delegieren besagt, dass eine Aufgabe nicht vom Auftraggeber ausgefhrt wird, u sondern er delegiert/beauftragt jemanden anders. Ist der Auftraggeber gleichzeitig der Sender der Nachricht, dann wird er Originator genannt. Sind Sender und Auftraggeber nicht identisch, dann muss geprft werden, ob der Sender im u Auftrag des Auftraggebers handelt. Sollte er nicht im Auftrag des Auftraggebers handeln, dann handelt es sich um einen Angreifer. Der Originator hat immer den Auftrag zu verantworten. Er kann ihn technisch nicht abstreiten. Es drfen u keine globalen Vollmachten erstellt werden, sondern nur eingeschrnkte Rechte. a Das macht das System sicherer gegen Angrie. Wichtig ist die erste Prfung der u Identitt des Auftraggebers. Die Identitt kann nur an der Stelle mit direktem a a Kontakt zum Auftraggeber durchgefhrt werden. Empfnger hinter dem ersten u a Kontakt knnen den Auftraggeber nicht mehr authentizieren. Fr die Autheno u tizierung wrden sie Zugangsdaten und Password des Auftraggebers bentigen. u o Diese Daten mssen uber das Netz weitergegeben werden, um den Auftraggeu ber zu authentizieren. Bei der Weitergabe der Zugangsdaten und Passwrter o handelt es sich um eine schdliche Form der Personikation. Prinzipiell ist eine a Authentizierung des Auftraggebers an jeder Stelle gut, aber durch die Weitergabe sicherheitsrelevanter Daten wird es zu einem Sicherheitsrisiko.
52
6.4
Vertrauenswrdiges System u
Damit bei einem System von einem vertrauenswrdigen System gesprochen weru den kann, mssen mehrere Punkte erfllt sein. Als erstes mssen abgesicheru u u te Kommunikationskanle verwendet werden. Dadurch wird das unautorisierte a Abhren verhindert. Die Verbindung ist durch Kryptograe geschtzt. Weiter ist o u gegenseitiges Misstrauen von einer sehr hohen Bedeutung. Dabei ndet eine Autorisierung beider Kommunikationspartner statt. Dadurch wird sichergestellt, dass der Client ein rechtmiger Vertreter ist und der Server authentisch ist. Als drita tes ist die Aktualitt der Nachricht sicherzustellen. Dazu werden Zeitstempel und a Nonces (Zufallszahl) verwendet. Durch einen Zeitstempel wird sichergestellt, dass eine Nachricht unbemerkt veraltet.
6.4.1
Verschlsselung u
Um die Kommunikationskanle abzusichern wird eine Verschlsselung eingesetzt. a u Bei einer Verschlsselung handelt es sich um eine Funktion, die auf Daten und u den Schlssel angewendet wird. Es existieren unterschiedliche Verfahren eine u Verschlsselung umzusetzen. u Das erste Verfahren ist die die symmetrische Verschlsselung. Bei einer u symmetrischen Verschlsselung haben beide Nutzer den gleichen Schlssel. Das u u heit, dass die Nachricht mit dem gleichen Schlssel ver- und entschlsselt u u wird. Bevor Nachrichten ausgetauscht werden knnen, muss der Schlssel o u ausgetauscht werden. Dieser Austausch ist gleichzeitig ein Angrispunkt auf die symmetrische Verschlsselung. Wird der Schlssel beim Austausch von einem u u Angreifer abgefangen, so kann die Kommunikation entschlsselt werden. u Ein weiterer Angrispunkt ist das Speichern des Schlssels. Beim Speichern muss u ebenfalls auf die Geheimhaltung des Schlssels geachtet werden. u Eine weiteres Verfahren zur Verschlsselung der Kommunikation ist die u asymmetrische Verschlsselung. Bei dem asymmetrischen Verfahren wird ein u o u o entlicher und ein privater Schlssel eingesetzt. Dabei muss der entliche Schlssel verteilt werden und der private Schlssel sicher gespeichert werden. u u Der entliche Schlssel wird aus dem privaten Schlssel generiert, aber es o u u muss sichergestellt werden, dass der private Schlssel nicht aus dem entlichen u o Schlssel berechnet werden kann. u 1. Empfnger stellt seinen entlichen Schlssel dem Sender zur Verfgung a o u u 2. Sender verschlsselt die Nachricht mit dem empfangenen entlichen u o Schlssel u
6.4 Vertrauenswrdiges System u
53
3. Sender sendet verschlsselte Nachricht an Empfnger u a 4. Empfnger entschlsselt Nachricht mit dem privaten Schlssel a u u Als drittes Verfahren sind Hashfunktionen zu nennen. Eine Hashfunktion bildet eine Nachricht beliebiger Lnge auf einen Hashwert fester Lnge ab. Dabei handelt a a es sich um eine Einwegfunktion. Dadurch kann aus dem Hashwert nicht wieder die Ausgangsnachricht hergestellt werden. Ein Hashwert muss leicht berechenbar sein, damit er von langsamer Hardware berechnet werden kann. Ein Hashwert muss auerdem kollisionsfrei sein. Kollisionsfrei bedeutet, das keine zwei Nachrichten den selben Hashwert erzeugen.
6.4.2
Authentizierung
Bei der Authentizierung handelt es sich um einen Vorgang, bei dem uberprft u wird, ob der Kommunikationspartner der ist fr den er sich ausgibt. Es handelt u sich somit um einen Echtheitsnachweis. Dazu werden oft seperate Authentizierungdienste auf eigenen Servern eingesetzt. Weit verbreitet ist das Needham Schroeder Protokoll. Legende: A: Sender, B: Empfnger, AS: Authentizierungsserver, NA: Nounce von A, NB: a Nounce von B, SK: Sessionkey, KA: Key zwischen AS und A ausgehandelt, KB: Key zwischen AS und B ausgehandelt
1. A sendet AS die Nachricht(A,B,NA) A sendet an den AS eine Nachricht. Sie besteht aus dem Sender (Absender), dem Empfnger an den gesendet werden soll (B) und eine selber generierte a Zufallszahl (NA) 2. AS sendet A die Nachricht (NA,B,SK,(SK,A)KB)KA AS sendet an A eine Nachricht. Diese besteht aus der von A gesendeten NA, dem Empfnger B, einem vereinbarten Sessionkey (SK) und einer mit KB a verschlsselten Nachricht. Diese mit KB verschlsselte Nachricht besteht aus u u dem SK und dem Sender A. Die ganze Nachricht ist mit dem KA verschlsselt. u 3. A sendet B die Nachricht (SK, A)KB A hat die von AS gesendete Nachricht entschlsselt. Den mit KB veru schlsselten Teil konnte sie nicht entschlsseln und sendet ihn genau so veru u schlsselt weiter an B. u 4. B sendet A die Nachricht (NB)SK B entschlsselt die von A gesendete Nachricht. Dadurch ist A gegenber B auu u
54
thentiziert, da A oensichtlich die von AS gesendete Nachricht entschlsseln u konnte. Um B gegenber A zu authentizieren, sendet nun B eine generierte u Nounce (NB) an A. Diese Nounce ist mit SK verschlsselt. u 5. A sendet B die Nachricht (NB - 1)SK A entschlsselt die von A gesendete Nachricht mit dem SK. Da B mit u dem SK verschlsselt hat, ist B auch authentiziert, da B die mit KB veru schlsselte Nachricht entschlsseln konnte und daraus den SK erhalten hat. u u Zur Besttigung sendet A noch eine mit SK verschlsselte, leicht vernderte a u a Nounce an B. Eine weitere Methode zur Authentizierung ist die Digitale Signatur. Durch sie wird sichergestellt, dass die Nachricht tatschlich vom Absender kommt. Eine Dia gitale Signatur muss flschungssicher sein und darf nur ein einziges mal verwendet a werden. Sie werden oft eingesetzt bei verschlsselter Emailkommunikation, eleku tronischen Handel, Bankverkehr. Das Ziel einer Digitalen Signatur ist nicht die Geheimhaltung der Nachricht. Mit einer Digitalen Signatur wird keine Nachricht verschlsselt Die Nachricht ist immer noch im Klartext lesbar.Ziel ist ausschlieu lich die Authentizierung. Hug werden Hashfunktionen eingesetzt, weil sie sehr a schnell sind und somit auf schwacher Hardware umsetzbar. Die Authentizierung mit einer Digitalen Signatur erfolgt in drei Schritten. S: Hashwert von Klartext gebildet und Ergebnis wird mit privaten Schlssel u verschlsselt u E: entschlsselt den Hashwert der empfangenen Nachricht mit entlichen u o Schlssel u E: bildet Hashwert uber die empfangenen Daten und vergleicht ihn mit dem entschlsselten Hashwert u
6.4.3
Kerberos
Bei Kerberos handelt es sich um einen Authentisierungsdienst fr oene Systeme. u Der Kerberos Dienst wird eingesetzt, um im Netz verteilte Dienste von jedem Arbeitsplatzrechner aus benutzen zu knnen. Alle Computer und Dienste (z.B. o Netzwerkdrucker) die das Kerberos-Protokoll implementiert haben, knnen somit o leicht und sicher verwendet werden. Abbildung 6.1 zeigt den Aufbau und Ablauf einer Authentizierung mit Kerberos. Der Kerberos Server selber besteht aus zwei Teilen. Dem Authentication Service und dem Ticket Granting Service. Der Authentication Service ubernimmt die Authentikation des Client und der Ticket Granting Service stellt Tickets fr die Kommunikation zu dem Dienst aus. Als u erstes muss sich der Client gegenber dem Kerberos Server authentizieren(siehe u Schritt 1 in Abbildung 6.1). Dies luft hnlich dem bereits erluterten Needham a a a
6.5 Secure Sockets Layer
55
Abbildung 6.1: Aufbau Kerberos
Schroeder Protokoll ab. Ist die Authentizierung erfolgreich, erhlt der Client vom a Kerberos Server ein Ticket Granting Ticket (TGT). Dies ist an Schritt Nummer 2 dargestellt. Dieses TGT dient dazu, dass der Client sich nicht erneut beim Kerberos Server authentizieren muss, sobald er einen anderen Dienst nutzen will. Ebenfalls wird ein Sessionkey ausgehandelt. Will der Client nun einen Dienst nutzen, schickt er sein TGT verschlsselt mit u dem Sessionkey an den Kerberos Server (siehe Schritt 3). Dieser entschlsselt die u Nachricht und stellt dem Client ein Ticket aus (siehe Schritt 4). Dieses Ticket sendet der Client nun an den Dienst (siehe Schritt 5). Der Dienst prft, ob der Client zur Nutzung berechtigt ist. Ist er berechtigt, dann wird ein u SessionKey ausgehandelt und Client und Dienst knnen verschlsselt kommunio u zieren (siehe Schritt 6).
6.5
Secure Sockets Layer
Secure Sockets Layer oder kurz SSL bildet eine zustzliche Zwischenschicht zwia schen der Transportschicht und der Anwendungsschicht. Die SSL Zwischenschicht wird eingesetzt, um eine sichere Ubertragung auf einem unsicheren Medium zu garantieren. Die Verbindung ist danach authentisch und die Integritt der Pakete a kann sichergestellt werden. Entwickelt wurde SSL ursprnglich von Netscape fr u u den Einsatz im https Protkoll des Browsers. Heute wird es aber in vielen Anwendungen eingesetzt. Abbildung 6.2 zeigt den Ablauf des SSL Handshakes. Der Handshake besteht aus vier Phasen. Phase 1: Der Client generiert eine Zufallszahl. Diese Zufallszahl wird in einem Client-Hallo an den Server gesendet. Der Server generiert ebenfalls eine Zufallszahl und sendet diese in einem Server-Hallo an den Client. Phase 2: Der Server sendet sein Zertikat zusammen mit seinem Public-Key
56
Abbildung 6.2: SSL Handshake
an den Client. Gleichzeitig fordert er das Zertikat des Clients an. Der Client uberprft das Zertikat des Server. u Phase 3: Der Client schickt sein Zertikat zusammen mit seinem Public-Key an den Server. Dieser checkt das Zertikat des Client. Der Client generiert das pre master secret (PMS). Beim PMS handelt es sich um eine Zufallszahl. Das PMW wird verschlsselt mit dem Public-Key des Server an den Server u gesendet. Der Server entschlsselt das PMS. Sowohl Client als auch Server u generieren das master secret (MS). Das MS wird aus der Zufallszahl des Client, des Server und dem PMS generiert. Ist der Handshake erfolgreich gewesen, dann haben sowohl Client als auch Server den selben MS erhalten. Phase 4: Sowohl Client als auch Server wechseln auf verschlsselte Kommuniu kation. Sie verschlsseln alle Nachrichten mit dem selbst generierten MS und u beenden ihrerseits den SSL Handshake.
6.6 Firewall
57
6.6
Firewall
Bei einer Firewall handelt es sich um ein System, dass den Datenstrom zwischen einem gesicherten Netzwerk (Heimnetz, oder Firmennetz) und einem unsicheren Netz (Internet) uberwacht. Ihr Zweck ist es also Sicherheitslcken und Angrisu punkte in Protokollen zu schlieen. Des weiteren erstellt sie Zugrisstatistiken. Es werden drei Typen von Firewall unterschieden. 1. Paketlter: Filtert Pakete nach denierten Regeln. Pakete, die den festgelegten Regeln entsprechen, werden nicht durch die Firewall durchgelassen und verworfen. 2. Circuit-Relay: Ein Circuit-Relay verhindert eine durchgehende Protokollverbindung. Er fungiert sozusagen als Proxy. Die Anwendung sendet die Daten an den Proxy und dieser sendet sie dann an den Empfnger. Genauso nimmt a der Proxy die Pakete des Empfngers entgegen und leitet sie an den Sena der weiter. Fr dieses Verhalten muss die Anwendung an die Verwendung des u Circuit-Relays als Proxy angepasst werden. 3. Application Gateway: Der Application Gateway hat gegenber dem Curcuitu Relay den Vorteil, dass die Anwendung nicht speziell angepasst werden muss. Dem Application Gateway ist der Kontext der Anwendung genau bekannt. Deshalb kann er klassizieren, welche Pakete typisch und korrekt sind fr die u Anwendung und welche nicht.
6.7
Intrusion Detection System
Bei einem Intrusion Detection System (kurz IDS) handelt es sich um ein Hardwareoder Software-System. Das IDS hat drei Aufgaben: Erkennen eines erfolgreichen Angris Meldung eines Angris automatische Vereitlung eines Angris Das IDS besteht aus vier einzelnen Teilen (siehe Abbildung 6.3). Die erste Komponente ist die E-Box. Die E-Box oder auch Ereignisquelle sammelt Nachrichten aus den Systemschichten. Diese Nachrichten werden fr eine sptere Verwendung u a in der D-Box oder auch Speichereinheit gespeichert. Zur Analyse der Ereignisse der E-Box wird die A-Box oder auch Analyseeinheit verwendet. Die A-Box analysiert Logles der E-Box, die diese nicht eindeutig als Angri identizieren konnte. So wird versucht neue Angrismuster zu nden. Handelt es sich um einen An-
58
Abbildung 6.3: Aufbau Intrusion Detection System
gri wird das Angrismuster in der D-Box gespeichert, damit die E-Box sptere a Angrie nach dem Muster direkt erkennen kann. Erkennt die A-Box einen neuen Angri oder die E-Box einen bereits bekannten, dann wird die C-Box aktiviert. In der A-Box ist die meiste Feinarbeit zu leisten, denn es mssen Fehlalarme veru mieden werden. Bei der C-Box handelt es sich um ein Gegenmanahmesystem. Die C-Box verfgt zumeist aber nur uber passive Gegenmanahmen. Als Beiu spiel fr eine passive Gegenmanahme wre das Verstndigen eines Mitarbeiters. u a a Aktive Gegenmanahmen (Abschotten des Systems, Angreifer blocken) werden selten durchgefhrt, weil die Konsequenzen bei einem Fehlalarm zu hoch wren. u a Es werden vier Typen von IDS unterschieden: 1. Netzwerkbasierte Intrusion Detection System: Es wird der Verkehr analysiert durch passives Lauschen auf der Verbindung. Die Pakete werden gesammelt und auf Angrie analysiert. 2. System Integrity Veriers: Die Integritt von Systemdateien wird durch die a Verwendung von Prfsummen uberwacht. Dadurch kann verhindert werden, u dass ein normaler User Admin Rechte erlangt. 3. Logle Monitor: Die Logles von Servern werden nach bekannten Attacken untersucht. Bei verteilten Systemen muss hierfr ein zentralisiertes Logging u verwendet werden.
6.8 Fazit
59
4. Deception System: Deception Systeme enthalten oder simulieren absichtlich Sicherheitslcken. Durch eine starke Uberwachung wird versucht Angreifer zu u fangen. Des Weiteren werden die Angristechniken der Angreifer analysiert, um sptere Angrie auf das Hauptsystem gegen diese Angrie abzusichern. a
6.8
Fazit
In dieser Arbeit wurden viele Techniken vorgestellt, welche dazu dienen ein verteiltes System vor Angreifern zu schtzen. Alle Techniken sind ausgereift und bieten u wenig Angrispunkte. Allerdings vertritt der Autor die Meinung, dass eine Technik alleine nutzlos ist. Nur die geschickte Kombination von mehreren Techniken bringt den maximalen Nutzen und Schutz fr die verteilten Systeme. Eine absolut u sichere Authentizierung bringt nicht, wenn der Kommunikationsweg ungesichert ist und dadurch die Kommunikation abgefangen werden kann. Somit ist nur eine Kombination aus Authentizierung (z.B. Kerberos), sicherer Ubertragung (z.B. SSL) einer Firewall und einem IDS als sicher zu bewerten. Allerdings macht das Verwenden von mehreren Systemen das Ganze kostenintensiv und die Umsetzung aufwendig. Anwendungen und Dienste mssen angepasst werden. Die Firewall u und das IDS mssen richtig konguriert werden. Eine falsch kongurierte Firewall u und IDS erschweren durch falsche Filter oder Fehlalarme die Arbeit des Administrators. Des Weiteren entsteht ein hoher Wartungsaufwand, denn die Systeme mssen immer aktuell gehalten werden, um auf bekannte Sicherheitslcken zu u u reagieren.
[1] Steen Wendzel, Praxisbuch Netzwerk-Sicherheit. Galileo Press, 2007. [2] Walter Kriha, Sichere Systeme. Konzepte, Architekturen und Frameworks. Springer, 2009. [3] Walter Kriha, Internet-Security aus Software-Sicht. Grundlagen der SoftwareErstellung fr sicherheitskritische Bereiche. Springer, 2008. u [4] Klaus Irmscher, Verteilte Systeme. Universitt Leipzig, 2011. a
60
Streaming
Markus Schramm
Inhaltsverzeichnis
7.1 7.2 Einleitung . . . . . . . . . . . . . . . . Grundlagen . . . . . . . . . . . . . . . 7.2.1 Begrisklrung . . . . . . . . . a 7.2.2 Mechanismus . . . . . . . . . . Technologie . . . . . . . . . . . . . . . 7.3.1 Vergleich HTTP-Streaming und 7.3.2 Encoding . . . . . . . . . . . . 7.3.3 Protokolle . . . . . . . . . . . 7.3.4 Verteilstrategien . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Live-Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 61 61 62 63 63 64 64 66 69
7.3
7.4
7.1
Einleitung
Die Weiterentwickung der Infrastruktur des Internets, fhrt auch immer zu neuen u Technologien und Mglichkeiten des Datenaustausches. In dieser Arbeit soll eine o neue Technik vorgestellt und behandelt werden mit dem Namen Streaming in deutsch auch Strom oder Strmung. Im Gegensatz zum Downloadverfahren wird o ein nur fr einen bestimmten zeitlichen Intervall vorhandenener Datenstrom zur u Verfgung gestellt, welcher jedoch hug nicht gespeichert wird. Diese Art der u a Ubertragung einer Datenkette ermglicht zahlreiche, neue Mglichkeiten der o o Informationsweitergabe. Trotz der bisher noch nicht uberall bekannten Technik, wird sie bereits in einem groen Umfeld aktueller Anwendungen und Angebote eingesetzt. Im ersten Teil der Arbeit werden grundlegende Begrie zum Thema StreamingMedia erlutert und der Mechanismus des Streamings erklrt. Im darauf a a folgenden Teil wird der Unterschied zwischen HTTP-Streaming und LiveStreaming erlutert. Ein weiterer Teil der Arbeit erlutert die Technologien im a a speziellen und verwendeten Protokolle vom Streaming-Verfahren. Abschlieend
62
7 Streaming
werden die verschiedene Verteilstrategien Broadcast, Unicast, Multicast und Splittung betrachtet und ein Fazit gezogen.
7.2
7.2.1
Grundlagen
Begrisklrung a
Zunchst werden die Begrie Streaming-Media, Streaming und Streams erklrt. a a Denition nach Wegner: Der Begri Streaming-Media bezeichnet eine Internet-Technologie, bei der Filme oder Sprache bzw. Musik in Echtzeit direkt aus dem Inter- oder Intranet abgespielt werden knnen. Neu an der Streaming-Technik ist, dass lange o Wartezeiten entfallen. Die Dateien knnen direkt angespielt werden. o Nach Hendrick: Beschrnkung auf Bitrate des Kanals, mit Schwankungen a Erfordert Fehlertoleranzmechanismen
Streaming bezeichnet den Vorgang der Datenbertragung. u Ubertragene Signale bzw. Programme werden als Streams oder Live-Streams bezeichnet
7.2.2
Mechanismus
Ein Streaming Media-System setzt sich grundstzlich aus 5 Bestandteilen a zusammen: Media-Quelle, Encoder, Server, Ubertragunsweg und Empfnger a (siehe Abbildung 7.1). Die Aufgabe vom Encoder ist vor allem die Reduzierung des Speicherbedarfs groer Mediendateien, weil diese unkomprimiert nicht geeignet sind, im Internet als Stream Ubertragen zu werden. Als Streaming Server bezeichnet man einen Server fr die Auslieferung von Streams uber ein Netzwerk. Die Streaming u Media-Daten werden in kleine Datenpakete zerlegt und dann aufeinander folgend uber das Netzwerk via Streaming-Server zum Player auf einem Client Ubertragen.
7.3 Technologie
63
Abbildung 7.1: Bestandteile des Streamingvorganges
7.3
7.3.1
Technologie
Vergleich HTTP-Streaming und Live-Streaming
HTTP-Streaming Auch Progressive Download genannt ist ein Streaming-System ohne speziellen Streaming-Server. Dieser nutzt die Tatsache aus, dass normalerweise immer eine Verbindung uber einen Webserver hergestellt wurde. Ein Encoder konvertiert die Audio/Video-Dateien auf ein Streaming-Format. Die konvertierte Datei wird dann auf dem Verentlichungsverzeichnis des Webservers abgelegt, so wie o HTML-Files oder Bilder. Die Datei wird wie ein normaler Download abgerufen. Whrend des Downloads wird dabei ein Ziwschenpuer gefllt, dem man a a bereits zum Abspielen nutzen kann. Diese Methode hat den Vorteil, dass das zu uberspielende Material schon vorzeitig in Augenschein genommen werden kann (sog. Pseudo-Streaming) und neben dem Webserver kein zusatzlicher Streaming-Server bentigt wird. o Nachteilig ist die Verwendung des langsamen HTTP-Protokolls und die fehlende Mglichkeit, die Ubertragungscharakteristika zu optimieren. Ferner ist o die Ubertragung von Live-Ereignissen mittels Download bzw. Pseudo-Streaming in der Regel nicht mglich. Groer Vorteil ist, dass keine zustzliche Portfreigabe o a fr Firewalls ntig ist, da diese standartmig Port 80 bei Webzugrien zulassen. u o a Bekannte Vertreter dieses Prinzips ist bspw. der Content-Provider YouTube. Live-Streaming Diese Methode wird bei besonders leistungsfhigen Streaming-Netzwerken a verwendet. Der Player (auch Client) wird hug als Hilfsapplikation zum Weba browser installiert oder als Java-Applet integriert. Dabei kann dieser entweder
64
7 Streaming
als Plug-In im Webbrowser selbst (sog. Embedding) eine Videodatei abspielen oder als externer Player starten. In beiden Fllen wird immer eine zustzliche a a Verbindung zum spezischen Streaming-Server aufgebaut. Der Datentransfer erfolgt uber Real-Time-Transport-Protokoll (RTP) meist in Verbindung mit dem User Datagram Protokoll (UDP). Vorteil ist ein schnellerer Datentransport im Vergleich zum HTTP-Streaming. Nachteilig ist der Verlust vom Inhalt und die unter Umstnden schlechtere Qualitt. a a Dieses Prinzip wird fr Webradios oder die Bereitstellung von IP-TV veru wendet.
7.3.2
Encoding
Wie bereits erwhnt wurde, benutzt ein Streaming-System Kodierungen und a Kompressionsalgorithmen, um einen Echtzeitstrom bestmglich im Internet zu o versenden. Was ist aber der Unterschied zwischen Kodierung und Kompression? Als Kodierung wird die Umsetzung einer Information auf eine bestimmte Ubertragungstechnik bezeichnet bspw. die Kodierung nach dem Morsealphabet. Dies schliet auch eine Verschlsselung mit ein. Bei der Kompression wird u Speicherplatz eingespart, indem Uberssige Informationen weckgelassen und u die restlichen Informationen in krzerer Form dargestellt werden knnen. u o Durch die Kodierung am Server und die nachtrgliche Dekodierung am a Client kann so die Ubertragungsrate gesenkt werden. Ein weiterer Vorteil des Encoding liegt darin, dass die Daten mit einem Fehlerschutz codiert werden. Damit knnen im Ubertragungskanal aufgetretene Strungen beim Empfnger o o a berichtigt werden. Daten und Fehler knnen voneinander getrennt werden. Die o ursprnglichen Daten erhalten vom Encoder zustzliche Informationen die vom u a Decoder bei der Fehlerbeseitigung verwendet werden. Der Kodierungsvorgang ist in Abbildung 7.2 dargestellt.
Abbildung 7.2: Ablauf der Encodierung und Decodierung beim Streaming
7.3 Technologie
65
7.3.3
Protokolle
Viele Anbieter von Streaming-Diensten setzen ihre eigenen Protokolle zur Datenbertragung ein. Die am hugsten verwendeten Protokolle werden hier voru a gestellt. Real-Time-Transport-Protokoll (RTP) RTP ermglicht die kontinuierliche Ubertragung von Streams (ber IP-basierte o u Netzwerke). Es arbeitet uber UDP (siehe Abbildung 7.3) und Ubermittelt die gewnschten Daten paketweise von Server zu Client. Zur Sicherstellung der u Synchronisierung und der korrekten Reihenfolge wird im Header eines jeden RTP-Pakets ein sogenannter Time-Stamp benutzt. Das RTP-Paket besteht aus folgenden Teilen: Versionsnummer Sequenznummer (dient dem Erkennen von Datagrammverlusten) Datenformat Sender-ID Zeitstempel/ Time-Stamp Nutzdaten
Abbildung 7.3: Protokollstack eines RTP-Paketes
Real-Time Control Protocol (RTCP) Das Real-Time Control Protocol wird in Verbindung mit RTP eingesetzt. Um dem Sender den aktuellen Status zu ubermitteln, sendet der Empfnger innerhalb einer a RTP-Session RTCP-Pakete mit Feedback uber erhaltene Daten und Benutzerin formationen. RTCP dient auerdem der Aushandlung und Einhaltung von Qualityof-Service-Parametern (QoS) durch den periodischen Austausch von Steuernachrichten zwischen Sender und Empfnger. Diese Einhaltung von QoS bedeutet, a dass der Server eine Rckmeldung vom Client mit Informationen uber bisherige u Qualitt des Streams erhlt. Daraus kann eine Anpassung der Ubertragungsrate a a erfolgen. Der Austausch von Steuernachrichten dient des Weiteren der Identikation aller Sitzungsteilnehmer.
66
7 Streaming
Real-Time Streaming Protocol (RTSP) RTSP wurde konzipiert um mit RTP zusammenzuarbeiten. Es dient der Steuerung der kontinuierlichen Ubertragung von audiovisuellen Daten (Streams) und basiert auf HTTP. Die Arbeitsweise des Protokolls ist bidirektional. Das heit, sowohl Server als auch Client knnen Anfragen uber bestimmte Daten absetzen. RTSP o dient hauptschlich der Steuerung von Datenstrmen (siehe Abbildung 7.4), wobei a o keine Nutzdaten Ubertragen werden. Durch RTSP ist es mglich den Stream voro und zurckzuspulen, sowie zu pausieren. u
Abbildung 7.4: Beispiel fr die Arbeitsweise von RTSP u
7.3.4
Verteilstrategien
Broadcast Der Begri Broadcast (breit = breit, cast = werfen,streuen) beschreibt in der Informationstechnik die ungezielte Verbreitung von Informationen in der Flche. a Rundfunk uber Satellit ist das klassische Beispiel fr die Ausstrahlung von u Informationen von einem Sender an viele Empfnger. Die Empfnger haben dabei a a keinen Einuss auf die Prsentation des Informationsangebots durch den Sender. a Sie knnen nur das empfangen, was gerade ausgestrahlt wird. o Unicast Computernetzwerke bieten im Gegensatz zur Ausstrahlung uber Funkfrequenzen individuelle, bidirektionale Kanle (sog. Punkt-zu-Punkt)-Verbindungen oder a point-to-point) zu jedem angeschlossenen Empfnger. Seit die Leistungsfhigkeit a a digitaler Ubertragungswege und Endgerte nicht nur in Firmen, sondern auch in a Privathaushalten zur Verarbeitung von digitalisierten Audio- und Videosignalen ausreicht, werden sie zunehmend von Rundfunkanstalten als Alternative zur klassischen Programmverteilung genutzt.
7.3 Technologie
67
Der Unicast-Datentransport hat jedoch einen erheblichen Nachteil. Da bei tausenden gleichzeitigen Anfragen auch tausend logische Punkt-zu-PunktVerbindungen zum Server aufgebaut werden (siehe Abbildung 7.5) alle Verbindungspfeile konzentrieren sich am Server), wird die am Server zur Verfgung u stehende Bandbreite schnell aufgebraucht. Ublicherweise ist die Netzanbindung eines Internetservers daher der erste begrenzende Leistungsfaktor. Ein Beispiel fr die Verbreitung uber Unicast ist das streaming eines Weu bradios. Multicast Dieser von Steve Deering u.a. beschriebene Ansatz sieht vor, dass den Netzwerk Routern die Entscheidung Uberlassen wird, wann ein AV-Streaming- Paket gesplittet wird und wann nicht. Damit wird ein Groteil der Intelligenz, die normalerweise nur zwischen Client und Server ausgehandelt wird, nunmehr ins Netz Ubertragen. Dies hat vor allem den Vorteil, dass vorhandene Router-Hardware benutzt werden kann und kein neuer Server gekauft werden muss.
Abbildung 7.5: Unterschied zwischen den Verteilstrategien Unicast und Multicast
Beim Multicast-Transport wird das Live-Signal nicht an eine IP-Adresse geschickt, die auf einen Rechner bezogen wird, sondern an eine IP-Adresse, die fr eine ganze u Gruppe von Rechnern stehen kann (siehe Abbildung 7.5). Der IP-Adressraum besitzt einen speziell fr diesen Fall reservierten Adressbereich, und die zugehrigen u o IP-Adressen werden als Multicast-Adressen bezeichnet. Whrend man normalera weise eine IP-Adresse direkt mit dem Rechner identizieren kann, beschreibt eine Multicast-Adresse demnach das zum jeweiligen Zeitpunkt eingeloggte Auditorium. Wird ein Live-Signal nun an eine Multicast-Adresse geschickt, so muss jeder Multicast-Router im Netz immer wieder befragt werden, ob die Weiterverteilung der Pakete in seinem Segment Uberhaupt Sinn macht. Dabei prft der intelligente u
68
7 Streaming
(multicast-fhige) Router im Netz, ob fr ein am Server anliegendes Live-Signal a u in seiner Umgebung Interesse besteht. Sobald ein Client in seiner Umgebung das Live-Signal empfangen mchte, baut der Router zum nchstgelegenen (multicasto a fhigen) Router eine Verbindung auf, um schlielich das Live-Signal verteilen zu a knnen. Da sich nur der Router, der einem oder mehreren Clients am nchsten o a steht, wie ein Splitter verhlt, wird bei dieser Art des Datenaustauschs die zur a Verfgung stehende Bandbreite am sparsamsten ausgenutzt. Der groe Nachteil u dieser netzwerknahen Lsung besteht darin, dass das bestehende Backbone-Netz o aus Grnden der Fehleranflligkeit und Kosten nicht multicast-fhig ist. Dennoch u a a fr IP-TV verwendet da Internet-Service-Provider innerhalb ihres Verteilnetzes u fr Kompatibilitt sorgen. Eine Vergleich der genannten Verteilstrategien ist in u a Abbildung 7.6 dargestellt.
Abbildung 7.6: Vergleich der Verteilungsstrategien Unicast, Multicast und Broadcast
Splitting Die Idee des Splitting drngt sich fr Live-Sendungen auf, wenn ein greres a u o Zuschauerpotenzial in den USA uber eine schlecht angebundene transatlantische Verbindung Inhalte abrufen mchte, die im deutschen Internet-Backbone angeboo ten werden. Warum sollten 5000 Amerikaner, die das gleiche Live-Event verfolgen mchten, 5000 parallele Verbindungen nach Deutschland aufbauen, wenn es doch o ausreichen wrde, das Signal nur einmal nach Amerika zu ubertragen und erst dort u 5000-mal zu splitten. Das Splitting fr AV-Server wurde im Internet in Ermangeu lung weitchiger Verfgbarkeit von IP-Multicast zum ersten Mal in Deutschland a u durch die GMD-Projektgruppe PersonalR@dio angewandt. Durch den Einsatz von Splittern spart man also Bandbreite beim Ausgangsserver. Zustzlich ermglicht a o das Splitting durch intelligente Kaskadierung auch die Einsparung von Encodern durch die Vervielfachung mehrerer Encoder-Strme in verschiedene Netze (siehe o Abbildung 7.7).
7.4 Fazit
69
Abbildung 7.7: Beispiel fr die Verteilstrategie Splitting u
7.4
Fazit
Die Technik des Streamings hat sich im Internet bereits weitgehend etabliert. Anwendungsbeispiele sind Webradio, IP-TV, Internet-TV u.a. Ohne Streaming knnten diese Services gar nicht realisiert werden. o Eine entscheidende Rolle wird die Technik auch in der Zukunft spielen, da immer verstrkter eine bestimmte Servicequalitt gefordert wird, auch Qualitya a of-Service (QoS) genannt. Beruhend auf diesen Uberlegungen kann man davon ausgehen, dass die Bedeutung der Streaming-Technik weiterhin steigen wird. Ein Nachteil ist die fehlende Umsetzung von Protokollen zur Ressourchenreservierung oder dem Multicastverfahren fr das globale Internet. Hier sollten u die Netzbetreiber nachbessern um die Streaming-Technik ezienter ausnutzen.
[1] Hendrich, N. (07.02.2001): Streaming, Abgerufen am 12.12.2011 von http://tams-www.informatik.unihamburg.de/lehre/2000ws/vorlesung/audioverarbeitung/09streaming.pdf Ning, C. (13.02.2006): Ausarbeitung RealVideo, Universitt Osnabrck a u Homrighausen, M. (2005): Streaming Media Ubertragung von audiovisuellen Daten im Internet Wegner, B. (2000): Streaming Media im Business-Bereich, AddisonWesley Verlag, Gersthofen 2000
[2] [3] [4]
70
7 Streaming
Verteilte Transaktionen
Christian Reibeholz
Inhaltsverzeichnis
8.1 8.2 8.3 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . Verteilte Datenbanksysteme . . . . . . . . . . . . . . . 8.2.1 Partitionierung . . . . . . . . . . . . . . . . . . Transaktionen in verteilten DBS . . . . . . . . . . . . . 8.3.1 ACID-Prinzip . . . . . . . . . . . . . . . . . . . 8.3.2 Zwei-Phasen-Sperrprotokoll . . . . . . . . . . . 8.3.3 Commit-Behandlung . . . . . . . . . . . . . . . 8.3.4 Commit-Strukturen bei verteilten Transaktionen Zwei-Phasen-Freigabe . . . . . . . . . . . . . . . . . . 8.4.1 Zentralisierte Zwei-Phasen-Freigabe . . . . . . . 8.4.2 Lineare Zwei-Phasen-Freigabe . . . . . . . . . . 8.4.3 Hierarchische Zwei-Phasen-Freigabe . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 71 71 74 74 74 75 76 77 78 78 79 80
8.4
8.5
8.1
Einleitung
Eine elektronische Speicherung von Daten ist heutzutage in vielen Bereichen unabdingbar. Fast uberall wo Verwaltungsarbeiten anfallen, sind Datenbanksysteme im Einsatz, um Daten vor allem dauerhaft zu speichern. Die auf Datenbanksystemen durchgefhrten Transaktionen sind Thema dieser Arbeit. Vor allem wird sich u nher mit dem Begri der Verteilten Transaktionen befasst und versucht dabei a die grundstzlichen Unterschiede gegenber normalen (zentralisierten) Transaka u tionen deutlich zu machen. Ziel dieser Arbeit ist es die theoretischen Grundlagen nher zu beschreiben, wozu Mglichkeiten der Partitionierung, das Sperren und a o Freigeben von Datenbestnden, sowie verschiedene Sperrfreigabemechanismen ina nerhalb unterschiedlicher Commit-Struktur zhlen. a
72
8 Verteilte Transaktionen
8.2
Verteilte Datenbanksysteme
Regulre Datenbanksysteme sind zentralisiert, was bedeutet dass sich der Daa tenbankenserver nur an einem bestimmten, zentralen Ort bendet. Es existieren jedoch beispielsweise Firmen, welche aus mehreren Zweigstellen aufgebaut sind und ggf. Kundendaten fr jede dieser Zweigstellen, innerhalb einer Datenbank, u verwaltet mssen. In einem solchen Fall wre es sinnvoll, die jeweiligen Daten u a nicht nur an einem zentralen Ort zu hinterlegen, da Zugrie von auerhalb uber eine lange Leitung erfolgen, was ungewollte Verzgerungen zur Folge haben kann. o Aus eben diesen Grund bietet es sich an ein verteiltes Datenbanksystem aufzusetzen, welches von beliebig vielen, dezentralisierten Rechnern betrieben wird, wobei sich die Rechner an vllig verschiedenen Orten benden knnen. o o
Abbildung 8.1: Verteiltes Datenbanksystem
8.2.1
Partitionierung
Unter einer Partitionierung versteht man die Aufteilung eines zentralen Datenbestandes (z.B. Tabelle fr Bestellungen eines Internetshops) auf mehr als ein u Rechnersystem. Dabei kann die Partitionierung eines Datenbanksystems auf zwei Arten erfolgen, der horizontalen, sowie der vertikalen Partitionierung. Dazu betrachten wir uns eine Beispieltabelle, welche Buchungen fr Flge innerhalb eines u u Flugunternehmens speichert. In folgender Abbildung bendet sich der zentrale Datenbestand vorerst in Dsseldorf. u
8.2 Verteilte Datenbanksysteme
73
Abbildung 8.2: Zentraler Datenbestand in Dsseldorf u
Horizontale Partitionierung Bei der horizontalen Partitionierung wird die Tabelle zeilenweise zerlegt. Das bedeutet dass wir die Tabelle horizontal so aufteilen, dass die jeweiligen Daten hinterher auf den lokalen DB-Servern der Orte liegen, an denen die entsprechenden Flge tatschlich gebucht wurden. Das bringt den Vorteil mit sich dass lokale Dau a ten besser und schneller verarbeitet werden knnen bzw. Zugrie (lesen,schreiben) o schneller erfolgen. Htten wir fr unseren Flughafen Zweigstellen in Erfurt und a u Frankfurt, welche jeweils eigene, lokale Flge zu verwalten htten, so wrde eine u a u horizontale Partitionierung also durchaus Sinn machen.
Abbildung 8.3: Horizontal verteilte Tabelle: Flugbuchungen
Vertikale Partitionierung Wenn eine vertikale Partitionierung vorgenommen wird, ndet eine spaltenweise Zerlegung der Tabelle statt. Das wre beispielsweise dann von Vorteil, wenn wir a innerhalb eines Ortes, aber in unterschiedlichen Abteilungen, verschiedene Spalten
74
einer Tabelle bentigten. So wrde beispielsweise eine Abteilung Ticketverwalo u tung die Flugnummern, Ticketnummern und die Buchungsdaten lokal verwalten, wobei die Abteilung Platzreservierung die Ticket- und Platznummern bekme. a Wichtig ist es hier vor allem weiterhin eine Beziehung zwischen beiden Fragmenten herstellen zu knnen. Dazu muss ein eindeutiges Attribut als Fremdschlssel o u festgelegt werden. Im unteren Beispiel haben wir uns fr das Attribut Ticketu nummer entschieden.
Abbildung 8.4: Vertikal verteilte Tabelle: Flugbuchungen
8.3
Transaktionen in verteilten DBS
Eine verteilte Transaktion durchluft in der Regel drei Phasen. Ersa tens mit dem Beginn der Transaktion, zweitens den darauolgenden DBOperationen(lesen,schreiben) und drittens einem erfolgreichen Abschluss, Abort1 oder einem Rollback2 der gesamten Transaktion.
8.3.1
ACID-Prinzip
Das ACID-Prinzip fasst vier Regeln zusammen, welche an Transaktionen innerhalb eines DBS gestellt werden. Diese Regeln sind immer einzuhalten. Atomaritt: Eine Transaktion muss ganz oder gar nicht durchgefhrt werden a u und darf whrend ihrer Durchfhrung nach auen fr niemanden sichtbar sein. a u u Konsistenz: Nach einer erfolgreichen Transaktion muss sich die Datenbank wieder in einem konsistenten Zustand benden. Isolation: Alle Aktionen innerhalb einer Transaktion mssen vor anderen, paru allel ablaufenden Transaktionen, verborgen bleiben. Die Transaktionen drfen u
1 2
Abbruch der gesamten Transaktion Rckfhrung des Datenbestandes in einen konsistenten Zustand(Ausgangszustand) u u
8.3 Transaktionen in verteilten DBS
75
sich nicht gegenseitig beeinussen. Dauerhaftigkeit: Durch abgeschlossene Transaktionen vorgenommene Anderungen mssen dauerhaft erhalten bleiben und drfen nur durch u u darauolgende Transaktionen beeinusst werden.
8.3.2
Zwei-Phasen-Sperrprotokoll
Da eine Transaktion nicht durch andere, parallel ablaufende, Transaktionen behindert werden darf, mssen immer Sperren gesetzt werden. Alle fr die Transaktion u u bentigten Objekte werden somit fr die Zeitdauer der Transaktion fr parallel o u u ablaufende Transaktionen unzugnglich gemacht, um somit fehlerhafte und inkona sistente Zustnde zu unterbinden. Somit werden vor dem Beginn der Transaktion a alle Sperren angefordert und nach dem Abschluss, Abort oder Rollback wieder freigegeben. Man spricht hier auch von einem Zwei-Phasen-Sperrprotokoll, welches vor einer Transaktion alle bentigten Sperren erhebt (Wachstumsphase) und o diese nach Ablauf der Transaktionen wieder freigibt (Schrumpfungsphase). Die folgende Grak macht dies deutlich.
Abbildung 8.5: Ablauf des Zwei-Phasen-Sperrprotokolls
Falls eine weitere Transaktion zum gleichen Zeitpunkt auf die gesperrten Daten zugreifen mchte, kann es zu einen Deadlock3 kommen. Um das zu unterbinden o werden diesbezglich Timeouts gesetzt, die dafr sorgen dass wenn nach einer u u bestimmten Zeit keine Rckmeldung erfolgt, die Transaktion abgebrochen wird. u
8.3.3
Commit-Behandlung
Im folgenden geht es um die Commit4 -Behandlung, welche die zweite Phase des Zwei-Phasen-Sperrprotokolls reprsentiert und deren Unterscheidung in zentralia
3
Bezeichnet einen Zustand, bei dem ein oder mehrere Prozesse auf Betriebsmittel warten, die dem Prozess selbst oder einem anderen beteiligten Prozess zugeteilt sind 4 Bezeichnet bei Datenbanken den erfolgreichen Abschluss einer Transaktion. Das Ergebnis der Verarbeitungsschritte wird dauerhaft gespeichert, in der Regel durch den SQL-Befehl Commit
76
sierten und verteilten Systemen. Dabei kommt es zum Austausch von speziellen Nachrichten und es werden Images (after-Images, before-Images) angelegt, die den Zustand vor, sowie nach jeder Transaktion kennzeichnen. Zentralisiertes System Das Ende einer Transaktion luft immer in zwei Phasen ab. In der ersten Phase a werden smtliche Anderungen protokolliert und ein sogenanntes after-Image era stellt und ein Commit-Satz in die Protokolldatei der Datenbanksystems geschrieben. Nach dem erfolgreichen Durchlauf von Phase eins ist somit, im Falle eines Ausfalls, eine Wiederholung der Transaktion mithilfe der after-Images mglich. In o der zweiten Phase werden die gesetzten Sperren aufgehoben und alle Anderungen sichtbar gemacht. Dazu werden alle vorhergehenden Anderungen (befor-Images) gelscht. Kommt es wrend der ersten Phase zu einem Ausfall, so wird die Transo a aktion vollstndig zurckgesetzt und die before-Images werden geladen. a u Verteiltes System Der Ablauf in einem verteilten System erfolgt ebenfalls in zwei Phasen (ZweiPhasen-Freigabe). Doch muss in einem Verteilten System aufgrund mehrerer Teilknoten eine entsprechende Koordination stattnden. Es mssen sich alle an der u Transaktion beteiligten Knoten auf ein gemeinsames Commit-Ergebnis einigen. Das bedeutet dass es entweder in allen Knoten zu einem Commit, oder zu einem Abort kommt. Daher existieren in verteilten Systemen drei spezielle Knotentypen. Der Transaktionsmanager, der Commit-Koordinator und die Agenten. Transaktionsmanager: Der Transaktionsmanager ist in jedem Knoten fr die u lokal ausgefhrten Teiltransaktionen verantwortlich und kommuniziert mit den u jeweiligen, ihm untergeordneten Knoten (Agenten). Commit-Koordinator: Legt das globale Commit-Ergebnis im obersten Knoten fest, sobald alle Teiltransaktionen der beteiligten Transaktionsmanager abgeschlossen sind. Es wird eine Mitteilung an alle beteiligten Knoten gesendet. Daraufhin wird entschieden ob es zu einen Commit oder Abort kommt. Es steht jedem Knoten bis zum Ende das Recht zu, die gesamte Transaktion zu abzubrechen, indem er es dem Commit-Koordinator mitteilt. Agent: Agenten sind alle Knoten, in denen Teiltransaktionen ausgefhrt weru den. Jeder Agent ist ein potentieller Transaktionsmanager, sofern ihm ebenfalls weitere Knoten (Agenten) unterstellt sind.
8.3 Transaktionen in verteilten DBS
77
8.3.4
Commit-Strukturen bei verteilten Transaktionen
Das Netzwerk eines verteilten DB-Systems kann verschieden strukturiert sein. Entsprechend seiner Strukturierung folgt es einer anderen Commit-Struktur. Es existieren zentralisierte, lineare und hierarchische Modelle. Zentralisierte Commit-Struktur Die zentralisierte Commit-Struktur entspricht einer Baumstruktur mit zwei Hierarchieebenen, eine fr den Koordinator und eine in welcher sich die dem Koordinator u untergeordneten Agenten benden. Da die Commit-Behandlung parallel mglich o ist, beschrnkt sich die Dauer einer solchen Transaktion auf die Teiltransaktionen a des langsamsten Agenten.
Abbildung 8.6: Zentralisierte Commit-Struktur
Lineare Commit-Struktur Hier ndet ein iterativer Austausch von Nachrichten statt. Die Dauer einer solchen Transaktion ist somit gewissermaen von der Anzahl der Agenten abhngig. a Dennoch ist die lineare Commit-Behandlung die einzige in welcher Nachrichten eingespart werden knnen, da keine Prepared Nachrichten notwendig sind und o das Finished(siehe Kapitel 4.2) am ende nur einmal gesendet werden muss.
Abbildung 8.7: Lineare Commit-Struktur
Hierarchische Commit-Struktur Hierbei handelt es sich um eine Baumstruktur mit beliebig vielen Hierarchieebenen, an deren Knotenpunkten die jeweiligen Transaktionsmanager auf die Subtransaktionen ihrer Agenten warten. Sobald die Subtransaktionen an einem Teil-
78
baum abgeschlossen sind, werden die Transaktionsmanager ebenfalls zu Agenten, wobei sie die bisherig ubermittelten Nachrichten ebenfalls an den ubergeordneten Transaktionsmanager weitergeben.
Abbildung 8.8: Hierarchische Commit-Struktur
8.4
Zwei-Phasen-Freigabe
Die Sperrfreigabe nach einer verteilten Transaktion, zwischen einem Koordinator und seinen Agenten, ndet immer in zwei Phasen statt. Innerhalb der Phasen kommt es zwischen den verschiedenen Knotentypen zum Austausch spezieller Nachrichten. Dafr sind innerhalb der verschiedenen Commit-Strukturen unteru schiedliche Ablaufmodelle vorzunden.
8.4.1
Phase 1
Zentralisierte Zwei-Phasen-Freigabe
Zu Beginn der ersten Phase sendet der Koordinator eine Prepare-Nachricht an alle an der Transaktion beteiligten Agenten. Sind die Agenten einverstanden ubermitteln sie dem Koordinator eine Ready-Nachricht. Ist die Teiltransaktion jedoch nur seitens eines Agenten fehlgeschlagen, so wird vom entsprechenden Agenten eine Failed-Nachricht an den Koordinator ubermittelt. Phase 2 Zu Beginn von Phase zwei hat der Koordinator alle angeforderten CommitErgebnisse seiner Agenten erhalten. Daraufhin sendet er ein globale Nachricht an alle beteiligten Agenten. Je nachdem ob alle Agenten in Phase eins mit einen Ready oder Failed geantwortet haben, enthlt diese globale Nachricht einen a Commit- oder einen Abort-Befehl. Im Falle eines globalen Commits seitens des Koordinators, wird ein entsprechender Commit-Satz in die Protokolldatei der Agenten geschrieben und die von ihnen belegten Sperren werden freigegeben. Im Falle eines globalen Aborts werden die entsprechenden Sub-Transaktion
8.4 Zwei-Phasen-Freigabe
79
zurckgesetzt, indem die before-Images geladen werden und ein Abort-Satz wird u in die Protokolldatei aller Agenten geschrieben. Zuletzt senden alle Agenten an den Koordinator eine Finished-Nachricht und die Transaktion gilt als beendet.
Abbildung 8.9: Zentralisierte Zwei-Phsaen-Freigabe
8.4.2
Lineare Zwei-Phasen-Freigabe
Einer lineare Commit-Struktur besitzt einen weiteren Knotentyp, den InitiatorKnoten. Phase 1 Der Initiator versetzt sich selbst in den Zustand Prepared und sendet ein Rea dy an den ersten Agenten. Der erste Agent bringt sich nach Erhalt der Nachricht ebenfalls in den Zustand Prepared und gibt sein Ready/Failed(je nach lokaler Entscheidung) an den nchsten Agenten weiter, bis der letzte Agent, welcher hier a als Koordinator agiert, die globale Nachricht erhalten hat. Phase 2 Nach Erhalt der Ready/Failed-Nachricht sendet der Koordinator eine Com mit/Abort-Nachricht in umgekehrter Reihenfolge an alle Agenten, inklusive dem Initiator, zurck. In allen Agenten erfolgt eine Protokollierung, worauf die Sperren u freigegeben werden. Der Initiator sendet anschlieend eine Finished-Nachricht an den Koordinator, welcher diese daraufhin protokolliert. Danach gilt die Transaktion als beendet. Durch den Wegfall der Prepared- und Finished-Nachrichten, werden Nachrichten eingespart, jedoch kann es durch die Erhhung der Agenteno anzahl auch zu einer signikanten Erhhung von Antwortzeiten kommen. o
80
Abbildung 8.10: Lineare Zwei-Phasen-Freigabe
8.4.3
Phase 1
Hierarchische Zwei-Phasen-Freigabe
Prepared-Nachricht wird vom Koordinator an seinen gesamten Teilbaum ver sendet. Sendet kein Agent ein Failed, so wird die Prepared-Nachricht an den darunterliegenden Teilbaum weiter versandt. Sendet jedoch nur ein Agent Fai led, so werden Failed-Nachrichten an alle Vorgnger und Abort-Nachrichten a an alle Nachfolger versendet. Phase 2 Nachdem der Koordinator Ready/Failed erhalten hat, sendet er im Falle eines Ready eine Commit-Nachricht an alle Nachfolger. Im Falle eines empfange nen Failed sendet er eine Abort-Nachricht an alle. Im Falle einer Commit Nachricht gibt ein Agent seine Sperren frei und protokolliert das Commit in der Protokolldatei. Daraufhin gibt er die Commit-Nachricht an seine Nachfolger weiter. Im Falle einer Abort-Nachricht werden ebenfalls alle Sperren freigege ben und das Abort in die Protokolldatei geschrieben. Die Nachricht wird auch hier an alle nachfolgenden Agenten weitergeleitet. Zum Schluss senden die Agenten das Finished in umgekehrter Reihenfolge an ihre Vorgnger. Nachdem der a Koordinator die Finished-Nachricht erhalten hat, wird diese von ihm protokol liert und die Transaktion gilt als beendet.
8.5
Fazit
Es ist zu erkennen das verteilte Transaktionen einige Vorteile bieten. Gerade die lokale Datenhaltung spricht fr eine solches Konzept. Jedoch muss beachtet weru den das verteilte Transaktionen weitaus komplexer und dadurch auch um einiges Fehleranflliger sind. Gerade durch die komplizierten Sperrfreigabeverfahren der a jeweiligen Commit-Strukturen wird dies kenntlich gemacht. Zudem kann es durch die Kommunikation uber das Netz immer und uberall zu Problemen kommen, z.B. durch den Ausfall eines Rechnerknotens oder gar einer Leitung, oder sei es nur durch eine allgemeine uberlast. So ist das Anlegen und Verwalten von Image
81
Abbildung 8.11: Hierarchische Zwei-Phasen-Freigabe
Dateien auf allen Knoten von grter Wichtigkeit, um ggf. Fehler zu korrigieren o und Datenbestnde dauerhaft konsistent zu halten. a
[1] Gnther Bengel, Grundkurs Verteilte Systeme: Grundlagen und Praxis des u Client-Server-Computing - Inklusive aktueller Technologien wie Web-Services u. a. - Fr Studenten und Praktiker, 3. Auage, 24. Februar 2004 u [2] Harm Knolle, Vertiefung Datenbanken: Datenbanken in Client / Server Systemen, 11. November 2010

Verteilte Systeme 2011

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Verteilte Systeme 2011

Hochgeladen von

Copyright:

Verfügbare Formate

Verteilte Systeme

Oliver BRAUN (Hrsg.)

Fakultt Informatik a Fachhochschule Schmalkalden

Fehlertoleranz in verteilten Systemen

1 Fehlertoleranz in verteilten Systemen

Fehlermaskierung durch Redundanz

1 Fehlertoleranz in verteilten Systemen

Abbildung 1.1: Kommunikation in Prozessgruppen

Fehlermaskierung und Replikation

1 Fehlertoleranz in verteilten Systemen

RPC-Semantik beim Vorliegen von Fehlern

Client ndet Server nicht

1.3 RPC-Semantik beim Vorliegen von Fehlern

Abbildung 1.2: Server-Absturz in der Client-Server-Kommunikation

1 Fehlertoleranz in verteilten Systemen

Abbildung 1.3: Unterschiedliche Kombinationen von Client-/Server-Strategien bei Server-Absturz

1 Fehlertoleranz in verteilten Systemen

Abbildung 1.4: Suche nach dem Wiederherstellungsverlauf von zwei Prozessen

Das Google File System

Vgl. LivingLogic, Suchmaschinen-Optimierung fr Google ohne Tricks u

2 Das Google File System

Design des GFS

2.2 Design des GFS

Architektur des GFS

2 Das Google File System

2.2 Design des GFS

2 Das Google File System

Systeminteraktionen des GFS

2.3 Systeminteraktionen des GFS

2 Das Google File System

Verteilung, Erstellung und Reproduktion von Kopien

2.5 Fehlertoleranz, Zuverlssigkeit und Verfgbarkeit a u

Fehlertoleranz, Zuverlssigkeit und a Verfgbarkeit u

2 Das Google File System

2 Das Google File System

3.2 Verteilte Multimediasysteme

Streaming Video und Audio

Abbildung 3.1: Streaming uber einen Webserver [4]

3.2 Verteilte Multimediasysteme

Abbildung 3.2: Streaming uber einen Streamingserver [5]

Interaktives Video und Audio in Echtzeit

Zuknftige Weiterentwicklungen im Internet zur u Ubertragung Multimedialer Anwendungen

3.2 Verteilte Multimediasysteme

Abbildung 3.3: Ursprungsserver ubertrgt Inhalte an CDN Verteilerknoten [6] a

Einfhrung zum Thema - Taktfrequenzen u stagnieren

4.2 OpenCL - Hintergrund

4.4 OpenCL - Aufbau/Architektur

Abbildung 4.2: Plattform-Modell einer OpenCL Anwendung[6]

4.4 OpenCL - Aufbau/Architektur

Abbildung 4.3: OpenCL Speicher Modell[7]

4.5 OpenCL C und Besonderheiten

OpenCL C und Besonderheiten

[6] Abb. 2, http://upload.wikimedia.org/wikipedia/de/thumb/9/96/Platform architectu 11-08.svg/800px-Platform architecture 2009-11-08.svg.png, abgerufen am 13.01.2012

[7] Abb. 3, http://upload.wikimedia.org/wikipedia/de/d/d1/OpenCL Memory model.sv abgerufen am 13.01.2012

6.5 6.6 6.7 6.8

6 Sicherheit in verteilten Systemen

6 Sicherheit in verteilten Systemen

6.4 Vertrauenswrdiges System u

6 Sicherheit in verteilten Systemen

6.5 Secure Sockets Layer

Abbildung 6.1: Aufbau Kerberos

Secure Sockets Layer

6 Sicherheit in verteilten Systemen

Abbildung 6.2: SSL Handshake