Dimitri Samorukov
Dezentrale Anwendungen
Operationen auf verteilten Daten
Dissertation
Informatik
Dezentrale Anwendungen:
Operationen auf verteilten Daten
Dimitri Samorukov
April 2020
Dezentrale Anwendungen:
Operationen auf verteilten Daten
Dissertation zur Erlangung des akademischen Grades DOKTOR-INGENIEUR
der Fakult¨at f¨ur Mathematik und Informatik der FernUniversit¨at
in Hagen
vorgelegt von
Dimitri Samorukov aus Porta Westfalica
Hagen, April 2020
Diese Stelle m¨ochte ich dazu nutzen, um meinen Dank an Personen aus meiner Umgebung auszusprechen, die mich all die Jahre begleitet haben.
In erster Linie geht mein Dank an Prof. Dr.-Ing. habil. Dr. h.c. Herwig Unger.
Er ist ein großartiger, harter und ebenso fairer Betreuer. Er hat daf¨ur gesorgt, dass ich das Beste aus mir herausholen konnte. Auch danke ich Dr.-Ing. habil.
Mario Kubek. Er hat mich durch seine Arbeit und Diskussion zu neuen Denk- weisen angestiftet. Des weiteren danke ich allen Beteiligten der Forschungs- gruppe, um die dezentrale Suchmaschine WebEngine und allen Mitgliedern des Lehrgebiet Kommunikationsnetze der Fernuni Hagen, f¨ur die Schaffung einer produktiven Arbeitsumgebung.
Der weitere Dank geht an Prof. Dr. Thomas B¨ohme und Prof. Dr. Dr. Wolfgang A. Halang f¨ur ihre fruchtbaren Diskussionen und Anregungen. Diese ließen mich ¨uber den Tellerrand meiner eigenen Umgebung blicken.
Mein besonderer Dank geht schließlich an meine Frau Olga. Sie ist f¨ur mich, wie kein Anderer, eine St¨utze gewesen.
Inhaltsverzeichnis
1 Einleitung 12
1.1 Motivation . . . 13
1.2 Der Beitrag dieser Arbeit . . . 16
1.3 Aufbau der Arbeit . . . 17
2 Stand der Technik 19 2.1 Klassische P2P-Netze . . . 21
2.1.1 Reduzierung der Kommunikationskosten . . . 22
2.1.2 Methoden des Lastenausgleichs . . . 27
2.1.3 Reduzierung der Latenzen . . . 28
2.1.4 Gestaltung der Operationen . . . 29
2.2 Grid- und Cloud-Computing . . . 32
2.2.1 Methoden des Lastenausgleich . . . 33
2.2.2 Reduzierung der Kommunikationskosten . . . 39
2.3 Kritik am Stand der Technik . . . 41
3 Das System 44 3.1 Peers . . . 44
3.1.1 Community . . . 44
3.1.2 Aufbau . . . 45
3.1.3 Kommunikation zwischen Peers . . . 45
3.2 Dezentrale Anwendung . . . 47
3.2.1 Verwaltungsstruktur der Anwendung . . . 47
3.2.2 Kommunikation innerhalb der Anwendung . . . 48
3.2.3 Operationen der Anwendung . . . 48
3.3 Das formale Model . . . 49
3.3.1 Peers . . . 49
3.3.2 Verwaltungsstruktur . . . 50
3.3.3 Abbildung von Gv auf Gp . . . 51
3.3.4 Lokale Sicht von Peer kp aufGv und Gp . . . 51
3.3.5 Operationen auf der Verwaltungsstruktur . . . 52
3.3.6 Weitere Zusammenh¨ange . . . 53
3.4 Modellierungen der Kommunikation . . . 54
3.4.1 Kommunikationsressourcen mit Latenzen und Bandbreiten . . . . 56
3.4.2 Verf¨ugbare Kommunikationsressourcen einer cp . . . 57
3.4.3 Ben¨otigte Kommunikationsressourcen einer cv . . . 62
3.4.4 Verbindungsg¨ute gv mit Latenz und Bandbreite . . . 67
3.4.5 Operationen und ihre Dauer Tov . . . 73
3.5 Problemdarstellung . . . 76
3.5.1 Formale Problemdarstellung . . . 78
4 Platzierung der Daten 80 4.1 Bewertung und Einordnung des Problems . . . 80
4.2 Anwendung des Sintflut-Algorithmus . . . 83
4.2.1 Einblick in Sintflut-Algorithmus . . . 83
4.2.2 Eingabeparameter . . . 85
4.2.3 Verschiebe-Richtung und Knotengewicht . . . 87
4.2.4 Generierung der initialen L¨osung . . . 89
4.2.5 Umsetzung des Manipulationsschritts . . . 91
4.2.6 Einbettung in den Sintflut-Algorithmus . . . 95
4.3 Zusammenfassung . . . 98
5 Peer-Ressourcen 99 5.1 Ressourcen-Variabilit¨at . . . 100
5.2 Multidimensionalit¨at der Ressourcen . . . 102
5.3 Zusammenfassung . . . 104
6 Verifikation 105 6.1 Hypothesen . . . 105
6.1.1 Entscheidungsgrundlage f¨ur Hypothesen . . . 105
6.1.2 Betrachtete Topologien . . . 107
Inhaltsverzeichnis
6.1.3 Zuf¨allige L¨osungsfunktion . . . 108
6.1.4 Zusammenfassung . . . 109
6.2 Aufbau der Simulationen . . . 110
6.2.1 Simulation des lokalen Peer-Verhaltens . . . 110
6.2.2 Simulation des globalen Anwendungsverhaltens . . . 119
6.3 Durchf¨uhrung der Experimente . . . 133
6.3.1 Lokales Peer-Verhalten . . . 134
6.3.2 Globales Anwendungsverhalten . . . 139
6.4 Diskussion und Bewertung der Ergebnisse . . . 142
6.4.1 Lokales Peer-Verhalten . . . 142
6.4.2 Globales Anwendungsverhalten . . . 146
7 Zusammenfassung und Ausblick 148 7.1 Zusammenfassung . . . 148
7.2 Ausblick . . . 149
A Anhang 151 A.1 Nachweise der Hypothesen des lokalen Verhaltens des Peers . . . . 151
A.1.1 Lokale Korrektheit: graphische Ergebnisse . . . 151
A.1.2 Lokale Korrektheit: Kumulierte Verl¨aufe . . . 156
A.1.3 Lokale Verkehr-Adaptierbarkeit . . . 158
A.2 Nachweise der Hypothesen des globalen Anwendungsverhaltens . . 160
A.2.1 Ausf¨uhrungsdauer der Operationen . . . 160
A.2.2 Gemessene Knotenlokalit¨aten . . . 164
Symbolverzeichnis
Gp Community der Peers als ungerichteter, vollst¨andiger Graph, definiert durchGp = (Kp, Cp),Cp=Kp×Kp, mit Kp=kp1, ...kNp als Menge alle Peers in der Community.
kp Ein Peer des Netzwerks Gp, definiert durch bereitgestellte Rbp und aktuell frei verf¨ugbare Ressourcen Rp. kp = (Rbp, Rp).
Rbp Insgesamt bereitgestellte Ressourcen f¨ur die Anwendung durch den Operator eines Peers.
Rp Aktuell frei verf¨ugbare Ressourcen f¨ur die Anwendung auf einem Peer.
cp Verbindung zwischen zwei Peers, gekennzeichnet durch ihre verf¨ugbaren Kommunikationsressourcen gp.
gp Verf¨ugbare Kommunikationsressourcen einer Peer-Verbindungcp. Gv Graph der Verwaltungsstruktur, definiert durchGv = (Kv, Cv),
Cp ⊆Kv×Kv, mit Kv=kv1, ...kvN.
kv Ein Knoten innerhalb der Verwaltungsstruktur Gv.
Rv Menge der ben¨otigtenkp-Ressourcen f¨ur einen Knoten kv. cv Inter-Struktur-Verbindung zwischen Knotenkv im Graph Gv,
definiert durch ihreVerbindungsg¨ute gv und ben¨otigte Kommunikationsressourcen Vinv.
Vinv Ben¨otigte Kommunikationsressourcen der Verbindungcv, korrespondiert zu den bereitgestellten Ressourcen gp einer Peer-Verbindungcp.
gv Verbindungsg¨ute der Inter-Struktur-Verbindung cv, ein
Optimierungskriterium. Beschreibt in wie weit die ben¨otigten Kommunikationsressourcen Vinv aktuell zur Verf¨ugung stehen.
Inhaltsverzeichnis
Zm Menge aller m¨oglichen Knotenzuordnungen zm von Kv zu Kp. zm Eine Knotenzuordnungen von KnotenKv zu Peers Kp, entspricht
der Abbildung Φ :Kv →Kp.
Φ Abbildung der Knoten Kv auf Peers Kp, definiert durch Φ :Kv →Kp.
Gpv Partition von GraphGv bei der alle Knoten kv dem lokalen Peer zugeordnet sind.
Glocv Partition von GraphGv die ein Peer aus seiner, lokalen Sicht kennt. Es ist die PartitionGpv, erweitert um Knoten kv auf anderen Peers mit direkter Verbindung zu Knoten ausGpv. Glocp Die N achbarschaf teines Peers, also der Teil von Gp zu dem er
¨uberGlocv verbunden ist.
Kploc Menge der Peers aus Glocp . Kvloc Menge der Knotenkv aus Glocv .
Φloc Abbildung der Knoten Kvloc auf Knoten Kploc aus der lokalen Peer-Sicht.
Zmloc Entsprechend der Abbildung Φloc representiert Zmloc die Menge der m¨oglichen Knotenzuordnungen aus der lokalen Peer-Sicht.
Ov Eine Operationen auf der Verwaltungsstruktur Gv. Es gilt Ov ∈Oges.
Oges Menge aller Operationen auf der Verwaltungsstruktur Gv. Pov Routing-Pfad einer Operation ¨uber die KnotenKv als geordnete
Menge.
Lov Gr¨oße einer Operation Ov in [bit].
Tov Dauer in [s] des Laufs einer Operation Ov uber den Routing-Pfad¨ Pov.
Vtr Bereitgestellte Kommunikationsressourcen einer cp als Ubertragungsgeschwindigkeit [bit/s].¨
Tdelay Bereitgestellte Kommunikationsressourcen einer cp als Latenz in [s].
Tv Ben¨otigte Kommunikationsressourcen einercv als Sendeperiode in [s].
Nv Ben¨otigte Kommunikationsressourcen einercv als Paketgr¨oße in [bit], die mit der Periode Tv verschickt werden.
Tsend Versanddauer eines Pakets ¨uber cp, siehe Formel 3.1.
Nest Mindestanzahl der verschickten Pakete von jeder cv, f¨ur die Sch¨atzung vongv, Formel 3.5.
tblock Zeit in [s],um die ein zu verschickendes Paket ¨uber cp, auf Grund der belegten Verbindung seine gew¨unschte Periode ¨uberschreitet, Formel 3.5.
Vinv Durchschnittliches Verkehrsaufkommen auf einer Verbindungcv, Formel 4.1.
Wkv Knotengewicht vom Knotenkv, Formel 4.2.
Vkpeer
v Peer-Verkehrsaufkommen, gesch¨atzte Verkehrsmenge vom lokalen Peer in richtung verbundenem Peer, Formel 4.3.
p(kv) Wahrscheinlichkeit f¨ur einen Knotenkv f¨ur die Verschiebung gew¨ahlt zu werden, Formel 4.4.
O Fitnesswert einer gefundenen Zuweisung z ∈Zmloc als Entscheidungsgrundlage f¨ur die L¨osungssuche, Formel 4.7.
OS Schwelle des Fitnesswerts der Sintflut-L¨osungssuche, siehe Kapitel 4.2.6 und die Formel 4.8.
Ornd Durchschnittliche Fitness der L¨osungen bei Simulationen mit zuf¨alligerL¨osungsfunktion. Siehe Kapitel 6.2.1.
Inhaltsverzeichnis
Oinit Durchschnittliche Fitness der initialen L¨osung bei Simulationen mit optimierter L¨osungsfunktion. Siehe Kapitel 6.2.1.
Oopt Durchschnittliche Fitness der finalen L¨osung bei Simulationen mit optimierterL¨osungsfunktion. Siehe Kapitel 6.2.1.
Oinit Normierung von Oinit aufOrnd. Siehe Kapitel 6.2.1.
Oopt Normierung von Oopt auf Ornd. Siehe Kapitel 6.2.1.
TRand Durchschnittliche Ausf¨uhrungsdauer von Operationen bei
Simulationen mit zuf¨alligerL¨osungsfunktion. Siehe Kapitel 6.2.2.
Topt Durchschnittliche Ausf¨uhrungsdauer von Operationen bei Simulationen mit optimierterL¨osungsfunktion. Siehe Kapitel 6.2.2.
Tallocopt Durchschnittliche Ausf¨uhrungsdauer von Operationen bei Simulationen mit optimierterL¨osungsfunktion und gemessenem Verkehrsaufkommen. Siehe Kapitel 6.2.2.
Topt Normierung von Topt auf TRand. Siehe Kapitel 6.2.2.
Tallocopt Normierung von Tallocopt auf TRand. Siehe Kapitel 6.2.2.
Die notwendige Hardware f¨ur die Verarbeitung der Daten hat in den letzten 80 Jahren enorme Entwicklungen gemacht. Diese ging von teuren, zentralisier- ten Großrechnern ¨uber den privaten Rechner f¨ur jeden Haushalt bis hin zur Massenware, wie mobile Telefonie oder einfache Temperatur-Sensoren. Mit der Leistungsf¨ahigkeit und der Verbreitung nahm die Heterogenit¨at der Hardware eben so zu. Es gibt weiterhin leistungsstarke Hardware (Großrechner, Cloud), w¨ahrend am anderen Skalenende Einfachstrechner vorherrschen.
Mit der Verbreitung der Hardware wurde die Notwendigkeit deren Vernetzung erkannt. Produzierte Daten mussten effektiv ausgetauscht werden. Nicht jeder Datenproduzent ist in der Lage, diese auch zu verarbeiten. Nicht jeder Daten- verarbeiter besitzt die Daten. So, im Falle des einfachen Temperatur-Sensors, ist dieser weder in der Lage seine eigenen Daten langfristig zu speichern, noch effektiv mit dieser Datenmenge zu arbeiten. Durch die Vernetzung erh¨alt er jedoch Zugriff auf andere Hardware, deren Speicher- und Prozessorressourcen die erzeugten Daten verarbeiten und speichern k¨onnen.
Wer ist den nun der Empf¨anger dieser Sensordaten? Ist es ein einzelner Groß- rechner, der genug Ressourcen besitzt um diese Daten langfristig zu speichern und ebenfalls zu verarbeiten, aber der nun die gesamte Gewalt ¨uber die Da- ten besitzt? Solche zentralisierten Systeme wurden schon fr¨uh als nachteilhaft empfunden. Die Besitzerinstanz kann b¨osartig, unzuverl¨assig bzw. ¨uberlastet sein, so dass die Daten nicht erreichbar oder verf¨alscht sind. Daher wird eine Community von Rechnern, in einem dezentralen Peer-to-Peer-Netzwerk (P2P) als bessere Alternative zum zentralisierten Ansatz gesehen.
Die Anzahl der Daten steigt weiter an, genau so wie die Anzahl und Hete- rogenit¨at der Hardware, die diese Daten bereitstellt bzw. konsumieren will.
1.1 Motivation
Diese Arbeit besch¨aftigt sich mit der Frage der effizienten Bereitstellung und dem Zugriff auf die Daten in dezentraler Weise, so dass die Heterogenit¨at der vielf¨altigen Hardware durch die P2P-Community sinnvoll ausgenutzt wird.
1.1 Motivation
Eine P2P-Community besteht aus einer Menge von Hardware-Knoten, die ihre bestehenden Ressourcen wie Prozessorzeit, Speicherplatz, Ein-/Ausgabe- Peripherie einer dezentralen Anwendung zur Verf¨ugung stellen. Jeder Peer dieser Community kennt einen oder mehrere weitere Peers. Der Ressourcen-Beitrag eines Peers ist eine freiwillige Leistung. Sein Betrag unterscheidet sich von Peer zu Peer und unterliegt zeitlichen Schwankungen.
Diverse, aktuell existierende Anwendungen sind dezentral aufgebaut und er- fordern f¨ur ihre Funktion eine vorhandene P2P-Community. Erw¨ahnenswert hierbei sind die dezentralen Websuchen und soziale Netzwerke, Linked Data - Initiative und digitale W¨ahrungen. Diese Beispiele werden genauer beleuchtet.
Die dezentralen Websuchen ([46] ,[47], [21], [8]) stellen eine Alternative zu den kommerziellen und zentralisierten Ans¨atzen der Websuche-Anwendungen.
Der erstellte Datensatz hierbei besteht aus Klassifizierungsdaten des WWW.
Die Benutzer k¨onnen der entsprechenden Community beitreten und erlauben der Anwendung die Nutzung der Ressourcen ihrer Peers. Die einzelnen Peers sind in der Verantwortung das WWW zu durchsuchen und die Ergebnisse der Webseiten-Klassifizierung in den global gehaltenen, f¨ur alle Peer sichtbaren Datensatz zu integrieren. Sucht nun ein Benutzer bestimmte Inhalte im WWW, so wird umgekehrt der global gehaltene Datensatz nach Eintr¨agen, entsprechend den Suchkriterien durchsucht. Hierbei gibt es keine zentrale Instanz die ¨uber die Menge der Suchergebnisse oder deren Ranking [61] entscheidet.
Soziale Netzwerke, in ihrer dezentralen Auspr¨agung [15], geben dem Nutzer die volle Kontrolle ¨uber seine Daten. Die konkrete Realisierung unterscheidet sich jedoch von Umsetzung zu Umsetzung. W¨ahrend Diaspora [17] alle Daten des Benutzers auf seinem lokalen Peer beibeh¨alt, erzeugt DECENT [34] einen
verteilten Datensatz (DHT, blockchain), der die Personeninformationen ver- schl¨usselt speichert. In jedem Fall existiert bei diesen Anwendungen immer ein Datensatz, der die Daten der Anwendung repr¨asentiert, aber dennoch dezentral gehalten wird.
Die Linked Data-Initiativen [25] bilden einen global verteilten Datensatz in der Community, basierend auf dem Symantic-Web-Ansatz. Einzelne, haupts¨achlich wissenschaftliche Einrichtungen, stellen ihre Datenteile im globalen Datensatz bereit, diese m¨ussen jedoch zu ¨ahnlichen Daten verlinkt werden. Die Datenteile verbleiben auf eigenen Peers der Einrichtung. ¨Ahnlich wie im WWW, besteht hier das Problem der Inhaltssuche. Es existieren sowohl zentralisierte als auch dezentrale Ans¨atze. Die vorhandene Peer-Community stellt Inhalte bereit, ist aber auch in der Lage Ressourcen f¨ur dezentrale Ans¨atze beizusteuern.
Auch digitale W¨ahrungen stellen eine dezentraler Anwendung dar. Das Ziel dieser Anwendung ist die Pflege und sichere Haltung eines verteilten Log- buchs mit Besitzinformationen. Dieses Logbuch ist ein dezentral gehaltener Datensatz. Der Kern der Anwendung ist die Zusage, dass einmal gespeicherte Eintr¨age des Logbuchs im nach-hinein nicht mehr ver¨andert werden k¨onnen.
In urspr¨unglichen Versionen wurde der Datensatz durch vollst¨andige Replika- tionen ([57]) zwischen Peers geteilt. Da der Datensatz auf mehrere Hundert GB anwuchs, waren nur wenige Peers bereit, entsprechend viele Ressourcen bereitzustellen und so schrumpfte die Community auf wenige Peers, die nun großen Einfluss in der Anwendung bekamen. Daher wurden Ans¨atze wie IOTA [63] entwickelt, die den großen, ¨uber mehrere Peers replizierten Datensatz, in kleineren, miteinander verkn¨upften Einheiten ¨uber die Peer-Community verteilen. Die Anforderungen an einen Peer wurden reduziert, dies vergr¨oßert die Community, was den Einfluss b¨oswilliger Peers reduziert.
Dieser verteilte Datensatz (auch Verwaltungsstruktur) stellt besondere Heraus- forderungen an die Anwendung, im einzelnen sind es:
• h¨ohere Anf¨alligkeit gegen¨uber Datenverlust aufgrund ungeregelter Peer- Abwanderung
1.1 Motivation
• steigende Reaktionszeiten der Anwendung gegen¨uber einer zentralisierten L¨osung
• Ressourcenverantwortlichkeit: die Anwendung steht nun selbst vor der Aufgabe gen¨ugend Ressourcen f¨ur die Community einzusammeln anstatt, wie im zentralisierten Ansatz, von ihrer Verf¨ugbarkeit auszugehen.
Die Peer-Abwanderung wurde bereits im Zusammenhang mit P2P-File-Sharing Netzwerken untersucht [77]. Diese Untersuchungen ergaben, dass nur wenige zuverl¨assige Peers im Vergleich zu unzuverl¨assigen existieren. Der Einfluss eines Peer-Fehlers kann reduziert werden indem Redundanzverfahren eingef¨uhrt werden. Eine redundante Datenhaltung bei unzuverl¨assigen Peers ist eine hohe H¨urde. Die Entscheidung, die Ressourcen eines Peers zu verwenden, ben¨otigt Kriterien und Verfahren, um aus der Masse der unzuverl¨assigen Peers, die zuverl¨assigen zu identifizieren. Eine Abw¨agung zwischen Peerwahl- und Redundanzverfahren muss die Anwendung f¨ur sich treffen.
Eine ungeregelte Peer-Abwanderung bedeutet einen Abbruch von laufen Opera- tionen der Anwendung und/oder Datenverlust. Die Notwendigkeit von erneuter Ausf¨uhrung von Operationen erh¨oht ebenfalls ihre Reaktionszeit. Wobei die Reaktionszeiten auch durch weitere Faktoren beeinflusst werden. Operationen, die einige Teile des verteilten Datensatzes ben¨otigen, sind gezwungen, f¨ur den Abschluss ¨uber mehrere Peers ihre Anfragen zu stellen. Hierbei spielen die Bandbreiten der Peer-Verbindungen, verf¨ugbare Prozessor-Ressourcen und die Anzahl zu ¨uberbr¨uckender Peers die wesentlichen Rollen. Auch hier kann die vorausschauende Wahl der Community-Teilnehmer Abhilfe schaffen, in dem nur gut verbundene Peers mit vielen Ressourcen-Reserven in die Community aufgenommen werden. Die Nutzung nur weniger Peers erh¨oht jedoch wieder den Einfluss vom einzelnen Peer. Es ist, aus zwei bereits genanten Gr¨unden, nicht w¨unschenswert: a) wegen b¨osartigem Einfluss auf den Datensatz und Operationen und b) h¨oherem Risiko f¨ur Datenverlust.
Es ist in der Verantwortlichkeit der Anwendung gen¨ugend Ressourcen anzusam- meln und ihre Community m¨oglichst dezentral zu gestalten. Daf¨ur muss diese Anreize schaffen. Die Peers m¨ussen einen Vorteil dabei sehen, der Community anzugeh¨oren. Ist der Peer einmal der Community beigetreten, darf dieser durch
die Anwendung ebenfalls nicht missbraucht werden. Eine nicht ausreichende Ressourcen-Menge f¨uhrt zu steigenden Reaktionszeiten und im Extremfall zum Datenverlust. Dies reduziert wiederum die Akzeptanz der Anwendung beim Benutzer.
Die Akzeptanz der dezentralen Anwendungen leidet an oberen Herausforderun- gen. Die Benutzer erhalten nicht ihre gewohnten Reaktionszeiten der Anwen- dung, die Entwickler der Anwendung stehen vor ganz neuen Herausforderungen im Vergleich zu zentralisierten Ans¨atzen. Die Motivation dieser Arbeit ist es nun Verfahren zu entwickeln, um die Konkurrenzf¨ahigkeit von dezentralen zu zentralisierten Anwendungen zu erh¨ohen. F¨ur den Benutzer sollte es am Ende transparent sein, ob er gerade mit einer dezentralen oder zentralisierten Anwen- dung interagiert. Die Peers der Community werden durch die Anwendung nicht uberlastet, die Anwendung hat jedoch gen¨ugend Ressourcen zur Verf¨ugung und¨ kann ihren Datensatz sicher in der Peer-Community halten.
1.2 Der Beitrag dieser Arbeit
Der Beitrag dieser Arbeit geht auf die vorher genanten Herausforderungen, im dezentralen Umfeld, ein.
Es wird die Reduzierung der Reaktionszeiten der Anwendung, bei paralleler Verbesserung der Ressourcenverf¨ugbarkeit adressiert. Wobei hier von einer Verwaltungsstruktur ausgegangen wird, deren Teile zwischen Peers verschoben werden k¨onnen.
Es werden Verfahren f¨ur folgende Fragestellungen geliefert:
• wie k¨onnen die Antwortzeiten der Anwendung verbessert werden und die vorhandenen Peer-Ressourcen besser genutzt werden
• wie kann die Ressourcenverf¨ugbarkeit in der P2P-Community insgesamt erh¨oht werden.
1.3 Aufbau der Arbeit
Es wird angenommen, dass die strikte Einhaltung der zugesagten Peer- Ressourcen, die Wahrscheinlichkeit f¨ur den l¨angeren Verbleib eines Peers in der Community erh¨oht. Dies vereinfacht die Ressourcenverantwortlichkeit der dezentralen Anwendung.
1.3 Aufbau der Arbeit
Es folgen insgesamt weitere 6 Kapitel. An dieser Stelle soll dem Leser ein Uberblick ¨uber die gesamte Arbeit gegeben werden.¨
Das nachfolgende Kapitel 2 gibt einen umfassenden ¨Uberblick ¨uber die aktu- ellen Methoden der Antwortzeit-Verbesserung von verteilten Anwendungen.
Insbesondere werden solche Felder wie Cloud- und Grid-Computing, klassische P2P-Netzwerke aber auch verteilte Datenbanken untersucht. Es werden auch einige wichtige Begriffe erl¨autert, die sich in diesem Umfeld manifestiert haben und auch im Rest dieser Arbeit eine Rolle spielen. Das Kapitel wird mit Kritik am Stand der Technik abgeschlossen.
Das Kapitel 3 definiert das betrachtete System. Im ersten Teil findet eine sinn- gem¨aße Beschreibung des Systems der hier betrachteten verteilten Anwendung.
Daraufhin folgt eine, mehr formale Beschreibung der Teilnehmer des Models.
Im Einzelnen ist hier die Rede von Peers, mit ihren bereitgestellten Rechen- und Netzwerkressourcen, sowie von der Anwendung, die diese bereitgestellten Ressourcen f¨ur sich und ihre Verwaltungsstruktur ben¨otigt. Im weiteren Teil des Kapitels folgen Modelle der Kommunikation zwischen den Peers und innerhalb der Anwendung.
Die Definitionen aus Kapitel 3 erlauben es nun, das im Kapitel 1.2 angespro- chene Problem der Antwortzeitoptimierung, formal anzugeben. Dieses findet im Kapitel 3.5 statt. Auch hier folgt erst eine sinngem¨aße Beschreibung, bevor die formale Darstellung gegeben wird.
Im Kapitel 4 wird eine L¨osung f¨ur die Antwortzeitoptimierung gegeben. Die Verwaltungsstruktur wird als ein Graph modelliert. Damit reduziert sich das
Problem, auf ein Problem der Graph-Partitionierung mit gewichteten Kanten.
Wobei jedoch hier die Kantengewichte dynamisch sind. Schon das einfache Problem der Graph-Partitionierung ist als NP-Vollst¨andig bekannt. Daher wird hierbei f¨ur die L¨osung, auf den heuristischen Sintflut-Algorithmus gesetzt. So beginnt das Kapitel 4 mit einer Bewertung des Problems. Daraufhin werden die Eckpunkte des Sintflut-Algorithmus beleuchtet, bevor dann in den letzten Abschnitten die Adaption der Sintflut-Suche auf das hier vorliegende Problem beschrieben wird.
Die gefundene L¨osung funktioniert nur, wenn die Peer-Ressourcen als skalarer Wert dargestellt werden und diese nur in diskreten Schritten von festgelegte Schrittweite vom Peer angeboten und von der Anwendung konsumiert werden.
Dezentrale Anwendungen k¨onnen jedoch mehr als eine Peer-Ressource ben¨otigen und diese wird in kontinuierlichen Werten verbraucht. Im Kapitel 5 wird nun gezeigt, wie diese mehrdimensionale, kontinuierliche Ressourcen-Definition auf eine skalare, diskreten Darstellung reduziert werden kann.
Kapitel 6 hat zwei Zielsetzungen. Das erste ist die Verifikation des gew¨unschten Peer-Verhaltens. Das zweite ist der Nachweis, dass das erreichte Peer-Verhalten tats¨achlich aus der globalen Sicht der verteilten Anwendung vorteilhaft ist. Im ersten Fall wird ein Peer betrachtet, der nur eine begrenzte Sicht auf seine Nach- barschaft besitzt und versucht sein Verhalten bez¨uglich dieser Nachbarschaft zu optimieren. Im zweiten Fall wird untersucht ob das gemeinsame, optimierte Verhalten der einzelnen Peers tats¨achlich f¨ur die Optimierung der Antwortzeit von Operationen geeignet ist.
Zuletzt findet im Kapitel 7 eine abschließende Betrachtung statt, mit nach- folgendem Ausblick auf Aufgabengebiete, die sich aus dieser Arbeit ergeben haben.
2 Stand der Technik
Die dezentralen Anwendungen grenzen das betrachtete Umfeld ein. Dezentrale Anwendungen basieren entweder auf einem P2P-Netz oder Grid- bzw. Cloud- Computing. Es wird ein ¨Uberblick ¨uber die Methoden gegeben, die in jeweiligem Umfeld den Stand der Technik bilden. Der Fokus liegt hierbei auf der Reduktion der Antwortzeiten der Anwendung. Die Antwortzeit der Anwendung ist im we- sentlichen gepr¨agt von ben¨otigten Kommunikationskosten ( ¨Ubertragungszeiten im Netzwerk), erforderlichen Prozessorressourcen (Ausf¨uhrungszeiten) und den entstandenen Wartezeiten (z.B. durch ausgelasteten Prozessor in den Ubertragungspuffern) jeder ausgef¨uhrten Operation.¨
Mit klassischen Peer-to-Peer-Netzen sind Netzwerke gemeint, die sich innerhalb vom Internet gebildet haben. Diese Netze nutzen die IP-basierten Transport- schichten wie TCP bzw. UDP. Die oft genannten Vertreter hierbei sind Gnutella [67], Napster [72], freenet [11]. Ein P2P-Netzwerk besteht aus einzelnen Peers, die einige andere Peers des Netzwerks kennen. Diese Verbindungen, zusam- men mit den Peers, bilden das P2P-Netzwerk. Dieses Netzwerk ¨uberlagert das darunterliegende Netzwerk (Internet), daher ist an dieser Stelle oft von einem Overlay-Netzwerk die Rede. Als Teilnehmer des P2P-Netzwerks stellen die Peers ihre Ressourcen der Anwendung bereit. Dies sind in erster Linie der lokale Speicher, Prozessor-Zeit aber auch lokale Dateien. Peers treten spontan dem Netzwerk bei und verlassen dieses oft ohne ordentliche Abmeldung. Diese spontane Ab- und Zuwanderung muss als inh¨arente Eigenschaft eines jeden P2P-Netzwerks angesehen werden [77].
Dezentrale Anwendungen setzen auf P2P-Netzwerken auf. Die ersten dezen- tralen Anwendungen dienten dem Musiktausch(z.B.Napster [72]), andere dem Dateitausch (Gnutella [67]), wiederum andere kombinierten den Dateitausch mit Anonymisierungseigenschaften (freenet [11]). Es gibt jedoch auch Beispiele
f¨ur verteiltes Rechnen wie das Seti@Home - Projekt [36] , digitale W¨ahrungen (IOTA [63]) oder dezentralen Websuchen ([46] ,[47]). Bezeichnend f¨ur diese Anwendungen ist der Datensatz, auf dem diese Arbeiten. Dieser wird als Ver- waltungsstruktur bezeichnet.
So durchsuchen die dezentralen Web-Suchen das Web und generieren f¨ur die gefundenen Dokumente eine kompakte Beschreibung (den Index). Diese Be- schreibung wird im P2P-Netz der Anwendung gespeichert. F¨uhrt ein Benutzer eine Suche aus, so wird dieser Datensatz durchsucht und passende Dokumente bzw. Links zur¨uckgegeben. Beispiele f¨ur solche Anwendungen sind gegeben in [8], [48]. Damit bildet diese Beschreibung die Verwaltungsstruktur der An- wendung. Weitere Beispiele der dezentralen Dokumentsuche sind gegeben in [46] [47]. Hierbei bilden die einzelnen Co-Occurrence-Graphen, die Knoten der Verwaltungsstruktur und die Menge aller Co-Occurrence-Graphen bildet die Verwaltungsstruktur. Im Fall von IOTA [63] sind es die gespeicherten Transak- tionen, in Form des gerichteten, azyklischen Graphen. So l¨asst sich bei jeder dezentralen Anwendung eine Verwaltungsstruktur identifizieren.
Grid-Umgebungen wurden schon sehr fr¨uh eingesetzt, um komplexe, langwierige Berechnungen in einem Zusammenschluss von mehreren, oft gleichwertigen Rechnern bzw. Prozessoren, auszuf¨uhren. Pr¨agnant f¨ur dieses Umfeld ist auch die Gleichwertigkeit von Kommunikationskosten zwischen allen Prozessoren.
Neuerdings werden solche Umgebungen auch als Cloud bezeichnet. Wobei Cloud - Umgebungen explizit daf¨ur ausgelegt wurden, die Rechenzeit als Dienstleistung (¨ahnlich wie Strom) zu verkaufen, w¨ahrend Grid-Computing mehr geschlossener Natur ist [23], wobei die Nutzung auf eine Organisation begrenzt ist. Beide stehen jedoch vor dem Problem der Verbesserung der Antwortzeit von eingelas- teten Operationen (engl. Tasks). Die Verf¨ugbarkeit der Ressourcen muss hier nicht ber¨ucksichtigt werden, da es nur einen Betreiber der Anlage gibt, der sich um Verf¨ugbarkeit von Ressourcen k¨ummert.
Die Ressourcenverf¨ugbarkeit in den P2P-Netzwerken ist eins der Unterschiede zu zuverl¨assigen Grid-Computing-Umgebungen. In Letzteren kann eine An- wendung den Ausfall einer Ressource als Ausnahme betrachten, w¨ahrend dies bei P2P als Normalfall gilt. Des weiteren bildet die Heterogenit¨at der Peers,
2.1 Klassische P2P-Netze
bez¨uglich ihrer Verbindungsgeschwindigkeit und bereitgestellter Ressourcen [67], ein weiteres Unterscheidungskriterium zu Grid-Computing-Umgebungen. Das Overlay bildet einen weiteren Unterschied zu Grid-Computing-Umgebungen.
Bevor ein Peer dem P2P-Netzwerk beitreten kann, muss dieser erst eine, evtl.
komplizierte Anmelde-Prozedur ausf¨uhren und sich erst in das Overlay einrei- hen. Im Gegensatz zu Grid-Umgebungen ist die Kommunikation zwischen den P2P-Teilnehmern nur ¨uber die Overlay-Verbindungen m¨oglich.
2.1 Klassische P2P-Netze
Die dezentralen Anwendungen basieren auf Operationen. Diese starten auf einem Peer, besuchen mehrere und kehren dann, mit dem Ergebnis zum Aufrufer zur¨uck. Je nach Auspr¨agung k¨onnen es einfache Broad-Cast-Nachrichten im P2P-Overlay sein, oder jedoch an einzelne Peers gerichtete Nachrichten, die einem vorgegeben Pfad im Overlay folgen. Bez¨uglich der Optimierungen von Operationen innerhalb der dezentralen Anwendung, sind in den P2P-Netzen folgende Methoden g¨angig:
• das Overlay des P2P-Netzwerks wird entsprechend aufgebaut, dass Ope- rationen m¨oglichst kleine Kommunikationskosten erzeugen
• faire Lastverteilung zwischen Peers, so dass Operationen m¨oglichst ohne Wartezeit die Prozessorressourcen nutzen k¨onnen
• Nutzung von latenzbasierten Adressen, so dass Operationen nur Peers nutzen, die schnell erreicht werden k¨onnen
• direkte Optimierung von Operationen. Am Beispiel der Linked-Data w¨are es die Reduktion der ben¨otigten Kommunikationsmenge und Prozessorzeit durch die Gestaltung der Operation.
Diese Methoden werden in den folgenden Kapiteln genauer beleuchtet.
2.1.1 Reduzierung der Kommunikationskosten
Ein Overlay-Netzwerk kann die notwendigen Kommunikationskosten einer Operation, durch ein effektives Routing der Operationen, wesentlich beeinflussen.
In diesem Abschnitt werden die Overlay-Netzwerke der g¨angigen P2P-Systeme untersucht.
Die Peers sind auf die Dienste des Internet angewiesen. Da das Internet aus unterschiedlichen verbundenen Einzelnetzen besteht, sind nicht alle, f¨ur den Betrieb des P2P-Netzes ben¨otigten Dienste, verf¨ugbar. So verbieten die Provider ein internetweites Broadcast oder entspricht das Routing der IP-Pakete, nicht den notwendigen Anforderungen. Daher bilden die P2P-Netzwerke ihr eigenes, uberlagertes Netzwerk, in dem nur die Teilnehmer des P2P-Netzes vorkommen.¨ Dieses ¨uberlagerte Netzwerk (engl. Overlay) besitzt seine eigene, an die Zwecke des jeweiligen dezentralen Anwendung angepasste, Topologie [10]. Bilden die Knoten im Internet noch ein vollst¨andig verbundenen Graphen, so wandelt das Overlay die Topologie zu einem Ring, Baum, Small World [52],[7] etc. . Beim Betreten des P2P-Netzwerks sucht jeder neuer Peer seine Nachbarn und reiht sich so, in das existierende Overlay ein. Hierzu muss der Peer jedoch zumindest einen, existierenden Teilnehmer des P2P-Netzwerks, kennen bzw.
finden. Hierf¨ur werden die sogn. ’bootstrapping nodes’ verwendet, die eine feste, statische IP-Adresse verwenden, oder es werden die DNS-Dienste des Internet eingesetzt. Damit l¨osen neue Peers vorhandene Teilnehmer ¨uber ihren Dom¨anen-Namen auf.
Ein Beispiel eines Overlay-Netzwerks ist im Bild 2.1 dargestellt. Hier sind alle Rechner ¨uber ein einfaches, lokales Netzwerk verbunden. Jeder Rechner kann jeden anderen erreichen. Einige Rechner sind jedoch Teil einer dezentraler Anwendung. Die hierf¨ur ausgew¨ahlte Rechner kommunizieren bevorzugt nur mit speziellen Rechnern, die in der Logik der Anwendung ihre Nachbarn sind.
Damit bilden diese Rechner, f¨ur die Anwendung ein eigenes Netzwerk, das Overlay.
2.1 Klassische P2P-Netze
Abbildung 2.1: Beispiel eines Overlay-Netzwerks, eingebettet im einfachen Ethernet-Netzwerk
Die Topologie des Overlays bildet ein wesentliches Unterscheidungsmerkmal der P2P-Netzwerke untereinander. Sie l¨asst sich grob in strukturiert und un- strukturiert einteilen. Bei strukturierten P2P-Netzen wie CAN [66], Chord [76], Tapestry [87] und Pastry [68] geht es in erster Linie darum, das Routing zu den gesuchten Inhalten bzw. Knoten zu optimieren. So setzt CAN [66] auf eine Zonenaufteilung des kartesischen Adressraums. Chord [76] bedient sich einer Ringtopologie, mit einigen Links zu weit entfernten Peers. Tapestry [87] und Pastry [68] setzen auf einen aufwendigen Routingalgorithmus, in der Absicht den gesuchten Knoten oder einen seiner Nachbarn, m¨oglichst schnell zu errei- chen. In allen F¨allen wird die Zieladresse, als Maß der Entfernung genommen.
Bei unstrukturierten Netzwerken wie Freenet [11], Gnutella [5] werden die Routings dynamisch, zu Laufzeit aufgebaut. In vielen F¨allen entstehen dabei Small-World-Netzwerke [42].
Die Zentralisierung ist ein weiteres Unterscheidungsmerkmal. Die P2P-Netze lassen sich grob unterteilen in zentralisiert, dezentral und hybrid. Bei dezentralen P2P-Netzwerken sind alle Peers absolut gleichberechtigt. Typische Beispiele hierf¨ur sind freenet [11] und Gnutella[72]. Bei zentralisierter L¨osung existieren im P2P-Netz Peers, die exklusiv spezielle Aufgaben ausf¨uhren k¨onnen. Beispiel
hierf¨ur ist das Napster-Projekt [72]. Hierbei melden sich die einzelnen Peers an einem Superpeer an. Alle Suchanfragen laufen ¨uber die Superpeers. Bei hybriden L¨osungen erf¨ullen Superpeers zus¨atzlich noch Aufgaben von einfachen Peers.
Der Aufbau des Overlays hatte immer den Zweck, die Dienste des P2P- Netzwerks zu erlauben bzw. weiter zu optimieren. Der wichtigste Dienst ist die Informationsr¨uckgewinnung (engl. Information Retrieval (IR)). Ein Benutzer sucht im P2P Inhalte, Dokumente bzw. Peers, die diese Dokumente anbieten.
Das Gnutella-Overlay [5] ist eine unstrukturierte Topologe, die sich nicht an Inhalten der Peers orientiert. Der Benutzer ist gezwungen einen Broadcast uber das Overlay abzusetzen. Der Nachteil vom Broadcast, in einem Netzwerk¨ unbekannter Gr¨oße, ist die unvorhersagbare Dauer und die Unzuverl¨assigkeit der Ergebnisse. Der Benutzer weiß nie, ob alle relevanten Peers erreicht wurden.
Der weitere Nachteil ist das Fluten des Netzwerks. Ripeanu [67] identifizierte 95% des Verkehrs in Gnutella als laufende Suchanfragen.
Weitere Entwicklungen in diesem Bereich haben st¨arker die Inhalte der Do- kumente der Peers in den Aufbau des Overlay-Netzwerks einbezogen. Damit bestimmten die Inhalte eines Peers seine Platzierung im Overlay-Netzwerk.
Je ¨ahnlicher die Inhalte der bereitgestellten Dokumente waren, desto n¨aher wurden die Peers zueinander im Overlay platziert. Damit musste der Dienst der Informationsr¨uckgewinnung aus der Suchanfrage des Benutzers, eine Adresse im Overlay-Netzwerk berechnen. Lediglich der Peer an der Adresse bzw. in seiner Nachbarschaft kamen als Suchziele in Frage. Die Vertreter dieser Methode bilden typischerweise ein Overlay der strukturierten Topologie (Ring, Baum, Gitter).
So bildet Chord [76] einen ringf¨ormigen Overlay, mit einigen Abk¨urzungen (Fingers). Den Peers wird ein Adressbereich zugeordnet, welcher am besten ihren Inhalten entspricht. Hierf¨ur m¨ussen die Peers beim Betreten des Overlays, einen Hash-Wert ¨uber ihre Inhalte bilden. F¨ur eine Suchanfrage in diesem Netz muss aus den Suchbegriffen ein Hash-Wert gebildet werden. Die Suchoperation f¨angt an einem bel. Peer an und navigiert zu dem Abschnitt des Rings, der
2.1 Klassische P2P-Netze
den wenigsten Abstand zu dem Hash-Wert der Suchanfrage hat. Weit entfernte Bereiche k¨onnen mittels Abk¨urzungen schnell erreicht werden.
CAN (content-addressable network) [66] bildet einen mehrdimensionalen, kar- tesischen Raum anstatt des Rings. Die Peers sind verantwortlich f¨ur die Pflege von einem Raum-Ausschnitt. Dieser Raum-Ausschnitt wird jedem Peers beim Betreten des Netzwerks zugewiesen. Knoten, die ihre Dateien anbieten wollen, generieren eine Adresse im CAN (z.B. Hash-Wert ¨uber den Dateinamen) f¨ur jedes Dokument und platzieren einen Link an der entsprechenden Adresse im CAN-Raum. CAN definiert damit Operationen get (Datei-Download), put (Platzierung von Dokument-Links) und lookup (Suchoperation). Alle Opera- tionen benutzen den mehrdimensionalen kartesischen Raum f¨ur das Routing innerhalb des CAN-Netzwerks.
Bekannte Protokolle sind ebenfalls Tapestry [87] und Pastry [68], beide basieren auf Plaxton [62]. Plaxton [62] definiert ein Overlay zwischen den Peers welches uber Peers verteilte, baumartige Verweise als Pfade zu den Dokumenten enth¨alt.¨ Alle Peers besitzen eine zuf¨allig gew¨ahlte Id. Soll ein Dokument in diesem Netzwerk platziert werden, so wird aus dem Dokument eine Hash-Summe berechnet. Das Dokument bzw. Link auf das Dokument wird auf einem Wurzel- Peer platziert, welcher den kleinsten Abstand seiner Id zu der Hash-Summe des Dokuments besitzt. Ausgehend von dem Wurzel-Peer wird ein virtueller, balancierter Dokumenten-Baum von Knoten ¨uber andere Peers verteilt (ein Konten pro Peer). Es gibt genau einen Dokumenten-Baum pro Dokument. Es k¨onnen auch mehrere Kopien des Dokuments ¨uber die Peers verteilt werden, jede Kopie ist jedoch Teil des ¨uber die Peers gespannten Dokumenten-Baums. Der Sinn hiervon ist es, eine Route zu dem Dokument im P2P-Netzwerk zu gestalten, damit die Such-Operation a) mit Hilfe des Baums schneller an das gesuchte Dokument geleitet werden und b) unterwegs auch auf Kopien des Dokuments trifft, damit das Durchsuchen des Baums bis zum Wurzel-Peer ¨uberfl¨ussig wird.
Tapestry [87] und Pastry [68] adaptieren Plaxton [62] f¨ur Herausforderungen im dynamischen Umfeld, wo Peers der Ab - und Zuwanderung unterliegen.
Weitere L¨osung f¨ur inhaltsbasierten Overlay bietet Neuser [58] an. In seiner Arbeit hat jeder Peer eine Adresse im zweidimensionalen, euklidschen Raum.
Der Peer kennt alle seine direkten Nachbarn im Raum und einige entfernte Peers, damit ist es eine Small-World-Topologie (siehe [42]). ¨Andern sich die Inhalte des Peers, so platziert sich dieser im Overlay neu. Nach physikalischen Analogien der Ladungsanziehung und -abstoßung ziehen sich Peers mit ¨ahnlichen Dokumenten an und stoßen sich ab bei sehr unterschiedlichen Dokumenten.
Bei der Durchquerung des Adressraums, rekonfiguriert der Peer st¨andig seine Verbindungen im Overlay. Verbindungen zu entfernten Peers werden zuf¨allig gel¨oscht, durchquerte Peers, die nicht mehr direkte Nachbarn sind, werden zu entfernten Nachbarn. Eine Operation, die ¨ahnliche Dokumente sucht, ben¨otigt somit nur die direkten Nachbarn eines Peers, um weitere, ¨ahnliche Dokumente zu finden. Entfernte Peers sind nur dann von Interesse, wenn der aktuelle Peer zu weit von Suchkriterien entfernt ist.
Freenet [11] erstellt ein unstrukturiertes Overlay und setzt dabei massiv auf Replikation der Dokumente. Das Hauptanliegen des Freenet ist die komplette Anonymit¨at der Benutzer. Es soll von außen nicht erkennbar sein, wer ein Dokument in das Netzwerk platziert hat und wer darauf zugegriffen hat. Dazu wird ein Dokument bei der Platzierung in das Netzwerk zerteilt und ¨uber mehrere Peers verteilt. Teile des Dokuments liegen mehrfach verteilt, ¨uber verschiedene Peers. Je ¨ofter auf ein Dokument zugegriffen wird, desto ¨ofter werden seine Teile im Netzwerk repliziert. Die Zugriffe auf beliebte Dokumente sind daher schneller. Unbeliebte, selten benutzte Dokumente, verschwinden nach und nach aus dem Netz. Jeder Peer speichert Teile seiner gelesenen Dokumente lokal. Da der Speicherplatz begrenzt ist, l¨oscht jeder Peer selten genutzte Teile der Dokumente. Damit implementiert Freenet neben der Such-/
Platzierungs-Operationen eine Vergessen-Operation.
Alle besprochenen Overlays (Chord [76], CAN [66], Tapestry [87] und Pastry [68], Plaxton [62], Freenet [11]) versuchen die Kosten der Informationsr¨uckgewinnung zu minimieren. Einige, wie Plaxton [62], ber¨ucksichtigt ebenfalls die lokal genutzten Ressourcen der Peers. Die Minimierung der Kosten f¨ur Informa- tionsr¨uckgewinnung wird entweder durch ein optimaleres Routing zwischen den Peers oder Replikationen erreicht. Im ersten Fall muss die Suchoperation weniger Peers besuchen, da das Overlay entsprechend strukturiert ist. Bei Replikationen, wie bei Plaxton [62], werden mehrere Kopien des Dokuments im
2.1 Klassische P2P-Netze
Overlay platziert, so dass die Suchoperation dadurch schneller abgeschlossen werden kann. Freenet [11] arbeitet ebenfalls mit Replikationen, dieser optimiert insbesondere Suchoperationen f¨ur beliebte Dokumente. Insgesamt l¨asst sich diese Art der Optimierung als Reduzierung der Anzahl von zu besuchenden Peers umschreiben.
2.1.2 Methoden des Lastenausgleichs
Weitere Ans¨atze der Optimierung der Operationen setzen auf eine faire Lastver- teilung zwischen den beteiligten Knoten. Die Idee dahinter: ist jeder beteiligte Peer etwa gleich belastet, so reduziert dies die Antwortzeit der Operationen, denn keine der ankommenden Operationen muss auf frei-werdende Ressour- cen warten. Im P2P-Umfeld wird hier von virtuellen Servern gesprochen ([65]
,[84],[88],[64],[82]).
Ein virtueller Server abstrahiert einen Peer, die verwalteten Regionen des P2P-Overlays werden nicht mehr fest einem Peer zugeordnet, sondern einem virtuellen Server. Die Zust¨andigkeitsbereiche im Overlay der virtuellen Server k¨onnen klein gew¨ahlt werden, so dass ein Peer mehrere virtuelle Server halten kann. Dies f¨uhrt nun zu der M¨oglichkeit virtuelle Server zwischen Peers zu verschieben, d.h. die Overlay-Zust¨andigkeitsbereiche k¨onnen zwischen Peers wandern.
So schl¨agt Bienkowski [2], f¨ur den Lastausgleich zwischen Peers, einen vollst¨andig dezentralen Algorithmus vor. Wobei hier periodisch die Overlay- Zust¨andigkeitsbereiche f¨ur alle Peers, im gesamten Netzwerk neu verteilt werden, mit dem Ziel jedem Peer die gleiche L¨ange vom Overlay-Zust¨andigkeitsbereich zuzuweisen.
Ein ¨ahnlicher Ansatz wird auch durch Vu [82] favorisiert. Hier werden die globalen Lastinformationen durch jeden Peer gepflegt. Hierf¨ur wird das gesamte Overlay in nicht-¨uberlappende Gruppen strukturiert. Die Peers halten damit nur die Last-Informationen der ihnen bekannten bzw. verbundenen Gruppen.
Vu [82] nutzt diese, um nun die Last zwischen den Peers so zu verschieben, dass die Auslastung der Peers sich ausgleicht.
Qiao [64] besch¨aftigt sich ebenso mit dem Lastausgleich in den P2P-Netzwerken.
In seiner Arbeit [64] werden Methoden des Lastausgleichs, bekannt aus dem Grid-Computing-Umfeld, auf die P2P-Netzwerke ¨ubertragen. Hier wird der Gradientenfeld-Ansatz (siehe 2.2.1) verfolgt, so dass die Peers lediglich die Lastinformationen seiner lokalen Nachbarschaft kennen m¨ussen und keine globalen Lastinformationen ben¨otigen. Auch hier wird das Ziel verfolgt, die durchschnittliche Antwortzeit der Anwendung zu verbessern, indem die Peer- Belastung systemweit angeglichen wird.
2.1.3 Reduzierung der Latenzen
Die vorhergehenden Verfahren haben entweder das Overlay so optimiert, dass die Operationen schneller zum gew¨unschten Inhalt navigiert haben oder die durchschnittliche Peerbelastung so reduziert, dass jeder Peer ann¨ahernd gleich ausgelastet war. Damit erhoffte man ebenfalls die Antwortzeit der Operationen zu verbessern. Beides, die Overlay-Gestaltung und die Lastausgleichsprozeduren, erfordern jedoch einen nicht zu vernachl¨assigbaren Rechen- und Kommunikati- onsaufwand.
Der Kommunikationsaufwand wird beeinflusst a) durch die verf¨ugbare Band- breite und b) durch die Signallaufzeit (Latenz). Beides beeinflusst die RTT 1 zwischen zwei Peers. Gelingt es diese zu reduzieren, k¨onnen weitere Verbesse- rungen der Antwortzeiten von Operationen erreicht werden.
Dieses Problem wurde durch Dabek [14] in Vivaldi angegangen. Dabek [14]
schl¨agt ein Adressierungssystem der Peers im Overlay vor, so dass aus den Adressen auf die Antwortzeit zwischen zwei Peers geschlossen werden kann.
Haben zwei Peers einen großen Abstand in dem Adressierungssystem, so ha- ben diese auch eine hohe Round-Trip-Time. Damit muss keine Messung der Bandbreite etc. stattfinden. Allein die Kenntnis der Adresse ist ausreichend.
1Round-Trip-Time: Signallaufzeit von Quelle zu Senke und zur¨uck
2.1 Klassische P2P-Netze
Die Ergebnisse der Arbeit sind a) eine einfache, dreidimensionale, euklidische Adresse (mit H¨ohe), die es erlaubt auf die RTT zu schließen und b) die RTT h¨angt in erste Linie von dem geographischen Abstand der Peers ab, jedoch wird die Erde nicht vom Internet-Kern umschlossen. Mit dieser Definition kann nun ein Peer immer den Peer, mit dem kleinsten Abstand aus Vivaldi-Adressraum w¨ahlen, um so die Operationsdauer zu minimieren.
2.1.4 Gestaltung der Operationen
In vorhergehenden Kapiteln wurden die Operationsoptimierungen durch ent- sprechende Overlay-Topologien, Lastausgleichsmethoden und Latenzreduzie- rung, durch entsprechende Adress-Gestaltung des Overlays, beleuchtet. Weitere M¨oglichkeiten f¨ur Optimierungen befinden sich innerhalb der dezentralen An- wendung. Hierbei werden die Operationen so ausgepr¨agt, dass diese aus der Kenntnis oder Sch¨atzung der vorliegenden Daten, ihre Ausf¨uhrungsdauern reduzieren k¨onnen. Auf Basis der P2P-Netzwerke wurde die sogn. Linked Open Data-Initiative entwickelt. Diese stellt einen großen Datensatz dezentral, aber zug¨angig f¨ur Abfragen durch Benutzer bereit. Repr¨asentativ f¨ur viele dezentrale Anwendungen, werden die Optimierungen von Operationen in Linked Open Data-Initiative untersucht.
Folgendes Beispiel ist charakteristisch f¨ur die Linked Open Data-Initiative. Es existieren große Datens¨atze von entschl¨usselten Krebsgenomen. Auch wenn diese ¨offentlich zug¨angig sind, ist deren Auswertung jedoch f¨ur Außenstehende kaum m¨oglich, aufgrund vom propriet¨aren Datenformat [69]. Mit Hilfe von Linked Data werden diese Datens¨atze a) der Allgemeinheit im einfachen Format zur Verf¨ugung gestellt und b) mit anderen Datens¨atzen in Beziehung gesetzt.
In diesem konkreten Beispiel ([69]) findet eine Verlinkung mit Publikationen statt, die auf entsprechende Krebsgenome-Daten zugreifen.
Die wesentlichen Elemente der Linked Open Data sind a) die Verlinkung der Daten [31] und b) eine Abfragesprache [30] f¨ur die Daten. Die Verlinkung basiert auf RDF (Resource Description Framework), in unterschiedlichen Darstellungs- sprachen (oft als XML). Ein RDF-Knoten besteht aus einem Tripel aus Subjekt,
Pr¨adikat und Objekt. Es stellt zwei Ressourcen (Subjekt und Objekt) mit- einander in Beziehung (Pr¨adikat). Folgend dem oberen Krebsgenome-Beispiel ist damit folgende Aussage m¨oglich: ”Genom A”(Subjekt) ”wird erw¨ahnt in”(Pr¨adikat) ”Dokument Z”(Objekt). Die Ressourcen werden durch URIs (Uni- form Resource Identifier) beschrieben. Dadurch ist eine rechner¨ubergreifende Verlinkung der Daten m¨oglich. RDF-Knoten werden dezentral, von mehreren Benutzern verwaltet, daher ist es m¨oglich, dass f¨ur ein Objekt mehrere solche Beschreibungen existieren. So kann eine Person mehrere RDF-Knoten in Lin- ked Open Data besitzen, angelegt durch seinen Arbeitgeber, seine Schule, die staatlichen Organe, usw.. .
SPARQL stellt eine Abfragesprache f¨ur die Linked Open Data dar. Mit dieser kann ein Benutzer Abfragen auf den Daten formulieren. Folgend dem oberen Beispiel : Bestimme alle Dokumente, die das Genom Z erw¨ahnen (SELECT Document WHERE {Document mentions Genom A}). Die typischen Schritte der Abarbeitung der Anfrage sind die Zusammenstellung der Angefragten Ressourcen, Filterung und Zusammenfassung der Ergebnisse und eventuelles Ranking. RDF und SPARQL stellen Grundlagen f¨ur die Operationen auf den Linked Open Data.
Wie auch in anderen verteilten Systemen, leiden die Operationen hierbei unter mangelnder zeitlicher Effizienz. Die Abfrageoperationen stehen vor dem Problem einer effizienten Suche von Daten, verteilt ¨uber viele Ressourcen auf vielen Rechnern. Neben der unbekannten Datenmenge und Anzahl der betroffenen Rechner, spielen hier auch die Kommunikationseigenschaften eine wesentliche Rolle. Die Kommunikationseigenschaften der Rechner k¨onnen nicht beeinflusst werden. Es kann jedoch die Operation an sich optimiert werden indem a) nur auf lokale, vorher gesammelte Daten zugegriffen wird oder b) durch Optimierung der Ausf¨uhrung der SPARQL - Anweisung [79] indem die Anzahl der befragten, entfernten Rechner minimiert wird. Zwischen diesem beiden Extrema existieren diverse Abstufungen mit hybriden L¨osungen, die einen minimalen lokalen Index der entfernten Rechner aufbauen. Im zweiten Fall bleibt die Aktualit¨at der Daten besser gew¨ahrleistet, w¨ahrend im ersten Fall oft bessere Effizienz erreicht wird. Vor einem ¨ahnlichen Problem stehen auch die Suchmaschinen des World Wide Web. Der Zugang zu entfernten Ressourcen ist immer ineffizienter als der
2.1 Klassische P2P-Netze
lokale Zugriff. Daher erstellen die WWW-Suchmaschinen ein lokales Abbild des WWW, ein Index, welches effektiv zug¨angig ist und f¨ur die Benutzerabfragen eingesetzt wird. Bessere Aktualit¨at der Daten gew¨ahrleisten jedoch dezentrale WWW-Suchmaschinen ([46],[21]). Es folgen einige konkrete Arbeiten aus dem Umfeld von Linked Open Data.
Cheng und Qu[6] entwickelten eine zentralisierte Suchmaschine f¨ur RDF-Knoten f¨ur Linked Open Data. Sie sammelt alle g¨ultigen RDF-Knoten durch zyklischen Abfragen von bekannten Quellen, folgt den im RDF-Knoten angegebenen Ressourcen und speichern deren virtuelle Dokumente (d.h. eine Beschreibung des Inhalts des RDFs). Der Benutzer kann nun mit Hilfe von Stichw¨ortern nach RDF-Knoten, in komplett zentralisierter Art ¨uber eine Web-Oberfl¨ache, suchen.
Hierbei wird nicht die SPARQL- Abfragesyntax eingesetzt, sondern lediglich reine Stichwortsuche.
Schwarte [74] setzt in seiner L¨osung FedX auf eine direkte Abfrage der Quel- len zur SPARQL-Abarbeitung. Es wird ein Verfahren beschrieben, um die SPARQL-Anfrage so zu verarbeiten und gruppieren, dass die Anzahl der Zu- griffe auf entfernte Rechner minimiert wird. Damit wird die zeitliche Effizienz der Anfrageverarbeitung verbessert. Auf den lokalen Systemen steht eine Liste aller m¨oglichen Quellen mit RDF-Objekten zur Verf¨ugung. Zu jeder SPARQL- Anfrage wird aus dieser Liste eine Untermenge von Quellen gebildet, die dem Endergebnis beitragen k¨onnen. Dazu wird jede Quelle im Vorfeld einzeln ange- fragt. Im Zweiten Schritt wird die gestellte SPARQL-Anfrage ausgef¨uhrt. Dazu wird eine heuristisch basierte Abfragereihenfolge der Quellen festgelegt. Damit werden Mehrfach-Anfragen einer Quelle durch eine gruppierte Einzelabfrage ersetzt.
Umbrich [79] setzt in in seiner Arbeit auf einen hybriden Ansatz, indem die Abarbeitung der SPARQL-Anfrage erst die lokal gehaltenen Daten inspiziert und daraufhin Entscheidung f¨ur den Zugriff auf die entfernten Ressourcen trifft. Die betroffenen Ressourcen werden hier von der anfragenden Instanz einzeln angefragt und verarbeitet. Das Ergebnis der SPARQL-Anfrage wird am Ende, aus den gelesenen Ressourcen, zusammengestellt. D.h. die entfernten Rechner sind nicht in der Lage Teile der SPARQL-Anfrage vorzuverarbeiten
und somit nur die relevanten Teilergebnisse zur¨uckzugeben. Die lokal gehaltenen Daten beschreiben die Ressourcen von bekannten Quellen. Diese basieren auf sog. multidimensionalen Histogrammen. Damit wird eine Wahrscheinlichkeit angegeben, mit der eine bestimmte Ressource auf dem Zielrechner enthalten ist.
F¨ur die Vorhersage der SPARQL-Ausf¨uhrungzeit setzt Hasan [26] auf eine ma- schinelle Klassifikation der SPARQL-Anfrage. Damit versetzt er den Benutzer in die Lage, mit Hilfe der vergangenen Anfragen, auf die Ausf¨uhrungszeit der aktuellen Anfrage zu schließen. Damit ist zumindest eine manuelle Anpassung der SPARQL-Anfrage m¨oglich, vor der eigentlichen Ausf¨uhrung. Joshi [37]
pr¨asentiert in seiner Arbeit ein Verfahren, welches die SPARQL-Abfragen da- hingehen optimiert, dass die Strukturen der angefragten Quellen ber¨ucksichtigt werden und die SPARQL-Anfrage des Benutzers auf die konkreten Formate der Quellen angepasst wird. Dadurch wird der Benutzer davon entlastet, den genau- en Kontext der RDF-Eintr¨age der Quelle zu kennen und bekommt dennoch gute Ergebnisse zu seiner Anfrage. Damit sind, neben der Performance der Abfragen, auch die Formate der verlinkten Ressourcen hinter den RDF-Objekten eine weitere Herausforderung. Einige Arbeiten (Karataev [38]) besch¨aftigen sich mit diesem Problem der sogn. Datenintegration.
2.2 Grid- und Cloud-Computing
Die Grid-Umgebungen gehen davon aus, dass es im System mehrere Tasks und Prozessoren gibt. Das Problem hierbei ist die Platzierung einer Task innerhalb des Grids (Zuweisung zu einem Prozessor), so dass diese m¨oglichst schnell, ohne Unterbrechungen abgearbeitet werden kann.
F¨ur den reinen Lastausgleich wird davon ausgegangen, dass die Task alles notwendige f¨ur ihre Ausf¨uhrung auf dem Prozessor vorfindet. Tasks haben keine Abh¨angigkeiten zu anderen Tasks, d.h. diese k¨onnen atomar, f¨ur sich selbst ausgef¨uhrt werden. Die Verfahren des Lastausgleichs k¨onnen einerseits nach Zentralit¨at (zentral, dezentral), andererseits nach Dynamik (dynamisch,
2.2 Grid- und Cloud-Computing
statisch) unterschieden werden. Die Zentralit¨at legt fest, ob es eine zentrale Instanz gibt, die f¨ur jede Task die Entscheidung ¨uber die Zuweisung zu einem Prozessor ¨ubernimmt. Die Dynamik entscheidet dar¨uber, ob die Reihenfolge und Ressourcenbedarf der ankommenden Tasks bekannt ist und daher vorher geplant werden kann (statisch) oder eine dynamische Zuweisung bei unbekanntem Ressourcenbedarf stattfinden muss.
Einige Autoren haben jedoch auch erkannt, dass die Tasks nicht immer un- abh¨angig voneinander agieren k¨onnen und die h¨aufige Verschiebung von Tasks zwischen Prozessoren ihre Ausf¨uhrungszeit negativ beeinflusst. Damit m¨ussen auch hierbei entstehenden Kommunikationskosten in Betracht gezogen wer- den.
Die folgenden zwei Abschnitte widmen sich nun den Themen a) des Lastaus- gleich bei atomaren Tasks und b) Reduzierung der Kommunikationskosten w¨ahrend der Ausf¨uhrung der Task.
2.2.1 Methoden des Lastenausgleich
Zentralisierte Ans¨atze der Lastverteilung sind f¨ur dezentrale Anwendungen, mit st¨andig wechselnden, heterogenen Community-Teilnehmern nur schwer umsetzbar. Kein Teilnehmer der Community kann von einer vollst¨andigen und aktuellen Datenbasis der Community-Teilnehmern und ihrer Ressourcen ausgehen. Daher sind hier dezentrale Methoden der Last-Verteilung vom hohem Interesse. Hierbei nutzt jeder Teilnehmer nur einen Ausschnitt der global verf¨ugbaren Daten. Physikalische und biologische Systeme der Natur basieren auf diesen Gedanken. Fr¨uhere Forschung hat diese Ans¨atze untersucht und in technische L¨osungen ¨uberf¨uhrt.
Physikalisch inspirierte Methoden
Die physikalisch inspirierten Methoden ahmen die bekannten Ph¨anomene bei thermodynamischem oder mechanischem Ungleichgewicht nach. Die physikali-
schen Systeme versuchen die Ungleichgewichte immer auszugleichen, entweder durch W¨armefluss, K¨orperbewegung oder auf molekularer Ebene, durch Diffu- sion. Das Bild 2.2 stellt die Diffusion in Fl¨ussigkeiten dar. Ein neu hinzugekom- mener Stoff verursacht zun¨achst ein Ungleichgewicht der Teilchen-Verteilung in der Fl¨ussigkeit. Auf Grund der Brownschen Bewegung aller Teilchen in der Fl¨ussigkeit, stellt sich nach einer Zeit eine Gleichverteilung aller Teilchen in der Fl¨ussigkeit wieder ein. Das Ungleichgewicht bei Grid-Umgebungen ergibt sich aus unterschiedlicher Prozessor-Auslastung. Es werden einige konkrete Verfah- ren aus diesem Umfeld besprochen. Alle haben das Ziel die Prozessorbelastungen anzugleichen und ein Gleichgewicht herzustellen.
Abbildung 2.2: Diffusion in Fl¨ussigkeiten, Quelle: [80]
Hu und Blake [33] definierten eine Methode f¨ur hybriden Ansatz (mit zen- tralisierten dynamischen/statischen Elementen) f¨ur Lastausgleich, bei einer Anwendung der Finite-Element-Berechnung(PDE). Damit muss eine Last, be- stehend aus einem Graphen von Finiten-Elementen, auf einen Graphen von Prozessoren so verteilt werden, dass jeder Prozessor etwa ¨ahnliche Anzahl von Finiten-Elementen erh¨alt. Die initiale Aufteilung der Finiten-Elemente findet statisch statt, nach bekannten Methoden f¨ur Graph-Partitionierung [40].
W¨ahrend der Simulation wird der PDE-Graph ungleichm¨aßig verfeinert, d.h.
die Anzahl der PDE-Knoten steigt an einigen Stellen an und dies f¨uhrt zur ungleicher Prozessorbelastung. Eine erneute Re-Partitionierung des gesamten PDE-Graphen ist kostspielig, da die neue L¨osung eine Neuplatzierung aller PDE-Knoten erforderlich machen wird. Hu und Blake [33] schlagen hierf¨ur
2.2 Grid- und Cloud-Computing
ein zentralisiertes, dynamisches Task-Zuweisungsverfahren vor, basierend auf der Diffusion. Ein hoch belasteter (heißer) Prozessor gibt seine Last an unter- belastete (k¨uhlere), benachbarte Prozessoren ab. Die Last wird somit auf die benachbarte, k¨uhlere Prozessoren abgeleitet, ¨ahnlich wie bei der Tempera- turkompensation in Festk¨orpern. Ziel hierbei ist es, die Last der Prozessoren anzugleichen, bei gleichzeitiger Minimierung der Migrationen-Anzahl der PDE- Knoten. Interessant an dieser Problemstellung ist der Aufbau der Last, der PDE-Graph. Dieser entspricht im Grundsatz der Verwaltungsstruktur, wie bei dezentralen Anwendungen, betrachtet in dieser Arbeit. Da jedoch hierbei eine zentralisierte L¨osung umgesetzt wurde, ist diese, im dezentralem Umfeld ohne Anpassungen, nicht einsetzbar. Die initiale Partitionierung vom PDE-Graph, als auch sp¨atere Verschiebe-Entscheidungen der Knoten auf neue Prozessoren, werden zentral mit der globalen Sichtweise getroffen. Dieser Ansatz l¨asst sich jedoch in einer dezentralen Weise umsetzen, was auch durch den folgenden Gradientenfeld-Ansatz bewiesen wird.
Lin and Keller[49] entwickelten ein vollst¨andig dezentrales, dynamisches Modell der Taskzuweisung zum Prozessor. ¨Ahnlich dem W¨armefluss in Stoffen, fließen hier Tasks von ¨uberlasteten zu unterlasteten Prozessoren. Hierzu wird ein Gradientenfeld ¨uber die vorhandenen Prozessoren gebildet, basierend auf dem Lastzustand der Prozessoren. Die Lastzust¨ande unterscheiden zwischen leicht, moderat und schwer. Den aktuellen Zustand meldet jeder Prozessor an seine Nachbarn. Wobei hier keine Beschr¨ankungen an die Verschaltung bzw. Topologie der Prozessoren gestellt werden. Damit ist jeder Prozessor in der Lage die Richtung des unter-lasteten Prozessors zu bestimmen. Das Gradientenfeld ist somit eine verteilte Routing-Tabelle f¨ur Tasks, die vom ¨uberlasteten Prozessor in Richtung unter-lasteten Prozessors fließen. Diese L¨osung betrachtet die Tasks ebenfalls als atomar, d.h. diese finden alle ben¨otigten Ressourcen vor Ort, an jedem Prozessor und ben¨otigen keine Kommunikation zu anderen Tasks. Im Gegensatz zu typischen Grid-Umgebungen, wird hier auch vom heterogenem Umfeld ausgegangen. D.h. die Prozessoren k¨onnen unterschiedliche Anzahl an Ressourcen vorhalten.
Ein weiterer physikalisch-inspirierter Ansatz wurde durch Heiss and Schmitz [28] entwickelt. Dieser ist ebenfalls dynamisch und dezentral, basiert jedoch
auf Kr¨aften, wie diese bei physikalischen Systemen auftreten. Auf jede Task des Systems wirken drei wesentliche Kr¨afte ein. Zum einen die anziehende Kommunikationskraft. Diese tritt zwischen zwei Tasks auf, wenn diese mitein- ander kommunizieren m¨ussen. Diese Kraft ist proportional zur ausgetauschten Datenmenge. Eine weitere ist die Lastausgleichskraft, diese wirkt auf eine Task wenn die Potentiale der benachbarten Prozessoren unterschiedlich sind.
Als Potential wird hier die Menge der freien Ressourcen des Prozessors ange- nommen. Befindet sich eine Task auf einem ¨uberlasteten Prozessor (niedriges Potential), so wird diese von einem unterlasteten Prozessor(hohes Potential) angezogen. Die dritte ist die D¨ampfungskraft. Diese wirkt auf eine Task von ihrem aktuellen Prozessor ein. Hierdurch wird Task an einer Migration zum benachbarten Prozessor gehindert. Damit wirkt die D¨ampfungskraft entgegen- gesetzt der Kommunikationskraft und der Lastausgleichskraft. Hierdurch wird ein Oszillieren der Tasks zwischen Prozessoren verhindert. Heiss and Schmitz [28] setzen nicht nur auf Dezentralit¨at, sondern ber¨ucksichtigen auch die Kom- munikationskosten zwischen den Tasks. Der jeweilige Prozessor muss lediglich die Lastinformationen mit seinen direkten Nachbarn austauschen. Es wird keine zentrale Instanz f¨ur die Organisation des Lastausgleichs ben¨otigt.
Biologisch inspirierte Methoden
Mit Schwarm-Intelligenz wird das Verhalten von dezentralen, selbst- organisierenden Einheiten bezeichnet, die in der Summe das Optimum f¨ur die Gruppe erreicht. Obwohl jede Einheit wenigen, trivialen Regeln folgt, wird in der Gesamtheit jedoch ein ¨außerst komplexes Verhalten bewirkt (siehe Con- way’s Game of Life). Eric Bonabeau hat in seinem Buch ’Swarm intelligence’
[3] viele Beispiele f¨ur erfolgreiche, selbst-organisierende, dezentrale Systeme gebracht. Ameisen, Wespen, Bienen haben f¨ur sich selbst einfache Regeln entwickelt, die im Einzelfall trivial sind, in der Summe angewendet helfen jedoch der gesamten Kolonie (dem Schwarm) zu ¨uberleben. So hinterlassen Ameisen eine Duftspur zur Nahrungsquelle. Duftspur verliert mit der Zeit an Intensit¨at. Folgen weitere Ameisen dieser Spur, wird diese erneuert und dadurch intensiver. Ist ein Pfad lang und entsprechend selten erneuert, wird
2.2 Grid- und Cloud-Computing
dieser von wenigen Ameisen benutzt. Sie weichen auf intensiver markierte Pfade aus. Dieses Vorgehen sorgt daf¨ur, dass die Ameisen nach und nach den k¨urzesten Pfad zur Nahrungsquelle finden. Mit AntSim 1 als Werkzeug lassen sich Ameisen-Kolonien bei der Futtersuche simulieren. Siehe hierzu das Bild 2.3. Hierbei sieht man einen Algorithmus, der nach dem oberen Muster arbeitet. Dieser findet in einer vollst¨andig dezentralen Weise einen Weg durch das Hindernis zur Futterquelle. Mit dem Schritt 0 werden hier die Ameisen aus dem Nest entlassen. Diese beginnen ihre Umgebung zu erkunden. Nach ca. 3126 Simulationsschritten ist eine stabile Duftspur vorhanden, so dass die meisten Ameisen dieser zur Futterquelle folgen. Einige neuere Arbeiten auf dem Gebiet der Lastbalancierung f¨ur Grid-Computing haben auf diesen bzw.
¨ahnlichen Ideen aufgesetzt.
(a) Schritt 0 (b) Schritt 9 (c) Schritt 546
(d) Schritt 3126
Abbildung 2.3: AntSim-Simulation einer Ameisenkolonie
1AntSim v1.1,Quelle: http://www.nightlab.ch/antsim.php (2019)
Wenn Ameisen Objekte gleichm¨aßig verteilen wollen, so verh¨alt sich jede einzel- ne nach folgendem Muster: a) wenn sie kein Objekt tr¨agt, wandert sie zuf¨allig herum, bis sie auf ein Objekt trifft und es aufnimmt; b) wenn eine Ameise ein Objekt tr¨agt, l¨asst sie es erst fallen, nachdem sie ’f¨ur eine Weile’ zuf¨allig herumgelaufen ist, ohne auf andere Objekte zu treffen. Dieses Prinzip wird durch Messor [56] angewendet, um im Grid-Computing-Umfeld die beteiligten Prozessoren gleichm¨aßig auszulasten. Hierzu wird eine Aufgabe in mehrere un- abh¨angige, atomare Tasks zerteilt und auf einem initialen Prozessor platziert. In diesem Netzwerk existieren mehrere Ameisen, die st¨andig ¨uber die Prozessoren wandern. Trifft eine Ameise auf einen ¨uberlasteten Prozessor, so merkt sie sich dessen Adresse und setzt ihre Wanderung fort, bis ein unterlasteter Prozessor gefunden wird. Die Wanderung der Ameisen geschieht hier nicht ganz zuf¨allig.
Vielmehr sammelt jede Ameise auf ihrem Weg die Lastinformationen einzelner Prozessoren und hinterl¨asst ihre gesammelten Daten in den Prozessoren f¨ur andere Ameisen, als eine Art Duftspur zu unter- oder ¨uberlasteten Prozessoren.
Ob nun ein Knoten als ¨uber-oder unterlastet eingestuft wird, wird anhand der vorher gesammelten Lastinformationen entschieden.
Die ameisenbasierte Taskzuweisung in Messor [56] hat den Nachteil, dass die Ameisen lange leben und daher ein Kommunikationsaufwand besteht, auch wenn keiner der Prozessoren ¨uberlastet ist. Salehi [70] l¨ost das Problem indem die Lebensdauer der Ameisen begrenzt wird bzw. die Anzahl der im System vorhandenen Ameisen an den ¨Uberlast-Zustand angepasst wird. Wenn viele Prozessoren ¨uberlastet sind, werden mehr Ameisen erzeugt. Die Lebenszeit der Ameise h¨angt ab von der Anzahl durchgef¨uhrter Migrationen zwischen den Prozessoren. Diese bestimmt essentiell die Anzahl lebendiger Ameisen und somit die Menge der Kommunikation im Netzwerk. Salehi [70] zeigt ein Verfahren, das die Lebenszeit der Ameise begrenzt, bei dennoch fairen Taskzu- teilung. Wie auch bei Messor [56], sammeln die Ameisen die Lastzust¨ande der besuchten Prozessoren. Beim Besuch eines ¨uberlasteten Prozessors kann die Ameise ein Zuweisungsziel f¨ur die Tasks des ¨uberlasteten Prozessors vorschlagen.
Treffen sich zwei Ameisen auf einem Prozessor so, im Gegensatz zu Messor, findet der Austausch der Lastinformationen direkt statt. Damit bekommt jede Ameise einen gr¨oßeren ¨Uberblick ¨uber den Gesamt-Lastzustand des Grids, mit
2.2 Grid- und Cloud-Computing
gleichzeitig reduziertem Kommunikationsaufwand.
Aber nicht nur das Verhalten von Insekten, sondern auch epidemische Ans¨atze wurden untersucht. Hierbei handelt es sich um Verfahren, die der Ausbreitung von Krankheiten in einer Individuen-Gruppe nachempfunden sind. Menon [55]
schl¨agt ein weiteres dynamisches, dezentrales Verfahren der Task-Zuweisung zum Ausgleich der Prozessorauslastungen, in einer festen Grid-Umgebung vor.
In einer statischen Grid-Umgebung (Großrechner) m¨ussen Tasks so zugeordnet werden, dass alle Prozessoren ann¨ahernd gleich ausgelastet sind. Die ¨uberladenen Prozessoren f¨uhren die Zuweisung eigenst¨andig aus. Hierzu ben¨otigen sie die Adressen von unterlasteten Prozessoren. Daf¨ur verteilen die unterlasteten Pro- zessoren ihren Lastzustand und Adresse im gesamten Grid, mit dem Ziel, dass jeder ¨uberlastete Prozessor mind. einen unterlasteten Prozessor kennt. F¨ur die Verteilung der Lastinformationen w¨ahlen die Prozessorenf zuf¨allige Prozessoren aus dem Grid-System und infizieren diese mit ihren Lastinformationen. Die Infi- zierten wiederum infizierten weitere Prozessoren. Mit dem Ziel die ¨uberlasteten Prozessoren zuerst mit neuen Lastinformationen zu versorgen, werden f¨ur die Weiterleitung der Lastinformationen nicht die lokal bekannten, unterlasteten Prozessoren verwendet. Ebenso wie die Verteilung der Lastinformationen, wird die Taskzuweisung stochastisch durchgef¨uhrt. Der ¨uberlastete Prozessor weist mit der h¨ochsten Wahrscheinlichkeit dem Prozessor, mit der niedrigsten Last seine Tasks zu. Auch Menon [55] geht in seiner Arbeit von atomaren Tasks aus, jedoch sind sie auf Ergebnisse anderer Tasks f¨ur die Fertigstellung angewiesen.
Die platzierten Tasks repr¨asentieren Teile einer großen Aufgabe. Die Tasks sind hierarchisch strukturiert und kommunizieren nur mit ihren Eltern- oder Kinder-Tasks.
2.2.2 Reduzierung der Kommunikationskosten
Die hierarchische Task-Strukturierung ist anscheinend in der Lage die Kom- munikationsaufw¨ande zwischen den Tasks deutlich zu reduzieren. Hasanov [27] zeigt ein Verfahren, wie aus der Anwender-Sicht die Tasks sich hierar- chisch strukturieren lassen. Im Umfeld des Grid-Computing wird MPI [32]
