Adaptives High Throughput Computing in Scavenging Grids

Transcription

Fachhochschule Wiesbaden
Fachbereich Design Informatik Medien
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Informatiker (FH)
Adaptives High Throughput Computing
in Scavenging Grids
Vorgelegt von:
Datum:
Referent:
Korreferentin:
Bertram Beyer
13. Dezember 2006
Prof. Dr. Ulrich Schwanecke
Margaryta Shramko M.A.
ii
Erklärung
Ich versichere hiermit, dass ich die vorliegende Diplomarbeit selbstständig und ohne unerlaubter fremde Hilfe angefertigt habe und dass ich alle von anderen Autoren
wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge anderer
Autoren eng anlehnenden Ausführungen meiner Arbeit besonders gekennzeichnet
und die Quellen zitiert habe.
Mainz, 13. Dezember 2006
Ort,Datum
Unterschrift
Verbreitung
Hiermit erkläre ich mein Einverständnis mit den im folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit:
Verbreitungsform
Einstellung der Arbeit in die Bibliothek der FHW
Veröffentlichung des Titels der Arbeit im Internet
Veröffentlichung der Arbeit im Internet
Ja
X
X
X
Nein
Mainz, 13. Dezember 2006
Ort,Datum
Unterschrift
iii
Inhaltsverzeichnis
Abbildungsverzeichnis
v
Tabellenverzeichnis
vii
1 Motivation
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Was ist Grid Computing? . . . . . . . .
2.2 Die Geschichte des Grid Computing . . .
2.3 Klassifizierung von Grid-Systemen . . . .
2.4 Anwendungsgebiete von Grid Computing
2.5 Der Vergleich mit Peer-To-Peer . . . . .
3 Standards und Marktführer
3.1 Open Grid Forum . . . . . .
3.2 Die Globus Alliance . . . . .
3.3 Sun N1 Grid Engine . . . .
3.4 Condor . . . . . . . . . . . .
3.5 BOINC . . . . . . . . . . .
3.6 Auswertung und Beurteilung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
3
4
.
.
.
.
.
6
6
7
9
11
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
19
22
24
27
29
4 Filesharing Protokolle als Data Grid
4.1 Die Idee der Datenverteilung . . . . . .
4.2 Verteilte Hashtabellen . . . . . . . . .
4.3 p2p Implementierungen . . . . . . . . .
4.4 Auswertung und Beurteilung . . . . . .
4.5 Beschreibung des BitTorrent Protokolls
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
33
34
37
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Konzeption
51
5.1 Rollenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Nodeverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Datenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
iv
5.4
Arbeitsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 Implementierung des Grid-Systems
6.1 Modul- und Klassendefinitionen . .
6.2 Aufgabendeklaration . . . . . . . .
6.3 Kommunikationskanäle . . . . . . .
6.4 Benutzerschnittstellen . . . . . . .
7 Testszenario
7.1 Test 1: Verteilung . . . . . . .
7.2 Test 2: Aufwandssteigerung .
7.3 Test 3: Leistungssteigerung . .
7.4 Beurteilung und Fehleranalyse
8 Fazit und Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
65
74
79
84
.
.
.
.
87
89
90
93
95
98
Literatur
100
Weblinks
104
Inhalt der CD-ROM
106
Glossar
107
Stichwortverzeichnis
110
v
Abbildungsverzeichnis
3.1
3.2
Das Globus Grid Schichtenmodell [Foster u. a., 2001] . . . . . . . . 20
Das BOINC Modell [University of California, 2006] . . . . . . . . . 28
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
BitTorrent Nutzdaten Kommunikation .
BitTorrent Tracker Kommunikation . . .
Beispiel einer .torrent Datei . . . . . .
Dekodierung vom Listening in Abbildung
Konsolenausgabe der Metainformationen
dung 4.3 . . . . . . . . . . . . . . . . . .
Beispiel eines GET Requests . . . . . . .
Beispiel einer Tracker-Antwort . . . . . .
Beispiel einer Peer Kommunikation . . .
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
Use Case Diagramm: Rollenverteilung . . . . . . . . . .
Interne Verknüpfung der Nodes im Beispiel . . . . . . .
Dienste und Kommunikation . . . . . . . . . . . . . . .
Struktur persistenter Daten . . . . . . . . . . . . . . .
Zustandsdiagramm: NodeManager Nachrichtenempfang
Zustandsdiagramm: NodeManager Hauptschleife . . . .
Zustandsdiagramm: JobScheduler Hauptschleife . . . .
Zustandsdiagramm: JobServer Initialisierung . . . . . .
Zustandsdiagramm: JobServer Metadatenaustausch . .
Zustandsdiagramm: ExecutionNode Taskbearbeitung .
.
.
.
.
.
.
.
.
.
.
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
Communication Package . . . . .
NodeRepresentation Package . . .
Auxiliary Package . . . . . . . . .
Paketauswahl BitTorrent API . .
Klassendiagramm ExecutionNode
Klassendiagramm GridManager .
Klassendiagramm JobServer . . .
manifest.xml . . . . . . . . . . . .
metainfo.dtd . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
4.3 .
vom
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Listening in
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
Abbil. . . .
. . . .
. . . .
. . . .
.
.
.
.
38
38
41
43
.
.
.
.
44
44
46
50
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
56
57
58
59
60
61
62
63
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
68
69
70
72
73
75
77
78
vi
7.1
7.2
7.3
7.4
Gerendertes Bild, Auflösung: 1024x768 . . . . . .
Laufzeit bei variabler Menge von Task . . . . . .
Laufzeit bei variabler Menge von ExecutionNodes
Testszenario manifest.xml . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
88
92
95
97
vii
Tabellenverzeichnis
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
ExecutionNode Nachrichtenobjekt . . . . .
NodeManager Nachrichtenobjekt . . . . .
Statusbyte der ExecutionNodes . . . . . .
JobServer/JobScheduler Nachrichtenobjekt
Wertebereich Nachrichtenobjekte . . . . .
ExecutionNode Befehle . . . . . . . . . . .
JobServer Befehle . . . . . . . . . . . . . .
GridManager Befehle . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
80
81
81
82
85
85
86
7.1
7.2
7.3
7.4
Testrechner . . . . . . . . . . . . . . . .
Scheduler update . . . . . . . . . . . . .
Aufwand zur Zeit bei gleicher Kapazität
Leistung zur Zeit bei gleichem Aufwand
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
87
90
91
93
.
.
.
.
1
1 Motivation
Die Rechenleistung moderner Privatrechner ist enorm und sie wächst stetig. In
einer nicht nur für den Laien erstaunlichen Häufigkeit werden auf dem Markt neue
Prozessorgenerationen mit immer höherer Taktfrequenzen sowie mit immer raffinierteren und fortgeschritteneren Technologien angeboten, die sich in ihrer Leistungsfähigkeit permanent übertreffen. Ebenso steigen die Bandbreiten privater Internetanbindungen in Dimensionen, die vor wenigen Jahren noch kaum vorstellbar
waren. Im Gegensatz hierzu sind die Preise für die Hardware auf ein Niveau gesunken, welches es größer werdenden Konsumentenkreisen ermöglicht, immer den
technisch aktuellen Stand halten zu können. Viele Haushalte besitzen schon oft
mehr als nur einen Computer. Die Internet Service Provider bieten ihre Dienstleistungen zu günstigen Pauschalpreisen an, weshalb nicht selten Rechner 24 Stunden
am Tag online sind.
Dieses geballte Potential wird allerdings nur selten genutzt. Zu den wenigen Anwendungen, mit welchen Privatanwender die Leistung ihres PCs ausschöpfen, gehören Spiele oder auch der Videoschnitt. Textverarbeitungen, Webbrowser, Emailclients, Instant Messenger und ähnliche Programme benötigen nur einen Bruchteil
dessen, was der Rechner an Leistung zu bieten hat. Vergleichbar mit einem leistungsstarken Porsche in einer verkehrsberuhigten Zone, bleibt es ihm verwehrt zu
zeigen, was in ihm steckt. Währe so ein Computer ein sensibles intelligentes Wesen,
liefe er wegen permanenter Unterforderung Gefahr, Opfer chronischer Depressionen zu werden.
Auch mit dem Internet mit all seinen Möglichkeiten stehen diese Maschinen nur in
einer sehr einseitigen Beziehung. Sie nutzen lediglich Dienste, die über das Netz-
2
werk offeriert werden, stellen aber selbst für das Netz keinen Nutzen dar.
Grid Computing wird in diesem Zusammenhang allerdings zu einem hochinteressanten Anwendungsgebiet. In ihm beschäftigt man sich mit dem gemeinsamen
Nutzen untereinander vernetzter Ressourcen. Wendet man dies auf den zuvor beschriebenen Zustand moderner Privatrechner an, so kann Grid Computing als Bündelung freier Kapazitäten verstanden werden, welche dann für aufwandsintensive
Berechnungen zur Verfügung stehen. Gelingt es, dieses Potential zu erschließen
und nutzbar zu machen, öffnen sich Türen zu Leistungsfähigkeiten, die zuvor nur
von Supercomputern erreicht wurden.
Ähnliche Anwendungen gab es schon zuvor, aber es gab keine, die in dem besagten
Umfeld eine universelle Plattform bot: Nämlich eine Möglichkeit, die Rechenleistung beliebig vieler Teilnehmer für einen wahlfreien Verwendungszweck zu nutzen.
Deshalb, um mitzuhelfen, diese nach wie vor bestehende Lücke zu verkleinern,
wurde im Rahmen dieser Diplomarbeit aktuelle Techniken auf ihre Tauglichkeit
für eine solche Plattform untersucht und darauf folgend eine erste Testimplementierung eines solchen Grids erstellt.
Letzteres bietet dem Anwender die Funktionalität, parallelisierbare Aufgaben von
beliebig vielen Rechnern ausführen zu lassen. So ist zum Beispiel das Rendern einer
3D Animation eine solche Aufgabe. Jedes Bild einer derartigen Animation kann
zum gleichen Zeitpunkt erstellt werden, da keine Abhängigkeiten zwischen den
Einzelbildern bestehen. Eine Besonderheit hierbei ist, dass vorhandene Software,
die nicht speziell für das Grid entwickelt wurde, weiterhin benutzt wird. Auf das
Beispiel bezogen, wäre dies ein gewöhnlicher Renderer, der mit wenig Mehraufwand
in das Grid integriert werden kann.
Ein wichtiger Aspekt dabei ist, wie die Ressourcenspender in das Grid integriert
werden können, also wie man den Besitzer einer solchen Maschine dazu bewegt,
sich die benötigte Software zu installieren und diese dann auch tatsächlich laufen
zu lassen.
Die erfolgversprechendste Idee dürfte wohl sein, das Programm als Plugin für einen
1.1. Aufgabenstellung
3
Instant-Messenger zu vertreiben. Über diesen Weg gelangt man an eine große Klientel, die prädestiniert für ein solches Produkt wäre, da die Wahrscheinlichkeit der
Akzeptanz, sowie der benötigten Vorraussetzungen für einen erfolgreichen Einsatz
in diesem Fall als sehr hoch einzuschätzen ist.
1.1 Aufgabenstellung
Die Aufgabenstellung der Diplomarbeit bestand daher in der Entwicklung eines adaptiven Scavenging Grids zur Realisierung eines High Trougput Computing (HTC)
Systems. HTC bedeutet, dass die Ausführungsgeschwindigkeiten langläufiger Berechnungen maximiert werden. Hiermit ist nicht die Optimierung zu einer möglichst kurzen Antwortzeit eines Prozesses gemeint. Dies wäre das Aufgabengebiet
von High Performance Computing (HPC). Ein Scavenging Grid beschreibt ein System, welches die brachliegende Rechenzeit vernetzter und ungenutzter Rechner in
Anspruch nimmt, um ferngesteuert Aufgaben an diese zu verteilen und ausführen
zu lassen. Ein Beispiel hierzu wären die Workstations einer Firma, die den Tag
über von den Mitarbeitern genutzt werden, und nachts für Simulationsberechnungen in Anspruch genommen werden. Die Adaptivität bezieht sich darauf, dass
der Einsatzbereich des Grids um die benötigte Funktionalität erweitert wird. Ein
häufiges Entscheidungskriterium, ob ein Teilnehmer eines Grids eine Aufgabe zugewiesen bekommt, ist die auf ihm installierte Software. Sich von dieser Vorstellung
zu trennen und jeden Teilnehmer universal einsetzbar zu betrachten, war ein Teil
der Aufgabe. Die notwendige Software, welche zur Lösung der Aufgaben benötigt
wird, muss also modular verteilt werden. Um diese Verteilung möglichst effizient
zu gestalten, galt es, die Idee zu verfolgen, diese über Filesharing-Protokolle zu
verteilen.
Da die Gridsoftware in einer späteren Implementierung als Plugin über den goober1 Instant-Messender verteilt werden soll, wurden hierdurch die Vorraussetzungen des Systems spezifiziert. Da der Messenger ein Windows Programm ist, müssen
1
http://www.goober.de
4
1.2. Aufbau der Diplomarbeit
auch die zu verteilenden Module windowslauffähig sein. Im Regelfall wird dieser
Messenger über einen zur Zeit durchschnittlichen Internetzugang an das Netz angebunden sein. Die Verfügbarkeit des Systems kann nicht garantiert werden und ist
als instabil zu bewerten, da der Anwender jederzeit die Verbindung unterbrechen
kann.
Der ersten Schritt der Arbeit beruhte in der Aufgabe, gängige Grid Implementierungen und im zweiten Schritt die verbreitesten Filesharing-Protokolle zu analysieren und auf ihre Einsatzmöglichkeit für das geplante System zu prüfen. Nach der
Auswahl geeigneter Komponenten stand dann die Implementierung eines Testsystems auf dem Plan. Letztendlich musste die Lauffähigkeit des Programms anhand
eines konkreten Beispieles demonstriert und bewertet werden.
1.2 Aufbau der Diplomarbeit
Die vorliegende Arbeit unterteilt sich in acht Kapitel. Das erste und gegenwärtige
Kapitel erläutert die zugrundeliegende Motivation, nennt die Aufgabenstellung
und beschreibt die Struktur der Diplomarbeit.
Kapitel zwei gibt einen Einstieg in die Thematik des Grid Computing. Hierzu
gehören ein kurzer historischer Rückblick auf die Entwicklung, sowie die Definition
und die Anwendungsgebiete von Grid Computing. Der letzte Teil dieses Kapitels
beschäftigt sich dann mit der Peer-To-Peer Technologie, beschreibt dieselbe und
setzt sie in Relation zur Grid Technologie.
Das dritte Kapitel nennt kursorisch die aktuellen Marktführer, Trendsetter und
Standards jener Technologie, sowie deren Kernbestandteile und wägt ab, inwiefern
diese für die vorliegende Arbeit von Interesse sind.
Im vierten Kapitel wird die Entscheidung begründet, weshalb ein Filesharing Protokoll den Datentransfer im geplanten Grid übernehmen soll. Drauf folgt eine Einführung in die Materie des Filesharings und eine Beschreibung der populärsten
Implementierungen. Anschließend wird erklärt, warum die Entscheidung auf das
1.2. Aufbau der Diplomarbeit
5
BitTorrent Protokoll fiel, welches danach vollständig beschrieben wird.
Die Konzeption des Grids ist Thema des fünften Kapitels. Dort wird definiert, in
welche Rollen die Gridteilnehmer zu differenzieren sind, wie Aufgaben im Grid
verteilt werden und nach welcher Struktur die Arbeitsabläufe vor sich zugehen
haben.
Kapitel sechs beschreibt die Implementierung. Hierfür zeigt es die Unterteilung
des Systems in Module und Klassen. Darauf aufbauend wird die Umsetzung der
Aufgabenverteilung erläutert. Als Nächstes erfolgt die Erklärung der Kommunikation unter Gridteilnehmern, und zum Schluss werden die Benutzerschnittstellen
zu Applikationen beschrieben.
Thema des siebten Kapitels ist die Prüfung des Systems anhand mehrerer Testsituationen. Zu diesem Zweck diente ein hierfür entwickeltes Szenario, welches mit
unterschiedlichen Parametern durchgeführt wurde. Jeder Test beinhaltet eine Erklärung und Analyse der Ergebnisse.
Das letzte Kapitel bietet eine kompakte Zusammenfassung dieser Arbeit. Sodann
nennt es sinnvollen Ergänzungen und potentiell interessanten Techniken, die für
eine Weiterentwicklung des Systems näher untersucht werden müssten.
Die Formatierung der Diplomarbeit hält sich an die gängigen Konventionen. Als
Besonderheiten sind dabei zu nennen: Begriffe, die einem implementierten System entnommen sind, dazu zählen zum Beispiel Dateinamen, Variablen und auch
Quellcodelistings, werden durch eine nicht proportionale Schrift hervorgehoben.
Ist zu einer Institution, einem Projekt oder einem Produkt ein Weblink bekannt,
wird dieser als Fußnote angegeben.
6
2 Grundlagen
Definitionen von Grid-Computing gibt es zuhauf. Ursachen hierfür resultieren aus
dem rasant angestiegenen Umfang dieses Themenfeldes, an den Überschneidungen
vieler Sachgebiete und den unterschiedlichen dazugekommenen Anwendungsgebieten, bei denen es bald schwierig werden dürfte, den Überblick zu behalten. Hier
soll nun ein Einstieg in die noch recht junge Thematik ermöglicht werden, indem
erklärt wird, welche Ideen hinter der Technologie stecken, woher diese stammen,
und wie sie zu dem wurden, was sie heute sind.
2.1 Was ist Grid Computing?
Mit Grid Computing bezeichnet man im allgemeinen Techniken, die mehrere Computer miteinander verknüpfen und die über den reinen Informationsaustausch, wie
es im Internet der Fall ist, weit hinausgehen.
Hierdurch sollen die Ressourcen eines einzelnen Rechners, als da wären: Speicherkapazität, Rechenkapazität, Applikationen oder auch Spezialhardware mit den
Ressourcen anderer Rechner verbunden werden. Auf diese Weise kann man zum
Beispiel aus mehreren einzelnen Computern virtuelle Supercomputer schaffen.
Genau das war die Idee, die Wissenschaftler schon in den Zeiten des Internetaufbaus hatten. Diese standen vor immer größeren und umfassenderen Problemen,
welche sich mit den Kapazitäten gängiger Computer nicht lösen ließen. Da Supercomputer Mangelware waren, entstand so die Vorstellung von der Verknüpfung
bestehender Ressourcen.
2.2. Die Geschichte des Grid Computing
7
Der Fachterminus „Grid“ hat seinen Ursprung in der englischen Bezeichnung für
Stromnetz, nämlich „electric power grid“. In diesem werden auch eine beliebige
Anzahl von Kraftwerken miteinander verbunden, welche die Kapazitäten stellen.
Über ein standardisiertes Netz ist es so möglich, jeden Haushalt mit Strom zu
versorgen. Der Verbraucher muss hierbei nicht wissen, wer seinen Strom wie und
wo produziert und wie er letztendlich zu seinem Toaster gelangt. Äquivalent hierzu
soll der Konsument im Grid Dienstleistungen zur Verfügung gestellt bekommen,
deren Zusammensetzung und Ursprung von der Verwendung dieser gekapselt sind
[Foster und Kesselman, 2003].
2.2 Die Geschichte des Grid Computing
Das erste große Netzwerk, welches Computer und technische Instrumente miteinander verband, war in den 50er Jahren das SAGE Netzwerk der USA. Es diente
als militärisches Frühwarnsystem zum Schutz vor russischen Bombern. SAGE verband mehrere Ortungssysteme, Militärflughäfen und Flugzeuge miteinander. In
einer späteren Phase des Projekts konnten dann durch Auswahl eines bestimmten Zieles automatisch die Autopiloten der Flugzeuge auf dieses Objekt angesetzt
werden [FAS, 1999].
Die allererste große Software zum Zusammenschluss und zum parallelen Lösen von
Aufgaben war PVM1 (Parallel Virtual Machine). Dessen ursprüngliche Version
stammte aus dem Jahre 1989. Durch sie konnten erstmals in Netzwerken die freien
Ressourcen für Batch Jobs verwendet werden.
1992 entstand das MPI2 Message Passing Interface. Über dieses können Prozesse,
welche parallel auf unterschiedlichen Rechnern gestartet wurden, direkt miteinander kommunizieren.
Im Jahr 1993 errichteten Wissenschaftler der UC Berkeley auf Basis von PVM und
1
2
http://www.csm.ornl.gov/pvm/
http://www-unix.mcs.anl.gov/mpi/
8
2.2. Die Geschichte des Grid Computing
MPI das erste Cluster, das es in die Top-500-Liste der schnellsten Computer der
Welt schaffte.
1994 bauten Techniker der NASA dann das berühmte Beowulf Cluster auf. Donald Becker and Thomas Sterling installierten damals aus 16 DX4 Rechnern auf
Basis von PVM und MPI den ersten Prototypen des Unix basierten Beowulf Clusters. Die Besonderheit bestand hierbei darin, dass die Komponenten, so genannte
COTS (Commodity Off The Shelf), als kostengünstige Massenware bezogen werden konnten. [Merkey, 2004].
1996 gründeten Dr. Ian Foster und Dr. Carl Kesselman zusammen mit Dr. Steve
Tuecke das Globus Project. Danach, im Juli 1998, veröffentlichten Foster und
Kesselman das Standardwerk „The Grid“. Im Oktober 1998 folgte dann das Globus
Toolkit in der Version 1.0. Dieses Globus Toolkit ist Open Source und wurde der
de facto Standard für Gridcomputing.
1999 trat zum ersten Mal das Global Grid Forum (GGF) zusammen. Vergleichbar
mit dem IETF für das Internet, wurde das GGF zum Standardisierungsgremium
für das Grid.
Im Mai 1999 erfolgte von der UC Berkeley im Rahmen ihres SETI Projekts die
Freigabe des Programms SETI@home zum Download. Hierdurch konnte jeder, der
wollte, die Rechenzeit seines Computers zur Analyse von Radioteleskopdaten bereitstellen, um sich so an der Suche nach außerirdischem Leben aktiv zu beteiligen.
In Deutschland gründete 1990 Dr. Wolfgang Gentzsch, Professor für Mathematik
und Informatik, in Regensburg seine Firma Genias Software. Dort wurde die Software Codine entwickelt, eine erste Managementsoftware für verteilte Ressourcen.
Von 1995 bis 1999 entwarf Genias dann zusammen mit Unicore, Autobench, Medusa, Julius, und Eroppa erste Gridprojekte. 1999 wurde die Firma in Gridware
umbenannt und arbeitete an Schnittstellen zu Globus, Legion, Punch, und Cactus
[Sun Microsystems, Inc., 2002].
Sun Mircosystems übernahm Gridware im July 2000 und konzipierte fortan Codine
2.3. Klassifizierung von Grid-Systemen
9
unter dem Namen Sun Grid Engine3 weiter. Wolfgang Gentzsch ging nach Amerika
und avancierte bei Sun zum Grid-Verantwortlichen [Sun Microsystems, Inc., 2002],
[Meyer, 2005].
Von Seiten der Industrie wurde im April 2004 die Enterprise Grid Alliance mit
der Aufgabe ins Leben gerufen, die seither als Standardisierungsgremium für den
Einsatz von Gridtechnologien im Unternehmensbereich dient. Die Gründer dieses Forums waren EMC, Fujitsu Siemens Computers, HP, Intel, NEC, Network
Appliance, Oracle und Sun Microsystems, AMD, Ascential Software, Cassatt, Citrix, Data Synapse, Enigmatec, Force 10 Networks, Novell, Optena, Paremus und
Topspin [EGA, 2004].
Im September 2005 startete die von der Bundesregierung geförderte D-Grid Initiative4 . Sie dient vorallem dem Zweck, eine nachhaltige Grid-Infrastruktur in
Deutschland aufzubauen. Hierzu kam dann Wolfgang Gentzsch als Koordinator
des D-Grid wieder nach Deutschland zurück.
Im Juni 2006 vereinten sich schließlich das Global Grid Forum und die 2004 gegründete Enterprise Grid Alliance zum Open Grid Forum5 .
2.3 Klassifizierung von Grid-Systemen
Die Aufgabenfelder, in denen man Grid-Computing anwenden kann, umschließen
ein gewaltiges Spektrum. Hierbei ist eine klare Abgrenzung zwischen den einzelnen
Feldern kaum möglich, denn die Grenzen sind fließend und Mischformen sind keine Seltenheit. Dieser Umstand erschwert die Klassifizierung von Grids. Es haben
sich aber mittlerweile in der Literatur drei Gruppierungen von Grids herauskristallisiert, welche deutlich voneinander abgesetzt sind. Die Definitionen stammten
ursprünglich von IBM und werden inzwischen von der Grid-Gemeinde so akzeptiert
[Bart, 2003].
3
http://gridengine.sunsource.net/
https://www.d-grid.de/
5
http://www.ogf.org/
4
10
2.3. Klassifizierung von Grid-Systemen
Computional Grid: Das Anwendungsgebiet dieses Grids liegt in der Bereitstellung von Rechenleistung. Hierbei handelt es sich bei den Maschinen meist um
Hochleistungsserver.
Scavenging Grid: Scavenging bedeutet auf Deutsch eigentlich Plünderung. Damit ist aber die Ausnutzung brachliegender Rechenleistungen von gewöhnlichen
Desktop-PCs gemeint, wenn diese vom Anwender nicht benötigt werden.
Data Grid: Diese Form des Grids ermöglicht den Verbund von Datenbanken
über Unternehmensgrenzen hinweg. So können zum Beispiel Fachbereiche mehrerer
Universitäten mit gleichen Forschungsgebieten ihre Daten zusammenschließen und
gemeinsam verwenden.
Die Definition der Anwendungsfelder sind aber nur eine Form der Klassifizierung.
Eine andere beschreibt die Entwicklung und Größenordnung von Grids [Thompson
und Clavenna, 2003].
Cluster: Unter einem Cluster versteht man den direkten Zusammenschluss von
meist homogenen Servern am gleichen Ort. Diese Zusammenschlüsse entstehen aus
dem Bestreben, Supercomputer aus Standardkomponenten zu bauen, wie es beim
Beowulf-Cluster der NASA der Fall war. Cluster sind wohl die heute am meisten
verbreiteste Form von Grid-Systemen.
Intra-Grid: In ihm wird der Zusammenschluß von Clustern meist innerhalb von
Unternehmensgrenzen definiert, um so Rechenleistung und Datenbestände anderen
Abteilungen zugänglich zu machen. Diese können geographisch verteilt sein, und
es bedarf einer komplexeren Middelware, um Zugriffe zu koordinieren.
Extra-Grid: Diese verbinden nun Intra-Grids und Cluster über Unternehmensund Ländergrenzen hinweg miteinander. Ein solches Unterfangen stellt natürlich
2.4. Anwendungsgebiete von Grid Computing
11
große Herausforderungen an die Integrität, Authensität und Verfügbarkeit der Leistungen. Das wiederum erfordert eine hohe Abstraktion durch die Middleware, die
meist durch Webservices versucht, diesem gerecht zu werden.
Inter-Grid: Hierunter verbirgt sich die Idee von weltweit verfügbaren Grids,
welche alle bisher genannten Klassifizierungen mit einschließen. Diese sind -ähnlich
mit dem Informationsaustausch im Internet heute- jederzeit und überall verfügbar.
2.4 Anwendungsgebiete von Grid Computing
Die Entwicklung eines Grid Systems hängt von den gestellten Anforderungen ab.
Um diese besser abschätzen zu können, muss man wissen, aus welchen Gründen
Grid Systeme aufgebaut werden. Die Beschreibung der wichtigsten Befähigungen
erfolgt in diesem Abschnitt [Berstis, 2002].
Nutzen von brachliegenden Ressourcen: Der einfachste Fall von Grid Computing besteht darin, einen existierenden Auftrag auf eine andere Maschine auszulagern. Dies ist dann sinnvoll, wenn die ursprüngliche Maschine unerwartet hoch
ausgelastet ist. Um eine Aufgabe auf einer anderen Maschine im Grid auszuführen, sind zwei Bedingungen notwendig. Zunächst muss der Mehraufwand für das
ferngesteuerte Ausführen der Arbeit in einem vernünftigen Rahmen bleiben. Sodann müssen die Anforderungen, die die Aufgabe stellt, also Hardware, Software,
Speicher, etc. von der anderen Maschine erfüllt sein.
Dieser Aufwand macht natürlich nicht bei jeder Anwendung Sinn. Im optimalen
Fall braucht eine ferngesteuerte Anwendung während ihrer Laufzeit keine Kommunikation bzw. Interaktion mit der ursprünglichen Maschine. Allerdings wäre
beispielsweise die Auslagerung einer Textverarbeitung mit Sicherheit keine sinnvolle Anwendung, weil hierbei, verursacht durch die systembedingte Interaktion,
hohe Lasten und Latenzzeiten im Netzwerk zu erwarten sind.
12
Die Auslastung von Rechnern am Arbeitsplatz liegt meist unter 5%. Zudem gibt
es in vielen Unternehmen Server, die die meiste Zeit brachliegen. Hier lohnt der
Aufbau eines Grids, welches solche Ressourcen erkennt und diese über eine Schnittstelle zur Verfügung stellt. Doch nicht nur verfügbare Rechenleistung lässt sich
nutzen, sondern auch Spezialhardware oder Speicherplatz. Ebenso lassen sich Applikationen replizieren, um so eine Lastverteilung im Netzwerk vorzunehmen. Als
ein gutes Beispiel hierfür währe das Round Robin Prinzip von Domainservern zu
nennen.
Parallele CPU Ausnutzung: Die Verwendung von sehr vielen parallel betriebenen CPUs ist eine der interessantesten Anwendungen im Grid. Hierzu ist es
notwendig, die Arbeitsschritte in parallel ausführbare Teilaufgaben zu unterteilen. Es gibt zahlreiche Wissens- und Wirtschaftsgebiete, die dies zulassen, z.B. die
Biomedizin, die Berechnung von Finanzmodellen, die Ölforschung, die Bildverarbeitung, die Generierung von Computergrafiken und viele Bereiche mehr.
Die Teilaufgaben einer Anwendung werden dann gleichmäßig über die vorhandenen
CPUs verteilt. Theoretisch wäre so ein System mit n Prozessoren und n Aufgaben
auch n mal schneller als eine einzelne Maschine. Dies ist allerdings in der Realität
nicht der Fall, da hier noch der zusätzliche Verwaltungsaufwand hinzukommt. Denn
zum Einen müssen die Aufgabe in ihre Teilstücke zerlegt und zum Anderen die
Verteilung während deren Abarbeitung gemanagt werden.
Dabei treten eine Reihe von Hindernissen auf, die eine optimale Skalierung der
Teilaufgaben beeinträchtigen und so die Parallelisierung einschränken. Die erste
Einschränkung ist die limitierte Aufspaltung eines Algorithmus. Hierdurch wird
das erste Limit festgelegt. Die zweite Einschränkung geschieht, wenn zwei Teilaufgaben nicht vollständig unabhängig voneinander arbeiten können. Benötigen
zwei Teilaufgaben zum Beispiel Schreibzugriff auf einen Datenbestand, so ist die
Erteilung der Zugriffserlaubnis ein weiteres Hindernis. Ebenso arbeiten Netzwerkbandbreiten, Latenzen und auch Protokollsynchronisierungen gegen Echtzeitanforderungen.
13
Anwendungen: Es gibt einige Faktoren, welche dafür sprechen, Anwendungen
gleich mit Grid-Funktionalität auszustatten. Aber nicht alle Anwendungen können in parallelen Prozessen in einem Grid ablaufen. Es ist schwer bis unmöglich,
Anwendungen, die für einen einzelnen Rechner konzipiert wurden, in ein Grid zu
integrieren. Neue Entwicklungen mit rechenintensiven Arbeitsschritten sollten daher von Anfang an für eine Parallelisierung ausgerichtet werden.
Zusammenarbeit durch virtuelle Ressourcen und Organisationen: Grid
Computing kann ebenfalls die Zusammenarbeit eines großen Publikums ermöglichen und vereinfachen. Die Idee, die man früher unter distributed computing
verstand, ist durch Grids möglich geworden und dies mittlerweile weit über die
damaligen Vorstellungen hinaus. Hierzu können sich beliebig viele Teilnehmer zu
beliebig vielen virtuellen Organisationen zusammenschließen. In dieser virtuellen
Organisation ist es dann möglich, nun bestehende Ressourcen mit den anderen
Benutzern zu teilen.
Derartiges Teilen beginnt mit dem Data Grid. Hier können alle Teilnehmer auf
einen gemeinsamen Datenbestand zugreifen. Sie können aber auch die noch freien Kapazitäten im Grid bündeln, welche dann die potentiellen Kapazitäten eines
alleinstehenden Systems bei weitem überflügeln. Zudem können Datenstände automatisch repliziert und dadurch vor Ausfall gesichert werden. Durch parallelen
Zugriff auf redundante Daten können sodann auch noch die Zugriffszeiten optimiert werden.
Das Teilen begrenzt sich hierbei nicht nur auf die Dateien. Auch Hardware, Dienste,
Lizenzen und Ähnliches sind teilbar. Hierzu überzieht man diese Komponenten mit
einer Virtualisierungsschicht, um so den Zugriff zu standardisieren.
Resource balancing: Der Zusammenschluss vieler Maschinen in einem Grid zu
einer großen virtuellen Maschine ermöglicht ressource balancing. Hierdurch werden
ausgelastete Maschinen entlastet, indem Aufgaben auf andere Maschinen übertragen werden, die noch freie Kapazitäten haben. Aber auch load balancing ermög-
14
2.5. Der Vergleich mit Peer-To-Peer
licht, die Netzlast in einem Grid zu verteilen. Ohne eine Grid-Infrastruktur sind
solche Entscheidungen allerdings um ein Vielfaches schwerer.
Verfügbarkeit: Heute realisiert man die Verfügbarkeit und die Hochverfügbarkeit eines Systems durch Redundanz und Hot-Plugable Komponenten, die einen
Komplettausfall eines Systems verhindern sollen. In einem Grid könnte dies, unabhängig von teuer Hardware, durch reine Softwarelösungen realisiert werden, und
das wiederum unabhängig vom geographischen Standort.
2.5 Der Vergleich mit Peer-To-Peer
In den letzten Jahren haben sich zwei Ansätze entwickelt, die sich um die Problemlösung bemühen, welche unweigerlich beim Arbeiten mit großen verteilten
Rechennetzen entstehen. Diese sind Grid Computing und Peer-To-Peer (P2P).
Beide schreiten in ihrer Entwicklung mit großen Schritten voran, besitzen sehr
erfolgreiche Anwendungen und erfreuen sich immer wiederkehrender temporärer
Aufmerksamkeit der Öffentlichkeit. Was ist nun aber der Vorteil des einen Systems, wie unterscheidet er sich von dem des anderen und welche Vorteile haben sie
beide gemeinsam? Dies soll im folgenden Teil der Diplomarbeit erläutert werden.
Hierzu wird Bezug auf [Foster und Iamnitchi, 2003] und [Hauswirth und Dustdar,
2005] genommen, welche als Einstiegsliteratur zu empfehlen sind.
Was ist P2P?
Um einen abschließenden effektiven Vergleich ziehen zu können, werden zunächst
die Grundprinzipien von P2P erläutert. In diesem Zusammenhang wird sich zeigen,
dass P2P nicht gleich P2P ist und dass die meisten Implementierungen von solchen
Netzen nicht als reine P2P Netze zu bezeichnen sind.
Das Wort Peer bedeutete ursprünglich Gleichgestellter und bezieht sich in der Da-
15
tenverarbeitung auf die Client-Server Funktionalität. In klassischen Netzwerken,
wie z.B. dem Internet, sind die Rollen klar verteilt. Hier gibt es Clients und Server.
Ein Server, sei es für FTP, HTTP, SMTP oder sonst ein Protokoll, bietet Dienstleistungen an, die durch einen Client in Anspruch genommen werden können. Bei
Peers fällt dieser Unterschied jedoch weg, denn jeder Peer kann Dienstleistungen
anbieten und solche aber auch bei anderen Peers nutzen. Peers werden in der
Literatur häufig auch als Nodes oder Servent bezeichnet.
Eine Besonderheit von P2P Netzen ist die Selbstorganisation, die durch autonome
Entscheidungen der einzelnen Peers zustande kommt. Dies bedeutet, dass das Verhalten des kompletten Systems das Resultat eigenständiger Entscheidungen der
Teilnehmer ist. Aus dieser Perspektive betrachtet, ist ein solches Netzwerk auch
als soziale Struktur zu sehen und bleibt somit nicht auf die rein technische Sichtweise beschränkt. So könnten eBay oder Ameisenkolonien eigentlich vom Prinzip
her ebenfalls als P2P bezeichnet werden [Hauswirth und Dustdar, 2005].
Zu den wichtigsten Aspekten von verteilten Systemen gehören deren Skalierbarkeit und Fehlertoleranz. Ein reines P2P System kann fast beliebig skalieren. Fehler,
beispielsweise der Ausfall von Peers, können bis zu einem gewissen Grad verkraftet werden. Denn das Netz verfügt über eine Art Selbstheilung und strickt sich,
wenn nötig, um die Fehlerstelle wieder neu zusammen. Um dies zu ermöglichen,
abstrahieren P2P Netze von der normalen Netzstruktur und überziehen diese mit
einer virtuellen Netzstruktur. Eine tiefergehende Erklärung bietet [Harwood und
Tanin, 2003].
Wie bereits erwähnt, sind aber nicht alle Netze mit P2P Technologie auschließlich reine P2P Netze, sondern sie bedienen sich ebenfalls anderer Techniken, wie
z.B. dem Client-Server Prinzip, weshalb man sie auch Hybridnetze nennt. Ebenso verhielt es sich seinerzeit bei Napster [Ding u. a., 2003]. Um die Komplexität
des Auffindens einer Datei zu umgehen, wurde dort ein zentraler Indexserver verwendet. Diesem Server teilte man bei Eintritt ins Netzwerk die Metadaten seines
Datenbestandes mit. Bei Suchanfragen durchsuchte der Server dann seinen Metadatenbestand und gab die Adressen der Treffer zurück.
16
Was sind die Anwendungsgebiete von P2P?
Der wohl bekannteste Anwendungsfall ist das Filesharing. Hier stellen die Peers
einen ausgewählten Datenbestand den anderen Peers zur Verfügung. Darauf wird
in Kapitel 4 näher eingegangen.
Instant Messaging ist ein weiteres Gebiet, auf dem P2P Netze Verwendung finden.
In den meisten Fällen handelt es sich hierbei um Hybridnetze. Dort existieren
zentrale Server, bei denen man sich anmeldet und die die Benutzerlisten verwalten.
Groupware, wie zum Beispiel Groove6 , nutzen ebenfalls P2P. Groupeware unterstützen Teams in der Zusammenarbeit. Sie offerieren gemeinsame Kalender, Diskussionsforen, Dateiaustausch, Chat und ähnliche Features, die die Kommunikation in Arbeitsgruppen verbessern kann.
P2P versus Grid
Kommen wir nun zu einem direkten Vergleich zwischen Peer-To-Peer und Grid
Computing. Wie bereits erwähnt, verfolgen beide die Ansätze von verteilten Anwendungen und Dienstleistungen. Beide schließen über eine virtuelle Netzwerkschicht die Teilnehmer und ihre Ressourcen zu virtuellen Organisationen zusammen. Der Unterschied lässt sich in zwei Aspekte zusammenfassen:
Als erster Aspekt ist der Service zu erwähnen. Stark vereinfacht könnte man sagen: In einem Grid sind weniger Teilnehmer, die mehr Service bekommen, und
in einem P2P Netz sind mehr Teilnehmer, die weniger Service bekommen. Ein
Grid kann umfangreiche Ressourcen umfassen, wie Computer, Speicherplatz, beliebige Instrumente, Software oder Daten. Diese werden alle über das Internet
und die darüber liegenden Middelware verbunden. Letztere stellt die Ressourcen
dann abstrahiert als Dienstleistungen ins Grid. Solche Dienstleistungen sind Teil
der virtuellen Organisationen, denen auch die potentiellen Nutzer angehören. Die
Nutzer selbst können alle nur im Rahmen vorher definierter Regeln agieren. P2P
6
http://www.groove.net
17
Netzwerke hingegen sind in den meisten Fällen nur auf eine Dienstleistung beschränkt. Außerdem können Ressourcen unvorhersagbar hinzukommen und auch
wieder verschwinden.
Als zweiter Aspekt gilt festzuhalten, dass ein Grid nicht komplett dezentral ist.
Es gibt zentrale Punkte, bei denen man sich registriert und die einem die zugewiesenen Rechte kontrollieren. Ressourcen gehören Besitzern, die die Rechte für
deren Verwendung reglementieren. Die Verbindung der einzelnen Ressourcen sind
in den meisten Fällen stabil. Bei P2P Netzen kommen Anwender unvorhersagbar
dazu oder verschwinden. Alle Peers unterliegen meist gleichen Rechten. Zu berücksichtigen ist weiterhin, das die Verbindungen der Peers nicht stabil sind und sie
jederzeit abbrechen können.
Als Fazit lässt sich daher sagen, dass beide Technologien ihre Vor- und Nachteile
haben. Letztendlich sind diese Verfahren Pionierleistungen auf dem Gebiet der
verteilten Systeme, nur dass das eine sein Feld sozusagen von links und das andere
seines von rechts aufrollt. Ian Foster schreibt hierzu:
Grid and P2P are both concerned with the pooling and coordinated
use of resources within distributed communities and are constructed as
overlay structures that operate largely independently of institutional
relationships. Yet despite these commonalities, there are also major
differences in communities, incentives, applications, technologies, resources, and achieved scale.
Nevertheless, we argue that the vision that motivates both Grid and
P2P computing - that of a worldwide computer within which access
to resources and services can be negotiated as and when needed - will
come to pass only if we are successful in developing a technology that
combines elements of what we today call both P2P and Grid computing.[Foster und Iamnitchi, 2003]
18
3 Standards und Marktführer
Im Bereich des Grid Computing gelten eine ganze Reihe von Standards und Implementierungen, die sich etablieren konnten. Die wichtigsten und interessantesten
hiervon wurden im Rahmen der Arbeit näher unter die Lupe genommen. Dieses
Kapitel bietet einen Überblick der gesammelten Erkenntnisse. Zum Schluss folgt
eine Beurteilung der untersuchten Implementierungen auf das Kriterium hin, inwieweit diese für das zu entwickelnde System verwendbar sind. Die Analyse führte
zu der Entscheidung, dass keiner der untersuchten Kandidaten in Betracht kam,
sondern für die vorliegende Arbeit eine Eigenentwicklung auf Basis eines Filesharing Protokolls bevorzugt wurde.
3.1 Open Grid Forum
Das Open Grid Forum (OGF), ehemals als Global Grid Forum bekannt, ist ein
Standardisierungsgremium mit Mitgliedern und Sponsoren aus Wissenschaft und
Industrie. Im Prinzip also gleichbedeutend der Internet Engineering Task Force
(IETF) für das Internet, veröffentlicht das OGF Empfehlungen zur Standardisierung des Grids.
Besagtes OGF untergliedert sich in die drei Gruppen: eSience Function, Enterprise
Function und Standards Function. eSience Function zeichnet für die Zusammenarbeit mit Wissenschaftlern, Ingeneuren und Lehrenden verantwortlich. Es versucht,
ein gemeinsames Forum für diese Gruppen zu ermöglichen, um so Anforderungen zu erkennen und den Fortschritt allen Beteiligten zugänglich zu machen. En-
3.2. Die Globus Alliance
19
terprise Function hat dieselbe funktionale Beschaffenheit für die Zielgruppe der
IT Industrie und der Software Vertreiber. Die Standards Function trägt die Verantwortung für die Entwicklung von Architekturen, Spezifikationen, Roadmaps,
Glossaren und ähnlichen Tätigkeiten, die sich mit der Standardisierung von Grid
Software beschäftigen.
Der wohl wichtigste und bekannteste Standard, den die OGF verabschiedet hat,
war die Open Grid Service Architecture (OGSA) [Foster u. a., 2002]. Das Hauptanliegen von OGSA besteht darin, alle Ressourcen als Service im Netzwerk zur
Verfügung zu stellen. So sollen Speicherressourcen, Netzwerke, Programme, Datenbanken, Instrumente etc. durch eine virtuelle Komponente als Grid Service
angesprochen werden können. Solch ein Grid Service ist ein Web Service, der die
OGSA Konventionen einhält und diverse Standardschnittstellen implementiert.
3.2 Die Globus Alliance
Die Globus Alliance1 erforscht und entwickelt Grid Technologien und Standards.
Sie besteht aus einem Zusammenschluß von mehreren Institutionen, wie dem Argonne National Laboratory, dem University of Southern California’s Information
Sciences Institute, der University of Chicago, der University of Edinburgh, des
Swedish Center for Parallel Computers, und des National Center for Supercomputing Applications (NCSA).In Fachkreisen gilt die Globus Alliance als eines der
führenden Mitglieder des Open Grid Forums.
Bei [Foster u. a., 2001] wird die Anatomie des Globus Grids ausführlich beschrieben. Diese setzt sich aus der Gliederung von Arbeitsgruppen in virtuelle Organisationen und dem Schichtenmodell für Grids, ähnlich dem ISO/OSI Modell, zusammen.
1
http://www.globus.org/alliance/about.php
20
Application
Collective
Application
Resource
Transport
Connectivity
Fabric
Internet
Link
Internet Protocol Architecture
Grid Protocol Architecture
Virtuelle Organisationen: Die Notwendigkeit von virtuellen Organisationen
(VO) zeigt sich darin, dass man Ressourcen, die im Grid angeboten werden, nur
einem definiertem Anwenderkreis zur Verfügung stellen möchte. Hierzu muss sich
der Anwender in derselben VO wie die Ressource befinden. Innerhalb der VOs gibt
es dann weitere Reglementierungen, die den Zugriff auf die Ressourcen steueren.
Abbildung 3.1: Das Globus Grid Schichtenmodell [Foster u. a., 2001]
Das Schichtenmodell: Wie schon erwähnt, ist dieses Modell an das ISO/OSI
Netzwerkmodell angelehnt. Jede folgende Schicht abstrahiert stets von der jeweils
darunterliegenden Schicht. Man bezeichnet das Grid Modell auch als Sanduhrenmodell, da es sich in der Mitte verjüngt. Mit diesem Begriff soll verdeutlicht werden,
dass dort die Anzahl der Collective- und Resourceprotokolle auf einen wesentlichen
Bestandteil reduziert ist.
Die Fabric ist die allerunterste Schicht. Hier befinden sich die eigentlichen Ressourcen, wie Cluster, Datenbanken oder Instumente. Auf diese Fabric Schicht kann
nur direkt lokal zugegriffen werden. Auch Internetprotokolle wie FTP oder NFS
können Ressourcen dieser Schicht sein. Sie sind allerdings nicht als Teil der Grid
Architektur zu verstehen.
Die darüber folgende Connectivity Schicht beschreibt den Kern der Authentifizierung und Kommunikation der Grid Transaktionen. Kommunikationsprotokolle
ermöglichen den Datenaustausch mit der Fabric Schicht, und Authentifizierungsprotokolle bauen auf der Kommunikation auf. Sie stellen Funktionen zur Authen-
21
zität und Integrität der Datenübertragung bereit.
Sodann baut die Resource- auf der Connectivity Schicht auf und bietet Protokolle, um Zugriffe auf Ressourcen zu initiieren, zu überwachen, zu steueren und
abzurechnen.
Während die Resource Schicht sich um die Interaktion mit einzelnen Ressourcen
bemüht, ist es die Aufgabe der dann folgenden Collective Schicht, sich um globale
Operationen zu kümmern, die mehr als nur eine Ressource in Anspruch nehmen.
Das heißt also, bei einer ankommenden Aufgabe ermittelt die Collective Schicht
zunächst den Bedarf an Ressourcen, findet dieselben als nächstes auf, um sie dann
ihren Aufgaben zuzuweisen.
Application bildet dann die oberste Schicht, in der die Dienste des Grids innerhalb
einer VO in Anspruch genommen werden können.
Globus Toolkit: Als zentrales Produkt der Globus Alliance fungiert die Open
Source Software Globus Toolkit2 . Sie stellt Dienste und Bibliotheken zu den Bereichen verteilte Sicherheit, Ressourcen Management, Monitoring, Resource Discovery und Datenmanagement zur Verfügung. Die aktuelle Version der Software
nennt sich GT4, welche auch Komponenten für das OGSA Framework bereit hält.
Das Globus Toolkit kann in seiner aktuellen Version 4.0.3 allerdings nur für UNIX
Betriebsysteme bezogen werden. Zwar wird eine Java Implementierung angeboten,
jedoch sagt Globus einerseits hierzu, dass die Version auf allen Betriebssystemen
laufen „könnte“ und andererseits wird nicht das vollständige Toolkit von der o.a.
Implementierung unterstützt, sondern nur Kernbestandteile davon.
2
http://www.globus.org/toolkit/about.html
22
3.3. Sun N1 Grid Engine
3.3 Sun N1 Grid Engine
Der Vertrieb der Gridsoftware von Sun läuft unter Sun N1 Grid Engine3 und liegt
zur Zeit in Version 6.0 vor. Diese Software wird als Open Source Projekt unter
SunSource.net4 zum Download bereit gestellt.
Das System funktioniert nach folgenden Schritten: Es akzeptiert Aufgaben (Jobs),
welche von außen in das System eingespeist werden. Jobs sind Benutzeranfragen
nach Ressourcen. Solche Jobs verweilen in einer Warteschlange (Queue), bis das
System sie zur Ausführung freigibt. Geschieht dies, wird der Job an die ausführende
Einheit gesendet und dort erledigt. Das System verwaltet die laufenden Jobs und
speichert die Ergebnisse beendeter Jobs ab.
Zu den Kernaufgaben des Systems gehört das Auffinden der passenden Ressourcen
zur richtigen Zeit für jede Anfrage. Hierzu ermittelt dieses System eine Priorität des
Jobs aus Parametern wie Wartezeit, Ansprüche, Dringlichkeit, Ausführungsdauer,
bevorzugter Behandlung und noch weiteren Faktoren.
Sun realisiert sein Grid in vier Komponententypen. Diese sind Master Host, Execution Host, Administration Host und Submit Host. In den folgenden Erklärungen
werden die dafür benötigten Dienste genannt, welche nachstehend noch kurz erläutert werden. [Sun Microsystems, Inc., 2005d].
Master Host ist das Zentrum der gesamten Clusteraktivität. Er besteht aus
dem Master Dienst sge_qmaster und dem Planer sge_schedd. Zusammen verwalten diese Dienste Jobs und Queues. Im Standardfall ist der Master Host auch
Administration Host und Submit Host.
Execution Hosts sind Gridnodes, die Jobs bearbeiten können. Hierfür verwaltet
jeder Node eine eigene Queue für seinen Host. Der Dienst für diesen Host ist der
3
4
http://www.sun.com/software/gridware/
http://gridengine.sunsource.net/
3.3. Sun N1 Grid Engine
23
sge_execd.
Administration Hosts haben das Recht, alle administrativen Aufgaben auszuführen, um das Grid zu steuern.
Submit Hosts berechtigen Benutzer, Jobs in das Netz zu stellen, und diese zu
konfigurieren. Hierfür gibt es bei Bedarf die grafische Oberfläche QMON.
Die Grid Engine besteht aus drei Diensten:
sge_qmaster ist Mittelpunkt der Verwaltungs- und Planungsaktivitäten. Er hält
Tabellen über die Hosts, Queues, Jobs, Systemlast und der Benutzerberechtigungen. Zudem bekommt er Entscheidungen vom sge_schedd und Anfragen von den
sge_execd Hosts.
sge_schedd ist ein Scheduling-Dienst und hat mit der Hilfe des sge_qmaster
eine Gesamtübersicht über die Aktivitäten des Grids. Er fällt die Entscheidungen,
wann ein Job wo ausgeführt wird, und wie die Daten des Jobs, inklusive seiner
Ergebnisse wem zur Verfügung gestellt werden. Diese Entscheidungen übergibt er
an den sge_qmaster.
sge_execd verwaltet eine Queue mit Jobs, die er nach und nach abarbeitet. In
regelmäßigen Abständen beliefert er den sge_qmaster mit aktuellen Statusinformationen.
Eine Windows Version der Software ist zwar in der aktuellen Version verfügbar, allerdings ist diese mit hohen Anforderungen an das Windowssystem verbunden und
beschränkt sich auf den sge_execd Dienst. Die vordringlichsten Bedingungen sind
zum einen die Installation der Microsoft Windows Services for UNIX (SFU) und
zum anderen der Verzicht auf verschlüsselte Datenübertragung [Sun Microsystems,
Inc., 2005b].
24
3.4. Condor
3.4 Condor
Condor5 ist ein Open Source System zur Lastverteilung von rechenintensiven Aufgaben in einem Netzwerk. Entwickelt wird es an der University of WisconsinMadison. Wie alle großen Systeme in diesem Segment besitzt es die Fähigkeiten,
Aufgaben in eine Warteschlange aufzunehmen, diese durch einen Planer und einem
Prioritätsschema zu bewerten, um sie dann den Ressourcen zuzuteilen. Dafür besitzt es Mechanismen zum Auffinden, Überwachen und Zuweisen von Ressourcen.
Außerdem verfügt es über spezielle Fähigkeiten, um die Rechenleistung nicht nur
von dedizierten Servern, sondern auch von Workstations mit einzubeziehen. Zu
diesem Zweck überwacht Condor permanent die Auslastung der CPU, sowie die
Eingabegeräte am Computer. Nach einer festgelegten Zeit der Inaktivität wird
die Rechenleistung für das Grid freigegeben. Sollte der Benutzer der Workstation
während der Ausführung einer Aufgabe ein Eingabegerät bedienen oder ein NichtCondor Prozess eine zu hohe Last erzeugen, wird die Aufgabe umgehend beendet.
Wenn möglich, wird diese dann auf einem freien Rechner integriert und dort weiter
ausgeführt.
Konzeptionell unterteilt sich Condor in folgende Bereiche: DAGMan, Checkpointing und Migration, Remote System Calls, die ClassAds und die Universen. Sie
werden nun unter Zugrundelegung von [Condor, 2006] erläutert.
DAGMan: Dieses Akronym steht für Directed Acyclic Graph Manager. Mit
ihm lassen sich Abhängigkeiten zwischen den Teilaufgaben einer Gesamtaufgabe
formulieren. Ein Knoten im Graphen entspricht einer Teilaufgabe. So kann man
definieren, welche Teilaufgaben wegen Abhängigkeiten seriell ablaufen müssen und
welche unabhängig parallel abgearbeitet werden können.
Checkpointing und Migration: Mittels dieser Technik ist es möglich, Prozesse auf andere Systeme zu übertragen. Wenn ein Benutzer an seine Workstation
5
http://www.cs.wisc.edu/condor/
3.4. Condor
25
zurückkehrt, wird der aktuell laufende Condor-Prozess umgehend beendet und
auf einem freien Rechner weitergeführt. Hierzu erstellt Condor in regelmäßigen
Abständen Abbilder (Checkpoints) des vom Prozess reservierten Arbeitsspeichers
her. Bei einem Abbruch des Prozesses wird sofort der letzte Checkpoint auf eine andere Maschine übertragen. Diese Abbilder werden dann in den Speicher
geladen (Migration) und können deshalb direkt weiterarbeiten. Dadurch ist das
partielle Abarbeiten einer langwierigen Aufgabe auf Workstations möglich. Eine
solche Fähigkeit wird allerdings mit schweren Einbußen erkauft. So sind zum Beispiel keine Schreibzugriffe auf Dateien erlaubt. Ebenfalls sind viele Systemaufrufe,
wie sleep() oder exec() nicht zulässig. Weiterhin dürfen Kernel-Threads oder
Netzwerkverbindungen im zu sichernden Prozess nicht auftreten. Speicherabbilder
können auch enorme Größen erreichen, die erst mal über das vorhandene Netzwerk transportiert werden müssen. Die Vorraussetzung zum Checkpointing ist,
dass man die Objektdateien des auszuführenden Programms besitzen und diese
mit Condor neu linken muss. Letztendlich kann man sagen, dass dieses Verfahren
nur unter sehr begrenzten Bedingungen eingesetzt werden kann, dann aber enorme
Geschwindigkeitsvorteile bietet.
Remote System Calls: Hierüber ist es möglich, ein Verhalten dergestalt zu
simulieren, als ob der fernaufgerufene Prozess tatsächlich auf dem eigenen Rechner
laufen würde. Dazu werden alle Systemaufrufe des Prozesses umgeleitet. Auch dies
erfordert das Neulinken der Objektdateien mittels Condor.
ClassAds: Sie sind die Grundlage der Aufgabenplanung und der Auswahl passender Ressourcen. Die Rechner im Grid senden regelmäßig Statusinformationen
an einen Server. Diese beinhalten sowohl Informationen über den verfügbaren Arbeitsspeicher, die Rechenleistung und die Auslastung als auch weiterer Daten, die
für die Vergabe von Aufgaben von Interesse sind. Wird nun eine Aufgabe ins Grid
gestellt, kann anhand von den Aufgabenanforderungen jeweils die passende Hardware ermittelt werden.
26
3.4. Condor
Universen: Das Konzept der Universen beschreibt, in welcher Laufzeitumgebung die Aufgaben arbeiten. Am häufigsten werden das Standard Universum und
das Vanilla Universum verwendet. Darüber hinaus gibt es aber noch eine Reihe
weitere Universen, von denen die wichtigsten hier nur kurz Erwähnung finden.
Das Standard Universum unterstützt Checkpointing und Remote System Calls. Bei
diesem Verfahren arbeiten die Aufgaben so, als ob sie auf dem eigenen Rechner
laufen.
Dieses Feature hat das Vanilla Universum nicht in seinem Angebot. Dafür fallen
die oben genannten Vorraussetzungen für Checkpointing und Remote System Calls
weg. Somit wird ermöglicht, dass jede beliebige Software ausgeführt werden darf.
Zuvor überträgt der aufrufende Rechner die benötigten Dateien auf den Zielrechner.
Das Grid Universum bietet eine Schnittstelle zu mehr Gridfunktionalität, die zweigeteilt ist, und zwar in Condor-C und in Condor-G . Condor-C erlaubt, Aufgaben
von der Warteschlange eines Rechners in die eines anderen zu übertragen.
Zudem ist es gegen Netzwerkausfälle ausgesprochen resistent. Eine Beispielszenario
wäre, dass man von irgendeinem Ort der Welt über einen Labtop eine Aufgabe
in einen Condor-Pool stellt, dann offline geht und irgendwann später wieder seine
Verbindung mit dem Pool aufbaut, um sich das Ergebnis abzuholen.
Condor-G wiederum ist eine Schnittstelle, die es ermöglicht, Condor-Aufgaben in
ein Globus Grid einzuspeisen und dort erledigen zu lassen.
Weiterhin gibt es auch die PVM, MPI und Java Universen, die für die Integration
der jeweiligen Technologie dienen.
Als letztes Universum bleibt noch das Scheduler Universum zu erwähnen. In ihm
werden keine Teilaufgaben verteilt, sondern die Aufgabe wird komplett auf dem
Rechner ausgeführt, der sie gestartet hat. Diese Vorgehensweise ermöglicht die
lokale Verwendung von DAGMan.
3.5. BOINC
27
Condor Umgebungen sind in sogenannten Pools organisiert. In einem solchen Pool
existieren Rechner mit verschiedenen Rollen, die hier nun kurz beschrieben werden.
Central Manager: Er hält alle ClassAd Informationen und weist freien Ressourcen passende Aufgaben zu. Je Condor Pool ist nur eine Instanz eines Central
Managers vorhanden.
Execute-Hosts: Sie sind die Arbeiter im Pool, die die zugewiesenen Aufgaben
abarbeiten.
Submit-Hosts: Diese Dienste sind die Auftaggeber im Pool. Hierüber lassen
sich Aufgaben in das Netz stellen. Für jeden Prozess, den ein Submit-Host an den
Pool abgibt, existiert auf selbigem ein Shaddow-Prozess, der als Fernbedienung
für den eigentlichen Prozess zu verstehen ist. Das Standard Universum verhält
sich dabei so, als ob der Shaddow-Prozess der tatsächliche Arbeitsprozess wäre.
Checkpoint Server: Ein solcher Server ist ein optionaler Dienst, der alle Checkpoints im Pool speichern kann. So ein Prozess stellt natürlich große Anforderungen
an Speicherplatz und Netzwerkbandbreite des verwendeten Rechners.
Die Condor Umgebung gibt es für alle gängigen Betriebssysteme, und somit ist sie
auch für heterogene Netze gut geeignet.
3.5 BOINC
Dieses Akronym bedeutet Berkeley Open Infrastructure for Network Computing6 .
Sie ist ein Open Source Framework, welches eine Plattform für Scavenging Grids
6
http://boinc.berkeley.edu/
28
3.5. BOINC
bietet. Durch den BOINC Client kann ein Rechner seine Rechenleistung an beliebige, meist wissenschaftliche Projekte zur Verfügung stellen. Welche Projekte der
Client dann unterstützt, ist abhängig von den Vorlieben des Benutzers, der sich
nämlich die Projektplugins selbst installiert.
Abbildung 3.2: Das BOINC Modell [University of California, 2006]
Ebenso ist es möglich, sein eigenes BOINC Projekt zu erstellen und bei der BOINC
Community dafür zu werben. Wie oben schon erwähnt, sind die meisten Projekte
wissenschaftlicher Natur. Es gibt aber auch anders orientierte Projekte, wie zum
Beispiel das BURP7 Projekt, welches sich mit dem Rendern von 3D Szenen beschäftigt. Der Ursprung von BOINC lag in SETI@home8 . Dieses Projekt beschäftigte sich, wie eingangs schon kurz erwähnt, mit der Suche nach außerirdischer
7
8
http://burp.boinc.dk/
http://www.setiathome.de/
3.6. Auswertung und Beurteilung
29
Intelligenz anhand der Analyse der durch Radioteleskope empfangenen Signale.
In seiner ursprünglichen Version gab es einen speziellen SETI Client. Den konnte
sich der interessierte Benutzer auf seinen Rechner installieren und diesen so in das
Netzwerk eingliedern. 1999 startete SETI@home und 2003 wurde BOINC in seiner
ersten Version veröffentlicht. 2005 hat man dann das klassische SETI@home abgeschaltet; es kann aber als BOINC Projekt weiter unterstützt werden. Der große
Schritt vorwärts von SETI@home zu BOINC bestand darin, dass die Verwaltung
solcher verteilter Projekte vom eigentlichen Projekt gekapselt wurde.
Abbildung 3.2 zeigt den Aufbau eines BOINC Projekts. Die grauen Felder sind die
Projektteile, die vom Entwickler implementiert werden müssen. Auf der Serverseite
ist dies das Project Back End, welches die Anwendungen verteilt und die Resultate
verarbeitet. Das Back End selbst baut auf dem BOINC Server Complex auf, der
das Verteilen und Sammeln von Daten verwaltet.
Dieser BOINC Server Complex besteht aus folgenden Komponenten: Mindestens
einem Scheduling Server, welcher mit den Teilnehmern kommuniziert; ferner einer
relationalen Datenbank, welche alle Informationen zur Arbeit, so wie die Teilnehmer und die Resultate speichert; sodann Bibliotheken und APIs, damit das
Project Back End mit dem Server Complex kommunizieren kann. Weiterhin besteht es aus einem Web Interface für Teilnehmer und Entwickler und zum Schluß
noch aus dem Data Server, welcher über das HTTP [Fielding u. a., 1999] Protokoll
den Dateitransfer zwischen den Clients und dem Server Complex übernimmt.
BOINC ist praktischerweise für alle gängigen Betriebssysteme verfügbar. Applikationen müssen allerdings extra für das Framework entwickelt und für jedes Betriebsystem angepasst werden, welches als Client unterstützt werden soll.
Wie man sehen kann, gibt es eine Fülle sehr interessanter und fortgeschrittener
Projekte im Bereich der verteilten Anwendungen. Globus bietet augenscheinlich
30
die höchste Komplexität und versucht den Themenbereich des Grid Computing
möglichst allumfassend abzudecken. Die Sun Grid Engine und Condor beschäftigen sich hauptsächlich mit der optimalen Verteilung von Aufgaben in einem Grid.
Alle drei Systeme sind für ein lokales Netz mit hoher Bandbreite optimiert. Condor sticht hier mit seinen Checkpoints und Remote System Calls besonders hervor.
Wie oben beschrieben, stellen diese Funktionen allerdings hohe Anforderungen an
die Applikation. BOINC ist speziell als Scavenging Grid im Internet ausgelegt und
universell einsetzbar. Allerdings fordert es für jedes Projekt eine eigene Entwicklung.
Das erste K.o.-Kriterium für die zu treffende Auswahl war die fehlende Vorrausetzung, auf Windows lauffähig zu sein. Hierdurch schied das Globus Toolkit und die
Sun Grid Engine aus, da diese keine vollständige Windowsunterstützung bieten.
Das zweite K.o.-Kriterium beruhte auf der Tatsache, dass die im Grid verwendeten
Applikationen nicht erst implementiert werden sollten, sondern bereits existierende hierfür vorgesehen waren. Somit war auch BOINC und Condor im Standard
Universum aus dem Rennen.
Die direkte Datenübertragung zwischen den Condor-Applikationen Execute-Hosts
und Submit-Host war dann das endgültige Aus für Condor, da dies für das vorgesehene Anwendungsgebiet der vorliegenden Arbeit, nämlich die Bearbeitung von
Aufgaben mit beliebig vielen Rechnern, nicht vertretbar ist.
Kein System greift die erwünschte Idee der Datenverteilung im Peer-To-Peer Stil
auf.
Dies sind die Gründe, warum für die vorliegende Arbeit die Entscheidung zu Gunsten einer Eigenentwicklung auf Basis eines Filesharing Protokolls gefällt wurde.
31
4 Filesharing Protokolle als Data
Grid
Zur Verteilung der Nutzdaten kommt das BitTorrent-Protokoll zur Anwendung.
Nach dem Vergleich mit konkurrierenden Filesharing-Implementierungen stellte
sich diese als die Vielversprechenste heraus. In diesem Kapitel wird die Idee der
Datenverteilung erklärt, sowie auf die grundlegenden Gemeinsamkeiten und Unterschiede von Filesharing-Protokollen eingegangen. Darauf aufbauend folgt ein
kleiner Einstieg in Verteilte Hashtabellen. Nachstehend werden die am meisten
verbreiteten Implementierungen kurz beschrieben und abschließend erfolgt die Begründung der oben genannte Entscheidung. Zum Schluss folgt dann eine vollständige Beschreibung des BitTorrent-Protokolls.
4.1 Die Idee der Datenverteilung
Wie in der Aufgabenstellung beschrieben, soll sich jeder Node die benötigten Fähigkeiten zum Bearbeiten einer Aufgabe bei Bedarf adaptiv in Form eines Moduls
aus dem Netz laden. Das ist genau das zentrale Problem dieser Arbeit, welches
in den folgenden Ausführungen gelöst wurde. Während in herkömmlichen Grids
die auf einem Node installierten Anwendungen als Entscheidungskriterium für die
Vergabe von Jobs gelten und Anwendungen wie SETI@home für lediglich genau
einen Verwendungszweck vorgesehen sind, löst sich der beabsichtigte Ansatz von
der Vorstellung, die Anwendung als feste Ressource und Entscheidungskriterium
zu sehen.
32
4.1. Die Idee der Datenverteilung
Als daraus folgende Konsequenz stellte sich die Frage, wie man die Module auf die
einzelnen Nodes verteilt. Ein oder eventuell mehrere zentrale Anlaufpunkte, die
die Module gleichzeitig sternförmig an vielleicht zehntausende von Nodes verteilen,
stellen eine große Herausforderung an Bandbreite und Performance der Anbieter
dar.
Die Idee war nun, alternativ zu den gängigen Protokollen der Datenverteilung,
wie zum Beispiel FTP und HTTP, Peer-To-Peer Protokolle aus dem FilesharingSegment zu verwenden. In diesen ist es üblich, dass die zu verteilenden Daten von
den Empfängern ebenfalls wieder weiter verteilt werden.
Eine Besonderheit, die alle etablierten Filesharing Protokolle gemeinsam haben,
ist der Umstand, dass Dateien, die ein Peer am Herunterladen ist, auch schon
vom selben Peer bezogen werden können, obwohl dieser seinen download noch
nicht beendet hat. Ermöglicht wird dies dadurch, dass eine zu verteilende Datei
in mehrere Chunks, zu Deutsch „Stücke“, aufgesplittet wird. Ein Peer lädt einen
Chunk, ermittelt mit Hilfe eines Hashwertes seine Authenzität und stellt bei Erfolg
diesen zum Download bereit.
Eine weitere Gemeinsamkeit ist, dass man eine Datei über mehrere Peers parallel
laden kann. Auch dieser Vorgang wird über die Chunks realisiert. So ermittelt ein
Peer eine Liste mit weiteren Peers, die ebenfalls dieselbe Datei am Laden sind,
beziehungsweise bereits vollständig geladen haben. Nun fordert er gleichzeitig von
den jeweiligen Peers, die die entsprechenden Chunks besitzen, die ihm fehlenden
Daten an.
Über diese Verfahren lässt sich, wenn man die Datenmenge in Ihrer Relation zur
Zeit betrachtet, ein exponentiell wachsendes Verteilen der Daten erreichen. Zudem kommt es zu einer Lastverteilung des benötigten Netzwerkverkehrs. Der letzte Punkt ist auch deswegen doppelt interessant, weil so der Verteiler eines Grid
Moduls einerseits den eigenen Netzwerkverkehr und andererseits die damit verbundenen Kosten minimal halten kann.
Der große Unterschied innerhalb der p2p Filesharing Tools ist das Vorgehen zum
4.2. Verteilte Hashtabellen
33
Auffinden der einzelnen Daten. Bei diesen Tools unterscheidet man drei Generationen [Boyvat, 2005], [Hämmerle, 2004].
Protokolle der ersten Generation besitzen einen zentralen Server, der alle im System vorhandenen Dateien und ihren Besitzer kennt. Bei Anfragen wird der zentrale
Server kontaktiert und dann die entsprechende Datei von den dort verzeichneten
Besitzern heruntergeladen. Probleme dieses Verfahrens sind zum einen die Skalierbarkeit, zum anderen die Aktualität der Daten und letztendlich der Single Point
of Failure [Reiser und Kapitza, 2003].
Protokolle der zweiten Generation verzichten auf den zentralen Indexierungsserver.
Ein Peer steht in Verbindung mit bis zu n weiteren Peers. Es wird eine TTL (TimeTo-Live) von m festgelegt. Eine Anfrage samt der TTL m eines Peers wird an die
n verbundenen Peers weitergeleitet. Diese wiederum geben die Anfrage und eine
TTL von m-1 an ihre restlichen n-1 Peers weiter. Ist die TTL bei 0 angekommen,
wird die Anfrage nicht mehr weitergeleitet. Die Treffer werden sodann an den
Anfragenden übergeben. Mit diesem Ansatz können aber, weil nicht alle Knoten
abgefragt, auch nicht alle passenden Daten gefunden werden. Zudem wird das
Netzwerk mit Suchanfragen überflutet und wegen der langen Wege kommt es zu
hohen Latenzzeiten.
Protokolle der dritten Generation beheben jedoch dieses Problem: Über dem bestehenden Netzwerk wird eine zweite virtuelle Netzstruktur in Form einer Verteilten
Hashtabelle aufgebaut. Diese Struktur ersetzt den zentralen Indexierungsserver
von Tools der ersten Generation. Somit ist es möglich, alle gesuchten Dateien im
Netz zu finden, ohne einen zentralen Indexierungsserver zu benötigen.
4.2 Verteilte Hashtabellen
Da die Verteilte Hashtabelle zu den fundamentalen Prinzipien moderner p2p Netzwerke gehört, wird im folgenden Teil der Arbeit ein kleiner Einblick in die Thematik
gegeben, welcher zum Verständnis des Unterkapitels 4.4 notwendig ist.
34
4.3. p2p Implementierungen
Die Verteilte Hashtabelle basiert auf dem Wertebereich einer Hashfunktion. Betritt ein Peer das Netzwerk, so wird die Hashfunktion auf ihn angewandt. Das
Ergebnis entspricht seiner Position im Netzwerk. Zudem bekommt ein Peer einen
Zuständigkeitsbereich zugwiesen, der zum Beispiel beim Chord Algorithmus von
seinem Hashwert bis zum Hashwert-1 seines Nachfolgers verläuft. Alle im Netzwerk angebotenen Daten werden ebenfalls auf die Hash Funktion angewandt. Das
Ergebnis entscheidet, welcher Peer für welches Datum zuständig ist. Beim Chord
Algorithmus wäre dies der Peer mit dem nächst kleineren Hashwert.
Die Speicherung der Inhalte kann auf zwei Arten geschehen: Entweder das Datum
wird direkt auf dem zuständigen Peer gespeichert, oder der Peer referenziert auf das
entsprechende Datum. Bei den üblichen Filesharing Tools wird die zweite Variante
verwendet. Fällt ein Peer aus, übernimmt zum Beispiel beim Chord-Algorithmus
dessen Vorgänger den Wertebereich mit. Die Vorgehensweise zum Auffinden der
Inhalte ist abhängig vom verwendeten Algorithmus. Dieser kann von der unpraktikablen Methode, die Anfrage an den nächsten Peer mit der geringsten Distanz
weiterzuleiten, bis hin zu Methoden mit einer Laufzeit von O(log n) reichen. Gängige Implementierungen sind CAN, Chord, Kademlia, Pastry und Tapestry. Eine
ausführliche Erläuterung zu verteilten Hashtabellen und eine Beschreibung des
Chord Algorithmus bietet [Harwood und Tanin, 2003].
4.3 p2p Implementierungen
Die gängigen Protokolle des p2p Filesharing werden im weiteren Verlauf kurz erläutert. Eine Vertiefung in die Thematik und Grundlagen der nun folgenden Beschreibungen findet man in [Ding u. a., 2003]. Abschließend folgt eine Beurteilung
der Protokolle hinsichtlich der benötigten Eigenschaften und letztendlich die Begründung der Auswahl des BitTorrent-Protokolls.
35
eDonkey2000 ist ein proprietäres Protokoll der Firma MetaMachine, welches
durch den gleichnamigen Client1 implementiert wird. Abgekürzt wird es mit ed2k.
Ursprünglich gehörte ed2k den Protokollen der ersten Generation an, wurde aber
später durch die Implementierung des Kademlia Algorithmus um Verteile Hashtabellen erweitert und gilt nun als Hybridclient. Das eMule Projekt2 schuf eine Open
Source Implementierung des ed2k Protokolls, die seit der Version 0.42 auch den
Kademlia Algorithmus unterstützt [MetaMachine, 2003], [Heckmann und Bock,
2002].
Gnutella gehört zu den Protokollen der zweiten Generation und ist eines der ersten völlig dezentralen Filesharing-Netze. Entwickelt hatte es die AOL-Tochterfirma
Gnullsoft. Kurz nach der Veröffentlichung im Jahre 2000 wurde die Entwicklung
jedoch eingestellt. Die Analyse des Protokolls3 brachte allerdings eine Vielzahl von
Klonen hervor, welche auch diverse Protokollerweiterung implementierten. Zu den
bekanntesten Implementierungen gehören heute die beiden Open Source Projekte
Limewire4 und Shareaza5 .
FastTrack stellt eine Erweiterung des Gnutella Protokolls dar, das von Kazaa6
erstmals implementiert wurde. Besagte Erweiterung besteht aus sogenannten Supernodes. Dabei werden Rechner zu Supernodes, welche über ausreichend Bandbreite und Rechenkraft verfügen. Diese sind Indexserver für eine Teilmenge anderer
FastTrack Clients. Die Clients geben dabei die Metadaten der von ihnen zur Verfügung gestellten Daten an den Server. Suchanfragen werden an den Supernode
geschickt, welcher wie bei Gnutella diese Anfragen an weitere Supernodes sendet.
1
http://www.edonkey2000.com/
http://www.emule-project.net/
3
http://rfc-gnutella.sourceforge.net/
4
http://www.limewire.com/
5
http://www.shareaza.com/
6
http://www.kazaa.com/
2
36
OpenFT steht für „Open FastTrack“ und ist eine Open Source Entwicklung7 ,
die sich an dem FastTrack Protokoll orientiert. Man unterscheidet hier die Nodes in die drei Typen User, Search und Index. Der User Node, der gewöhnliche
Teilnehmer im OpenFT Netzwerk, ist mit mehreren Search Nodes verbunden, welchen er die Metainformationen zu seinen freigegebenen Daten sendet und seine
Suchanfragen an diese stellt. Search Nodes sind Nodes, welche eine relativ große
Netzwerkbandbreite besitzen. Sie verwalten eine Menge von User Nodes und indizieren die Metainformationen zu den freigegebenen Daten derselben. Zudem leiten
sie Suchanfragen an weiter Search Nodes weiter, bzw. beantworten diese Anfragen. Index Nodes unterliegen den höchsten Anforderungen. Ein Kriterium dabei
ist, dass der Node seit relativ langer Zeit online ist. Diese Index Nodes verwalten
Listen von Search Nodes und werden von Search Nodes auf der Suche nach weiteren Search Nodes konsultiert. Wenn die Voraussetzungen stimmen, kann ein Node
gleichzeitig Search Node und Index Node sein.
BitTorrent Dieses Protokoll8 unterscheidet sich insofern von anderen Protokollen, als bei ihm ursprünglich keine Suche vorgesehen war. Es basiert auf Torrentdateien und Tracker Servern. Die Torrentdatein werden meist über Webseiten
verbreitet. Für jedes Datum existiert eine eigene Torrentdatei. Diese beinhaltet
unter anderem Informationen zu dem Namen, der Größe und den Hashwerten der
einzelnen Chunks eines Datums, sowie der URL des Trackers. Letzterer verwaltet
alle Peers, die diese Daten am Laden sind, beziehungsweise geladen haben. Peers,
die am Laden sind, werden leecher genannt, was auf Deutsch eigentlich „Sauger“
bedeutet. Dahingegen werden Peers, die das komplette Datum besitzen, seeder
genannt, auf Deutsch Säer. Neue Versionen von BitTorrent verwenden mit dem
Kademila Algorithmus auch Verteilte Hashtabellen, um so einen trackerlosen Betrieb zu ermöglichen [BitTorrent.org, 2006a]. Hierbei übernehmen die Peers für eine
ihnen zugewiesene Teilmenge der Hashwerte die Rolle der Tracker. Das originale
BitTorrent Programm wurde von Bram Cohen in Python geschrieben und ist Open
Source. Azureus9 , ebenfalls Open Source, gilt als der verbreitetste Bittorrentclient.
7
http://gift.sourceforge.net/
http://www.bittorrent.org/
9
http://azureus.sourceforge.net/
8
37
Ein Auswahlkriterium bestand für diese Arbeit darin, dass es sich um ein offenes
und gut dokumentiertes Protokoll handeln sollte. Da keine umfangreichen Suchfunktionalitäten benötigt wurden, ein Umstand, der ausführlich in Kapitel 5 erläutert wird, bot sich das BitTorrent Protokoll an. Als einziger Nachteil gilt nochmals
festzuhalten, dass alle Anfragen für ein bestimmtes Modul von beliebig vielen Peers
über einen Tracker laufen, ein Faktor, der sich in der Netzlast bemerkbar machen
könnte. Zudem ist ein Tracker ein Single Point of Failure.
Der Einsatz von verteilten Hashtabellen würde für das geplante Vorhaben keinen
Vorteil bringen, da für ein Modul auch weiterhin nur ein Peer verantwortlich wäre und dessen Netzbandbreite mit hoher Wahrscheinlichkeit im Bereich privater
Internetanschlüsse liegt. Dies könnte zur Folge haben, dass ein Peer mit relativ
geringer Bandbreite für ein Modul mit relativ hoher Nachfrage verantwortlich ist.
Die Verwendung eines Protokolls der zweiten Generation entfiel, da hier nur Teilmengen der bestehenden Netze durchsucht werden. Die Wahl fiel somit, sozusagen
zwangsläufig, auf das BitTorrent Protokoll.
4.5 Beschreibung des BitTorrent Protokolls
Dieses Unterkapitel lehnt sich an die Protokoll Spezifikation [BitTorrent.org, 2006a]
von BitTorrent.org an und ergänzt diese um Grafiken, sowie Erklärungen und
Beispiele zum besseren Verständnis.
Einführung
BitTorrent besteht aus drei Kernbestandteilen, die nun erläutert werden:
38
4.5. Beschreibung des BitTorrent Protokolls
Leecher
Seeder
Leecher
Leecher
Abbildung 4.1: BitTorrent Nutzdaten Kommunikation
Downloader ist die Endanwender-Software. Durch die Angabe der Metainformationen in Form einer Torrent Datei erhält der Downloader alle notwendigen
Informationen über den Download und kann diesen dann durchführen. Trotz des
Namens Downloader fungiert dieser eigentlich als Peer, was bedeutet, dass Daten
nicht nur zum Runterladen sondern auch zum Hochladen bereitgestellt werden.
Wie bereits im Abschnitt 4.3 beschrieben, differenziert man die Peers in Seeder
und Leecher. Abbildung 4.1 veranschaulicht die Kommunikation derselben untereinander.
Leecher
Seeder
Tracker
Leecher
Leecher
Abbildung 4.2: BitTorrent Tracker Kommunikation
39
Tracker: Ein Tracker ist ein Server, der über das HTTP Protokoll [Fielding u. a.,
1999] mit den Downloadern kommuniziert. Alle Downloader melden sich beim
Tracker an und erhalten Informationen über andere Downloader, bei denen die
Daten bezogen werden können. Abbildung 4.2 veranschaulicht die Kommunikation
des Trackers.
Torrent Dateien beinhalten die Metainformationen zu den zum Download bereitgestellten Daten. Sie umfassen die URL des Trackers, die Namen der Daten,
die Größe der Daten, sowie die Hashwerte der einzelnen Chunks.
Nachstehend wird der klassische Weg zur Datenverteilung über BitTorrent beschrieben. Dabei werden folgende Bestandteile benötigt:
• einen normalen Webserver
• eine statische Datei mit Metainformationen
• einen BitTorrent Tracker
• einen Downloader, der die Original Daten vorhält
• einen Webbrowser für den Endanwender
• Einen Downloader für den Endanwender
Um nun Daten zum Download zur Verfügung zu stellen, sind folgende Schritte
notwendig:
1. Den Tracker starten
2. Die Dateierweiterung .torrent in als mimetype
application/x-bittorrent im Webserver eintragen
3. Den Webserver starten
40
4. Die .torrent Datei mit den Metainformationen erstellen
5. Die Metainformationen auf den Webserver stellen
6. Einen Downloader starten, welcher schon alle Daten besitzt.
Um nun als Endnutzer den Download zu starten, muß folgendes getan werden:
1. BitTorrent Downloader installieren, wenn nicht schon geschehen.
2. Aus dem Web die .torrent Datei laden.
3. Mit der BitTorrent Software die .torrent Datei öffnen.
4. Einen Speicherort wählen.
5. Warten bis der Download beendet ist.
6. BitTorrent Downloader beenden.
Die Datenserialisierung
Die .torrent Dateien, sowie die Nachrichten des Trackers an die Peers, sind serialisierte Datenobjekte. Deren Ähnlichkeit dieser Objekte zu denen der Skriptsprache
Python lässt sich dadurch erklären, dass die original BitTorrent Software in Python geschrieben wurde. Besagte Serialisierung erfolgt nach einfachen Regeln, auf
welche im Folgend eingegangen wird. Man unterscheidet dabei vier Datentypen:
Strings für beliebig lange Zeichenketten werden kodiert, indem man die Länge
der betreffenden Zeichenkette zur Basis zehn, gefolgt von einem Doppelpunkt, an
dieselbe als Prefix anhängt. So entspricht 4:apfel dem String ’apfel’.
41
Integer definiert die Darstellung ganzer Zahlen. Auch wenn der Name die Vermutung aufkommen lassen könnte, so ist die Größe der Zahl dennoch nicht beschränkt. Die Kodierung erfolgt dergestalt, dass am Anfang ein ’i’ steht, gefolgt
von der Zahl zur Basis zehn und mit einem ’e’ abgeschlossen wird. Als Beispiel:
i42e entspricht der 42, und i-42e entspricht der -42. Alle Zahlen mit führender
Null, außer der Null selbst, also i0e, sind ungültig.
Lists sind Listen, welche für eine Sequenz beliebig vieler Elemente, auch solcher
unterschiedlicher Typen, genutzt werden. Man kodiert diese über ein ’l’ am Anfang, gefolgt von den Nutzdaten. Abgeschlossen wird mit einem ’e’. So entspricht
l5:wurst4:brote der Liste [wurst, brot].
Dictionaries werden durch ein ’d’ am Anfang, gefolgt von den Nutzdaten und
einem abschließenden ’e’ kodiert. Die Nutzdaten hängt man auch hier einfach
aneinander, wobei immer zuerst der Schlüssel angegeben wird, gefolgt vom Wert.
Im Beispiel sieht das dann wie folgt aus:
d5:wurst4:brot5:getreidel5hafer6roggenee entspricht
{’wurst ’: ’brot ’, ’getreide’ : [’hafer’ ,’roggen ’] }.
Das Torrent Dateiformat
d8 : announce30 : h t t p : / / l o c a l h o s t : 6 9 6 9 / announce13 : c r e a t i o n
datei1158566350e4 : infod5 : f i l e s l d 6 : lengthi302080e4 : pathl7 : rar
. e x e e e d 6 : l e n g t h i 1 0 5 e 4 : p a t h l 3 : xml9 : modul . xmleee4 : name3 : j o b 1 2 :
p i e c e l e n g t h i 2 6 2 1 4 4 e 6 : p i e c e s 4 0 : ’ \ x99XS5\ xab \ x9b \ x f 9 \ x1a \ xa5 \
xd9 \ x e b f v \ xa0e \xdb\ x9e&\xd5 \ x17&\xd6 \x16O\ x93−\x06b \ x0c \ x055
\ x18 \ x83 \ xeb \ x f 1 5 n \ x f 9 \ xbaee
Abbildung 4.3: Beispiel einer .torrent Datei
Eine .torrent Datei enthält ein Dictionary, welches die beiden Schlüssel announce
und info beinhalten muss.
42
announce enthält einen String, der die URL des Trackers ist.
info umfasst ein weiteres Dictionary, indem die eigentlichen Metainformationen
der Daten abgelegt sind. Es beinhaltet die Schlüssel: name, piece length, pieces
und files.
name ist ein String, welcher als Name der zu speichernden Datei oder des zu
speichernden Verzeichnisses gewählt wird.
piece length beinhaltet eine Zahl, die der Größe der einzelnen Chunks, also der
Größe der Dateisegmente entspricht. Sie ist immer ein Potenz von der Basis zwei.
Standardmäßig wird hier die Zahl 218 verwendet, welches 265 KB entspricht. In
neueren Versionen findet man auch die Zahl 220 , also 1 MB, als Standardeinstellung.
pieces enthält ein String, dessen Länge ein Vielfaches von 20 beträgt. Dieser
ist wiederum in einzelne Strings der Länge 20 zu unterteilen. Die so erhaltenen
Teilstrings entsprechen den SHA1 Hashcodes [Eastlake und Jones, 2001] der einzelnen Chunks mit gleichem Index und ermöglichen dadurch eine Verifizierung der
geladenen Daten.
length kommt als Schlüssel nur vor, wenn der Torrent lediglich auf eine einzelne
Datei verweist. Der Wert entspricht dabei der Größe der Datei in Byte.
files kommt zum Einsatz, wenn mehrere Dateien vorhanden sind. Er beinhaltet
dann eine Liste, die mit je einem Dictionary pro Datei, wobei jedes Dictionary die
folgenden Schlüssel length und path enthält:
length ist wie auch zuvor, die Länge der Datei in Byte.
43
path ist eine Liste mit Strings, welche die Unterverzeichnisse wiedergeben, in der
die Datei liegt. Der letzte Eintrag der Liste entspricht dann dem Dateinamen.
1
{
’ c r e a t i o n ␣ date ’ : 1158566350 ,
’ announce ’ : ’ h t t p : / / l o c a l h o s t : 6 9 6 9 / announce ’ ,
’ info ’ : {
’ files ’: [
{ ’ path ’ : [ ’ r a r . exe ’ ] , ’ l e n g t h ’ : 3 0 2 0 8 0 } ,
{ ’ path ’ : [ ’ xml ’ , ’ modul . xml ’ ] , ’ l e n g t h ’ : 1 0 5 } ] ,
’ p i e c e ␣ length ’ : 262144 ,
’ name ’ : ’ j o b ’ ,
’ p i e c e s ’ : " ’ \ x99XS5\ xab \ x9b \ x f 9 \ x1a \ xa5 \ xd9 \ x e b f v \ xa0e \xdb\ x9e
&\xd5 \ x17&\xd6 \x16O\ x93−\x06b \ x0c \ x055 \ x18 \ x83 \ xeb \ x f 1 5 n \
x f 9 \ xba "
}
2
3
4
5
6
7
8
9
10
11
12
}
Abbildung 4.4: Dekodierung vom Listening in Abbildung 4.3
Abbildung 4.3 zeigt das Beispiel einer .torrent Datei und korrespondierend hierzu
ist in Abbildung 4.4 die dekodierte Datenstruktur in Python zu sehen. Dabei fällt
auf, dass dort ein zusätzlicher Schlüssel mit dem Namen creation date auftaucht,
welcher optional ist, der allerdings in [BitTorrent.org, 2006a] nicht dokumentiert
wurde. Die Länge des Strings von pieces beträgt 40. Dies bedeutet, dass die zu
übertragenden Daten in zwei Chunks unterteilt werden.
Abbildung 4.5 zeigt die Ausgabe der Metainformationen, wie sie auf der Konsole erscheinen, wenn man sie über das hierfür vorgesehene BitTorrent Programm
btshowmetainfo.py abruft.
Die Tracker Kommunikation
Die Peers kommunizieren mit den Trackern über das HTTP Protokoll, wobei die
zu übertragenden Informationen mit einer GET Anfrage verschickt werden. Abbildung 4.6 zeigt eine solche Anfrage.
44
1
btshowmetainfo 20021207 − decode B i t T o r r e n t m e t a i n f o f i l e s
2
3
4
5
6
7
8
9
10
m e t a i n f o f i l e . : modul . xml . t o r r e n t
i n f o hash . . . . . : 6 e 8 5 4 6 b 3 3 a 7 5 f b 4 f 9 5 9 9 f e f 7 d 8 3 9 f e 9 8 0 4 2 f b a 2 7
d i r e c t o r y name: j o b
files . . . . . . . . . :
r a r . exe ( 3 0 2 0 8 0 )
xml/modul . xml ( 1 0 5 )
a r c h i v e s i z e . . : 302185 ( 1 ∗ 262144 + 4 0 0 4 1 )
announce u r l . . : h t t p : // l o c a l h o s t : 6 9 6 9 / announce
Abbildung 4.5: Konsolenausgabe der Metainformationen vom Listening in Abbildung 4.3
GET / announce ? info_hash=8z%B9%E4%3E%A0%12%29%BB7%CB%2B%99%84VWM%
F1%C3%5E&peer_id=M4−4−1−−e9987a353295&p o r t =6881&key=7 e f b f 5 3 4
&uploaded=0&downloaded=0& l e f t =21129&compact=1&e v e n t=s t a r t e d
HTTP/ 1 . 1 \ r \ nHost : 1 9 2 . 1 6 8 . 0 . 2 : 6 9 6 9 \ r \ nConnection : c l o s e . .
Accept−e n c o d i n g : g z i p \ r \ nUser−a g e n t : B i t T o r r e n t / 4 . 4 . 1 \ r \n\ r \
n
Abbildung 4.6: Beispiel eines GET Requests
Für derartige Anfragen gibt es die folgende Parameter: info_hash, peer_id, ip,
port, uploaded, downloaded, left, event, failure_reason, interval, complete,
incomplete und peers.
info_hash ist der 20 Byte lange SHA1 Hashcode vom serialisierten Wert info
Feldes in der .torrent Datei.
peer_id meint eine 20 Byte lange Zeichenfolge zur Identifizierung des Peers.
Jeder Peer generiert für einen Download sich selbst eine neue zufällige Zeichenfolge.
45
ip stellt ein optionales Feld dar, welches die IP Adresse oder den DNS Namen
enthält, unter welchem der Peer zu finden ist. Dieses Feld wird hauptsächlich dann
verwendet, wenn das Ziel auf der selben Maschine wie der Tracker läuft.
port gibt die Portnummer an, auf die der Peer hört. Das Standardverhalten
eines Peers ist es, auf Port 6881 zu hören. Schlägt dies fehl, werden inkrementell
die Ports bis 6889 ausprobiert. Gelingt dies jedoch nicht, so bricht der Peer ab.
uploaded ist die absolute Menge hochgeladener Bytes, kodiert in ascii und zur
Basis zehn.
downloaded meint die absolute Menge heruntergeladener Bytes, kodiert in ascii
und zur Basis zehn.
left zeigt die Menge der noch zu herunterzuladenden Bytes an, kodiert in ascii
und zur Basis zehn. Dieser Wert kann nicht durch das Feld downloaded und der
Dateigröße ermittelt werden, da auch downloads durch fehlgeschlagene Integritätsprüfungen möglicherweise wiederholt wurden.
event ist ein optionaler Schlüssel, welcher die Werte started, completed, stopped oder empty besitzen kann, wobei das empty gleichbedeutend mit dem Weglassen dieses Parameters ist. Der Peer setzt started, wenn er mit dem Download
beginnt. completed bedeutet, dass der Download fertig ist. Dies wird aber nicht
geschickt, wenn der Download schon zu Beginn fertig war. Beendet der Peer den
Datenverkehr, wird der Wert auf stopped gesetzt. Die Antwort des Trackers ist
ein serialisiertes Dictionary, welches folgende Schlüssel hat:
failure_reason ist ein optionaler Schlüssel. Wird er gesetzt, so muss ein Fehler
aufgetreten sein, alle anderen Schlüssel werden nicht benötigt. Der Wert ist dann
46
ein String mit einer Fehlerbeschreibung.
interval gibt die Anzahl der Sekunden an, die ein Peer warten sollte, bis er eine
erneute Anfragen stellen kann.
complete ist ein optionales Feld, dass angibt, wieviele Peers das Datum vollständig haben.
incomplete ist ein optionales Feld, welches anzeigt, wie viele Peers das Datum
nicht vollständig haben.
peers: Hier wird ein String hinterlegt, dessen Länge ein Vielfaches von sechs ist.
Je sechs Zeichen stehen für die Adresse eines Peers, wobei die ersten vier die IP
Adresse - und die rechtlichen Zwei die Portnummer beschreiben.
1
2
3
4
5
6
{
’ p e e r s ’ : ’ \ xc0 \ xa8 \ x00 \ x02 \ x1a \ xe1 \ xc0 \ xa8 \ x00 \ x03 \ x1a \ xe1 \ xc0 \
xa8 \ x00 \ x04 \ x1a \ xe1 ’ ,
’ i n t e r v a l ’ : 1800 ,
’ complete ’ : 3 ,
’ incomplete ’ : 1
}
Abbildung 4.7: Beispiel einer Tracker-Antwort
Abbildung 4.7 zeigt eine solche in Python decodierte Antwort eines Trackers.
Nimmt man nun die ersten vier Zeichen des peers String und konvertiert diese
in das Dezimalsystem, so erhält man die Folge 192,168,0,2. Die Zeichen an Stelle
fünf und sechs entsprechen 26 und 225. Diese wiederum entsprechen zusammen
(26 ∗ 256) + 225 = 6881, was dem Standartport für BitTorrent-Peers entspricht.
Die Adresse des Peers ist also 192.168.0.2 : 6881.
47
Die Peer Kommunikation
Die Peers kommunizieren untereinander über das BitTorrent Peer Protokoll, das
ein bidirektionales TCP Protokoll ist, bei dem die Peers sich auf die Chunks der
.torrent Datei beziehen, wobei der Index Null dem ersten Chunk entspricht.
Beendet ein Peer den Download eines Chunks und prüft erfolgreich mittels des
SHA1 Hashwertes die Integrität desselben, so teilt er dann dessen Besitzt an alle
weiteren Peers mit.
Das Übertragungsprotokoll besteht aus einem Handshake und einem folgenden,
nicht endenden Übertragungsstrom von einzelnen Nachrichten, wobei jede Nachricht ihre eigene Länge als Prefix trägt.
Besagter Handshake beginnt mit der Zahl 19, gefolgt von dem 19 Zeichen langen
String ’BitTorrent protokol’. Danach folgen weiter acht reservierte Bytes, welche
zur Erkennung von Erweiterungen dienen. Als nächstes kommen 20 Byte für den
SHA1 Wert des info Wertes aus der .torrent Datei. Dies ist derselbe Wert wie
der info_hash bei der Tracker-Kommunikation. Nun folgen noch 20 Bytes mit der
peer_id. Der Gegenpart schickt ebenfalls seinen Handshake. Stimmen jetzt der
info_hash überein und unterscheidet sich die peer_id, kommt eine Verbindung
zustande.
Die Nachrichten zeichnen sich dadurch aus, dass nach der Längenangabe ein Byte
mit der Definition ihres Nachrichtentyps folgt. Ist dabei die Länge der Nachricht
Null, so entspricht dies einer Keep-Alive Nachricht, welche im Regelfall alle zwei
Minuten versendet wird. Trifft in einem definierten Zeitraum keine Nachricht des
Gegenparts ein, wird die Verbindung geschlossen. Für Nachrichten sind folgende
Bytes mit ihrer Bezeichnung definiert: 0 choke, 1 unchoke, 2 interested, 3 not
interested, 4 have, 5 bitfield, 6 request, 7 piece und 8 cancel. Werden mit
den Nachrichten Nummern übertragen, so sind diese mit vier Byte Länge definiert.
choke, unchoke, interested and not interested: Diesen Nachrichten folgen keine weiteren Informationen.
48
bitfield wird nur einmal, und zwar gleich nach dem Handshake übertragen.
Die Nutzbytes repräsentieren dabei jeweils acht Indizes der in der .torrent Datei
definierten Teilstücke. Dies bedeutet, dass das erste Byte die Chunks 0-7 repräsentiert, das Zweite 8-15 und so weiter. Gelesen wird das Ganze von links nach
rechts, wobei das höchste Bit den niedrigsten Index wiedergibt und das niedrigste
Bit den höchsten. Ist ein Bit gesetzt, so besitzt der Peer dieses Stück und gibt es
zum Download frei. Hat ein Peer noch keinen Chunk, so muss das Bitfield nicht
übertragen werden.
have schickt ein Peer an alle mit ihm verbundenen Peers, sobald er einen Chunk
fertig geladen und dessen Integrität geprüft hat. Der Wert des Feldes beinhaltet
dessen Index.
request überträgt die drei Nummern index, beginn und length. Auf diese Weise fordern Peers gegenseitig die Nutzdaten an. Die erste Nummer legt fest, welcher
Chunk gemeint ist. Die zweite ist der Offset und klärt damit, an welcher Position
des Chunks zu beginnen ist. Die dritte Zahl sagt, wieviele Bytes übertragen werden
sollen, wobei die Länge allerdings eine Potenz der Basis zwei und auf maximal 217
beschränkt sein muss. Der Standartwert liegt bei 215 .
cancel hat den selben Inhalt wie request. Es wird gegen Ende des Gesamtdownloads verwendet, wenn der Peer im Endgame Mode ist. Dazu später mehr.
piece ist die Antwort auf einen Request. Es beinhaltet zuerst die Indexnummer,
dann den Offset, gefolgt von den Nutzdaten des Downloads.
Die Reihenfolge der Teilstücke, die Peers laden, ist zufällig, um so eine möglichst
große Fächerung des gesamten Inhaltes über das Netzwerk zu bewerkstelligen.
Choking ist ein Verfahren von BitTorrent, um die maximale Leistung aus TCP
herauszuholen. Werden über viele TCP Verbindungen gleichzeitig Daten übertra-
49
gen, so bricht die Übertragungsgeschwindigkeit ein. Aus diesem Grund hält ein
Peer immer nur eine gewisse Anzahl von Kanälen offen (unchoked) und der Rest
wird abgewürgt (choked). Ein Datenverkehr zwischen zwei Peers kann nur zustande kommen, wenn ein Peer interessiert ist, und der andere diesen nicht choked. Die
Ausgangssituation einer Verbindung ist not interested und choked.
Gegen Ende des Gesamtdownloads fallen die Peers dann in den Endgame Mode.
Dieser soll dafür sorgen, dass der Download nicht durch eine langsame Verbindung
unnötig in die Länge gezogen wird. Hierzu fordert der Peer von mehreren Peers
gleichzeitig die letzten Teile an. Ist ein Teilstück vollständig übertragen, so bekommen die anderen Peers ein cancel geschickt, um die Übertragung zu beenden.
Abbildung 4.8 veranschaulicht anhand eines mitgesnifften und aufgearbeiteten Beispiels die eben beschriebene Kommunikation zweier Peers.
50
Peer 1 : P r o t o c o l Name Length : 19
P r o t o c o l Name : B i t T o r r e n t p r o t o c o l
Reserved E x t e n s i o n Bytes : 0000000000000000
SHA1 Hash o f i n f o d i c t i o n a r y : 387AB9 . . .
Peer ID : 4D342D342D31 . . .
Peer 2 : P r o t o c o l Name Length : 19
P r o t o c o l Name : B i t T o r r e n t p r o t o c o l
Reserved E x t e n s i o n Bytes : 0000000000000000
SHA1 Hash o f i n f o d i c t i o n a r y : 387AB9 . . .
Peer ID : 4D342D322 . . .
Peer 2 : Message Length : 2
Message Type : B i t f i e l d ( 5 )
B i t f i e l d data : 80
Peer 1 :
Message Length : 1
Message Type : I n t e r e s t e d ( 2 )
Message Type : Unchoke ( 1 )
Message Type : Request ( 6 )
P i e c e i n d e x : 0 x00000000
Begin o f f s e t o f p i e c e : 0 x00000000
P i e c e Length : 0 x00004000
Message Type : P i e c e ( 7 )
P i e c e i n d e x : 0 x00000000
Data i n a p i e c e : FFD8FFE . . .
Message Type : P i e c e ( 7 )
P i e c e i n d e x : 0 x00000000
Data i n a p i e c e : DC894AC . . .
Message Type : Choke ( 0 )
Abbildung 4.8: Beispiel einer Peer Kommunikation
51
5 Konzeption
Das folgende Kapitel präsentiert die Ergebnisse der Planungsphase. Anhand einer
Rollenverteilung wurden Aufgabengebiete definiert und ihren Akteuren zugeordnet. Darauf aufbauend wird die Notwendigkeit einer komplexen Verwaltung der
Gridteilnehmer begründet und ihre Funktionsweise erklärt. Danach erfolgt der
Plan, wie die Datenverteilung unter den Beteiligten zu organisieren ist und zum
Schluss wird beschrieben, wie die wichtigsten Arbeitsabläufe der Akteure zu verlaufen haben.
5.1 Rollenverteilung
Für eine klare Abgrenzung der Aufgabenbereiche und der Eingriffsmöglichkeiten
definiert das System drei Rollenmodelle: den GridManager, den JobServer und den
ExecutionNode. Abbildung 5.1 zeigt die Verteilung der Aufgabenberiche in einem
Use-Case Diagramm.
Der GridManager stellt die zentrale Verwaltung des gesamten Grids dar. Je
System existiert nur eine Instanz dieses Akteurs. Seine Aufgaben bestehen in der
Verwaltung und Verteilung von Aufgaben und ExecutionNodes. JobServer melden
sich beim GridManger an und übertragen ihre Anforderungen an diesen. Auch
ExecutionNodes melden sich hier an und warten auf kommende Instruktionen.
Kann der GridManager die Anforderungen der JobServer erfüllen, weist er diesen
eine festgelegte Anzahl an ExecutionNodes zu.
52
5.2. Nodeverwaltung
Der JobServer repräsentiert eine Gesamtaufgabe. Wie zuvor erwähnt, meldet
sich dieser beim GridManager an und teilt diesem mit, unter welchen Bedingungen
die Aufgabe erfüllt werden soll. ExecutionNodes verbinden sich mit dem JobServer
und fordern Teilaufgaben an. Nach Verifizierung durch den GridManager wird die
Teilaufgabe an den ExecutionNode übertragen. Equivalent hierzu verhält sich das
Übertragen der Resultate an den JobServer.
Der ExecutionNode erledigt die Abarbeitung der ins Grid gestellten Aufgaben. Er kommuniziert mit dem GridManager und bekommt von diesem Aufgaben
zugewiesen. Die Aufgaben holt sich der ExecutionNode beim JobServer ab, bearbeitet diese und überträgt das Resultat an selbigen zurück.
5.2 Nodeverwaltung
Wie zuvor beschrieben, tauscht der GridManager mit den ExecutionNodes Nachrichten aus. Hierzu müssen für jeden dieser Nodes Daten, wie Netzwerkadressen,
Kategorisierungen sowie weitere Variablen zwischengespeichert und schnell abgerufen werden können. Aus diesem Grund wurde für das Kommunikationsmanagement der Nodes eine sortierte und dynamisch verlinkte Liste entworfen, die in
ihrem Funktionsumfang die Verwaltung der ExecutionNodes unterstützt. So wird
der GridManager dazu befähigt, mit einer großen Anzahl von häufig wechselnden
Kommunikationspartnern über verbindungslose Protokolle Daten auszutauschen
und zuzuordnen. Das Motiv dieser Verwaltung liegt in der Zielgruppe der potentiellen ExecutionNode-Anwender. Diese sind Privatanwender mit ihren eigenen PCs,
die den Node als Plugin eines Instant-Messengers laufen lassen. Deshalb ist es nicht
vorhersehbar, wann und wie lange ein ExecutionNode angemeldet bleibt, bzw. wie
lange die Rechenleistung des Computers durch ihn in Anspruch genommen werden
darf.
Abbildung 5.2 illustriert den Aufbau der erwähnten Liste, deren Herzstück der
Hook ist. Er hält eine Verbindung zum kleinsten Element der Liste. Solche Listen-
5.2. Nodeverwaltung
Abbildung 5.1: Use Case Diagramm: Rollenverteilung
53
54
5.2. Nodeverwaltung
elemente werden Links genannt. Die einzelnen Links sind in einer doppelt verlinkten Liste miteinander verbunden, wobei der größte Link wieder auf den kleinsten
referenziert. Es bildet sich also ein Kreis. Jeder Link zeigt auf einen Node. Diese
Nodes stehen nun repräsentativ für die einzelnen ExecutionNodes und dienen dem
GridManager als Ablage für zuzuordnende Daten. Neben der Verbindung zum
kleinsten Element besitzt der Hook des Weiteren einen Iterator, welcher endlos
im besagten Kreis die Links sequentiell ansteuert und anstehende Ereignisse ihrer
Nodes bearbeitet. Zu den weiteren Funktionalitäten eines Hooks gehören die Fähigkeiten des Auffindens, des Einfügens und des Entfernens von Listenelementen.
Durch den Mehraufwand der Sortierung können so vor allem bei großen Listen mit
Hilfe der binären Suche sehr schnelle Zugriffszeiten mit einer Laufzeit von O(log n)
bewirkt werden.
Abbildung 5.2: Interne Verknüpfung der Nodes im Beispiel
Ein Node ist nun aber nie nur Bestandteil einer einzelnen solchen Listenstruktur, sondern immer von zweien. Zum einen existiert eine Hauptliste, im folgenden
5.3. Datenverteilung
55
MainHook genannt, und mindestens noch eine Teilliste, die SubHook genannt wird.
Diese SubHooks sind in ihrer Anzahl nach oben nicht weiter limitiert. Die MainHook Liste hält Referenzen auf alle im Grid registrierten Nodes. Die SubHooks
stehen für die einzelnen JobServer, welche das Grid mit Arbeit beauftragen. So
entspricht die Zuordnung eines Nodes in eine SubHook Liste der Zuordnung eines
ExecutionNodes zu einem JobServer. Zudem existiert noch eine weitere SubHook
Liste mit dem Namen IdleHook, die alle unbeschäftigten Nodes beinhaltet. Der
MainHook Liste unterliegt zudem die Verwaltung aller SubHooks.
5.3 Datenverteilung
Die Verteilung der Nutzdaten erfolgt, wie schon erwähnt, über das BitTorrentProtokoll. Hierzu müssen von allen Nutzdaten, die versendet werden sollen, die
Metainformationen als .torrent Dateien erstellt werden. Wer eine solche Metadatei besitzt, hat das Recht, von den verteilenden Rechnern die Nutzdaten zu
laden. Deswegen benötigt man ein Verfahren, welches regelementiert, wie und unter welche Bedingungen die Metadaten verteilt werden. Zu diesem Zweck unterteilt
das System die Kommunikation in drei Kanäle: den Steuerungskanal, den Metadatenkanal und den Nutzdatenkanal.
Ein JobServer registiert sich über den Steuerungskanal beim GridManager und
übergibt diesem die Ausführungsbedingungen seines Auftrags. Der GridManger
weist nun, sobald er diese Bedingungen erfüllt, dem JobServer eine Menge an ExecutionNodes zu. Die Kenntnis, welcher Node zu welchem Job gehört, bleibt beim
GridManager. Dieser teilt nun den zugewiesenen ExecutionNodes über Steuerdaten mit, von welchem JobServer sie sich wann ihre Metadaten abholen können.
Daraufhin verbinden sich die ExecutionNodes über den Metadatenkanal mit dem
JobServer, der sich über den Steuerungskanal die Nodes vom GridManager bestätigen lässt. Danach erfolgt die Übertragung der Metadaten an die ExecutionNodes.
Nach Erhalt der Metadaten beginnt der Download der benötigten Datenmengen
über den Nutzdatenkanal, sprich über das BitTorrent-Protokoll. Veranschaulicht
wird dieser Vorgang in Abbildung 5.3.
56
5.3. Datenverteilung
Abbildung 5.3: Dienste und Kommunikation
Die Strukturierung der Nutzdaten unterliegt nur wenigen Reglementierungen. Zusammen mit den Teilaufgaben müssen die ausführbaren Programme in einem gemeinsamen Hauptverzeichnis liegen.Dabei ist die Struktur innerhalb dieses Ordners bis auf das Verzeichnis ./metadata nicht vorgeschrieben. Besagter Ordner
mit seiner manifest.xml Datei stellt die Schnittstelle zwischen den Nutzdaten
und dem Grid dar. Einen beispielhaften Aufbau einer solchen Struktur zeigt Teil
A der Abbildung 5.4.
Die manifest.xml Datei, deren Aufbaubeschreibung später erfolgt, definiert, welche Dateien zusammen mit welchen Parametern zum Bearbeiten der einzelnen
Teilaufgaben benötigt werden. Hieraus separiert der JobServer neue XML Dateien, welche jeweils eine Teilaufgabe beschreiben, und generiert aus diesen Dateien
zusammen mit den in ihnen festgelegten Nutzdaten die Metadateien. Diese XMLund Metadaten werden ebenfalls im ./metadata Ordner gespeichert. Zur Veranschaulichung dient hier Teil B der Abbildung 5.4.
5.4. Arbeitsablauf
57
Abbildung 5.4: Struktur persistenter Daten
5.4 Arbeitsablauf
Die Rolle des GridManagers ist zweigeteilt. Zum einen in den Part des NodeManagers, welcher sich um die Betreuung der ExecutionNodes kümmert und zum
anderen in den Part des JobScheduler mit der Verwaltung von Aufgaben und der
Betreuung der JobServer. Dabei erfolgt die Zusammenarbeit von NodeManager
und JobScheduler über die gemeinsame Verwendung einer MainHook.
Der NodeManager nimmt Nachrichten von den ExecutionNodes entgegen. Trifft
eine Nachricht ein, so startet er in der MainHook die Suche nach einem zutreffenden Nodeeintrag. Ist kein Node auffindbar, wird ein neuer Node erstellt und in die
58
5.4. Arbeitsablauf
Nachricht
empfangen
Suche Node
in MainHook
gefunden
nicht
gefunden
erzeuge
Node
Nachricht gültig?
ja
nein
bearbeite
Nachricht
stell Antwort in
Nachrichtenqueue
des Nodes
Abbildung 5.5: Zustandsdiagramm: NodeManager Nachrichtenempfang
MainHook eingepflegt. Als nächstes ist die eintreffende Nachricht auf ihre Gültigkeit zu überprüfen und bei Erfolg zu bearbeiten. Erhält der ExecutionNode eine
Antwort, dann wird diese nicht gleich versandt, sondern in eine Warteschlange im
Node eingefügt. Erst die Hauptschleife überträgt die Daten an die ExecutionNodes.
Abbildung 5.5 illustriert das Eintreffen einer Nachricht.
Abbildung 5.6 zeigt das Zustandsdiagramm der Hauptschleife. Sie iteriert endlos
über alle Nodes und bearbeitet diese in zwei Arbeitsgängen. Der erste Schritt
liegt in der Diagnose von Timeouts. Ein Node beinhaltet Zeitstempel mit der
Ankunft der letzten Nachricht seines ExecutionNodes und mit der Verweildauer in
verschiedenen Status. Liegt das letzte Lebenszeichen zu lange zurück oder ist der
Status festgefroren, wird der Node aus der Liste entfernt.
5.4. Arbeitsablauf
59
Im zweiten Schritt wird geprüft, ob in der Node-Instanz Nachrichten hinterlegt
wurden. Ist das der Fall, so werden sie an den ExecutionNode übertragen. Der
GridManager sendet für diesen ExecutionNode bestimmte Nachrichten nicht direkt, sondern stellt dieselben in eine Warteschlange des entsprechenden Nodes,
die dann von der Hauptschleife abgefragt wird. Hierdurch werden die Nachrichten
zuerst gesammelt und darauf in einem Arbeitsschritt an den Empfänger versandt.
Deshalb kann eine möglichst homogene Netzauslastung generiert werden. Dies ist
möglich, da keine Anforderung besteht die Nachrichten schnellstmöglich an die
ExecutionNodes zu übermitteln.
Abbildung 5.6: Zustandsdiagramm: NodeManager Hauptschleife
60
5.4. Arbeitsablauf
Iterator zeigt auf
nächstfolgenden Job
ja
Iterator aufrufen
definierten Intervall
warten
nein
Schleife
fortsetzen?
Job startbereit?
ja
nein
nein
Job in Ausführung?
ja
Job beenden?
ja
SubHook
erzeugt
SubHook
regulieren
SubHook
beenden
nein
Abbildung 5.7: Zustandsdiagramm: JobScheduler Hauptschleife
Die Bestimmung des JobSchedulers liegt im Verwalten der Aufgaben der JobServer
und in der Kommunikation mit diesen. Dabei iteriert nun der JobScheduler in
der Hauptschleife permanent über alle Aufgaben und managed sie. Abbildung
5.7 veranschaulicht diesen Vorgang. Wird eine Aufgabe noch nicht ausgeführt,
ist zunächst zu überprüfen, ob die Bedingungen einen Start erlauben. Trifft das
zu, so wird hierfür ein SubHook generiert. Dieser SubHook bekommt dann durch
die MainHook einen Teil der Nodes aus der IdleHook-Liste zugewiesen. Ist eine
Aufgabe bereits in Ausführung, so wird versucht, die Anzahl der beteiligten Nodes
zu regulieren. Das bedeutet, wenn zum Beispiel durch Timeouts zugewiesene Nodes
wegfallen, werden der Aufgabe neue zugeteilt. Soll eine Aufgabe beendet werden,
ist die entsprechende SubHook-Liste zu löschen und die Nodes sind der IdleHook
zuzuführen. Diese Vorgänge wiederholen sich in zeitlich definierten Abständen, bis
der GridManager beendet wird.
5.4. Arbeitsablauf
61
Abbildung 5.8: Zustandsdiagramm: JobServer Initialisierung
Ein JobServer verwaltet die Bearbeitung eines JobPackage, welches die Daten und
Informationen zum Ausführen einer Aufgabe enthält. Beim Start eines JobServers baut dieser zuerst eine Verbindung zum JobScheduler auf und registriert sich
dort. Danach analysiert er das Aufgabenpaket und bereitet die Teilaufgaben in
sogenannten Tasks zur Verarbeitung auf. Daraufhin überträgt er die Ausführungsbedingungen, welche Policy genannt werden, an den JobScheduler. Im Anschluss
daran tritt der JobServer in drei verschiedene Zustände. Erstens überträgt er die
62
5.4. Arbeitsablauf
Tasks in Form von Metadaten auf die ExecutionNodes und sammelt die Ergebnisse
ebenfalls als Metadaten wieder ein. Zweitens verteilt und sammelt er alle Nutzdaten, auf die die Metadaten referenzieren. In seinem dritten und letzten Zustand
wartet er auf das Eintreffen eines Ergebnisses und verarbeitet dieses. Abbildung
5.8 veranschaulicht diese Vorgänge.
Abbildung 5.9: Zustandsdiagramm: JobServer Metadatenaustausch
Auf den Metadatenaustausch wird im Folgenden näher eingegangen, Abbildung
5.9 unterstützt hierbei die Beschreibung. Der JobServer wartet auf eingehende
Verbindungen der ExecutionNodes. Kommt eine solche Verbindung zustande, wird
an den JobScheduler eine Autorisierungsanfrage für den betreffenden Node gestellt.
Erfolgt eine positive Antwort, so teilt der ExecutionNode mit, ob er Metadaten
für einen neuen Task erhalten oder die Metadaten eines Ergebnisses senden will.
Nach erfolgter Übertragung wird die Verbindung beendet.
5.4. Arbeitsablauf
63
Die ExecutionNodes bekommen, wie oben bereits erwähnt, nachdem sie einem
JobServer zugeordnet wurden, Metadaten für einzelne Tasks übertragen. Nach Erhalt dieser Metadaten beginnt der Download der darauf bezogenen Nutzdaten.
Ein ExecutionNode wartet fortwährend auf das Eintreffen von Nutzdaten. Ist der
Download eines Datenpaketes beendet, wird es analysiert und die Ausführung der
enthaltenen Anweisungen vorbereitet. Danach werden diese sequentiell ausgeführt.
Sodann ist aus den erstellten Resultaten eine Metadatei zu erstellen und an den
JobServer zu übertragen. In Abbildung 5.10 ist dieser Vorgang graphisch dargestellt.
Abbildung 5.10: Zustandsdiagramm: ExecutionNode Taskbearbeitung
64
6 Implementierung des
Grid-Systems
Die Programmierung des Systems erfolgte in der Skriptsprache Python1 . Hierfür
lagen die Gründe in den folgenden Vorteilen. Python erlaubt dank seiner unkomplizierten Syntax und den umfangreichen Standartmodulen sehr rasche Entwicklungszyklen. Die Original-BitTorrent-Implementierung wurde ebenfalls in dieser
Sprache verfasst und ist somit leicht zu integrieren. Da es sich um eine Skriptsprache handelt und Interpreter für alle gängigen Systeme vorliegen, kann sie als
betriebssystemunabhängig bezeichnet werden. Dieser Umstand ist zwar auf Seiten
der ExecutionNodes uninteressant, weil dieselben auf Windows ausgelegt werden
sollen, fügt aber auf der Seite des GridManagers und des JobServers den Vorteil der
Portierbarkeit hinzu. Die Performance, welche bei Skriptsprachen bekannterweise
weit hinter denen von gängigen Programmiersprachen zurücksteht, fiel in diesem
Fall nicht ins Gewicht, da keine zeitkritischen oder rechenintensiven Berechnungen
in Python selbst ausgeführt werden. Diese sind nämlich für Windows kompilierte Programme und somit von Python unabhängig. Die Implementierung erfolgte
in Python 2.4 und BitTorrent 3.4.2. Als Literatur für Python ist [Martelli u. a.,
2005] und [Pilgrim, 2004] zu empfehlen, wobei letztere kostenlos aus dem Web zu
beziehen ist.
1
http://www.python.org/
6.1. Modul- und Klassendefinitionen
65
6.1 Modul- und Klassendefinitionen
Im Folgenden werden die einzelnen Packages und relevanten Klassen beschrieben.
Die detaillierte Beschreibung der Klassen und ihrer Methoden kann in der Quelltextdokumentation nachgelesen werden.
Das Communication Package dient zur Kapselung der Netzwerkverbindung.
Siehe hierzu Abbildung 6.1. Hierdurch ist eine einfache Verwendung von verbindungsorientierter und verbindungsloser Kommunikation möglich, ohne direkten
Zugriff auf die Sockets zu haben. Dieses Verfahren bietet die Möglichkeit, das Modul später noch um Features zu erweitern, wie zum Beispiel Verschlüsselung, ohne
die restlichen Applikationen durch diesen Eingriff zu tangieren.
Eine Besonderheit dieses Moduls besteht darin, dass man direkt Instanzen beliebige Objekte versenden kann und diese dann als solche auch wieder auf der Empfängerseite empfangen werden. Die Serialisierung und die Dekodierung werden intern
über die ComCodec Klasse implementiert. Verwendet wird das Package folgendermaßen: Eine Klasse, die hierüber kommunizieren will, muss von der ComDef Klasse
erben, sowie die Methoden recv(self, msg, address) und send(self, msg,
address) überschreiben. Dann braucht die besagte Klasse nur noch eine Instanz
von ClientCom, ServerCom oder DgramCom bilden und als einen der Parameter
eine Referenz auf sich selbst übergeben.
Während für UDP/IP Kommunikation die Klasse DgramCom instanziert werden
muss, sind für TCP/IP Verbindungen die Klassen ClientCom und ServerCom vorgesehen. ClientCom baut sodann eine Verbindung zu der Adresse auf, die dem
Konstruktor übergeben wurde. Als Gegenpart hierzu nimmt die ServerCom Instanz Verbindungen auf der Adresse an, die sie über den Konstruktor erhalten
hat. ServerCom kann beliebig viele TCP/IP Verbindungen verwalten, welche über
die Empfängeradresse im ServerCom.recv(self, msg, address) Aufruf unterschieden werden.
66
Communication
ComCodec
DgramCom
+logger: logging._loggerClass
+loop: bool
+codec: ComCodec
+rthread: threading.Thread
+__init__(self,address:tuple,comdef:ComDef)
+recv(self)
+send(self,msg:object,address:tuple)
+close(self)
1 +logger: logging._loggerClass
+seperator: string
+__init__(self,seperator:string="\r\n")
+decode(self,data:string): tuple
+encode(self,encode:object): string
1
Com
+ip: string
+port: int
+socket: socket.socket
+comdef: ComDef
+close(self)
StreamCom
+cons: dict
+sema: threading.Semaphore
+recv(self,address:tuple,msg:object)
+send(self,msg:object,address:tuple=None)
+closeCon(self,address:tuple)
+__del__(self)
1
1
1
1
ComDef
+__init__(self)
+recv(self,msg:object,address:tuple)
+appendRawData(self,data:string,address:tuple): string
+setRawData(self,data:string,address:tuple)
ClientCom
+cthread: threading.Thread
+__init__(self,addresss:tuple,comdef:ComDef)
+connectSock(self)
Connection
n
ServerCom
+othread: threading.Thread
+flag: threading.Event
+__init__(self,address:tuple,comdef:ComDef,
listen:int)
+openSock(self)
+__del__(self)
+sock: socket.socket
+address: tuple
+com: StreamCom
+codec: ComCodec
+loop: bool
+maxd: int
+CLOSED: int = 1
+__init__(self,sock:socket.socket,address:tuple,
com:StreamCom)
+recv(self)
+send(self,msg:object)
+__del__(self)
Abbildung 6.1: Communication Package
1
67
Das NodeRepresentation Package ist die Implementierung der in Kapitel
5.2 beschriebenen Nodeverwaltung. Abbildung 6.2 zeigt das zugehörige Klassendiagramm.
Die Verwendung erfolgt über die Klasse MainHook. Die wichtigsten Eigenschaften
werden im Folgenden kurz beschrieben: Mit den Methoden add und drop stellt die
Klasse die Funktionalität zum Einfügen und Löschen von Nodes in eine sortierte
Liste von miteinander verknüpften Links zur Verfügung. SubHook Klassen lassen
sich mit createHook instanzieren und mit freeHook wieder entfernen. fitHook
versucht, die Sollzahl der eingegliederten Node Instanzen zu regulieren. Die Methode next stellt den Zugriff auf den Iterator dar, und mit search kann man
mittels eines Adress-Port-Tuples über die binäre Suche nach einer entsprechenden Node Instanz im Hook fanden. Eine MainHook Instanz gilt als threadsicher
und kann so gefahrlos von mehreren Klassen parallel verwendet werden, wie es im
GridManager der Fall ist.
Das Auxiliary Package (siehe Abbildung 6.3) dient als Depot für Definitionen und Hilfsklassen. Mit seinen Unterklassen bietet das DefSet eine Struktur
für allgemeingültige Definitionen und Standartwerten an. Zusammen mit dem
NodeManager gehört der JobScheduler zu den Bestandteilen des GridManagers.
Durch den JobServer wird der TorrentServer instanziert. Er verteilt die .torrent
Dateien an die TorrentClients, welche von den ExecutionNodes verwendet werden.
Der Metadatenkanal ist die Bezeichnung für die Kommunikation zwischen TorrentServer und TorrentClient. Zur Überwachung von BitTorrent gestarteten Downloadthreads dient der TorrentWatcher. Über getData lassen sich so die Namen
fertig heruntergeladener Metadatenpakete erfragen. Stehen keine fertigen Pakete
an, so blockiert die Methode, bis ein Download beendet wurde.
68
NodeRepresentation
MainHook
+subhooks: dict
+idle: string = "idle"
+sema: threading.Semaphore = Semaphore(1)
+__init__(self)
+add(self,node:Node,hook:SubHook=None)
+drop(self,address:tuple)
+free(self,address:tuple,blocking:bool=True)
+createHook(self,hook:string,request:int=0,
modul:string=None)
+fitHook(self,hook:string,modul:string=None,
blocking:bool=True,kickState:int=None)
+freeHook(self,hook:string)
Hook
+links: Link
+iterator: Link
+len: int
+__init__(self,sema:threading.Semaphore)
+next(self,blocking:bool=True): Link
+resetIt(self)
+add(self,node:Node,blocking:bool=True)
+drop(self,address:tuple,blocking:bool=True)
+search(self,address:tuple,start:Link=None,
len:int=None,nearest:bool=False,blocking:bool=False,
r:int=0): Link
+groupMessage(self,msg:object)
+acquire(self,blocking:bool=True)
+release(self,blocking:bool=True)
1
1
1
IdleHook
+modules: dict
+ammount(self,modul:string): int
SubHook
n
Node
n
+mainhook: MainHook
+request: int
+maximum: int
+tserver: tuple
+tracker: tuple
+distribute: bool
+__init__(self,sema:threading.Semaphore,
mainhook:MainHook,request:int=0)
Link
1
+node: Node
+hook: SubHook
+head: Link
+tail: Link
+__init__(self,node:Node,head:Link=None,
tail:Link=None,subhook:SubHook=None)
+__cmp__(self,other): int
+__add__(self,i:int): Link
+__sub__(sellf,i:int): Link
1
+address: tuple
+status: string
+msg: [[],{}]
+modules: list
+sublink: Link
+lastmsg: float
+euthanized: bool = False
+data: string = ""
+timer: dict
+ctorrents: list
+__init__(self,address:tuple,status:string,
modules:list=[])
+updateStatus(self,status:string)
+hasModul(self,modul): bool
+addModul(self,modul:string): bool
+delModul(self,modul:string): bool
1
+__cmp__(self,x): int
+isDownloading(): bool
+isUploading(): bool
+isIdle(): bool
+isBusy(): bool
+isTrafficAllowed(): bool
+isSharingAllowed(): bool
Abbildung 6.2: NodeRepresentation Package
Timeout
Message
= 2
= 3
= 4
= 0
+INIT: int = 0
+EXIT: int = 2
+REQUEST: int = 3
+ALLOWED: int = 3
+DENIED: int = 4
+ALLOWDIS: int = 5
+DENYDIS: int = 6
JobMessage
+WHATSMYADDRESS: int
+GETTORRENT: int = 1
+WHATSMYTSERVER: int
+WHATSMYTRACKER: int
+RESETWORKSPACE: int
+MESSAGE: int = 5
Abbildung 6.3: Auxiliary Package
+dcom: Communication.DgramCom
+mhook: MainHook
+ltime: float = 0.3
+address: tuple
+loop: threading.Thread
+__init__(self,msg:object,address:tuple=None)
+recv(self,msg:Object,address:tuple)
+mainloop(self)
+checkvalidity(self,node:Node)
+appendRawData(self,data:string,address:tuple)
+resetIdle(self)
+groupMessage(self,m:string)
+close(self)
NodeManager
+connect(self,server:tuple,myaddress:tuple)
+download(self,saveas:string,myaddress:tuple,
mytserver:tuple,request:string="t")
+upload(self,path:string,myaddress:tuple,
mytserver:tuple)
TorrentClient
+VERSION: char = 0x00
+NODEMANAGER: tuple = ("", 6669)
+JOBSCHEDULER: tuple = ("",6670)
+TORRENTSERVER: tuple = ("",6671)
+JOBLISTEN: int = 5
DefSet
+DOWNLOAD: int = 32
+UPLOAD: int = 16
+IDLE: int = 8
+BUSY: int = 4
+DATATRAFFIC: int = 2
+ALLOWSHARE: int = 1
NodeState
+LASTMSG: int = 60
+DOWNLOAD: int = 1500
+UPLOAD: int = 1500
+IDLE: int = 1800
+BUSY: int = 60
+DATATRAFFIC: int = 60
+ALLOWSHARE: int = 60
Auxiliary
1
1
TorrentWatcher
+active: dict
+done: list
+failed: list
+todo: list
+jserver: JobServer
+address: tuple
+savepath: string
+torrentpath: string
+modulid: int
+tallac: TorrentAllocator
+__init__(self,jserver:JobServer,
address:tuple=DefSet.TORRENTSERVER,
listen:int=5)
+close(self)
+prepare(self)
+mainloop(self)
+connection(self,sock:socket.socket)
TorrentServer
+mhook: MainHook
+scom: Communication.ServerCom
+jobs: dict
+wait: int = 2
+thread: threading.Thread
+__init__(self,mhook:MainHook)
+addJob(self,address:tuple,policy:object)
+getStatus(self)
+startJob(self,address:tuple)
+mainloop(self)
+close(self)
JobScheduler
+ext: string = ".torrent"
+flag: threding.Event
+data: list
+blacklist: list
+files: list
+__init__(self,folder:string)
+mainloop(self)
+getData(self): string
+close(self)
1
1
Hook
ServerCom
DgramCom
+__init__(self)
ComDef
+othread: threading.Thread
+__init__(self,address:tuple,comdef:ComDef,
listen:int)
+openSock(self)
+__del__(self)
+loop: bool
1 +codec: ComCodec
+recv(self)
+close(self)
1
Communication (Auszug)
+links: Link
+iterator: Link
+len: int
1 +next(self,blocking:bool=True): Link
+resetIt(self)
+search(self,address:tuple,start:Link=None,
len:int=None,nearest:bool=False,blocking:bool=False,
r:int=0): Link
+groupMessage(self,msg:object)
+acquire(self,blocking:bool=True)
+release(self,blocking:bool=True)
NodeRepresentation (Auszug)
1
69
70
BitTorrentApp ist das BitTorrent Softwarepaket. btdownloadheadless und
btdownloadcurses sind zwei Downloader mit zwei unterschiedlichen KonsolenBenutzerschnittstellen. Beide laden und verteilen anhand einer Metadatei die in
ihr referenzierten Nutzdaten. btlaunchmany und btlaunchmanycurses sind ebenfalls zwei Downloader mit differenzierenden Benutzerschnittstellen. Sie laden und
verteilen allerdings alle Metadaten in einem angegebenen Verzeichnis. Durch Hinzufügen und Entfernen der Torrents zur Laufzeit startet und beendet man den
entsprechenden Datentransfer. Mit btmakemetafile werden .torrent Dateien erstellt. Neue Tracker weist man ihnen mit btreannounce zu. Den in der Metadatei
gesetzten Tracker ändert man mit btrename, und mit btshowmetainfo können alle Informationen zu einem Torrent ausgegeben werden. btcompletedir dient zum
Erstellen einer Metadatei von einem Verzeichnis mit all seinen Inhalten. Letztendlich wird duch bttrack noch ein Tracker zur Verfügung gesetellt.
Zudem befindet sich im eben beschriebenen Softwarepaket ein Ordner mit dem
Namen BitTorrent, der eine Vielzahl von Modulen enthält, die in den oben genannten Programmen Verwendung finden. Von besonderem Interesse ist hierbei
bencode.py. Diese Datei beinhaltet Funktionen zur Serialisierung und Rekonstruktion von Metadaten.
BitTorrentApp (Auszug)
BitTorrent (Auszug)
launchmanyasthread
bencode
bencode
maketorrentfromlist
Abbildung 6.4: Paketauswahl BitTorrent API
Um BitTorrent in das System zu integrieren, waren einige Abänderungen nötig. So stellt launchmanyasthread eine Abwandlung von btlaunchmany dar, die
es ermöglicht, die dort beschriebenen Funtkionen als Thread laufen zu lassen.
maketorrentfromlist ist eine abgeänderte Version von btmaktetorrent. Jene
erlaubt das Erstellen von Metadaten, bei denen die Nutzdaten nicht alle im selben
Verzeichnis liegen oder nur eine einzelne Datei sind, sondern eine Auswahl von lo-
71
kal beliebig verteilten Dateien. Eine Darstellung der explizit verwendeten Module
und ihre Position zueinander ist in Abbildung 6.4 zu sehen.
Die Implementierung von BitTorrent erwies sich bei der Analyse des Quellcodes aus
Sicht der Softwaretechnik als unsauber. So ist beispielsweise die Umsetzung eine
Mischung aus hauptsächlich prozeduraler Programmierung mit einer gelegentlichen
Verwendung der Objektorientierung, die eine Darstellung in einem Klassendiagramm nicht zuließ. Einige Dateien enthalten darüber hinaus eins zu eins kopierte
Funktionen aus anderen Dateien, anstatt diese modular zu kapseln. Schließlich
wurden auch Syntaxfehler im Quellcode gefunden, die nur deswegen bislang nicht
auffielen, weil die betroffenen Codezeilen nur äußerst selten interpretiert werden.
Die ExecutionNode Klasse ist die Hauptklasse eines ExecutionNodes. Sie versendet in regelmäßigen Abständen über eine DgramCom Instanz Nachrichten an
den GridManager. Durch den TorrenClient werden Metadaten vom JobServer runter oder zu ihm hinauf geladen. Über den Methodenaufruf launchTorrents wird
mittels launchmanyasthread der für die Metadaten vorgesehene Ordner fortwährend auf Torrents geprüft. Solange eine Metadatei sich in diesem Ordner befindet,
werden die in ihr beschriebenen Nutzdaten verteilt, beziehungsweise auch geladen.
Abbildung 6.5 klärt den Zusammenhang dieser Klassen.
Im Beispiel würde das wie folgt ablaufen: Über DgramCom trifft ein Nachrichtenobjekt ein, das die Anweisung zum Download eines Torrents enthält. Der TorrentClient verbindet sich hierauf mit dem JobServer und verlangt nach einer Aufgabe.
Nachdem der JobServer sich die Netzwerkadresse des Anfragenden beim GridManager hat verifizieren lassen, wird der Torrent übertragen. Ist der Download
abgeschlossen, beginnt automatisch BitTorrent die Nutzdaten zu laden. Der TorrentWatcher stellt nach beendetem Download den Torrentnamen in eine Queue,
welche vom ExecutionNode über getData abholt wird. Hierauf analysiert der ExecutionNode in der execute Methode die Daten auf Informationen zur Bearbeitung und führt letztere im darauf folgenden Schritt durch. Aus dem Ergebnis der
Bearbeitung wird dann ein Torrent erzeugt und dieser wieder an den JobServer
übertragen.
72
ExecutionNode
+address: tuple
+server: tuple
+stopbt: threading.Event
+myaddress: tuple
+mytserver: tuple
+mytracker: string
+firsttime: bool
+download: bool
+upload: bool
+idle: bool
+busy: bool
+datatraffic: bool
+allowshare: bool
+datdic: dict
+dcom: DgramCom
+mloop: threading.Thread
+dloop: threading.Thread
+workspace: string
+twatcher: TorrentWatcher
+send(self,msg:list,address:tuple=None)
+recv(self,msg:tuple,address:tuple)
+mainloop(self)
+startdownload(self,saveas:string)
+startupload(self,path:string)
+launchTorrents(self,start:bool=True)
+getStatus(self): char
+datafetcher(self)
+executer(self,metainfo_name)
+resetworkspace(self)
+close(self)
Auxiliary (Auszug)
DefSet
1
1
+JOBLISTEN: int = 5
TorrentClient
1
n
+connect(self,server:tuple,myaddress:tuple)
+download(self,saveas:string,myaddress:tuple,
mytserver:tuple,request:string="t")
+upload(self,path:string,myaddress:tuple,
mytserver:tuple)
TorrentWatcher
1
1
+data: list
+blacklist: list
+files: list
+mainloop(self)
+close(self)
1
1
DgramCom
ComDef
+__init__(self)
+loop: bool
+codec: ComCodec
+recv(self)
+close(self)
Abbildung 6.5: Klassendiagramm ExecutionNode
73
Die GridManager Klasse ist eine Zusammensetzung aus dem JobScheduler
und dem NodeManger, wie in Abbildung 6.6 zu sehen ist. Beide operieren auf einer gemeinsamen MainHook Instanz. Der NodeManager nimmt über eine DgramCom Instanz Nachrichten von den ExecutionNodes entgegen und verarbeitet sie.
Resultieren hieraus Antworten, so werden diese dann an das den ExecutionNode
repräsentierende Node Objekt übergeben. Beim Initialisieren der NodeManager
Klasse wird die Methode mainloop in einem extra Thread gestartet. Diese itereriert endlos über alle in der MainHook registrierten Nodes, bewertet dieselben und
schickt Nachrichten an die entsprechenden ExecutionNodes, sofern solche im Node
Objekt hinterlegt wurden.
Der JobScheduler hält die Verbindungen zu den JobServern und verwaltet deren
Aufgabenausführung. Auch der JobScheduler führt eine Methode mit dem Namen
mainloop, welche in einem eigenen Thread endlos läuft. In diesem Fall werden aber
die auszuführenden Aufgaben einer permanenten Überprüfung und Bewertung unterzogen. Hier fallen dann die Entscheidungen, wann eine Aufgabe beispielsweise
gestartet oder gestoppt werden soll.
Auxiliary (Auszug)
NodeManager
JobScheduler
DefSet
+JOBLISTEN: int = 5
+mhook: MainHook
+scom: Communication.ServerCom
+jobs: dict
+wait: int = 2
+__init__(self,mhook:MainHook)
+addJob(self,address:tuple,policy:object)
+getStatus(self)
+startJob(self,address:tuple)
+mainloop(self)
+close(self)
1
+dcom: Communication.DgramCom
+mhook: MainHook
+ltime: float = 0.3
+address: tuple
+__init__(self,msg:object,address:tuple=None)
+recv(self,msg:Object,address:tuple)
+mainloop(self)
+checkvalidity(self,node:Node)
+appendRawData(self,data:string,address:tuple)
+resetIdle(self)
+groupMessage(self,m:string)
+close(self)
1
1
GridManager
1
+js: JobServer
+nm: NodeManager
+__init__(self)
+close(self)
Abbildung 6.6: Klassendiagramm GridManager
74
6.2. Aufgabendeklaration
Die JobServer Klasse verwaltet die Verteilung der Tasks. Initial analysiert
sie das Verzeichnis der Aufgabestellung und generiert Abhängigkeitslisten aus den
Teilaufgaben. Hieraus erstellt der JobServer über maketorrentfromlist die Metadaten. Mittels eine ClientCom Instanz wird eine Verbindung zum GridManager
aufgebaut und mit Hilfe eines TorrentServers werden Verbindungen der ExecutionNodes entgegengenommen. Den Aufbau und die Abhängigkeiten der JobServer
Klasse zeigt Abbildung 6.7.
Der Algorithmus, nach dem die Aufgabenpakete verteilt werden, sieht folgendermaßen aus: Alle unbearbeiteten Tasks befinden sich in einer Queue. Soll einem
ExecutionNode ein Task zugewiesen bekommen, wird der vorderste aus der Queue
genommen, an den ExecutionNode übertragen und wieder an das Ende der Queue
gestellt. Erst wenn ein Ergebnis von einem ExecutionNode empfangen wurde, entfernt man den Tasks aus der Queue. Dies hat zur Folge, dass gegen Ende der
Jobbearbeitung Tasks erneut verteilt werden, für die der JobServer noch kein Ergebnis erhalten hat. Der Vorteil liegt darin, dass so langsame oder ausgefallene
Rechner kompensiert werden können.
6.2 Aufgabendeklaration
Ein Jobpackage ist eine für das Grid konforme Menge von beliebigen Daten. Wie
schon in Kapitel 5.3 angerissen, definiert es sich durch drei Eigenschaften:
• Identifiziert wird der Job durch das Verzeichnis im Dateisystem, in welchem
die Daten abgelegt wurde.
• Dieses Verzeichnis benötigt ein Unterverzeichnis mit dem Namen ./metadata.
• Das Verzeichnis ./metadata benötigt die Datei manifest.xml
Für einen erfolgreichen Einsatz gibt es zudem zwei Bedingungen, nämlich dass a)
der JobServer Schreibrechte auf das Jobpackage hat und dass b) alle benötigten
DefSet
Abbildung 6.7: Klassendiagramm JobServer
+data: list
+blacklist: list
+files: list
+mainloop(self)
+close(self)
TorrentWatcher
+active: dict
+done: list
+failed: list
+todo: list
+jserver: JobServer
+address: tuple
+savepath: string
+torrentpath: string
+modulid: int
+tallac: TorrentAllocator
+__init__(self,jserver:JobServer,
address:tuple=DefSet.TORRENTSERVER,
listen:int=5)
+close(self)
+prepare(self)
+mainloop(self)
+connection(self,sock:socket.socket)
TorrentServer
+JOBLISTEN: int = 5
Auxiliary (Auszug)
+manifest: string
+modul: string
1 1 +tasks: string
+torrents: string
+results: string
+tserver: tuple
+tracker: string
+manager: tuple
+exitEvent: threading.Event
+stopSeeding: threading.Event
+statEvent: threading.Event
+path: string
+ccom: ClientCom
+hook: Hook
+requests: dict
+dom: xml.dom.minidom
1 1 +modulid: string
+policy: xml.dom.minidom
+tdis: TorrentServer
+stats: Statistic
+twatcher: TorrentWatcher
+dloop: threading.Thread
+__init__(self,path:string,tracker:string,
manager:tuple,tserver:tuple)
+datafetcher(self)
+makeTorrent(self,node:string)
+progress(self,x:int)
+seedTorrents(self,start:bool=True)
1 1
+close(self)
JobServer
1
1
ClientCom
+__init__(self)
+appendRawData(self,data:string,
address:tuple): string
ComDef
+cthread: threading.Thread
+__init__(self,addresss:tuple,comdef:ComDef)
+connectSock(self)
75
76
Dateien inklusive der ausführbaren Programme und ihrer Bibliotheken innerhalb
der Ordnerstruktur liegen.
Der Aufbau der manifest.xml wird durch die metadata.dtd, siehe Abbildung 6.9,
deklariert. Sie beinhaltet unter anderem die Policy Informationen, welche Ausführungszeitraum, Prioritätslevel, Eigentümer und die Anzahl der gewünschten ExecutionNodes festlegen. Der GridManager benötigt diese Information zur Priorisierung und Konfiguration des Jobs. Des Weiteren definiert diese Konfigurationsdatei
das Modul und die Tasks des Jobs. Beide Elemente beschreiben Kommandos, welche auf den ExecutingNodes ausgeführt werden sollen, sowie die dafür benötigten
Daten. Der Unterschied besteht darin, dass das Modul an jeden ExecutingNode
übertragen wird, die Tasks aber nur an jeweils einen einzigen. Besagtes Modul
beinhaltet also die Grundvoraussetzungen, die zum Erledigen der eigentlichen Teilaufgaben, der Tasks, benötigt werden.
Für jeden Job wird eine eigene JobServer Instanz gestartet. Diese analysiert jetzt
die manifest.xml, extrahiert die Modul und Task Informationen in einzelne .xml
Dateien und legt dieselben im Ordner ./metadata ab. Nun werden für das Modul
und die Tasks eigene Torrent Dateien erstellt, welche für die jeweilige .xml Datei
und die darin beschriebenen Dateien gelten. Sie sind ebenfalls im ./metadata
Ordner abzulegen.
Abbildung 6.8 zeigt den beispielhaften Aufbau einer manifest.xml, welche eine
Policy, ein Modul und drei Tasks umfasst. Das Modul besteht in diesem Fall nur
aus einer Datei, die einen Packer repräsentieren soll. Die Tasks beinhalten je eine
.txt Datei und drei Kommandos. Kommando eins besagt, dass das Programm
welches die ID 0001 trägt, mit den Parametern des param Strings auszuführen
ist. Werden IDs im param String verwendet, so werden sie von Prozentzeichen
eingeschlossen. Im Beispiel soll der Packer also aus der jeweiligen .txt Datei im
Task ein gleichnamiges Archiv mit der zusätzlichen Endung „.rar“ erzeugen. In den
Kommandos zwei und drei wird der Parameter cmd verwendet. Für diesen sind die
Werte „result“, „copy“, „delete“ und „move“ zulässig. Erster markiert den Inhalt
von param als Resultat, welches nach erfolgter Aufgabenlösung zum JobServer zu
übertragen ist. Die restlichen Werte stellten dabei Dateisystemoperationen dar,
77
die äquivalent ihrer Bedeutung verwendet werden. Die übergebenen Parameter
stimmen mit den Pfadangaben überein, wie sie auch in den gleichbedeutenden
Konsolenkommandos gängiger Betriebssysteme zum Einsatz gelangen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?xml version=" 1 . 0 " e n c o d i n g="ISO−8859−1" ?>
< !DOCTYPE j o b SYSTEM " m e t a i n f o . dtd ">
<j o b i d=" 0001 ">
<p o l i c y p r i o r i t y l e v e l="1 " minnodeamount="1" maxnodeamount="1"
f a v o u r e d s t a r t="−1" f a v o u r e d e n d="−1" owner=" username "/>
<modul i d=" 0001 ">
<data i d=" 0001 " path=" . / r a r . exe "/>
</modul>
<t a s k i d=" 0001 " modul=" 0001 ">
<data i d=" 0002 " path=" . / a l p h a . t x t "/>
<command data=" 0001 " param="␣%0002%␣%0002%. r a r "/>
<command cmd =" d e l e t e " param="%0002%"/>
<command cmd =" r e s u l t " param="%0002%. r a r "/>
</ t a s k>
<t a s k i d=" 0002 " modul=" 0001 ">
<data i d=" 0003 " path=" . / b e t a . t x t "/>
<command cmd =" d e l e t e " param="%0003%"/>
<command cmd =" r e s u l t " param="%0003%. r a r "/>
</ t a s k>
<t a s k i d=" 0003 " modul=" 0001 ">
<data i d=" 0004 " path=" . / gamma . t x t "/>
<command cmd=" d e l e t e " param="%0004%"/>
<command cmd=" r e s u l t " param="%0004%. r a r "/>
</ t a s k>
</ j o b>
Abbildung 6.8: manifest.xml
78
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
< !ELEMENT m e t a i n f o ( j o b | modul | t a s k | r e s u l t )>
< !ELEMENT j o b
( p o l i c y , modul , t a s k +)>
< !ELEMENT p o l i c y
EMPTY>
< !ELEMENT modul
( data ∗ , command∗ )>
< !ELEMENT t a s k
( data ∗ , command∗ )>
< !ELEMENT data
EMPTY>
< !ELEMENT command EMPTY>
< !ELEMENT r e s u l t
( data +)>
< !ATTLIST j o b
i d CDATA #REQUIRED>
< !ATTLIST p o l i c y
p r i o r i t y l e v e l CDATA #REQUIRED
minnodeamount CDATA #REQUIRED
maxnodeamount CDATA #REQUIRED
f a v o u r e d s t a r t CDATA #REQUIRED
favouredend
CDATA #REQUIRED
owner
CDATA #REQUIRED>
< !ATTLIST modul
id
CDATA #REQUIRED>
< !ATTLIST t a s k
id
CDATA #REQUIRED
modul CDATA #REQUIRED>
< !ATTLIST data
id
CDATA #REQUIRED
path CDATA #REQUIRED>
< !ATTLIST command
id
CDATA #REQUIRED
data CDATA #IMPLIED
cmd
CDATA #IMPLIED
param CDATA #REQUIRED>
< !ATTLIST r e s u l t
job
CDATA #REQUIRED
t a s k CDATA #REQUIRED>
Abbildung 6.9: metainfo.dtd
6.3. Kommunikationskanäle
79
6.3 Kommunikationskanäle
Der Informationsaustausch findet über drei Kommunikationskanäle statt. Diese
sind der Steuerungs-, der Metadaten- und der Nutzdatenkanal. Die Konstellation,
in welcher die Teilnehmer miteinander in Verbindung treten, wird durch Abbildung
5.3 auf Seite 56 dargestellt.
Der Steuerungskanal dient unter den Teilnehmern zum Austausch von Informationen und Steuerbefehlen. Hierüber kommuniziert der GridManager mit den
ExecutionNodes und den JobServern. Die ExecutionNodes tauschen mit dem GridManger ihre Nachrichten über das zustandslose UDP/IP Protokoll aus. Der Grund
für diese Entscheidung liegt darin, dass bei dauerhaften TCP/IP Verbindungen jeder Node eine Socketinstanz zugewiesen bekäme. Da die Annahme gilt, dass ExecutionNodes unvorhersagbar ausfallen werden, würde dies eine permanente Fehlerbehandlung in der Nodeverwaltung mit sich ziehen. Die Alternative, dass TCP/IP
Verbindungen je Nachricht neu aufgebaut und wieder geschlossen werden könnten,
würde einen unnötigen Overhead an Netzwerkverkehr und Verwaltungsaufwand
generieren.
Hingegen basiert die Kommunikation zwischen GridManager und JobServern auf
permanenten TCP/IP Verbindungen, da hier die oben genannten Entscheidungsgründe nicht gegeben sind.
Die Kommunikation des Steuerungskanal erfolgt über Nachrichtenobjekte. Diese
werden in Python mit Hilfe des pickle Moduls serialisiert und über einen Socket
versendet. Nun rekonstruiert und verarbeitet die Empfängerseite das ursprüngliche
Objekt. Als Nachrichtenobjekt bezeichnet man eine Liste, deren erstes Element ein
Character ist, welcher zur Versionierung dient. Die folgenden Beschreibungen der
Nachrichtenobjekte beziehen sich alle auf Version 0x00.
ExecutionNode Nachrichtenobjekte werden vom ExecutionNode an den NodeManager des GridManagers gesendet. Das Objekt, welches in Tabelle 6.1 mit
80
dem Namen object bezeichnet und dessen Zusammensetzung dort dargestellt
wird, besteht aus den vier Elementen version, status, messages und infos.
Name
object
version
status
messages
infos
Definiton
List:[version, status, messages, infos]
Character
Character
List
Dictionary
Tabelle 6.1: ExecutionNode Nachrichtenobjekt
Der Character status stellt eine Zusammenschluss von binären Zuständen dar,
welche durch ihre Bitstelle im Characterbyte in der Bedeutung definiert werden.
Interpretiert wir der Wert mit 1 für ja und 0 für nein. Die Bezeichnung und ihre
Bedeutung sind der Tabelle 6.3 zu entnehmen. Anhand dieser Zustände und der
Zeitdauer, wie lange ein Node in diesem Zustand verweilt, entscheidet der GridManager über die Verwendung desselben. Das message Objekt ist eine Liste, die
als Container der in der Klasse DefSet.Messages festgelegten Definitionen dient.
Mittels dieser kann der Node beispielsweise Anfragen über die Adresse des ihm zugewiesenen JobServers stellen. infos instanziert ein Dictionary, das die Aufgabe
hat, Anfragen mit einem variablen Anteil zu versenden. In der aktuellen Version
wird dies noch nicht benötigt.
Name
object
version
messages
infos
Definiton
List:[version, messages, infos]
Character
List
Dictionary
Tabelle 6.2: NodeManager Nachrichtenobjekt
NodeManager Nachrichtenobjekte heißen die Narichten, welche vom NodeManager an die ExecutionNodes versendet werden. Wie man Tabelle 6.2 entnehmen kann, haben diese denselben Aufbau wie die ExecutionNode Nachrichtenobjekte, allerdings mit dem Unterschied, dass kein Statusbyte vorhanden ist.
Bitstelle
8
7
6
5
4
3
2
1
Bezeichnung
FREE
FREE
DOWNLOAD
UPLOAD
IDLE
BUSY
DATATRAFFIC
ALLOWSHARE
81
Erklärung
nicht verwendet
nicht verwendet
ist der EN Daten am laden?
ist der EN Daten am hochladen?
ist der EN frei oder am rechnen?
wird der EN vom Anwender verwendet?
ist ein Datentransfer zur Zeit erlaubt?
darf EN Daten mit anderen ENs Teilen?
Tabelle 6.3: Statusbyte der ExecutionNodes
JobServer Nachrichtenobjekte werden an den JobScheduler gesendet. Sie
enthalten, wie Tabelle 6.4 entnommen werden kann, die Variablen type und content. type definiert mit seinem Wert den zu erwartenden Inhalt von content. Der zu
der ExecutionNode und dem NodeManager beschriebene Aufbau der Nachrichtenobjekte resultiert aus der Tatsache, dass beim JobServer und beim JobScheduler
die Nachrichten direkt versendet und nicht, wie im Fall der ExecutionNodes und
des NodeManagers, vorerst gesammelt werden. Daher ist eine einfachere Struktur
der Nachrichten möglich.
Name
object
version
type
content
Definiton
List:[version, type, content]
Character
Integer
von type Abhängig
Tabelle 6.4: JobServer/JobScheduler Nachrichtenobjekt
JobScheduler Nachrichtenobjekte gleichen sich im Aufbau mit denen der
JobServer.
Welche Kommandos von den jeweiligen Nachrichtenobjekten in der aktuellen Version unterstützt werden und was diese bedeuten, zeigt Tabelle 6.5.
82
Variable Werte
Bedeutung
ExecutionNode Nachrichtenobjekt
messages WHATSMYADDRESS Anfrage nach eigener IP Adresse
um NATs zu erkennen.
WHATSMYTRACKER Adresse des Trackers erfragen.
WHATSMYTSERVER Adresse des TorrentServers erfragen.
NodeManager Nachrichtenobjekt
messages GETTORRENT
Aufforderung zum Laden einer
Aufgabe.
RESETWORKSPACE
Aufforderung in den Grundzustand zu kehren.
infos
WHATSMYADDRESS
Antwort auf Anfrage. Enthält
Adresstuple.
WHATSMYTRACKER Antwort auf Anfrage. Enthält
Adresstuple.
WHATSMYTSERVER Antwort auf Anfrage. Enthält
Adresstuple
MESSAGE
Textnachricht an den Node.
JobServer Nachrichtenobjekt
type
INIT
Initialisierung. Enthält die Policy.
EXIT
Aufforderung Job zu beenden.
REQUEST
Identifikations- und Authorisierungsanfrage. Enthält Adresstuple eines Nodes.
ALLOWDIS
Aufgabenzuweisung der Nodes erlauben.
DENYDIS
Aufgabenzuweisung der Nodes
verbieten.
JobScheduler Nachrichtenobjekt
type
ALLOWED
Positive Antwort auf REQUEST.
Enthält Addresstuple
Tabelle 6.5: Wertebereich Nachrichtenobjekte
83
Der Metadatenkanal dient zur Übertragung der .torrent Dateien zwischen
den ExecutionNodes und den JobServern. Dieser Kanal verwendet das TCP/IP
Protokoll und baut nicht auf dem Communication Package auf. Initiator der einer
Verbindung ist immer der ExecutionNode. Entweder er erhält vom GridManager
die Anweisung, sich eine .torrent Datei vom JobServer abzuholen oder er beendet
eine Aufgabe und möchte die Metadaten seines Resultates zum JobServer schicken.
Nach dem Verbindungsaufbau überträgt der ExecutionNode einen String seines
mit pickle serialisiertes Adresstuples, welchen er vom GridManager zugewiesen
bekommen hat. Als Prefix vor diesem String steht die Länge des Strings in ASCII Zahlen zur Basis zehn, gefolgt von einem Doppelpunkt. Im Beispiel würde das
Adresstuple ("11.11.0.11",1234) mit "26:(S’11.11.0.11’\nI1234\ntp1\n."
übertragen werden. Dabei sagt die Zahl 26 dem JobScheduler, wieviele Byte für die
Adresse einzulesen sind, wobei der Doppelpunkt das Ende der Zahl markiert. Der
JobServer schickt ein Nachrichtenobjekt mit einem REQUEST und der Adresse
als Wert an den GridManager, um den ExecutionNode verifizieren zu lassen. Die
Tatsache, dass der JobScheduler nicht die Adresse der eingehenden Verbindung
zur Verifizierung verwendet, hat zwei Gründe: erstens sollen so Adressveränderungen durch Proxyserver und NATs umgangen werden, und zweitens ist somit eine
spätere Umstellung auf andere Identifikationswerte, wie zum Beispiel eindeutige,
zufällig generierte Zeichenketten problemlos möglich.
Nach erfolgter Verifizierung empfängt der JobServer ein weiteres Byte, um den
Grund der Verbindung zu erfahren. Dieses Byte repräsentiert ein Zeichen der
ASCII Tabelle. Entspricht besagtes Byte einem „u“ hat der ExecutionNode eine Metadatei zum Hochladen, und bei einem „d“ soll ein Torrent vom JobServer
heruntergeladen werden. Im zweiten Fall muss noch ein Byte übertragen werden.
Ist dieses ein „m“, so fordert der ExecutionNode das Modul; bei einem „t“ soll ein
Task übertragen werden. Hiernach steht wieder eine Zahl, gefolgt von einem Doppelpunkt, welche der Größe der Metadatei in Bytes entspricht. Schließend wird die
Torrentdatei übertragen.
84
6.4. Benutzerschnittstellen
Der Nutzdatenkanal verteilt die in den Torrents referenzierten Daten. Implementiert wird dies durch das BitTorrent Protokoll, welches in Kapitel 4.3 vollständig beschrieben ist.
6.4 Benutzerschnittstellen
Das System stellt dem Benutzer für die drei Anwendungen ExecutionNode, JobServer und GridManager je eine Konsole zur Steuerung bereit. Diese Systemschnittstellen erlauben den Zugriff auf die grundlegenden Fähigkeiten zur Verwaltung und
Manipulation der verbundenen Anwendungsinstanz.
Im Folgenden wird der Gebrauch der drei Schnittstellen erläutert. Hierfür werden im Sinne einer verständlichen Erklärung zuvor beispielhafte Konfigurationsbedingungen festgelegt. Es gelten nachstehende Bedingungen: Von jeder Anwendung wird nur eine Instanz gestartet. Unter der URL http://10.10.11.68:6969/
announce steht ein BitTorrent Tracker zur Verfügung. Der ExecutionNode wird
auf einem Rechner mit der IP Adresse 10.10.11.69 gestartet. Der GridManager soll
unter der IP Adresse 10.10.11.68 initiiert werden, wobei der NodeManager unter
Port 6669 und der JobScheduler unter dem Port 6670 erreicht wird. Der JobServer
erhält einen Rechner mit der IP Adresse 10.10.11.67. Dabei soll der TorrentServer
unter dem Port 6671 laufen. Der JobServer findet seine JobPackage unter dem
Pfad /home/griduser/renderjob.
Der ExecutionNode ist über das nachstehende Kommando zu starten:
python ExecutionNode.py -manager 10.10.11.68:6669
Der Wert des Parameters -manager gibt die Adresse des NodeManagers vom GridManager an. Alle Nachrichtenobjekte werden vom ExecutionNode an diese Netzadresse geschickt. Nach dem Start steht dem Benutzer eine Eingabeaufforderung
85
mit dem Prompt ExecutionNode > zur Verfügung. Tabelle 6.6 zeigt eine Übersicht
aller zugelassener Befehle.
Befehl
help
status
debug
reset
exit
Definiton
Listet alle Befehle mit kurzer Erklärung auf.
Listet alle Statuswerte auf.
Sprung zu einem definierten Breakpoint. Nur
für den Debugmodus der Entwicklungsumgebung.
Stellt den ExecutionNode auf den Ursprungszustand zurück und löscht alle geladenen und errechneten Daten.
Beendet das Programm.
Tabelle 6.6: ExecutionNode Befehle
Der JobServer wird mit vier Parametern initiiert. Hiervon nennt -job den
Pfad zum JobPackage. Die Festlegung des Trackers erfolgt mit dem Parameter
-tracker. -manager gibt die Adresse des JobSchedulers vom GridManager an.
Der -tserver benennt die lokale Adresse, an die der TorrentServer gebunden werden soll. Nach Ausführung des nachstehenden Befehls erhält der Anwender eine
Kommandozeile mit dem Prompt JobServer >.Tabelle 6.7 zeigt eine Übersicht
aller zugelassener Befehle.
python JobServer.py -job /home/griduser/renderjob
-tracker http://10.10.11.68:6969/announce
-manager 10.10.11.68:6670
-tserver 10.10.11.67:6671
Befehl
help
status
exit
Definiton
Gibt Prozentual die Fertigstellung des Jobs
und die benötigte Zeit aus.
Beendet den JobServer.
Tabelle 6.7: JobServer Befehle
86
Der GridManager wird ohne weitere Parameter über den folgenden Befehl
ausgeführt:
python GridManager.py
Somit hat der Benutzer eine Kommandozeile mit dem Prompt GridManager > auf
seinem Schirm. Tabelle 6.8 zeigt eine Übersicht aller zugelassener Befehle.
Befehl
help
status
start
kill
newidle
msg
restart
exit
Definiton
Listet Informationen über Menge und Zustand der registrierten Gridteilnehmer.
Benötigt JobServer-Adresse IP:PORT als
Prameter. Startet den Job.
Benötigt JobServer-Adresse IP:PORT als
Prameter. Beendet den Job.
Anweisung an alle freien ExecutionNodes
sich in den Grundzustand zurückzusetzen.
Benötigt einen String als Parameter. Versendet diesen als Gruppennachricht an alle ExecutionNodes.
Startet den GridManager neu.
Beendet den GridManager.
Tabelle 6.8: GridManager Befehle
87
7 Testszenario
Als Testplattform für die ExecutionNodes standen mehrere Rechner mit größtenteils homogenen Leistungsfaktoren zur Verfügung, welche über ein Fast Ethernet
Netzwerk miteinander verbunden waren. Eine Spezifikation der einzelnen Computer ist Tabelle 7.1 zu entnehmen. Der GridManager und die JobServer wurden
auf einem Ubuntu Linux Rechner ausgeführt. Auf diesem Rechner befand sich zudem ein Subversion Repository, über welches die Testrechner via WebDAV ihre
ExecutionNode-Versionen aktualisierten.
Name
PC1
PC2
PC3
PC4
PC5
PC6
PC7
PC8
CPU
Pentium 4
Pentium 4
Pentium 2
Pentium 4
Pentium 4
Pentium 4
Pentium 4
Pentium 4
Taktfrequenz
3.0 GHz
3.0 GHz
350 MHz
2.4 GHz
3.0 GHz
3.0 GHz
2.0 GHz
3.0 GHz
Arbeitsspeicher
512 MB
1024 MB
128 MB
512 MB
512 MB
512 MB
512 MB
512 MB
Tabelle 7.1: Testrechner
Das Testszenario sah wie folgt aus: Mit der freien 3D Modellierungssoftware Blender1 entstand eine aus zehn Bildern bestehende Animationssequenz. Deren Einzelbilder wurden dann als XML Dateien exportiert und sodann mit der freien
Software 7-Zip2 komprimiert. Die Aufgabe der ExecutionNodes bestand darin, die
7a-Archive herunterzuladen und nach deren Dekompression aus den XML-Dateien
1
2
http://www.blender3d.org/
http://www.7-zip.org/
88
mittels des Open Source Renderes YafRAY3 die Bilder zu berechnen. Danach galt
es, diese Resultate als komprimiertes Archiv dem Auftraggeber zu übertragen.
Hierzu beschrieb die manifest.xml Datei 7-Zip und YafRay als Modul und die
einzelnen Archive als Tasks. Zur Veranschaulichung zeigt Abbildung 7.4 einen Ausschnitt der manifest.xml. Dieses 10 Bilder JobPackage diente dann als Basis für
abgewandelte JobPackges, welche aus 5, 25, 50, 75 und 100 Aufgaben bestanden.
Abbildung 7.1 zeigt das von YafRay generierte Bild 10 der Animation.
Abbildung 7.1: Gerendertes Bild, Auflösung: 1024x768
Das Programm YafRay ist ein Raytracer. Mit Raytracing bezeichnet man ein Verfahren zur Bildsynthese aus einer 3D Szenerie. Hierzu werden vom Auge des Betrachters Strahlen in die Szene gesandt und so die Sichtbarkeit, beziehungsweise
die Verdeckung von Objekten ermittelt. Über dieses Verfahren ist eine globale
3
http://www.yafray.org/
7.1. Test 1: Verteilung
89
Beleuchtung der 3D Objekte möglich. Während in lokalen Beleuchtungsmodellen
nur die Reflektion zwischen zuvor definierten Lichtquellen und einer Oberfläche
simuliert werden, ist es die Aufgabe der globalen Beleuchtungsmodelle, alle in
der Szene befindlichen Objekte in die Berechnung eines Bildpunktes mit einzubeziehen. So wird zum Beispiel das reflektierende Licht eines Objekts für die Berechnung eines benachbarten Objekts mit berücksichtigt. Über Erweiterungen der
klassischen Raytracing-Algorithmen ist es unter anderem möglich Schattenwurf,
Lichtbrechung, Reflektion und Kaustik einer 3D Szene zu simulieren. Durch die
Tatsache, dass Raytracing eine mit zunehmender Komplexität der Szenerie und
steigender Auflösung der zu erstellenden Bilder sehr zeitaufwändige Aufgabe sein
kann, und alle Bilder einer Szene parallel erstellt werden können, ist Raytracing
ein ideales Anwendungsgebiet für das implementierte Grid.
Die Laufzeit tp eines JobServers resultiert aus einem Zusammenhang mit der Anzahl der ExecutionNodes m, der Anzahl der Tasks n, der mittleren Ausführungszeit
tm pro Aufgabe und der Zeitbedarf ti zur Initialisierung des JobServers. Der Wert
von tm ist die Summe der eigentlichen Rechenzeit des ExecutionNodes und des
im Grid betriebenen Mehraufwands für einen Task. Letzterer umfasst den Verwaltungsaufwand zur Zuordnung und Verteilung der Aufgaben, vor allem aber die
Datenübertragung zu den ExecutionNodes und die Übergabe der Resultate an den
JobServer. Die durchschnittliche Anzahl an Berechnungen, die auf einem ExecutionNode ausgeführt werden, bildet der Quotient von der Taskmenge n und der
ExecutionNodes m. Die Formel 7.1 stellt diesen Zusammenhang dar.
tp = tm ·
n
+ ti
m
(7.1)
7.1 Test 1: Verteilung
In diesem Versuch wurde die Verteilung der Aufgabenpakete untersucht. Anhand
der ermittelten Werte ließ sich eine Schwachstelle im Verteilungsalgorithmus ausmachen und verbessern.
90
7.2. Test 2: Aufwandssteigerung
Der Test bestand aus der Berechnung von zehn Bildern, die zuerst auf einem
Rechner (PC1), dann auf vier (PC1, PC4, PC5, PC7) und anschließend auf fünf
(PC1, PC3, PC4, PC5, PC7) erfolgte. Als Ergebnis wurde die Ausführungsdauer
des JobServers gemessen. Tabelle 7.2 zeigt die Ergebnisse. Man erkennt, dass die
Ausführungszeit mit der Versuchnummer 3 mit fünf Rechnern deutlich länger war,
als die der Versuchnummer 2 mit vier Rechnern. Zu erklären ist dies damit, dass
in Versuch 3 der Rechner PC3 hinzukam. Die Ausführungszeit des JobServers
erhöhte sich durch die relativ geringe Leistung des Rechners, da dieser auf das
Ergebnis von PC3 warten musste. Die Konsequenz dieser Messung bestand in der
Überarbeitung des Verteilungsalgorithmus. So werden jetzt nach der Verteilung
aller Tasks an die ExecutionNodes freie Computer mit der Berechnung von bereits
verteilten Aufgaben beauftragt, die sich noch in der Bearbeitung befinden. Der
erste Rechner, der eine solch mehrfach verteilte Aufgabe fertig stellt, darf diese
dann an den JobServer übertragen. So können leistungsschwache Rechner gegen
Ende der Laufzeit kompensiert werden. Versuch Nummer 4 entstand nach der
Überarbeitung des entsprechenden Algorithmus. Deutlich erkennt man die nun
kürzere Laufzeit.
7.2 Test 2: Aufwandssteigerung
Dieser Versuch untersuchte die Laufzeiten der JobServer bei unterschiedlichen
Mengen von Teilaufgaben und einer konstanten Anzahl von ExecutionNodes. Als
Ergebnis war ein annährend linearer Anstieg der Laufzeit bei zunehmender Aufgabenmenge festzustellen. Danach brachte eine Regessionsanalyse die Messdaten in
einen gemeinsamen Bezug. Tabelle 7.3 zeigt die Resultate der Messungen, welche
in Abbildung 7.2 graphisch dargestellt sind. Alle Jobs wurden dreimal wiederholt,
Versuch Nr.
Teilnehmer
Zeit [mm:ss]
1
1
08:17
2
4
02:56
3
5
4:04
Tabelle 7.2: Scheduler update
4
4
03:16
91
die Ergebnisse gemittelt und jeweils die mittlere Abweichung berechnet.
Teilnehmer
Summe Tasks
Messungen
[mm:ss]
Mittelwert
mittl. Abw.
PC1, PC3, PC4, PC5, PC7
5
10
25
50
01:42 03:16 07:07 13:28
01:43 03:17 07:09 13:30
01:40 02:36 07:04 13:25
01:42 03:03 07:07 13:28
00:01 00:18 00:02 00:02
75
21:30
21:02
18:14
20:15
01:21
100
26:07
26:15
26:03
26:08
00:04
Tabelle 7.3: Aufwand zur Zeit bei gleicher Kapazität
Zur Untersuchung der erhobenen Messdaten stand sodann die Durchführung einer
linearen Korrelations- und Regressionsanalyse an, da ein linearer Zusammenhang
zu vermuten war. Anhand dieser Methoden kann man nämlich den funktionalen
Zusammenhang von Messdaten in Bezug auf ihre Koordinaten x und y bewerten.
Der Korrelationskoeffizient r gibt hierbei die Wahrscheinlichkeit eines Funktionalen
Zusammenhangs wieder. Der Wertebereich geht über −1 ≤ r ≤ 1. Ist |r| gleich 1,
so besteht ein funktionaler Zusammenhang. Nähert dieser Wert sich 1, so wird der
Zusammenhang wahrscheinlicher. Bei 0 besteht kein Zusammenhang. Die lineare
Regressionsgleichung berechnet die angenäherten Werte für die Steigung a und den
Schnittpunkt der y-Achse b der Geradegleichung y = ax + b. Einen Einstieg in die
Thematik bietet [Huber, 2006]. Formel 7.2 zeigt die Gleichung von r, Formel 7.3
und 7.4 beschreiben die Berechnung von a und b.
P
P
xy − n1 ( x) ( y)
r=q P
P P 2 1 P 2
y − n ( y)
x2 − n1 ( x)2
P
a=
P
b=
P
xy − (
P 2
x −
P
P
x)( y)
n
P
( x)2
n
(7.2)
y−b
n
P
x
(7.3)
(7.4)
Die Anwendung dieser Formeln auf die gemittelten Werte brachte nun folgendes
92
Ergebnis. Der Korrelationskoeffizient r ist gleich 0,99 und sagt somit eine sehr
hohe Wahrscheinlichkeit eines funktionalen Zusammenhangs aus. Die Steigung a
beträgt 15,52 und der y-Achsenschnittpunkt b ist gleich 31,7.
Abbildung 7.2: Laufzeit bei variabler Menge von Task
Die hieraus resultierende Gerade ist gleich der oben beschriebenen Formel 7.1.
Folglich konnten mit ihrer Hilfe die mittlere Ausführungsdauer tm und der Initialisierungsaufwand ti ermittelt werden. Diesen Zusammenhang zeigt Gleichungsfolge
7.5 bis 7.10.
f (n) = an + b
(7.5)
f (n) = 15, 52n + 31, 7
n
tp = tm ·
+ ti
m
tp = f (n)
(7.6)
tm = a · m = 15, 52 · 5 = 77, 6
(7.7)
(7.8)
(7.9)
7.3. Test 3: Leistungssteigerung
93
ti = b = 31, 7
(7.10)
Die Dauer von tm betrug also gleich 77,6 Sekunden und die von ti war gleich
31,7 Sekunden. Die Gleichsetzung mit der Geradengleichung bot sich deshalb an,
weil m für diesen Test konstant blieb und die Gleichung 7.1 daher ebenfalls eine
Gerade beschrieb. Abbildung 7.2 stellt die Messwerte und den Verlauf der Geraden
f graphisch dar.
7.3 Test 3: Leistungssteigerung
Der Test bezweckte die Analyse des Systemverhaltens bei einer unterschiedlichen
Anzahl von ExecutionNodes. Zur Messung diente jeweils ein JobServer mit dem
gleichen, 50 Tasks beinhaltenden JobPackage. Für jeden Test wurde ein Rechner
aus Tabelle 7.1 hinzugeschaltet. Eine Ausnahme war hierbei PC3. Dieser blieb
ungenutzt, um ein möglichst homogenes Rechnernetz zu erhalten. Die Ergebnisse zeigt Tabelle 7.4, welche in Abbildung 7.3 visualisiert sind. Mit zunehmender
Rechnerzahl nähert sich die Funktion in Form einer Hyperbel einem Grenzwert
an. Letzterer ist dann erreicht, wenn m = n ist, also wenn jeder Rechner nur eine Aufgabe zugewiesen bekommt. Der besagte Grenzwert und damit die kürzeste
Rechenzeit liegt dann bei theoretischen tm + ti . Aus dieser Beobachtung heraus resultierte die Feststellung, dass die Steigung der Hyperbel ein Maß der Wirksamkeit
des Systems ist. Anhand der ersten Ableitung der Hyperbelfunktion kann somit die
benötigte Rechneranzahl für eine gewünschte Funktionssteigung ermittelt werden.
Teilnehmer
Messungen
[mm:ss]
Mittelwert
mittl. Abw.
1
59:47
62:15
61:01
01:14
2
28:36
30:18
29:27
00:51
3
19:27
18:57
19:17
00:20
4
15:11
15:38
15:24
00:14
5
13:28
13:02
13:15
00:13
6
11:34
11:23
11:28
00:05
7
10:08
10:20
10:14
00:06
Tabelle 7.4: Leistung zur Zeit bei gleichem Aufwand
Da man bereits wegen der Messdaten einen hyperbelartigen Abfall vermuten konn-
94
7.3. Test 3: Leistungssteigerung
te, und die Gleichung 7.1 bei konstanter Aufgabenanzahl n und variabler Rechneranzahl m eben einen solchen Verlauf beschreibt, konnte aufgrund der Messwerte
die mittlere Laufzeit tm und der Initialisierungsaufwand ti berechnet werden. Zu
diesem Zweck wurde die Gleichung nach ti aufgelöst, für ti die gegenüberliegende
Seite der Gleichung eingesetzt und nach tm aufgelöst. Dies ermöglicht mit Hilfe
zweier Messpunkte eine Bestimmung von ti und tm . Gleichungsfolge 7.11 bis 7.14
veranschaulicht dies.
tp1 − tm1
n
+ ti
m
n
= tp − tm
m
n2
= tp2 − tm2
m2
tp2 − tp1
= n1
n2
−m
m1
2
tp = tm ·
(7.11)
ti
(7.12)
n1
m1
tm
(7.13)
(7.14)
Mit Hilfe dieser Gleichungen wurde für jede mögliche Zweierkombination der Messwerte tm und ti berechnet und sodann die Ergebnisse gemittelt. Diese ergaben für
tm = 64, 38 Sekunden und für ti = 124, 61 Sekunden. Die Funktion g in Abbildung
7.3 stellt Gleichung 7.1 mit diesen Werten und n = 50 dar. Deutlich sieht man die
enge Nachbarschaft zu den Messpunkten.
Wie die Grafik verdeutlicht, nimmt die Effektivität des Systems, also die negative
Steigung der Hyperbel, mit jedem hinzugefügten Rechner ab. Für einen ressourcenschonenden Umgang mit den ExecutionNodes kann es daher sinnvoll sein, die
Steigung der Hyperbel einen definierten Wert nicht überschreiten zu lassen, also
dem Job eine optimierte Menge von Nodes zuzuweisen. Um diese optimale Menge
an ExecutionNodes zu errechnen, ermittelt man die Steigung der Hyperbelfunktion
anhand der ersten Ableitung. Durch die Umformung nach m kann so die benötigte Menge von Rechnern für die Steigung t0p ermessen werden. Die Funktionsreihe
7.15 bis 7.17 stellt diese Umformung dar. In Abbildung 7.3 zeigt Funktion g 0 die
Ableitung von g.
7.4. Beurteilung und Fehleranalyse
n
+ ti
m
tm n
g 0 (m) = t0p = − 2
m
s
tm n
m =
− 0
tp
g(m) = t0p = tm ·
95
(7.15)
(7.16)
(7.17)
Abbildung 7.3: Laufzeit bei variabler Menge von ExecutionNodes
7.4 Beurteilung und Fehleranalyse
Das System ist so konzipiert, dass mit ihm eine große Menge von eventuell mehreren tausend Rechnern verwaltet werden können, die über verhältnismäßig schmale
Bandbreiten miteinander vernetzt sind.
96
Aufgrund der für diese Diplomarbeit zur Verfügung stehenden Ressourcen entsprach das verwendete Rechnernetzwerk allerdings weder in der Quantität der
Rechner noch in der Qualität des Netzwerks den geplanten Kriterien. Die hier
geschilderten Untersuchungen sind somit nicht direkt auf das vorgesehene Anwendungsgebiet zu übertragen. Allerdings geben sie bereits wichtige Informationen
über das Zusammenspiel des Job-Aufwands in Relation zur Rechneranzahl, Ausführungsdauer und Effektivität.
Die Rechner im Testnetzwerk waren auch nicht absolut gleichwertig. Sie unterschieden sich teilweise in der Taktfrequenz sowie in der Größe des Arbeitsspeichers. Hinzu kam, dass die hierfür benutzten Computer Work- und Teststations
der Mitarbeiter der Firma Goober waren, die während der laufenden Tests ihre
Rechner weiter verwendeten und somit einen unbekannten Störfaktor in das System einbrachten.
Bei den Tests fiel auf, dass es zum teilweisen Ausfall des Nutzdatenkanals bei der
Ausführung von Jobs mit über 150 Tasks kam. Trotz der korrekten Übertragung
der Metadaten wurden die in ihnen beschriebenen Daten nicht übertragen, weil
die Anzahl der parallel zur Verfügung gestellten Metadaten eines BitTorrent Peers
einem Limit unterstellt waren.
Die Ursache hierfür konnte nicht genau lokalisiert werden. Der BitTorrent Quellcode wies diesbezüglich keine Beschränkung auf. BitTorrent verwendet für jede
Torrentdatei einen eigenen Python-Thread. Die Vermutung, dass die Anzahl der
Threads somit auf eine in Python definierte Beschränkung stieß, konnte nicht bestätigt werden, weil sonst der TorrentServer auch keine weiteren Verbindungen
hätte entgegen nehmen können, da diese ebenfalls in einem Thread starteten. Ein
möglicher Lösungsansatz wäre, die Torrents in Queues zu verwalten und nur die
aktuell benötigten Metadateien an BitTorrent weiterzureichen. Dies sollte dann
zudem unnötige Systembelastungen durch wartende Nutzdatenübertragungen verringern.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
97
< !DOCTYPE j o b SYSTEM " m e t a i n f o . dtd ">
<j o b i d=" 0001 ">
<p o l i c y modulid=" 1" p r i o r i t y l e v e l="1" minnodeamount="5"
maxnodeamount=" 5" f a v o u r e d s t a r t="−1" f a v o u r e d e n d="−1"
owner=" t e s t u s e r " />
<modul i d= ’ 1 ’>
<data i d= ’ 1−2 ’ path= ’ . / 7 za /7 za . exe ’ />
<data i d= ’ 1−25 ’ path= ’ . / y a f r a y / y a f r a y . exe ’ />
<data i d= ’ 1−26 ’ path= ’ . / y a f r a y / y a f r a y . i c o ’ />
<data i d= ’ 1−27 ’ path= ’ . / y a f r a y / y a f r a y c o r e . d l l ’ />
<data i d= ’ 1−28 ’ path= ’ . / y a f r a y / y a f r a y p l u g i n . d l l ’ />
...
</modul>
<t a s k i d= ’ 0 ’ modul= ’ 1 ’>
<data i d= ’ 1−29 ’ path= ’ a n i 0 . 7 z ’ />
<data i d= ’ 1−3 ’ path= ’ sky . j p g ’ />
<command i d= ’ 0001 ’ data= ’ 1−2 ’ param= ’ x␣−y␣{1−29} ’ />
<command i d= ’ 0003 ’ data= ’ 1−25 ’ param= ’−p␣ . / y a f r a y ␣ a n i 0 1 0 . xml
’ />
<command i d= ’ 0004 ’ data= ’ 1−2 ’ param= ’ a␣ result_0_ {1−29}␣
a n i 0 1 0 . t g a ’ />
<command i d= ’ 0005 ’ cmd= ’ d e l e t e ’ param= ’ a n i 0 1 0 . t g a ’ />
<command i d= ’ 0006 ’ cmd= ’ d e l e t e ’ param= ’ a n i 0 1 0 . xml ’ />
<command i d= ’ 0007 ’ cmd= ’ r e s u l t ’ param= ’ result_0_ {1−29} ’ />
</ t a s k>
...
</ j o b>
Abbildung 7.4: Testszenario manifest.xml
98
8 Fazit und Ausblick
Der erste Teil der Arbeit diente dem Verschaffen eines kritischen Überblicks über
den aktuellen Stand der Grid- und P2P-Technologien. Die hieraus gewonnenen
Erkenntnisse flossen in die Konzeption des im Rahmen dieser Diplomarbeit konstruierten Systems ein. Dieses befähigt einen Netzwerkverbund von Computern
zur gemeinsamen Berechnung von parallelisierbaren Aufgaben beliebiger Natur.
Dabei ist die benötigte Software, welche zur Lösung spezieller Aufgaben gebraucht
wird, unabhängig von diesem System und kann gleich der Software sein, wie sie
auch zur seriellen Bearbeitung auf einem einzelnen Rechner verwendet wird.
Nach erfolgter Implementierung des Systems wurden anhand eines Testszenarios
mit verschieden parametrisierten Aufgaben die Lauffähigkeit und das Verhalten
des Grids untersucht. Unter Verwendung der hieraus gesammelten Daten konnten
Formulierungen zur Prognostizierung und Optimierung der Laufzeiten von Aufgabenpaketen erstellt werden.
Der zeitliche Rahmen einer Diplomarbeit steckte die Grenzen für die hier entwickelte Software. Im Folgenden soll noch ein Ausblick auf mögliche Erweiterungen
des Systems gegeben werden.
JobServer erlauben, nur parallelisierbare Aufgaben zu einem Job zusammenzuschließen. Sinnvoll wäre hier eine Erweitung zur Einbindung sequentieller, von einander abhängiger Arbeitsschritte. Hierzu müssten die auf den JobServer geladenen
Resultate Auslöser zur Generierung neuer Teilaufgaben werden. Die Einsatzmöglichkeiten des Grids würden somit stark erweitert.
99
Weitere Vorteile kann die Umstellung des Metadatenkanals auf Web Service Technologien bringen. Diese haben weniger Probleme bei der Überwindung von NATs
und Firewalls und sind auch im Bedarfsfalle leichterer auszubauen.
Das Thema Sicherheit bietet ausgiebig Potential für notwendige Erweitungen, um
einen erfolgreichen Einsatz außerhalb eines Testlabors zu ermöglichen. So wäre zum
einen die komplette Datenübertragung zu verschlüsseln. Zum anderen müssten Resultate auf ihre Authenzität geprüft werden. Ein Ansatz wäre hier beispielsweise
die Mehrfachberechnung von Aufgaben. Des Weiteren stellen die Module, welche
auf den ExecutionNodes ausgeführt werden, ein nicht zu vernachlässigendes Sicherheitsrisiko dar. Möglich wäre hier eine Zertifikation durch eine Trustcenter Instanz.
Nur zertifizierte Module würden dann auf den ExecutionNodes ausgeführt.
100
Literatur
[Barth und Schüll 2006]
Barth, Thomas ; Schüll, Anke: Grid Computing. Konzepte, Technologien, Anwendungen. 1. Vieweg, März 2006. – ISBN
3834800333
[Berstis 2002] Berstis, Viktors: Fundamentals of Grid Computing. IBM Redbook. November 2002. – URL http://www.redbooks.ibm.com/redpapers/
pdfs/redp3613.pdf
[Boyvat 2005] Boyvat, Baris: Kenosis: A P2P RPC system using the Kademlia
DHT / Telecommunications Software and Multimedia Laboratory. April 2005.
– Forschungsbericht
[Chervenak u. a. 2001] Chervenak, Ann ; Foster, Ian ; Kesselman, Carl ;
Salisbury, Charles ; Tuecke, Steven: The Data Grid:Towards an Architecture
for the Distributed Management and Analysis of Large Scientic Datasets. In:
Journal of Network and Computer Applications 23 (2001), Nr. 3, S. 187–200. –
URL http://www.globus.org/alliance/publications/papers/JNCApaper.
pdf
[Condor 2006] Condor: Condor Version 6.8.1 Manual. University of WisconsinMadison (Veranst.), September 2006. – URL http://www.cs.wisc.edu/
condor/manual/v6.8.1/condor-V6_8_1-Manual.pdf
[Ding u. a. 2003] Ding, Choon H. ; Nutanong, Sarana ; Buyya, Rajkumar:
P2P Networks for Content Sharing / Department of Computer Science and
Software Engineering. Dezember 2003. – Forschungsbericht
101
[Eastlake und Jones 2001] Eastlake, D. ; Jones, P.: US Secure Hash Algorithm
1 (SHA1). Internet Engineering Task Force: RFC 3174. September 2001. – URL
http://www.ietf.org/rfc/rfc3174.txt
[EGA 2004]
EGA:
Neue Allianz treibt Einführung von Grid Computing in Unternehmen voran. Enterprise Grid Alliance: Pressemitteilung.
April 2004. – URL http://www.gridalliance.org/en/news/PressReleases/
DE-Enterprise_Grid_Alliance9.pdf
[Feng u. a. 2005] Feng, Jun ; Cui, Lingling ; Wasson, Glenn ; Humphrey, Marty: Toward Seamless Grid Data Access: Design and Implementation of GridFTP
on .NET. URL http://www.cs.virginia.edu/~humphrey/papers/GridFTP_
on_dotNET.pdf, November 2005. – Forschungsbericht
[Fielding u. a. 1999] Fielding, R. ; Gettys, J. ; Mogul, J. ; Frystyk, H. ;
Masinter, L. ; Leach, P. ; Berners-Lee, T.: Hypertext Transfer Protocol:
HTTP/1.1. Internet Engineering Task Force: RFC 2616. June 1999. – URL
http://www.ietf.org/rfc/rfc2616.txt
[Foster und Iamnitchi 2003] Foster, I. ; Iamnitchi, A.: On Death, Taxes, and
the Convergence of Peer-to-Peer and Grid Computing. In: 2nd International
Workshop on Peer-to-Peer Systems (IPTPS’03). Berkeley, CA, Februar 2003
[Foster 2002] Foster, Ian: What is the Grid? A Three Point Checklist. In: Grid
Today 1 (2002), Juli, Nr. 6. – URL http://www-fp.mcs.anl.gov/~foster/
Articles/WhatIsTheGrid.pdf
[Foster und Kesselman 2003] Foster, Ian ; Kesselman, Carl: The Grid. Blueprint for a New Computing Infrastructure. 2. Morgan Kaufmann Publishers,
November 2003. – ISBN 1558609334
[Foster u. a. 2002] Foster, Ian ; Kesselman, Carl ; Nick, Jeffrey M. ; Tuecke, Steven: The Physiology of the Grid. In: Open Grid Service Infrastructure
WG (2002), Juni. – URL http://www.globus.org/alliance/publications/
papers/ogsa.pdf
102
[Foster u. a. 2001] Foster, Ian ; Kesselman, Carl ; Tuecke, Steven: The
Anatomy of the Grid. In: International Journal of High Performance Computing
Applications 15 (2001), August, Nr. 3, S. 200–222. – URL http://www.globus.
org/alliance/publications/papers/anatomy.pdf
[Harwood und Tanin 2003] Harwood, Aaron ; Tanin, Egemen: Hashing Spatial Content over Peer-to-Peer Networks. In: Australian Telecommunications,
Networks and Applications Conference (CD-ROM), ATNAC, 2003. – URL
http://www.cs.mu.oz.au/~aharwood/online/HarwoodTanin-2003d.pdf
[Hauswirth und Dustdar 2005] Hauswirth, Manfred ; Dustdar, Schahram:
Peer-to-Peer: Grundlagen und Architektur. In: Datenbank-Spektrum 5 (2005),
Nr. 13, S. 5–13
[Heckmann und Bock 2002] Heckmann, Oliver ; Bock, Axel: The eDonkey
2000 Protocol / Department of Electrical Engineering & Information Technology. Dezember 2002. – Forschungsbericht
[Hämmerle 2004] Hämmerle, Lukas: P2P Population Tracking and Traffic Characterization of Current P2P File-sharing Systems, Eidgenössische Technische
Hochschule Zürich, Diplomarbeit, 2004
[Liming und Foster 2005] Liming, Lee ; Foster, Ian: GT4: What’s in it for
you? Mai 2005. – URL http://www.globus.org/alliance/publications/
clusterworld/0505Grid.pdf. – Das Magazin „Gridworld“ stellte vor der Veröffentlichung den Betrieb ein.
[Martelli u. a. 2005] Martelli, Alex ; Ravenscroft, Anna M. ; Ascher,
David: Python Cookbook. 2. O’Reilly, April 2005. – ISBN 0596007973
[Meyer 2005] Meyer, Angela: Grid: Visionen vom Computer aus der Steckdose.
In: Ct́ 23 (2005), November, S. 96–97
[Pilgrim 2004] Pilgrim, Mark: Dive into Python. 2. Apress, Juli 2004. – URL
http://diveintopython.org/. – ISBN 1590593561
103
[Sun Microsystems, Inc. 2005a] Sun Microsystems, Inc. (Veranst.): N1 Grid
Engine 6 Administration Guide. 817.5677.20. Mai 2005. – URL http://docs.
sun.com/app/docs/doc/817-5677?a=load
[Sun Microsystems, Inc. 2005b] Sun Microsystems, Inc. (Veranst.): N1 Grid
Engine 6 Installation Guide. 817.6118.20. Mai 2005. – URL http://docs.sun.
com/app/docs/doc/817-6118?a=load
[Sun Microsystems, Inc. 2005c] Sun Microsystems, Inc. (Veranst.): N1 Grid
Engine 6 Release Notes. 817.5678.20. Mai 2005. – URL http://docs.sun.
com/app/docs/doc/817-5678?a=load
[Sun Microsystems, Inc. 2005d] Sun Microsystems, Inc. (Veranst.): N1 Grid
Engine 6 Users Guide. 817.6117.20. Mai 2005. – URL http://docs.sun.com/
app/docs/doc/817-6117?a=load
[Thain u. a. 2002] Thain, Douglas ; Tannenbaum, Todd ; Livny, Miron: Condor and the Grid. In: Berman, Fran (Hrsg.) ; Fox, Geoffrey (Hrsg.) ; Hey, Tony
(Hrsg.): Grid Computing: Making the Global Infrastructure a Reality. John Wiley & Sons Inc., Dezember 2002. – URL http://media.wiley.com/product_
data/excerpt/90/04708531/0470853190.pdf
104
Weblinks
[Bart 2003] Bart, Jacob: Grid computing: What are the key components? Juni 2003. – URL http://www-128.ibm.com/developerworks/grid/library/
gr-overview/. – Zugriffsdatum: 13. Oktober 2006
[BitTorrent.org 2006a] BitTorrent.org: BitTorrent Protocol. Protocol Specifications v1.0, 2006. – URL http://www.bittorrent.org/protocol.html. –
Zugriffsdatum: 1. August 2006
[BitTorrent.org 2006b] BitTorrent.org: DHT Protocol, 2006. – URL http://
www.bittorrent.org/Draft_DHT_protocol.html. – Zugriffsdatum: 1. August
2006
[BitTorrent.org 2006c] BitTorrent.org: Fast Extension, 2006. – URL http:
//www.bittorrent.org/fast_extensions.html. – Zugriffsdatum: 1. August
2006
[Cohen 2003] Cohen, Bram: Incentives Build Robustness in BitTorrent, Mai
2003. – URL http://www.bittorrent.org/bittorrentecon.pdf. – Zugriffsdatum: 1. August 2006
[FAS 1999] FAS: Semi-Automatic Ground Environment (SAGE). Juni 1999. –
URL http://www.fas.org/nuke/guide/usa/airdef/sage.htm. – Zugriffsdatum: 14. Oktober 2006
[Huber 2006]
Huber, Prof. Dr. H.:
Theorie: Lineare Regression.
2006. – URL http://www.chemie.unibas.ch/~huber/Statistik/LinReg/
LRTheorie/theorie.html. – Zugriffsdatum: 5. Dezember 2006
105
[Merkey 2004] Merkey, Phil: Beowulf History. 2004. – URL http://www.
beowulf.org/overview/history.html. – Zugriffsdatum: 14. Oktober 2006
[MetaMachine 2003] MetaMachine: How Overnet works. 2003. – URL http:
//www.edonkey2000.com/documentation/how_on.html. – Zugriffsdatum: 6.
Oktober 2006
[Norberg 2005] Norberg, Arvid: LibtorrentDocs. Rasterbar Software (Veranst.), 2005. – URL http://www.rasterbar.com/products/libtorrent/
docs.html. – Zugriffsdatum: 6. Oktober 2006
[Reiser und Kapitza 2003] Reiser, Hans P. ; Kapitza, Rüdiger: Verteilte HashTabellen. 2003. – URL http://www4.informatik.uni-erlangen.de/Lehre/
WS03/V_VA/Skript/VA-6b.pdf. – Zugriffsdatum: 6. Oktober 2006
[Sun Microsystems, Inc. 2002] Sun Microsystems, Inc.: History of the Grid.
2002. – URL http://nz.sun.com/2002-0708/grid/history.html. – Zugriffsdatum: 15. Oktober 2006
[Surveyer 2002] Surveyer, Jacques: Grid computing uses spare CPU power. July 2002. – URL http://www.networkworld.com/news/tech/2002/0715tech.
html. – Zugriffsdatum: 13. Oktober 2006
[Thompson und Clavenna 2003] Thompson, Rick ; Clavenna, Scott: Grid
Networking. Mai 2003. – URL http://www.lightreading.com/document.asp?
doc_id=33405&print=true. – Zugriffsdatum: 6. Oktober 2006
[University of California 2006] University of California: Creating BOINC
projects. 2006. – URL http://boinc.berkeley.edu/create_project.php. –
Zugriffsdatum: 15. Oktober 2006
106
Inhalt der CD-ROM
Inhalt
/Diplomarbeit.pdf
/readme.pdf
/src
/doc
/jobs
Beschreibung
Datei, enthält die schriftliche Ausarbeitung der Diplomarbeit.
Datei, nennt Informationen zum Inhalt der CD-ROM
und dessen Verwendung.
Verzeichnis, enthält den Python Quelltext des Systems.
Verzeichnis, mittels pydoc generierte HTML Quelltextdokumentation.
Verzeichnis, JobPackackges der in Kapitel 7 durchgeführten Tests.
107
Glossar
ASCII . . . . . . . . . . . . . . American Standard Code for Information Interchange. 7
Bit Zeichenkodierung.
Batch Job . . . . . . . . . . Dies ist ein Synonym für Stapelverarbeitung. Aufgaben werden in eine Liste aufgenommen und sequentiell abgearbeitet.
BitTorrent . . . . . . . . . . Protokoll zum parallelen Datenaustausch über beliebig viele Rechner.
Chunk . . . . . . . . . . . . . . Dies sind die Teilelemente eines Datums. Ihre Größe und
Reihenfolge ist fest definiert. BitTorrent Peers übertragen
die zu verteilenden Daten in Chunks. Die Summe dieser
Chunks ergibt das Datum.
Cluster . . . . . . . . . . . . . Der Zusammenschluss mehrerer Computer zur Steigerung
der Leistung oder der Ausfallsicherheit.
Condor . . . . . . . . . . . . . Grid Software der Universität von Wisconsin
COTS . . . . . . . . . . . . . . Commodity Off The Shelf. Zu deutsch: Massenware aus
dem Regal.
Dictionary . . . . . . . . . . Datenstruktur im BitTorrent Protokoll, über die man anhand eines Schlüsselswertes auf einen darauf verwiesenen
Wert zugreifen kann. Vergleichbar mit Dictionaries in Python oder HashMaps in Java.
ExecutingNode . . . . . Ausführende Einheit, bekommt Aufgaben vom JobServer
zugewiesen, bearbeitet diese und stellt das Ergebnis dem
JobServer zur Verfügung.
Globus . . . . . . . . . . . . . Vereinigung zur Entwicklung von Gridtechnologie, welche
108
goober . . . . . . . . . . . . . .
Grid . . . . . . . . . . . . . . . .
GridManager . . . . . . .
Handshake . . . . . . . . . .
Hashfunktionen . . . . .
HTC . . . . . . . . . . . . . . .
HTTP . . . . . . . . . . . . . .
JobServer . . . . . . . . . . .
List . . . . . . . . . . . . . . . . .
Load Balancing . . . . .
Metadaten . . . . . . . . . .
NAT . . . . . . . . . . . . . . . .
Hersteller des Globus Toolkits sind.
Neuer, propäritärer, Instant Messenger mit VOIP Client
und vielen weiteren Features.
Oberbegriff für vernetzte Rechner, deren Kommunikation
und Zusammenarbeit über den reinen Datenaustausch hinausgehen.
Zentrales Resourcenmanagement. Zur Verwaltung von JobServern und ExecutionNodes.
Verfahren zwischen Kommunikationspartnern im Datenverkehr, um sich initial zu synchronisieren.
Berechnung, die aus einer Quelle beliebiger Größe ein eindeutiges Ergebnis definierter Größe erzeugt.
High Throughput Computing. Steht für möglichst schnelles
berechnen von Aufgaben auf langen Zeiträumen. Latenzzeiten spielen eine untergeordnete Rolle.
Hypertext Transfer Protocol. Dient zur Übertragung von
Daten über ein Netzwerk
Zentrales Aufgabenmanagement. Reserviert beim GridManager ExecutingNodes. Weist diesen Teilaufgaben zur Bearbeitung zu. Verwaltet die Daten der Aufgaben und der
Ergebnisse.
Datenstruktur im BitTorrent Protokoll, über die man eine
Sequenz beliebig vieler Datensätze hinterlegen kann. Vergleichbar mit den Listen von Python oder den Maps von
Java.
Durch geschicktes Routen im Netzwerk wird versucht, die
Netzlast über das Netz so zu verteilen, dass es zu keinen
Engpässen in der verfügbaren Bandbreite kommt.
Beschreibende Daten, die Informationen, wie Ort, Name
oder Größe der eigentlichen Daten vorhalten.
Network Address Translation. Verbindet zwei Netzwerke
mittels Ersetzung der Packetadressen durch Adressen des
Zielnetzes.
109
Node . . . . . . . . . . . . . . . Knotenpunkt in einem Grid. Jeder Node stellt einen eigenen
Rechner dar.
Offset . . . . . . . . . . . . . . . Im Zusammenhang des Datenzugriffs steht dieser Begriff
für die Distanz zwischen Anfang und dem Zugriffspunkt
einer Datei.
Peer . . . . . . . . . . . . . . . . Gleichgestellte Computer in einem Netzwerk, in dem jeder einzelne sowohl Server- als auch Client-Aufgaben wahrnimmt.
Proxyserver . . . . . . . . . Ein P. wird stellvertretend mit der Beschaffung von Daten
beauftragt, die dieser an den Auftraggeber überträgt.
Resource Balancing . Durch geschickte Planung wird versucht, eine Ressource,
wie z.B. ein Computercluster, homogen auszunutzen und
Lasten gleichmäßig zu verteilen.
Round Robin . . . . . . . Verfahren zur Ablaufsteuerung von Arbeitsschritten. Alle
Aufgaben bekommen nacheinander einen definierten Zeitschlitz für die Bearbeitung zur Verfügung gestellt.
SHA1 . . . . . . . . . . . . . . . Secure Hash Algorithm. Hashfunktion zum Erstellen von
160 Bit langen Hashwerten aus Quellen beliebiger Größe.
Subversion . . . . . . . . . . Freie Software zu Versionierung von digitalen Entwicklungsständen.
Virtual Organisation Geographie- als auch organisationsunabhängiger Zusammenschluss von beliebigen Computer, Netzwerken u.a. Ressourcen zu einer gemeinsamen Arbeitsgruppe.
WebDAV . . . . . . . . . . . Web-based Distributed Authoring and Versioning. Erweiterung des HTTP Protokolls um zusätzliche Funktionen im
Dateitransfer.
110
Stichwortverzeichnis
BitTorrent, 36, 37, 70
Intra-Grid, 10
Chunk, 32
Cluster, 10
Communication Package, 65
Computional Grid, 10
Condor, 24
Condor-C, 26
Condor-G, 26
JobScheduler, 57
JobServer, 52
Data Grid, 10
Downloader, 37
MainHook, 55
NodeManager, 57
OGSA, 19
Open Grid Forum, 18
OpenFT, 35
Python, 64
eDonkey2000, 34
ExecutionNode, 52
Extra-Grid, 10
FastTrack, 35
Globus, 19
Globus Toolkit, 21
Gnutella, 35
Grid Service, 19
GridManager, 51
Handshake, 47
IdleHook, 55
Inter-Grid, 11
Raytracing, 88
Scavenging Grid, 10
SubHook, 55
Sun N1 Grid Engine, 22
Torrent Dateien, 39
Tracker, 38
Verteilte Hashtabellen, 33

Adaptives High Throughput Computing in Scavenging Grids

Transcription

Similar documents

Entwurf und Implementierung eines verteilten Systems zur Suche