Untersuchungen der Skalierbarkeit eines P2P
Werbung
––– Untersuchungen der Skalierbarkeit eines P2P-basierten verteilten Rechensystems. Bachelorarbeit Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik Vorgelegt von: Benjamin Kappel Matrikelnummer: 210204477 Betreuer: Dr.-Ing. Peter Danielis, M.Sc. Jan Skodzik Prof. Dr. Dirk Timmerman Abgabedatum: 31.03.2014 Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation Inhaltsverzeichnis A. Abbildungsverzeichnis ....................................................................................................... iv B. Tabellenverzeichnis ............................................................................................................ v C. Abkürzungsverzeichnis ...................................................................................................... vi 1 Einleitung & Motivation und Aufbau der Arbeit ................................................................ 1 2 1.1 Einleitung und Motivation ........................................................................................... 1 1.2 Aufbau dieser Arbeit .................................................................................................... 2 Grundlagen ......................................................................................................................... 3 2.1 2.1.1 Protokolle der Transportschicht........................................................................... 3 2.1.2 Einteilung der Netze nach geografischer Entfernung und Zugang zum WAN ..... 4 2.1.3 Topologie .............................................................................................................. 5 2.2 4 P2P ............................................................................................................................... 7 2.2.1 Abgrenzung zum Client-Server-Modell ................................................................ 7 2.2.2 Einteilung von P2P basierten Systemen ............................................................... 8 2.2.3 Strukturierter Ansatz ............................................................................................ 9 2.2.4 Kad als Implementierungsvariante von Kademlia .............................................. 10 2.3 3 Netzwerktechnische Grundlagen ................................................................................ 3 Verteiltes Rechnen .................................................................................................... 14 2.3.1 Stand der Technik ............................................................................................... 15 2.3.2 P2P-Vorteile gegenüber Client-Server-Ansatz ................................................... 15 DuDE-Konzept .................................................................................................................. 16 3.1 Verteilen von Daten ................................................................................................... 16 3.2 Prinzipieller Ablauf..................................................................................................... 17 3.3 Einsammeln von Daten (KaDis) ................................................................................. 23 3.4 Rollen und Zustände .................................................................................................. 24 Simulation......................................................................................................................... 26 Inhaltsverzeichnis ii Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation 5 4.1 Warum Eigenentwicklung? ........................................................................................ 26 4.2 Verwendete Technologien ........................................................................................ 26 4.3 Modellierung ............................................................................................................. 27 4.3.1 Peers ................................................................................................................... 27 4.3.2 Topologie ............................................................................................................ 28 4.3.3 Daten .................................................................................................................. 31 4.3.4 Jobs und Tasks .................................................................................................... 32 4.3.5 Berechnung von Tasks und Ressourcen-Metrik ................................................. 32 4.4 Funktionsweise des Simulators (Wie schickt Peer A an Peer B eine Nachricht) ....... 33 4.5 Möglichkeiten des Simulators ................................................................................... 36 4.6 Parameter der Simulation ......................................................................................... 36 4.7 Wie werden Ergebnisse produziert? ......................................................................... 37 Aufgaben und Auswertung............................................................................................... 39 5.1 Vergleich Client-Server-Modell ................................................................................. 39 5.2 Aufbau der Simulation ............................................................................................... 40 5.3 Skalierbarkeit und Vergleich mit Client-Server (statisches Netz) .............................. 40 5.3.1 5.4 6 Auswirkung des Parameters Peers Pro Task-Watcher ....................................... 42 Analyse des erzeugten Datenverkehrs ...................................................................... 43 Zusammenfassung und Ausblick ...................................................................................... 46 Literaturverzeichnis .................................................................................................................. 47 Inhaltsverzeichnis iii Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation A. Abbildungsverzeichnis Abbildung 2-1 Ein vermaschtes Netz ......................................................................................... 6 Abbildung 2-2 Ein voll vermaschtes Netz ................................................................................... 6 Abbildung 2-3 Stern-Toplogie .................................................................................................... 6 Abbildung 2-4 Einteilung von P2P-Systemen ............................................................................. 8 Abbildung 2-5 Darstellung eines P2P-Netzes mit 3 Bit-Adressen und 8 Peers. Es wird der Aufbau der k-Buckets ausgehend vom Peer mit dem Hashwert 001 dargestellt. ................... 11 Abbildung 2-6 Beispiel für einen rekursiven Suchvorgang, bei dem der Peer 001 den Peer 110 sucht. ........................................................................................................................................ 13 Abbildung 2-7 Beispiel für einen interativen Suchvorgang. Bei dem der Peer 001 den Peer 110 sucht. Der zuerst gefragte Peer 100 antwortet mit einem näheren Peer. Dieser Peer wird anschließend befragt und sendet die Kontaktinformationen.................................................. 13 Abbildung 3-1 Prinzipieller Ablauf von DuDE ........................................................................... 23 Abbildung 3-2 Schematischer Ablauf der Suche nach Dateien ................................................ 24 Abbildung 3-3 Zustandsdiagramm von DuDE .......................................................................... 25 Abbildung 4-1 Ermittlung des Weges für ein Netz innerhalb einer Area................................. 30 Abbildung 4-2 Beispiele für die Outer-Area-Routing-Tabelle von verschiedenen Nodes ....... 31 Abbildung 4-3 Modellierung der Kommunikation zwischen zwei Peers ................................. 35 Abbildung 5-1 Skalierungsverhalten von DuDE im Vergleich zum Client-Server-Model ......... 41 Abbildung 5-2 Diagramm zur Darstellung der Verteilung der Datentypen am Gesamtverkehr am Beispiel der Simulationsreihe DuDE-200 1000 Teilnehmer und DuDE-200 8000 Teilnehmer .................................................................................................................................................. 44 Fehler! Verweisquelle konnte nicht gefunden werden. iv Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation B. Tabellenverzeichnis Tabelle 2-1 Übersicht für die Einteilung von Netzen basierend auf der geographischen Ausdehnung................................................................................................................................ 5 Tabelle 2-2 Ergebnisse der XOR-Verknüpfung der Peers in Abbildung 2-2 aus Sicht der Peers mit dem Hashwert 010. Entsprechend der XOR-Metrik wird dann eine Einteilung in die entsprechenden k-Buckets durchgeführt ................................................................................ 11 Tabelle 3-1 Überblick über die Rollen und deren Aufgabe bei DuDE ...................................... 25 Tabelle 4-1 Aufteilung des Jobs in seine Task am Beispiel RAM- und CPU-Auslastung von 1000 Peers bei einer maximal Größe von 400 Peers pro Aufgabe ................................................... 32 Tabelle 4-2 Übersicht über eine Auswahl der Parameter des Simulators ............................... 37 Tabelle 5-1 Werte der Parameter für den Vergleich Client-Server und DuDE ........................ 40 Tabelle 5-2 Ergebnisse der Simulation und der Vergleichsrechnung. Alle Angaben sind in Sekunden, bis auf die Teilnehmer sind in Sekunden ............................................................... 41 Tabelle 5-3 Zeitliche Skalierung wenn unterschiedliche Anzahl an Peers pro Task gewählt werden ..................................................................................................................................... 42 Tabelle 5-4 Datenvolumen für die DuDE-200 Messreihe ........................................................ 43 Tabelle 5-5 Verteilung der Datenmenge innerhalb eines Simulationsvorgangs. Es wird die Messreihe DuDE-200 für 1000 und 8000 Teilnehmer dargestellt ........................................... 44 Fehler! Verweisquelle konnte nicht gefunden werden. v Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation C. Abkürzungsverzeichnis ATM - Asynchronous Transfer Mode CIL - Common Intermediate Language CLR - Common Language Runtime CPU - Central Processing Unit CSV - Comma-separated values DHT - Distribudet Hash Table DNS - Domain Name System DSL - Digital Subscriber Line DSLAM - Digital Subscriber Line Access Multiplexer DuDE - Distributed Computing System using a Decentralized P2P Environment FLOPS - Floating Point Operations Per Second FTTC - Fibre To The Curb Gbits - Gigabit per Second IDE - integrated development environment IP - Internet Protocol ISP - Internet Service Provider KaDis - Kademlia Discovery LSB - least significant bit Mbits - Megabit per Second MD4 - Message-Digest Algorithm 4 MIPS - Million Instructions Per Second MPLS - Multiprotocol Label Switching OSPF - Open Shortest Path First RAM - Random Access Memory SDH - Synchrone Digitale Hierarchie SPoF - Single-Point-of-Failure TCP - Transmission Control Protocol UDP - User Datagram Protocol VDSL - Vectoring Digital Subscriber Line Abkürzungsverzeichnis vi Einleitung & Motivation und Aufbau der Arbeit - Einleitung und Motivation 1 Einleitung & Motivation und Aufbau der Arbeit 1.1 Einleitung und Motivation Wie kann man den Erfolg einer Technologie messen? Eine Antwort auf die Frage, könnte die Verbreitung sein. Gemessen daran ist das Internet wohl einer der erfolgreichsten Technologien des letzten Jahrhunderts, denn es gibt quasi keinen Bereich, der nicht durch diese Technik verändert wurde. Wie genau aber das Internet funktioniert, bleibt wie auch bei vielen anderen Technologien dem technisch nicht versierten Benutzer verborgen. Hinter dem Aufruf einer Internetseite durch einen Browser liegt neben vielen verschiedenen Programmen vor allem eine ganze Palette an verschiedenen Geräten die Netzwerke auf unterschiedlichen Ebenen miteinander verbinden. Stellen wir also kurz die Frage, wo genau das Internet nun beginnt? Wenn wir den Anschluss zu Hause betrachten, so beginnt das Internet dort, wo die Leitung der Telefonbuchse endet. Dieser Punkt, an dem nicht nur die eigene Telefonleitung, sondern die vieler anderer Teilnehmer auch endet, ist in den meisten Fällen ein sogenannter Digital Subscriber Line Access Multiplexer (DSLAM), den man sich als einen Computer für sehr spezielle Zwecke vorstellen kann. Hier beginnt für die meisten Menschen das Internet. Nun verhält es sich mit diesen Zugangspunkten wie auch mit vielen anderen Computersystemen. Sie haben freie und ungenutzte Ressourcen. Stellt man sich weiter vor, man sollte ein Land wie Deutschland mit Internet versorgen, dann müssten dem entsprechend solche Zugangspunkte aufstellen. Unter der Annahme, dass bis zu 100001 Teilnehmer an einen solchen Knoten passen und man von einer Einwohnerzahl von 80 Millionen ausgeht, würden 10.0002 solcher Zugangspunkte benötigt. Hinzu kam der in den letzten Jahren gestiegener Bedarf nach Breitbandanschlüssen. Möchte man dieses Bedürfnis auf kurze Sicht kostengünstig abdecken, muss die aktive Technik wesentlich näher an den potenziellen Kunden gebracht werden. Bei VDSL beträgt die maximale Länge bis zum Teilnehmer beispielsweise 300 Meter, um eine signifikante Erhöhung 1 Dabei wird die Anzahl nicht von einem Gerät, sondern von mehrere die in einem Verbund agieren abgedeckt. Ein DSLAM besteht aus mehrere Linecards. Pro Linecard können bis zu 96 Teilnehmer angeschlossen werden. 2 Die tatsächliche Anzahl beträgt ein Vielfaches mehr. Kapitel: Einleitung & Motivation und Aufbau der Arbeit -1- Einleitung & Motivation und Aufbau der Arbeit - Aufbau dieser Arbeit der Bandbreite zu erzielen. Aus diesen Gegebenheiten wird die Anzahl der DSLAM in den nächsten Jahren drastisch zunehmen. Damit sich die Knoten überwachen lassen, erzeugen diese Logeinträge. Zur Planungs- und Wartungszwecken, oder zum Erkennen einer bewussten Störung des Netzes, müssen diese Logeinträge ausgewertet werden. Diese immense Anzahl an Zugangsknoten fördert ein weiteres Problem zu Tage. Wenn es überhaupt möglich sein soll, diese Logeinträge durch eine zentrale Instanz in Form von Statistiken wie z.B. Maximal, Minimal und Mittelwert auszuwerten, dann benötigt diese Instanz eine sehr große Leistungsfähigkeit und stellt damit auch gleichzeitig die Achillesverse des Systems dar. Um diese zu vermeiden, muss wiederum erneut ein hoher technisch aufwendiger und damit teurer Weg eingeschlagen werden, in dem nicht nur eine zentrale Instanz gibt sondern diese zu Clustern zusammen fügt. Es müssen also zwangsläufig andere dezentrale, Systeme gefunden werden, um diese Aufgabe zu bewältigen. Die nachfolgende Bachelorarbeit beschäftigt sich mit der Fragestellung der Skalierbarkeit für ein dezentrales System zum verteilten Berechnen von Statistiken aus Logeinträgen von Zugangsknoten. Dabei wird vor allem der Vergleich eines solchen Systems mit dem vorherrschenden Client-Server-Modell in dem Mittelpunkt gestellt. 1.2 Aufbau dieser Arbeit Nach einleitenden Worten im ersten Kapitel folgen in Kapitel zwei wichtige Grundlagen zu den Themen netzwerktechnische Grundlagen, Peer-to-Peer (P2P)-basierte Systeme und Verteiltem Rechnen. Das dritte Kapitel stellt das System Distributed Computing System using a Decentralized P2P Environment (DuDE) vor, bei dem es sich um ein System zum verteilten Berechnen von Statistiken für Zugangsknoten handelt. Anschließend, im vierten Kapitel, wird auf die Simulation eingegangen und die Ergebnisse werden präsentiert und diskutiert. Den Abschluss bildet das letzte Kapitel mit einer Zusammenfassung und einem Ausblick. Kapitel: Einleitung & Motivation und Aufbau der Arbeit -2- Grundlagen - Netzwerktechnische Grundlagen 2 Grundlagen Dieses Kapitel geht auf die zum Verständnis für DuDE und den Simulator wichtigen Grundlagen ein. Dazu gehören netzwerktechnische Aspekte sowie auch der Aufbau und die Verwaltung von Peer-to-Peer-basierten System und den Prinzipien für das Verteilte Rechnen. 2.1 Netzwerktechnische Grundlagen 2.1.1 Protokolle der Transportschicht Damit zwei Systeme erfolgreich mit einander kommunizieren können, bedarf es einem Satz von verbindlichen Regeln. Diese Regeln werden Protokolle genannt und dienen als Schema, wie die einzelnen Bits einer Nachricht interpretiert werden müssen. Das ist vergleichbar mit der menschlichen Sprache. Zwei Menschen sind nur in der Lage, einander zu verstehen, wenn es verbindliche Regeln gibt, in diesem Fall die Grammatik (Syntax) und die Wörter (Lexik), an die sich die beiden Teilnehmer halten3. Auf den verschiedenen Ebenen im Netzwerk existieren verschieden Protokolle. So definiert das Interprotocol (IP) ein Adressierungsschema, damit Geräte, die sich in verschiedenen Netzen befinden, kommunizieren können. Zum Verständnis für den Simulator sind die beiden Protokolle der Transportschicht wichtig. Diese Schicht teilt einen Datenstrom in kleinere Segmente auf und ermöglicht ein Anwendungsmultiplex auf einem Netzteilnehmer. In der ersten Version des sogenannten TCP/IP-Protokoll-Stapels gab es nur ein Protokoll für die Transportschicht und zwar TCP. Die Abkürzung TCP steht für Transmission Control Protocol. TCP ist ein sogenanntes zustandsbehaftetes Protokoll. Zu Beginn einer jeden Kommunikation wird über einen 3-Wege-Handshake eine Verbindung zwischen den beiden Teilnehmern etabliert. Eine Aufgabe dieser Schicht ist die Teilung des zu sendenden Datenstromes in kleinere Segmente. Nun kann es passieren, dass auf dem Kommunikationsweg zwischen den Teilnehmern Pakete verloren gehen oder in einer anderen als die ursprüngliche Reihenfolge beim Empfänger ankommen. Um mit diesen Probleme umzugehen, bietet TCP im Header eine Sequenznummer. Der Startwert dieser Sequenznummer wird während des Handshakes initialisiert. Mit jedem versendeten Segment wird die Sequenznummer um eins erhöht. Auf 3 Dieser Vergleich hinkt an einer Stelle. Um es technisch auszudrücken, sind Menschen Fehler tolerant und können selbst dann den Gegenüber verstehen, wenn nur ein paar syntaktische Regeln befolgt werden. Selbst fehlende Wörter könne aus dem Zusammenhang der Nachricht erschlossen werden. Kapitel: Grundlagen -3- Grundlagen - Netzwerktechnische Grundlagen diese Weise erhält auch jedes Segment eine eindeutige Nummer und kann für den Fall, dass eine andere Empfangs- als Sendereihenfolge vorliegt, sortiert werden. Damit kein Paketverlust stattfindet, bestätigt der Empfänger den Erhalt von Segmenten. Dies erfolgt derart, dass dem Sender mitgeteilt wird, welche Sequenznummer als nächsten erwartet wird. Stellt der Sender nun fest, dass er die vom Empfänger erwartete Sequenznummer bereits geschickt hat, trat ein Paketverlust auf und die fehlenden Pakete werden noch einmal gesendet. Sind die Daten ausgetauscht, wird ähnlich wie beim Start der Verbindung auch über einen 3Wege-Handshake die Verbindung abgebaut. TCP bieten noch viele weitere Funktionalitäten wie Staukontrolle, die aber in dieser Arbeit nicht weiter von Belang sind und deshalb nur erwähnt werden. TCP selbst braucht einige Timer vor allem, da Segmente gepuffert werden müssen, der Zwischenspeicher, meist in Form von flüchtigen Speicher, wie RAM4, dafür aber Ressourcen verbraucht. Auf der anderen Seite existiert das Protokoll UDP. Dementsprechend ist der Header von UDP wesentlich geringer als bei TCP. Dafür muss eine Anwendung, wenn gewünscht, selbst dafür sorgen, dass die Daten gesichert beim Empfänger ankommen. Es gibt einige Dienste wie z.B. das Domain Name System (DNS)5, die UDP benutzen und bei Ausbleiben einer Antwort vom Empfänger einen anderen möglichen Empfänger wählen, insofern es noch Empfänger gibt, die noch nicht gefragt wurden. Empfänger wählen, insofern es noch Empfänger gibt, die noch nicht gefragt wurden. 2.1.2 Einteilung der Netze nach geografischer Entfernung und Zugang zum WAN Es gibt verschiedene Möglichkeiten Netze zu kategorisieren. Eine Einteilung legt die geografische Entfernung, die ein solches Netz umspannen kann, als Grundlagen an. Daraus ergeben sich folgende Kategorien. 4 Die zwingende Vorrausetzung ist natürlich dass der Empfänger während der Datenübertragung mit dem Netzwerk verbunden bleibt. 5 Das DNS-System dient dazu, einen Namen z.B. www.uni-rostock.de in eine konkrete IP-Adresse umzuwandeln. Kapitel: Grundlagen -4- Grundlagen - Netzwerktechnische Grundlagen Name Personal Area Network Local Area Network Wide Area Network Abkürzung PAN LAN WAN Geographische Ausdehnung mehrere Meter Bis 10km Mehrere 1000 Kilometer Technologien Bluetooth Ethernet ATM Tabelle 2-1 Übersicht für die Einteilung von Netzen basierend auf der geographischen Ausdehnung6 In dieser Arbeit interessiert vor allem der Punkt, an dem das lokale Netz, sei es das persönliche zu Hause oder das Firmennetzwerk, an das WAN-Netz angeschlossen wird. Wird DSL als Zugangstechnologie verwendet, so ist dieser Punkt der Digital Subscriber Line Access Multiplexer (DSLAM). Dieser Punkt terminiert die Teilnehmeranschlussleitung, bündelt diese und leitet die Daten in das WAN-Netz des Service Provider. Dieses WAN-Netz wird oft auch als Backbone (im dt. etwa Rückgrat) bezeichnet. Als Technologie zum Teilnehmer wird eine DSL-Technologie verwendet, wahlweise asymmetrisch, symmetrisch oder mit dem Einsatz von Vectoring-Verfahren (ADSL, SDSL, VDSL). Als Technologie zum WAN-Netz kommt verstärkt immer mehr Ethernet oder MPLS oder ältere Technologien wie SDH und ATM. Die Bandbreite zum Teilnehmer ist im Allgemeinen sehr viel niedriger als die Bandbreite zum WAN-Netz.7 Da für DSL die bestehende Infrastruktur der Telefonie verwendet wird, befinden sich die DSLAM noch8 größtenteils in den Hauptverteilern. Diese werden auch als Indoor-DSLAM bezeichnet. Davon gibt es in Deutschland etwas mehr als 8.000. Aufgrund des Breitbandausbaus und der damit verbundenen geringer Entfernung zwischen Teilnehmer und DSLAM, werden verstärkt auch immer mehr kleinere Outdoor-DSLAM installiert, die Wahlweise in einem kleinen etwa Garagen großes Gebäude oder in einem Kabelverzweiger untergebracht sind. 2.1.3 Topologie Unter dem Begriff Topologie wird an dieser Stelle die logische Zusammenschaltung der Netzwerkelemente verstanden. Eine Topologie ist immer unabhängig von der genutzten Technologie. Für den später vorgestellten Simulator sind zwei Topologien wichtig. Das sind zum einen die vermaschte Topologie und die Stern-Topologie. Bezogen auf den konkreten 6 Wireless-LAN kann in die Kategorie zum LAN einsortiert werden. Zwar ist die Reichweite eines einzelnen AccessPoints begrenzt aber sie werden mit einander kombinieret um auf die gleiche Ausdehnung wie das verkabelte LAN zu kommen 7 Bei modernen FTTC-Strukturen hat der Teilnehmer mit Vectoring eine Bandbreite von 100 Mbits und der DSLAM an das WAN-Netz bis zu 10 Gbits. 8 VDSL macht es erforderlich die DSLAM wesentlich näher an die Kunden kommen. Um die volle Bandbreite zu nutzen, darf die Leitung nicht länger als 300 Meter sein. Kapitel: Grundlagen -5- Grundlagen - Netzwerktechnische Grundlagen Sachverhalt kann man als Netzwerkelement einen DSLAM verstehen. Die Betrachtungen werden jedoch allgemein gehalten. 2.1.3.1 Die vermaschte Topologie In dieser Topologie ist jedes Netzwerkelement mit mindestens einem weiteren Netzwerkelement verbunden. Die Topologie ist schematisch in der Abbildung 2-1 dargestellt. Eine Sonderform dieser Topologie ist das voll vermaschte Netz, in dem jedes Netzwerkelement eine Verbindung zu jedem anderen hat. Dies ist in der Abbildung 2-2 dargestellt. Abbildung 2-1 Ein vermaschtes Netz Abbildung 2-2 Ein voll vermaschtes Netz Der Vorteil eines vermaschten Netzes liegt darin, dass in aller Regel, selbst bei Ausfall eines Elementes, der Netzwerkverkehr durch das Netz immer noch geleitet werden kann. Es ist somit robust gegen den Ausfall eines einzelnen Teilnehmers. Dieser Vorteil wird jedoch erkauft durch ein komplexes Routing. Mit Routing ist die Wegfindung durch das Netz gemeint. Zum anderen wohnt dem System Komplexität inne, sodass Fehlersuche und Wartung kostenintensiv werden können. Kapitel: Grundlagen -6- Grundlagen - P2P 2.1.3.2 Die Sterntopologie Diese Topologie ist in der Abbildung 2-3 dargestellt. Bei dieser Struktur werden mehrere Netzwerkelement an einem „Konzentrator“ angeschlossen. Da das so Konzentrator entstehende Gebilde einem Stern ähnelt, spricht man auch von Sterntopologie. Diese Struktur verkraftet den Ausfall eines an den Konzentrator angeschlossenen Abbildung 2-3 Stern-Toplogie Elementes. Es eignet sich hervorragend für Broadcast und Multicast-Datenverkehr und der Routing-Aufwand ist gerade im Verhältnis zum vermaschten Netz wesentlich geringer. Der Nachteil dieses System ist die starke Abhängigkeit vom Konzentrator. Fällt dieses Element aus, so ist das Netz funktionsunfähig. 2.1.3.3 Topologie im WAN-Netz Die Netzstrukturen in der Realität sind sehr häufig eine Mischung aus den theoretischen Modellen. Das WAN-Netz eines Service Providers lässt sich als „vermaschte Sterntopologie“ modellieren. Dabei sind die DSLAM an einen Konzentrator angeschlossen, bilden also einen Stern, während die Konzentratoren untereinander ein vermaschtes Netz bilden. Diese Struktur ist die Grundlage für die spätere Simulation. 2.2 P2P Es gibt im Aufbau von verteilten Anwendungen zwei grundlegende Modelle. Eine verteilte Anwendung ist ein Programm, „das zum Ausführen seiner Funktionalitäten seinen eigenen Adressraum verlassen muss“ [1]. Für gewöhnlich, aber nicht zwingend, erfolgt dabei die Kommunikation zwischen den verschiedenen Adressräumen über ein Netzwerk. 2.2.1 Abgrenzung zum Client-Server-Modell Eines der ersten Modelle für diese Kommunikation ist das Client-Server-Modell. Dieses Modell ist auch heute noch das meist eingesetzte. Bei diesem Modell gibt es eine zentrale Instanz, die alle Verwaltungsaufgaben innehat. Oft wird mit diesem Modell auch immer eine Maschine mit viel Rechenleistung als Server verbunden, obgleich das entscheidende Merkmal die Zentralisierung ist und eher aufgrund der Fülle von Anfragen von Clients eine leistungsfähige Maschine als Server gewählt wird. Kapitel: Grundlagen -7- Grundlagen - P2P Eine andere Beschreibung, der bei diesem Modell verwendeten Komponenten, ergibt sich wie folgt. Der Server bietet einen Dienst oder Funktionalitäten an, hingegen konsumiert der Client diese. Die Kommunikation erfolgt ausschließlich zwischen Client und Server. Ein Client ist sich nicht der Existenz anderer Clients bewusst. Dem Server kommt in diesem Modell eine sehr wichtige Rolle zu. Ist der Server nicht erreichbar, sind die von ihm angebotenen Funktionalitäten für das Netzwerk verloren. Aus diesem Grund stellt er einen Single-Point-of-Failure9 (SPoF) dar. Das zweite Modell ist das Peer-to-Peer (P2P)-Modell. Bei diesem Modell sind alle Teilnehmer gleichwertig und die Kommunikation erfolgt direkt zwischen den Peers. Daher leitet sich der Name Peer-to-Peer ab. Auf der anderen Seite entstehen dadurch einige Probleme. Das P2PNetz muss sich selbst organisieren. Es müssen also Mechanismen gefunden werden, wie sich Peers gegenseitig finden. Hinzu kommt, dass solche Netze eine hohe Dynamik, wie z.B. beim Filesharing, besitzen. Infolge des Grundgedanken der P2P-Netze wohnen Merkmale wie Zuverlässigkeit und Skalierbarkeit dem System inne, denn jeder Knoten kennt das Netz aus seiner Perspektive und verlässt ein Teilnehmer das P2P-Netz, ist jeder Knoten in der Lage das Netz aus eben dieser Sicht wieder neu zu erstellen. Die Skalierbarkeit erwächst aus der Selbstorganisation. 2.2.2 Einteilung von P2P basierten Systemen Je nachdem, wie sich ein P2P-Netz organisiert, P2P-Systeme kann man diese in zwei verschiedene Kategorien einteilen – unstrukturierte- und strukturierte Systeme. Unstrukturierte Systeme lassen sich in drei weitere Kategorien einteilen. unstrukturierte zentralisierte strukurierte DHT basiert dezentralisierte Bei einem zentralisierten unstrukturierten Netz existiert ein Server, dem alle hybride Abbildung 2-4 Einteilung von P2P-Systemen teilnehmenden Peers bekannt sind. Die Kommunikation kann hier jedoch anders als beim Client-Server-Modell, nach dem Erfragen 9 Es gibt viele Maßnahmen um diesen Nachteile abzumildern. So ist es z.B. möglich einen Server zu clustern. Der technische Aufwand und damit auch der finanzielle der dabei betrieben wird ist immens. Kapitel: Grundlagen -8- Grundlagen - P2P der gewünschten Peers beim Server, direkt zwischen den Peers stattfinden. Der Server fungiert nur als Vermittler. Anders sehen die Prinzipien bei dezentralisierten unstrukturierten Netzen aus. Bei solchen Netzen verwalten die Peers nur Nachbarschaftslisten. Wird nach anderen Peers gesucht, muss das Netz dementsprechend geflutet werden. Bei hybriden unstrukturierten Netzen werden sogenannte Super-Peers gebildet. Diese Peers kennen sowohl angeschlossene als auch weitere Super-Peers. Sucht ein Peer nach Ressourcen stellt er seine Anfrage an den Super-Peer mit dem er verbunden ist. Findet dieser bei seinen angeschlossenen Peers nicht das gewünschte Datum, leitet er die Anfrage an weitere SuperPeers weiter. Dieses System verhält sich ähnlich wie ein Router mit vielen direkt angeschlossenen Netzen. Ein Gerät das außerhalb seines eigenen Netzes kommunizieren will, sendet das Paket an den Router. Dieser entscheidet dann, wohin das Paket weitergeleitet werden soll. Findet er ein passendes Netz, wird das Paket weitergeleitet. 2.2.3 Strukturierter Ansatz Ein Problem bei P2P-Netzen ist das Auffinden von Peers. Angenommen sei, dass jeder Peer jeden anderen kennen müsste. Es entsteht ein sogenanntes voll vermaschtes Netz. Bei geringer Teilnehmeranzahl ist ein solches Netz noch zu verwalten, aber wird das Netz größer treten viele Probleme auf, denn ein solches Netzt skaliert schlecht. Eine der Ursachen dafür ist die hohe Dynamik, die P2P-Netzen innewohnt. Wenn jeder Peer jeden anderen kennen würde, muss jeder Peer sich auch über die Aktualität seiner bekannten Peers kümmern. Meldet sich ein Peer ab, ist die Wahrscheinlichkeit, dass ein anderer Peer diese Information nicht bekommt, groß. Man stelle sich auch die Netzwerklast vor, wenn ein neuer Peer dem Netz beitritt und alle anderen Peers antworten, denn nur so hätte der Peer die Möglichkeit das Netz kennen zu lernen. Für große Netze müssen Methoden gefunden werden, die das System strukturierbar machen. Distributed Hash Table (DHT) bilden hierfür einen Mechanismus. Ziel von DHTs ist es, das Netz zu strukturieren, indem ein logischer Ring gebildet wird. Dabei wird die Ringstruktur durch einen Hashwert erzeugt. Beim Hashen handelt es sich um eine mathematische Operation, die einen beliebigen Eingangswert (z.B. eine IP-Adresse) auf eine eindeutige Zahl abbildet. Diese Zahl wird Hashwert genannt. Im besten Falle sorgen kleine Kapitel: Grundlagen -9- Grundlagen - P2P Änderungen der Eingangswerte zu großen Änderungen des Hashwertes. Des Weiteren sollte ein guter Hashalgorithmus nicht vom Hashwert auf den Eingang schließen lassen, jeden beliebigen Hashwert annehmen können und eineindeutig sein. Heute eingesetzte Verfahren in dem Bereich sind MD4 und MD5. Da nun die Hashwerte immer eine feste Länge haben und theoretisch jeder Wert angenommen werden kann, lässt sich ein Ring bilden, wobei der Wert nach dem größtmöglichsten der kleinstmöglichste ist. Im nächsten Schritt verwaltet ein Peer nur noch Informationen über eine gewisse Anzahl von anderen Peers, wobei er die Informationen von vielen nahen und nur wenig entfernten verwaltet. Soll nun Kontakt zu einem Peer aufgenommen werden, der dem sendenden Peer nicht bekannt ist, sendet er einfach eine Nachricht zu dem Peer der ihm am nächsten scheint. Dieser wiederum entscheidet, ob ihm der gewünschte Peer direkt bekannt ist oder welcher andere Peer aus seiner Sicht am nächsten ist und meldet es dem ursprünglichen. So kann das ganze Netz durchsucht werden. Im nächsten Schritt wird auch für Dateien, zum Beispiel aus deren Namen, ein Hashwert gebildet. Dabei gilt, dass ein Peer, der einen der Datei ähnlichen Hashwert hat, auch für die Datei verantwortlich ist, also vermutlich deren Besitzer ist. Ein Beispiel folgt im nächsten Abschnitt. 2.2.4 Kad als Implementierungsvariante von Kademlia Kademlia ist ein P2P-basiertes Protokoll das DHTs zur Strukturierung des Overlays einsetzt wird. Eine Implementierung dieses Protokolls ist Kad [2]. Kapitel: Grundlagen - 10 - Grundlagen - P2P Als Hashalgorithmus wird MD4 eingesetzt und der zu hashende Wert ist die IP-Adresse. Als Beispiel für den Aufbau der Routingtabelle und zum Finden von Daten soll die Fehler! Verweisquelle konnte nicht gefunden werden. dienen. 0 0 0 1 000 001 1. Bucket 0. Bucket 1 1 0 0 010 1 011 2. Bucket 1 0 1 100 101 0 110 1 111 3. Bucket Abbildung 2-5 Darstellung eines P2P-Netzes mit 3 Bit-Adressen und 8 Peers. Es wird der Aufbau der k-Buckets ausgehend vom Peer mit dem Hashwert 001 dargestellt. In diesem Netz befinden sich acht Peers, symbolisiert durch Kreise. Zur einfachen Darstellung gehen wir davon aus, dass der Adressraum drei Bits umfasst. Der Hashwert der Peers ist in dem Kreis dargestellt. Zur Berechnung der Distanz von zwei Peers wie auch für Daten wird die XOR-Metrik herangezogen, das bedeutet Quell- und Zielhashwert werden XOR verknüpft. Je geringer des Ergebnis, umso ähnlicher und damit näher, sind sich zwei Peers. Ausgehend von diesem Ergebnis werden die Peers ihrer Entfernung nach in sogenannte k-Buckets eingeteilt. In welches k-Bucket ein Peer einzuordnen ist, entscheidet sich über die erste Position - vom LSB aus betrachtet - an der sich eine Eins im Ergebnis der XOR-Verknüpfung befindet. Wir betrachten das Netz aus Sicht des Peers mit dem Hashwert 001. Daraus ergibt sich folgende Tabelle. Peer-Hashwert 000 001 010 011 100 101 110 111 XOR-Metrik zum Peer 001 001 000 011 010 101 100 111 110 K-Bucket 1 0 2 2 3 3 3 3 Tabelle 2-2 Ergebnisse der XOR-Verknüpfung der Peers in Fehler! Verweisquelle konnte nicht gefunden werden. aus Sicht der Peers mit dem Hashwert 010. Entsprechend der XOR-Metrik wird dann eine Einteilung in die entsprechenden k-Buckets durchgeführt Kapitel: Grundlagen - 11 - Grundlagen - P2P Für das Beispiel wurde eine baumartige Darstellung gewählt, um die Einteilung der k-Buckets gut sichtbar zu machen. Eine Visualisierung hätte auch wie im Abschnitt 2.2.3 beschrieben als Ring erfolgen können. Man kann an dem Beispiel erkennen, dass je größer der Adressraum ist, desto mehr Peers in wird es in entfernteren Buckets geben. Auch ergibt sich die Anzahl der Buckets direkt aus der Größe des Adressraumes. Da MD4 und MD5 einen 128-bit breiten Hashwert liefert, hat ein Peer im Kad-Netzwerk eine Routingtabelle die aus 128 k-Buckets besteht. Das k drückt aus, wie viele Peers in einem Bucket gespeichert werden sollen. Bei Kad sind es zehn. Darüber hinaus hat jeder Peer in der Routingtabelle eine Lebenszeit. Bevor die Lebenszeit abgelaufen ist, wird überprüft, ob der Peer noch antwortet. Damit die Routingtabelle gefüllt wird, gibt es drei verschiedene Mechanismen. Zum einen führt ein jeder Peer, der dem Netzwerk beitreten will, einen Bootstrap aus. Dabei wird ein bekannter Peer angesprochen. In seiner Antwort befinden sich Kontakte. Neben dem Bootstrap gibt es noch ein Lookup Verfahren. Bei einem Lookup-Verfahren wird zu einem Hashwert ein naher Peer gesucht. Dieser Peer erhält eine Nachricht, die den Hashwert beinhaltet. Der Peer wird durch diese Nachricht aufgefordert, aus seiner Routing-Tabelle Peers mit einem ähnlichen Hashwert zu finden und diese dem fragenden Peer mitzuteilen. Man unterscheidet dabei zum einen das Verfahren des Self-Lookup, bei dem der eigene Hashwert übertragen wird und dem Random-Lookup, in dem ein durch Zufall bestimmter Hashwert übertragen wird. Wird nun ein Datum gesucht, wird auch von diesem ein Hashwert gebildet. Gesetz dem Falle, dass der Hashwert 110 wäre, würde die XOR-Verknüpfung mit dem eigenen Hashwert (001) 111 ergeben. Daraus folgt, dass der Ziel Peer, insofern bekannt, sich im dritten Bucket befinden muss. Dementsprechend würde der Peer dieses k-Bucket durchsuchen nach dem Peer mit der geringsten Entfernung zum Ziel suchen und den Ziel Peer dort auch finden. Das Kademlia-Protokoll kennt zwei verschiedene Arten Dateien zu suchen - rekursiv und iterativ. Damit der Sachverhalt mit demselben Beispiel erklärt werden kann, wird angenommen der Peer 001 würde nicht das Bucket durchsuchen, sondern zuerst den Peer mit dem Hashwert 100 befragen. Kapitel: Grundlagen - 12 - Grundlagen - P2P Für den Fall der rekursiven Suche, würde der suchende Peer den Peer aus seiner RoutingTabelle den für den Ziel-Hashwert am nächsten gelegenen Peer suchen. Hat dieser das Ziel nicht in seiner Routing-Tabelle, sucht der sich wiederum dem Ziel am ähnlichsten Peer und fordert diesen auf, nach dem Peer zu suchen. Dieser Vorgang wiederholt sich solange, bis der Ziel-Peer gefunden wurde. Wurde dieser Peer gefunden, sendet der Peer, der ihn gefunden hat, eine Antwort an den suchenden Peer. Diese Antwort enthält alle notwendigen Informationen, damit die Peers sich über das Underlay verständigen können. Dazu zählen unter anderem die IP-Adresse und der Port. Diese Informationen werden im Folgenden Kontaktinformationen genannt. Die unten stehende Abbildung zeigt exemplarisch eine solche Strategie. 001 Suche Peer: 111 Fragender Peer: 001 100 Suche Peer: 111 110 Ziel bekannt, Teile fragendem Peer (001) die Kontaktdaten mit Ziel nicht bekannt, Suche nahen Peer, Befrage Peer 110 Sender Peer 001 die Kontaktdaten Abbildung 2-6 Beispiel für einen rekursiven Suchvorgang, bei dem der Peer 001 den Peer 110 sucht. Im iterativen Fall, würde jeder Peer entlang des Suchpfades dem suchenden Peer eine Antwort senden, die jeweils immer die Kontaktinformationen eines Peers beinhaltet, die näher am Ziel sind als der vorherige. Dabei wird auch in der Routingtabelle immer nach dem ähnlichsten Peer gesucht. Im Erfolgsfall würden dann wie bei der iterativen Suche, die Kontaktdaten des Ziel-Peers mitgeteilt werden. Abbildung 2-7 stellt dieses Prinzip dar. Dabei wird der blaue Pfad zuerst gewählt. Aus der Information in der Antwort wird der orangene Pfad eingeschlagen. Suche Peer 111 001 Suche Peer: Hash 111 Peer ist mir nicht bekannt, aber Peer 110 könnte es wissen, Sende Kontaktdaten von Peer 110 100 110 Peer bekannt, sende Kontaktdaten Abbildung 2-7 Beispiel für einen interativen Suchvorgang. Bei dem der Peer 001 den Peer 110 sucht. Der zuerst gefragte Peer 100 antwortet mit einem näheren Peer. Dieser Peer wird anschließend befragt und sendet die Kontaktinformationen. Kapitel: Grundlagen - 13 - Grundlagen - Verteiltes Rechnen 2.3 Verteiltes Rechnen An dieser Stelle soll kurz geklärt werden, was unter dem Begriff Verteiltes Rechnen zu verstehen ist. Verteiltes Rechnen ist eine Spezialisierung der Verteilten Anwendung, deren Definition in der Einleitung zu dem Abschnitt 2.2 zu finden ist. Beim Verteilten Rechnen arbeiten nun alle Instanzen der Anwendung an einer gemeinsamen Aufgabe. Dabei erledigen die einzelnen Instanzen im Allgemeinen unterschiedliche Teilaufgaben. Die Aufgabe, die durch das Verteilte Rechnen gelöst werden soll, muss sich grundlegend in Teilaufgaben zerlegen lassen, die alle unabhängig voneinander sind. Wären die Aufgaben abhängig, würde dies bedeuten, dass eine Teilaufgabe Ergebnisse einer anderen benötigen würde und in Folge dessen solange warten müsste, bis die abhängige Teilaufgabe gelöst wurde. Als Beispiel sei die Berechnung von statistischen Kenngrößen (z.B. Mittelwert und Varianz) mehrerer Datensätze angedacht. Würde man die Aufgabe so zerlegen, dass die erste Teilaufgabe die Berechnung des Mittelwertes aller Datensätze vorsehen würde und die zweite Teilaufgabe die Berechnung der Varianzen, so würden Abhängigkeiten entstehen, denn die Varianz kann erst bestimmt werden, wenn der Mittelwert bekannt ist10. Dieses Beispiel hätte in dieser Form keinen Vorteil gegenüber der sequenziellen Berechnung durch nur eine Maschine. Würde man hingegen die Aufgaben derart einteilen, dass jede Maschine einen Datensatz bekäme, wäre die Aufgabe für das verteilte Rechnen geeignet und die Berechnung der gesuchten Größe würde wesentlich schneller vorliegen als bei dem gewöhnlichen sequenziellen Ansatz. Neben dieser Vorrausetzung an die Aufgabe bedarf es noch weitere Schritte damit eine Aufgabe durch ein verteiltes Rechnen System gelöst werden kann. Dazu zählen vor allem Anforderungen an die Koordination der einzelnen Teilnehmer. Man kann die diese in die folgenden drei Punkte einteilen. ο· Finden der verfügbaren Geräte ο· Verteilen der Aufgabe an die verfügbaren Geräte ο· Einsammeln der berechneten Ergebnisse 1 2 Für die Berechnung wird die Formel: π 2 = ∑π π=0(π₯π − π₯Μ ) angewandt. Es gibt Verfahren die Varianz und π Mittweltwert in einem Durchlauf schätzen 10 Kapitel: Grundlagen - 14 - Grundlagen - Verteiltes Rechnen Auf eine allgemeine Beschreibung dieser Koordinierungsaufgaben wird verzichtet. Stattdessen wird im Abschnitt drei gezeigt, wie das System DuDE diese Aufgaben löst. 2.3.1 Stand der Technik 2.3.2 P2P-Vorteile gegenüber Client-Server-Ansatz Es wurde gezeigt, dass die Koordinierung der einzelnen Teilnehmer eine große Herausforderung beim Verteilten Rechner darstellt. Bei dem Client-Server-Ansatz wird dies meist durch eine zentrale Instanz, dem Server, geregelt. Dabei melden sich die potenziellen Clients beim Server an beziehungsweise ab. Daher weiß der Server zu jedem Zeitpunkt, welche Teilnehmer für eine Aufgabe verfügbar wären. Die für eine Aufgabe notwendigen Dateien befinden sich entweder direkt auf dem Server beziehungsweise können durch ihn bereitgestellt werden oder werden, wenn die Aufgabe verteilt wird, den Teilnehmern direkt geschickt. Wurde eine Teilaufgabe gelöst, so sendet der Client seine Ergebnisse an den Server. Auch in diesem Szenario stellt der Server ein SPoF dar. Ein P2P-Netz hingegen muss sich selbst organisieren und ist robust gegen den Ausfall einzelner Peers. Nimmt die Anzahl der Teilnehmer zu und die Reaktionszeit des Systems soll die gleiche bleiben, so muss zwangsweise die Leistung des Server mitwachsen und zwar für jeden einzelnen Teilnehmer, der hinzukommt. P2P-Netze hingegen skalieren wesentlich besser, was die Organisation betrifft. Ein weiterer Nachteil des Client-Server-Modells ist der Fakt, dass ein Server, was die Netzwerkbandbreite angeht, einen Flaschenhals bildet. Bei P2P-Netzen und ihrem dezentralen Charakter wird dies vermieden. Dadurch, dass keine sehr leistungsfähige Maschine mehr benötigt wird und alle Teilnehmer im P2P-Netz von ihrer Leistung auch stark heterogen sein können, nimmt es zum einen den Kostendruck und ermöglicht zum anderen auch Teilnehmer mit einzubeziehen, die im ClientServer-Modell nicht teilnehmen hätten können. Kapitel: Grundlagen - 15 - DuDE-Konzept - Verteilen von Daten 3 DuDE-Konzept In diesem Kapitel wird das DuDE-Konzept dargestellt. Dieses Konzept wurde an der Universität Rostock entwickelt und stellt ein Verfahren dar, um mit Hilfe eines dezentralen Ansatzes Statistiken der Zugangsknoten (DSLAM) zu berechnen. Das System ist dezentral sowohl bezogen auf die Koordinierung des Verteilten Rechnen als auch die Datenhaltung11. Als Daten werden in diesem Falle die Logeinträge der Zugangsdaten bezeichnet. Das sind Dateien, die Informationen zur Auslastung von beispielweise CPU, RAM oder Paketverlust beinhalten. Durch das Anfertigen von Statistiken, basierend auf diesen Daten, kann man Erkenntnisse zur Auslastung des Netzes und der verwendeten Zugangsknoten erhalten, die dann als Planungsgrundlagen für spätere Investitionen dienen können. Des Weiteren kann sich auch ein Angriff auf das Netz aus diesen Statistiken feststellen lassen. Hinzu kommt, dass die meisten Zugangsknoten ungenutzte Ressourcen haben, die sich zum Berechnen der Statistiken eignen würden. Dabei wird das Kademlia-Protokoll um Fähigkeiten zum Verteilen von Sitzungsdaten und zum Verteilten Rechnen erweitert. Das hält zum einen den zu erwartenden Overhead klein und sorgt für Stabilität, da ein Protokoll eingesetzt wird, welches sich in der Praxis bewährt hat und die Grundlage vieler weiterer Anwendungen ist. 3.1 Verteilen von Daten DuDE ist ein vollkommen dezentrales System. Dementsprechend muss auch die Datenhaltung dezentral erfolgen. Da immer die Möglichkeit besteht, dass ein Peer das Netz verlässt, verteilt der Peer seine Sitzungsdaten periodisch oder wenn bestimmte Ereignisse eintreten, die die alten Daten für ungültig erklären, so dass ein Neuverteilen notwendig wird. Zum Verteilen wird eine Datei in n Datenstücke und m Kodierungsstücke geteilt. Unter der Annahme, dass der Knoten mit der ID 2 seinen Log-Datei für den RAM verteilen wird, so würde er die Teile derart benennen: „Knoten 2 RAM_n.log“. Die Kodierungsstücke würden in der Nummerierung einfach weiter laufen. Anschließend wird aus diesem Namen der Hashwert gebildet. Danach wird nach mindestens k Knoten gesucht, deren Hashwert dem Hashwert der 11 Damit das System funktioniert muss ein bekannter Peer definiert sein oder durch einen Broad bzw. Multicast ermittelt werden. Nimmt man den bekannten Peer an, so ist das System nicht vollständig dezentral. Kapitel: DuDE-Konzept - 16 - DuDE-Konzept - Prinzipieller Ablauf Daten ähnlich sind. Diese Knoten werden angewiesen, die Dateien zu speichern. Dieser Datenverkehr wird über TCP abgewickelt, um zu gewährleisten, dass die Daten gesichert und vollständig beim Ziel-Peer ankommen. Ein Peer hat also dementsprechend immer eigene vollständige Dateien und kann darüber hinaus noch Dateistücke von anderen Peers bekommen. Je größer die Werte für n, m und k gewählt werden, umso größer wird die Datenverfügbarkeit und je mehr Datenverkehr wird erzeugt. Auf eine genaue Rechnung wird an diese Stelle auf die Arbeit von [3] verwiesen. 3.2 Prinzipieller Ablauf In diesem Abschnitt wird davon ausgegangen, dass die Daten bereits redundant im Netz verteilt sind und das Netz bereits konvergiert ist, also jeder Peer ausreichend andere Peers kennt. Für dieses Beispiel sollen die Statistiken für die Werte von RAM, CPU und Paketverlust für alle Zugangsknoten berechnet werden. Dies ist der Sachverhalt, welcher auch Grundlage in der später beschriebenen Simulation ist. Das System DuDE könnte aber auch zum Beispiel nur die RAM-Auslastung von bestimmten Knoten berechnen. Ein jeder Knoten bekommt eine eindeutige Identifikation, die aus dem Präfix „Knoten “ und einer Nummer besteht, welche bei null startet und bis n-1 Teilnehmer durchnummeriert wird. Aus dieser Identifikation wird der Hashwert gebildet. Folgende Schritte werden durchgeführt: 1. Ermitteln des Job-Schedulers 2. Teilen des Jobs in einzelne Tasks 3. Finden der Task-Watcher 4. Verteilen der Aufgabe 5. Ein jeder Task-Watcher sammelt die notwendigen Dateien 6. Die Berechnung werden durchgeführt 7. Die Ergebnisse werden an den Job-Scheduler gesendet 8. Sind alle Task gelöst, ist der Job beendet Nachfolgend werden die Schritte detailliert beschrieben. Soll eine Aufgabenstellung durchgeführt werden, verbindet sich ein Administrator mit einem beliebigen Zugangsknoten. Diesem Knoten wird eine Aufgabenstellung mitgeteilt. Mit Aufgabenstellung ist in diesem Kapitel: DuDE-Konzept - 17 - DuDE-Konzept - Prinzipieller Ablauf Zusammenhang gemeint, dass RAM, CPU und Paketverlust von beispielsweise allen Zugangsknoten bestimmt werden soll. Aus dieser Aufgabenstellung wird später der Job generiert. Dieser Zugangsknoten sendet eine Nachricht an alle Peers in seiner Routingtabelle. Durch diese Nachricht werden die Peers aufgefordert ihre Ressourcen-Metrik zu berechnen und diese dem fragenden Peer mitzuteilen. Zu diesem Zeitpunkt wird ein Ressourcen-Timer gestartet. Mit Ressourcen-Metrik ist eine Zahl gemeint, die verschiedene Werte bezüglich der aktuellen Auslastung des Zugangsknoten verrechnet und damit ein Maß bildet, wie leistungsstark der Zugangsknoten zum aktuellen Zeitpunkt ist und damit wie viel Verantwortung er innerhalb von DuDE übernehmen kann. Denkbar wäre auch, wenn der errechnete Wert einen Schwellwert unterschreitet, dass keine Antwort gesendet wird. Sobald der Peer seine Antwort gesendet hat, wechselt er in einen Zustand, der verhindert, dass der Peer auf irgendeine DuDE-bezogene Nachricht antwortet. Dies ist notwendig, da im System auch mehrere Jobs parallel abgearbeitet werden können. So wird auf einfache Weise eine Gruppe von Peers an einen Job gebunden. Damit die Peers nicht für immer blockiert sind, wird ein Timer gestartet, der nach Ablauf den Ausgangszustand wieder herstellt. Ist der Ressourcen-Timer abgelaufen oder haben alle gefragten Peers geantwortet, werden alle ankommenden Antworten mit einem Entsperren beantwortet und somit nicht mehr akzeptiert und der fragende Peer wertet die Antworten aus. Der Peer, der die höchste Ressourcen-Metrik hatte, wird zum sogenannten Job-Scheduler gewählt, indem ihm eine Nachricht geschickt wird. Diese Nachricht beinhaltet auch, den zu bearbeitenden Job. Die Aufgabe des Job-Scheduler ist es, den Job zu verwalten und zu überwachen. Alle anderen Peers die an der Wahl teilgenommen haben, aber nicht gewählt wurden, erhalten eine Nachricht, die sie wieder in den Ausgangszustand versetzt. So sind diese Peers wieder freigegeben. Ebenso wird auch der fragende Peer selbst freigegeben. Der Job-Scheduler wechselt zuerst in einen Zustand, in dem er auf Ressourcen Anfragen anderer Peers nicht antwortet. Er ist an die Aufgabe gebunden. Anschließend wird die Aufgabe in einzelne Tasks geteilt. Dabei bezieht sich ein Task immer nur auf einen bestimmten Kapitel: DuDE-Konzept - 18 - DuDE-Konzept - Prinzipieller Ablauf Datentyp und eine bestimmte Anzahl von Peers. Umfasst das Netz beispielsweise 800012 Teilnehmer und ein Task darf nicht mehr als 300 Peers beinhalten, so würden es 8000*3 (RAM, CPU, Paketverlust) / 300 = 80 Task entstehen. Ist der Job in die einzelnen Task geteilt, sucht der Job-Scheduler nach Ressourcen. Dieser Vorgang kann äquivalent zu der Suche nach Ressourcen zur Wahl des Job-Schedulers verstanden werden. Befinden sich in der Routing-Tabelle weniger Peers als ein Schwellwert, so wird die Suche nach Ressourcen rekursiv ausgeführt. Dabei kontaktieren die Peers, die eine Nachfrage nach Ressourcen hatten, ebenso alle Peers in ihrer Routing-Tabelle. Damit das Netz nicht geflutet wird, wird die Anzahl der Schritte begrenzt. Der Schwellwert errechnet sich aus der Anzahl der Task erhöht um einen Sicherheitsfaktor der in Prozent angeben wird. π = πππ ππ΄ππ§πβπ ∗ (1 + πππβππβπππ‘π πΉπππ‘ππ) Der Sicherheitsfaktor ist notwendig, da nicht davon ausgegangen werden kann, dass alle gefragten Peers auch antworten. Der Job-Scheduler wertet die Metriken aus. Die Tasks werden dann anschließend auf die Peers mit den höchsten Metriken verteilt, in dem sie eine Nachricht mit den Tasks erhalten. Alle anderen Peers die geantwortet haben, aber für die keine Task übrig war, werden dazu wieder freigegeben. Erhalten Peers eine Nachricht, die einen Task beinhaltet, werden diese zu Task-Watchern befördert. Auch in diesem Zustand wird nicht auf Ressourcenanfragen von anderen Peers geantwortet. Der Task selbst beinhaltet Informationen zu dem Dateityp, auf den sich die Aufgabe bezieht und die Identifikationen der Peers, von denen die Informationen gesammelt und berechnet werden sollen. Der Task-Watcher beginnt dann mit der Suche nach den Dateien. Die Suche wird detailliert im nächsten Abschnitt erklärt. Ist die Suche nach den Dateien beendet, wird die Berechnung durchgeführt. Ist auch diese beendet, wird dem JobScheduler das Ergebnis mitgeteilt. Der Task-Watcher wechselt danach wieder in den Anfangszustand und wäre somit bereit, an einer weiteren Berechnung teilzunehmen. 12 Wenn die Anzahl der Zugangsknoten im gesamten Netz nicht bekannt sind, sollte dieser Wert größer als real gewählt werden. Bei dem Abschnitt „Einsammeln von Daten“ wird auf ein Verfahren eingegangen, dass in solchen Fällen die Suche terminiert. Kapitel: DuDE-Konzept - 19 - DuDE-Konzept - Prinzipieller Ablauf Hat der Job-Scheduler von jedem Task-Watcher die Ergebnisse, werden diese dem Administrator mitgeteilt und auch der Job-Scheduler begibt sich wieder in den Ausgangszustand und steht für die verteilte Berechnung wieder bereit. Sollte ein Task Watcher nach einer bestimmten Zeit nicht geantwortet haben, geht der Job-Scheduler davon aus, dass der Task-Watcher nicht erreichbar ist und wird erneut nach Ressourcen suchen und den Task erneut verteilen. Ein Administrator PC Administrator beauftragt das Netz damit eine Aufgabe zu Peer ID: 4 erledigen. Dazu wird ein Peer ID: 6571 Peer ID: 400 Peer ID: 124 Übersende Aufgabe beliebiger Peer kontaktiert. In diesem Beispiel der Peer mit der ID 6571 Dieser beginnt mit der Administrator PC Suche nach Ressourcen um den Job-Scheduler Peer ID: 4 Peer ID: 6571 Kapitel: DuDE-Konzept zu finden. Dabei werden alle Peers in Peer ID: 124 Peer ID: 400 seiner Routing-Tabelle befragt. - 20 - DuDE-Konzept - Prinzipieller Ablauf Die gefragten Peers Administrator PC antworten mit ihrer Ressourcen Metrik. Zu Peer ID: 6571 Freie Ressourcen Peer ID: 124 Peer ID: 4 sehen ist, dass der Peer mit der ID 400 nicht Peer ID: 400 befragt wurde, weil er z.B. dem Peer mit der ID 6571 nicht bekannt ist. Der Administrator PC Peer mit der höchsten RessourcenMetrik wird zum Job- Beföderung zum Job-Scheduler Peer ID: 6571 Peer ID: 124 Peer ID: 4 Scheduler befördert. In dem Beispiel der Peer Peer ID: 400 mit der ID 4. Dieser beginnt erneut Administrator PC mit der Suche nach Ressourcen. Peer ID: 4 Peer ID: 6571 Kapitel: DuDE-Konzept werden alle Kontakte in Peer ID: 124 Peer ID: 400 Dazu seiner Routing- Tabelle befragt. - 21 - DuDE-Konzept - Prinzipieller Ablauf Auch jetzt antworten Administrator PC die gefragten Peers mit ihrer Ressourcen Freie Ressourcen Peer ID: 6571 Peer ID: 4 Metrik. Zu beachten ist, dass für den Peer Peer ID: 124 Peer ID: 400 mit der ID 4, der Peer mit der ID 400 bekannt sei. Der Peer mit der ID 4 ist Administrator PC Job-Scheduler (orange). Peer ID: 4 Task RAM Peer ID: 6571 Task CPU verteilt die Task an die Peers mit der höchsten Peer ID: 400 Peer ID: 124 Dieser Ressourcen Damit Metrik. werden die Peers mit der ID 6571 und 124 zu Task- Watchern. Die Administrator PC Task-Watcher sammeln die Dateien ein und berechnen die Peer ID: 4 Fertig Peer ID: 6571 Fertig Peer ID: 124 Aufgabe. Haben sie die Aufgabe Peer ID: 400 übersenden berechnet, sie die Aufgabe an den JobScheduler. Kapitel: DuDE-Konzept - 22 - DuDE-Konzept - Einsammeln von Daten (KaDis) Wenn Administrator PC alle Task- Watcher ihre Aufgabe Ergebnisse beendet haben, sendet Peer ID: 4 Peer ID: 6571 der Job-Scheduler die Ergebnisse Peer ID: 124 Peer ID: 400 an den fragenden Admin. Abbildung 3-1 Prinzipieller Ablauf von DuDE 3.3 Einsammeln von Daten (KaDis) Da bei DuDE auch die Datenhaltung dezentral ist, muss jeder Task-Watcher alleine die Daten für den Task sammeln. In dem Task selbst wird auch die Information transportiert, auf welche Peers sich der Task bezieht. Jeder Peer hat eine eindeutige Identifikation. Es soll angenommen werden, dass der Task besagt, dass die Statistik der RAM-Auslastung von Knoten mit der Identifikation 300 bis 600 ermittelt werden soll. Das Netz eines Providers kann als hinreichend stabil betrachtet werden, um im ersten Versuch direkt nach dem Peer mit der ID zu suchen. Der Task-Watcher würde also angefangen, den Hashwert für „Knoten 300“ zu ermitteln. Anschließend sucht er in seiner Routingtabelle nach einem entsprechend nahen Peer. Ist der Peer selbst nicht dabei, wird entweder iterativ oder rekursiv nach dem Ziel-Peer gesucht. Ist der Ziel-Peer noch im Netz sendet er seine entsprechende Log-Datei direkt an den Task-Watcher. Antwortet der Ziel-Peer nach einer bestimmten Zeit nicht, wird der Task-Watcher davon ausgehen, dass der Ziel-Peer das Netz verlassen hat und beginnt nun nach den Teilen der entsprechenden Datei zu suchen. Dazu würde der Hashwert der Datei also in dem Beispiel „Knoten 300 RAM_0.log“ gebildet werden und nach einem entsprechenden nahen Peer gesucht. Dies geschieht für alle Teile. Ist auch diese Suche erfolglos, was bedeutet, dass nicht alle für das Zusammensetzen nötigen Dateien gefunden wurden, wird der Wert für aktuelle Verluste um eins erhöht. Würde die Datei „Knoten 301 RAM.log“ gefunden werden, so wird dieser Wert wieder auf 0 gesetzt werden. Hat der Wert einen bestimmten Schwellwert überschritten, wird davon ausgegangen, dass das Netz vollständig durchsucht wurde und der Task-Watcher würde mit der Berechnung Kapitel: DuDE-Konzept - 23 - DuDE-Konzept - Rollen und Zustände starten. Dieser Algorithmus wird Kademlia Discovery (KaDis) genannt und ist schematisch in Abbildung 3-2 dargestellt. Task Noch IDs übrig Starte mit nächster Type: RAM Peer-IDs: 300 301 302 303 …. ο· ο· Frage nach der Logdatei für RAM Erhalte Daten Alle IDs durchsucht Peer gefunden ο· ο· Peer ο· Bilde Hashwert von „Knoten i". Suche nach Peer Peer nicht ο· gefunden ο· ο· Suche nach Datei Stücken Bilde Hashwert z.B. von „Knoten i_RAM_1.log“ Suche nach Peers für Dateistücke Setze „Zähler für nicht gefundene Dateien“ auf 0 Abbruch der Suche Start der Berechnung Zähler kleiner als Schwellwert Genügend Stücke gefunden Nicht genügend Stücke gefunden ο· ο· Zähler gleich Schwellwert ο· Erhöhe „Zähler für nicht gefundene Dateien“ um eins Abbildung 3-2 Schematischer Ablauf der Suche nach Dateien 3.4 Rollen und Zustände In diesem Abschnitt werden noch einmal die Rollen und die Zustände innerhalb von DuDEbesprochen. In Abbildung 3-3 ist das Zustandsdiagramm dargestellt. Am Anfang befindet sich jeder Peer in dem „Freien“ Zustand. Wird eine Anfrage nach Ressourcen gestellt, wechselt ein Peer in den Zustand „Blockiert“. In diesem Zustand antwortet er auf keine DuDE-Nachricht außer Beförderungsnachrichten oder Freigabenachrichten. Durch die Nachricht „Freigeben“ kehrt ein Peer wieder in den „Freien“ Zustand zurück. Durch die Nachricht „Befördern zum Job-Scheduler“ wechselt ein Peer in den Zustand Job-Scheduler. Diesen Zustand kann der Peer nur alleine verlassen und auch hier beantwortet er währenddessen keine DuDE-Nachricht. Durch die Nachricht „Befördern zum Task-Watcher“ wechselt ein Peer in den Zustand „TaskWatcher“. Dieser Zustand ist mit dem Zustand „Job Scheduler“ identisch und wurde nur für eine saubere Trennung eingeführt. Kapitel: DuDE-Konzept - 24 - DuDE-Konzept - Rollen und Zustände Aufgabe wurde berechnet Blockiert Frei Ressourcen Anfrage Antworte auf Ressourcen Anfragen Starte Timer Keine Antwort auf Ressourcen Anfragen oder befördern zum Task-Watcher Nachricht: „Befördern zum Job-Scheduler“ erhalten Job-Scheduler Verteilen, Überwachen der Tasks Keine Antwort auf Ressourcen Anfragen Timer abgelaufen o. Nachricht: „Freigeben“ erhalten Nachricht: „Befördern zum Task-Watcher“ erhalten Task-Watcher Durchführen vom Task Keine Antwort auf Ressourcen Anfragen Aufgabe abgeschlossen oder abgebrochen Abbildung 3-3 Zustandsdiagramm von DuDE In Tabelle 3-1 werden die Rolle von DuDE genannt und ihre Funktionen erklärt. Rolle Job-Scheduler Sucher Job-Scheduler Task-Watcher Aufgabe Mit diesem Peer verbindet sich ein Administrator. Seine Aufgabe ist es eine Ressourcen Suche durchzuführen und den JobScheduler zu bestimmen Wird dynamisch ermittelt und teilt den Job in einzelne Aufgaben und verteilt diese, sammelt diese oder verteilt sie neu, wenn eine definierte Zeit vergangen ist und schickt das Gesamtergebnis an den Administrator. Sammelt die notwendigen Dateien ein, führt die Berechnungen aus und sendet die Ergebnisse an den Job-Scheduler. Tabelle 3-1 Überblick über die Rollen und deren Aufgabe bei DuDE Kapitel: DuDE-Konzept - 25 - Simulation - Warum Eigenentwicklung? 4 Simulation In dem nachfolgenden Abschnitt werden der Simulator und seine Funktionsweise beschrieben. Vor allem wird kritisch auf die Modellierung eingegangen und deren Rahmenbedingungen genannt. 4.1 Warum Eigenentwicklung? Im Bereich P2P gibt es bereits verschiedene etablierte Simulationssoftware wie ns-2 oder Oversim. Basierend auf der Diskussion in [3] würde nur ns-2 in Betracht kommen, da in der Fragestellung vor allem auch das physikalische Underlay berücksichtigt werden muss. Das Problem an ns-2 ist, dass er aufgrund der sehr genauen Abbildung das Underlays und des Durchlaufens des gesamten TCP/IP-Protokoll-Stack zu langsam für diese Aufgabenstellung wäre. Hinzu kommt, dass die Simulation auch nicht den TCP/IP-Protokoll-Stack benötigt. Die Modellierung erfolgt auf einen andere Art und Weise. Es wird für diese sehr spezielle Aufgabenstellung ein Abstraktionsniveau gewählt, das dafür sorgt, dass der Simulator hinreichend schnell ist. Der Nachteil davon ist, dass sich der Simulator eher schlecht beziehungsweise mit hohem Aufwand an eine andere Aufgabenstellung anpassen lässt. Ein großes Problem bei einer Eigenentwicklung ist die Verifizierung der Ergebnisse. Um diese zu gewährleisten, werden umfangreiche Dateien angefertigt, die detailliert über den Weg und das Zeitverhalten eines Paketes Aufschluss geben. Anhand dieser Dateien, die später auch zur Auswertung genutzt werden, kann eine Plausibilitätsprüfung der Ergebnisse erfolgen. 4.2 Verwendete Technologien Die verwendete Programmiersprache ist C# im .NET-Framework. Das .NET-Framework und C# sind Entwicklungen des Softwarehersteller Microsoft. Das .NET-Framework besteht aus zwei großen Teilen, das ist zum einen eine umfangreiche Klassenbibliothek mit fertigen Lösungen für z.B. Auflistungen und Serialisierung und zum anderen eine Laufzeitumgebung, die Common Language Runtime (CLR). Die CLR ist unteranderem für Speichermanagement und das Typsystem verantwortlich. Das .NET-Framework ist Sprach- und Plattformunabhängig13, 13 Voraussetzung dafür ist, dass es eine Implementierung für das .NET-Framework für die Plattform existiert. Ähnlich der Virtuellen Maschine von Java. Microsoft hat bis jetzt nur eine Implementierung für die Windows Client und Server Betriebssysteme bereitgestellt. Es existiert aber eine Implementierung auf Linux-Basis, die sich Mono nennt. Kapitel: Simulation - 26 - Simulation - Modellierung was dadurch erzeugt wird, dass ein Zwischencode definiert wird, der Common Intermedia Language (CIL). ). Der C#-Compiler erzeugt CIL-Code. Erst zur Laufzeit wandelt eine Komponente der CLR, nämlich der Just-In-Time-Compiler, den CIL-Code, in den für die spezifische Plattform verständlichen Assembler-Code um. Die Sprachunabhängigkeit basiert zum einem auf dem eben genannten CIL-Code und zum anderen auf einer gemeinsamen Typdefinition, die Common Type Specification (CTS). Diese Definition ermöglicht es, dass bei einem Wechsel der Sprache keine Typenkonvertierung stattfindet muss, da genau dieselben Typen verwendet werden. Microsoft selbst bietet auch eine integrierte Entwicklungsumgebung (engl. integrated development environment (IDE)) zum Entwickeln mit dem Namen Visual Studio an. Der Simulator selbst wurde mit der Version 2012 Professional entwickelt. Da der zeitliche Aufwand für diese Arbeit zwölf Wochen betrug und auch aus den in Abschnitt 4.1 genannten Gründen eine Eigenentwicklung effizient ist, hat der Autor dieser Arbeit diese Technologie gewählt, da die große Klassenbibliothek es ermöglicht, sich beim Programmieren auf das Wesentliche zu konzentrieren. Auch bestand keine Anforderung, dass die Simulationssoftware auf einen Unix/Linux-Umgebung lauffähig sein oder systemnah implementiert werden muss. Ein weiter wichtiger Fakt ist, dass Multithreading im .NETFramework relativ unkompliziert möglich ist, wenn man die Klassen threadsicher auslegt und der Simulator immens vom Multithreading profitiert. 4.3 Modellierung In diesem Abschnitt wird erläutert, wie die Modellierung, also das Abstrahieren des DuDESystems und des Netzes, im Simulator stattfindet. Des Weiteren werden auch die Randbedingungen für den Simulator genannt. 4.3.1 Peers Der Simulator unterteilt den Peer in zwei Ebenen. Die obere Ebene, „Peer“ genannt, symbolisiert alles, was mit dem Overlay zu tun hat. Ein Peer besitzt also eine Routing-Tabelle, die in Buckets eingeteilt ist und implementiert Logik, um diese Tabelle instand zu halten, also neue Peers in das richtige Bucket einzuordnen, die Lebenszeit zu überwachen, wenn nötig einen Peer zu kontaktieren um zu testen, ob dieser noch im Netz ist sowie abgelaufene Peers zu entfernen. Auch zählt dazu das BootstrappingKapitel: Simulation - 27 - Simulation - Modellierung und Lookup-Verfahren. Des Weiteren implementiert auch ein Peer alle notwendige Logik für DuDE und ist in der Lage, beliebige Nachrichten an andere Peers zu schicken. 4.3.2 Topologie Der untere Teil eines Peers wird im Folgenden als „Node“ bezeichnet. Ein Node stellt dabei eine Abstraktion aller physischen Komponenten eines Peers dar. Dem entsprechend kann es immer auch Nodes geben, denen kein Peer zu geordnet ist. Umgekehrt gilt dies nicht. Die Aufgabe eines Nodes ist, das Underlay zu darzustellen und Nachrichten mit anderen Nodes auszutauschen. Dabei erzeugen Nodes nie selbst Nachrichten14, sondern nehmen die Nachricht ihrer übergeordneten Peers entgegen und stellen diese im Netz zu. Für den Simulator wird die Topologie aus Abschnitt 2.1.3.3 angenommen. Dabei sind die DSLAM an einen Konzentrator angeschlossen und die Konzentratoren sind untereinander vermascht. 15 Die Modellierung erfolgt derart, dass ein Node Nachbarn haben kann. Mit diesem Nachbarn verbindet ihn eine „Physical Line“. An diesem Modell sind Eigenschaften wie Verzögerung und maximale Last hinterlegt. Beim Generieren der Topologie können neben der Anzahl der Nodes noch weitere Parameter festgelegt werden. Dazu zählen maximale und minimale Verzögerung der Leitung, sowie durchschnittliche Anzahl der DSLAM an einem Konzentrator und die durchschnittliche Anzahl der Verbindungen zwischen den Konzentratoren. Des Weiteren wird davon ausgegangen, dass die minimale Verzögerung zwischen den Konzentratoren auftritt und die maximale zwischen einem DSLAM und einem Konzentrator. Dies soll dem Sachverhalt der unterschiedlichen Bandbreiten Rechnung tragen. Genauso kann die Verzögerung als Maß für sonstige Aktivitäten im Netz verstanden werden, die die Zustellung von allen Nachrichten des System DuDE verzögert. Damit ein Node einem anderen eine Nachricht zukommen lassen kann, müssen die Wege bestimmt werden. Dazu verfügt auch ein Node über eine Routing-Tabelle. Diese ist in keinerlei Weise mit der Routing-Tabelle eines Peers zu verwechseln, sondern ist eher mit der eines realen Routers zu vergleichen. Darin wird eine Zuordnung zwischen Ziel und Node getroffen, die auf dem Weg zum Ziel das nächste Element wäre. 14 Zum Testen der Topologie existiert eine Ping-Methode, bei der Nodes sich direkt Nachrichten schicken, die aber in der Simulation nie aufgerufen wird. 15 Darüber hinaus ist aus auch möglich ein vermaschtes Netz als Topologie zu wählen Kapitel: Simulation - 28 - Simulation - Modellierung Die Wegfindung durch ein auf diese Weise generiertes Netz erfordert einen Algorithmus. In der Praxis kommen verschiedene Protokolle für das Routing innerhalb eines WAN-Netzes eines Providers vor. Für die Simulation wurde auf eine Art Link-State Protokoll implementiert. Bei solchen Routing-Protokollen kennt ein jeder Teilnehmer das gesamte Netz aus seiner Perspektive und trifft eigenständig Entscheidungen, wie der beste Weg durch das Netz ist. Dabei werden Nachbarschaftstabellen gepflegt. Wenn verschiedene Wege zu einem Ziel führen, wird der Weg präferiert, der die geringsten Kosten zu einem Ziel hat. Im Simulator sind die Kosten mit der Anzahl der Hops identisch. Da ein solches Verfahren schlecht mit steigender Anzahl von „Nodes“ skaliert, werden „Areas“ eingeführt. Ein normaler Node in einer Area, die keine Verbindung zu anderen Areas hat, wird Inner-Area-Node genannt und kennt alle anderen Nodes in der Area. Nodes, die Verbindungen in mehrere Areas haben, werden als Border-Nodes bezeichnet. Border-Nodes haben Kenntnissen von allen anderen Border-Nodes unabhängig der Area. Möchte ein Inner-AreaNode ein Ziel in einer anderen Area erreichen, werden alle Border-Router der Area kontaktiert und es wird die Route übernommen, welche die geringsten Kosten aus der Summe zum Border-Router und vom Border-Router in die entsprechende Area hat. So kennt man Ende eine jede Node, alle Ziele in der eigenen Area und einen Weg in jede andere Area. Dieser Algorithmus ist an den Routing-Algorithmus des Protokolls Open Shortest Path First (OSPF) angelehnt. Nachfolgend ist der Sachverhalt für die Kostenermittlung innerhalb einer Area detailliert dargestellt. Für das Beispiel wird das Netz aus Sicht von „Node 0“ analysiert. Die für einen Schritt wichtigen Nodes sind blau hinterlegt; alle anderen grau. Node ID: 2 Node ID: 0 Node ID: 3 Konzentrator 1 ID: 10 Konzentrator 2 ID: 20 Konzentrator 3 ID:30 Kapitel: Simulation Node ID: 4 Im ersten Schritt wird die Entfernung zu sich selbst bestimmt. Routing-Tabelle: Ziel Kosten NextHop 0 0 0 Node ID: 5 - 29 - Simulation - Modellierung Node ID: 2 Node ID: 0 Node ID: 3 Konzentrator 1 ID: 10 Konzentrator 2 ID: 20 Konzentrator 3 ID:30 Node ID: 2 Node ID: 0 Node ID: 3 Konzentrator 1 ID: 10 Node ID: 0 Node ID: 3 Konzentrator 1 ID: 10 Node ID: 5 Node ID: 4 Konzentrator 2 ID: 20 Konzentrator 3 ID:30 Node ID: 2 Node ID: 4 Node ID: 5 Node ID: 4 Konzentrator 2 ID: 20 Konzentrator 3 ID:30 Node ID: 5 Jetzt sollen die Ziele von allen Nachbarn erfragt werden. Es gibt zurzeit nur einen Nachbarn. Der Konzentrator mit der ID 10. Routing-Tabelle: Ziel Kosten NextHop 0 0 0 10 1 10 Jetzt werden alle Nachbarn von Node 10 befragt und entsprechend in die RoutingTabelle eingefügt. Routing-Tabelle: Ziel Kosten NextHop 0 0 0 10 1 10 2 2 10 20 2 10 30 2 10 Auch jetzt werden wieder die Nachbarn erfragt. Da Konzentrator 1 mit der ID 10 bereits befragt wurde, wird dieser nicht erneut befragt. Der Konzentrator hat als Nachbarn ebenfalls den Konzentrator 2. Dieser hätte aber jetzt die Kosten 3 und wird dementsprechend nicht in die Routing-Tabelle eingefügt. Damit sieht ist die RoutingTabelle fertig Ziel Kosten NextHop 0 0 0 10 1 10 2 2 10 20 2 10 30 2 10 3 3 10 4 3 10 5 3 10 Abbildung 4-1 Ermittlung des Weges für ein Netz innerhalb einer Area Dieser Vorgang müsste für jeden Node in der der Area wiederholt werden. Der Vorgang würde ebenso abbrechen, wenn der nächste Nachbar nicht mehr in derselben Area wäre. Die BorderKapitel: Simulation - 30 - Simulation - Modellierung Nodes füllen ihre Border-Node-Routing-Tabelle auf dieselbe Weise, nur eben bezogen auf andere Border-Nodes. In Abbildung 4-2 ist eine Topologie gezeigt, die mehrere Areas hat. Mit IA sind der Abbildung Inner-Area-Nodes bezeichnet. Das B steht für Border-Node. Area 0 IA 10 Area 1 B 121 B 19 IA 114 B 117 Area 2 B 0 IA 90 Outer-Area-Routing-Tabelle Node 10: Ziel Kosten NextHop Area 1 2 121 Area 2 2 117 Outer-Area-Routing-Tabelle Node 117: Ziel Kosten NextHop Area 1 3 10 Area 2 1 0 Outer-Area-Routing-Tabelle Node 114: Ziel Kosten NextHop Area 0 2 19 Area 2 5 19 Abbildung 4-2 Beispiele für die Outer-Area-Routing-Tabelle von verschiedenen Nodes 4.3.3 Daten Die Modellierung der Daten ist simpel gehalten. Sie verfügen über eine Größe und einen Datentyp (RAM, CPU, Paketverlust etc.). Aus dem Datentyp und der Knotenidentifikation wird der Name der Datei erstellt. Die Größe einer Datei wird über einen Zufallsgenerator bestimmt, obgleich die Maximal- und Minimalgröße für jeden Datentyp angegeben werden kann. Die Zufallsvariable ist dabei gleichverteilt. Darüber hinaus lässt sich eine Datei teilen und aus Teilen wieder zusammensetzen. Dem Simulator kann neben dem periodischen Verteilen auch eine durchschnittliche Rate mitgeteilt werden, in dem die Dateien verteilt werden sollen. Dies modelliert das Auslösen von Ereignissen, die ein Erneuern der Log-Dateien nach sich ziehen würden. Kapitel: Simulation - 31 - Simulation - Modellierung 4.3.4 Jobs und Tasks Auch diese Teile des DuDE-Systems sind simpel gehalten. Ein Job besteht aus Tasks. Der Job, der vom Administrator erstellt wird, enthält dabei zwar auch schon Tasks z.B. die Berechnung der CPU-Statistik von allen Peers. Diese entsprechen aber nicht den später verteilten Statistiken. Sobald ein Job-Scheduler gewählt wurde, beginnt dieser die vorhandenen Tasks entsprechend der maximalen Anzahl von Peers pro Task zu teilen. Diese Tasks werden dann später verteilt. Die Teilung erfolgt dabei in regelmäßigen Abständen. Beinhaltet der Job beispielsweise die Berechnung der CPU- und RAM-Auslastung von allen Zugangspunkten und das Netz umfasst 1000 Peers und eine Aufgabe soll nicht mehr als 400 Peers umfassen, so würden die Aufgaben entsprechend der Tabelle 4-1 geteilt werden. Nr. 1 2 3 4 5 6 Type RAM RAM RAM CPU CPU CPU Peers 0-400 400-800 800-1000 0-400 400-800 800-1000 Tabelle 4-1 Aufteilung des Jobs in seine Task am Beispiel RAM- und CPU-Auslastung von 1000 Peers bei einer maximal Größe von 400 Peers pro Aufgabe 4.3.5 Berechnung von Tasks und Ressourcen-Metrik Hat ein Task-Watcher alle für die Aufgaben benötigten Dateien eingesammelt, beginnt die Berechnung. Dies wird derart simuliert, dass pro Dateityp und Datei eine bestimmte Anzahl von Rechenschritten benötigt wird. Die Gesamtanzahl von Rechenschritten für eine Aufgabe ist also das Produkt aus den gefundenen Dateien und der pro Datei notwendigen Rechenschritte. Ein Node wiederrum verfügt über eine Größe, die besagt, wie viele Rechenschritte pro Zeiteinheit abgearbeitet werden können. Diese Größe wird an den Node gebunden, da dies mehr etwas Physisches als Logisches P2P-Element ist. Diese Art der Modellierung soll den Kennwerten Million Instructions Per Second (MIPS) bzw. Floating Point Operations Per Second (FLOPS) entsprechen. Für die Ressourcen-Metrik wird folgende Formel angewandt. π = π1 ∗ ππππππ π π΄π + π2 ∗ πΆππ πΏπππ π‘π’ππ + π3 ∗ (1 − π π΄π π΄π’π πππ π‘π’ππ) + π4 ∗ (1 − πΆππ π΄π’π πππ π‘π’ππ) Formel 4-1 Berechnung der Ressourcen Kapitel: Simulation - 32 - Simulation - Funktionsweise des Simulators (Wie schickt Peer A an Peer B eine Nachricht) Dabei stellen die Faktoren π1 bis π4 Gewichtungen der einzelnen Komponenten dar, die beliebig angepasst werden können. Die Parameter die in der Formel 4-1 vorkommen sind Eigenschaften eines Nodes. Diese werden zufällig über die Nodes verteilt. Die Verteilung entspricht dabei einer Normalverteilung16. Die Standardabweichung und der Mittelwert sind dabei einstellbar. 4.4 Funktionsweise des Simulators (Wie schickt Peer A an Peer B eine Nachricht) Alle im Simulator vorkommenden Zeiten werden als Einheitszeiten dargestellt. Dabei kann definiert werden, wie groß eine Einheitszeit später sein soll. Diese Zeit stellt die Schrittweite eines Simulationsschrittes dar. In der eigentlichen Simulation wird später Schritt für Schritt simuliert. Bei jedem Schritt verringern die Peers zum Beispiel die Lebenszeit ihrer Kontakte in der Routing-Tabelle. Des Weiteren basiert das gesamte Nachrichtensystem auf diesen Zeitschritten. Möchte ein Peer eine Nachricht senden, so wird diese zuerst in einen Peer internen Puffer geschrieben. Fährt die Simulation einen Schritt weiter, werden diese Nachrichten an die darunter liegenden Node weitergegeben. Die Node wiederum liest für jede Nachricht im Eingangs-Buffer, der durch den Peer oder anderen ankommende Nachrichten anderer Nodes gefüllt wird, aus dem Ziel-Peer die Ziel-Node aus und schaut in seiner Routing-Tabelle nach, was der Next-Hop ist. Sollte er selbst das Ziel sein, wird die Nachricht in den Eingangs-Buffer des Peer geschrieben. Da der Next-Hop immer ein Nachbar ist und alle Nodes mit Physical Line verbunden sind, kann der Node die Verzögerung ermitteln. Anschließend wandert die Nachricht in den Ausgangs-Buffer mit einem Vermerk auf die noch zu wartenden Zeit. Neben dem Auslesen des Eingangs-Buffers wird auch der Vermerk der Wartezeit der Nachrichten im Ausgangs-Buffer um eine Einheit dekrementiert. Ist der Wert kleiner oder gleich null, wird die Nachricht an die nächste Node geschickt und landet in deren EingangsBuffer. Es wird jedoch pro Zeitschritt jeweils nur eine Nachricht auf einer Leitung verschickt. Dadurch kann es passieren, dass Nachrichten länger als die angegeben Verzögerung im Ausgangs-Buffer verbleibet. 16 Das .NET-Framework besitzt keine Klasse um eine Normalverteilung zu erzeugen, dafür aber eine Klasse die eine Gleichverteilung erzeugt. Mit Hilfe der Box-Müller Transformation lassen sich daraus eine normal verteilte Zufallsvariable berechnen. Kapitel: Simulation - 33 - Simulation - Funktionsweise des Simulators (Wie schickt Peer A an Peer B eine Nachricht) Auch ein Peer prüft in jedem Zeitschritt seine Nachrichten im Eingangs-Buffer und reagiert dementsprechend. In Abbildung 4-3 ist die Kommunikation für einen Ping beispielhaft dargestellt. Es wird davon ausgegangen, dass zur selben Zeit keine anderen Peers kommunizieren Buffer Peer 789 0 Eingang Ausgang Type: Ping Quelle-Peer: 789 Ziel-Peer: 432 Peer ID: 432 Peer ID: 789 Node ID: 5 Verzg: 2 Node ID: 0 Verzg: 4 Node ID: 5 1 Node ID: 7 Peer ID: 432 Peer ID: 789 Verzg: 2 Node ID: 0 Verzg: 4 Der Peer mit der ID 789 möchte den Peer 432 einen Ping senden. Im ersten Schritt wird diese Nachricht erzeugt und in den Ausgangs-Buffer vom Peer gelegt. Der Zeitschritt ist in der oberen linken Ecke dargestellt. Node ID: 7 Im nächsten Zeit-Schritt wandert die Nachricht vom Ausgangs-Buffer des Peers in den Eingangs-Buffer vom dazugehörigen Node. Buffer Node 5 Eingang Ausgang Type: Ping Quelle-Peer: 789 Ziel-Peer: 432 Peer ID: 432 Peer ID: 789 Node ID: 5 1 Verzg: 2 Node ID: 0 Verzg: 4 Node ID: 7 Noch im selben Zeitschritt wird ein Eingangs-Buffer ausgewertet. Für jede Nachricht im Eingangs-Buffer wird der Next-Hop ermittelt und eine dem entsprechende Wartezeit ein. Buffer Node 5 Eingang Ausgang Ziel-Node: 7 Next-Hop: 0 Wartezeit: 2 Kapitel: Simulation - 34 - Simulation - Funktionsweise des Simulators (Wie schickt Peer A an Peer B eine Nachricht) Peer ID: 432 Peer ID: 789 Node ID: 5 3 Node ID: 0 Verzg: 2 Node ID: 7 Verzg: 4 Für die nächsten beiden Zeitschritte passiert nichts. Ist die Wartezeit bei 0 angekommen, wird die Nachricht an den nächste Node geschickt und ladet dort entsprechend im Eingangs-Buffer. Buffer Node 0 Eingang Ausgang Ziel-Node: 7 Peer ID: 432 Peer ID: 789 Node ID: 5 3 Verzg: 2 Node ID: 0 Node ID: 7 Verzg: 4 Noch im selben Zeitschritt wird die Nachricht im Ausgangs-Buffer von Node 0 verschoben. Node 0 hat das Ziel ausgewertet, den nächsten Hop ermittelt und die Wartezeit eingefügt Buffer Node 0 Eingang Ausgang Ziel-Node: 7 Next-Hop: 7 Wartezeit: 4 Peer ID: 432 Peer ID: 789 Node ID: 5 7 Node ID: 0 Verzg: 2 Verzg: 4 Node ID: 7 Die nächsten 4 Zeitschritte passiert nichts. Ist die Wartezeit vergangen, wird die Nachricht zur Node mit der ID 7 zugestellt. Buffer Node 7 Eingang Ausgang Ziel-Node: 7 Buffer Peer 432 7 Peer ID: 789 Eingang Type: Ping Quelle-Peer: 789 Ziel-Peer: 432 Node ID: 5 Verzg: 2 Node ID: 0 Ausgang Peer ID: 432 Verzg: 4 Node ID: 7 Node 7 hat festgestellt, dass die Nachricht für ihn bestimmt war und leitete die Nachricht in den EingangsBuffer vom Peer mit der ID 432 weiter. Im nächsten Zeitschritt, also Zeitschritt 8 würde der Peer seinen Eingangspuffer lesen und entsprechend antworten. Abbildung 4-3 Modellierung der Kommunikation zwischen zwei Peers Auf diese Art und Weise wird versucht das physikalische Verhalten von Netzkoppelelementen wie Router und Switches nachzubilden, die sich bezogen auf die Buffer genauso verhalten. Die Kapitel: Simulation - 35 - Simulation - Möglichkeiten des Simulators Verzögerungszeit in diesen Geräten entsteht, weil der Eingangs-Buffer schneller gefüllt als das Nachrichten verschickt werden können. Ein Problem an dieser Modellierung ist, dass davon ausgegangen wird, dass jede übertragene Nachricht aus genau einem Segment, einem Packet und einem Frame besteht. Für alle UDPNachrichte, mag dies noch gelten, aber für die Übertragung von Log-Dateien trifft dieses nicht mehr zu. 4.5 Möglichkeiten des Simulators Der Simulator bietet einige Möglichkeiten um das Verhalten zu steuern. So kann beispielweise eine Verlustrate von Paketen pro Sekunde angegeben werden. Der Verlust wird derart modellieret, dass einer Node mitgeteilt wird, dass diese ein Paket aus dem Ausgangs-Buffer entfernen soll. Bei einer TCP basierte Übertragung kann kein Paketverlust auftreten. Um dies zu verwirklichen, werden ausschließlich Pakete aus dem Buffer entfernt, die mit UDP transportiert werden. Um zu verhindern, dass alle Peers ähnliche Timer haben, besteht die Möglichkeit eine Rate vorzugeben in denen die Peers dem Netzwerk beitreten. Treten alle Peers zur selben Zeit bei, kann es vorkommen, dass das Netz geflutet wird. Dieses Verhalten erhöht die Dauer der Simulation signifikant. Um den Startzeitpunkt von einem Job festzulegen, gibt es zwei Möglichkeiten. Entweder wird eine Zeitspanne angegeben, die aussagt wie viele Sekunden nach dem Start der Simulation der Job verteilt werden soll oder man gibt eine Zeitspanne, die sich auf den Beitritt des letzten Peers in das Netzwerk bezieht. Letztes hat den Vorteil, dass die Simulationszeit verkürzt wird. Diese Einstellung soll ein konvergiertes Netz symbolisieren. Darüber hinaus ist der Simulator auch in der Lage ein dynamisches Netz abzubilden. Dazu gibt es die Option das Peers das Netz nur temporär verlassen um beispielsweise einen Neustart durchzuführen oder dauerhaft. Ebenso ist es möglich eine Generationsrate von Peers vorzugeben. 4.6 Parameter der Simulation Um bei der Simulation viele Freiheitsgrade zu haben, basiert der Simulator auf Einstellbaren Parametern. Tabelle 4-2 zeigt eine Auswahl der Parameter. Kapitel: Simulation - 36 - Simulation - Wie werden Ergebnisse produziert? Name im Simulator DataParts Erläuterung Anzahl der Datenstücke die bei der Teilung einer Datei entstehen sollen CodingParts Anzahl der Kodierungsstücke die bei der Teilung einer Datei entstehen sollen MinPeerAmountForShareData Minimale Anzahl an Peers, die ein und dasselbe Dateistück erhalten sollen CPUSpeedWeigth Gewichtung der CPU-Geschwindigkeit bei der Ressourcen Metrik RAMAmountWeigth Gewichtung der RAM-Größe bei der Ressourcen Metrik MaxAmountOfPeersForResponse Maximale Anzahl von Peers, die bei einem Lookup (Random, Self, Bootstrap) zurückgegeben werden sollen DHTBits Anzahl der Bits in der DHT-Tabelle. Dieser Wert kann nur geändert werden, wenn ein anderer HashAlgorithmus verwendet wird. KBucketLength Anzahl von Peers die maximal Platz in einem Bucket haben. TimeOutForGettingWholeData Die maximale Dauer die ein Task-Watcher wartet, bis er versucht die Stücke einer Datei zu suchen Tabelle 4-2 Übersicht über eine Auswahl der Parameter des Simulators 4.7 Wie werden Ergebnisse produziert? Das Produzieren der Ergebnisse des Simulators basiert auf der Auswertung der Dateien, die während der Simulation geschrieben werden. Wird eine Nachricht durch das simulierte Netz transportiert, fügt jeder passierte Node einen Eintrag in der Route der Nachricht hinzu. Ist die Nachricht am Ziel angekommen, wird sie aus der Liste der aktiven Nachrichten entfernt und auf die Liste der zu speichernden Dateien hinzugefügt. Erreicht diese Liste eine bestimmte Größe werden die Daten aus dem Arbeitsspeicher in eine Datei geschrieben. Genauso wird mit geloggt, wenn ein Job oder ein Task begonnen und beendet wurde. Aus den gebrauchten Zeitschritten und der realen Dauer eines Zeitschrittes lässt sich die benötigte reale Zeit berechnen. Der Vorteil an dieser Variante liegt darin, dass zum Beispiel auch ein zeitlicher Verlauf der Nachrichten betrachten werden kann, selbst wann diese Funktion zur Zeit der Simulation noch nicht implementiert war. Zum Ende der Simulation wird zusätzlich auch das Setup sowie die Jobs als auch der Wert der Parameter in Dateien geschrieben. Das Auswertungswerkzeug liest diese Dateien ein, erzeugt Kapitel: Simulation - 37 - Simulation - Wie werden Ergebnisse produziert? die Ergebnisse und speichert diese in einer .CSV Datei, die mit verschiedenen Programmen wie Excel eingelesen werden kann. Kapitel: Simulation - 38 - Aufgaben und Auswertung - Vergleich Client-Server-Modell 5 Aufgaben und Auswertung Im folgenden Kapitel wird die Skalierbarkeit untersucht. Alle Daten, bis auf die Vergleichsrechnung mit dem Client-Server-Modell, wurden durch den in Kapitel 4 beschriebenen Simulator erzeugt. 5.1 Vergleich Client-Server-Modell Der Vergleich der Rechenzeit des Systems DuDE mit dem Client-Server-Modell ist rein theoretischer Natur und soll nur der Orientierung dienen. Das Client-Server-Modell ist kaum in der Lage, die Funktionalitäten von DuDE zu bieten. So müsste ein Server beispielsweise alleine bei 8000 Teilnehmern, drei verschiedene Dateitypen mit einer durchschnittlichen Größe von 1,2 Megabit pro Datei ein Datenvolumen von 28 Gigabyte verwalten. An dieser Stelle möchte der Autor die Formel vorstellen, die zur Berechnung der benötigten Zeit für das Client-Server-Modell verwendet wird. Dabei wird auf das Modell hinter der Formel eingegangen. Es wird das gleiche, auf Rechenschritte basierende Modell angewendet, wie auch bei dem Simulator. Die Anzahl der Rechenschritte für den Server kann dabei wie folgt bestimmt werden. π΅ππππβππ’πππ π§πππ‘ = π·ππ‘πππ‘π¦πππ ∗ π΄ππ§πβπ πππ π·ππΏπ΄π ∗ π ππβππππ πβπππ‘π‘π πππ π·ππ‘ππ π ππβππππ πβπππ‘π‘π πππ ππππ’πππ Neben der Zeit für die Berechnung muss noch die Zeit für das Sammeln der Dateien hinzugefügt werden. Dabei wird davon ausgegangen, dass der Server alle angeschlossenen Clients kennt, also kein Verwaltungsoverhead hinzukommt. Des Weiteren wird davon ausgegangen, dass die Bandbreite zwischen Server und allen Clients homogen ist, die Daten intern auch mit dieser Geschwindigkeit verarbeitet werden können und alle Dateien nach einander zum Server transportiert werden. Es wird ein Overhead kommend vom IP-Stack und weiteren Synchronisationsvorgängen, wie dem Anfragen nach Datei angenommen. Daraus ergibt sich folgende Formel: π·ππ‘ππππößπ = ∑ πΊπößπ πππππ πΈπππ§πππππ‘ππ π·ππ€πππππππππ‘ = π·ππ‘ππππößπ ∗ π΄ππ§πβπ πππ π·ππΏπ΄π ∗ (1 + ππ£ππβπππ) π΅ππππππππ‘π Die Gesamtzeit ist dann die Summe aus der Downloadzeit und der Berechnungszeit π΅ππöπ‘πππ‘πππππ‘ = π·ππ€πππππππππ‘ + π΅ππππβππ’πππ π§πππ‘ In der späteren Rechnung werden die Werte noch einmal entsprechend gesetzt und erklärt. Kapitel: Aufgaben und Auswertung - 39 - Aufgaben und Auswertung - Aufbau der Simulation 5.2 Aufbau der Simulation Die nachfolgenden Werte sind unter den nachfolgenden Bedingungen entstanden. Diese gelten sowohl für die Untersuchung der Skalierbarkeit als auch für die Betrachtung des Datenverkehrs. In der Simulation wurde ein Netz mit steigender Teilnehmeranzahl simuliert. Es wurde ein Bereich von 1000 bis 9000 Peers in 1000 Schritten abgedeckt. Dabei bestand der Job darin, für alle Peers im Netz die Statistik für RAM-, CPU-Auslastung und Paketverlust zu simulieren. Die Aufteilung in Tasks erfolgte in maximal 100, 200 und 300 Teilnehmern. Für den Vergleich wird angenommen, dass der Server eine 10-mal höhere Rechenleistung als ein durchschnittlicher Peer besitzt. Um die Leistungsfähigkeit von DuDE zu zeigen, ist auch eine Datenreihe beigefügt, die dem Server das 100-Fache der Leistung eines einzelnen Peers zuspricht, auch wenn diese Annahme nicht in der Praxis zutrifft. Alle weiteren Parameter für den Vergleich können der Tabelle 5-1 entnommen werden. Die Bezeichnung DuDE 100 bedeutet, das Ergebnis bezieht sich auf DuDE und der Job wurde derart geteilt, dass ein einzelner Task-Watcher nur von maximal 100 anderen Peers Statistiken berechnet. Beim Client-Server bezieht sich die Zahl hinter dem Namen auf den Faktor, wie viel schneller ein Server rechnen kann, als ein DuDE-Peer. Parameter Dateitypen Rechenschritte Peer-Rechenschritte Faktor Rechenschritte pro Sekunde Dateigröße in MB Overhead in Prozent Bandbreite in Mbits Wert 3 2000 30000 10 bzw. 100 300000 3,5 0,1 1000 Tabelle 5-1 Werte der Parameter für den Vergleich Client-Server und DuDE Es hat sich Tabelle 5-2 und das in Abbildung 5-1 dargestellte Diagram ergeben 5.3 Skalierbarkeit und Vergleich mit Client-Server (statisches Netz) Auf die Ergebnisse bzgl. der benötigten Zeit, die durch die Simulation gewonnen wurden, ist ein Unsicherheitsfaktor von 15% angerechnet worden. Dieser entsteht zum einen durch Modellierungsfehler, wie der Übertragung der Daten in nur einem Paket und weiterer Unsicherheiten. Kapitel: Aufgaben und Auswertung - 40 - Aufgaben und Auswertung - Skalierbarkeit und Vergleich mit Client-Server (statisches Netz) Teilnehmer DuDE 100 DuDE 200 DuDE 300 Client-Server 10 Client-Server 100 1000 28 47 60 51 33 2000 30 51 65 102 66 3000 32 46 62 152 98 4000 34 58 74 203 131 5000 34 43 78 254 164 6000 36 57 69 305 197 7000 55 66 75 356 230 8000 37 54 67 406 262 9000 36 58 52 457 295 Tabelle 5-2 Ergebnisse der Simulation und der Vergleichsrechnung. Alle Angaben bis auf die Teilnehmer sind in Sekunden Skallierungsverhalten von DuDE 140,00 130,00 120,00 Zeit in Sekunden 110,00 100,00 90,00 80,00 70,00 60,00 50,00 40,00 30,00 20,00 10,00 1000 2000 3000 4000 5000 6000 7000 8000 9000 Anzahl der Zugangsknoten DuDE 100 DuDE 200 DuDE 300 Client-Server 10 Client-Server 100 Abbildung 5-1 Skalierungsverhalten von DuDE im Vergleich zum Client-Server-Model Sowohl in Tabelle 5-2 als auch im Abbildung 5-1 ist deutlich zu erkennen, dass das System DuDE wesentlich besser skaliert als das Client-Server-Modell. Dieses Modell, verhält sich, wie in der Modellierung angenommen, linear. Der begrenzende Faktor bei diesem Modell ist die Bandbreite. Dennoch lässt sich erkennen, dass gerade im Bereich unter 2000 Teilnehmer der schnellere Server fast genauso wenig Zeit benötigt wie das System DuDE. Dies unterstreicht die Annahme, dass sich ein solches System erst ab einer großen Anzahl von Teilnehmern lohnt. Betrachtet man die einzelnen DuDE-Kurven so lässt sich erkennen, dass mit steigender Anzahl von Teilnehmern nur minimal mehr Zeit benötigt wird. So beträgt der Anstieg der Kapitel: Aufgaben und Auswertung - 41 - Aufgaben und Auswertung - Skalierbarkeit und Vergleich mit Client-Server (statisches Netz) Regressionsgraden für den Fall DuDE-100 0,0015. Dies bedeutet, dass mit 1000-Teilnehmern mehr, nur 1,5 Sekunden mehr Zeit benötigt wird. Die Verhältnisse für die anderen DuDEKurven sind ähnlich. 5.3.1 Auswirkung des Parameters Peers Pro Task-Watcher Im nachfolgenden wird der Parameter, der bestimmt, wie groß die maximale Anzahl von Peers ist, von denen ein Task-Watcher die Daten einsammelt und daraus die Statistiken berechnet, Anzahl der Peers pro Task genannt. Es lässt sich erkennen, dass das System DuDE umso weniger Zeit benötigt, je geringer die Anzahl der Peers pro Task ist. Dies unterstreicht den dezentralen Charakter. Tabelle 5-3 zeigt das Verhältnis der Zeiten von DuDE-100 und DuDE-200, sowie von DuDE-100 und DuDE-300 und DuDE-200 und DuDE-300. Teilnehmer 1000 2000 3000 4000 5000 6000 7000 8000 9000 π«ππ«π¬ − πππ π«ππ«π¬ − πππ 1,7 1,7 1,4 1,7 1,3 1,6 1,2 1,5 1,6 π«ππ«π¬ − πππ π«ππ«π¬ − πππ π«ππ«π¬ − πππ π«ππ«π¬ − πππ 2,1 1,3 2,1 1,3 1,9 1,3 2,2 1,3 2,3 1,8 1,9 1,2 1,4 1,2 1,8 1,2 1,5 0,9 Tabelle 5-3 Zeitliche Skalierung wenn unterschiedliche Anzahl an Peers pro Task gewählt werden Aus der Tabelle 5-3 lässt sich entnehmen, dass die Skalierung bzgl. Anzahl der Peers pro Task nicht linear ist. So wurde für die Berechnung der Statistiken von 8000 Peers bei der Datenreihe DuDE-200 nur das 1,5-fache wie bei der Datenreihe DuDE-100, obgleich sich die Anzahl der Peers pro Task verdoppelt hat. Deutlicher wird dieser Zusammenhang bei 9000 Peers und der Messreihe DuDE-300 und DuDE-200. Hier war die benötigte Zeit für DuDE-300 10 Prozent geringer als für DuDE-200. Des Weiteren ist zu erkennen, dass der Unterschied umso geringer wird, je mehr Teilnehmer ein solches Netz haben. Das wellenartige Verhalten der Kurven in Abbildung 5-1 ist dem Zufall geschuldet. Es ist möglich, dass ein Peer als Job-Scheduler gewählt wurde, der nicht genügend andere Peers in seiner Routing-Tabelle kannte. Dadurch wurde die Suche nach Ressourcen rekursiv ausgeführt und es muss auf das Ablaufen des Timers gewartet werden. Diese Abweichungen dürfen nicht Kapitel: Aufgaben und Auswertung - 42 - Aufgaben und Auswertung - Analyse des erzeugten Datenverkehrs als Fehler interpretiert werden, sondern sind Ausdruck der Dynamik in einem P2P-Netz. Es gibt Konfigurationen (Hashwerte, Position im Underlay und DuDE-Rollen), die ein sehr günstiges Verhältnis erzeugen, wie bei dem Datenpunkt DuDE-300 und 9000 Teilnehmern und eben solche, wie bei allen DuDE-Kurven und bei der Teilnehmeranzahl 7000. 5.4 Analyse des erzeugten Datenverkehrs Die Funktionalitäten und die Geschwindigkeit von DuDE gehen mit einem Anstieg des Datenverkehrs einher. Dieser Abschnitt analysiert die Daten des Simulators bzgl. des Datenverkehrs. Anzahl Simulierte Zeit Datenmenge Datenmenge pro Peer und pro Zugangsknoten (s) (GB) Sekunde (KB) 1000 54 6,04 2000 67 9,74 3000 72 13,85 4000 93 18,16 5000 89 21,53 6000 111 26,12 7000 127 30,63 8000 129 33,75 9000 140 38,02 107 70 61 47 46 37 33 31 29 Tabelle 5-4 Datenvolumen für die DuDE-200 Messreihe In Tabelle 5-4 ist das Datenvolumen für die Messreihe DuDE-200 angegeben. Hierbei wurde die Datenmenge um 10% erhöht, um nicht betrachtete Aspekte wie eventueller Neusendung von Paketen durch TCP, Fragmentierungseffekt und weitere Modellierungsfehler zu berücksichtigen. Es wird nur diese Messreihe dargestellt, da sich die anderen nicht signifikant von dieser unterscheiden. Es ist zu erkennen, dass die Simulationszeit mit der Anzahl der Teilnehmer zunimmt. Dies liegt zum einen daran, dass der Job länger braucht, um erledigt zu werden und zum anderen an einer Einstellung im Simulator, denn die Rate, in der die Peers in das Kad-Netz beitreten, ist konstant und ein Job startet immer erst, nachdem alle Peers das Netzwerk betreten haben. Dies ist notwendig um einen Gleichtakt der Peers zu verhindern. Dementsprechend ist die Datenrate pro Peer und pro Sekunde bei niedrigen TeilnehmerAnzahlen höher. Bei längeren Simulationszeiten relativiert sich das Datenvolumen. Deswegen sind eher die letzten Messwerte als realistisch anzusehen. Nachfolgend sind Tabellen und Diagramme dargestellt, die die Verteilung auf die Datenpakte innerhalb eines Durchgangs zeigen. Kapitel: Aufgaben und Auswertung - 43 - Aufgaben und Auswertung - Analyse des erzeugten Datenverkehrs Nachrichten-Typ DuDE-200 1000 Teilnehmer DuDE-200 8000 Teilnehmer Größe (Byte) Anteil Größe (Byte) Anteil Bootstrap 26973 0% 215973 0% Ping 10503 0% 122742 0% Ping Answer 10503 0% 122742 0% Look Up 840 0% 126 0% Store Data 2267338752 38% 3860642564 12% Lookup Answer 1123261 0% 11751338 0% Find File 670800 0% 6915100 0% Find File Answer 3630036242 62% 29063358828 88% Get Resource Metric 4212 0% 266814 0% Get Resource Metric Answer 5032 0% 163725 0% DuDE Unfrozen 830 0% 1070 0% Promote To Job Schedular 27 0% 27 0% GetTaskMessage 15000 0% 120000 0% Worker Information 405 0% 3240 0% Summe 5899243380 100% 32943684289 100% Tabelle 5-5 Verteilung der Datenmenge innerhalb eines Simulationsvorgangs. Es wird die Messreihe DuDE-200 für 1000 und 8000 Teilnehmer dargestellt Es ist zum einen zuerkennen, dass die größten Anteile durch die Nachrichtentypen Store Data, welches genutzt wird, um Dateistücke zu verteilen und Find File Answer, welcher genutzt wird, um eine gefundene Datei an den fragenden Peer zu senden, hervorgerufen werden. Da am Anfang noch einige Daten repliziert werden müssen, fallen die Store Data- Nachrichten mehr ins Gewicht als bei der längeren Simulation In der Abbildung 5-1 sind zwei Diagramme dargestellt, die das Verhältnis der einzelnen Pakettypen am Gesamtdatenaufkommen zeigen. DuDE-200 1000 Teilnehmer DuDE-200 8000 Teilnehmer 12% 38% 62% Store Data 88% Find File Answer Store Data Find File Answer Abbildung 5-2 Diagramm zur Darstellung der Verteilung der Datentypen am Gesamtverkehr am Beispiel der Simulationsreihe DuDE-200 1000 Teilnehmer und DuDE-200 8000 Teilnehmer Kapitel: Aufgaben und Auswertung - 44 - Aufgaben und Auswertung - Analyse des erzeugten Datenverkehrs Da auch bei der zentralen Lösung die Daten eingesammelt werden müssten, ist nur der Teil Store Data als Overhead zu sehen, der durch DuDE hinzugekommen ist. Die restlichen Typen haben, wie man der Tabelle 5-5 entnehmen kann, keinen Einfluss. Dabei ist beachten, dass der Wert der Datenmenge pro Peer und pro Sekunde im Bereich von 100 bis 30 Kilobyte liegt. Dies ist als gering einzuschätzen. Zum Vergleich benötigt ein Video on Demand Dienst für FullHD Auflösung durchschnittlich 6 MB pro Sekunde und Teilnehmer. Zum Schluss sei noch erwähnt, dass die angeführten Parameter für die Rechenschritte eine Schätzung darstellen. Selbst wenn diese Schätzung von praktischen Zahlen abweichen sollte, so ändert dies nichts an den grundlegenden Aussagen, sondern das System DuDE würde lediglich früher oder später besser skalieren als das Client-Server-Modell. Bei den Datenmengen, würden sich nur geringfügige Änderungen durch eine längere bzw. kürzere Laufzeit ergeben. Auch hier würde sich die grundlegende Aussage, dass der Overhead an Daten eher gering ist, nicht ändern. Kapitel: Aufgaben und Auswertung - 45 - Zusammenfassung und Ausblick - Analyse des erzeugten Datenverkehrs 6 Zusammenfassung und Ausblick In der vorliegenden Arbeit wurde gezeigt, dass eine P2P-basierter Ansatz nicht nur in der Lage ist, eine Aufgabe verteilt zu berechnen, sondern dass dieses System signifikant schneller sein kann als eine zentrale Lösung. In der Simulation war das P2P-System bis zu 12-mal schneller, als das Client-Server-Modell. Dabei ist der benötigte Overhead bezüglich der Daten sehr klein und beträgt pro Peer und Sekunde gerade einmal 30 Kilobyte, also ein wenig mehr als eine mit MP3 codierte Audiodatei. Damit stellt das System DuDE für sein spezielles Anwendungsgebiet, der Berechnung von Statistiken für Zugangsknoten von ISPs, nicht nur eine wirkliche Alternative zu den vorherrschen Paradigmen dar, sondern ermöglicht die Erstellung dieser überhaupt erst. Da in den nächsten Jahren die Anzahl der Zugangsknoten weiter steigen wird, wird auch der Bedarf an einer solchen Lösung wachsen. Alle Daten für diese Aussage, wurden mit einem eigenentwickelten Simulator, der ebenfalls in der Arbeit beschrieben wurde, erstellt. Eine große Stärke von P2P-System allgemein und DuDE im Besonderen, ist die Robustheit des Systems gegenüber Ausfall eines einzelnen Knotens. Zwar wurde dies in dieser Arbeit nicht dargelegt, aber es ist vorstellbar, dass im Fehlerfall zum Beispiel, beim Nichtauffinden einer Datei oder dem Ausfall eines Task-Watchers, die Berechnung immer noch durchgeführt wird. Mit einem redundanten Job-Scheduler wäre es möglich, dass selbst dieser Peer ausfallen könnte. In diesem Punkt ist DuDE dem vorherrschenden Client-Server-Modell weit überlegen. Hier gebe es noch Bedarf, um die Parameter für ein solches Szenario zu erforschen. Es wäre genauso gut denkbar, DuDE von seinem speziellen Zweck zu entkoppeln und es zu einem allgemeinen System für Verteiltes Rechnen zu entwickeln, denn die Anzahl der verfügbaren Geräte, gerade der Internetfähigen, wird in der nächsten Dekade noch deutlich zunehmen. Kapitel: Zusammenfassung und Ausblick - 46 - Literaturverzeichnis - Analyse des erzeugten Datenverkehrs Literaturverzeichnis [1] G. W. A. W. S. K. Jim Waldo, „A note on distributed computing,“ in Mobile Object Systems Towards the Programmable Internet, Berlin Heidelberg, Springer-Verlag, 1996, pp. 4964. [2] R. Brunner, A Performance Evaluation of the Kad-Protocol, Masterarbeit, University of Manheim, 2006. [3] P. Danielis, Peer-to-Peer-Technologie in Teilnehmerzugangsnetzen, 2012. [4] J. Dunkel, A. Eberhart, S. Fischer, C. Kleiner und A. Koschel, Systemarchitekturen für Verteilte Anwendungen Client-Server, Multi-Tier, SOA, Event-Driven Architectures, P2P, Grid, Web 2.0, München: Carl Hanser Verlag GmbH & Co. KG , 2008. [5] X. Shen, H. Yu, J. Buford und M. Akon, Handbook of peer-to-peer networking, New York: Springer, 2010. [6] R. Steinmetz und K. Wehrle, Peer-to-Peer Systems and Applications, Springer, 2005. [7] R. Graziani und A. Johnson, Routing-Protokolle und -Konzepte - CCNA Exploration, Addison-Wesley , 2009. [8] B. Vachon und R. Graziani, Wide Area Networks - CCNA Exploration Companion Guide, Addison-Wesley Verlag, 2009. [9] A. Schill und T. Springer , Verteilte Systeme Grundlagen und Basistechnologien, Berlin, Heidelberg: Springer Berlin Heidelberg, 2012. [10] T. Rauber und G. Rünger, Parallele Programmierung, Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg, 2007. [11] A. S. Tanenbaum und D. J. Wetherall, Computer Networks, Bosten: Pearson, 2011. Kapitel: Literaturverzeichnis - 47 - Eidesstaatliche Versicherung Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, sind kenntlich gemacht und die Arbeit ist in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung. Rostock, der 31. März 2014
