Verteilte Systeme 2011

Verteilte SystemeOliver BRAUN (Hrsg.)

Fakultt Informatik a Fachhochschule Schmalkalden

Wintersemester 2011/2012

Inhaltsverzeichnis1 Fehlertoleranz in verteilten Systemen Ricardo Hohmann . . . . . . . . . . . . . . . 1

2 Das Google File System . . . . . . . . . . . . . . . . . . . . . . . Oliver Wolf 3 Verteilte Multimediasysteme . . . . . . . . . . . . . . . . . . . . Philipp Richardt 4 OpenCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roger Jger a 5 Peer-to-Peer-Systeme . . . . . . . . . . . . . . . . . . . . . . . . Tim Achtert 6 Sicherheit in verteilten Systemen . . . . . . . . . . . . . . . . . . Mario Fhr o 7 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Markus Schramm 8 Verteilte Transaktionen . . . . . . . . . . . . . . . . . . . . . . . Christian Reibeholz

11

23

35

47

49

61

71

IV

Inhaltsverzeichnis

1

Fehlertoleranz in verteilten Systemen

Ricardo Hohmann

Inhaltsverzeichnis1.1 Grundlagen . . . . . . . . . . . . . . . . . 1.1.1 Denition . . . . . . . . . . . . . . 1.1.2 Grundlegende Konzepte . . . . . . 1.1.3 Fehlermodelle . . . . . . . . . . . 1.1.4 Fehlermaskierung durch Redundanz Prozesselastizitt . . . . . . . . . . . . . . a 1.2.1 Entwurfsaspekte . . . . . . . . . . 1.2.2 Fehlermaskierung und Replikation . 1.2.3 k-Fehlertoleranz . . . . . . . . . . RPC-Semantik beim Vorliegen von Fehlern 1.3.1 Client ndet Server nicht . . . . . 1.3.2 Verlorene Anforderungsnachricht . 1.3.3 Server-Absturz . . . . . . . . . . . 1.3.4 Verlorene Antwortnachricht . . . . 1.3.5 Client-Absturz . . . . . . . . . . . Wiederherstellung . . . . . . . . . . . . . . 1.4.1 Einfhrung . . . . . . . . . . . . . u 1.4.2 Prfpunkte . . . . . . . . . . . . . u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 3 3 3 4 5 5 6 6 6 7 8 9 9 9

1.2

1.3

1.4

Kennzeichnend fr verteilte Systeme ist der partielle Ausfall. Dieser tritt auf, u wenn eine Komponente in einem verteilten System ausfllt. Andere Komponenten a knnen ihre Arbeit fortsetzen und so ggf. weiterhin Anforderungen bearbeiten. o Ein Entwurfsziel beim Aufbau eines verteilten Systems sollte es daher sein, dass das System nach partiellen Ausfllen automatisch wiederhergestellt werden kann a und auch bei auftretenden Fehlern weiterhin funktionsfhig bleibt. a Was es fr ein verteiltes System bedeutet, fehlertolerant zu sein und wie eben u dies umgesetzt werden kann, wird auf den folgenden Seiten beschrieben.

2

1 Fehlertoleranz in verteilten Systemen

1.1

Grundlagen

In diesem Kapitel werden Begrie erlutert, die fr das Verstndnis fehlertolerana u a ter Systeme notwendig sind.

1.1.1

Denition

Fehlertoleranz (von lat. tolerare, erleiden, erdulden) ist die Eigenschaft eines technischen Systems, seine Funktionsweise auch aufrechtzuerhalten, wenn unvorhergesehene Eingaben oder Fehler in der Hardware oder Software auftreten.[1]

1.1.2

Grundlegende Konzepte

Ein verteiltes System mit hoher Fehlertoleranz ist auch gekennzeichnet durch eine hohe Verlsslichkeit. Diese deckt vier praktische Anforderungen ab, die an a verteilte Systemen gestellt werden. Verfgbarkeit ist die Eigenschaft, dass ein System unmittelbar zur Nutzung beu reitsteht, wenn ein Zugri erfolgt. Im Allgemeinen drck die Verfgbarkeit u u die Wahrscheinlichkeit aus, dass ein System zu einer bestimmten Zeit zur Verfgung steht und funktioniert. u Zuverlssigkeit ist die Eigenschaft, dass ein System fortlaufend fehlerfrei ausa gefhrt werden kann. Dabei bezieht sich die Zuverlssigkeit auf einen zusamu a menhngenden Zeitintervall, whrend die Verfgbarkeit sich auf Zeitpunkt a a u bezieht. Sicherheit ist die Eigenschaft, die besagt, dass nichts katastrophales passieren darf, wenn ein System vorbergehend nicht korrekt funktioniert. u Wartbarkeit ist die Eigenschaft, die besagt, wie einfach oder schwierig es ist, ein ausgefallenes System zu reparieren. Von einem Ausfall ist die Rede, wenn ein System seine Zusagen nicht mehr einhalten kann. Die Ursache eines Ausfalls wird als Fehler bezeichnet. Es gibt verschiedene Mglichkeiten der Klassikation von Fehlern in verteilten Syso temen. Folgend sind Fehler nach chronologischen Aspekten klassiziert, whrend a im nchsten Kapitel 1.1.3 Fehler nach ihrem Typ klassiziert werden. a Vorbergehende Fehler treten einmalig auf. Bei Wiederholung der Operatiu on tritt kein Fehler mehr auf. Derartige Fehler knnen auftreten, wenn o Ubertragungswege gestrt werden. o

1.1 Grundlagen

3

Periodischer Fehler treten mehrfach auf, ohne dass sich ein Muster abzeichnet. Diese Fehler sind schwierig zu Diagnostizieren. Mgliche Ursache ist ein o Wackelkontakt in einem Stecker. Permanente Fehler treten auf, wenn eine Komponente im verteilten System nicht mehr funktioniert. Eine Fehlerbehebung ist nur durch Ersatz der fehlerhaften Komponente mglich. o

1.1.3

Fehlermodelle

Die folgende Auistung soll ein Gefhl dafr vermitteln, wie schwerwiegend veru u schiedene Fehler sind. Der Bezeichnung eines Fehlertyps folgt jeweils eine kurze Beschreibung. Absturzfehler: Ein Server wurde unterbrochen, hat aber bis zu diesem Zeitpunkt korrekt gearbeitet. Auslassungsfehler: Ein Server reagiert nicht auf eingehende Anforderungen. Empfangsauslassung: Ein Server erhlt keine eingehenden Anforderungen. a Sendeauslassung: Ein Server sendet keine Nachrichten. Timing-Fehler: Die Antwortzeit eines Servers liegt auerhalb eines festgelegten Zeitintervalls. Antwortfehler: Die Antwort des Servers ist falsch. Wertfehler: Der Wert der Antwort ist falsch. Statusbergangsfehler: Der Server weicht vom korrekten Steueruss ab. u Zufllige Fehler: Ein Server erzeugt zu zuflligen Zeiten zufllige Antworten. a a a Die zuflligen Fehler sind am schwierigsten zu beheben. Sie werden auch Bya zantinische Fehler1genannt. So kann es vorkommen, dass ein Server Ausgaben erzeugt, die nie erzeugt werden sollten, aber nicht als fehlerhaft erkannt werden. Noch schlimmer wird es, wenn dies in Zusammenarbeit mit anderen Servern geschieht.

1.1.4

Fehlermaskierung durch Redundanz

Redundanz ist die wichtigste Technik zur Maskierung von Fehlern. Maskierung ist das Verbergern von Fehlern vor anderen Prozessen. Es gibt 3 Arten von Redundanz.1 Der Begri byzantinischbezieht sich auf das byzantinische Reich, Zeit (330 - 1435) und Ort (der Balkan und die heutige Trkei) endloser Verschwrungen und Intrigen, die in Herrscheru o kreisen als ublich galten.

4


Informationsredundanz: Durch das Hinzufgen von Prfbits wird die Herstelu u lung von Daten ermglicht. o zeitliche Redundanz: Eine Aktion wird ausgefhrt und ggf. wiederholt. Ein Beiu spiel ist die Verwendung von Transaktionen. Besonders praktisch ist diese Form der Redundanz bei vorbergehenden und periodischen Fehlern. u physische Redundanz: Der Verlust / die Fehlfunktion bestimmter Komponenten wird durch Replikation kompensiert. Dies kann mithilfe von Software oder Hardware erfolgen.

1.2

Prozesselastizitt a

In diesem Kapitel wird sich mit der Frage befasst, wie Fehlertoleranz realisiert werden kann, wenn die Prozesse an sich fehlerhaft sind.

1.2.1

Entwurfsaspekte

Der wichtigste Ansatz zum Schutz gegen Prozessfehler ist die Replikation identischer Prozesse in Gruppen. Alle Prozesse, die sich in einer Gruppe benden, empfangen die Nachrichten, die an die Gruppe gesendet werden. Wenn ein Prozess fehlerhaft ist, so kann ein anderer Prozess seine Arbeit ubernehmen. Die Prozessgruppen knnen dynamisch sein. Neue Gruppen knnen erzeugt oder o o alte zerstrt werden. Weiterhin ist es jederzeit mglich, dass Prozesse Gruppen o o beitreten oder sie verlassen. Ein Prozess kann in mehreren Gruppen gleichzeitig sein. Ein mglicher Ansatz zur Verwaltung der Gruppen und Prozesse ist die o Verwendung eines Gruppenservers. Weiterhin lassen sich die Prozessgruppen in ache und hierarchische Gruppen einteilen (siehe Abbildung 1.1). In der achen Gruppe (a) sind alle Prozesse identisch. Entscheidungen werden gemeinsam getroen und jeder Prozess der Gruppe kommuniziert mit jedem anderen. In einer hierarchischen Gruppe (b) hingegen gibt es einen Koordinator, den Chef der Gruppe. Die Arbeiter kommunizieren nicht untereinander, sondern nur mit dem Koordinator. Beide Einteilungen haben ihr Vor- und Nachteile. Ein Vorteil einer achen Gruppe liegt darin, dass sie keinen Ausfallpunkt hat, whrend eine hierarchische Gruppe a nicht mehr weiterarbeiten kann, wenn der Koordinator ausfllt. Ein Nachteil eia ner achen Gruppe ist die komplizierte Entscheidungsndung per Abstimmung, whrend bei hierarchischen Gruppen Entscheidungen allein durch den Koordinator a getroen werden knnen. o

1.2 Prozesselastizitt a

5

Abbildung 1.1: Kommunikation in Prozessgruppen

1.2.2

Fehlermaskierung und Replikation

Prozessgruppen sind ein Teil der Lsung zum Aufbau fehlertoleranter Systeme. o Einzelne Prozesse werden repliziert, um einen einzigen (ungeschtzten) Prozess u durch eine (fehlertolerante) Gruppe zu ersetzen. Es gibt zwei Mglichkeiten fr o u eine solche Replikation, nmlich primrbasierte Protokolle und Protokolle mit a a repliziertem Schreiben. Primrbasierte Protokolle basieren auf hierarchischen Gruppen. Anforderungen a werden an einen primren Prozess weitergeleitet. Fllt dieser aus, wird auf einen a a Backup-Prozess zugegrien, der die Anforderung erfllt. u Protokolle mit repliziertem Schreiben basieren auf achen Gruppen. Anforderungen knnen von jedem der Gruppenmitglieder erfllt werden. o u

1.2.3

k-Fehlertoleranz

Die folgenden Ausfhrungen beziehen sich auf Systeme mit repliziertem Schreiu ben. Der Wert kgibt ein Ma an, wie fehlertolerant eine Prozessgruppe ist. Er lsst sich wie folgt beschreiben. Ein System ist k-fehlertolerant, wenn es a Fehler in k Komponenten kompensieren und seine Aufgaben dennoch erledigen kann.[2]Eine Prozessgruppe mit k+1 replizierten Prozessen ist somit auch bei Ausfall von k Prozessen noch funktionsfhig. Dies gilt jedoch nicht, wenn die feha lerhaften Prozesse byzantinische Fehler aufweisen. Dann werden 2k+1 Prozesse bentigt, um ein System k-fehlertolerant zu machen. o

6


1.3

RPC-Semantik beim Vorliegen von Fehlern

Nachdem das letzte Kapitel von Fehlern handelt, die bei fehlerhaften Prozessen auftreten knnen, soll es in diesem um den Umgang mit fehlerhafter Kommuo nikation gehen. Ein Kommunikationskanal kann dabei Absturz-, Auslassungs-, Timing- und zufllige Fehler aufweisen. a Bei der Punkt-zu-Punkt-Kommunikation knnen Fehler teilweise durch die o Verwendung eines zuverlssigen Transportprotokolls wie TCP maskiert wera den. So werden Auslassungsfehler mithilfe von Besttigungen und erneuten a Ubertragungen maskiert. Nicht maskiert werden Absturzfehler. Meist wird allerdings der Client durch das Werfen einer Ausnahme uber den Absturz des Servers informiert. Die einzige Mglichkeit der Maskierung ist die automatische Einricho tung einer neuen Verbindung. Auf einer hheren Ebene der Client-Server-Kommunikation sind Kommunikatio onsfunktionen wie RPC (Remote Procedure Calls) angesiedelt. RPCs beschreiben entfernte Prozessaufrufe, die wie lokale Prozessaufrufe aussehen und sich auch, bei korrekt funktionierendem System, genauso verhalten. Die Kommunikation wird verborgen. In den folgenden Kapiteln werden fnf Fehlerklassen unterschieden, u die in RPC-Systemen auftreten knnen. Es werden die auftretenden Probleme o und mgliche Lsungen beschrieben. o o 1. Der Client ndet den Server nicht 2. Die Anforderungsnachricht vom Client an den Server geht verloren. 3. Der Server strzt ab, nachdem er eine Anforderung empfangen hat. u 4. Die Antwortnachricht vom Server an den Client geht verloren. 5. Der Client strzt ab, nachdem er eine Anforderung gesendet hat. u

1.3.1

Client ndet Server nicht

Die Ursache fr einen solchen Fehler kann sein, dass der Server nicht mehr luft u a oder sich in Wartung bendet. Auch kann Server-seitig eine neue Schnittstelle installiert worden sein, welche die alte ablst und fr den Client nicht aundbar o u ist. Eine mgliche Lsung ist das Werfen einer Ausnahme. Nachteil dieses Ano o satzes ist, dass die Transparenz verloren geht. Ein Fehler wie Kann Server nicht nden.knnte in einem lokalen System gar nicht auftreten. o

1.3.2

Verlorene Anforderungsnachricht

Dieser Fehler ist einfach zu beheben. Eine mgliche Lsung ist der Einbau eines o o Client-seitigen Timers. Ist nach Zeit t noch keine Antwort auf die Anforderung

1.3 RPC-Semantik beim Vorliegen von Fehlern

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 knnen Probleme auftreten, die in Kapitel 1.3.4 erklrt o a werden.

1.3.3

Server-Absturz

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

Zur vereinfachten Anschauung soll die Abbildung 1.2 dienen. In (a) ndet die normale Ereignisabfolge statt. Eine Anforderung trit ein, wird ausgefhrt, und u eine Antwort wird gesendet. (b) und (c) zeigen Fehlerflle, bei denen der Server a abstrzt. Dabei strzt in (b) der Server erst nach Ausfhrung der Anforderung ab, u u u whrend er in (c) vor der Ausfhrung abstrzt. Problematisch ist, dass die korrekte a u u Behandlung des Absturzes sich in beiden Fllen unterscheidet. In (b) muss das a System den Fehler an den Client zurckmelden, whrend in (c) die Anforderung u a einfach erneut ubertragen werden kann. Fr den Client gibt es keinen Unterschied u bei (b) oder (c), er erhlt in beiden Fllen keine Antwort. a a Im folgenden soll ein Beispiel vorgestellt werden, das verdeutlicht, welche Konsequenzen ein Serverabsturz (Crash) bei verschiedenen Fehlerfall-Strategien von Client und Server haben kann. Uber einen RPC soll ein Text ausgedruckt werden. Der Client sendet die Anforderung, einen Text zu drucken. Der Server reagiert, indem er den Text ausdruckt (Print) und eine Besttigungsnachricht (Message) a an den Client sendet. Nach einem Crash sendet der Server die Nachricht an den Client, dass er abgestrzt ist und jetzt wieder luft. u a Der Server kann zwei Strategien verfolgen. Erstens kann er erst den Text drucken (P) und danach die Besttigung senden (M). Zweitens kann er aber auch erst a die Besttigung senden (M) und danach den Text drucken (P). a Der Client kann vier Strategien verfolgen, wenn er vom Server die Absturznachricht erhlt (C). Erstens kann er immer eine neue Anforderung absetzen. Zweitens a kann er nie eine neue Anforderung absetzen. Drittens kann er nur dann eine neue Anforderung absetzen, wenn er eine Besttigung erhalten hat und viertens kann a er nur dann eine neue Anforderung absetzen, wenn er keine Besttigung erhalten a

8


hat. Die Konsequenzen der acht sich ergebenden Strategiekombinationen verdeutlicht Abbildung 1.3.

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

Die Klammern zeigen an, dass das Ereignis nicht mehr eintreten kann. Es ist klar ersichtlich, dass es keine Kombination aus Client- und Server-Strategie gibt, die fr alle mglichen Ereignisabfolgen korrekt funktioniert. Der Client kann nie u o wissen, ob der Server nach oder vor Ausdruck des Textes abgestrzt ist. u

1.3.4

Verlorene Antwortnachricht

Wie auch schon in Kapitel 1.3.2 ist auch in diesem Kapitel das Hauptproblem, dass der Client nicht wei, warum er vor Ablauf seines Timers keine Antwort erhalten hat. Er wei nicht, ob die Anforderung oder die Antwort verlorengegangen oder ob der Server schlichtweg zu langsam ist. Das standardisierte Verhalten ist die Neuanforderung. Bei Operationen, die beliebig oft wiederholt werden knnen, o hat eine Neuanforderung keine negativen Auswirkungen. Eine Anforderung ohne Seiteneekte, die beliebig oft ausgefhrt werden kann, wird auch als idempotent u bezeichnet. Allerdings gibt es auch Anforderungen, die Seiteneekte hervorru fen. Ein berhmtes Beispiel ist die Uberweisung. Diese darf nur genau einmal u ausgefhrt werden. u

1.4 Wiederherstellung

9

Eine mgliche Lsung ist, jeder Anforderung des Clients eine Folgenummer zuo o zuweisen, sodass der Server den Unterschied zwischen einer Originalanforderung und einer Neuanforderung erkennen und sich weigern kann, diese Anforderung ein zweites Mal auszufhren. Zudem kann ein Wchter verwendet werden, dau a her ein Bit im Nachrichtenheader, das bei einer Neuanforderung gesetzt wird. Die Idee dahinter ist, dass die Ausfhrung einer Originalanforderung immer sicher u ist, whrend bei einer Neuanforderung seitens des Servers eine hhere Sorgfalt a o notwendig ist.

1.3.5

Client-Absturz

Die letzte Fehlerklasse beschreibt einen Client, der abstrzt, nachdem er eine Anu forderung an einen Server gesendet hat. Die Folge ist, dass eine Berechnung aktiv ist, auf deren Ergebnis niemand mehr wartet. Eine solche Berechnung wird auch als Waise bezeichnet. Fr den Umgang mit Waisen gibt es die vier Mglichkeiten u o der Exterminierung, Reinkarnation, gndigen Reinkarnation und den Ablauf. Keia ne der genannten Mglichkeiten ist wnschenswert. Besonders kritisch werden o u Waisen, wenn sie Sperren fr Dateien oder Datenbankstze angefordert haben, u a die nicht mehr aufgehoben werden knnen. Zudem kann ein Waise bereits meho rere Prozesse in Auftrag gegeben haben, sodass auch ein Lschung des Waisen o seine Spuren nicht vollstndig verwischt. a

1.4

Wiederherstellung

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

1.4.1

Einfhrung u

Fr die Wiederherstellung eines korrekten Status gibt es zwei Mglichkeiten. u o Bei der Rckwrts-Wiederherstellung (Backward Recovery) wird das System u a aus dem aktuellen, fehlerhaften Status in einen vorherigen, korrekten Status uberfhrt. Voraussetzung sind Prfpunkte (Checkpoints), welche im folgenden u u Kapitel 1.4.2 erlutert werden. a Bei der VorwrtsWiederherstellung (Forward Recovery) wird das System aus a dem aktuellen, fehlerhaften Status in einen neuen, korrekten Status uberfhrt. u Voraussetzung ist, dass mgliche Fehler vorher bekannt sind. o

10


1.4.2

Prfpunkte u

Fr die Rckwrts-Wiederherstellung ist es notwendig, dass das System seinen u u a Status regelmig in einen stabilen Speicher schreibt. Diese Aufzeichnung von a Prfpunkten kann sehr kostspielig sein und zu Leistungseinbuen fhren. Daher u u wird sie oft in Kombination mit der Nachrichtenprotokollierung verwandt. Zudem ist es erforderlich, einen konsistenten, globalen Status des verteilten Systems aufzuzeichnen, auch als verteilte Momentaufnahme bezeichnet. Die letzte verteilte und konsistente Momentaufnahme wird auch als Wiederherstellungsverlauf bezeichnet.

Abbildung 1.4: Suche nach dem Wiederherstellungsverlauf von zwei Prozessen

Die Abbildung 1.4 soll der Veranschaulichung dienen. P1 und P2 sind Prozesse, von denen regelmig Prfpunkte erstellt werden. Nun tritt in P2 ein Fehler auf a u und der Wiederherstellungsverlauf soll ermittelt werden. Der letzte Prfpunkt von u P2 (P2**) passt nicht zu (P1**), weil die Nachricht (N2) in (P2**) gespeichert ist, nicht aber in (P1**). Daher kann (P2**) nicht als Prfpunkt verwendet weru den. Der vorige Prfpunkt (P2*) passt nicht zu (P1**), weil (N1) nur in (P1**) u gespeichert ist. (P1*) und (P2*) sind allerdings konsistent und somit der Wiederherstellungsverlauf der Prozesse P1 und P2.

Literaturverzeichnis[1] Wikipedia, Fehlertoleranz http://de.wikipedia.org/wiki/Fehlertoleranz, 2012 [2] A. Tannenbaum und M. van Steen, Verteilte Systeme: Grundlagen und Paradigmen. Pearson Studium, 2003.

2

Das Google File System

Oliver Wolf

Inhaltsverzeichnis2.1 2.2 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . Design des GFS . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Annahmen von Google an das Design . . . . . . . 2.2.2 Architektur des GFS . . . . . . . . . . . . . . . . 2.2.3 Konsistenzmodell . . . . . . . . . . . . . . . . . Systeminteraktionen des GFS . . . . . . . . . . . . . . . 2.3.1 Kontrollrechte und Mutationsreihenfolge . . . . . 2.3.2 Datenuss . . . . . . . . . . . . . . . . . . . . . 2.3.3 Record Append-Operation . . . . . . . . . . . . . 2.3.4 Snapshot-Operation . . . . . . . . . . . . . . . . Masteroperationen . . . . . . . . . . . . . . . . . . . . . 2.4.1 Management des Namensraumes . . . . . . . . . 2.4.2 Verteilung, Erstellung und Reproduktion von Kopien 2.4.3 Garbage Collecion . . . . . . . . . . . . . . . . . Fehlertoleranz, Zuverlssigkeit und Verfgbarkeit . . . . . a u Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 11 12 12 13 15 15 15 16 16 17 17 17 17 18 19 20

2.3

2.4

2.5 2.6

2.1

Einleitung

Google deckt fast 80 % aller Suchanfragen (200.000.000 pro Tag) ab und ist damit die mit Abstand bedeutendste Suchmaschine. Mit dem erfolgreichen Brsengang o in 2004 stellt Google eine der bedeutendsten success stories des Internet dar.1 Durch die immer strkere Nutzung der Suchmaschine, sowie die komplexer wera denden Google-Applikationen ist die zu verwaltende Datenmenge in den letzten Jahren stark angewachsen. Dies war die Ursache fr die Entwicklung neuer Konu zepte, um eine konsistente Datenhaltung und -verwaltung, sowie eine schnelle Datenrettung zu ermglichen. Im Mittelpunkt dieser Entwicklung steht die Sio cherung der Performance des Systems, das Milliarden von Dokumenten verwaltet1

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

12

2 Das Google File System

und mehrere tausende Treer pro Suchanfrage nach Relevanz ordnet. Der Umfang und die Komplexitt des Systems stellen dabei sowohl besondere Herausforderuna gen an die einzusetzende Hardware, als auch an die Konzepte der Datenverteilung und -sicherung. Ein unerwarteter Ansatz ist dabei der Verzicht auf teure Spezialhardware. Alle Anwendungen laufen auf gewhnlicher PC-Hardware und o sind somit sehr wirtschaftlich im Vergleich zu teurerer Spezialhardware. Durch den Einsatz gewhnlicher PC-Hardware sind Ausflle von Festplatten oder ganzer o a Server wesentlich wahrscheinlicher, es wird sogar mit dem Ausfall von Systemen gerechnet. Dass Anwendungen dennoch so zuverlssig und schnell funktionieren, a liegt an der Struktur des von Google entwickelten Dateisystems dem Google File System (GFS). Dieses wurde entwickelt, um den wachsenden Anforderungen der Datenverarbeitung von Google zu begegnen. Es bietet eine hohe Fehlertoleranz, sodass Fehler automatisch entdeckt und Wiederherstellungen automatisiert ausgefhrt werden. Nachteile der Hardwarekonguration knnen damit abgefanu o gen werden. Eine weitere strukturelle Besonderheit des GFS stellt die Verwaltung von Schreibzugrien dar. Bestehende Dateien werden nicht durch schwer zu kontrollierende Schreiboperationen, sondern vielmehr durch leichter zu verwaltende Append-Operationen erweitert. Es ist somit mglich, dass viele Nutzer gleichzeitig o auf grere Dateien schreibend zugreifen, ohne dass eine stndige Synchronisation o a zwischen diesen Nutzern stattnden muss. Die vorliegende Arbeit soll einen Einblick in die Funktionsweise und Komplexitt des GFS geben sowie die strukturelle Umsetzung der Anforderungen aufa zeigen. Dazu wird im zweiten Kapitel zunchst das Design des GFS ausfhrlich a u diskutiert. Das dritte Kapitel wird die Systeminteraktion des GFS aufzeigen. Im vierten Kapitel stehen die Masteroperationen des GFS im Mittelpunkt. Die aus den Vorkapiteln realisierten Vorteile bezglich Fehlertoleranz, Zuverlssigkeit und u a Verfgbarkeit werden im fnften Kapitel aufgegrien und evaluiert. Das letzte u u Kapitel stellt eine Zusammenfassung der evaluierten Informationen dar.

2.22.2.1

Design des GFSAnnahmen von Google an das Design

Beim Entwurf moderner Datenverarbeitungssysteme werden immer diverse Annahmen getroen, welche die Designentscheidungen leiten, wie auch fr das GFS. u Folgende vier Annahmen sind fr das GFS essentiell: u 1. Ausflle von Computer-Komponenten sind die Regel. Das Dateisystem a besteht aus tausenden, preiswerten Computern von denen nicht alle durchweg funktionsfhig arbeiten knnen und manche nach ihren Ausfllen sich a o a

2.2 Design des GFS

13

nicht wiederherstellen lassen. Probleme knnen auftreten bei Anwendungs-, o Betriebssystem und menschlichen Fehlern sowie das Versagen von Festplatten, Speichern, Anschlssen, Netzwerken und Netzgerten. Daher ist eine stndige u a a Uberwachung, Fehlererkennung, Fehlertoleranz und die automatische Wiederherstellung integraler Bestandteil des GFS. 2. Die Dateigre wchst. Jede Datei enthlt viele Anwendungsobjekte wie o a a z. B. Web-Dokumente. Bei wachsenden Datenmengen von vielen TBs mit Milliarden von Objekten ist es unhandlich Milliarden KB groe Dateien zu verwalten. 3. Die meisten Dateien sind verndert durch Anhngen neuer Daten ana a statt dem Uberschreiben vorhandener Daten. 4. Erhhung der Flexibilitt. Das GFS Konsistenz Modell wurde entspannt, o a um das Dateisystems zu vereinfachen ohne dass es zu Belastungen fr die u Anwendungen kommt. Weiterhin wurde eine atomare Append-Operation eingefhrt, so dass mehrere Clients gleichzeitig an eine Datei anhngen knnen u a o ohne zustzliche Synchronisation zwischen den Clients. a

2.2.2

Architektur des GFS

Um groe Datenmengen zu speichern sowie die Verfgbarkeit zu erhhen setzt u o Google auf alt bewhrte Computercluster. Ein Computercluster bezeichnet den a Verbund von Computern zur Steigerung der Rechenleistung und Ausfallsicherheit. Ein GFS-Cluster besteht dabei aus einem Master-Server sowie mehreren Chunk-Servern auf denen Dateien gespeichert werden. Jeder dieser Server ist in der Regel ein gewhnlicher Linux-Server. Die Dateien werden in einzelne Chunks o gesplittet und auf den Chunk-Servern lokal gespeichert. Sie werden in Chunks fester Gre unterteilt. Jeder Chunk ist identizierbar durch einen vom Master o unvernderlichen 64-Bit-Schlssel, dem Chunk-Handle, der zum Zeitpunkt der Era u stellung zugeordnet wird. Zum Zwecke der Zuverlssigkeit werden Replikationen a jedes Chunks auf mehreren Chunk-Servern gespeichert. Der Master-Server ist fr die Organisation aller Metadaten des Dateisystems u zustndig. Dies beinhaltet: die Verwaltung von Namensrumen und Zugrinfora a mationen, das Mapping von Dateien zu den Chunks sowie die Information uber die aktuelle Position der Chunks. Weiterhin koordiniert der Master-Server Systemaktivitten wie Chunk-Lease-Management, Garbage Collection und Chunka Migration zwischen den einzelnen Chunk-Servern. Der Master-Server kommuniziert in regelmigen Abstnden mit den Chunk-Servern uber HeartBeat-Massages a a um ihnen Instruktionen zu ubergeben und ihren Status abzufragen. Clients kom munizieren mit dem Master-Server und den Chunk-Servern um Daten fr eine u Anwendung lesen oder schreiben zu knnen. Dabei interagiert der Client mit dem o

14


Master, um Metadaten-Operationen auszufhren, der Datenuss hingegen luft u a direkt uber die Chunk-Server. Der Master-Server selbst ist nicht mit den Lese oder Schreibvorgngen mit den Clients beschftigt, er hlt lediglich die Position a a a der Chunk-Server fr die Clients bereit. Somit entsteht kein Engpass im System. u Daten werden in Chunks gespeichert. Jede Chunk-Datei ist auf einem ChunkServer mit einer festen Gre von 64MB gespeichert und kann bei Bedarf erweitert o werden. Die Wahl dieser Dateigre bietet mehrere Vorteile: o 1. Es reduziert die Notwendigkeit der Interaktion zwischen dem Client- und dem Master-Server, da nur wenige Informationen bezglich der Lage des Chunku Servers zur Verfgung gestellt werden mssen. u u 2. Clients fhren eher viele Operationen auf einem bestimmten Chunk aus. Dies u kann den Netzwerk-Overhead reduzieren durch das Halten einer persistenten TCP-Verbindung zum Chunk-Server uber einen lngeren Zeitraum. a 3. Es reduziert die Gre der Metadaten die auf dem Master gespeichert werden. o Dies erlaubt die Metadaten im Speicher zu halten. Im Speicher eines Masters werden drei Arten von Metadaten gehalten: 1. Datei- und Chunk-Namensrume a 2. Adressierung der Dateien auf die Chunks 3. Standorte jeder Chunk-Kopie Die ersten beiden Typen, die Datei- und Chunk-Namensrume sowie die a Adressierung der Dateien auf die Chunks, werden persistent gehalten, indem Vernderungen in einem Operation-Log protokoliert werden, welches auf einer a lokalen Festplatte des Masters gespeichert und zustzlich noch auf anderen Recha nern repliziert wird. Mit Hilfe eines Operation-Logs kann der Zustand des Masters einfach und zuverlssig aktualisiert werden, ohne Inkonsistenzen bei einem Aba sturz des Masters zu riskieren. Der Master speichert Informationen zu den Standorten der Chunk-Dateien nicht persistent ab. Stattdessen wird jeder Chunk-Server uber seine Chunk-Dateien bei dem Start des Masters und wenn ein Chunk-Server das Cluster betritt abgefragt. Fr jeden dieser 64 MB Chunks werden nur 64 u Byte fr die Adressierung bentigt, sodass Kapazittserweiterungen durch eine u o a Speichervergrerung des Masters realisierbar sind. Da die gesamten Metadao ten im Speicher stehen, sind sie nicht nur sehr schnell zugnglich, es ermglicht a o dem Master auch die Erstellung von Kopien, Chunk-Migration, Lastverteilung und Festplattenplatz im Hintergrund zu managen. Aufgrund dieses Designs sind die auf dem Master vorliegenden Daten nicht immer konsistent, da stndig Chunk-Server hinzukommen, sich abmelden, ihren Namen a

2.2 Design des GFS

15

a a ndern, neustarten oder ausfallen. Diese stndigen Anderungen werden durch regelmige Scans aktualisiert. Der Master kann whrend eines Scanprozesses uber a a eine HeartBeat-Massage den aktuellen Stand eines Chunk-Servers abfragen. Diese Verbindung umfasst nur sehr wenige Daten und ist in sehr kurzer Zeit abgeschlossen. Da diese HeartBeat-Massage nur sehr kurz aufgebaut wird, hat sie keinen groen Einuss auf die Performance des Servers. Der Zeitpunkt dieser Verbindung wird vom Master nach Kriterien der optimalen Lastverteilung gewhlt. Um a vernderte Metadaten zu protokollieren, werden ebenfalls Operation-Log-Files im a Speicher des Masters gehalten. Es werden darin die Versionsnummern von Dateien und Chunks gespeichert, weiterhin wird eine logische Zeitlinie festgelegt, welche fr die eindeutige Identikation der Chunks bentigt wird. Durch das Operationu o Log kann der Master das Chunk-Dateisystem sehr schnell wiederherstellen. Dieses Dateisystem wird hierbei in Form eines Binrbaumes abgelegt. Durch das Festlea gen von Checkpoints innerhalb dieses Binrbaumes kann der Server immer wieder a in einen konsistenten Zustand zurckgesetzt werden. Sobald ein neuer konsisu tenter Checkpoint ermittelt wurde, knnen vorher festgelegte Checkpoints sowie o zugehrige Logles gelscht werden. Die Schlssel der Knoten des Binrbaums o o u a werden durch eine Dateiadresse, auch Chunk-Handle genannt, mit einem Zeitstempel speziziert. Das Operation-Log ist die einzige persistente Speicherung der Metadaten. Ein Verlust wrde zu einem Verlust des ganzen Dateisystems u fhren. Es wird daher auf mehreren Rechnern gesichert. u

2.2.3

Konsistenzmodell

Das Konsistenzmodell bildet die Grundlage fr eine konsistente Datenspeicherung. u Dabei werden Namenskonventionen sowie die Reihenfolge von Datenoperationen festgelegt. Da die Dateinamensrume ausschlielich durch den Master verwala tet und die zeitliche Reihenfolge der Datenspeicherung durch das Operation-Log deniert werden, kann Atomaritt und Korrektheit garantiert werden. Wird eine a Datei verndert, so wird von einer Mutation gesprochen. Eine Datei ist konsistent, a wenn alle Clients nach einer Mutation auf allen Kopien dieselben Daten sehen. Mutationen werden auf allen Kopien in derselben Reihenfolge ausgefhrt und die u Versionsnummern protokolliert. Auch nach erfolgreichen Mutationen knnen Koo pien beschdigt sein, diese werden mit Hilfe von Checksummen identiziert. Wie a Datenverluste konkret vermieden werden, soll im nchsten Kapitel nher beleucha a tet werden.

16


2.32.3.1

Systeminteraktionen des GFSKontrollrechte und Mutationsreihenfolge

Jede Mutation verndert die Chunk-Daten und wird auf allen Chunk-Kopien a durchgefhrt. Leases (Kontrollrechte) werden hierbei benutzt, um eine konsisu tente Reihenfolge der Mutationen zu garantieren. Der Master whlt dabei eine a primre Kopie aus und gibt ihr das Chunk-Lease, das Recht der Wahl der Mua tationsreihenfolge, auf allen untergeordneten Chunk-Kopien. Die globale Mutationsreihenfolge ist somit durch die Lease-Rechte des Masters sowie durch die von der primren Kopie festgelegte Mutationsreihenfolge unter den anderen Kopien a deniert. Diese Vorgehensweise verringert den Verwaltungs-Overhead des Masters. Ein Lease hat typischerweise einen Timeout von 60 Sekunden, kann aber auf Anfrage der primren Kopie verlngert werden, falls eine Mutation lnger als der a a a Timeout dauert. Diese Anfragen an den Master werden an die Heartbeat- Massage gekoppelt. Falls das Lease abluft oder die Kommunikation mit der primren a a Chunk-Kopie verloren geht, kann der Master einfach einer anderen Kopie das Lease gewhren. a

2.3.2

Datenuss

Whrend der Kontrolluss vom Client uber den primren zu den sekundren a a a Chunk-Servern luft, werden die Daten durch Pipelining mit einer festgelegten a Reihenfolge zwischen den Chunk-Servern transferiert. Der Grund fr diese Voru gehensweise ist das Ziel der ezienten Nutzung der Bandbreite der jeweiligen Server sowie der Vermeidung von Engpssen. Durch die Linearitt des Datenusa a ses kann die Bandbreite besser als in anderen Topologien genutzt werden, da auf Splitting und somit Performanceverlust verzichtet wird. Werden die Daten auf den Chunk-Server transferiert, so ist er in diesem Zeitraum fr Clients nicht eru reichbar. Die zu schreibenden Daten werden somit in einer Operation geschrieben, und dadurch die Ausfallzeit des Chunk-Servers minimiert sowie die Erreichbarkeit und Performance des Gesamtsystems vergrert. Weiterhin werden Daten auf o den naheliegendsten Chunk-Server transferiert, wobei die Entfernung durch die IP Adressen ermittelt wird, um Engpsse im Netzwerk zu vermeiden. Der Transa fer uber TCP-Verbindungen ermglicht die Minimierung der Latenzzeit, da ein o Chunk-Server, kurz nachdem er Daten empfangen hat, diese sofort weiterleitet. Durch diese Struktur ist es mglich 1 MB in etwa 80 ms auf alle Chunk-Server o des Clusters zu verteilen.

2.3 Systeminteraktionen des GFS

17

2.3.3

Record Append-Operation

Bei einer Schreib-Operation, bei der mehrere Clients zeitgleich auf die gleiche Datei schreibend zugreifen, wird die Operation Record Append benutzt, um eine komplizierte Synchronisationen zu umgehen. Dabei wurden einige Koordinationsmechanismen auf dem primren Chunk-Server eingebaut. Der primre Chunka a Server checkt, ob die vom Client auszufhrende Schreiboperation die maximale u Gre eines Chunks von 64 MB uberschreitet. Ist dies der Fall, gibt der primre o a Chunk-Server den sekundren Chunk-Server den genauen Oset, an den die Daten a zu schreiben sind und gibt eine Erfolgsmeldung an den Client zurck. Falls dies u nicht der Fall ist, gibt der primre Chunk-Server die Anweisung an alle sekundren a a Chunk-Server, die Chunks aufzufllen. Falls die Schreiboperation auf einer Kou pie fehlschlgt, wird diese vom Client wiederholt, so dass auch Duplikate der a Daten auf den Chunk-Servern vorliegen. Das GFS garantiert nicht, dass alle Kopien bitweise ubereinstimmen, aber die Schreiboperation wurde mindestens einmal atomar auf allen Kopien ausgefhrt. Der wesentliche Vorteil der Record Appendu Operation, im Vergleich zu einer normalen Schreiboperation, besteht in dem geringeren Synchronisationsaufwand bei Clientzugrien. Whrend der Ausfhrung a u der Operation wird lediglich ein Oset am Ende der Datei verndert. Bei einer a normalen Schreibaktion werden alle Speicheradressen gesperrt, die grer sind als o die zu beschreibende Speicheradresse. Durch diese Vorgehensweise sind immer nur Teile der Datei fr Leseoperationen verfgbar. u u

2.3.4

Snapshot-Operation

Die Operation Snapshot ermglicht dem Master unverzglich eine Kopie des o u Dateisystems und des Verzeichnisbaums zu erstellen, ohne dass stattndende Mutationen gestrt werden. Wenn der Master einen Snapshot-Befehl erhlt, werden o a zuerst alle an die primren Kopien vergebenen Lease widerrufen, um sicherzustela len, dass Schreibbefehle von Clients eine Interaktion mit dem Master bentigen. o Nachdem das Lease widerrufen oder abgelaufen ist, kann das im Speicher bendliche Quellverzeichnissystem kopiert werden. Sobald ein Client nun diesen, durch den Snapshot betroenen, Chunk A anfordert, wird von dem Master ein neuer Chunk-Handle A erschaen. Nun fordert der Master die Chunk-Server auf, eine lokale Kopie des Chunks A anzulegen und diese A zu ubergeben. Da die Kopie auf demselben Chunk ausgefhrt wird, kann sie lokal, nicht uber das Netzwerk, u stattnden. Einer Kopie wird nun das Lease gewhrt und die Interaktion mit dem a Client kann fortgesetzt werden. Das Anlegen einer Kopie fr den Zweck eines u Rollbacks ist somit sehr ezient implementiert.

18


2.42.4.1

MasteroperationenManagement des Namensraumes

Viele Masteroperationen beanspruchen eine lange Zeit, wie die bereits beschriebene Snapshot Operation. Um die Performance des Masters durch diese Operationen nicht zu verringern, knnen multiple Operationen gleichzeitig aktiv sein. Um seo rielle Zugrie sicher zu stellen, werden mit Hilfe von Locks bestimmte Bereiche des Namensraums gesperrt. Die logische Reprsentation des GFS ist eine Looka Up-Table, in dem die Pfadnamen auf ihre Metadaten abgebildet werden, wobei diese Tabelle im Speicher gehalten wird. An jedem Knoten im Verzeichnisbaum kann ein eigener Lese-Schreib-Lock, also eine Sperre fr Lese- oder Schreibzuu grie gesetzt werden. Durch diesen Lock werden auch auf alle ubergeordneten Verzeichnisse Read-Locks gesetzt.

2.4.2

Verteilung, Erstellung und Reproduktion von Kopien

Die Hauptaufgaben der Verteilung von Kopien, sind die Maximierung der Datenerreichbarkeit und -zuverlssigkeit und die eziente Nutzung der Netzwerka bandbreite. Es reicht somit nicht aus, Kopien uber verschiedene Maschinen zu verteilen, es muss auch eine Verteilung uber verschiedene Racks erfolgen. Somit kann gesichert werden, dass Kopien bestehen bleiben, auch wenn ganze Racks ausfallen. Soll ein neuer Chunk erstellt werden, muss zunchst die Verteilung der Kopien a bestimmt werden. Die Auswahl erfolgt anhand folgender Kriterien: 1. Um eine gleichmige Speicherplatzausnutzung zu garantieren, werden Maa schinen mit unterdurchschnittlicher Speicherplatzauslastung favorisiert. 2. Da nach der Erzeugung eines Chunks gewhnlich groe Schreiboperationen o folgen, wird die Anzahl neuer Chunks auf einem Chunk-Server begrenzt. 3. Eine Verteilung auf multiplen Racks wird angestrebt. Der Master repliziert Kopien, sobald eine festgelegte Anzahl unterschritten wird. Dies knnte aus zwei Grnden geschehen: o u 1. Ein Chunk-Server ist nicht mehr erreichbar 2. Eine Kopie oder eine Festplatte ist beschdigt. a Jeder Chunk, der repliziert werden muss, wird auf Basis von bestimmten Faktoren priorisiert. Eine Entscheidungsgrundlage ist, wie weit die Chunkanzahl vom Limit

2.5 Fehlertoleranz, Zuverlssigkeit und Verfgbarkeit a u

19

der Anzahl der Kopien entfernt ist. Eine weitere Priorisierung erfhrt ein Chunk, a wenn er einen Clientprozess blockiert. Der Master ordnet dann die Kopie des Chunks an, wobei die Verteilung der Kopie auf Basis der bereits beschriebenen Faktoren erfolgt. Um die Netzwerkbelastung zu minimieren, werden die Zahl der Kopieprozesse und die verwendete Bandbreite eingeschrnkt. a

2.4.3

Garbage Collecion

Wird eine Datei von einem Client gelscht, erfolgt das Lschen des genutzten o o Speicherplatzes nicht sofort. Es wird lediglich ein Eintrag im Logle des Masters vorgenommen. Die Ressourcen werden im GFS in einen versteckten Dateinamen umbenannt, um weitere Clientzugrie zu verhindern. Whrend der regelmigen a a - vom Master durchgefhrten - Scans werden versteckte Dateien, die lter als u a drei Tage sind, aufgesprt und permanent gelscht. Innerhalb dieser drei Tage u o kann die betreende Datei ohne Probleme auf allen Chunks wiederhergestellt werden. Whrend der Scans des Namensraums knnen weiterhin verwaiste Chunks, a o Chunks ohne Referenz, identiziert und entfernt werden. Durch die bereits beschriebene HeartBeat-Massage knnen alle Chunks erkannt werden, die nicht o lnger in der Datei-Metadaten-Verknpfung des Masters vorhanden sind. Diea u se Chunks knnen nun selbstndig durch den jeweiligen Chunk-Server gelscht o a o werden. Zur Identikation von veralteten Kopien werden die Versionsnummern herangezogen und mit der aktuellen Nummer verglichen. Diese veralteten Kopien knnen ebenfalls gelscht werden, da gehaltene Daten nicht mehr relevant sind. o o Die Aktualitt einer Kopie kann bei einer Anfrage eines Clients durch die Versia onsnummer garantiert werden. Diese Mechanismen der Garbage Collection sind in einem stark verteilten System, mit einer hohen Ausfallwahrscheinlichkeit von Komponenten, besonders wichtig.

2.5

Fehlertoleranz, Zuverlssigkeit und a Verfgbarkeit u

Eine der grten Herausforderungen an das GFS stellen die regelmigen Ausflle o a a von Komponenten dar. Fehler in Komponenten knnen sowohl unerreichbare Syso teme als auch fehlerhafte Daten nach sich ziehen. In einem GFS Cluster mit mehreren hunderten Rechnern sind Ausflle die Regel und nicht die Ausnahme. Um a dennoch eine hohe Verfgbarkeit sicher zu stellen, stehen die Strategien werden u die schnelle Wiederherstellung sowie die schnelle Kopieerstellung im Mittelpunkt. Master und Chunk-Server sind in der Lage, sich innerhalb von Sekunden neu zu starten und ihren Status wiederherzustellen, wobei diese schnelle Wiederherstel-

20


lung unabhngig von der Terminierung der Server ist. Auch wenn ein Timeout a uberschritten wurde, und der Chunk-Server eine neue Verbindung zum Master aufbauen muss, geschieht dies innerhalb von Sekunden. Die Anzahl der Kopien kann festlegen werden, wobei im Regelfall von 3 Kopien ausgegangen wird. Die Kopieerstellung eines Masters ist fr die Verfgbarkeit des u u Systems entscheidend. Das Operation-Log und die Checkpoints werden auf verschieden Maschinen repliziert. Aus Grnden der Vereinfachung ist nur ein Masteru prozess fr alle Mutationen sowie Hintergrundoperationen verantwortlich. Wenn u dieser Prozess abbricht, wird sofort ein Masterprozess auf einer Kopie gestartet mit dem vorher replizierten Operation-Log. Clients benutzen bei der Interaktion mit dem Master stets einen DNS Alias, welcher gendert werden kann, falls der a Master ausfllt. Um das Lesen von Dateien zu erleichtern, die nur unregelmige a a Mutationen erfahren, wurden so genannte Shadow-Master bereitgestellt, welche nur einen Lesezugri bereitstellen. Weiterhin sind diese Master um Bruchteile einer Sekunde langsamer als der primre Master und knnen unter Umstnden a o a veraltete Resultate liefern. Ein Shadow-Master erhlt Informationen bezglich a u Chunkkopien und Mutationsreihenfolge vom primren Master und speichert so a Namensrume, wenn auch zeitlich versptet, identisch ab. a a Jeder Chunk-Server benutzt das bereits erklrte Checksumming, um fehlerhafte a Daten zu identizieren. Aufgrund der Operation Record Append sind Kopien auf verschieden Chunk-Servern nicht unbedingt identisch. Aus diesem Grund muss jeder Chunk-Server seine eigene Integritt mittels Checksumming uberprfen. Jeder a u 64 KB Block eines Chunks wird durch eine 32 bit Checksumme deniert. Bei einer Leseanfrage eines Clients werden zunchst die Blcke uberprft, die uber die Lea o u sestrecke des Chunk-Servers hinausgehen. Durch dieses Vorgehen wird verhindert, dass fehlerhafte Checksummen zu spt aufgedeckt und fehlerhafte Daten bereits a gesendet werden. Kommt es nicht zu einer Ubereinstimmung der Checksummen, wird ein Fehler an den Client zurckgegeben und ebenfalls dem Master berichtet. u Der Master veranlasst, wie bereits beschrieben, dass eine korrekte Kopie dupliziert wird.

2.6

Zusammenfassung

Diese Arbeit gibt einen Einblick in die komplexen Fragestellungen und Anforderungen an das GFS. Aufgrund der Analyse lsst sich sagen, dass trotz einer a fast unbegrenzten Skalierbarkeit des Systems, der wachsende Datenindex und die Anzahl an Zugrien auch zuknftig organisiert werden knnen. Selbst mit u o dem Einsatz von handelsblicher Hardware werden Dezite wie Unzuverlssigkeit u a und Nichtverfgbarkeit durch geschickte Datenhaltung ausgeglichen. Durch eine u

Literaturverzeichnis

21

stndige Uberwachung, Replikation wichtiger Daten und eine schnelle sowie aua tomatische Wiederherstellung ist das GFS sehr fehlertolerant. Auch im Hinblick auf den Gesamtdurchsatz an gleichzeitigen Lese- und Schreibvorgngen, wurden a innerhalb des GFS Mechanismen entwickelt, welche die Daten persistent sowie konsistent halten. Die stetig wachsende Datenmenge im Internet erschwert die Suche zunehmend. Neue Konzepte der Informationsverarbeitung und -strukturierung werden immer wichtiger. Diese Arbeit zeigt auf, dass das Google File System eine stabile Datenhaltung bietet die dieser Aufgabe gerecht werden kann.

Literaturverzeichnis[1] Ghemawat S., Gobio H., Leung S.-T., The Google File System, http://www.cs.brown.edu/courses/cs295-11/2006/gfs.pdf, 2003, 2003

[2]

Leyh M., Das Google File System, http://www.wi.unimuenster.de/pi/lehre/ss05/seminarSuchen/Ausarbeitungen/MichaelLe 2005 LivingLogic AG, Suchmaschinen-Optimierung fr Google ohne u Tricks, http://www.livinglogic.de/xist4c/web/SuchmaschinenOptimierung id 247 .htm Moritz M., Verteilte Dateisysteme in der Cloud, http://dbs.unileipzig.de/le/seminar 0910 maria moritz ausarbeitung.pdf, 2010 Schmidt J., Verteilte Dateisysteme, http://www.minet.unijena.de/dbis/lehre/ss2010/saas/material/Ausarbeitung05Schmidt.pdf

[3]

[4]

[5]

22


3

Verteilte teme

Multimediasys-

Philipp Richardt

Inhaltsverzeichnis3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Allgemeines . . . . . . . . . . . . . . . . . . 3.1.2 Verteilte Systeme . . . . . . . . . . . . . . . 3.1.3 QoS (Dienstgte) . . . . . . . . . . . . . . . u 3.1.4 Best-Eort . . . . . . . . . . . . . . . . . . . Verteilte Multimediasysteme . . . . . . . . . . . . . . 3.2.1 Streaming Video und Audio . . . . . . . . . . 3.2.2 Interaktives Video und Audio in Echtzeit . . . 3.2.3 Zuknftige Weiterentwicklungen im Internet u Ubertragung Multimedialer Anwendungen . . Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . zur . . . . 23 23 24 25 26 26 27 30 30 33

3.2

3.3

3.13.1.1

EinleitungAllgemeines

In unserem heutigen Zeitalter ist von immer schneller wachsender Vernetzung die Rede. Dabei werden sowohl einzelne Rechner als auch ganze Unternehmensbereiche vernetzt. Moderne Kommunikationsmechanismen erlauben es verschiedene multimediale Inhalte beispielsweise Bilder, Filme und Audiodateien uber ein Rech nernetz zu verbreiten. Daraus bilden sich immer mehr multimediale Anwendungen wie zum Beispiel verteilte Informationsdienste, Videokonferenzsysteme aber auch Systeme, die ein Kooperatives Arbeiten erlauben. Client-Server Interaktionen, die nach dem Anfrage-Antwort Prinzip agieren treten ebenso, wie kontinuierlichen Datenstrme auf. Beispiele dafr stellen Abrufdienso u te, wie z.B. Zugrie auf multimediale Inhalte aus Datenbanken genauso wie Kooperatives Arbeiten unter verschiedenen Benutzern, die in einem verteilten Work-

24

3 Verteilte Multimediasysteme

ow Managementsystem sich untereinander austauschen. Dabei werden nicht selten asymetrische Strukturen nachgewiesen, welche durch eine Anfrage geringe Datenmengen an den Server senden. Im Zuge dessen kann es unter Umstnden a zu groen Datenmengen von Seiten des Servers in Richtung Client kommen. Als eigentliches Grundlage dieser Art der Kommunikation ist der Remote Procedur Call zu nennen. Bei der Rechnerkommunikation spielt dieser Mechanismus eine immer grere Rolle. Mit der Entstehung des Internets wurde ein weltweites o Rechnernetz erschaen, welches die unterschiedlichsten Technologien verbindet und den angeschlossenen Rechnern die Basis dieser Interaktionen bietet. Technologien sind sowohl unterschiedliche Medienzugrisverfahren wie Token Ring, Token Bus, ATM oder auch CSMA/CD, darauf aufgesetzte transportorientierte Protokolle, sowie physikalische Medien wie Lichtwellenleiter, Kupfer- und Glas faserkabel. Ein Flaschenhals entsteht, meist bei der Ubertragung multimedialer Inhalte uber verschiedenartige Netze, hug an den Netzbergngen. Die Nacha u a richten mssen so oft umkodiert werden, damit uberhaupt eine Weiterleitung in u ein anderes Netz ermglicht werden kann. o Meist kennen die Anwendungen, welche uber solche Netzwerke eingesetzt werden, die zugrunde liegenden Parameter des verwendeten Netzwerkes nicht genau. Bei spiele solcher Parameter sind Schwankungsbreite oder die Ubertragungsrate des zugrunde liegenden Netzwerkes. Dabei werden von vielen Anwendungen konstan te Ubertragungsraten vorausgesetzt. Dies trit in den meisten aller Flle jedoch a nicht zu. Sind der Anwendung genaue Angaben uber den zu ubertragenden Datenstrom vorhanden, wird dieser jedoch zumeist nur auf die Anwendungsebene bezogen. Bei Video ist es beispielsweise die Eigenschaft der Bildrate, der Abtastrate oder der Bildqualitt. Da das vorliegende Medium nicht bekannt ist, innerhalb der Ana wendung, entstehen folglich Schwierigkeiten bei der Ubergabe dieser Daten an ein Netzwerk. Dies gilt besonders in der Transportschicht und der des entsprechenden Netzwerkprotokolls.

3.1.2

Verteilte Systeme

Als verteiltes System bezeichnet man einen Verbund von mehreren unabhngigen a Systemen, welche durch den Zusammenschluss uber ein Netzwerk und einer oft integrierten Softwareschicht dem Benutzer als ein einzeln arbeitendes System erscheinen. Es existiert keine allgemeingltige Denition fr verteilte Systeme. Jeu u doch kann man die folgende als Charakterisierung der Begriichkeit verwenden. Ein verteiltes System ist eine Menge voneinander unabhngiger Computer, die a dem Benutzer wie ein einzelnes, kohrentes System erscheinen. [1] a Im folgenden sind die Ziele aufgefhrt, welche ein verteiltes System verfolgt: u

3.1 Einleitung

25

Benutzer und Ressoucen verbinden: Hierbeit geht es darum Benutzer und Ressourcen so einfach und so ezient wie mglich miteinander zu verbinden. Dem Benutzer wird dadurch durch eine o kontrollierte Art und Weise der Zugang und die gemeinsame Nutzung einer entfernten Ressource mit anderen Benutzern ermglicht. o Transparenz: Die Transparent spiegelt die Fhigkeit des verteilten Systems wieder, sich dem a Benutzer oder einer Applikation so darzustellen, als ob es aus lediglich einem System besteht und dennoch alle anderen Ressourcen die es nutzt so ezient wie nur mglich einsetzt. o Oenheit: Dienste in verteilten Systemen sollen bestimmten Standardregeln entsprechend angeboten werden, welche auch den Semantik und Syntax dieser Dienste beschreibt. Skalierbarkeit: Die Skalierbarkeit eines Systems spiegelt die Erweiterbarkeit und die somit verbundene Vergrerung dar. Dabei sollte das Hinzufgen von neuen Beo u nutzern und Ressourcen in das gesamte System ohne jegliche administrativen Aufwand erfolgen.

3.1.3

QoS (Dienstgte) u

Quality of Service oder auch Dienstgte stellt die zur Verfgung stehenden Eigenu u schaften einer Dienstleistung dar. Alle Verfahren, die dafr verwandt werden um u einen Dienst mit bestimmter Qualitt beim Empfnger ankommen zu lassen um a a somit die Anforderungen des Kunden bzw. Empfngers zu gewhrleisten. Folgende a a Parameter werden in IP-Netzen an unterschiedliche Anwendungen gestellt: Jitter: Der Jitter steht fr die Schwankung bei der Ubertragung von Digitalsignau len. Dabei ist dieser Eekt unerwnscht und fhrt bei der Ubertragung von u u multimedialen Inhalten zu unerwnschten Nebeneekten. Ein zu frhes oder u u zu sptes Eintreen des Signals ist beispielsweise bei Internet-Telefonie sehr a strend. Man spricht auch von einer Abweichung der Laufzeit von Datenpao keten. Latenzzeit: Die Latenzzeit oder auch Verzgerungszeit spaltet sich in zwei unterschiedliche o Eekte. Zum einen in die gewnschte Verzgerungszeit , dem sogenannten u o

26


Delay, und in die unerwnschte Laufzeitverzgerung. u o Paketverlustrate: Die Paketverlustrate gibt einen prozentualen Wert der verloren gegangenen Pakete wieder. Dieser Prozentsatz spiegelt bei einem Datenstrom die Rate wieder, wie viele IP-Pakete bei der Ubertragung von einem Sender zu einem Empfnger nicht angekommen sind. Es wird dabei davon ausgegangen, dass a bei der IP-Telefonie Raten bis zu 5 Prozent Verlust noch in akzeptabler Qualitt bei Empfnger ankommen. Der Idealfall ist eine Paketverlustrate von 0. a a Datendurchsatz: Der Datendurchsatz stellt die Gre da, welche im Mittel bei einer o Ubertragung pro Zeiteinheit erreicht wird. Sie spiegelt anders als die Datenbertragungsrate den reinen Durchsatz dar. u [2]

3.1.4

Best-Eort

Der heute im Internet durch das IP-Protokoll erbrachte Best-Eort-Dienst gewhrleistet das Weiterleiten eintreender Pakete, solange das Netz noch a freie Ubertragungskapazitten bietet. Es werden dabei keine Garantien fr a u die vollstndige und fehlerfreie Ubertragung gemacht. Kommt es zu einem a Stau, nachdem ein Pfad bei der Ubermittlung uberlastet ist, so bleibt dem ubergeordneten Protokoll beispielsweise TCP bzw. dem Benutzer es uberlassen die Ubertragung und damit auch die Kommunikation wieder herzustellen. [3]

3.2

Verteilte Multimediasysteme

In den voran gegangenen Abschnitten wurden die grundlegenden Begriichkeiten nher erlutert. Multimedia-Anwendungen stellen im heutigen Internet hohe a a Dienstanforderungen im Gegensatz zu traditionellen und elastischen Anwendungen. Hierbei sind E-Mail, World Wide Web, Remote Login, Filesharing oder auch das herunterladen von Dateien als elastische Vertreter zu nennen. Bei ihnen spielt es keine Rolle wie hoch die End-zu-End Verzgerung ist bzw. ist es kaum von o nten, dass die Daten ich annhernder Echtzeit beim Empfnger ankommen. Auf o a a der anderen Seite knnen traditionelle und elastische Anwendungen anders als o Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Verteilte Multimediasysteme In den voran gegangenen Abschnitten wurden die grundlegenden Begriichkeiten nher erlutert. Verteilte Multimedia-Anwendungen stellen a a im heutigen Internet hohe Dienstanforderungen im Gegensatz zu traditionellen

3.2 Verteilte Multimediasysteme

27

und elastischen Anwendungen. Hierbei sind E-Mail, World Wide Web, Remote Login, Filesharing oder auch das herunterladen von Dateien als elastische Vertreter zu nennen. Bei ihnen spielt es keine Rolle wie hoch die End-zu-End Verzgerung ist o bzw. ist es kaum von belangen, dass die Daten nicht annhernder in Echtzeit beim a Empfnger ankommen. Auf der anderen Seite knnen traditionelle und elastische a o Anwendungen anders als Multimedia-Anwendungen gelegentliche Datenverluste nicht tolerieren. Somit stellen Multimedia-Anwendungen in ihren verschiedensten Ausprgungen unterschiedlichste Netz- und Qualittsanforderungen. In den fola a genden Abschnitten soll dabei zunchst anhand von zwei unterschiedlichen Klasa sen die Anwendung von verteilten Multimediasystemen erlutert werden. Hierbei a geht es zum einen um die Klasse des Streaming von Live-Video und -Audio, welche mit einem konkreten Beispiel belegt werden sollen und zum anderen die Klasse der interaktiven Video und Audio Echtzeitanwendungen.

3.2.1

Streaming Video und Audio

Ahnlich wie bei traditionellen Fernseh- oder Radiosendungen ndet das Streaming von Live-Video und Audio ausschlielich im Internet statt. Somit werden weltwei te Ubertragungen von Sendungen an mehrere Millionen Zuschauen und Zuhrer o mglich. Da sich das Senden der Inhalte uber das Internet abspielt sind diese o Multimedia-Anwendungen auch unter IPTV oder Internetradio bekannt. Aufgrund der Tatsache, dass die empfangenen Inhalte nicht vorher aufgezeichnet wurden und somit Live ubermittelt werden mssen kann der Client keine vorluge Speiu a cherung der Inhalte durchfhren. u Beispiel: IPTV Fernsehinhalte werden heutzutage nicht mehr nur noch traditionell uber Satelliten oder Glasfaser-/ Koaxialkabel, sondern besteht sehr groes Interesse dem Endverbraucher das Fernsehen uber das Internet zu senden. Hierbei werden jedoch extrem groe Bandbreiten vorausgesetzt. Diese hohe Bandbreite ist vor allem serverseitig von Nten. Wir gehen davon aus, dass ein sportliches Groereignis o wie die Fuball Weltmeisterschaft 2014 uber das Internet ubertragen werden soll. Nehmen wir nun noch an,dass mittels eines Servers an 500 Millionen Zuschauer gesendet werden soll. Bei einer Videorate von sehr geringen 1Mbps wrde eiu ne Serverbandbreite von 500 Terabit/Sekunde bentigt werden. Eine klassische o Server-Client-Verteilung ist somit aufgrund der bentigten Serverbandbreite vllig o o unzureichend. Eine angebrachte Verteilung knnte man durch IP-Multicast erreio chen. Ebenfalls besteht die Alternative ein Multicast-Overlay-Netzwerk zu bilden und darber die Inhalte zu verteilen. Solche Mglichkeiten werden durch Content u o Distribution Networks bereits zur Verfgung gestellt. Weitere Mglichkeiten der u o Verbreitung wre die Verteilung uber Peer to Peer. Hierbei wrde jeder Peer auch a u

28


gleichzeitig dazu beitragen die Empfangenen Pakete weiter an andere Peers zu geben. Wrden alle Peers entsprechend viel Upload- Bandbreite liefern wrde der u u Server eine weitaus geringere Bandbreite bentigen. o Eine weitere Streaming Methode ist das Streamen von bereits aufgenommenen Inhalten, welche auf einem Server bereit liegen.ANders als bei der vorher beschriebenen vorgehensweise fordert hier der Client fordern komprimierte Audio und Videodateien von einem Server an. Dem Benutzer steht durch die vorhergehende Speicherung der Inhalte auf dem lokalen Rechner die Mglichkeit oen im o Film zu spulen, anzuhalten oder weiterzuspringen. Bei den Servern, welche die Video/Audio Inhalte zur Verfgung stellen kann es sich zum einen um einfach u Webserver handeln und zum anderen um einen Streamingserver. Streaming uber einen Webserver 1. Der Benutzer besucht eine Webseite mit einem entsprechenden Hyperlink auf die Videodatei. Die enthaltene Header-Zeile in der HTTP-Response-Nachricht enthlt die verwendete Video-/Audio-Codierung. a 2. Der Browser des Clients untersucht die Header-Zeile der Response-Nachricht und startet den zugehrigen Medienplayer und ubermittelt den Datenbereich o der Response-Nachricht an diesen. 3. Durch Kontaktierung des Medienplayers und dem HTTP-Server direkt uber eine TCP-Verbindung wird die Audio-/Videodatei an den Medienplayer ubertragen.

Abbildung 3.1: Streaming uber einen Webserver [4]


29

Streaming uber einen Streamingserver Das Streamen uber einen Streamingserver teilt sich auf in drei unterschiedliche Methoden. Mit einer konstanten Rate wird die Audio-/Videodatei uber UDP ver sandt. Diese entspricht genau der Abspielrate beim Empfnger. Treen die kompria mierten Daten aus dem Netz beim Empfnger ein, werden sie dort dekomprimiert a und abgespielt. Eine zweite Methode beschreibt wie bei der ersten Vorgehensweise die Ubertragung mittels UDP. Ahnlich wie bei der ersten Streamingmethode wird hierbei eine Verzgerung im Medien Player hervorgerufen. Dieser verzgert die o o Ausgabe des Videos um wenige Sekunden. Dies dient zur Entfernung von netzwerkbedingten Jitter. Die komprimierten Daten werden in einem sogenannten Client-Puer abgelegt und nach Ansammlung einiger Sekunden im Voraus von dort abgespielt. Die dritte Methode ubertrgt die Inhalte vom Server mittels TCP. Die Media endateien werden hierbei vom Server so schnell es geht auf dem TCP-Socket abgelegt. Der Medien Player liest den TCP-Socket aus. Die komprimierten Daten werden im Medienpuer gespeichert. Erneut nach einer Anfangsverzgerung o gibt der Medienplayer den Puer wieder aus und leitet die komprimierten Daten zur Wiedergabe und Dekompression weiter. Da die hier angewandte Methode TCP, verworfene Pakete nochmals ubertrgt wird somit ein besserer Ton und ein a besseres Bild erzielt.

Abbildung 3.2: Streaming uber einen Streamingserver [5]

30


3.2.2

Interaktives Video und Audio in Echtzeit

In dieser Klasse der Multimedia-Anwendungen wird es dem Anwender ermglicht o mit anderen Anwendern weltweit in Echtzeit zu kommunizieren. Dabei erfolgt wie im vorhergehenden Beispiel schon beschrieben die Kommunikation unter den Endanwendern uber das Internet. Diese Anwendungen werden meist auch Internette lefonie genannt. Ahnlich wie bei traditionellen leitungsvermittelnden Fernsprechdiensten ist es dadurch dem Anwender gestattet weltweit mit anderen Anwendern in Kontakt zu treten. Sowohl das Audio, als auch das Videosignal wird dabei durch das IP-Netz ubertragen. Neue Dienste die sich dadurch ermglichen sind Grupo penkommunikationen, Anrulterung, Erkennung ob Anwender anwesend sind und die damit verbundene Integration von webbasierten Anrufen. Bekannte Beispiele fr die voran gegangenen Dienste sind: Skype oder Microsoft NetMeeting u Bei beiden Conferencing-Tools wird es dem Benutzer ermglicht mit andeo ren Benutzern audiovisuell in Kontakt zu treten. Hierbei sollte idealerweise die Verzgerung zwischen Bild und Ton des Senders und Empfngers nicht hher sein o a o als 150ms. Sobald es hhere Abweichungen bei der Verzgerung gibt kann dies zu o o indiskutablen Gesprchsstrungen oder zu asynchronen Bild/Ton Ubertragungen a o fhren. Somit stellen diese Anwendungen ein hohe Anforderung an Paket-Jitter u und Paketverzgerung. Der Paket-Jitter beschreibt dabei eine Vernderung eio a ner Paketverzgerung im selben Strom von Paketen. Solange der Echtzeitano wendung gengend Bandbreite zur Verfgung steht ist eine gute Ubertragung u u von Video und Audio gewhrleistet, da dadurch die Verzgerung und der Jitter a o niedrig gehalten werden kann. Sobald jedoch der Paket-Strom auf einen ausgelasteten Pfad trit kann sich die Qualitt extrem verschlechtern. Da das heutige a Internet keine Klassizierung bzw. eine Priorisierung von Paketen in erster und zweiter Klasse zulsst, ist die Weiterentwicklung von Multimedia-Anwendungen a schwierig. Die Paketverarbeitung erfolgt somit ohne jegliche Gewichtung fr u verzgerungsempndliche Anwendungen. Alle Pakete werden somit gleich behano delt und auch gleich abgearbeitet. Somit muss man zunchst mit diesem Besta Eort-Dienst auskommen.

3.2.3

Zuknftige Weiterentwicklungen im Internet zur u Ubertragung Multimedialer Anwendungen

Bereits in der Einfhrung wurde auf die Bedeutung von Dienstgte in IPu u Netzwerken eingegangen. Diese spielt auch in der Weiterentwicklung des Inter nets und besonders bei der Ubertragung multimedialer-Anwendungen eine sehr groe Rolle. Es gibt eine Reihe von Forschern, welche es fordern grundlegen de Anderungen am Internet vorzunehmen. Diese Anderungen zielen dahin, dass zuknftig Anwendungen End-zu-End Bandbreite reservieren knnen. Dadurch u o


31

wird eine garantierte Leistung zwischen beiden Endpunkten sichergestellt. Eine Unterscheidung in feste und weiche Garantie bietet der Anwendung eine sichere bzw. hohe Wahrscheinlichkeit das die angeforderte Dienstgte eingehalten wird. u Es soll nach Meinungen dieser Forschergruppe mglich sein, dass beispielsweise o bei einem Anruf zwischen zwei Hosts, eine Reservierung vorgenommen werden kann, die den Hosts Bandbreite zusichert egal auf welchem Pfad entlang der Route sich bewegt wird. Um dies jedoch in die Tat umzusetzen und diese Ga rantierte Dienstgte zu gewhrleisten bedarf es groen Anderungen. Folgende u a Anderungen msste dabei bercksichtigt werden. Zum einen wrde man ein Prou u u tokoll bentigen das in der Lage ist die Bandbreite auf dem Pfad zwischen Sender o und Empfnger zu reservieren.Darber hinaus msste man eine Priorisierung der a u u zu behandelnden Pakete einfhren. Somit wrden Pakete, welche sich in der Rouu u tingwarteschlage benden und eine hohe Prioritt aufweisen zuerst abgearbeitet a und andere mit niedrigerer spter. Die Pakete die mehr reserviert haben werden a folglich schneller abgearbeitet. Die Anwendungen mssen dafr dass ihre Reservieu u rungen bercksichtigt werden dem Netz eine Ubersicht uber ihren Verkehr geben. u Welchen sie beabsichtigen ins Netzwerk zu senden. Das Netz wiederum ist dann verpichtet den Verkehr jeder Anwendung zu uberwachen. Damit wird sicherge stellt, dass die getroenen Abmachungen mit Anwendung und Netz eingehalten werden. Eine weitere Methode die noch angefhrt werden muss ist ein Mechau nismus mit der das Netzwerk entscheiden kann ob genug Bandbreite vorhanden ist um die neue Reservierungen vorzunehmen. Um diese neuen Mechanismen zu realisieren bentigt es neuer und komplexer Software, die sowohl auf den Hosts, o als auch auf den Routern sowie den Diensten installiert werden muss. Eine andere Gruppe von Forschern argumentiert, dass es ohne grundlegende Anderungen am Best-Eort-Dienst und vorhandener Internetprotokolle keiner notwendigen Vernderung bedarf. Sie sind somit Befrworter des sogenannten a u Laissez-faiere-Ansatzes. Dieser besagt folgendes: Sobald der Bedarf steigt sollen in diesem Fall auch die Internet Service Provider ihre Netzwerke so anpassen, dass der Bedarf wieder erfllt werden kann. Somit mssen die ISPs lediglich ihre u u Bandbreite und die Switching-Kapazitt so angleichen, dass die bentigte Leisa o tung hinsichtlich der Verzgerung und des Paketverlust im Rahmen bleibt. Durch o den gettigten Angleich der Leistung durch die ISps werden folglich die Kunden a zufrieden gestellt und somit laut Aussage der Befrworter dieses Ansatzes auch u mehr Kunden zum ISP kommen. Folglich ist eine Steigerung der Einnahmen fr u den ISP gewhrleistet. Um auch wirklich zu gewhrleisten, dass Multimedia- Ana a wendungen auch zu Hchstlastzeiten in guter Qualitt im ausreichenden Mae o a zur Verfgung stehen, sollte der ISP deutlich mehr Bandbreite und Switchingu Kapazitt bereithalten als aktuell bentigt. Dieses Overprovisioning bietet dem a o Kunden die Mglichkeit weiche Dienstgte-Garantien uber den Verkehr zu geben. o u

32


Durch Content Distribution Networks werden Inhalte durch Kopien an unterschiedlichen Standorten (am Rand des Internets) gespeichert. Kopien werden angefertigt und auf weiteren CDN-Knoten verteilt. Somit knnen durch CDNs o Datenaufkommen im inneren des Internets verringert werden. Somit ist auch bei CDN oft eine schnellere Lieferung der Inhalte an den Endanwender mglich. Die o Nachfolgende Abbildung zeigt eine Verteilung von Inhalten zunchst auf einen a Server, der wiederum die Inhalte verteilt auf die CDN Knoten-Server. Von diesen knnen die meist multimedialen Inhalte durch den Anwender abgerufen werden. o

Live-Streaming-Verkehr wie im voran gegangenen Kapitel anhand von IPTV erlutert muss an mehrere hundert Millionen Menschen (Beispiel WM 2014) a uber das Internet live ubertragen werden. Die Live-Ubertragungen knnen mittels o Multicast-Overlay-Netzwerken realisiert werden. In diesen Netzwerken bestehen die Verteilerknoten aus Hosts und dedizierten Servern. Diese werden uber das ge samte Internet verstreut. Server,Hosts und logische Links dazwischen bilden dann das Overlay-Netzwerk, in welchem der Datenverkehr mittels Multicast von Quelle zu den Benutzern ubertragen wird. Dieses wird nicht wie bei IP-Multicast von Routern auf der IP-Schicht durchgefhrt, sondern auf der Anwendungsschicht. u Es knnte so durch kontinuierliche Weitergabe des Stroms an Overlay-Server und o Hosts ein Verteilungsbaum entstehen. Somit kann die gesamte Verkehrslast im Internet aufgeteilt werden. Eine dritte Forschergruppe untersttzen die Ansichten der geringen Vernderung u a an Netzwerk- und Transportschicht. Sie wollen lediglich einfache Uberwachungsund Preisschemata am Rand des Netzwerkes einfhren. Diese sollen an der u Schnittstelle zwischen Benutzer und ISP installiert werden. Der sogenannte DiServ Ansatz beschreibt somit einen Service bei dem im Grundgedanke einige wenige Verkehrsklassen eingefhrt werden, welche in Routingwarteschlangen unu

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

3.3 Zusammenfassung

33

terschiedlich behandelt werden sollen. Somit knnen Benutzer durch verschiedene o Preismodelle ihren Internetzugang an die Pakete mit den verschiedenen Klassen anpassen. Somit werden Pakete vom ISP angeboten, die ein schnelleres Routing gewhrleisten und somit preislich teurer sind. a In den voran gegangen Methoden und Anstzen wurden unterschiedlichste Hera angehensweisen und teilweise auch Lsungen dargestellt, um mit dem immer weio ter wachsenden Datenaufkommen und den wachsenden Anforderungen an neue multimedialen Anwendungen fertig zu werden. Das IP-Netzwerkprotokoll des Internets bietet somit einen Best-Eort-Dienst, der sein bestes tut um jedes noch so unterschiedliche Datagramm schnellstmglich zum Ziel zu ubertragen. o

3.3

Zusammenfassung

In den voran gegangenen Kapiteln haben wir zum einen durch eine Einfhrung u und durch Begriserklrungen einen Einblick in das Thema der verteilten Mula timediasysteme bekommen. In weiteren Abschnitten wurde das Thema anhand von technisch eingesetzten Beispielen im Internet weiter Ausgefhrt. Zum Schluss u wurden einige Anstze und Methoden dargestellt, welche zur Verbesserung des aka tuellen Best-Eort-Internets beitragen sollen und auch zuknftig die Verbreitung u Multimedialer-Anwendungen uber verteilte Systeme steuern knnen und sollen. o Dabei spielt zuknftig die Dienstgte, welche von einer Anwendung gefordert ist u u und dessen Erfllungsgrad eine wichtige Rolle um das immer hher werdenden u o Datenaufkommen und die wachsende Zahl der Benutzer des Internets steuern zu knnen. o

34


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

[3] Wikipedia, Best-Eort. http://de.wikipedia.org/wiki/Best_Effort, 14.01.2012 [4] James F Kurose, Keith W. Ross:Computernetzwerke: Der Top-DownAnsatz.S. 644 Pearson Studium; Auage: 4., aktualisierte Auage., September 2008. [5] James F Kurose, Keith W. Ross:Computernetzwerke: Der Top-DownAnsatz. S. 642 Pearson Studium; Auage: 4., aktualisierte Auage., September 2008. [6] Cslongwang, Content Distribution Network - Grak http://www. cslongwang.com/Images/Cdn_Product.gif, 16.01.2012

4

OpenCL

Roger Jger a

Inhaltsverzeichnis4.1 4.2 4.3 4.4 Einfhrung zum Thema - Taktfrequenzen stagnieren u OpenCL - Hintergrund . . . . . . . . . . . . . . . . Voraussetzungen fr OpenCL . . . . . . . . . . . . . u OpenCL - Aufbau/Architektur . . . . . . . . . . . . 4.4.1 Host . . . . . . . . . . . . . . . . . . . . . 4.4.2 Compute Devices/Units . . . . . . . . . . . 4.4.3 Kernel . . . . . . . . . . . . . . . . . . . . 4.4.4 Program . . . . . . . . . . . . . . . . . . . 4.4.5 Command Queue . . . . . . . . . . . . . . 4.4.6 Program Object . . . . . . . . . . . . . . . 4.4.7 Context . . . . . . . . . . . . . . . . . . . . 4.4.8 Memory Object . . . . . . . . . . . . . . . OpenCL C und Besonderheiten . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 37 38 39 40 40 40 41 41 41 41 42 43 44

4.5 4.6

4.1

Einfhrung zum Thema - Taktfrequenzen u stagnieren

Mit der rasanten Entwicklung der Computertechnologie wuchsen schnell die Aufgaben und somit auch die Anforderungen an die Systeme. Lange Zeit galt die Taktrate, nicht nur aus PR Zwecken, als grobes Ma fr die Leistung einer CPU. u Sie gibt auch die Geschwindigkeit an, mit der die Einzelnen Transistoren schalten. Damit trgt sie entscheidend dazu bei, wie schnell Berechnungen durchgefhrt a u werden knnen. Lange Zeit stellten die anwachsenden Taktraten kein greres o o Problem, fr die Entwicklung immer leistungsfhiger Chips, dar. Auch die u a immer feiner werdenden Strukturen, wurden durch die Entwicklung neuer Verfahrenstechniken und den Einsatz neuer Materialien im Fertigungsprozess ermglicht. Zur Einfhrung des Pentium 4 Prozessor warb der US-amerikanische o u Halbleiterhersteller Intel noch damit, die Taktraten bei Prozessoren in den

36

4 OpenCL

kommenden Jahren noch auf 10Ghz steigern zu knnen[1]. Allerdings bestehen o grundstzliche physikalische Hindernisse bei der Steigerung der Taktrate. Bei a jedem Stromuss muss ein Wiederstand uberwunden werden der in thermische Energie umgewandelt wird. Bei immer kleiner werdenden Strukturen und Chipchen wurde die somit erzeugte Abwrme der Prozessor bald zu einem a a Problem. Die Chiphersteller wie Intel und AMD lassen fr ihre CPU maximal u 150 Watt Abwrme zu. Zwar gibt es seit 2007 mittlerweile von IBM speziell a fr Serversysteme Power6-Prozessoren mit bis zu 5Ghz Taktrate[2], doch lassen u sich noch hhere Werte nur noch schwer zuverlssig mit Luftkhlen. Aus diesem o a u Grund suchte man nach neuen Wegen um die Leistung weiter zu steigern. Das Ziel war es nicht mehr uber die Taktung des CPU an Schnelligkeit zu gewinnen, sondern mittels parallelem rechnen. Aus diesem Grund entschloss man sich mehrere Kerne auf einem Prozessor zu verbauen. Allerdings reicht selbst die aktuellste und schnellste Multi-Core-CPU fr einige anspruchsvolle Anwendung u nicht aus. Vor allem im medizinischen und wissenschaftlichen Bereich, der Signalverarbeitung, bei Audio- Bild- und Videoverarbeitung, der Kryptographie oder bei Physik-Simulation/Eekte stoen aktuelle Mehrkern-Prozessoren an ihre Grenzen. Aus diesem Grund versucht man seit kurzem auf andere leistungsfhige a Systemressourcen zurckzugreifen. u Im Zuge der rasanten Entwicklung in der Spieleindustrie wuchs auch die Leistung der Grakkarten mit den Anforderungen. Immer mehr grasch anspruchsvollere spiele Titel veranlasste Hersteller wie ATI und NVIDIA Grakprozessoren zu entwickeln, die so viele Berechnung wie mglich parallel ausfhren konnten, um o u die Inhalte ssig darzustellen. Diese wurden ursprnglich zur Untersttzung u u u und Entlastung von Grakberechnung der CPU genutzt. Doch durch gestiegene Leistung und Flexibilitt, sowie der hohen Parallelitt an Aufgabenbearbeitung, a a boten Grakkarten immer mehr das Potential fr den Einsatz als Co-Prozessor. u NVIDIA entwickelt erstmals mit der API CUDA(Compute Unied Device Architecture) eine Schnittstelle Programmteile zur Berechnung auf Hersteller eigenen Grakkarten auszulagern. Es bietet der Anwendung den Vorteil, von der meist auerhalb von Videospielen und Grakanwendung genutzten und brach liegende Rechenleistung der GPU zu protieren. Dabei bieten vor allem neuere GPUs durch die hohe Anzahl an Kernen im Vergleich CPUs die Mglichkeit, Programme mglichst schnell parallel abzuaro o beiten. Wie auf Abb. 4.1 zu erkennen ist, besitzt ein Multi-Core CPU deutlich weniger ALUs (Arithmetic Logic Unit) als eine GPU, die aktuell weit uber 500 von Stream-Prozessoren enthalten kann. CPUs haben zwar den Vorteil einen umfangreicheren Befehlssatz und greren Speicher zu besitzen, der o

4.2 OpenCL - Hintergrund

37

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

es ihnen ermglich komplexere Befehle abzuarbeiten, allerdings sind in ihrer o Parallelitt relativ begrenzt. Diesen Nachteil haben Grakprozessoren nicht. Sie a bieten zwar nur einen begrenzten Befehlssatz an, weien dabei aber eine hohe Parallelitt von Aufgabenabarbeitung auf. Ermglicht wird dies durch mehrere a o kleine Control Units die uber einen eigenstndigen Cache verfgen. Die Berecha u nung ist zwar hnlich der eines Threads bei einer CPU, jedoch deutlich ezienter. a Zur Programmierung von CUDA Fhigen Grakkarten wird C for CUDA a eine C Version mit NVIDIA-Erweiterung genutzt. Weiterhin existieren auch ein Wrapper fr Perl, Phyton, Java, Fortan und .NET und auch eine Anbindung u fr Matlab. Ein Entscheidender Nachteil bei der Entwicklung von CUDA ist, u das diese Schnittstelle auf die NVIDIA eigenen Grakkarten beschrnkt ist. Aus a diesem Grund begann Apple mit der Entwicklung einer eignen Schnittstelle.

4.2

OpenCL - Hintergrund

Apple entwickelte in Zusammenarbeit mit Firmen wie AMD, Intel und NVIDIA einen ersten Entwurf fr uneinheitliche Parallelrechner. Dieser Entwurf ist ein Frau mework namens OpenCL und verfolgt das Ziel aus mehreren unterschiedlichen Systemkomponenten wie CPU, GPU und anderen Signalprozessoren fr Berechu nung notwendige Systemleistung zu kombinieren. OpenCL welches ursprnglich u

38

4 OpenCL

von Apple entwickelt worden war, wurde schlielich im Juni 2008 zur Standardisierung eingereicht. Verantwortlich fr die Entwicklung ist seitdem die im Jahr u 2000 gegrndete Khronos Group. Das Konsortium wird gebildet aus einem Zuu sammenschluss einer Vielzahl von namenhaften Herstellern- und Dienstleistungskonzernen der IT-Branche. Darunter bekannte Unternehmen wie Intel, AMD/ATI, Nvidia, Sun, Apple, Mozilla, Opera, Adobe und Google. Unter anderem betreut die Khronos Group noch weitere bekannte Projekte, wie zum Beispiel die Weiterentwicklung von OpenMAX, OpenGL und den Ableger OpenGL ES, sowie WebGL. Dadurch das OpenCL nun als oener und Standard entwickelt wird, bietet es im Vergleich zu CUDA nun die Mglichkeit an, fr jeden Hardware- und Betriebssyso u temhersteller eigene Implementierungen und Erweiterungen zu entwickeln, welche sich allerdings im Rahmen der Spezikationen bewegen mssen. Die Khronos u Group verentlichte die erste Spezikation von OpenCL am 8. Dezember 2008. o Die Aktuellste und neuste Version ist OpenCL 1.2, welche auch abwrtskompatibel a ist und im November 2011 erschien.

4.3

Voraussetzungen fr OpenCL u

Um die Voraussetzungen fr aufgabenparalleles bzw. datenparalleles Rechnen fr u u OpenCL zu erfllen, bentigt man allerdings einige Hardware und Softwareseitige u o Implementierungen. Das Betriebssystem muss, um eine Beschleunigung mit OpenCL nutzen zu knnen, uber folgende Bestandteile verfgen. o u Implementierung in BS notwendig: OpenCL Application Programming Interface (API) OpenCL Runtime Engine OpenCL Compiler Auch auf der Hardwareseite mssen einige Voraussetzungen erfllt werden. Es u u kann fr die Berechnung nur auf Hardware zurckgegrien werden, wie CPUs u u und GPUs, bzw. Schaltkreise, die die notwendigen Spezikationen erfllen. Eine u der wesentliche Bestandteil liegt in den neuen Funktionen und Frameworks. Bei der Verwendung dieser mssen die neuen Mglichkeiten zum Datenparallel rechu o nen auch ausgenutzt werden. Bisherige Software wird somit durch die fehlende OpenCL Tauglichkeit nicht von einem Performance-gewinn protieren. Es mssen u als Ressourcen intensive programmteile OpenCL konform und API konform ausgelagert werden, um die erforderliche Beschleunigung zu erreichen. Sobald alle Voraussetzungen erfllt sind: u

4.4 OpenCL - Aufbau/Architektur

39

Betriebssystem OpenCL tauglich Hardwarekomponenten OpenCL tauglich Software OpenCL konform ist die Beschleunigung von Programmteilen durch Auslagerungen mglich. Wenn o allerdings nur eine der drei Bedingungen nicht erfllt ist, kann kein OpenCL u Code auf dem System ausgefhrt werden. u Wie bereits erwhnt, bentigt das OpenCL-Framework zur Ausfhrung a o u drei Komponenten: die OpenCL-API, die OpenCL-Runtime und den OpenCLCompiler. Bei Betriebssystemen auf denen die OpenCL-Runtime implementiert ist, trennt die Runtime die unterliegende Hardware vom Betriebssystem. Der Compiler wandelt die auf C basierende Sprache in OpenCL C um. Diese, mit der C verwandte Programmiersprache, kann auf jeder Recheneinheit die den OpenCL-Standard erfllt, kompiliert und nativ ausgefhrt werden. Sie enthlt u u a zustzlich zu den normalen Befehlen einige Erweiterungen mit mathematischen a Zusatzfunktionen, die die Implementierung von wissenschaftlicher sowie und ingenieur-spezischer Problemlsungen vereinfacht. Durch die Integrierung des o Compilers in das OpenCL-Framework wird es ermglicht, Programme erst zur o Laufzeit am Zielrechner kompiliert zu lassen. Diese schat die Voraussetzung fr das Speichern des Programmcodes, der somit nicht bei jedem Start des u Programms neu am Zielrechnerneu kompiliert werden muss. Es ist von daher nicht ntig fr den Entwickler im Vorfeld zu wissen, ob und wie viele verschiedene o u OpenCL taugliche Komponenten im Zielsystem verfgbar sind, da durch die u externe Verarbeitung eine Vorkompilierung auf unterschiedliche Version der Anwendung uberssig ist. u

4.4

OpenCL - Aufbau/Architektur

Eine OpenCL Anwendung besteht im Wesentlichen aus folgenden Bestandteilen: Hosts, Devices, Compute Units, Command Queues, Program Objects, Kernel Functions, Memory Objects und Context, Abb. 4.2.

4.4.1

Host

Als Host-Applikation wird das Programm bezeichnet das die Funktionen von OpenCL aufruft, den dafr notwendigen Context erstellt und die Kernel an die u Warteschlangen weitergibt. Die dazugehrigen Host Devices(beispielsweise CPU), o sind Gerte auf denen die Host-Applikation ausgefhrt werden kann. Um jedoch a u

40

4 OpenCL

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

ein Kernel starten zu knnen, muss die Anwendung folgende Schritte ausfhren: o u Bestimmung der verfgbaren Devices(CPU, GPU...) u Whlen der geeigneten Devices, die fr die Berechnung in Frage kommen a u Befehlswarteschlangen fr die gewhlten Devices erstellen u a Allokieren des Speichers (Memory Objects) der fr die gemeinsame Nutzung u der Kernel-Ausfhrung bentigt wird u o

4.4.2

Compute Devices/Units

Jede Baugruppe die rechentaugliche Aufgaben im Sinne der OpenCL Spezikationen ausfhren kann, wird als Device bezeichnet. Innerhalb jedes Devices knnen u o sich ein oder mehrere Recheneinheiten benden. Diese werden auch als Compute Units bezeichnet, in der die Berechnungen mithilfe von Befehls-Sets abgearbeitet werden. Unter Compute Units versteht man im Allgemeinen nicht anderes als beispielsweise bei einem Mehrkernprozessor, die einzelnen Kerne. Daraus ergibt sich bei CPUs eine theoretische Abarbeitungsparallelitt, die der Anzahl der a zur Verfgung stehenden Kerne entspricht. Im Vergleich zu GPUs bieten CPUu Modelle mit ihrer geringen Anzahl an Compute Units allerdings weniger potential um Anwendungen mittels parallel Verarbeitung zu beschleunigen

4.4 OpenCL - Aufbau/Architektur

41

4.4.3

Kernel

Der Begri Kernel steht im Allgemeinen fr eine Funktion innerhalb einer Sprau che. Als Kernel werden in OpenCL Programme bezeichnet die zur Ausfhrung u auf OpenCL tauglichen Devices kompiliert wurden. Auch wenn die Kernels in die Host-Applikation implementiert und in C oder C++ geschrieben sind, mssen u diese auf dem Zielrechner separat erzeugt werden. Nur so knnen die verfgbaren o u Devices angesprochen und optimal an das jeweilige System angepasst werden. Der so entstandene Quellecode kann entweder extra in einer Datei gespeichert oder in den Code der Host-Applikation eingebettet werden. Zwei Arten von Kerneln[3]: OpenCL-Kernel, sind in der Programmiersprache OpenCL C geschrieben(OpenCL C basiert auf ISO C99 und wurde um Funktionen und Datentypen zur parallelen Verarbeitung erweitert) Native Kernel: Diese Kernel sind optional und implementierungsspezisch

4.4.4

Program

Ein Program in OpenCL besteht aus einer Menge von Kerneln, sowie dazugehriger Hilfsfunktionen und Konstanten. Diese knnen innerhalb des Kernels o o aufgerufen und verwendet werden.

4.4.5

Command Queue

Die Ausfhrung einiger Befehle wird in OpenCL mittels Command Queue abgeu arbeitet. Diese Befehle dienen zur Ausfhrung von Kerneln, fr den Transfer von u u Daten zwischen Hauptspeicher und dem Speicher des Compute Devices. Weiterhin knnen Befehlswarteschlangen genutzt werden, um anstehende Befehle an o ein konkretes Gert zu ubermitteln. Diese fhren den Kernel auf dem Gert in a u a der Reihenfolge aus, in der sie in die Warteschlange abgelegt wurden. Zustzlich a gibt es Synchronisationsbefehle mithilfe derer man den Kernel auf die Ausfhrung u eines Datentransfers warten lassen kann.

4.4.6

Program Object

Als Program Object werden in OpenCL Datentypen bezeichnet, die eine OpenCLAnwendung reprsentieren. Folgende Informationen knnen somit gekapselt wera o den: Eine Referenz auf den aktuellen Context

42

4 OpenCL

Programmcode oder auch das Binary Die zuletzt erfolgreich kompilierte Version des Programms Eine Liste der Gerte, bei der letzten erfolgreich kompilierte Programm Version a und der zugehrigen Kompilier-Parametern und Logles o

4.4.7

Context

Mit dem Context wird eine Systemumgebung beschrieben, in der ein Kernel ausgefhrt werden kann. Dazu gehren die Anzahl der Devices, die Angabe der u o verfgbaren Speicherbereiche im System, sowie Befehlswarteschlangen zur Abaru beitung der Programmbefehle. Er ist auerdem notwendig um gemeinsame Speicherobjekte zwischen den einzelnen Devices aufzuteilen, Abb. 4.3.

Abbildung 4.3: OpenCL Speicher Modell[7]

4.4.8

Memory Object

Eine Memory Object enthlt eine Referenz auf einen lokalen Speicherbereich a und dient so zur Bereitstellung von Arbeitsspeicher fr die Applikation. In u OpenCL werden zwei Arten von Speicherobjekten unterschieden. Buer-Objects

4.5 OpenCL C und Besonderheiten

43

die alle Arten von Daten beinhalten knnen und Image-Objects die nur auf o Bildinformationen spezialisiert sind. Die Host-Applikation verwaltet diese und reiht sie in die Befehlswarteschlange zum Lesen und Schreiben ein. In OpenCL gibt es verschiedene Arten von Adressrumen: a Private fr Daten die zu einem Work-Item gehren u o Local fr Daten die zu einer Work-Group gehren u o Global fr Daten auf die von allen Work-Items und Work-Groups aus zugeu grien werden kann constant fr read-only Daten u In OpenCL wird versucht die jeweilige Implementierung der Hierarchie so gut wie mglich auf die zur Verfgung stehende Hardware anzupassen. Zu beachten o u ist, dass die Konsistenz der Daten im Speicher nicht immer garantiert ist. So knnen zwar innerhalb einer Work-Group, nach einer Synchronisation, die Daten o aus lokalen und globalen Speicherbereich konsistent sein. Jedoch wird auf die global zugreifbaren Daten keine Konsistenz uber die Grenzen einer Work-Group hinweg garantiert. OpenCL bietet die Mglichkeit mehrere Instanzen eines Kernels gleichzeitio ge auf einem oder mehreren OpenCL-Gerten auszufhren. Jede Kernel-Instanz a u wird dabei als Work-Item bezeichnet und besitzt zu dem eine globale ID. Sobald ein Entwickler den Kernel zu Abarbeitung an ein Device ubergibt, kann er die Anzahl der Kernel-Instanzen fest denieren, auch Index-Spaces genannt. Diese knnen sowohl ein- zwei, als auch dreidimensional sein. Damit eine o synchronisierte Berechnung der einzelnen Kernel-Instanzen erfolgen kann, wird es ermglicht die Work-Items in sogenannten Work-Groups zusammenzufassen. o Eine Synchronisation zwischen Work-Groups ist allerdings nicht mglich. o

4.5

OpenCL C und Besonderheiten

In OpenCL wird die Sprache OpenCL C verwendet, welche auf der Syntax von ISO C99 beruht. OpenCL C gehrt zwar zur Obermenge der Sprache C, o enthlt aber auch einige Absonderungen und Ausnahmen zu dieser. Zustzlich a a zu C, wurden weiter Funktionen und Datentypen zu parallelen Verarbeitung hinzugefgt, beispielsweise ein Datentypen fr zwei- und dreidimensionale u u Bilder. Es gibt allerdings auch einige Einschrnkungen die z.B. den Aufruf von a Funktionspointern und rekursiven Kernel Aufrufen verbietet. Ebenso werden

44

4 OpenCL

Array mit variabler Lnge und Structs nicht untersttzt. a u nicht enthalten: Funktionspointer Rekursion Arrays variabler Lnge a structs optional: Gleitkommazahlen mit doppelter Genauigkeit Atomare Funktionen (z.B. increment) Zustzlich zu den in C99 verwendeten Datentypen, werden die weiteren folgenden a Datentypen in OpenCL C benutzt[4]: half: 16 Bit Gleitkommazahlen nach IEEE 754r Vektordatentypen: Char, uchar, short, ushort, int, uint, long, ulong und float als Vektor

Documents

Verteilte Systeme 2011