Verteilte Systeme

Oliver BRAUN (Hrsg.)

Fakult¨t 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 J¨ger a 5 Peer-to-Peer-Systeme . . . . . . . . . . . . . . . . . . . . . . . . Tim Achtert 6 Sicherheit in verteilten Systemen . . . . . . . . . . . . . . . . . . Mario F¨hr o 7 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markus Schramm 8 Verteilte Transaktionen . . . . . . . . . . . . . . . . . . . . . . . Christian Reibeholz

11

23

35

47

49

61

71

IV

Inhaltsverzeichnis

1

Fehlertoleranz in verteilten Systemen

Ricardo Hohmann

Inhaltsverzeichnis
1.1 Grundlagen . . . . . . . . . . . . . . . . . 1.1.1 Definition . . . . . . . . . . . . . . 1.1.2 Grundlegende Konzepte . . . . . . 1.1.3 Fehlermodelle . . . . . . . . . . . 1.1.4 Fehlermaskierung durch Redundanz Prozesselastizit¨t . . . . . . . . . . . . . . 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 findet 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 Einf¨hrung . . . . . . . . . . . . . u 1.4.2 Pr¨fpunkte . . . . . . . . . . . . . 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 f¨r verteilte Systeme ist der partielle Ausfall. Dieser tritt auf, u wenn eine Komponente in einem verteilten System ausf¨llt. Andere Komponenten a k¨nnen 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 Ausf¨llen automatisch wiederhergestellt werden kann a und auch bei auftretenden Fehlern weiterhin funktionsf¨hig bleibt. a Was es f¨r ein verteiltes System bedeutet, fehlertolerant zu sein und wie eben u dies umgesetzt werden kann, wird auf den folgenden Seiten beschrieben.

2

1 Fehlertoleranz in verteilten Systemen

1.1

Grundlagen

In diesem Kapitel werden Begriffe erl¨utert, die f¨r das Verst¨ndnis fehlertolerana u a ter Systeme notwendig sind.

1.1.1

Definition

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 Verl¨sslichkeit. Diese deckt vier praktische Anforderungen ab, die an a verteilte Systemen gestellt werden. Verf¨gbarkeit ist die Eigenschaft, dass ein System unmittelbar zur Nutzung beu reitsteht, wenn ein Zugriff erfolgt. Im Allgemeinen dr¨ck die Verf¨gbarkeit u u die Wahrscheinlichkeit aus, dass ein System zu einer bestimmten Zeit zur Verf¨gung steht und funktioniert. u Zuverl¨ssigkeit ist die Eigenschaft, dass ein System fortlaufend fehlerfrei ausa gef¨hrt werden kann. Dabei bezieht sich die Zuverl¨ssigkeit auf einen zusamu a menh¨ngenden Zeitintervall, w¨hrend die Verf¨gbarkeit sich auf Zeitpunkt a a u bezieht. Sicherheit ist die Eigenschaft, die besagt, dass nichts katastrophales passieren darf, wenn ein System vor¨bergehend 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 M¨glichkeiten der Klassifikation von Fehlern in verteilten Syso temen. Folgend sind Fehler nach chronologischen Aspekten klassifiziert, w¨hrend a im n¨chsten Kapitel 1.1.3 Fehler nach ihrem Typ klassifiziert werden. a Vor¨bergehende Fehler treten einmalig auf. Bei Wiederholung der Operatiu on tritt kein Fehler mehr auf. Derartige Fehler k¨nnen auftreten, wenn o ¨ Ubertragungswege gest¨rt werden. o

1.1 Grundlagen

3

Periodischer Fehler treten mehrfach auf, ohne dass sich ein Muster abzeichnet. Diese Fehler sind schwierig zu Diagnostizieren. M¨gliche 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 m¨glich. o

1.1.3

Fehlermodelle

Die folgende Auflistung soll ein Gef¨hl daf¨r 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 erh¨lt keine eingehenden Anforderungen. a Sendeauslassung: Ein Server sendet keine Nachrichten. Timing-Fehler: Die Antwortzeit eines Servers liegt außerhalb eines festgelegten Zeitintervalls. Antwortfehler: Die Antwort des Servers ist falsch. Wertfehler: Der Wert der Antwort ist falsch. Status¨bergangsfehler: Der Server weicht vom korrekten Steuerfluss ab. u Zuf¨llige Fehler: Ein Server erzeugt zu zuf¨lligen Zeiten zuf¨llige Antworten. a a a Die zuf¨lligen Fehler sind am schwierigsten zu beheben. Sie werden auch Bya ” zantinische Fehler1“genannt. 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 Begriff byzantinisch“bezieht sich auf das byzantinische Reich, Zeit (330 - 1435) und Ort ” (der Balkan und die heutige T¨rkei) endloser Verschw¨rungen und Intrigen, die in Herrscheru o kreisen als ublich galten. ¨

4

1 Fehlertoleranz in verteilten Systemen

Informationsredundanz: Durch das Hinzuf¨gen von Pr¨fbits wird die Herstelu u lung von Daten erm¨glicht. o zeitliche Redundanz: Eine Aktion wird ausgef¨hrt und ggf. wiederholt. Ein Beiu spiel ist die Verwendung von Transaktionen. Besonders praktisch ist diese Form der Redundanz bei vor¨bergehenden 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

Prozesselastizit¨t 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 befinden, empfangen die Nachrichten, die an die Gruppe gesendet werden. Wenn ein Prozess fehlerhaft ist, so kann ein anderer Prozess seine Arbeit ubernehmen. ¨ Die Prozessgruppen k¨nnen dynamisch sein. Neue Gruppen k¨nnen erzeugt oder o o alte zerst¨rt werden. Weiterhin ist es jederzeit m¨glich, dass Prozesse Gruppen o o beitreten oder sie verlassen. Ein Prozess kann in mehreren Gruppen gleichzeitig sein. Ein m¨glicher Ansatz zur Verwaltung der Gruppen und Prozesse ist die o Verwendung eines Gruppenservers. Weiterhin lassen sich die Prozessgruppen in flache und hierarchische Gruppen einteilen (siehe Abbildung 1.1). In der flachen Gruppe (a) sind alle Prozesse identisch. Entscheidungen werden gemeinsam getroffen 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 flachen Gruppe liegt darin, dass sie keinen Ausfallpunkt hat, w¨hrend eine hierarchische Gruppe a nicht mehr weiterarbeiten kann, wenn der Koordinator ausf¨llt. Ein Nachteil eia ner flachen Gruppe ist die komplizierte Entscheidungsfindung per Abstimmung, w¨hrend bei hierarchischen Gruppen Entscheidungen allein durch den Koordinator a getroffen werden k¨nnen. o

1.2 Prozesselastizit¨t a

5

Abbildung 1.1: Kommunikation in Prozessgruppen

1.2.2

Fehlermaskierung und Replikation

Prozessgruppen sind ein Teil der L¨sung zum Aufbau fehlertoleranter Systeme. o Einzelne Prozesse werden repliziert, um einen einzigen (ungesch¨tzten) Prozess u durch eine (fehlertolerante) Gruppe zu ersetzen. Es gibt zwei M¨glichkeiten f¨r o u eine solche Replikation, n¨mlich prim¨rbasierte Protokolle und Protokolle mit a a repliziertem Schreiben. Prim¨rbasierte Protokolle basieren auf hierarchischen Gruppen. Anforderungen a werden an einen prim¨ren Prozess weitergeleitet. F¨llt dieser aus, wird auf einen a a Backup-Prozess zugegriffen, der die Anforderung erf¨llt. u Protokolle mit repliziertem Schreiben basieren auf flachen Gruppen. Anforderungen k¨nnen von jedem der Gruppenmitglieder erf¨llt werden. o u

1.2.3

k-Fehlertoleranz

Die folgenden Ausf¨hrungen beziehen sich auf Systeme mit repliziertem Schreiu ben. Der Wert k“gibt ein Maß an, wie fehlertolerant eine Prozessgruppe ist. ” Er l¨sst 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 funktionsf¨hig. Dies gilt jedoch nicht, wenn die feha lerhaften Prozesse byzantinische Fehler aufweisen. Dann werden 2k+1 Prozesse ben¨tigt, um ein System k-fehlertolerant zu machen. o

6

1 Fehlertoleranz in verteilten Systemen

1.3

RPC-Semantik beim Vorliegen von Fehlern

Nachdem das letzte Kapitel von Fehlern handelt, die bei fehlerhaften Prozessen auftreten k¨nnen, soll es in diesem um den Umgang mit fehlerhafter Kommuo nikation gehen. Ein Kommunikationskanal kann dabei Absturz-, Auslassungs-, Timing- und zuf¨llige Fehler aufweisen. a Bei der Punkt-zu-Punkt-Kommunikation k¨nnen Fehler teilweise durch die o Verwendung eines zuverl¨ssigen Transportprotokolls wie TCP maskiert wera den. So werden Auslassungsfehler mithilfe von Best¨tigungen 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 M¨glichkeit der Maskierung ist die automatische Einricho tung einer neuen Verbindung. Auf einer h¨heren 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 f¨nf Fehlerklassen unterschieden, u die in RPC-Systemen auftreten k¨nnen. Es werden die auftretenden Probleme o und m¨gliche L¨sungen beschrieben. o o 1. Der Client findet den Server nicht 2. Die Anforderungsnachricht vom Client an den Server geht verloren. 3. Der Server st¨rzt ab, nachdem er eine Anforderung empfangen hat. u 4. Die Antwortnachricht vom Server an den Client geht verloren. 5. Der Client st¨rzt ab, nachdem er eine Anforderung gesendet hat. u

1.3.1

Client findet Server nicht

Die Ursache f¨r einen solchen Fehler kann sein, dass der Server nicht mehr l¨uft u a oder sich in Wartung befindet. Auch kann Server-seitig eine neue Schnittstelle installiert worden sein, welche die alte abl¨st und f¨r den Client nicht auffindbar o u ist. Eine m¨gliche L¨sung ist das Werfen einer Ausnahme. Nachteil dieses Ano o satzes ist, dass die Transparenz verloren geht. Ein Fehler wie Kann Server nicht ” finden.“k¨nnte in einem lokalen System gar nicht auftreten. o

1.3.2

Verlorene Anforderungsnachricht

Dieser Fehler ist einfach zu beheben. Eine m¨gliche L¨sung 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

7

gekommen, sendet der Client eine Neuanforderung. Server-seitig treten keine Probleme auf. Nur die Neuanforderung wird vom Server erkannt und entsprechend bearbeitet. Client-seitig k¨nnen Probleme auftreten, die in Kapitel 1.3.4 erkl¨rt 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) findet die normale Ereignisabfolge statt. Eine Anforderung trifft ein, wird ausgef¨hrt, und u eine Antwort wird gesendet. (b) und (c) zeigen Fehlerf¨lle, bei denen der Server a abst¨rzt. Dabei st¨rzt in (b) der Server erst nach Ausf¨hrung der Anforderung ab, u u u w¨hrend er in (c) vor der Ausf¨hrung abst¨rzt. Problematisch ist, dass die korrekte a u u Behandlung des Absturzes sich in beiden F¨llen unterscheidet. In (b) muss das a System den Fehler an den Client zur¨ckmelden, w¨hrend in (c) die Anforderung u a einfach erneut ubertragen werden kann. F¨r den Client gibt es keinen Unterschied u ¨ bei (b) oder (c), er erh¨lt in beiden F¨llen 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 Best¨tigungsnachricht (Message) a an den Client sendet. Nach einem Crash sendet der Server die Nachricht an den Client, dass er abgest¨rzt ist und jetzt wieder l¨uft. u a Der Server kann zwei Strategien verfolgen. Erstens kann er erst den Text drucken (P) und danach die Best¨tigung senden (M). Zweitens kann er aber auch erst a die Best¨tigung senden (M) und danach den Text drucken (P). a Der Client kann vier Strategien verfolgen, wenn er vom Server die Absturznachricht erh¨lt (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 Best¨tigung erhalten hat und viertens kann a er nur dann eine neue Anforderung absetzen, wenn er keine Best¨tigung erhalten a

8

1 Fehlertoleranz in verteilten Systemen

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 f¨r alle m¨glichen Ereignisabfolgen korrekt funktioniert. Der Client kann nie u o wissen, ob der Server nach oder vor Ausdruck des Textes abgest¨rzt 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 k¨nnen, o hat eine Neuanforderung keine negativen Auswirkungen. Eine Anforderung ohne Seiteneffekte, die beliebig oft ausgef¨hrt werden kann, wird auch als idempotent u bezeichnet. Allerdings gibt es auch Anforderungen, die Seiteneffekte hervorru¨ fen. Ein ber¨hmtes Beispiel ist die Uberweisung. Diese darf nur genau einmal u ausgef¨hrt werden. u

1.4 Wiederherstellung

9

Eine m¨gliche L¨sung 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 auszuf¨hren. Zudem kann ein W¨chter verwendet werden, dau a her ein Bit im Nachrichtenheader, das bei einer Neuanforderung gesetzt wird. Die Idee dahinter ist, dass die Ausf¨hrung einer Originalanforderung immer sicher u ist, w¨hrend bei einer Neuanforderung seitens des Servers eine h¨here Sorgfalt a o notwendig ist.

1.3.5

Client-Absturz

Die letzte Fehlerklasse beschreibt einen Client, der abst¨rzt, 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. F¨r den Umgang mit Waisen gibt es die vier M¨glichkeiten u o der Exterminierung, Reinkarnation, gn¨digen Reinkarnation und den Ablauf. Keia ne der genannten M¨glichkeiten ist w¨nschenswert. Besonders kritisch werden o u Waisen, wenn sie Sperren f¨r Dateien oder Datenbanks¨tze angefordert haben, u a die nicht mehr aufgehoben werden k¨nnen. Zudem kann ein Waise bereits meho rere Prozesse in Auftrag gegeben haben, sodass auch ein L¨schung des Waisen o seine Spuren nicht vollst¨ndig verwischt. a

1.4

Wiederherstellung

In diesem Kapitel sollen Verfahren beschrieben werden, die ein System nach einem Fehler wieder in einen korrekten Status uberf¨hren. u ¨

1.4.1

Einf¨hrung u

F¨r die Wiederherstellung eines korrekten Status gibt es zwei M¨glichkeiten. u o Bei der R¨ckw¨rts-Wiederherstellung (Backward Recovery) wird das System u a aus dem aktuellen, fehlerhaften Status in einen vorherigen, korrekten Status uberf¨hrt. Voraussetzung sind Pr¨fpunkte (Checkpoints), welche im folgenden u u ¨ Kapitel 1.4.2 erl¨utert werden. a Bei der Vorw¨rts–Wiederherstellung (Forward Recovery) wird das System aus a dem aktuellen, fehlerhaften Status in einen neuen, korrekten Status uberf¨hrt. u ¨ Voraussetzung ist, dass m¨gliche Fehler vorher bekannt sind. o

10

1 Fehlertoleranz in verteilten Systemen

1.4.2

Pr¨fpunkte u

F¨r die R¨ckw¨rts-Wiederherstellung ist es notwendig, dass das System seinen u u a Status regelm¨ßig in einen stabilen Speicher schreibt. Diese Aufzeichnung von a Pr¨fpunkten kann sehr kostspielig sein und zu Leistungseinbußen f¨hren. 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 regelm¨ßig Pr¨fpunkte erstellt werden. Nun tritt in P2 ein Fehler auf a u und der Wiederherstellungsverlauf soll ermittelt werden. Der letzte Pr¨fpunkt 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 Pr¨fpunkt verwendet weru den. Der vorige Pr¨fpunkt (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.

2

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 Datenfluss . . . . . . . . . . . . . . . . . . . . . 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, Zuverl¨ssigkeit und Verf¨gbarkeit . . . . . 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 B¨rsengang o in 2004 stellt Google eine der bedeutendsten success stories des Internet dar.1 Durch die immer st¨rkere 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 f¨r die Entwicklung neuer Konu zepte, um eine konsistente Datenhaltung und -verwaltung, sowie eine schnelle Datenrettung zu erm¨glichen. Im Mittelpunkt dieser Entwicklung steht die Sio cherung der Performance des Systems, das Milliarden von Dokumenten verwaltet
1

Vgl. LivingLogic, Suchmaschinen-Optimierung f¨r Google ohne Tricks u

12

2 Das Google File System

und mehrere tausende Treffer pro Suchanfrage nach Relevanz ordnet. Der Umfang und die Komplexit¨t 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 gew¨hnlicher PC-Hardware und o sind somit sehr wirtschaftlich im Vergleich zu teurerer Spezialhardware. Durch den Einsatz gew¨hnlicher PC-Hardware sind Ausf¨lle von Festplatten oder ganzer o a Server wesentlich wahrscheinlicher, es wird sogar mit dem Ausfall von Systemen gerechnet. Dass Anwendungen dennoch so zuverl¨ssig 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 ausgef¨hrt werden. Nachteile der Hardwarekonfiguration k¨nnen damit abgefanu o gen werden. Eine weitere strukturelle Besonderheit des GFS stellt die Verwaltung von Schreibzugriffen dar. Bestehende Dateien werden nicht durch schwer zu kontrollierende Schreiboperationen, sondern vielmehr durch leichter zu verwaltende Append-Operationen erweitert. Es ist somit m¨glich, dass viele Nutzer gleichzeitig o auf gr¨ßere Dateien schreibend zugreifen, ohne dass eine st¨ndige Synchronisation o a zwischen diesen Nutzern stattfinden muss. Die vorliegende Arbeit soll einen Einblick in die Funktionsweise und Komplexit¨t des GFS geben sowie die strukturelle Umsetzung der Anforderungen aufa zeigen. Dazu wird im zweiten Kapitel zun¨chst das Design des GFS ausf¨hrlich 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 bez¨glich Fehlertoleranz, Zuverl¨ssigkeit und u a Verf¨gbarkeit werden im f¨nften Kapitel aufgegriffen 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 getroffen, welche die Designentscheidungen leiten, wie auch f¨r das GFS. u Folgende vier Annahmen sind f¨r das GFS essentiell: u 1. Ausf¨lle von Computer-Komponenten sind die Regel. Das Dateisystem a besteht aus tausenden, preiswerten Computern von denen nicht alle durchweg funktionsf¨hig arbeiten k¨nnen und manche nach ihren Ausf¨llen sich a o a

2.2 Design des GFS

13

nicht wiederherstellen lassen. Probleme k¨nnen auftreten bei Anwendungs-, o Betriebssystem und menschlichen Fehlern sowie das Versagen von Festplatten, Speichern, Anschl¨ssen, Netzwerken und Netzger¨ten. Daher ist eine st¨ndige u a a ¨ Uberwachung, Fehlererkennung, Fehlertoleranz und die automatische Wiederherstellung integraler Bestandteil des GFS. 2. Die Dateigr¨ße w¨chst. Jede Datei enth¨lt 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 große Dateien zu verwalten. 3. Die meisten Dateien sind ver¨ndert durch Anh¨ngen neuer Daten ana a ¨ statt dem Uberschreiben vorhandener Daten. 4. Erh¨hung der Flexibilit¨t. Das GFS Konsistenz Modell wurde entspannt, o a um das Dateisystems zu vereinfachen ohne dass es zu Belastungen f¨r die u Anwendungen kommt. Weiterhin wurde eine atomare Append-Operation eingef¨hrt, so dass mehrere Clients gleichzeitig an eine Datei anh¨ngen k¨nnen u a o ohne zus¨tzliche Synchronisation zwischen den Clients. a

2.2.2

Architektur des GFS

Um große Datenmengen zu speichern sowie die Verf¨gbarkeit zu erh¨hen setzt u o Google auf alt bew¨hrte 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 gew¨hnlicher Linux-Server. Die Dateien werden in einzelne Chunks o gesplittet und auf den Chunk-Servern lokal gespeichert. Sie werden in Chunks fester Gr¨ße unterteilt. Jeder Chunk ist identifizierbar durch einen vom Master o unver¨nderlichen 64-Bit-Schl¨ssel, dem Chunk-Handle, der zum Zeitpunkt der Era u stellung zugeordnet wird. Zum Zwecke der Zuverl¨ssigkeit werden Replikationen a jedes Chunks auf mehreren Chunk-Servern gespeichert. Der Master-Server ist f¨r die Organisation aller Metadaten des Dateisystems u zust¨ndig. Dies beinhaltet: die Verwaltung von Namensr¨umen und Zugriffinfora a mationen, das Mapping von Dateien zu den Chunks sowie die Information uber ¨ die aktuelle Position der Chunks. Weiterhin koordiniert der Master-Server Systemaktivit¨ten wie Chunk-Lease-Management, Garbage Collection und Chunka Migration zwischen den einzelnen Chunk-Servern. Der Master-Server kommuniziert in regelm¨ßigen Abst¨nden 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 f¨r eine u Anwendung lesen oder schreiben zu k¨nnen. Dabei interagiert der Client mit dem o

14

2 Das Google File System

Master, um Metadaten-Operationen auszuf¨hren, der Datenfluss hingegen l¨uft u a direkt uber die Chunk-Server. Der Master-Server selbst ist nicht mit den Lese¨ oder Schreibvorg¨ngen mit den Clients besch¨ftigt, er h¨lt lediglich die Position a a a der Chunk-Server f¨r 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 Gr¨ße von 64MB gespeichert und kann bei Bedarf erweitert o werden. Die Wahl dieser Dateigr¨ße bietet mehrere Vorteile: o 1. Es reduziert die Notwendigkeit der Interaktion zwischen dem Client- und dem Master-Server, da nur wenige Informationen bez¨glich der Lage des Chunku Servers zur Verf¨gung gestellt werden m¨ssen. u u 2. Clients f¨hren 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 l¨ngeren Zeitraum. a ¨ 3. Es reduziert die Gr¨ße 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-Namensr¨ume a 2. Adressierung der Dateien auf die Chunks 3. Standorte jeder Chunk-Kopie Die ersten beiden Typen, die Datei- und Chunk-Namensr¨ume sowie die a Adressierung der Dateien auf die Chunks, werden persistent gehalten, indem Ver¨nderungen in einem Operation-Log protokoliert werden, welches auf einer a lokalen Festplatte des Masters gespeichert und zus¨tzlich noch auf anderen Recha nern repliziert wird. Mit Hilfe eines Operation-Logs kann der Zustand des Masters einfach und zuverl¨ssig 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. F¨r jeden dieser 64 MB Chunks werden nur 64 u Byte f¨r die Adressierung ben¨tigt, sodass Kapazit¨tserweiterungen durch eine u o a Speichervergr¨ßerung des Masters realisierbar sind. Da die gesamten Metadao ten im Speicher stehen, sind sie nicht nur sehr schnell zug¨nglich, es erm¨glicht 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 st¨ndig Chunk-Server hinzukommen, sich abmelden, ihren Namen a

2.2 Design des GFS

15

¨ a a ¨ndern, neustarten oder ausfallen. Diese st¨ndigen Anderungen werden durch regelm¨ßige Scans aktualisiert. Der Master kann w¨hrend 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 großen Einfluss auf die Performance des Servers. Der Zeitpunkt dieser Verbindung wird vom Master nach Kriterien der optimalen Lastverteilung gew¨hlt. Um a ver¨nderte 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 f¨r die eindeutige Identifikation der Chunks ben¨tigt wird. Durch das Operationu o Log kann der Master das Chunk-Dateisystem sehr schnell wiederherstellen. Dieses Dateisystem wird hierbei in Form eines Bin¨rbaumes abgelegt. Durch das Festlea gen von Checkpoints innerhalb dieses Bin¨rbaumes kann der Server immer wieder a in einen konsistenten Zustand zur¨ckgesetzt werden. Sobald ein neuer konsisu tenter Checkpoint ermittelt wurde, k¨nnen vorher festgelegte Checkpoints sowie o zugeh¨rige Logfiles gel¨scht werden. Die Schl¨ssel der Knoten des Bin¨rbaums o o u a werden durch eine Dateiadresse, auch Chunk-Handle genannt, mit einem Zeitstempel spezifiziert. Das Operation-Log ist die einzige persistente Speicherung der Metadaten. Ein Verlust w¨rde zu einem Verlust des ganzen Dateisystems u f¨hren. Es wird daher auf mehreren Rechnern gesichert. u

2.2.3

Konsistenzmodell

Das Konsistenzmodell bildet die Grundlage f¨r eine konsistente Datenspeicherung. u Dabei werden Namenskonventionen sowie die Reihenfolge von Datenoperationen festgelegt. Da die Dateinamensr¨ume ausschließlich durch den Master verwala tet und die zeitliche Reihenfolge der Datenspeicherung durch das Operation-Log definiert werden, kann Atomarit¨t und Korrektheit garantiert werden. Wird eine a Datei ver¨ndert, 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 ausgef¨hrt und die u Versionsnummern protokolliert. Auch nach erfolgreichen Mutationen k¨nnen Koo pien besch¨digt sein, diese werden mit Hilfe von Checksummen identifiziert. Wie a Datenverluste konkret vermieden werden, soll im n¨chsten Kapitel n¨her beleucha a tet werden.

16

2 Das Google File System

2.3
2.3.1

Systeminteraktionen des GFS
Kontrollrechte und Mutationsreihenfolge

Jede Mutation ver¨ndert die Chunk-Daten und wird auf allen Chunk-Kopien a durchgef¨hrt. Leases (Kontrollrechte) werden hierbei benutzt, um eine konsisu tente Reihenfolge der Mutationen zu garantieren. Der Master w¨hlt dabei eine a prim¨re 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 prim¨ren Kopie festgelegte Mutationsreihenfolge unter den anderen Kopien a definiert. Diese Vorgehensweise verringert den Verwaltungs-Overhead des Masters. Ein Lease hat typischerweise einen Timeout von 60 Sekunden, kann aber auf Anfrage der prim¨ren Kopie verl¨ngert werden, falls eine Mutation l¨nger als der a a a Timeout dauert. Diese Anfragen an den Master werden an die Heartbeat- Massage gekoppelt. Falls das Lease abl¨uft oder die Kommunikation mit der prim¨ren a a Chunk-Kopie verloren geht, kann der Master einfach einer anderen Kopie das Lease gew¨hren. a

2.3.2

Datenfluss

W¨hrend der Kontrollfluss vom Client uber den prim¨ren zu den sekund¨ren a a a ¨ Chunk-Servern l¨uft, werden die Daten durch Pipelining mit einer festgelegten a Reihenfolge zwischen den Chunk-Servern transferiert. Der Grund f¨r diese Voru gehensweise ist das Ziel der effizienten Nutzung der Bandbreite der jeweiligen Server sowie der Vermeidung von Engp¨ssen. Durch die Linearit¨t des Datenflusa 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 f¨r 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 vergr¨ßert. Weiterhin werden Daten auf o den naheliegendsten Chunk-Server transferiert, wobei die Entfernung durch die IP Adressen ermittelt wird, um Engp¨sse im Netzwerk zu vermeiden. Der Transa fer uber TCP-Verbindungen erm¨glicht die Minimierung der Latenzzeit, da ein o ¨ Chunk-Server, kurz nachdem er Daten empfangen hat, diese sofort weiterleitet. Durch diese Struktur ist es m¨glich 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 prim¨ren Chunk-Server eingebaut. Der prim¨re Chunka a Server checkt, ob die vom Client auszuf¨hrende Schreiboperation die maximale u Gr¨ße eines Chunks von 64 MB uberschreitet. Ist dies der Fall, gibt der prim¨re o a ¨ Chunk-Server den sekund¨ren Chunk-Server den genauen Offset, an den die Daten a zu schreiben sind und gibt eine Erfolgsmeldung an den Client zur¨ck. Falls dies u nicht der Fall ist, gibt der prim¨re Chunk-Server die Anweisung an alle sekund¨ren a a Chunk-Server, die Chunks aufzuf¨llen. Falls die Schreiboperation auf einer Kou pie fehlschl¨gt, 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 ausgef¨hrt. Der wesentliche Vorteil der Record Appendu Operation, im Vergleich zu einer normalen Schreiboperation, besteht in dem geringeren Synchronisationsaufwand bei Clientzugriffen. W¨hrend der Ausf¨hrung a u der Operation wird lediglich ein Offset am Ende der Datei ver¨ndert. Bei einer a normalen Schreibaktion werden alle Speicheradressen gesperrt, die gr¨ßer sind als o die zu beschreibende Speicheradresse. Durch diese Vorgehensweise sind immer nur Teile der Datei f¨r Leseoperationen verf¨gbar. u u

2.3.4

Snapshot-Operation

Die Operation Snapshot erm¨glicht dem Master unverz¨glich eine Kopie des o u Dateisystems und des Verzeichnisbaums zu erstellen, ohne dass stattfindende Mutationen gest¨rt werden. Wenn der Master einen Snapshot-Befehl erh¨lt, werden o a zuerst alle an die prim¨ren Kopien vergebenen Lease widerrufen, um sicherzustela len, dass Schreibbefehle von Clients eine Interaktion mit dem Master ben¨tigen. o Nachdem das Lease widerrufen oder abgelaufen ist, kann das im Speicher befindliche Quellverzeichnissystem kopiert werden. Sobald ein Client nun diesen, durch den Snapshot betroffenen, Chunk A anfordert, wird von dem Master ein neuer Chunk-Handle A’ erschaffen. 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 ausgef¨hrt wird, kann sie lokal, nicht uber das Netzwerk, u ¨ stattfinden. Einer Kopie wird nun das Lease gew¨hrt und die Interaktion mit dem a Client kann fortgesetzt werden. Das Anlegen einer Kopie f¨r den Zweck eines u Rollbacks ist somit sehr effizient implementiert.

18

2 Das Google File System

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, k¨nnen multiple Operationen gleichzeitig aktiv sein. Um seo rielle Zugriffe sicher zu stellen, werden mit Hilfe von Locks bestimmte Bereiche des Namensraums gesperrt. Die logische Repr¨sentation 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 f¨r Lese- oder Schreibzuu griffe 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 -zuverl¨ssigkeit und die effiziente 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 zun¨chst die Verteilung der Kopien a bestimmt werden. Die Auswahl erfolgt anhand folgender Kriterien: 1. Um eine gleichm¨ßige Speicherplatzausnutzung zu garantieren, werden Maa schinen mit unterdurchschnittlicher Speicherplatzauslastung favorisiert. 2. Da nach der Erzeugung eines Chunks gew¨hnlich große 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 k¨nnte aus zwei Gr¨nden geschehen: o u 1. Ein Chunk-Server ist nicht mehr erreichbar 2. Eine Kopie oder eine Festplatte ist besch¨digt. 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, Zuverl¨ssigkeit und Verf¨gbarkeit a u

19

der Anzahl der Kopien entfernt ist. Eine weitere Priorisierung erf¨hrt 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 eingeschr¨nkt. a

2.4.3

Garbage Collecion

Wird eine Datei von einem Client gel¨scht, erfolgt das L¨schen des genutzten o o Speicherplatzes nicht sofort. Es wird lediglich ein Eintrag im Logfile des Masters vorgenommen. Die Ressourcen werden im GFS in einen versteckten Dateinamen umbenannt, um weitere Clientzugriffe zu verhindern. W¨hrend der regelm¨ßigen a a - vom Master durchgef¨hrten - Scans werden versteckte Dateien, die ¨lter als u a drei Tage sind, aufgesp¨rt und permanent gel¨scht. Innerhalb dieser drei Tage u o kann die betreffende Datei ohne Probleme auf allen Chunks wiederhergestellt werden. W¨hrend der Scans des Namensraums k¨nnen weiterhin verwaiste Chunks, a o Chunks ohne Referenz, identifiziert und entfernt werden. Durch die bereits beschriebene HeartBeat-Massage k¨nnen alle Chunks erkannt werden, die nicht o l¨nger in der Datei-Metadaten-Verkn¨pfung des Masters vorhanden sind. Diea u se Chunks k¨nnen nun selbst¨ndig durch den jeweiligen Chunk-Server gel¨scht o a o werden. Zur Identifikation von veralteten Kopien werden die Versionsnummern herangezogen und mit der aktuellen Nummer verglichen. Diese veralteten Kopien k¨nnen ebenfalls gel¨scht werden, da gehaltene Daten nicht mehr relevant sind. o o Die Aktualit¨t 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, Zuverl¨ssigkeit und a Verf¨gbarkeit u

Eine der gr¨ßten Herausforderungen an das GFS stellen die regelm¨ßigen Ausf¨lle o a a von Komponenten dar. Fehler in Komponenten k¨nnen sowohl unerreichbare Syso teme als auch fehlerhafte Daten nach sich ziehen. In einem GFS Cluster mit mehreren hunderten Rechnern sind Ausf¨lle die Regel und nicht die Ausnahme. Um a dennoch eine hohe Verf¨gbarkeit 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

2 Das Google File System

lung unabh¨ngig 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 f¨r die Verf¨gbarkeit des u u Systems entscheidend. Das Operation-Log und die Checkpoints werden auf verschieden Maschinen repliziert. Aus Gr¨nden der Vereinfachung ist nur ein Masteru prozess f¨r 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 ge¨ndert werden kann, falls der a Master ausf¨llt. Um das Lesen von Dateien zu erleichtern, die nur unregelm¨ßige a a Mutationen erfahren, wurden so genannte Shadow-Master bereitgestellt, welche nur einen Lesezugriff bereitstellen. Weiterhin sind diese Master um Bruchteile einer Sekunde langsamer als der prim¨re Master und k¨nnen unter Umst¨nden a o a veraltete Resultate liefern. Ein Shadow-Master erh¨lt Informationen bez¨glich a u Chunkkopien und Mutationsreihenfolge vom prim¨ren Master und speichert so a Namensr¨ume, wenn auch zeitlich versp¨tet, identisch ab. a a Jeder Chunk-Server benutzt das bereits erkl¨rte Checksumming, um fehlerhafte a Daten zu identifizieren. Aufgrund der Operation Record Append sind Kopien auf verschieden Chunk-Servern nicht unbedingt identisch. Aus diesem Grund muss jeder Chunk-Server seine eigene Integrit¨t mittels Checksumming uberpr¨fen. Jeder a u ¨ 64 KB Block eines Chunks wird durch eine 32 bit Checksumme definiert. Bei einer Leseanfrage eines Clients werden zun¨chst die Bl¨cke uberpr¨ft, die uber die Lea o u ¨ ¨ sestrecke des Chunk-Servers hinausgehen. Durch dieses Vorgehen wird verhindert, dass fehlerhafte Checksummen zu sp¨t aufgedeckt und fehlerhafte Daten bereits a ¨ gesendet werden. Kommt es nicht zu einer Ubereinstimmung der Checksummen, wird ein Fehler an den Client zur¨ckgegeben 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 l¨sst sich sagen, dass trotz einer a fast unbegrenzten Skalierbarkeit des Systems, der wachsende Datenindex und die Anzahl an Zugriffen auch zuk¨nftig organisiert werden k¨nnen. Selbst mit u o dem Einsatz von handels¨blicher Hardware werden Defizite wie Unzuverl¨ssigkeit u a und Nichtverf¨gbarkeit durch geschickte Datenhaltung ausgeglichen. Durch eine u

Literaturverzeichnis

21

¨ st¨ndige 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 Schreibvorg¨ngen, 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.

Literaturverzeichnis
[1] Ghemawat S., Gobioff 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 f¨r 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/file/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

2 Das Google File System

3

Verteilte teme

Multimediasys-

Philipp Richardt

Inhaltsverzeichnis
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Allgemeines . . . . . . . . . . . . . . . . . . 3.1.2 Verteilte Systeme . . . . . . . . . . . . . . . 3.1.3 QoS (Dienstg¨te) . . . . . . . . . . . . . . . u 3.1.4 Best-Effort . . . . . . . . . . . . . . . . . . . Verteilte Multimediasysteme . . . . . . . . . . . . . . 3.2.1 Streaming Video und Audio . . . . . . . . . . 3.2.2 Interaktives Video und Audio in Echtzeit . . . 3.2.3 Zuk¨nftige 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 Datenstr¨me auf. Beispiele daf¨r stellen Abrufdienso u te, wie z.B. Zugriffe auf multimediale Inhalte aus Datenbanken genauso wie Kooperatives Arbeiten unter verschiedenen Benutzern, die in einem verteilten Work-

24

3 Verteilte Multimediasysteme

flow 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 Umst¨nden a zu großen 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 gr¨ßere Rolle. Mit der Entstehung des Internets wurde ein weltweites o Rechnernetz erschaffen, welches die unterschiedlichsten Technologien verbindet und den angeschlossenen Rechnern die Basis dieser Interaktionen bietet. Technologien sind sowohl unterschiedliche Medienzugriffsverfahren 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, h¨ufig an den Netz¨berg¨ngen. Die Nacha u a ¨ richten m¨ssen so oft umkodiert werden, damit uberhaupt eine Weiterleitung in u ¨ ein anderes Netz erm¨glicht 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 trifft in den meisten aller F¨lle 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 Bildqualit¨t. 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 unabh¨ngigen 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 allgemeing¨ltige Definition f¨r verteilte Systeme. Jeu u doch kann man die folgende als Charakterisierung der Begrifflichkeit verwenden. Ein verteiltes System ist eine Menge voneinander unabh¨ngiger Computer, die a ” dem Benutzer wie ein einzelnes, koh¨rentes System erscheinen.” [1] a Im folgenden sind die Ziele aufgef¨hrt, 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 effizient wie m¨glich 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 erm¨glicht. o Transparenz: Die Transparent spiegelt die F¨higkeit 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 effizient wie nur m¨glich einsetzt. o Offenheit: 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 Vergr¨ßerung dar. Dabei sollte das Hinzuf¨gen von neuen Beo u nutzern und Ressourcen in das gesamte System ohne jegliche administrativen Aufwand erfolgen.

3.1.3

QoS (Dienstg¨te) u

Quality of Service oder auch Dienstg¨te stellt die zur Verf¨gung stehenden Eigenu u schaften einer Dienstleistung dar. Alle Verfahren, die daf¨r verwandt werden um u einen Dienst mit bestimmter Qualit¨t beim Empf¨nger ankommen zu lassen um a a somit die Anforderungen des Kunden bzw. Empf¨ngers zu gew¨hrleisten. Folgende a a Parameter werden in IP-Netzen an unterschiedliche Anwendungen gestellt: Jitter: ¨ Der Jitter steht f¨r die Schwankung bei der Ubertragung von Digitalsignau ¨ len. Dabei ist dieser Effekt unerw¨nscht und f¨hrt bei der Ubertragung von u u multimedialen Inhalten zu unerw¨nschten Nebeneffekten. Ein zu fr¨hes oder u u zu sp¨tes Eintreffen des Signals ist beispielsweise bei Internet-Telefonie sehr a st¨rend. Man spricht auch von einer Abweichung der Laufzeit von Datenpao keten. Latenzzeit: Die Latenzzeit oder auch Verz¨gerungszeit spaltet sich in zwei unterschiedliche o Effekte. Zum einen in die gew¨nschte Verz¨gerungszeit , dem sogenannten u o

26

3 Verteilte Multimediasysteme

Delay, und in die unerw¨nschte Laufzeitverz¨gerung. 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 Empf¨nger nicht angekommen sind. Es wird dabei davon ausgegangen, dass a bei der IP-Telefonie Raten bis zu 5 Prozent Verlust noch in akzeptabler Qualit¨t bei Empf¨nger ankommen. Der Idealfall ist eine Paketverlustrate von 0. a a Datendurchsatz: Der Datendurchsatz stellt die Gr¨ße da, welche im Mittel bei einer o ¨ Ubertragung pro Zeiteinheit erreicht wird. Sie spiegelt anders als die Daten¨bertragungsrate den reinen Durchsatz dar. u [2]

3.1.4

Best-Effort

Der heute im Internet durch das IP-Protokoll erbrachte Best-Effort-Dienst gew¨hrleistet das Weiterleiten eintreffender Pakete, solange das Netz noch a ¨ freie Ubertragungskapazit¨ten bietet. Es werden dabei keine Garantien f¨r a u ¨ die vollst¨ndige 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 Begrifflichkeiten n¨her erl¨utert. 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 Verz¨gerung ist bzw. ist es kaum von o n¨ten, dass die Daten ich ann¨hernder Echtzeit beim Empf¨nger ankommen. Auf o a a der anderen Seite k¨nnen traditionelle und elastische Anwendungen anders als o Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Verteilte Multimediasysteme In den voran gegangenen Abschnitten wurden die grundlegenden Begrifflichkeiten n¨her erl¨utert. 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 Verz¨gerung ist o bzw. ist es kaum von belangen, dass die Daten nicht ann¨hernder in Echtzeit beim a Empf¨nger ankommen. Auf der anderen Seite k¨nnen traditionelle und elastische a o Anwendungen anders als Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Somit stellen Multimedia-Anwendungen in ihren verschiedensten Auspr¨gungen unterschiedlichste Netz- und Qualit¨tsanforderungen. In den fola a genden Abschnitten soll dabei zun¨chst anhand von zwei unterschiedlichen Klasa sen die Anwendung von verteilten Multimediasystemen erl¨utert 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 findet das Streaming von Live-Video und Audio ausschließlich im Internet statt. Somit werden weltwei¨ te Ubertragungen von Sendungen an mehrere Millionen Zuschauen und Zuh¨rer o m¨glich. 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 m¨ssen kann der Client keine vorl¨ufige Speiu a ¨ cherung der Inhalte durchf¨hren. u Beispiel: IPTV Fernsehinhalte werden heutzutage nicht mehr nur noch traditionell uber Satelliten ¨ oder Glasfaser-/ Koaxialkabel, sondern besteht sehr großes Interesse dem Endverbraucher das Fernsehen uber das Internet zu senden. Hierbei werden jedoch ¨ extrem große Bandbreiten vorausgesetzt. Diese hohe Bandbreite ist vor allem serverseitig von N¨ten. Wir gehen davon aus, dass ein sportliches Großereignis o wie die Fußball 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 w¨rde eiu ne Serverbandbreite von 500 Terabit/Sekunde ben¨tigt werden. Eine klassische o Server-Client-Verteilung ist somit aufgrund der ben¨tigten Serverbandbreite v¨llig o o unzureichend. Eine angebrachte Verteilung k¨nnte man durch IP-Multicast erreio chen. Ebenfalls besteht die Alternative ein Multicast-Overlay-Netzwerk zu bilden und dar¨ber die Inhalte zu verteilen. Solche M¨glichkeiten werden durch Content u o ” Distribution Networks“ bereits zur Verf¨gung gestellt. Weitere M¨glichkeiten der u o Verbreitung w¨re die Verteilung uber Peer to Peer. Hierbei w¨rde jeder Peer auch a u ¨

28

3 Verteilte Multimediasysteme

gleichzeitig dazu beitragen die Empfangenen Pakete weiter an andere Peers zu geben. W¨rden alle Peers entsprechend viel Upload- Bandbreite liefern w¨rde der u u Server eine weitaus geringere Bandbreite ben¨tigen. 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 M¨glichkeit offen im o Film zu spulen, anzuhalten oder weiterzuspringen. Bei den Servern, welche die Video/Audio Inhalte zur Verf¨gung 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 enth¨lt die verwendete Video-/Audio-Codierung. a 2. Der Browser des Clients untersucht die Header-Zeile der Response-Nachricht und startet den zugeh¨rigen 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] ¨

3.2 Verteilte Multimediasysteme

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 Empf¨nger. Treffen die kompria mierten Daten aus dem Netz beim Empf¨nger 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 Verz¨gerung im Medien Player hervorgerufen. Dieser verz¨gert die o o Ausgabe des Videos um wenige Sekunden. Dies dient zur Entfernung von netzwerkbedingten Jitter. Die komprimierten Daten werden in einem sogenannten Client-Puffer abgelegt und nach Ansammlung einiger Sekunden im Voraus von dort abgespielt. Die dritte Methode ubertr¨gt 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 Medienpuffer gespeichert. Erneut nach einer Anfangsverz¨gerung o gibt der Medienplayer den Puffer wieder aus und leitet die komprimierten Daten zur Wiedergabe und Dekompression weiter. Da die hier angewandte Methode TCP, verworfene Pakete nochmals ubertr¨gt wird somit ein besserer Ton und ein a ¨ besseres Bild erzielt.

Abbildung 3.2: Streaming uber einen Streamingserver [5] ¨

30

3 Verteilte Multimediasysteme

3.2.2

Interaktives Video und Audio in Echtzeit

In dieser Klasse der Multimedia-Anwendungen wird es dem Anwender erm¨glicht 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 erm¨glichen sind Grupo ¨ penkommunikationen, Anruffilterung, Erkennung ob Anwender anwesend sind und die damit verbundene Integration von webbasierten Anrufen. Bekannte Beispiele f¨r die voran gegangenen Dienste sind: Skype oder Microsoft NetMeeting u Bei beiden Conferencing-Tools wird es dem Benutzer erm¨glicht mit andeo ren Benutzern audiovisuell in Kontakt zu treten. Hierbei sollte idealerweise die Verz¨gerung zwischen Bild und Ton des Senders und Empf¨ngers nicht h¨her sein o a o als 150ms. Sobald es h¨here Abweichungen bei der Verz¨gerung gibt kann dies zu o o ¨ indiskutablen Gespr¨chsst¨rungen oder zu asynchronen Bild/Ton Ubertragungen a o f¨hren. Somit stellen diese Anwendungen ein hohe Anforderung an Paket-Jitter u und Paketverz¨gerung. Der Paket-Jitter beschreibt dabei eine Ver¨nderung eio a ner Paketverz¨gerung im selben Strom von Paketen. Solange der Echtzeitano ¨ wendung gen¨gend Bandbreite zur Verf¨gung steht ist eine gute Ubertragung u u von Video und Audio gew¨hrleistet, da dadurch die Verz¨gerung und der Jitter a o niedrig gehalten werden kann. Sobald jedoch der Paket-Strom auf einen ausgelasteten Pfad trifft kann sich die Qualit¨t extrem verschlechtern. Da das heutige a Internet keine Klassifizierung bzw. eine Priorisierung von Paketen in erster und zweiter Klasse zul¨sst, ist die Weiterentwicklung von Multimedia-Anwendungen a schwierig. Die Paketverarbeitung erfolgt somit ohne jegliche Gewichtung f¨r u verz¨gerungsempfindliche Anwendungen. Alle Pakete werden somit gleich behano delt und auch gleich abgearbeitet. Somit muss man zun¨chst mit diesem Besta Effort-Dienst auskommen.

3.2.3

Zuk¨nftige Weiterentwicklungen im Internet zur u ¨ Ubertragung Multimedialer Anwendungen

Bereits in der Einf¨hrung wurde auf die Bedeutung von Dienstg¨te in IPu u Netzwerken eingegangen. Diese spielt auch in der Weiterentwicklung des Inter¨ nets und besonders bei der Ubertragung multimedialer-Anwendungen eine sehr große Rolle. Es gibt eine Reihe von Forschern, welche es fordern grundlegen¨ ¨ de Anderungen am Internet vorzunehmen. Diese Anderungen zielen dahin, dass zuk¨nftig Anwendungen End-zu-End Bandbreite reservieren k¨nnen. Dadurch u o

3.2 Verteilte Multimediasysteme

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 Dienstg¨te eingehalten wird. u Es soll nach Meinungen dieser Forschergruppe m¨glich 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 Dienstg¨te zu gew¨hrleisten bedarf es großen Anderungen. Folgende u a ¨ Anderungen m¨sste dabei ber¨cksichtigt werden. Zum einen w¨rde man ein Prou u u tokoll ben¨tigen das in der Lage ist die Bandbreite auf dem Pfad zwischen Sender o und Empf¨nger zu reservieren.Dar¨ber hinaus m¨sste man eine Priorisierung der a u u zu behandelnden Pakete einf¨hren. Somit w¨rden Pakete, welche sich in der Rouu u tingwarteschlage befinden und eine hohe Priorit¨t aufweisen zuerst abgearbeitet a und andere mit niedrigerer sp¨ter. Die Pakete die mehr reserviert haben werden a folglich schneller abgearbeitet. Die Anwendungen m¨ssen daf¨r dass ihre Reservieu u ¨ rungen ber¨cksichtigt werden dem Netz eine Ubersicht uber ihren Verkehr geben. u ¨ Welchen sie beabsichtigen ins Netzwerk zu senden. Das Netz wiederum ist dann verpflichtet den Verkehr jeder Anwendung zu uberwachen. Damit wird sicherge¨ stellt, dass die getroffenen Abmachungen mit Anwendung und Netz eingehalten werden. Eine weitere Methode die noch angef¨hrt 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 ben¨tigt 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-Effort-Dienst und vorhandener Internetprotokolle keiner notwendigen Ver¨nderung bedarf. Sie sind somit Bef¨rworter 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 erf¨llt werden kann. Somit m¨ssen die ISPs lediglich ihre u u Bandbreite und die Switching-Kapazit¨t so angleichen, dass die ben¨tigte Leisa o tung hinsichtlich der Verz¨gerung und des Paketverlust im Rahmen bleibt. Durch o den get¨tigten Angleich der Leistung durch die ISps werden folglich die Kunden a zufrieden gestellt und somit laut Aussage der Bef¨rworter dieses Ansatzes auch u mehr Kunden zum ISP kommen. Folglich ist eine Steigerung der Einnahmen f¨r u den ISP gew¨hrleistet. Um auch wirklich zu gew¨hrleisten, dass Multimedia- Ana a wendungen auch zu H¨chstlastzeiten in guter Qualit¨t im ausreichenden Maße o a zur Verf¨gung stehen, sollte der ISP deutlich mehr Bandbreite und Switchingu Kapazit¨t bereithalten als aktuell ben¨tigt. Dieses Overprovisioning bietet dem a o Kunden die M¨glichkeit weiche Dienstg¨te-Garantien uber den Verkehr zu geben. o u ¨

32

3 Verteilte Multimediasysteme

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 k¨nnen durch CDNs o Datenaufkommen im inneren des Internets verringert werden. Somit ist auch bei CDN oft eine schnellere Lieferung der Inhalte an den Endanwender m¨glich. Die o Nachfolgende Abbildung zeigt eine Verteilung von Inhalten zun¨chst auf einen a Server, der wiederum die Inhalte verteilt auf die CDN Knoten-Server. Von diesen k¨nnen die meist multimedialen Inhalte durch den Anwender abgerufen werden. o

Live-Streaming-Verkehr wie im voran gegangenen Kapitel anhand von IPTV erl¨utert muss an mehrere hundert Millionen Menschen (Beispiel WM 2014) a ¨ uber das Internet live ubertragen werden. Die Live-Ubertragungen k¨nnen 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 durchgef¨hrt, sondern auf der Anwendungsschicht. u Es k¨nnte 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 unterst¨tzen die Ansichten der geringen Ver¨nderung u a ¨ an Netzwerk- und Transportschicht. Sie wollen lediglich einfache Uberwachungsund Preisschemata am Rand des Netzwerkes einf¨hren. Diese sollen an der u Schnittstelle zwischen Benutzer und ISP installiert werden. Der sogenannte DiffServ“ Ansatz beschreibt somit einen Service bei dem im Grundgedanke einige ” wenige Verkehrsklassen eingef¨hrt werden, welche in Routingwarteschlangen unu

Abbildung 3.3: Ursprungsserver ubertr¨gt Inhalte an CDN Verteilerknoten [6] a ¨

3.3 Zusammenfassung

33

terschiedlich behandelt werden sollen. Somit k¨nnen 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 gew¨hrleisten und somit preislich teurer sind. a In den voran gegangen Methoden und Ans¨tzen wurden unterschiedlichste Hera angehensweisen und teilweise auch L¨sungen 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-Effort-Dienst, der sein bestes tut um jedes noch so unterschiedliche Datagramm schnellstm¨glich zum Ziel zu ubertragen. o ¨

3.3

Zusammenfassung

In den voran gegangenen Kapiteln haben wir zum einen durch eine Einf¨hrung u und durch Begriffserkl¨rungen einen Einblick in das Thema der verteilten Mula timediasysteme bekommen. In weiteren Abschnitten wurde das Thema anhand von technisch eingesetzten Beispielen im Internet weiter Ausgef¨hrt. Zum Schluss u wurden einige Ans¨tze und Methoden dargestellt, welche zur Verbesserung des aka tuellen Best-Effort-Internets beitragen sollen und auch zuk¨nftig die Verbreitung u Multimedialer-Anwendungen uber verteilte Systeme steuern k¨nnen und sollen. o ¨ Dabei spielt zuk¨nftig die Dienstg¨te, welche von einer Anwendung gefordert ist u u und dessen Erf¨llungsgrad eine wichtige Rolle um das immer h¨her werdenden u o Datenaufkommen und die wachsende Zahl der Benutzer des Internets steuern zu k¨nnen. o

34

3 Verteilte Multimediasysteme

Literaturverzeichnis
[1] Andrew S. Tanenbaum, Maarten van Steen: Verteilte Systeme: Prinzipien und Paradigmen. Pearson Studium; Auflage: 2., aktualisierte Auflage., November 2007. [2] Wikipedia, Quality of Service. Quality_of_Service,12.01.2012 http://de.wikipedia.org/wiki/

[3] Wikipedia, Best-Effort. 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; Auflage: 4., aktualisierte Auflage., September 2008. [5] James F Kurose, Keith W. Ross:Computernetzwerke: Der Top-DownAnsatz. S. 642 Pearson Studium; Auflage: 4., aktualisierte Auflage., September 2008. [6] Cslongwang, Content Distribution Network - Grafik http://www. cslongwang.com/Images/Cdn_Product.gif, 16.01.2012

4

OpenCL

Roger J¨ger a

Inhaltsverzeichnis
4.1 4.2 4.3 4.4 Einf¨hrung zum Thema - Taktfrequenzen stagnieren u OpenCL - Hintergrund . . . . . . . . . . . . . . . . Voraussetzungen f¨r 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

Einf¨hrung 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ß f¨r die Leistung einer CPU. u Sie gibt auch die Geschwindigkeit an, mit der die Einzelnen Transistoren schalten. Damit tr¨gt sie entscheidend dazu bei, wie schnell Berechnungen durchgef¨hrt a u werden k¨nnen. Lange Zeit stellten die anwachsenden Taktraten kein gr¨ßeres o o Problem, f¨r die Entwicklung immer leistungsf¨higer Chips, dar. Auch die u a immer feiner werdenden Strukturen, wurden durch die Entwicklung neuer Verfahrenstechniken und den Einsatz neuer Materialien im Fertigungsprozess erm¨glicht. Zur Einf¨hrung 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 k¨nnen[1]. Allerdings bestehen o grunds¨tzliche physikalische Hindernisse bei der Steigerung der Taktrate. Bei a jedem Stromfluss muss ein Wiederstand uberwunden werden der in thermische ¨ Energie umgewandelt wird. Bei immer kleiner werdenden Strukturen und Chipfl¨chen wurde die somit erzeugte Abw¨rme der Prozessor bald zu einem a a Problem. Die Chiphersteller wie Intel und AMD lassen f¨r ihre CPU maximal u 150 Watt Abw¨rme zu. Zwar gibt es seit 2007 mittlerweile von IBM speziell a f¨r Serversysteme Power6-Prozessoren mit bis zu 5Ghz Taktrate[2], doch lassen u sich noch h¨here Werte nur noch schwer zuverl¨ssig mit Luftk¨hlen. 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 f¨r 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/Effekte stoßen aktuelle Mehrkern-Prozessoren an ihre Grenzen. Aus diesem Grund versucht man seit kurzem auf andere leistungsf¨hige a Systemressourcen zur¨ckzugreifen. u Im Zuge der rasanten Entwicklung in der Spieleindustrie wuchs auch die Leistung der Grafikkarten mit den Anforderungen. Immer mehr grafisch anspruchsvollere spiele Titel veranlasste Hersteller wie ATI und NVIDIA Grafikprozessoren zu entwickeln, die so viele Berechnung wie m¨glich parallel ausf¨hren konnten, um o u die Inhalte fl¨ssig darzustellen. Diese wurden urspr¨nglich zur Unterst¨tzung u u u und Entlastung von Grafikberechnung der CPU genutzt. Doch durch gestiegene Leistung und Flexibilit¨t, sowie der hohen Parallelit¨t an Aufgabenbearbeitung, a a boten Grafikkarten immer mehr das Potential f¨r den Einsatz als Co-Prozessor. u NVIDIA entwickelt erstmals mit der API CUDA(Compute Unified Device Architecture) eine Schnittstelle Programmteile zur Berechnung auf Hersteller eigenen Grafikkarten auszulagern. Es bietet der Anwendung den Vorteil, von der meist außerhalb von Videospielen und Grafikanwendung genutzten und brach liegende Rechenleistung der GPU zu profitieren. Dabei bieten vor allem neuere GPUs durch die hohe Anzahl an Kernen im Vergleich CPUs die M¨glichkeit, Programme m¨glichst 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 gr¨ßeren Speicher zu besitzen, der o

4.2 OpenCL - Hintergrund

37

Abbildung 4.1: Vergleich Aufbau einer mehr Kern CPU und GPU mit dazugeh¨rigem o Speicheraufbau[5]

es ihnen erm¨glich komplexere Befehle abzuarbeiten, allerdings sind in ihrer o Parallelit¨t relativ begrenzt. Diesen Nachteil haben Grafikprozessoren nicht. Sie a bieten zwar nur einen begrenzten Befehlssatz an, weißen dabei aber eine hohe Parallelit¨t von Aufgabenabarbeitung auf. Erm¨glicht wird dies durch mehrere a o kleine Control Units die uber einen eigenst¨ndigen Cache verf¨gen. Die Berecha u ¨ nung ist zwar ¨hnlich der eines Threads bei einer CPU, jedoch deutlich effizienter. a Zur Programmierung von CUDA F¨higen Grafikkarten wird C for CUDA“ a ” eine C Version mit NVIDIA-Erweiterung genutzt. Weiterhin existieren auch ein Wrapper f¨r Perl, Phyton, Java, Fortan und .NET und auch eine Anbindung u f¨r Matlab. Ein Entscheidender Nachteil bei der Entwicklung von CUDA ist, u das diese Schnittstelle auf die NVIDIA eigenen Grafikkarten beschr¨nkt 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 f¨r uneinheitliche Parallelrechner. Dieser Entwurf ist ein Frau mework namens OpenCL und verfolgt das Ziel aus mehreren unterschiedlichen Systemkomponenten wie CPU, GPU und anderen Signalprozessoren f¨r Berechu nung notwendige Systemleistung zu kombinieren. OpenCL welches urspr¨nglich u

38

4 OpenCL

von Apple entwickelt worden war, wurde schließlich im Juni 2008 zur Standardisierung eingereicht. Verantwortlich f¨r die Entwicklung ist seitdem die im Jahr u 2000 gegr¨ndete 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 offener und Standard entwickelt wird, bietet es im Vergleich zu CUDA nun die M¨glichkeit an, f¨r jeden Hardware- und Betriebssyso u temhersteller eigene Implementierungen und Erweiterungen zu entwickeln, welche sich allerdings im Rahmen der Spezifikationen bewegen m¨ssen. Die Khronos u Group ver¨ffentlichte die erste Spezifikation von OpenCL am 8. Dezember 2008. o Die Aktuellste und neuste Version ist OpenCL 1.2, welche auch abw¨rtskompatibel a ist und im November 2011 erschien.

4.3

Voraussetzungen f¨r OpenCL u

Um die Voraussetzungen f¨r aufgabenparalleles bzw. datenparalleles Rechnen f¨r u u OpenCL zu erf¨llen, ben¨tigt man allerdings einige Hardware und Softwareseitige u o Implementierungen. Das Betriebssystem muss, um eine Beschleunigung mit OpenCL nutzen zu k¨nnen, uber folgende Bestandteile verf¨gen. o u ¨ Implementierung in BS notwendig: OpenCL Application Programming Interface (API) OpenCL Runtime Engine OpenCL Compiler Auch auf der Hardwareseite m¨ssen einige Voraussetzungen erf¨llt werden. Es u u kann f¨r die Berechnung nur auf Hardware zur¨ckgegriffen werden, wie CPUs u u und GPUs, bzw. Schaltkreise, die die notwendigen Spezifikationen erf¨llen. Eine u der wesentliche Bestandteil liegt in den neuen Funktionen und Frameworks. Bei der Verwendung dieser m¨ssen die neuen M¨glichkeiten zum Datenparallel rechu o nen auch ausgenutzt werden. Bisherige Software wird somit durch die fehlende OpenCL Tauglichkeit nicht von einem Performance-gewinn profitieren. Es m¨ssen u als Ressourcen intensive programmteile OpenCL konform und API konform ausgelagert werden, um die erforderliche Beschleunigung zu erreichen. Sobald alle Voraussetzungen erf¨llt sind: u

4.4 OpenCL - Aufbau/Architektur

39

Betriebssystem OpenCL tauglich Hardwarekomponenten OpenCL tauglich Software OpenCL konform ist die Beschleunigung von Programmteilen durch Auslagerungen m¨glich. Wenn o allerdings nur eine der drei Bedingungen nicht erf¨llt ist, kann kein OpenCL u Code auf dem System ausgef¨hrt werden. u Wie bereits erw¨hnt, ben¨tigt das OpenCL-Framework zur Ausf¨hrung 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 erf¨llt, kompiliert und nativ ausgef¨hrt werden. Sie enth¨lt u u a zus¨tzlich zu den normalen Befehlen einige Erweiterungen mit mathematischen a Zusatzfunktionen, die die Implementierung von wissenschaftlicher sowie und ingenieur-spezifischer Probleml¨sungen vereinfacht. Durch die Integrierung des o Compilers in das OpenCL-Framework wird es erm¨glicht, Programme erst zur o Laufzeit am Zielrechner kompiliert zu lassen. Diese schafft die Voraussetzung f¨r das Speichern des Programmcodes, der somit nicht bei jedem Start des u Programms neu am Zielrechnerneu kompiliert werden muss. Es ist von daher nicht n¨tig f¨r den Entwickler im Vorfeld zu wissen, ob und wie viele verschiedene o u OpenCL taugliche Komponenten im Zielsystem verf¨gbar sind, da durch die u externe Verarbeitung eine Vorkompilierung auf unterschiedliche Version der Anwendung uberfl¨ssig 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 daf¨r notwendigen Context erstellt und die Kernel an die u Warteschlangen weitergibt. Die dazugeh¨rigen Host Devices(beispielsweise CPU), o sind Ger¨te auf denen die Host-Applikation ausgef¨hrt werden kann. Um jedoch a u

40

4 OpenCL

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

ein Kernel starten zu k¨nnen, muss die Anwendung folgende Schritte ausf¨hren: o u Bestimmung der verf¨gbaren Devices(CPU, GPU...) u W¨hlen der geeigneten Devices, die f¨r die Berechnung in Frage kommen a u Befehlswarteschlangen f¨r die gew¨hlten Devices erstellen u a Allokieren des Speichers (Memory Objects) der f¨r die gemeinsame Nutzung u der Kernel-Ausf¨hrung ben¨tigt wird u o

4.4.2

Compute Devices/Units

Jede Baugruppe die rechentaugliche Aufgaben im Sinne der OpenCL Spezifikationen ausf¨hren kann, wird als Device bezeichnet. Innerhalb jedes Devices k¨nnen u o sich ein oder mehrere Recheneinheiten befinden. 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 Abarbeitungsparallelit¨t, die der Anzahl der a zur Verf¨gung 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 Begriff Kernel steht im Allgemeinen f¨r eine Funktion innerhalb einer Sprau che. Als Kernel werden in OpenCL Programme bezeichnet die zur Ausf¨hrung u auf OpenCL tauglichen Devices kompiliert wurden. Auch wenn die Kernels in die Host-Applikation implementiert und in C oder C++ geschrieben sind, m¨ssen u diese auf dem Zielrechner separat erzeugt werden. Nur so k¨nnen die verf¨gbaren 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 implementierungsspezifisch

4.4.4

Program

Ein Program in OpenCL besteht aus einer Menge von Kerneln, sowie dazugeh¨riger Hilfsfunktionen und Konstanten. Diese k¨nnen innerhalb des Kernels o o aufgerufen und verwendet werden.

4.4.5

Command Queue

Die Ausf¨hrung einiger Befehle wird in OpenCL mittels Command Queue abgeu arbeitet. Diese Befehle dienen zur Ausf¨hrung von Kerneln, f¨r den Transfer von u u Daten zwischen Hauptspeicher und dem Speicher des Compute Devices. Weiterhin k¨nnen Befehlswarteschlangen genutzt werden, um anstehende Befehle an o ein konkretes Ger¨t zu ubermitteln. Diese f¨hren den Kernel auf dem Ger¨t in a u a ¨ der Reihenfolge aus, in der sie in die Warteschlange abgelegt wurden. Zus¨tzlich a gibt es Synchronisationsbefehle mithilfe derer man den Kernel auf die Ausf¨hrung u eines Datentransfers warten lassen kann.

4.4.6

Program Object

Als Program Object werden in OpenCL Datentypen bezeichnet, die eine OpenCLAnwendung repr¨sentieren. Folgende Informationen k¨nnen 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 Ger¨te, bei der letzten erfolgreich kompilierte Programm Version a und der zugeh¨rigen Kompilier-Parametern und Logfiles o

4.4.7

Context

Mit dem Context wird eine Systemumgebung beschrieben, in der ein Kernel ausgef¨hrt werden kann. Dazu geh¨ren die Anzahl der Devices, die Angabe der u o verf¨gbaren Speicherbereiche im System, sowie Befehlswarteschlangen zur Abaru beitung der Programmbefehle. Er ist außerdem 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 enth¨lt eine Referenz auf einen lokalen Speicherbereich a und dient so zur Bereitstellung von Arbeitsspeicher f¨r die Applikation. In u OpenCL werden zwei Arten von Speicherobjekten unterschieden. Buffer-Objects

4.5 OpenCL C und Besonderheiten

43

die alle Arten von Daten beinhalten k¨nnen 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 Adressr¨umen: a Private f¨r Daten die zu einem Work-Item geh¨ren u o Local f¨r Daten die zu einer Work-Group geh¨ren u o Global f¨r Daten auf die von allen Work-Items und Work-Groups aus zugeu griffen werden kann constant f¨r read-only Daten u In OpenCL wird versucht die jeweilige Implementierung der Hierarchie so gut wie m¨glich auf die zur Verf¨gung stehende Hardware anzupassen. Zu beachten o u ist, dass die Konsistenz der Daten im Speicher nicht immer garantiert ist. So k¨nnen 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 M¨glichkeit mehrere Instanzen eines Kernels gleichzeitio ge auf einem oder mehreren OpenCL-Ger¨ten auszuf¨hren. 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 definieren, auch Index-Spaces genannt. Diese k¨nnen sowohl ein- zwei, als auch dreidimensional sein. Damit eine o synchronisierte Berechnung der einzelnen Kernel-Instanzen erfolgen kann, wird es erm¨glicht die Work-Items in sogenannten Work-Groups zusammenzufassen. o Eine Synchronisation zwischen Work-Groups ist allerdings nicht m¨glich. 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 geh¨rt zwar zur Obermenge der Sprache C, o enth¨lt aber auch einige Absonderungen und Ausnahmen zu dieser. Zus¨tzlich a a zu C, wurden weiter Funktionen und Datentypen zu parallelen Verarbeitung hinzugef¨gt, beispielsweise ein Datentypen f¨r zwei- und dreidimensionale u u Bilder. Es gibt allerdings auch einige Einschr¨nkungen die z.B. den Aufruf von a Funktionspointern und rekursiven Kernel Aufrufen verbietet. Ebenso werden

44

4 OpenCL

Array mit variabler L¨nge und Structs nicht unterst¨tzt. a u nicht enthalten: Funktionspointer Rekursion Arrays variabler L¨nge a structs optional: Gleitkommazahlen mit doppelter Genauigkeit Atomare Funktionen (z.B. increment) Zus¨tzlich 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 zus¨tzlich Vektoren mit 3-dimensionen eingef¨hrt a u image2d t: zweidimensionales Bild image3d t: dreidimensionales Bild sampler t: sampler, der definiert, wie ein Bild abgetastet wird event t: Event Handler

4.6

Fazit

Da mittlerweile fast alle aktuell verkauften Systeme neben einer MehrkernCPU, auch eine leistungsf¨hige Grafikkarte besitzen und diese bei den meisa ten Anwendungen zur Verf¨gung stehende Leistung nicht genutzt wird, bieten u sich im Bereich verteiltes und paralleles Rechnen mit OpenCL beeindruckende M¨glichkeiten der Performance Steigerung von Applikationen an. Im Vero gleich zu CUDA welches speziell nur auf NVIDIA Grafikkarten anwendbar ist, bietet OpenCL die M¨glichkeit frei den Hersteller zu w¨hlen. So k¨nnen uno a o abh¨ngig vom Hersteller des Betriebssystem und der Grafikkarte OpenCL kona forme Programme ausgef¨hrt werden. Dazu z¨hlen auch spezielle L¨sungen die u a o

Literaturverzeichnis

45

die OpenCL Spezifikationen erf¨llen, 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 Molek¨lforschung zu finden. u

Literaturverzeichnis
[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 Specification - 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

5

Peer-to-Peer-Systeme

Tim Achtert

48

5 Peer-to-Peer-Systeme

6

Sicherheit Systemen

in

verteilten

Mario F¨hr o

Inhaltsverzeichnis
6.1 6.2 6.3 6.4 Einleitung . . . . . . . . . . Angriffe . . . . . . . . . . . Delegation . . . . . . . . . Vertrauensw¨rdiges System . u 6.4.1 Verschl¨sselung . . u 6.4.2 Authentifizierung . . 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 h¨ufiger zu Zielen von Angriffen werden. Es wird fast t¨glich von Angriffen 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 Angriffen. Ein verteiltes System ist hier vermeintlich besonders anf¨llig, da es aus mehreren Systemen besteht. Jea des weitere System ist ein potenzieller Angriffspunkt f¨r Angreifer und bedeutet u zus¨tzlichen Aufwand zur Absicherung. Schaut man sich die Vielzahl der Angriffe a und die Gr¨ße/Bekanntheit der angegriffenen Ziele an, so k¨nnte 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 M¨glichkeiten gibt, sich gegen einen Angreifer zu wehren. o

50

6 Sicherheit in verteilten Systemen

Abschnitt eins nennt und erl¨utert m¨gliche Angriffe auf ein verteiltes System. a o Abschnitt zwei erl¨utert den Begriff der Delegation, der pr¨gend f¨r ein verteiltes a a u System ist, da Aufgaben nur selten direkt am Eintrittspunkt des Anwenders ausgef¨hrt werden. u Der dritte Abschnitt erl¨utert die Merkmale, welche ein System aufweisen muss, a dem vertraut werden kann. Die dazu ben¨tigten Techniken werden vorgestellt. o Im vierten Abschnitt wird der Secure Socket Layer erl¨utert und auf seine Wicha tigkeit zur Absicherung einer Verbindung zwischen zwei Systemen hingewiesen. Abschnitt f¨nf erl¨utert das Vorgehen, um ein sicheres Netz von einem unsicheren u a Netz abzutrennen und somit das sichere verteilte System vom unsicheren Internet zu sch¨tzen. u Es werden ebenfalls Techniken zur Analyse, Erkennung und Vermeidung von Angriffen ben¨tigt. Mit diesem Thema befasst sich das sechste Kapitel. o Im letzten Kapitel wird der Autor ein Fazit zu allen erl¨uterten Techniken ziehen. a

6.2

Angriffe

Es werden vier Arten von Angriffen unterschieden. 1. Unterbrechen: Dabei handelt es sich um eine bewusste St¨rung des o ¨ Ubertragungssystems durch Trennung vom Netz. Es handelt sich um einen Angriff auf die Verf¨gbarkeit des Systems. u 2. Abh¨ren und Mitschneiden: Abh¨ren erfolgt durch nicht autorisierte Teilneho o mer. Es erfolgt ein Angriff auf die Vertraulichkeit der Nachricht. 3. F¨lschen: Die Nachricht wird w¨hrend des Transport ver¨ndert. Dies ist ein a a a Angriff auf Integrit¨t der Nachricht. a 4. hinzuf¨gen / generieren: Der Angreifer ahmt das Verhalten eines autorisieru ten Teilnehmers nach und erzeugt falsche Daten. Dies ist ein Angriff auf Glaubw¨rdigkeit der Nachricht. u Es werde f¨nf Angriffsformen unterschieden. Davon sind vier passiv und eine u aktiv. Aktive und passive Angriffsformen unterscheiden sich dadurch, dass f¨r u einen aktiven Angriff ein Programm in das System eingeschleust werden muss. 1. Lauschangriff (passiv): Die Informationen werden unbemerkt mitgeschnitten und nicht ver¨ndert. Der Angreifer hat keine Kontrolle dar¨ber, 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 verf¨lscht, sodass a der Angreifer ein anderes Verhalten beim Empf¨nger erzeugt, als vom Absena der gewollt. 4. Wiederholen (passiv): Die Nachrichten k¨nnen mitgeschnitten und sp¨ter uno a ver¨ndert erneut gesendet werden. Der Angreifer muss dazu die Nachricht a nicht entschl¨sseln k¨nnen. 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 Netz¨berflutung mit willk¨rlichen u u Nachrichten kann zur Verweigerung f¨hren. u Zur Durchf¨hrung eines Angriff werden bekannte Zugangsdaten verwendet. Diese u Zugangsdaten k¨nnen durch eine gef¨lschte Login-Oberfl¨che gesammelt werden. o a a Des Weiteren kann ein Angriff durchgef¨hrt werden, indem die Autorisierung umu gangen wird, oder bekannte Sicherheitsl¨cken ausgenutzt werden. Eine weitere u M¨glichkeit ist das Tarnen eines Programms als legitimes Programm und es per o Mail verschicken, um den Empf¨nger zu infizieren. a

6.3

Delegation

In verteilten Systemen muss eine Aufgabe zwischen den Servern delegiert werden. Delegieren besagt, dass eine Aufgabe nicht vom Auftraggeber ausgef¨hrt 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 gepr¨ft 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 d¨rfen u keine globalen Vollmachten erstellt werden, sondern nur eingeschr¨nkte Rechte. a Das macht das System sicherer gegen Angriffe. Wichtig ist die erste Pr¨fung der u Identit¨t des Auftraggebers. Die Identit¨t kann nur an der Stelle mit direktem a a Kontakt zum Auftraggeber durchgef¨hrt werden. Empf¨nger hinter dem ersten u a Kontakt k¨nnen den Auftraggeber nicht mehr authentifizieren. F¨r die Autheno u tifizierung w¨rden sie Zugangsdaten und Password des Auftraggebers ben¨tigen. u o Diese Daten m¨ssen uber das Netz weitergegeben werden, um den Auftraggeu ¨ ber zu authentifizieren. Bei der Weitergabe der Zugangsdaten und Passw¨rter o handelt es sich um eine sch¨dliche Form der Personifikation. Prinzipiell ist eine a Authentifizierung des Auftraggebers an jeder Stelle gut, aber durch die Weitergabe sicherheitsrelevanter Daten wird es zu einem Sicherheitsrisiko.

52

6 Sicherheit in verteilten Systemen

6.4

Vertrauensw¨rdiges System u

Damit bei einem System von einem vertrauensw¨rdigen System gesprochen weru den kann, m¨ssen mehrere Punkte erf¨llt sein. Als erstes m¨ssen abgesicheru u u te Kommunikationskan¨le verwendet werden. Dadurch wird das unautorisierte a Abh¨ren verhindert. Die Verbindung ist durch Kryptografie gesch¨tzt. Weiter ist o u gegenseitiges Misstrauen von einer sehr hohen Bedeutung. Dabei findet eine Autorisierung beider Kommunikationspartner statt. Dadurch wird sichergestellt, dass der Client ein rechtm¨ßiger Vertreter ist und der Server authentisch ist. Als drita tes ist die Aktualit¨t der Nachricht sicherzustellen. Dazu werden Zeitstempel und a Nonces (Zufallszahl) verwendet. Durch einen Zeitstempel wird sichergestellt, dass eine Nachricht unbemerkt veraltet.

6.4.1

Verschl¨sselung u

Um die Kommunikationskan¨le abzusichern wird eine Verschl¨sselung eingesetzt. a u Bei einer Verschl¨sselung handelt es sich um eine Funktion, die auf Daten und u den Schl¨ssel angewendet wird. Es existieren unterschiedliche Verfahren eine u Verschl¨sselung umzusetzen. u Das erste Verfahren ist die die symmetrische Verschl¨sselung. Bei einer u symmetrischen Verschl¨sselung haben beide Nutzer den gleichen Schl¨ssel. Das u u heißt, dass die Nachricht mit dem gleichen Schl¨ssel ver- und entschl¨sselt u u wird. Bevor Nachrichten ausgetauscht werden k¨nnen, muss der Schl¨ssel o u ausgetauscht werden. Dieser Austausch ist gleichzeitig ein Angriffspunkt auf die symmetrische Verschl¨sselung. Wird der Schl¨ssel beim Austausch von einem u u Angreifer abgefangen, so kann die Kommunikation entschl¨sselt werden. u Ein weiterer Angriffspunkt ist das Speichern des Schl¨ssels. Beim Speichern muss u ebenfalls auf die Geheimhaltung des Schl¨ssels geachtet werden. u Eine weiteres Verfahren zur Verschl¨sselung der Kommunikation ist die u asymmetrische Verschl¨sselung. Bei dem asymmetrischen Verfahren wird ein u o u o ¨ffentlicher und ein privater Schl¨ssel eingesetzt. Dabei muss der ¨ffentliche Schl¨ssel verteilt werden und der private Schl¨ssel sicher gespeichert werden. u u Der ¨ffentliche Schl¨ssel wird aus dem privaten Schl¨ssel generiert, aber es o u u muss sichergestellt werden, dass der private Schl¨ssel nicht aus dem ¨ffentlichen u o Schl¨ssel berechnet werden kann. u 1. Empf¨nger stellt seinen ¨ffentlichen Schl¨ssel dem Sender zur Verf¨gung a o u u 2. Sender verschl¨sselt die Nachricht mit dem empfangenen ¨ffentlichen u o Schl¨ssel u

6.4 Vertrauensw¨rdiges System u

53

3. Sender sendet verschl¨sselte Nachricht an Empf¨nger u a 4. Empf¨nger entschl¨sselt Nachricht mit dem privaten Schl¨ssel a u u Als drittes Verfahren sind Hashfunktionen zu nennen. Eine Hashfunktion bildet eine Nachricht beliebiger L¨nge auf einen Hashwert fester L¨nge 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 außerdem kollisionsfrei sein. Kollisionsfrei bedeutet, das keine zwei Nachrichten den selben Hashwert erzeugen.

6.4.2

Authentifizierung

Bei der Authentifizierung handelt es sich um einen Vorgang, bei dem uberpr¨ft u ¨ wird, ob der Kommunikationspartner der ist f¨r den er sich ausgibt. Es handelt u sich somit um einen Echtheitsnachweis. Dazu werden oft seperate Authentifizierungdienste auf eigenen Servern eingesetzt. Weit verbreitet ist das Needham Schroeder Protokoll. Legende: A: Sender, B: Empf¨nger, AS: Authentifizierungsserver, 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 Empf¨nger 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 Empf¨nger B, einem vereinbarten Sessionkey (SK) und einer mit KB a verschl¨sselten Nachricht. Diese mit KB verschl¨sselte Nachricht besteht aus u u dem SK und dem Sender A. Die ganze Nachricht ist mit dem KA verschl¨sselt. u 3. A sendet B die Nachricht (SK, A)KB A hat die von AS gesendete Nachricht entschl¨sselt. Den mit KB veru schl¨sselten Teil konnte sie nicht entschl¨sseln und sendet ihn genau so veru u schl¨sselt weiter an B. u 4. B sendet A die Nachricht (NB)SK B entschl¨sselt die von A gesendete Nachricht. Dadurch ist A gegen¨ber B auu u

54

6 Sicherheit in verteilten Systemen

thentifiziert, da A offensichtlich die von AS gesendete Nachricht entschl¨sseln u konnte. Um B gegen¨ber A zu authentifizieren, sendet nun B eine generierte u Nounce (NB) an A. Diese Nounce ist mit SK verschl¨sselt. u 5. A sendet B die Nachricht (NB - 1)SK A entschl¨sselt die von A gesendete Nachricht mit dem SK. Da B mit u dem SK verschl¨sselt hat, ist B auch authentifiziert, da B die mit KB veru schl¨sselte Nachricht entschl¨sseln konnte und daraus den SK erhalten hat. u u Zur Best¨tigung sendet A noch eine mit SK verschl¨sselte, leicht ver¨nderte a u a Nounce an B. Eine weitere Methode zur Authentifizierung ist die Digitale Signatur. Durch sie wird sichergestellt, dass die Nachricht tats¨chlich vom Absender kommt. Eine Dia gitale Signatur muss f¨lschungssicher sein und darf nur ein einziges mal verwendet a werden. Sie werden oft eingesetzt bei verschl¨sselter Emailkommunikation, eleku tronischen Handel, Bankverkehr. Das Ziel einer Digitalen Signatur ist nicht die Geheimhaltung der Nachricht. Mit einer Digitalen Signatur wird keine Nachricht verschl¨sselt Die Nachricht ist immer noch im Klartext lesbar.Ziel ist ausschließu lich die Authentifizierung. H¨ufig werden Hashfunktionen eingesetzt, weil sie sehr a schnell sind und somit auf schwacher Hardware umsetzbar. Die Authentifizierung mit einer Digitalen Signatur erfolgt in drei Schritten. S: Hashwert von Klartext gebildet und Ergebnis wird mit privaten Schl¨ssel u verschl¨sselt u E: entschl¨sselt den Hashwert der empfangenen Nachricht mit ¨ffentlichen u o Schl¨ssel u E: bildet Hashwert uber die empfangenen Daten und vergleicht ihn mit dem ¨ entschl¨sselten Hashwert u

6.4.3

Kerberos

Bei Kerberos handelt es sich um einen Authentisierungsdienst f¨r offene Systeme. u Der Kerberos Dienst wird eingesetzt, um im Netz verteilte Dienste von jedem Arbeitsplatzrechner aus benutzen zu k¨nnen. Alle Computer und Dienste (z.B. o Netzwerkdrucker) die das Kerberos-Protokoll implementiert haben, k¨nnen somit o leicht und sicher verwendet werden. Abbildung 6.1 zeigt den Aufbau und Ablauf einer Authentifizierung mit Kerberos. Der Kerberos Server selber besteht aus zwei Teilen. Dem Authentication Service und dem Ticket Granting Service. Der Authentication Service ubernimmt die Authentifikation des Client und der Ticket ¨ Granting Service stellt Tickets f¨r die Kommunikation zu dem Dienst aus. Als u erstes muss sich der Client gegen¨ber dem Kerberos Server authentifizieren(siehe u Schritt 1 in Abbildung 6.1). Dies l¨uft ¨hnlich dem bereits erl¨uterten Needham a a a

6.5 Secure Sockets Layer

55

Abbildung 6.1: Aufbau Kerberos

Schroeder Protokoll ab. Ist die Authentifizierung erfolgreich, erh¨lt 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 authentifizieren muss, sobald er einen anderen Dienst nutzen will. Ebenfalls wird ein Sessionkey ausgehandelt. Will der Client nun einen Dienst nutzen, schickt er sein TGT verschl¨sselt mit u dem Sessionkey an den Kerberos Server (siehe Schritt 3). Dieser entschl¨sselt 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 pr¨ft, ob der Client zur Nutzung berechtigt ist. Ist er berechtigt, dann wird ein u SessionKey ausgehandelt und Client und Dienst k¨nnen verschl¨sselt kommunio u zieren (siehe Schritt 6).

6.5

Secure Sockets Layer

Secure Sockets Layer oder kurz SSL bildet eine zus¨tzliche 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 Integrit¨t der Pakete a kann sichergestellt werden. Entwickelt wurde SSL urspr¨nglich von Netscape f¨r 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 Zertifikat zusammen mit seinem Public-Key

56

6 Sicherheit in verteilten Systemen

Abbildung 6.2: SSL Handshake

an den Client. Gleichzeitig fordert er das Zertifikat des Clients an. Der Client uberpr¨ft das Zertifikat des Server. u ¨ Phase 3: Der Client schickt sein Zertifikat zusammen mit seinem Public-Key an den Server. Dieser checkt das Zertifikat des Client. Der Client generiert das pre master secret (PMS). Beim PMS handelt es sich um eine Zufallszahl. Das PMW wird verschl¨sselt mit dem Public-Key des Server an den Server u gesendet. Der Server entschl¨sselt 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 verschl¨sselte Kommuniu kation. Sie verschl¨sseln 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 Sicherheitsl¨cken und Angriffsu ¨ punkte in Protokollen zu schließen. Des weiteren erstellt sie Zugriffsstatistiken. Es werden drei Typen von Firewall unterschieden. 1. Paketfilter: Filtert Pakete nach definierten 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 Empf¨nger. Genauso nimmt a der Proxy die Pakete des Empf¨ngers entgegen und leitet sie an den Sena der weiter. F¨r dieses Verhalten muss die Anwendung an die Verwendung des u Circuit-Relays als Proxy angepasst werden. 3. Application Gateway: Der Application Gateway hat gegen¨ber 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 klassifizieren, welche Pakete typisch und korrekt sind f¨r 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 Angriffs Meldung eines Angriffs automatische Vereitlung eines Angriffs 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 f¨r eine sp¨tere 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 Logfiles der E-Box, die diese nicht eindeutig als Angriff identifizieren konnte. So wird versucht neue Angriffsmuster zu finden. Handelt es sich um einen An-

58

6 Sicherheit in verteilten Systemen

Abbildung 6.3: Aufbau Intrusion Detection System

griff wird das Angriffsmuster in der D-Box gespeichert, damit die E-Box sp¨tere a Angriffe nach dem Muster direkt erkennen kann. Erkennt die A-Box einen neuen Angriff 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 m¨ssen Fehlalarme veru mieden werden. Bei der C-Box handelt es sich um ein Gegenmaßnahmesystem. Die C-Box verf¨gt zumeist aber nur uber passive Gegenmaßnahmen. Als Beiu ¨ spiel f¨r eine passive Gegenmaßnahme w¨re das Verst¨ndigen eines Mitarbeiters. u a a Aktive Gegenmaßnahmen (Abschotten des Systems, Angreifer blocken) werden selten durchgef¨hrt, weil die Konsequenzen bei einem Fehlalarm zu hoch w¨ren. 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 Angriffe analysiert. 2. System Integrity Verifiers: Die Integrit¨t von Systemdateien wird durch die a Verwendung von Pr¨fsummen uberwacht. Dadurch kann verhindert werden, u ¨ dass ein normaler User Admin Rechte erlangt. 3. Logfile Monitor: Die Logfiles von Servern werden nach bekannten Attacken untersucht. Bei verteilten Systemen muss hierf¨r ein zentralisiertes Logging u verwendet werden.

6.8 Fazit

59

4. Deception System: Deception Systeme enthalten oder simulieren absichtlich ¨ Sicherheitsl¨cken. Durch eine starke Uberwachung wird versucht Angreifer zu u fangen. Des Weiteren werden die Angriffstechniken der Angreifer analysiert, um sp¨tere Angriffe auf das Hauptsystem gegen diese Angriffe abzusichern. a

6.8

Fazit

In dieser Arbeit wurden viele Techniken vorgestellt, welche dazu dienen ein verteiltes System vor Angreifern zu sch¨tzen. Alle Techniken sind ausgereift und bieten u wenig Angriffspunkte. 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 f¨r die verteilten Systeme. Eine absolut u sichere Authentifizierung bringt nicht, wenn der Kommunikationsweg ungesichert ist und dadurch die Kommunikation abgefangen werden kann. Somit ist nur eine ¨ Kombination aus Authentifizierung (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 m¨ssen angepasst werden. Die Firewall u und das IDS m¨ssen richtig konfiguriert werden. Eine falsch konfigurierte Firewall u und IDS erschweren durch falsche Filter oder Fehlalarme die Arbeit des Administrators. Des Weiteren entsteht ein hoher Wartungsaufwand, denn die Systeme m¨ssen immer aktuell gehalten werden, um auf bekannte Sicherheitsl¨cken zu u u reagieren.

Literaturverzeichnis
[1] Steffen 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 f¨r sicherheitskritische Bereiche. Springer, 2008. u [4] Klaus Irmscher, Verteilte Systeme. Universit¨t Leipzig, 2011. a

60

6 Sicherheit in verteilten Systemen

7

Streaming

Markus Schramm

Inhaltsverzeichnis
7.1 7.2 Einleitung . . . . . . . . . . . . . . . . Grundlagen . . . . . . . . . . . . . . . 7.2.1 Begriffskl¨rung . . . . . . . . . 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, f¨hrt auch immer zu neuen u Technologien und M¨glichkeiten des Datenaustausches. In dieser Arbeit soll eine o neue Technik vorgestellt und behandelt werden mit dem Namen Streaming in deutsch auch Strom oder Str¨mung. Im Gegensatz zum Downloadverfahren wird o ein nur f¨r einen bestimmten zeitlichen Intervall vorhandenener Datenstrom zur u Verf¨gung gestellt, welcher jedoch h¨ufig nicht gespeichert wird. Diese Art der u a ¨ Ubertragung einer Datenkette erm¨glicht zahlreiche, neue M¨glichkeiten der o o Informationsweitergabe. Trotz der bisher noch nicht uberall bekannten Technik, ¨ wird sie bereits in einem großen Umfeld aktueller Anwendungen und Angebote eingesetzt. Im ersten Teil der Arbeit werden grundlegende Begriffe zum Thema StreamingMedia erl¨utert und der Mechanismus des Streamings erkl¨rt. Im darauf a a folgenden Teil wird der Unterschied zwischen HTTP-Streaming und LiveStreaming erl¨utert. Ein weiterer Teil der Arbeit erl¨utert die Technologien im a a speziellen und verwendeten Protokolle vom Streaming-Verfahren. Abschließend

62

7 Streaming

werden die verschiedene Verteilstrategien Broadcast, Unicast, Multicast und Splittung betrachtet und ein Fazit gezogen.

7.2
7.2.1

Grundlagen
Begriffskl¨rung a

Zun¨chst werden die Begriffe Streaming-Media, Streaming und Streams erkl¨rt. a a Definition nach Wegner: ”Der Begriff Streaming-Media bezeichnet eine Internet-Technologie, bei der Filme oder Sprache bzw. Musik in Echtzeit direkt aus dem Inter- oder Intranet abgespielt werden k¨nnen. Neu an der Streaming-Technik ist, dass lange o Wartezeiten entfallen. Die Dateien k¨nnen direkt angespielt werden.” o Nach Hendrick: Beschr¨nkung auf Bitrate des Kanals, mit Schwankungen a Erfordert Fehlertoleranzmechanismen

Streaming bezeichnet den Vorgang der Daten¨bertragung. u ¨ Ubertragene Signale bzw. Programme werden als Streams oder Live-Streams bezeichnet

7.2.2

Mechanismus

Ein Streaming Media-System setzt sich grunds¨tzlich aus 5 Bestandteilen a ¨ zusammen: Media-Quelle, Encoder, Server, Ubertragunsweg und Empf¨nger a (siehe Abbildung 7.1). Die Aufgabe vom Encoder ist vor allem die Reduzierung des Speicherbedarfs großer Mediendateien, weil diese unkomprimiert nicht geeignet sind, im ¨ Internet als Stream Ubertragen zu werden. Als Streaming Server bezeichnet man einen Server f¨r 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 Ver¨ffentlichungsverzeichnis des Webservers abgelegt, so wie o HTML-Files oder Bilder. Die Datei wird wie ein normaler Download abgerufen. W¨hrend des Downloads wird dabei ein Ziwschenpuffer gef¨llt, 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 ben¨tigt wird. o Nachteilig ist die Verwendung des langsamen HTTP-Protokolls und die ¨ fehlende M¨glichkeit, die Ubertragungscharakteristika zu optimieren. Ferner ist o ¨ die Ubertragung von Live-Ereignissen mittels Download bzw. Pseudo-Streaming in der Regel nicht m¨glich. Großer Vorteil ist, dass keine zus¨tzliche Portfreigabe o a f¨r Firewalls n¨tig ist, da diese standartm¨ßig Port 80 bei Webzugriffen zulassen. u o a Bekannte Vertreter dieses Prinzips ist bspw. der Content-Provider YouTube. Live-Streaming Diese Methode wird bei besonders leistungsf¨higen Streaming-Netzwerken a verwendet. Der Player (auch Client) wird h¨ufig 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 F¨llen wird immer eine zus¨tzliche a a Verbindung zum spezifischen 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 Umst¨nden schlechtere Qualit¨t. a a Dieses Prinzip wird f¨r Webradios oder die Bereitstellung von IP-TV veru wendet.

7.3.2

Encoding

Wie bereits erw¨hnt wurde, benutzt ein Streaming-System Kodierungen und a Kompressionsalgorithmen, um einen Echtzeitstrom bestm¨glich 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 schließt auch eine Verschl¨sselung mit ein. Bei der Kompression wird u ¨ Speicherplatz eingespart, indem Uberfl¨ssige Informationen weckgelassen und u die restlichen Informationen in k¨rzerer Form dargestellt werden k¨nnen. u o Durch die Kodierung am Server und die nachtr¨gliche 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 k¨nnen im Ubertragungskanal aufgetretene St¨rungen beim Empf¨nger o o a berichtigt werden. Daten und Fehler k¨nnen voneinander getrennt werden. Die o urspr¨nglichen Daten erhalten vom Encoder zus¨tzliche 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 Daten¨bertragung ein. Die am h¨ufigsten verwendeten Protokolle werden hier voru a gestellt. Real-Time-Transport-Protokoll (RTP) ¨ RTP erm¨glicht die kontinuierliche Ubertragung von Streams (¨ber IP-basierte o u ¨ Netzwerke). Es arbeitet uber UDP (siehe Abbildung 7.3) und Ubermittelt die ¨ gew¨nschten 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 Empf¨nger innerhalb einer a ¨ RTP-Session RTCP-Pakete mit Feedback uber erhaltene Daten und Benutzerin¨ formationen. RTCP dient außerdem der Aushandlung und Einhaltung von Qualityof-Service-Parametern (QoS) durch den periodischen Austausch von Steuernachrichten zwischen Sender und Empf¨nger. Diese Einhaltung von QoS bedeutet, a dass der Server eine R¨ckmeldung vom Client mit Informationen uber bisherige u ¨ ¨ Qualit¨t des Streams erh¨lt. Daraus kann eine Anpassung der Ubertragungsrate a a erfolgen. Der Austausch von Steuernachrichten dient des Weiteren der Identifikation 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 heißt, sowohl Server als auch Client k¨nnen Anfragen uber bestimmte Daten absetzen. RTSP o ¨ dient haupts¨chlich der Steuerung von Datenstr¨men (siehe Abbildung 7.4), wobei a o ¨ keine Nutzdaten Ubertragen werden. Durch RTSP ist es m¨glich den Stream voro und zur¨ckzuspulen, sowie zu pausieren. u

Abbildung 7.4: Beispiel f¨r die Arbeitsweise von RTSP u

7.3.4

Verteilstrategien

Broadcast Der Begriff Broadcast (breit = breit, cast = werfen,streuen) beschreibt in der Informationstechnik die ungezielte Verbreitung von Informationen in der Fl¨che. a Rundfunk uber Satellit ist das klassische Beispiel f¨r die Ausstrahlung von u ¨ Informationen von einem Sender an viele Empf¨nger. Die Empf¨nger haben dabei a a keinen Einfluss auf die Pr¨sentation des Informationsangebots durch den Sender. a Sie k¨nnen nur das empfangen, was gerade ausgestrahlt wird. o Unicast Computernetzwerke bieten im Gegensatz zur Ausstrahlung uber Funkfrequenzen ¨ individuelle, bidirektionale Kan¨le (sog. Punkt-zu-Punkt)-Verbindungen oder a point-to-point) zu jedem angeschlossenen Empf¨nger. Seit die Leistungsf¨higkeit a a ¨ digitaler Ubertragungswege und Endger¨te 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 Verf¨gung u ¨ stehende Bandbreite schnell aufgebraucht. Ublicherweise ist die Netzanbindung eines Internetservers daher der erste begrenzende Leistungsfaktor. Ein Beispiel f¨r 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 Großteil 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 f¨r eine ganze u Gruppe von Rechnern stehen kann (siehe Abbildung 7.5). Der IP-Adressraum besitzt einen speziell f¨r diesen Fall reservierten Adressbereich, und die zugeh¨rigen u o IP-Adressen werden als Multicast-Adressen bezeichnet. W¨hrend man normalera weise eine IP-Adresse direkt mit dem Rechner identifizieren 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 pr¨ft der intelligente u

68

7 Streaming

(multicast-f¨hige) Router im Netz, ob f¨r ein am Server anliegendes Live-Signal a u in seiner Umgebung Interesse besteht. Sobald ein Client in seiner Umgebung das Live-Signal empfangen m¨chte, baut der Router zum n¨chstgelegenen (multicasto a f¨higen) Router eine Verbindung auf, um schließlich das Live-Signal verteilen zu a k¨nnen. Da sich nur der Router, der einem oder mehreren Clients am n¨chsten o a steht, wie ein Splitter verh¨lt, wird bei dieser Art des Datenaustauschs die zur a Verf¨gung stehende Bandbreite am sparsamsten ausgenutzt. Der große Nachteil u dieser netzwerknahen L¨sung besteht darin, dass das bestehende Backbone-Netz o aus Gr¨nden der Fehleranf¨lligkeit und Kosten nicht multicast-f¨hig ist. Dennoch u a a f¨r IP-TV verwendet da Internet-Service-Provider innerhalb ihres Verteilnetzes u f¨r Kompatibilit¨t 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 dr¨ngt sich f¨r Live-Sendungen auf, wenn ein gr¨ßeres a u o Zuschauerpotenzial in den USA uber eine schlecht angebundene transatlantische ¨ Verbindung Inhalte abrufen m¨chte, die im deutschen Internet-Backbone angeboo ten werden. Warum sollten 5000 Amerikaner, die das gleiche Live-Event verfolgen m¨chten, 5000 parallele Verbindungen nach Deutschland aufbauen, wenn es doch o ausreichen w¨rde, das Signal nur einmal nach Amerika zu ubertragen und erst dort u ¨ 5000-mal zu splitten. Das Splitting f¨r AV-Server wurde im Internet in Ermangeu lung weitfl¨chiger Verf¨gbarkeit 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. Zus¨tzlich erm¨glicht a o das Splitting durch intelligente Kaskadierung auch die Einsparung von Encodern durch die Vervielfachung mehrerer Encoder-Str¨me in verschiedene Netze (siehe o Abbildung 7.7).

7.4 Fazit

69

Abbildung 7.7: Beispiel f¨r 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 k¨nnten diese Services gar nicht realisiert werden. o Eine entscheidende Rolle wird die Technik auch in der Zukunft spielen, da immer verst¨rkter eine bestimmte Servicequalit¨t 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 f¨r das globale Internet. Hier sollten u die Netzbetreiber nachbessern um die Streaming-Technik effizienter ausnutzen.

Literaturverzeichnis
[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, Universit¨t Osnabr¨ck 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

8

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 durchgef¨hrten Transaktionen sind Thema dieser Arbeit. Vor allem wird sich u n¨her mit dem Begriff der Verteilten Transaktionen“ befasst und versucht dabei a ” die grunds¨tzlichen Unterschiede gegen¨ber normalen (zentralisierten) Transaka u tionen deutlich zu machen. Ziel dieser Arbeit ist es die theoretischen Grundlagen n¨her zu beschreiben, wozu M¨glichkeiten der Partitionierung, das Sperren und a o Freigeben von Datenbest¨nden, sowie verschiedene Sperrfreigabemechanismen ina nerhalb unterschiedlicher Commit-Struktur z¨hlen. a

72

8 Verteilte Transaktionen

8.2

Verteilte Datenbanksysteme

Regul¨re Datenbanksysteme sind zentralisiert, was bedeutet dass sich der Daa tenbankenserver nur an einem bestimmten, zentralen Ort befindet. Es existieren jedoch beispielsweise Firmen, welche aus mehreren Zweigstellen aufgebaut sind und ggf. Kundendaten f¨r jede dieser Zweigstellen, innerhalb einer Datenbank, u verwaltet m¨ssen. In einem solchen Fall w¨re es sinnvoll, die jeweiligen Daten u a nicht nur an einem zentralen Ort zu hinterlegen, da Zugriffe von außerhalb uber ¨ eine lange Leitung erfolgen, was ungewollte Verz¨gerungen 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 v¨llig verschiedenen Orten befinden k¨nnen. o o

Abbildung 8.1: Verteiltes Datenbanksystem

8.2.1

Partitionierung

Unter einer Partitionierung versteht man die Aufteilung eines zentralen Datenbestandes (z.B. Tabelle f¨r 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 f¨r Fl¨ge innerhalb eines u u Flugunternehmens speichert. In folgender Abbildung befindet sich der zentrale Datenbestand vorerst in D¨sseldorf. u

8.2 Verteilte Datenbanksysteme

73

Abbildung 8.2: Zentraler Datenbestand in D¨sseldorf 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 Fl¨ge tats¨chlich gebucht wurden. Das bringt den Vorteil mit sich dass lokale Dau a ten besser und schneller verarbeitet werden k¨nnen bzw. Zugriffe (lesen,schreiben) o schneller erfolgen. H¨tten wir f¨r unseren Flughafen Zweigstellen in Erfurt und a u Frankfurt, welche jeweils eigene, lokale Fl¨ge zu verwalten h¨tten, so w¨rde 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, findet eine spaltenweise Zerlegung der Tabelle statt. Das w¨re beispielsweise dann von Vorteil, wenn wir a innerhalb eines Ortes, aber in unterschiedlichen Abteilungen, verschiedene Spalten

74

8 Verteilte Transaktionen

einer Tabelle ben¨tigten. So w¨rde beispielsweise eine Abteilung Ticketverwalo u ” tung“ die Flugnummern, Ticketnummern und die Buchungsdaten lokal verwalten, wobei die Abteilung Platzreservierung“ die Ticket- und Platznummern bek¨me. a ” Wichtig ist es hier vor allem weiterhin eine Beziehung zwischen beiden Fragmenten herstellen zu k¨nnen. Dazu muss ein eindeutiges Attribut als Fremdschl¨ssel o u festgelegt werden. Im unteren Beispiel haben wir uns f¨r das Attribut Ticketu ” nummer“ entschieden.

Abbildung 8.4: Vertikal verteilte Tabelle: Flugbuchungen“ ”

8.3

Transaktionen in verteilten DBS

Eine verteilte Transaktion durchl¨uft in der Regel drei Phasen. Ersa tens mit dem Beginn der Transaktion, zweitens den darauffolgenden 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. Atomarit¨t: Eine Transaktion muss ganz oder gar nicht durchgef¨hrt werden a u und darf w¨hrend ihrer Durchf¨hrung nach außen f¨r niemanden sichtbar sein. a u u Konsistenz: Nach einer erfolgreichen Transaktion muss sich die Datenbank wieder in einem konsistenten Zustand befinden. Isolation: Alle Aktionen innerhalb einer Transaktion m¨ssen vor anderen, paru allel ablaufenden Transaktionen, verborgen bleiben. Die Transaktionen d¨rfen u
1 2

Abbruch der gesamten Transaktion R¨ckf¨hrung des Datenbestandes in einen konsistenten Zustand(Ausgangszustand) u u

8.3 Transaktionen in verteilten DBS

75

sich nicht gegenseitig beeinflussen. Dauerhaftigkeit: Durch abgeschlossene Transaktionen vorgenommene ¨ Anderungen m¨ssen dauerhaft erhalten bleiben und d¨rfen nur durch u u darauffolgende Transaktionen beeinflusst werden.

8.3.2

Zwei-Phasen-Sperrprotokoll

Da eine Transaktion nicht durch andere, parallel ablaufende, Transaktionen behindert werden darf, m¨ssen immer Sperren gesetzt werden. Alle f¨r die Transaktion u u ben¨tigten Objekte werden somit f¨r die Zeitdauer der Transaktion f¨r parallel o u u ablaufende Transaktionen unzug¨nglich gemacht, um somit fehlerhafte und inkona sistente Zust¨nde 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 ben¨tigten Sperren erhebt (Wachstumsphase) und o diese nach Ablauf der Transaktionen wieder freigibt (Schrumpfungsphase). Die folgende Grafik macht dies deutlich.

Abbildung 8.5: Ablauf des Zwei-Phasen-Sperrprotokolls

Falls eine weitere Transaktion zum gleichen Zeitpunkt auf die gesperrten Daten zugreifen m¨chte, kann es zu einen Deadlock3 kommen. Um das zu unterbinden o werden diesbez¨glich Timeouts gesetzt, die daf¨r sorgen dass wenn nach einer u u bestimmten Zeit keine R¨ckmeldung 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 repr¨sentiert 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

8 Verteilte Transaktionen

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 l¨uft immer in zwei Phasen ab. In der ersten Phase a ¨ werden s¨mtliche 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 m¨glich. In o ¨ der zweiten Phase werden die gesetzten Sperren aufgehoben und alle Anderungen ¨ sichtbar gemacht. Dazu werden alle vorhergehenden Anderungen (befor-Images) gel¨scht. Kommt es w¨rend der ersten Phase zu einem Ausfall, so wird die Transo a aktion vollst¨ndig zur¨ckgesetzt 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 stattfinden. Es m¨ssen 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 f¨r die u lokal ausgef¨hrten 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 ausgef¨hrt 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 f¨r den Koordinator und eine in welcher sich die dem Koordinator u untergeordneten Agenten befinden. Da die Commit-Behandlung parallel m¨glich o ist, beschr¨nkt sich die Dauer einer solchen Transaktion auf die Teiltransaktionen a des langsamsten Agenten.

Abbildung 8.6: Zentralisierte Commit-Struktur

Lineare Commit-Struktur Hier findet ein iterativer Austausch von Nachrichten statt. Die Dauer einer solchen Transaktion ist somit gewissermaßen von der Anzahl der Agenten abh¨ngig. a Dennoch ist die lineare Commit-Behandlung die einzige in welcher Nachrichten eingespart werden k¨nnen, 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

8 Verteilte Transaktionen

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, findet immer in zwei Phasen statt. Innerhalb der Phasen kommt es zwischen den verschiedenen Knotentypen zum Austausch spezieller Nachrichten. Daf¨r sind innerhalb der verschiedenen Commit-Strukturen unteru schiedliche Ablaufmodelle vorzufinden.

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, enth¨lt 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

zur¨ckgesetzt, 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 n¨chsten 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, zur¨ck. In allen Agenten erfolgt eine Protokollierung, worauf die Sperren u freigegeben werden. Der Initiator sendet anschließend 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 Erh¨hung der Agenteno anzahl auch zu einer signifikanten Erh¨hung von Antwortzeiten kommen. o

80

8 Verteilte Transaktionen

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 Vorg¨nger 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 Vorg¨nger. 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 f¨r eine solches Konzept. Jedoch muss beachtet weru den das verteilte Transaktionen weitaus komplexer und dadurch auch um einiges Fehleranf¨lliger 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¨

Literaturverzeichnis

81

Abbildung 8.11: Hierarchische Zwei-Phasen-Freigabe

Dateien auf allen Knoten von gr¨ßter Wichtigkeit, um ggf. Fehler zu korrigieren o und Datenbest¨nde dauerhaft konsistent zu halten. a

Literaturverzeichnis
[1] G¨nther Bengel, Grundkurs Verteilte Systeme: Grundlagen und Praxis des u Client-Server-Computing - Inklusive aktueller Technologien wie Web-Services u. a. - F¨r Studenten und Praktiker, 3. Auflage, 24. Februar 2004 u [2] Harm Knolle, Vertiefung Datenbanken: Datenbanken in Client / Server Systemen, 11. November 2010