Implementierung eines Simulators für verteilte Rechnersysteme mit

Universität Rostock
Institut für Informatik
Lehrstuhl für Rechnerarchitektur
Diplomarbeit
Implementierung eines Simulators
für verteilte Rechnersysteme mit
beispielhafter Implementierung
eines assoziativen Speicherkonzeptes
von Dipl.-Ing.(FH) Henry Ristau
Erstgutachter
:
Zweitgutachter :
Betreuer
:
Datum
:
Prof. Dr-Ing. habil. Djamshid Tavangarian
Prof. Dr. rer. nat. habil. Peter Luksch
Dipl.-Inf. Daniel Versick, Dipl.-Inf. Ulrike Lucke
30.11.2004
Kurzfassung
In dieser Arbeit wird ein Modell zur Nachbildung verteilter Systeme, insbesondere
Systemen zur Speicherung großer Datenmengen, entworfen und ein Simulator entwickelt, der das Verhalten dieser Systeme auf Basis des Modells sehr genau nachbilden
kann.
Weiterhin wird ein bestehender Algorithmus zur verteilten assoziativen Datenspeicherung erweitert und auf diesem Simulator realisiert. Es werden Simulationen
durchgeführt, die dieses Speicherkonzept und die Erweiterungen hinsichtlich Skalierungsfähigkeit und Performance untersuchen.
Außerdem wird eine grafische Benutzerschnittstelle implementiert, die die Verteilung der Daten auf die einzelnen Knoten und die Funktionsweise des implementierten
Speicherkonzeptes veranschaulicht.
Abstract
In this thesis a model for distributed systems, especially systems for data-storage,
will be developed. Based on that model a simulator will be realised which is capable
to simulate the behaviour of distributed systems in much detail.
Moreover, an algorithm for distributed associative data access will be enhanced and
implemented on that simulator. Afterwards, the algorithm and enhancements will be
tested in simulation to determine performance and scaling features.
A graphical user interface in order to show the distribution of data onto every node
inside the system and the functionality of the algorithm will be implemented.
Stichworte und Klassifikation nach ACM
Stichworte:
Keywords:
Klassifikation:
Simulation, inhaltsadressierte Speicher, verteilte Systeme
simulation, content addressable memory, distributed systems
C.2.4. (Distributed Systems)
C.4. (Performance of Systems)
E.2. (Data Storage Representations)
I.6.0. (Simulation and Modeling)
I.6.5. (Model Development)
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Simulator zur Nachbildung verteilter Rechnersysteme
1.2.2 Verteiltes Speicherkonzept . . . . . . . . . . . . . . .
1.2.3 Simulationen und Messungen . . . . . . . . . . . . .
2 Grundlagen
2.1 Peer-to-Peer . . . . . . . . . . . .
2.1.1 Peer-to-Peer als Konzept .
2.1.2 Peer-to-Peer-computing .
2.1.3 File-Sharing . . . . . . . .
2.2 Grid . . . . . . . . . . . . . . . .
2.2.1 Erste Generation . . . . .
2.2.2 Zweite Generation . . . .
2.2.3 Dritte Generation . . . . .
2.3 Assoziative Speicher . . . . . . .
2.3.1 Assoziationsfunktionen . .
2.3.2 Neuronale Netzwerke . . .
2.3.3 Inhaltsadressierte Speicher
2.4 Simulation . . . . . . . . . . . . .
2.4.1 System . . . . . . . . . . .
2.4.2 Modell . . . . . . . . . . .
2.4.3 Simulationsarten . . . . .
2.4.4 Pseudo-Zufall . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
2
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
6
7
7
8
9
13
14
15
16
16
18
18
20
21
22
i
INHALTSVERZEICHNIS
INHALTSVERZEICHNIS
3 Bisherige Arbeiten
3.1 Simulatoren . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 P2psim und Myns . . . . . . . . . . . . . . . . . .
3.1.2 Peersim . . . . . . . . . . . . . . . . . . . . . . .
3.2 Algorithmen zur verteilten Speicherung von Daten . . . .
3.2.1 Technologien aus dem frühen File-Sharing-Umfeld
3.2.2 DHT-basierende Algorithmen . . . . . . . . . . .
3.2.3 Content-Addressable Network . . . . . . . . . . .
3.2.4 Chord . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Distance Halving . . . . . . . . . . . . . . . . . .
4 Konzept
4.1 Die Simulation . . . . . . . . . . . . . . . .
4.1.1 Das simulierte System . . . . . . . .
4.1.2 Entwicklung eines geeigneten Modells
4.1.3 Simulationsumgebung . . . . . . . .
4.2 Algorithmenentwicklung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
5 Implementation
5.1 Realisierung des Simulators . . . . . . . . . . .
5.1.1 Der Netzwerksimulator . . . . . . . . . .
5.1.2 Ein einzelner Speicherknoten . . . . . . .
5.2 Implementation des verteilten Speicherkonzeptes
5.2.1 Taskstruktur . . . . . . . . . . . . . . .
5.2.2 Graphische Schnittstelle . . . . . . . . .
5.3 Messungen . . . . . . . . . . . . . . . . . . . .
5.3.1 Topologie T1 . . . . . . . . . . . . . . .
5.3.2 Topologie T2 . . . . . . . . . . . . . . .
5.3.3 Simulationen . . . . . . . . . . . . . . .
6 Ergebnisse und Diskussion
6.1 Vergleich verschiedener Optionen . . . . .
6.1.1 Die Benutzung von L2N-Tabellen .
6.1.2 Die Verwaltung mehrerer Zonen pro
6.2 Skalierungsfähigkeit des Algorithmus’ . . .
6.2.1 Hinzufügen eines weiteren Knotens
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
Knoten
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
25
25
26
27
28
32
34
.
.
.
.
.
37
37
37
38
41
43
.
.
.
.
.
.
.
.
.
.
47
47
47
49
49
50
51
51
51
54
54
.
.
.
.
.
58
58
58
61
62
62
ii
INHALTSVERZEICHNIS
6.3
6.4
6.2.2 Durchschnittliche Routingkomplexität . .
6.2.3 Zeitverhalten beim Speichern und Suchen .
Simulationsdauer . . . . . . . . . . . . . . . . . .
Erkenntnisse aus den Simulationen . . . . . . . .
INHALTSVERZEICHNIS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
65
66
7 Zusammenfassung
68
8 Ausblick
70
Abkürzungsverzeichnis
71
Literaturverzeichnis
73
Abbildungsverzeichnis
77
A Messergebnisse Simulationsreihe 1
A.1 Simulationsreihe 1 auf Topologie T1 . . . . . . . . . . . . . . . . . . . .
A.2 Simulationsreihe 1 auf Topologie T2 . . . . . . . . . . . . . . . . . . . .
80
80
80
B Messergebnisse Simulationsreihe 2
B.1 Simulationsreihe 2 auf Topologie T1 . . . . . . . . . . . . . . . . . . . .
B.2 Simulationsreihe 2 auf Topologie T2 . . . . . . . . . . . . . . . . . . . .
86
86
86
C Thesen
91
iii
Kapitel 1
Einleitung
Den Einstieg in diese Arbeit bildet eine kurze Motivation des Lesers für die Themengebiete, in denen die Arbeit angesiedelt ist. Im Anschluss daran wird das Ziel der Arbeit
beschrieben. An einigen Stellen werden Technologien erwähnt und nur kurz erläutert.
Eine detaillierte Beschreibung dieser Technologien erfolgt im nächsten Kapitel.
1.1
Motivation
Die zunehmende Verfügbarkeit leistungsfähiger Kommunikationstechnologien erleichtert den Zugriff von Benutzern auf entfernte Ressourcen. Dabei ist es nicht länger
wünschenswert nur gezielt auf einzelne Ressourcenprovider, wie zum Beispiel FileServer, zuzugreifen, sondern einen ganzen Pool an unterschiedlichen Ressourcen, wie
zum Beispiel Speicherplatz oder Prozessorleistung, zur unmittelbaren Verfügung zu
haben. Wichtige Kriterien hierbei sind Transparenz, Sicherheit und nicht zuletzt auch
Performance.
Zur Realisierung dieses Anspruchs sind momentan verschiedene Technologien
verfügbar. Das Peer-to-Peer (P2P)-computing, also die dezentrale Kommunikation zwischen Teilnehmern, stellt die technische Grundlage dar, während das Grid-computing
das Konzept des transparenten und sicheren Zugriffs auf beliebige Ressourcen zu realisieren versucht.
Ein wichtiges Anwendungsgebiet für diese Technologien ist die verteilte Speicherung
großer Datenmengen. Hierfür eignen sich insbesondere assoziative Speicherkonzepte,
da diese die Suche nach Inhalten unterstützen und keinen einheitlichen Adressraum
benötigen.
1
Ziel
Einleitung
Verteilung, Replikation und schnelle, effektive Suche nach Daten auf über komplexe Netzwerkstrukturen verbundenen Rechnern verlangen nach aufwändigen adaptiven
Algorithmen. Zur Entwicklung und Verbesserung derartiger Algorithmen sind Simulatoren nötig, die zur Nachbildung entsprechender Netzwerkstrukturen in der Lage sind.
Auf diese Weise lassen sich Schwachstellen in Algorithmen finden und beseitigen sowie
auf spezielle Netzwerktopologien optimierte Algorithmen entwickeln und testen.
1.2
Ziel
Ziel dieser Arbeit ist die Entwicklung eines Simulators, der ein verteiltes Rechnersystem
nachbilden kann. Darauf aufbauend wird ein Algorithmus zur verteilten Datenspeicherung entwickelt und implementiert. Es werden Verschiedene Simulationen, unterschiedlich sowohl in der nachgebildeten Netzwerktopologie als auch in der Konfiguration des
Algorithmus’, durchgeführt und deren Ergebnisse diskutiert. Eine detailliertere Darstellung dieser drei Ziele erfolgt in den nächsten Abschnitten.
1.2.1
Simulator zur Nachbildung verteilter Rechnersysteme
Im Verlauf der Arbeit wird ein Simulator zur Nachbildung verteilter Rechnersysteme
entwickelt. Konfigurierbar sind dabei sowohl die Eigenschaften des Netzwerkes als auch
der einzelnen vernetzten Rechner, im weiteren Verlauf der Arbeit als Knoten bezeichnet.
Die Netzwerktopologie wird über Kosten für jede einzelne Verbindung in Form von
Bandbreite und Latenz definiert. Außerdem werden auch Netzwerkkomponenten wie
Hubs, Switches und Router nachgebildet und sind mit Latenzeigenschaften konfigurierbar.
Die Anzahl der simulierten Knoten ist variabel, genau wie deren Eigenschaften.
Dazu gehören Größe, Bandbreite und Latenzeigenschaften von Festspeichern zur dauerhaften Datenspeicherung sowie Cache-Speichern zur vorübergehenden Datenspeicherung.
1.2.2
Verteiltes Speicherkonzept
Aufbauend auf den zuvor beschriebenen Simulator wird ein assoziatives Speicherkonzept zur verteilten Datenspeicherung auf den simulierten Knoten realisiert. Der dafür
2
Ziel
Einleitung
implementierte Algorithmus ist gut auf die Anzahl der Knoten skalierbar und unanfällig
gegenüber dem Ausfall einzelner Knoten.
In diesem simulierten verteilten Speicher ist die Ablage von Daten, die Suche nach
bestimmten Datensätzen sowie die Suche nach Datensätzen mit einer einfachen bitweisen Suchmaske möglich.
1.2.3
Simulationen und Messungen
In dem implementierten verteilten Speicher werden verschiedene Messungen durchgeführt und ausgewertet. Dabei wird das Verhalten des Algorithmus auf verschiedenen
Netzwerktopologien verglichen. Weiterhin werden verschiedene Einstellungsmöglichkeiten des Algorithmus’ auf ihren Einfluss auf die Geschwindigkeit der Suche im verteilten
Speicher untersucht.
3
Kapitel 2
Grundlagen
In diesem Kapitel werden die dieser Arbeit zugrundeliegenden Technologien vorgestellt.
Den Einstieg bildet die Beschreibung des Begriffes P2P und der damit verbundenen
Technologien. Darauf folgt ein kurzer Abriss über die geschichtliche Entwicklung und
die wesentlichen Merkmale von Grids als die zur Zeit vielversprechendsten Vertreter
heterogener verteilter Systeme. Anschließend werden Funktionsweise und Entwicklung
assoziativer Speicher vorgestellt. Den Abschluss bildet ein Überblick über Simulation.
2.1
Peer-to-Peer
Der Begriff P2P ist in der Informatik schon seit einigen Jahren kein eindeutiger Begriff
im Sinne einer Bezeichnung für eine spezielle Technologie mehr. In den nachfolgenden Abschnitten sollen drei verschiedene Sichtweisen auf diese vieldeutige Bezeichnung
erläutert werden. Den Anfang bildet das P2P-Konzept, darauf folgt das P2P-computing
und zuletzt ein kurzer Überblick über das File-Sharing, die Form des P2P-computing,
der der P2P-Begriff seine momentane Berühmtheit verdankt.
2.1.1
Peer-to-Peer als Konzept
P2P beschreibt die gleichberechtigte Zusammenarbeit verschiedener informationsverarbeitender Systeme zur Erbringung eines Services, dessen Realisierung die Möglichkeiten eines Einzelsystemes übersteigt. Dieses Konzept basiert auf drei grundsätzlichen
Prinzipien [1]:
4
Peer-to-Peer
Grundlagen
Ressourcenteilung – In jedem P2P-System werden die Ressourcen der einzelnen
Teilnehmer unter allen Teilnehmern verteilt. Dabei kann es sich zum Beispiel
um Rechenleistung, Speicherplatz oder Informationen handeln.
Dezentralisierung – In einem P2P-System gibt es keine zentrale Instanz zur Überwachung der Ressourcenverteilung. Damit werden Probleme wie zentrale Fehlerquellen (single points of failure) und punktuelle Systemüberlastungen (bottlenecks)
vermieden.
Selbstorganisation – Aus dem Fehlen einer zentralen Überwachungsinstanz ergibt
sich die Notwendigkeit zur eigenständigen Verwaltung des P2P-Systems.
Anhand der bisherigen Beschreibung sind viele verschiedene P2P-Systeme denkbar. Eine Gruppe von Wissenschaftlern, die an einem gemeinsamen Projekt arbeitet
und Informationen über das Telefon austauscht, ist genauso ein P2P-System wie das
Internet, in dem jeder Computer mit jedem anderen Daten austauschen kann. Eine
Unterscheidung kann hier anhand eines Schichtenmodells, wie in Abbildung 2.1 dargestellt, erfolgen.
Benutzer
benutzt
Service
Anwendung
benutzt
Service
Informations−
verwaltung
benutzt
Service
Netzwerk
Abbildung 2.1: Darstellung der Systemschichten, auf denen das P2P-Konzept angewandt werden kann [1]
Die beiden zuvor erwähnten Beispiele lassen sich anhand dieses Schichtenmodells
wie folgt einordnen: Die Gruppe Wissenschaftler betreibt P2P auf Benutzerebene,
während das Internet P2P auf Netzwerkebene zur Verfügung stellt. Dies sind die beiden älteren Formen der Anwendung von P2P. Die Grundlage für P2P auf Anwendungs5
Peer-to-Peer
Grundlagen
und Informationsverwaltungsebene bildet das P2P-computing, welches im nächsten Abschnitt vorgestellt wird.
2.1.2
Peer-to-Peer-computing
Die zwei ältesten Formen der Zusammenarbeit von informationsverarbeitenden Systemen in Netzwerken sind das Client-Server-computing und das P2P-computing. Abbildung 2.2 versucht eine vergleichende Gegenüberstellung dieser beiden Formen.
Client−Server−computing
Peer−to−Peer−computing
Server
Client
Teilnehmer
Teilnehmer
Client
Client
Teilnehmer
Teilnehmer
Request
Request
Service
Service
Abbildung 2.2: Gegenüberstellung der Zusammenarbeit zwischen informationsverarbeitenden Systemen beim Client-Server-computing und beim P2Pcomputing
Beim Client-Server-computing übernehmen die Teilnehmer unterschiedliche Rollen.
Ein Server stellt eine Ressource zur Verfügung, die von einem Client in Anspruch
genommen werden kann. Der Client äußert den Wunsch zur Inanspruchnahme durch
einen Request und der Server stellt daraufhin die Ressource zur Verfügung.
Beim P2P-computing gibt es keine derartige Rollenverteilung. Jeder Teilnehmer
ist sowohl Server, beim P2P-computing auch Servent genannt, und stellt damit eine
Ressource zur Verfügung als auch Client bei der Benutzung derselben Ressource von
anderen Teilnehmern.
Eine mögliche Anwendung des P2P-Konzeptes auf Anwendungs- und/oder Informationsverwaltungsebene unter Verwendung von P2P-computing stellt das im nächsten
Abschnitt näher betrachtete File-Sharing dar.
6
Grid
2.1.3
Grundlagen
File-Sharing
Den Großteil seiner Popularität verdankt der Begriff P2P dem File-Sharing. Häufig
wird die Bezeichnung P2P sogar mit dem File-Sharing gleichgesetzt, obwohl es sich
dabei, wie in den vorhergehenden Abschnitten beschrieben, nur um eine von vielen
Anwendungsmöglichkeit handelt. Die hierbei zur Verfügung gestellten Ressourcen sind
Informationen, oder genauer Daten. Diese werden durch einen Teilnehmer für alle anderen zur Verfügung gestellt.
Das erste als File-Sharing-Applikation bekannt gewordene P2P-System ist Napster
[31]. Napster verwendet das P2P-Konzept auf Benutzer-, Anwendungs- und Netzwerkebene. Die Informationsverwaltung, also in diesem Fall die Verwaltung der Metadaten, insbesondere die Zuordnung von Dateinamen zum Teilnehmer, der die Datei zur
Verfügung stellt, findet bei Napster zentralisiert statt.
Seit der Entwicklung von Gnutella [24] wird das P2P-Konzept auch zur Verwaltung der Metadaten verwendet. Es ist keine zentrale Instanz mehr vorhanden. Daraus
ergeben sich die weiter oben genannten Vorteile, die Vermeidung von single-points-of
failure und bottlenecks. Allerdings entstehen dadurch neue, vor allem juristische Probleme. Diese sollen im Rahmen dieser Arbeit nicht näher betrachtet werden.
Die Weiterentwicklung im Bereich des File-Sharing zielt seit dem auf die Verbesserung der Zugriffsverfahren um eine optimalere Selbstverwaltung zu ermöglichen. Ein
genauerer Einblick in die, dem File-Sharing zugrundeliegenden Algorithmen und deren
Optimierungen wird im Abschnitt 3.2 gegeben.
2.2
Grid
Ein Forschungszweig, der sich ebenfalls des P2P-Konzeptes bedient, ist das Gridcomputing. In [16] arbeitet Foster drei Eigenschaften heraus, die ein verteiltes System
als Grid kennzeichnen. Diese sind:
1. Die Koordination von Ressourcen, die nicht einer zentralen Kontrollinstanz unterstehen,
2. das Basieren auf offenen general-purpose Standardprotokollen und -schnittstellen
sowie
3. das Anbieten einer erweiterten Quality of Service.
7
Grid
Grundlagen
Dabei dient Punkt eins der Abgrenzung eines Grids zu einem Cluster. Das Grid soll
eben nicht, wie ein Cluster von einer zentralen Instanz, einem Administrator, einem
Lehrstuhl, einer Firma oder ähnlichem, kontrolliert werden. Punkt zwei unterscheidet
ein Grid von vielen heutzutage weit verbreiteten Systemen zum verteilten Rechnen, die
jeweils auf proprietären Implementationen basieren. Ein solches Beispiel ist Seti@Home
[38]. Punkt drei letztlich unterscheidet das Grid vom heutigen Internet. Bei einem Grid
muss der Nutzen des Gesamtsystems deutlich größer sein, als der Nutzen der Summe
seiner Bestandteile.
Wie man außerdem an Punkt eins erkennt, bedient sich das Grid-computing zwar
des P2P-Konzeptes was die Koordination von Ressourcen angeht, stellt aber in den
beiden folgenden Punkten Anforderungen, die weit darüber hinaus gehen.
Die Entwicklung des Grids lässt sich in drei Generationen [36] einteilen. Im Folgenden werden diese kurz beschrieben und die Merkmale und Fortschritte einer jeden
Generation dargelegt.
2.2.1
Erste Generation
Seine Ursprünge hat das Grid-Computing Anfang der 1990er Jahre unter der Bezeichnung Metacomputing. Ziel war es, Rechenleistung für high-performance-Anwendungen
zur Verfügung zu stellen. Dazu sollten viele einzelne Workstations oder auch
Supercomputing-Zentren miteinander verbunden werden. Um dieses Ziel zu erreichen,
waren verschiedene Probleme zu überwinden, die Kommunikation zwischen den Einzelkomponenten, die Ressourcenverwaltung und die Manipulation von entfernt gespeicherten Daten. Zwei solche Projekte waren Factoring via Network-Enabled Recursion (FAFNER) [13] und Information Wide Area Year (I-WAY) [17].
Beispiele für Grids der ersten Generation
Ziel von FAFNER war das Faktorisieren großer Zahlen, die Basis für das asymmetrische
Rivest, Shamir, Adelman (RSA)-Verschlüsselungsverfahren. Grundlage der Implementierung war ein Netz von Web-Servern und das Hypertext Transfer Protocol (HTTP).
Über die Web-Server konnte eine große Anzahl von Clients ohne menschliches Eingreifen verwaltet werden. FAFNER war damit der Vorläufer vieler proprietärer verteilter
Applikationen wie zum Beispiel SETI@home [38] oder Distributed.Net [12].
Bei I-WAY handelte es sich um ein experimentelles Hochleistungsnetzwerk, das
Hochleistungsrechner und fortschrittliche Visualisierungsumgebungen verschiedener
8
Grid
Grundlagen
US-amerikanischer Forschungseinrichtungen verbinden sollte. Anschließend sollte es
möglich sein, Applikationen auf das Gesamtsystem zu verteilen. Das Projekt war ein
Erfolg und Vorläufer weiterer Grid-Systeme. Die im Zusammenhang mit I-WAY entwickelten Protokolle und Ideen wurden die Basis für das Globus-Projekt [18], auf das
im nächsten Abschnitt näher eingegangen wird.
Ein weiteres Projekt zur Bearbeitung von DV-Problemen in Weitverkehrsnetzen
ist das Projekt Hypercomputing[42] des Lehrstuhls für Rechnerarchitektur der Universität Rostock. Hier wurde ein verteiltes System geschaffen, dass Workstation-Cluster
verschiedener, über Deutschland verteilter Institutionen zu einem Hypercomputer verbindet. Mit diesem lassen sich Applikationen nebenläufig bearbeiten. Die Realisierung
erfolgte größtenteils in Java und zeichnet sich durch ein hohes Maß an Plattformunabhängigkeit und Modularisierung aus. Neben der Bereitstellung von Modulen zum
Ressourcen-, Performance- und Job-Management sowie Sicherheitsmodulen wurde insbesondere Wert auf eine einfache Bedienung, zum Beispiel durch grafische Benutzeroberflächen, gelegt.
2.2.2
Zweite Generation
Mit der Entwicklung von Standards zur Realisierung einer Middleware für GridSysteme begann in den späten 1990er Jahren die Entstehung der zweiten GridGeneration. Dabei sollte es möglich werden, ein Grid über das Internet beliebig zu
verteilen und neue Probleme mussten bewältigt werden:
Heterogenität – Die Ressourcen für ein solches Internet-weites Grid unterscheiden
sich stark voneinander und stehen nicht mehr unter zentraler Verwaltung. Selbst
Ländergrenzen spielen im Internet keine Rolle mehr, bringen aber neue Probleme
bei der Internationalisierung von Grids mit sich.
Skalierbarkeit – Ein Grid soll in der Anzahl der partizipierenden Knoten nicht begrenzt sein. Es kann aus wenigen Rechnern in einem Rechenzentrum oder mehreren Millionen Rechnern weltweit bestehen. Dazu sind besondere Strategien nötig,
um Latenzen zu minimieren und eventuell vorhandene Lokalität von Ressourcen
auszunutzen. Außerdem entstehen neue Anforderungen an Authentifizierung und
Autorisierung von Ressourcen und Benutzern.
9
Grid
Grundlagen
Anpassungsfähigkeit – Der Ausfall von Ressourcen in Internet-weiten Grids ist
nicht zu vermeiden und muss von der Middleware erkannt und toleriert werden
können.
Ziel der Bestrebungen war es, allgemein für Grids benötigte Services zu erkennen
und durch Standards und deren Implementationen verfügbar zu machen. Basierend auf
dieser Middleware sollte es dann möglich sein, spezialisierte Grids für bestimmte Arten
von Anwendungen zu konzipieren und zu realisieren.
Folgende Anforderungen an die Middleware eines Grids der zweiten Generation
werden in [36] aufgeführt:
Administrationshierarchie – Sie stellt sicher, wie administrative Informationen im
Grid verbreitet werden.
Kommunikationsdienste – Standards zur Kommunikation im Grid gewährleisten
Datentransport, Streaming, Gruppenkommunikation bis hin zum Austausch von
Objekten.
Informationdienste – Sie stellen sicher, dass Informationen überall im Grid jederzeit
zur Verfügung stehen.
Namensdienste – Besonders in verteilten Systemen, wo die Adresse einer Ressource
von geringer Bedeutung ist, spielen Namen eine wesentliche Rolle.
Verteilte Dateisysteme und Caching – Genau wie Informationen müssen auch
Daten im Grid möglichst schnell dort zur Verfügung stehen, wo sie benötigt
werden.
Sicherheit – Große verteilte Systeme bieten viele Angriffspunkte. Die Gewährleistung von Nutzerauthentifizierung, Nachvollziehbarkeit von Handlungen, Vertraulichkeit zwischen den Systemen und die Integrität der Daten sind von enormer
Bedeutung.
Fehlertoleranz – Um den Einfluss von Fehlern und Systemausfällen innerhalb des
Grids in Grenzen zu halten sind neben einer fehlertoleranten Systemstruktur
auch Überwachungswerkzeuge nötig.
Ressourcenverwaltung und Scheduling – Eine Grid-weite Verwaltung der vorhandenen Ressourcen ist genauso notwendig wie eine enge Zusammenarbeit mit
den lokal installierten Mechanismen zur Verwaltung der Systemressourcen.
10
Grid
Grundlagen
grafische Benutzer- und Administrationsschnittstelle – Um auch Grids von
enormer Größe effektiv verwalten zu können ist eine übersichtliche Administrationsschnittstelle notwendig.
Diese Anforderungen wurden seitdem in verschiedenen Projekten umgesetzt. Die
am weitesten verbreiteten Kerntechnologien werden nachfolgend kurz vorgestellt.
Globus
Das Globus-Projekt [18] entstand aus den Ergebnissen und dem Know-How des I-Way
Projektes als US-amerikanisches, multiinstitutionelles Forschungsprojekt. Zentrale Idee
war die Entwicklung einer allgemeinen Grid-Middleware, des Globus-Toolkits [43]. Es
besteht aus einer Reihe von Komponenten, die die grundsätzlichen Anforderungen an
Grids der zweiten Generation, wie Sicherheit, Ressourcenlokalisierung, Ressourcenverwaltung und Kommunikation gewährleisten.
GRAM
GridFTP
MDS
HTTP
FTP
LDAP
TLS / GSI
IP
Abbildung 2.3: Ausschnitt aus der Schichtenarchitektur des Globus-Toolkit in den Versionen 2.x
Diese Komponenten bilden eine modulare Schichtenarchitektur, die einen flexiblen
Einsatz des Toolkits gewährleistet. Abbildung 2.3 zeigt einen Teil dieser Architektur.
Über bestehende Protokolle und Schnittstellen hinaus wurden einige neue Protokolle
entwickelt, die speziell auf die Anforderungen von Grids zugeschnitten sind:
Globus Resource Allocation Manager (GRAM) – Das
HTTP-basierende
GRAM Protokoll dient der Allokation, Kontrolle und Überwachung von
Ressourcen im Grid.
Grid File Transfer Protocol (GridFTP) – Beim GridFTP handelt es sich um eine erweiterte Version des File Transfer Protocol (FTP), die um spezielle Eigen11
Grid
Grundlagen
schaften, wie die Nutzung von Sicherheitsschichten, den Zugriff auf Dateiteile und
Parallelität erweitert wurde.
Monitoring and Discovery System (MDS) – Das Monitoring and Discovery System stellt Informationen über verfügbare Ressourcen im Grid und deren Status
zur Verfügung.
Grid Security Infrastructure (GSI) – dient der Authentifizierung im Grid.
Global Access to Secondary Storage (GASS) – realisiert
parallelen Datenzugriff.
sequentiellen
und
Globus Executable Management (GEM) – zur Verwaltung von ausführbaren
Applikationen im Grid.
Globus Advanced Reservation and Allocation (GARA) – ist für die Reservierung und Verteilung von Ressourcen zuständig.
Das Globus-Toolkit wird noch immer weiterentwickelt und ist in der inzwischen
vorliegenden Version 3.2 bereits ein Vertreter der dritten Grid-Generation. Bevor diese
genauer charakterisiert wird, wird ein anderer Ansatz, die Anforderungen an die zweite
Generation von Grids umzusetzen, kurz vorgestellt.
Legion
Einen objektorientierten Ansatz zur Realisierung von Grid-Umgebungen verfolgt Legion [25]. Hier werden alle Systemkomponenten als Objekte realisiert. Dieser Ansatz
bietet alle Vorteile eines objektorientierten Systems wie Datenabstraktion, Kapselung,
Vererbung und Polymorphie.
Ein weiterer Vorteil ist die Plattformunabhängigkeit dieses Ansatzes. Objektdefinitionen werden von einem Generator für die jeweilige Plattform übersetzt und anschließend ausgeführt. Legion nutzt weiterhin einen eindeutigen Namensraum für das
gesamte Grid. Jedes Objekt erhält einen global eindeutigen Identifikator über den es
im Grid referenziert wird.
Um eine sehr hohe Anzahl von Objekten zu ermöglichen, unterscheidet Legion zwischen aktiven und inaktiven Objekten. Aktive Objekte liegen im Speicher eines Systems
und werden ausgeführt. Inaktive Objekte sind als Schnappschüsse in Festspeichern abgelegt. Zwischen den Zuständen eines Objektes kann bei Bedarf, zum Beispiel bei Erhalt
12
Grid
Grundlagen
einer Nachricht, umgeschaltet werden, so dass der momentane Zustand eines Objektes
für den Benutzer völlig transparent bleibt.
Legion unterstützt verschiedene Programmiersprachen, darunter auch Fortran und
C. Interfaces und Object-Wrapper, so genannte Interface Manager, stellen hierbei sicher, dass der objektorientierte Zugriff auf in imperativen Programmiersprachen entwickelte Objekte möglich bleibt.
Weitere Vertreter der zweiten Grid-Generation
Neben den soeben vorgestellten Systemen, die versuchen, alle Kerntechnologien von
Grids umzusetzen, wurden verschiedene auf einzelne Anforderungen spezialisierte Systeme entwickelt. Dazu gehören verschiedene Batch- und Schedulingsysteme, Storage
Resource Broker und Grid-Portale auf die nicht näher eingegangen wird.
Aus der zweiten Grid-Generation sind verschiedene Projekte hervorgegangen, die
auf den vorgestellten Kerntechnologien aufsetzen, um einer Gruppe von Nutzern konkrete Grid-basierende Services zur Verfügung zu stellen. Einige Beispiele sind Cactus
[7], DataGrid [11] und UNICORE [14].
2.2.3
Dritte Generation
Im Jahr 2001 begann sich die Sichtweise auf Grids noch einmal zu verändern. Foster
beschreibt in [20] die Nutzer eines Grids als virtuelle Organisation und das Grid selbst
als Erbringer von Services. Um dieser Sichtweise gerecht zu werden, schlägt er eine
strikt serviceorientierte Schichtenarchitektur vor.
Die unterste Schicht bildet ein breiter Pool an Basistechnologien (Fabric) wie zum
Beispiel der Zugriff auf Festspeicher, Netzwerk und Sensoren, auf dem eine schmale
Schicht von Verbindungs- und Zugriffsprotokollen (Ressource and Connectivity Protocols) aufsetzt. Diese Schicht bildet wiederum die Basis für eine breite Schicht von
high-level-Services (Collective Services), von denen die Anwendungen (User Applications) Gebrauch machen können. Aus diesem, in Abbildung 2.4 dargestellten, “hourglass
model” ging dann ca. 2002 die Open Grid Service Architecture (OGSA) [19], die einen
vollständig transparenten Ansatz aus Services und Interfaces vorstellt, hervor. Nachfolgend soll die OGSA kurz beschrieben werden.
13
Assoziative Speicher
Grundlagen
User Applications
Collective Services
Ressource and
Connectivity Protocols
Fabric
Abbildung 2.4: Das von Foster in [15] vorgestellte “hourglass model”
Open Grid Service Architecture
Die OGSA definiert alle Bestandteile und Leistungen eines Grids als Services. Dazu
gehören zum Beispiel Rechenleistung, Speicher, Netzwerke, Programme und Datenbanken. Zur Zusammenarbeit zwischen Gridkomponenten, also zwischen Services, werden
Service-Interfaces und Protokolle benötigt.
Lokale und Remote-Transparenz sowie Unabhängigkeit von Betriebssystemen wird
durch eine standardisierte Interface-Beschreibung gewährleistet. Dazu kommen die Web
Service Definition Language (WSDL) oder verschiedene auf die WSDL abbildbare Technologien zum Einsatz.
Zentrales Element im OGSA ist der Grid-Service. Er stellt eine festgelegte Menge
an Interfaces zur Verfügung, um folgende Aufgaben erfüllen zu können: Auffinden, dynamische Erstellung, Lebenszyklusverwaltung, Benachrichtigung und Verwaltung von
Services sowie Namensauflösung, Aktualisierung, Autorisierung und Zugriffssteuerung.
Eine Implementierung der OGSA stellt das Globus-Toolkit in der aktuellen Version
3.2 dar.
2.3
Assoziative Speicher
Neben dem Speichern und Löschen von Daten ist die wesentliche Eigenschaft eines
assoziativen Speichers die “Wiedergewinnung, Verarbeitung sowie Manipulation ge-
14
Assoziative Speicher
Grundlagen
speicherter Daten gemäß ihrer Inhalte oder Teilinhalte durch Assoziationsfunktionen”
[41].
Es werden auf Grund ihrer unterschiedlichen Funktionsweise zwei Arten assoziativer Speicher unterschieden: neuronale Netzwerke und inhaltsadressierte Speicher. Diese werden im Anschluss näher beschrieben, wobei der Fokus auf Grund der höheren
Relevanz für diese Arbeit auf inhaltsadressierten Speichern liegt. Bevor mit der Beschreibung der Arten assoziativer Speicher begonnen wird, folgt ein kurzer Überblick
über die verschiedenen Formen assoziativen Zugriffs.
2.3.1
Assoziationsfunktionen
Assoziationsfunktionen werden vorwiegend zur Suche in assoziativen Speichern eingesetzt. Sie werden auf die Inhalte oder Teilinhalte angewandt, nach denen im Speicher
gesucht wird. Unter Teilinhalten können zum Beispiel Schlüssel verstanden werden,
wenn der Speicher Schlüssel-Wert-Paare aufnimmt.
In [41] werden folgende fünf Gruppen von Assoziationsfunktionen genannt:
Äquivalenzrelationen – Folgende vier Relationen gehören in diese Gruppe:
Identität – Ein gegebener Wert dient als Suchargument für sich selbst im Speicher.
Teilidentität – Ein Teil des gesuchten Wertes dient als Suchargument.
Näherung – Es findet eine unscharfe Suche nach allen Werten, die einem
Suchargument ähneln, statt.
Ungleichheit – Diese Operation liefert alle Werte aus dem Speicher, die ungleich einem Suchargument sind.
Relationale Suchoperationen mit einem Grenzwert – In diese Gruppe gehören
alle Suchoperationen, bei denen die Suche über Vergleiche mit einem Grenzwert
stattfindet. Dazu gehören Größer-Gleich-, Kleiner-Gleich, Größer- und KleinerSuchoperationen.
Relationale Suchoperationen mit zwei Grenzwerten – Suchoperationen über
Intervalle von zwei Grenzwerten gehören dieser Gruppe an. Dabei kann sowohl
nach Werten innerhalb des gegebenen Intervalls gesucht werden als auch nach
Werten außerhalb dieses Intervalls, sowohl unter Einbeziehung als auch ohne
Einbeziehung der Grenzwerte.
15
Assoziative Speicher
Grundlagen
Suchoperationen nach Extremwerten – Die Suche nach Minimal- und Maximalwerten innerhalb des Speichers gehört in diese Gruppe.
Nachbarschaftssuchoperationen – Diese Gruppe von Operationen enthält die Suche nach Werten anhand der Operationen Vorgänger, Nachfolger und Nachbar.
Welche Assoziationsfunktionen implementiert sind, die Geschwindigkeit der
Ausführung und die Güte der Ergebnisse ist von der Art des assoziativen Speichers
abhängig.
2.3.2
Neuronale Netzwerke
Die grundsätzliche Funktionsweise neuronaler Netzwerke orientiert sich an der Funktion
des menschlichen Gehirns und Nervensystems. Sie bestehen aus einer großen Anzahl
von Neuronen, die in Netzwerken verschiedener Form verschaltet sind. Die Speicherung
der Informationen erfolgt hierbei über die Gewichtung der Verbindungen zwischen den
Neuronen.
Ein Nachteil neuronaler Netze ist, dass das Speichern und Löschen von Daten über
aufwändige Lernprozesse erfolgt, wobei das Löschen von Informationen nicht immer
möglich und meist auf Grund des Aufwands nicht sinnvoll ist. Ein enormer Vorteil
neuronaler Netze besteht in der durch Parallelität sehr schnellen Suche über Identitätsund Näherungs-Relationen.
2.3.3
Inhaltsadressierte Speicher
Es gibt zwei Ansätze zur Realisierung inhaltsadressierter Speicher mit Unterschieden
in Funktionsweise und Eigenschaften, als Hardware und als Software. [28]
Inhaltsadressierte Speicher als Hardware
Der Aufbau eines einfachen wortorientierten inhaltsadressierten Speichers besteht neben dem eigentlichen Speicher mindestens aus einem Suchregister, in dem das Argument für die Suchoperation gespeichert wird, einem Maskenregister, mit dessen Hilfe
bei Bedarf Teile des Suchregisters ausgeblendet werden können, einem Adressdekoder,
der die Wortadressen in Steuersignale umsetzt, einem Treffervektor, der die Treffer einer Suchanfrage markiert, und einem Output-Register, das die Ergebnisse sequentiell
zur Verfügung stellt. Ein solcher Speicher ist in Abbildung 2.5 dargestellt. Bei Bedarf
16
Assoziative Speicher
Grundlagen
kann der inhaltsadressierte Teil des Speichers um einen Datenteil ergänzt werden, so
dass Schlüssel-Daten-Paare abgelegt und gesucht werden können.
0
1
Suchregister
b
0
1
Maskenregister
b
0
1
Speicherwort W0
b
T0
0
1
Speicherwort W1
b
T1
0
1
Speicherwort Wn
b
0
1
Outputregister
b
Trefferregister
Adressdekoder
Wortadresse
Treffervektor T
Tn
Abbildung 2.5: Aufbau eines einfachen wortorientierten inhaltsadressierten Speichers
Mit Hardware-Lösungen sind wortparallele oder bitparallele Suchoperationen über
Identität und Teilidentität sehr effektiv möglich. Es gibt auch Algorithmen und Speziallösungen zur Realisierung weiterer Assoziationsfunktionen. Inhaltsadressierte Speicher sind in der Herstellung deutlich teurer als gewöhnlicher Random Access Memory (RAM). Dies ist zugleich die Motivation für die Implementation als Software.
Inhaltsadressierte Speicher als Software
Die Grundidee bei der Implementation inhaltsadressierter Speicher als Software ist die
möglichst effektive Umsetzung von Inhalten auf Adressen, so dass Daten in gewöhnlichem RAM abgelegt und trotzdem über ihre Inhalte adressiert werden können.
Eine sehr effektive Möglichkeit, diese Umsetzung zu bewältigen, stellt die Verwendung von Hash-Funktionen [28] dar. Hash-Funktionen dienen der Umsetzung von Inhalten in Hash-Werte. Hash-Werte liegen in einem festen Wertebereich, der gewöhnlich
über die Anzahl der, von einem Hash-Wert verwendeten Bits definiert ist. Ein Qua-
17
Simulation
Grundlagen
litätsmerkmal für Hash-Funktionen ist in diesem Zusammenhang1 die Gleichverteilung
der Hash-Werte über den Wertebereich.
Mit Hilfe der Hash-Werte lassen sich Inhalte auf Speicheradressen umsetzen. Dabei
kann zum Beispiel der Hash-Wert direkt als Adresse im Speicher (direkte Adressierung) oder als Adresse eines Zeigers, der dann auf den eigentlichen Datensatz zeigt,
(indirekte Adressierung) dienen. Ein Problem, das hierbei bewältigt werden muss, sind
Kollisionen. Kollisionen treten auf, wenn verschiedene Inhalte auf den gleichen HashWert abgebildet werden. Zur Kollisionsvermeidung gibt es verschiedene Ansätze, die
hier nicht weiter detailliert werden.
Hash-Funktionen sind der effektivste Ansatz bei der Umsetzung von Inhalten auf
Adressen und somit bei der Abbildung der Identität als Assoziationsfunktion. Zur Abbildung anderer Assoziationsfunktionen in inhaltsadressierten Speichern gibt es andere
Zugriffsverfahren, wie zum Beispiel Baumstrukturen, die hier nicht näher beschrieben
werden.
2.4
Simulation
Die Simulation, 1987 noch als letzter Ausweg [5] bezeichnet, gewinnt zunehmend an
Bedeutung. Ursachen hierfür liegen in immer leistungsfähigeren Rechnerumgebungen
sowie im Vergleich zu Experimenten häufig deutlich geringeren Kosten. Abbildung
2.6 stellt dar, wo die Simulation im Prozess des Erkenntnisgewinnes über ein System
angeordnet ist.
Im Zusammenhang mit Simulationen fallen immer die Begriffe System und Modell.
Diese werden im Anschluss charakterisiert. Im darauf folgenden Abschnitt werden verschiedene Simulationsarten vorgestellt. Den Abschluss bildet ein kurzer Überblick über
Pseudo-Zufall, der bei Simulationen eine wichtige Rolle spielt.
2.4.1
System
Ein System besteht aus einer Gruppe von Objekten, die zur Erfüllung einer bestimmten
Aufgabe in Beziehung zueinander stehen. Außerdem wird ein System durch verschiedene Ereignisse, die außerhalb des Systems stattfinden, beeinflusst [4]. Ein Beispiel für
ein solches System sei ein Fließband, an dem Kraftfahrzeuge montiert werden. Objek1
Im Bereich der Kryptographie unterliegen Hash-Funktionen weit mehr Anforderungen, die im
Zusammenhang mit inhaltsadressierten Speichern nicht von Bedeutung sind.
18
Simulation
Grundlagen
ex
pe
en
rim
System
r
tie
en
mit einem Modell
des Systems
an
mit dem eigent−
lichen System
ys
al
r
ie
en
bn
r
ie
ul
ge
abstraktes
Modell
sim
Er
physikalisches
Modell
er
uv
ez
en
iss
er
sig
s
lä
analytische
Lösung
Simulation
Ergebnisse unzuverlässiger
Abbildung 2.6: Methodik des Studiums eines Systems [32]
te sind hier die Maschinen, Komponenten und Arbeiter, die miteinander interagieren.
Einflüsse von außen sind zum Beispiel die Belieferung mit Material und Energie.
Die in einem System befindlichen Objekte lassen sich durch Eigenschaften beschreiben. Diese Eigenschaften können sich verändern und stellen damit die Variablen eines
Systems dar. Der Zustand eines solchen Systems ist definiert als die Gesamtheit der
Zustände aller Variablen zu jedem beliebigen Zeitpunkt [4]. Sei zum Beispiel ein Fachhandel ein System, in dem Kunden von Verkäufern beraten werden. So könnte der
Zustand dieses Systems durch die Anzahl der Verkäufer, die Anzahl der wartenden
Kunden und die Zeit, die vergangen ist, seit ein jeder Kunde das Geschäft betreten
hat, beschrieben werden.
Diskrete und kontinuierliche Systeme
Ein diskretes System zeichnet sich dadurch aus, dass die Variablen nur bestimmte
Zustände annehmen können. Zum Beispiel sind für die Anzahl der Verkäufer und Kunden im vorangehenden Beispiel nur ganze Zahlen zulässig. Auch die Zeit kann in diesem
Beispiel hinreichend genau durch ganze Zahlen in Minuten beschrieben werden.
Systeme, in denen die Variablen beliebige Zustände annehmen können, werden als
kontinuierliche Systeme bezeichnet. Ein Beispiel für ein kontinuierliches System ist der
19
Simulation
Grundlagen
Zusammenstoß eines Fahrzeuges mit einem Hindernis. Die hierbei auftretenden Kräfte
verändern sich kontinuierlich nach bestimmten physikalischen Gesetzmäßigkeiten.
Komplexere Systeme sind häufig nicht in allen Eigenschaften diskret oder kontinuierlich. Deshalb wird bei der Betrachtung der Eigenschaften häufig eine Auswahl
getroffen und es entsteht das Modell.
2.4.2
Modell
Ein Modell ist die Repräsentation eines Systems zu Studienzwecken. Dabei wird das
System auf die, für die Betrachtung relevanten Objekte und Eigenschaften beschränkt.
Es sind also bei verschiedenen Fragestellungen unterschiedliche Modelle für das selbe
System denkbar.
Modelle lassen sich anhand verschiedener Eigenschaften klassifizieren [32]:
Statische und dynamische Modelle
Ein statisches Modell repräsentiert ein System zu einem bestimmten Zeitpunkt oder
ein System, in dem Zeit keine Rolle spielt. Ein dynamisches Modell repräsentiert ein
System, dass sich in Abhängigkeit von der Zeit verändert.
Deterministische und stochastische Modelle
Ein Modell, das keine zufallsabhängigen Variablen enthält, wird als deterministisch
bezeichnet. Der Vorteil von deterministischen Modellen liegt darin, dass der Endzustand bereits feststeht, wenn der Anfangszustand und die äußeren Einflüsse definiert
sind. Das heißt, jeder Simulationslauf mit einem deterministischen Modell führt zum
gleichen, überprüfbaren Ergebnis.
Häufig sind Systeme nicht ohne zufällige Einflüsse modellierbar. Modelle, die zufallsabhängige Variablen enthalten, werden als stochastische Modelle bezeichnet. Hierbei
liefern Simulationen nur mögliche beziehungsweise wahrscheinliche Ergebnisse. Um Simulationen mit stochastischen Modellen wiederholbar und überprüfbar zu machen,
spielen Pseudo-Zufallszahlen eine entscheidende Rolle. Diese werden in Abschnitt 2.4.4
ausführlicher beschrieben.
20
Simulation
Grundlagen
Kontinuierliche und diskrete Modelle
Genau wie bei den Systemen werden auch Modelle anhand der Veränderung ihrer Variablen in kontinuierliche und diskrete Modelle unterschieden. Hier ergeben sich allerdings
drei Kategorien [44]:
Differentialgleichungsmodelle Der Zustand der Systemvariablen verändert sich
kontinuierlich über die Zeit. Diese Modelle werden meist durch eine Reihe differentieller Gleichungen repräsentiert. Die “Zukunft” wird in solchen Simulationen durch
Integrationsmethoden “berechnet”.
Zeitdiskrete Modelle Die Zeitachse ist in diskrete Intervalle konstanter Länge eingeteilt und der Zustand des Modells verändert sich nur zu diesen diskreten Zeitpunkten.
Den häufigsten Anwendungsfall für derartige Modelle bildet die detaillierte Simulation
digitaler Systeme.
Ereignisdiskrete Modelle Der Zustandswechsel der Variablen erfolgt hier durch
Ereignisse, die zu beliebigen Zeitpunkten auftreten können. Diese Art von Modellen
lassen sich zur Nachbildung digitaler Systeme sehr effektiv einsetzen.
2.4.3
Simulationsarten
Zur Simulation digitaler Systeme werden meist zeitdiskrete oder ereignisdiskrete Modelle verwandt. Entsprechende Simulationsarten werden nachfolgend kurz vorgestellt.
Zeitgesteuerte Simulation
Diese Simulationen werden schrittweise ausgeführt. Dabei wird die Zeit in gleichbleibenden Schritten, dem so genannten Takt, vorgegeben und die Veränderungen im Modell
entsprechend schrittweise berechnet. Der Folgezustand Z[i + 1] der Variablen hängt
hierbei lediglich vom vorhergehenden Zustand Z[i] und den äußeren Einflüssen ab.
Diese Vorgehensweise eignet sich für die Simulation zeitdiskreter Modelle. Ein Nachteil ist, dass entweder die zeitliche Auflösung sehr eingeschränkt ist oder die Simulation
aus einer sehr großen Anzahl von Simulationsschritten mit häufig sehr geringen oder
gar keinen Zustandsänderungen besteht.
21
Simulation
Grundlagen
Ereignisgesteuerte Simulation
Hier ist die Vorgehensweise wie folgt:
1. Die Simulationszeit wird auf Null initialisiert.
2. Die Simulationszeit wird auf den Zeitpunkt des zeitlich nächstgelegenen Ereignissen gesetzt.
3. Der Zustand des Systems wird entsprechend des Ereignisses angepasst.
4. Das Wissen um zukünftige Ereignisse wird aktualisiert und das Vorgehen wird
bei Schritt zwei fortgesetzt.
Ereignisgesteuerte Simulation hat den Vorteil, dass die Zustände des Systems nur
verändert werden, wenn ein äußeres Ereignis stattgefunden hat. Außerdem ist die
Zeitachse nicht diskretisiert und damit eine optimale zeitliche Auflösung möglich. Die
Simulation von zeitdiskreten und ereignisdiskreten Modellen ist hiermit möglich.
2.4.4
Pseudo-Zufall
Der Einfluss von zufälligen Ereignissen beziehungsweise Variablen, deren Zustand von
zufälligen Ereignissen abhängig ist, ist in Simulationen häufig nicht zu umgehen. Um
die exakte Wiederholbarkeit und somit Überprüfbarkeit von Simulationsläufen sicherzustellen, kommen Pseudo-Zufallszahlen zum Einsatz.
In [4] werden fünf Anforderungen an Routinen zur Generierung von PseudoZufallszahlen gestellt:
• Die Routine zum Generieren der Pseudo-Zufallszahlen muss schnell sein, da sie
meist häufig benötigt wird und damit signifikanten Einfluss auf die Geschwindigkeit der Simulation hat.
• Sie muss portabel sein, damit die Simulation auf unterschiedlichen Plattformen
die gleichen Ergebnisse liefert.
• Die Routine muss einen ausreichend langen Zyklus haben. Die Länge eines Zyklus’
gibt an, wie viele Pseudo-Zufallszahlen generiert werden können, bis sich eine
Menge von Werten in der gleichen Reihenfolge wiederholt. Außerdem darf die
Routine nicht degenerieren, das heißt nach einer bestimmten Anzahl produzierter
Werte anfangen, wiederholt den gleichen Wert zu generieren.
22
Simulation
Grundlagen
• Die Reihenfolge der generierten Werte muss wiederholbar sein. Das heißt, bei gleichem Startwert muss die Routine auch die gleiche Folge an Pseudo-Zufallswerten
zur Verfügung stellen.
• Die produzierten Werte müssen Gleichverteilung und Unabhängigkeit möglichst
gut simulieren.
Es gibt mehrere Algorithmen, um solche Zahlen zu produzieren. Außerdem werden verschiedene Tests beschrieben, um Algorithmen auf diese Eigenschaften hin zu
überprüfen. Diese werden hier nicht im Einzelnen vorgestellt.
23
Kapitel 3
Bisherige Arbeiten
Dieses Kapitel gibt einen Überblick über bisherige Arbeiten zum Thema. Im ersten
Abschnitt werden verschiedene Anstrengungen zur Entwicklung von Simulatoren für
verteilte Rechnersysteme vorgestellt. Der zweite Abschnitt gibt einen umfangreichen
Überblick über bisherige Forschungsergebnisse im Bereich der verteilten assoziativen
Datenspeicherung.
3.1
Simulatoren
Komplexitäten und Performanceprognosen für deterministische Algorithmen in verteilten Systemen lassen sich häufig noch berechnen, aber schon bei wenigen adaptiven
Optimierungen oder gar komplett adaptiven Algorithmen ist die Simulation das Mittel
der Wahl, um Aussagen über Performance und Komplexität zu gewinnen.
Grid-Simulatoren wie SimGrid [8], GridSim [6] und MicroGrid [9] bilden ein komplettes Grid-System nach und dienen hauptsächlich der Evaluierung von SchedulingAlgorithmen. Für die Simulation von Algorithmen zur Verteilung von Daten sind sie
weitgehend ungeeignet.
Für die Simulation von Datenverteilungsalgorithmen sind P2P-Simulatoren gut geeignet. Einige Vertreter werden nachfolgend kurz vorgestellt und bezüglich ihrer Eignung für diese Arbeit geprüft. Bei der Beschreibung des Funktionsumfangs einiger
vorgestellter Simulatoren werden Bezeichnungen von Algorithmen benutzt, ohne auf
deren Funktionsweise einzugehen. Eine detaillierte Übersicht über bisher entwickelte
Algorithmen und deren Funktionsweise findet sich im Abschnitt 3.2.
24
Algorithmen zur verteilten Speicherung von Daten
3.1.1
Bisherige Arbeiten
P2psim und Myns
Zwei C-basierte P2P-Simulatoren sind P2psim [23] und Myns [2]. Sie befinden sich
in den Anfängen der Entwicklung und sind somit als Grundlage dieser Arbeit nicht
geeignet.
P2psim stellt bereits eine Reihe von Algorithmen, darunter Chord und Tapestry
zur Verfügung. Die Algorithmen werden in C programmiert. Die Simulation wird über
verschiedene Konfigurationsdateien gesteuert. P2psim bietet keine grafische Benutzerschnittstelle.
Myns stellt einige Application-Level-Multicast-Algorithmen, darunter Narada [10]
und NICE [3], zur Verfügung. Auch hier werden die Algorithmen in C implementiert.
Die Steuerung der Simulation erfolgt über ein Script. Eine grafische Benutzeroberfläche
bietet myns ebenfalls nicht.
3.1.2
Peersim
Peersim [27] ist in Java entwickelt. Er kann eine große Anzahl von Knoten simulieren
und wird über eine umfangreiche Konfigurationsdatei gesteuert. Algorithmen werden
in Java implementiert.
Um bis hin zu mehreren Millionen Knoten simulieren zu können, nimmt peersim keine Rücksicht auf Netzwerktopologien, Verbindungskosten und Eigenschaften einzelner
Knoten. Da ein Ziel dieser Arbeit die Nachbildung von Eigenschaften der Netzwerktopologie und der einzelnen Knoten ist, ist peersim als Grundlage nicht geeignet.
3.2
Algorithmen zur verteilten Speicherung von
Daten
Die Entwicklung von Algorithmen zur assoziativen verteilten Speicherung von Daten
ist eng mit der Entwicklung der File-Sharing-Programme verbunden. Die ersten derartigen Algorithmen fanden dort Verwendung. Zur ersten Generation dieser Programme
gehören Napster [31] und ähnliche Programme. Eine Weiterentwicklung hin zu besserer Skalierbarkeit und Robustheit fand sich in Gnutella-basierenden File-SharingProgrammen [24]. Der erste Distributed Hash Table (DHT)-basierende Algorithmus,
CAN, wurde 2001 veröffentlicht [34].
25
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Zunächst werden die grundlegende Funktionsweise der erstgenannten Verfahren
und deren Nachteile vorgestellt. Anschließend werden einige ausgewählte Vertreter der
DHT-basierenden Algorithmen vorgestellt, um einen Überblick über den Entwicklungsstand dieser Gruppe von Algorithmen zu geben.
3.2.1
Technologien aus dem frühen File-Sharing-Umfeld
Die Motivation der Entwicklung von File-Sharing-Programmen ist der Austausch von
Dateien über das Internet. Dabei ist eine assoziative Zugriffsstruktur gegeben. Der
Dateiname dient hierbei als Schlüssel und verweist auf den Knoten, der diese Datei
zur Verfügung stellt. Dieser Abschnitt soll aufzeigen, wie die gängigen Vertreter der
File-Sharing-Programme diesen assoziativen Zugriff lösen und welche Nachteile hierbei
auftreten.
zentralisierte Ansätze
Zu den ersten File-Sharing-Programmen, die Verbreitung fanden, gehört Napster.
Es benutzt einen zentralisierten Algorithmus, bei dem die gesamte Auflösung von
Schlüsseln auf Adressen über einen zentralen Server erfolgt. Der große Vorteil dieses
Verfahrens liegt in der perfekten Kontrolle über die Daten. Da jeder Datensatz beim
zentralen Server registriert ist, können Replikation und Verteilung sowie Sicherheit und
Zugriffsrechte perfekt gesteuert werden.
Ein scheinbarer Vorteil ist auch, dass die Suchanfragen nicht durch die einzelnen
Knoten geroutet werden müssen und somit deutlich weniger latenzbelastet sind. Allerdings kann es bei einem zentralen Server sehr schnell zu Überlastungserscheinungen
kommen. Der Algorithmus skaliert nicht. Außerdem stellt der zentrale Server einen
single point of failure dar. Der Ausfall nur eines Servers hat den Ausfall des gesamten
verteilten Speichers zur Folge.
Random Power-Law Graphs (RPLG)
Eine vollkommene Dezentralisierung der File-Sharing-Programme wurde durch die Verwendung so genannter overlay networks, einer auf den Anwendungszweck optimierten
Netzwerktopologie auf Anwendungsebene, möglich. Die ersten Implementierungen, wie
zum Beispiel Gnutella, basieren auf einem RPLG. Die Funktionsweise ist ebenso einfach
wie robust. Jeder Knoten im verteilten Speicher kennt eine zufällige Anzahl anderer
Knoten. Jede Suchanfrage wird als Application-Level Multicast durch das gesamte
26
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
System geschickt. Dieses Flooding wird von zwei Parametern kontrolliert. Anhand der
Anfrage-ID wird Rückläufigkeit im RPLG verhindert und mit Hilfe der Time to Live (TTL) lässt sich der Grad der Ausbreitung der Anfrage beeinflussen.
Die Vorteile dieses Verfahrens liegen in der hohen Robustheit. Über eine Menge
von sehr stabilen Superknoten wird gewährleistet, dass ein neuer Knoten immer einen
aktiven Knoten im System finden und anschließend vollständig am System teilnehmen
kann. Außerdem ist das System unanfällig gegen den Ausfall vieler einzelner Knoten
und skaliert bis zu mehreren Millionen Knoten.
Zwei entscheidende Nachteile dieses Algorithmus’ sind der Mangel an Kontrolle und
die hohe Netzlast. Der Algorithmus bietet keine Möglichkeit, Verteilung und Replikation deterministisch zu steuern. Die hohe Netzlast durch die weitläufigen Suchoperationen hat ebenfalls eine hohe Latenz bei Suchanfragen zur Folge.
3.2.2
DHT-basierende Algorithmen
Die Idee der DHT-basierenden Algorithmen ist es, sowohl die Schlüssel der Datensätze
als auch die Knotenadressen über eine Hash-Funktion in den gleichen Wertebereich
abzubilden. Ein Knoten ist für die Verwaltung der Daten in seinem Abschnitt des
Wertebereichs zuständig. Ein Overlay-Routing beschreibt dann, wie in diesem Wertebereich von einem Wert beziehungsweise Knoten zu einem Zieldatensatz und damit
dem Knoten, der ihn verwaltet, geroutet wird. Die verschiedenen Algorithmen unterscheiden sich im genutzten Wertebereich und damit der Hash-Funktion sowie dem
Overlay-Routing-Verfahren.
Der Vorteil von DHT-basierenden Verfahren ist, dass sie, obwohl sie sehr gut skalieren, eine gute Kontrolle über die Verteilung und Replikation der Daten ermöglichen.
Als einziger Nachteil bleiben die Differenzen zwischen dem Overlay-Routing und dem
darunter liegenden IP-Routing. Sie haben zur Folge, dass die Pfade von Paketen relativ
zum IP-Routing betrachtet, sehr lang werden können. Die Folge ist eine Erhöhung von
Latenz und Netzlast.
Es gibt zwei Möglichkeiten, diesen Nachteil zu minimieren. Eine ist die Erhöhung
der Lokalität der Overlay-Routing-Verfahren. Durch stark adaptive Algorithmen wird
eine Vermeidung von Umwegen im IP-Routing angestrebt. Die zweite Möglichkeit ist
die Minimierung der Anzahl der Routing-Schritte. Je weniger Schritte nötig sind, desto
weniger Gefahr besteht, Umwege zu beschreiten.
27
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
DHT-basierende Algorithmen lassen sich über zwei Eigenschaften charakterisieren,
die durchschnittliche Anzahl der Routing-Schritte und die Anzahl der Einträge in der
Routing-Tabelle eines Knotens. Die ersten Algorithmen wie zum Beispiel CAN [34],
Chord [39] und Pastry [37] stellten einen Kompromiss zwischen beiden Parametern
dar.
Mit Viceroy [29] und Distance Halving [30] gelang es, auch mit konstanter Anzahl
an Routing-Tabellen-Einträgen, logarithmische Routing-Schritt-Komplexitäten zu erreichen.
Die DHT-basierenden Algorithmen wurden inzwischen auch in File-SharingProgrammen adaptiert. Ein Beispiel hierfür ist Overnet [33]. Eine Auswahl an Algorithmen dieser Gruppe, Content-Addressable Network (CAN), Chord und Distance
Halving, werden in den folgenden Abschnitten näher vorgestellt.
3.2.3
Content-Addressable Network
CAN arbeitet auf einem d-dimensionalen Wertebereich, der als Koordinatensystem auf
einem d-Torus angeordnet ist. Das heißt, der Wertebereich ist in allen Dimensionen
begrenzt und der Wert 0 ist direkter Nachfolger des größten Wertes in einer Dimension
(siehe auch Abbildung 3.1).
Zur Erklärung des Algorithmus’ wird von d = 2 ausgegangen. Ein Schlüssel wird von
einer Hash-Funktion auf einen Punkt im Koordinatensystem abgebildet. Der Torus ist
nur beim Routing von Bedeutung, um die maximale Entfernung zwischen zwei Punkten
zu halbieren.
Hinzufügen neuer Knoten
Der Wertebereich wird wie folgt auf die Knoten aufgeteilt: Nimmt ein neuer Knoten
am verteilten Speicher teil, so wählt er einen zufälligen Punkt im Wertebereich, zum
Beispiel durch die Anwendung der Hash-Funktion auf seine IP-Adresse. Der Knoten,
der diesen Punkt bisher verwaltet, halbiert seinen Bereich und überträgt alle Daten aus
der Hälfte, in der sich der gewählte Punkt befindet an den neuen Knoten. So entsteht
ein Gitter, dessen Teil-Rechtecke von einzelnen Knoten verwaltet werden. Jeder Knoten verwaltet also all die Datensätze deren Schlüssel durch die Hash-Funktion in sein
Teil-Rechteck abgebildet werden. In Abbildung 3.1 ist ein solches Gitter beispielhaft
dargestellt.
28
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Datensatz im Wertebereich
der Hash−Funktion
Verwaltungsbereich
eines Knotens
(Schlüssel)
Hash
(14,10)
Abbildung 3.1: CAN-Gitter mit Datensatz
Routing im CAN
Als Overlay-Routing im CAN kommt adaptives x-y-z-Routing [35] zum Einsatz. Dabei
wird die Distanz vom Startpunkt zum Zielpunkt in x- und y-Richtung in beliebiger
Reihenfolge nach bestimmten Kriterien zurückgelegt. Der Ablauf für jeden beteiligten
Knoten ist folgendermaßen:
1. Der Knoten bestimmt seinen Abstand vom Zielpunkt als Länge der kürzesten
direkten Verbindungslinie im CAN-Gitter.
2. Der Knoten bestimmt für jeden Knoten in seiner Nachbartabelle ebenfalls diesen
Abstand.
3. Der Knoten schickt die zu routenden Daten zu einem der Nachbarn, für den dieser
Abstand kleiner ist als der eigene.
Als Kriterium für die Auswahl des nächsten Knotens kann zum Beispiel die RoutingEntfernung zwischen den Knoten in der darunter liegenden Netzwerktopologie dienen.
Als Routing-Tabelle benötigt dazu jeder Knoten einen Zeiger auf jeden Nachbarknoten. Nachbarknoten eines Knotens k sind all diejenigen Knoten, die sich in ihrer
29
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Lage im CAN-Gitter von k in nur einer Dimension unterscheiden und an k angrenzen,
also alle Knoten, die mit k eine (d − 1) -dimensionale Seitenfläche oder -linie teilen.
Entfernen von Knoten aus dem CAN
Will ein Knoten k seine Teilnahme am verteilten Speicher beenden, so sendet er all seine
Daten an den Nachbarknoten, dessen Bereich mit dem von k konvex zusammengefügt
werden kann. Gibt es keinen solchen Nachbarknoten, so muss einer der Nachbarknoten
so lange zwei Bereiche verwalten, bis ein neuer Knoten ihm einen dieser Bereiche wieder
abnimmt.
Um den Ausfall eines Knotens zu erkennen, sendet jeder Knoten in regelmäßigen
Abständen ein Signal an seine Nachbarn. Ist ein Knoten ausgefallen, wird dessen Bereich von einem der Nachbarn übernommen. Die Daten sind verloren.
Routing-Komplexität im CAN
Diese einfache Version des CAN hat pro Knoten O(d) Einträge in der Routing-Tabelle.
Die durchschnittliche Anzahl an Routing-Schritten kann mit der Komplexität O(dN 1/d )
angegeben werden, wobei N die Anzahl der Knoten im CAN ist.
Diese Komplexitäten, insbesondere die Anzahl der Routing-Schritte, ist mit modernen Algorithmen wie zum Beispiel Distance Halving nicht mehr konkurrenzfähig.
Allerdings hat CAN den großen Vorteil, dass er auf Grund seiner Einfachheit viele
Optimierungen zulässt, die das Verhalten des Algorithmus’ deutlich verbessern. Die
wichtigsten werden nachfolgend kurz erklärt, weil an anderen Stellen dieser Arbeit auf
sie zurückgegriffen wird.
Replikation durch Realitäten
Realitäten sind unabhängig voneinander arbeitende Content-Addressable Networks wie
in Abbildung 3.2 dargestellt. Dabei verwaltet jeder Knoten einen Bereich aus jeder
Realität. Dies darf aber niemals in zwei Realitäten der gleiche Bereich sein. Wird ein
Datensatz gespeichert, so wird er immer für jede Realität auf dem Knoten gespeichert,
der diesen Datensatz in der entsprechenden Realität verwaltet. Damit wird sichere
Replikation im CAN möglich. Fällt ein Knoten aus, so können seine Datensätze aus
einer anderen Realität gerettet werden.
Ein weiterer Vorteil bietet sich beim Suchen nach Datensätzen. Jeder Knoten kann
nun flexibel eine seiner Realitäten als Ausgangspunkt für das Routing auswählen. Dies
30
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Realitäten
von einem Knoten
kontrollierte Zonen
Abbildung 3.2: Zonen eines Knotens in einem CAN mit drei Realitäten.
führt auf langen Routen mit hoher Wahrscheinlichkeit zu Abkürzungen weil die Wahrscheinlichkeit, dass ein Knoten in einer anderen Realität dichter am Ziel liegt, mit dem
Abstand vom Ziel steigt.
Caching im CAN
Beim CAN sind zwei verschiedene Arten von Caching möglich. Für den wiederholten
Zugriff auf den gleichen Datensatz durch den gleichen Knoten ist es sinnvoll, diesen Datensatz im zugreifenden Knoten zwischenzuspeichern. Caching im zugreifenden Knoten
beschleunigt die Suche nach genau diesem Datensatz auf genau diesem einen Knoten.
Knoten mit Datensatz
mit vielen Zugriffen
zugreifender Knoten
Zugriffe
Knoten, der den Daten−
satz zwischenspeichert
Abbildung 3.3: Caching durch Replikation im Nachbarknoten
31
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Bei häufigen Zugriffen aus dem verteilten Speicher auf den gleichen Knoten ist es
möglich, die betroffenen Daten auf dessen Nachbarknoten zwischenzuspeichern. Abbildung 3.3 verdeutlicht diesen Vorgang. Replikation auf Nachbarknoten dient in erster
Linie der Vermeidung von hotspots, also Zonen hoher Aktivität, die gefährdet sind,
frühzeitig überlastet zu werden.
3.2.4
Chord
Mit Pastry [37], Tapestry [45] und Chord [39] entstanden die ersten DHT-basierenden
Algorithmen mit logarithmischer Komplexität für die Länge der Routing-Pfade. Allerdings war dafür auch eine logarithmische Komplexität für die Anzahl der RoutingTabellen-Einträge pro Knoten notwendig. Stellvertretend für diese Algorithmen wird
Chord kurz vorgestellt, da er ein sehr einfaches und gut nachvollziehbares OverlayRouting benutzt. In Pastry und Tapestry kommt Hypercube-Routing [35] zum Einsatz.
Dadurch werden die Routing-Tabellen deutlich komplexer.
Chord basiert auf einem Kreis von ID’s Modulo 2m , wobei jeder Schlüssel durch
eine Hash-Funktion auf eine dieser ID’s abgebildet wird. Dabei muss m ausreichend groß gewählt werden, um Überlappungsfreiheit zu gewährleisten. Die IDs h
liegen somit im Bereich 0 < h < 2m − 1. Wie bei DHT-basierenden Algorithmen
üblich werden auch die Knoten in den gleichen Wertebereich, also als Punkte auf
den ID-Kreis abgebildet. Die Operation K = N achf olger(h) liefert den nächstgelegenen Knoten K von der ID h aus gesehen im Uhrzeigersinn. Für jeden Knoten K
gilt K = V orgaenger(N achf olger(K)). Ein Knoten mit der ID K verwaltet alle Datensätze für deren ID h gilt: K = N achf olger(h).
Routing im Chord
Jeder Knoten im Chord kennt seinen Vorgängerknoten und seinen Nachfolgerknoten.
Das simpelste Routing wäre also ein Pfad im Uhrzeigersinn um den Kreis bis zum Ziel.
Um eine logarithmische Anzahl von Routing-Schritten zu gewährleisten, kennt jeder
Knoten N noch eine festgelegte Zahl an Fingerknoten N.f inger[i]. Diese sind wie folgt
rekursiv definiert:
N.F inger[1] = N achf olger(N )
(3.1)
N.F inger[i + 1] = N achf olger(N + 2i )
(3.2)
32
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Das Routing vom Knoten N zur Ziel-ID z erfolgt weiterhin strikt im Uhrzeigersinn. Dabei wird immer der Fingerknoten N.F inger[i] gewählt, für den gilt:
N.F inger[i] < z < N.F inger[i + 1]. Abbildung 3.4 zeigt den Wertebereich mit Knoten sowie die Fingerknoten eines ausgewählten Knotens.
Nachfolger(K)
Knoten K
Abschnitt, der von
Knoten K verwaltet wird
Zeiger auf
K.Finger[i]
Vorgaenger(K)
Hilfslinien: N + 2
i
0
Abbildung 3.4: Chord-Wertebereich mit Knoten und Fingerknoten
Hinzufügen neuer Knoten und Entfernen von Knoten
Das Hinzufügen neuer Knoten erfolgt wiederum durch Wahl eines zufälligen ID durch
den neuen Knoten N . Der Knoten K mit K = N achf olger(N ) übergibt alle Datensätze
mit IDs i < N an den neuen Knoten. Das Entfernen eines Knotens führt zur Abgabe
aller Datensätze an seinen Nachfolger.
Um den Ausfall von Knoten sowie den Zugang neuer Knoten zu bemerken, wird
regelmäßig von allen Knoten eine Selbstheilungsfunktion stab() ausgeführt. Dabei fragt
ein Knoten seinen Nachfolger nach dessen Vorgänger. Hierbei wird bemerkt, wenn sich
ein neuer Knoten zwischen den beiden Knoten angesiedelt hat. Außerdem bemerkt jeder
Knoten auf diese Weise den Ausfall seines Nachfolgers und kann dessen Datenbereich
zukünftig mitverwalten.
33
Algorithmen zur verteilten Speicherung von Daten
3.2.5
Bisherige Arbeiten
Distance Halving
Die Entwicklung der Algorithmen erreichte mit Viceroy [29] einen neuen Meilenstein.
Erstmals war es möglich, eine logarithmische Anzahl von Routing-Schritten mit einer konstanten Anzahl von Routing-Tabellen-Einträgen pro Knoten zu realisieren. Da
Viceroy ein sehr komplexer Algorithmus ist, wird er nicht näher beschrieben.
Eine nochmalige Verringerung der Anzahl der Routingschritte gelang mit Distance
Halving. Dieser Algorithmus kommt mit folgenden Komplexitäten für die Anzahl der
Routing-Schritte (dilatation - Formel 3.3) und Routing-Tabellen-Einträge pro Knoten
(linkage - Formel 3.4) aus. Dabei repräsentiert n die Anzahl der Knoten und d eine zur
Dimensionalität äquivalente Option des Algorithmus’, die am Ende dieses Abschnittes
erklärt wird.
O(dilatation) = O(logd n)
O(linkage) = O(d)
(3.3)
(3.4)
Da es sich bei Distance Halving um einen erstaunlich einfachen Algorithmus handelt, wird er nachfolgend kurz erklärt.
Bei Distance Halving werden die Schlüssel der Datensätze durch eine Hash-Funktion
auf einen Bereich von 0 bis 1 abgebildet. Auch jeder Knoten bekommt eine ID in diesem
Wertebereich. Der Knoten K[i] verwaltet dabei alle Datensätze für deren IDs h gilt:
K[i] ≤ h < K[i + 1].
(3.5)
Aufbau der Routing-Tabelle
Jeder Knoten K verwaltet Zeiger in der Art, dass er sämtliche Knoten Z kennt, die eine
der IDs z verwalten, auf die eine der folgenden Eigenschaften für jede von K verwaltete
ID k zutrifft.
z = k/2
k+1
z =
2
(3.6)
(3.7)
Dabei beschreibt Eigenschaft 3.6 immer Zeiger nach links in die linke Hälfte des Wertebereichs und Eigenschaft 3.7 immer Zeiger nach rechts in die rechte Hälfte des Wertebereichs.
34
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Die beiden Zeiger 3.6 und 3.7 haben eine besondere Eigenschaft, der der Algorithmus seinen Namen verdankt: Gegeben seien zwei beliebige Punkte p1 und p2 im Wertebereich der Hash-Funktion. Wendet man eine der Zeigerfunktionen auf diese beiden
0
0
0
Punkte an, so erhält man p1 und p0 2 . Es gilt dann p1 − p2 = 21 (p1 − p2 ). Der Abstand
zwischen den Punkten halbiert sich bei genau einer Anwendung. Diese Eigenschaft
bildet die Grundlage für das Routing.
Routing durch Distance Halving
Angenommen, Knoten K0 möchte zum Zielpunkt z0 routen. Man stelle sich sowohl
vom Startpunkt K0 als auch von z0 ausgehend eine Ausführung eines beliebigen, aber
für beide gleichen Zeigers vor. Man erhält die Punkte K1 und z1 . Dieser Vorgang wird
so lange wiederholt, bis Kx und zx in den Verwaltungsbereich des gleichen Knotens X
fallen. Dieses Vorgehen wird in Abbildung 3.5 dargestellt.
0
1
0.5 d
Knoten X
d
Ziel z
Knoten K
Hin−Route − Zeiger links (eigentlich beliebig)
Rück−Route − Zeiger rechts (entgegengesetzt)
Abbildung 3.5: Wertebereichsaufteilung
Algorithmus
und
Routing
im
Distance-Halving-
Die Route von K0 zu z0 sieht nun im Wertebereich wie folgt aus: K0 , K1 , . . . ,
Kx , zx−1 , . . . , z1 , z0 . Dabei wird jeder dieser Punkte von einem Knoten verwaltet, der
die entsprechenden Routing-Schritte ausführt. Es fällt auf, dass die erste Hälfte des
Routing-Pfades nur von der Wahl der Zeiger, links oder rechts, abhängig und somit
frei wählbar ist. Die zweite Hälfte stellt den Rückweg dar und ist durch die Wahl der
ersten Hälfte des Pfades festgelegt.
35
Algorithmen zur verteilten Speicherung von Daten
Bisherige Arbeiten
Erweiterungen von Distance Halving
Das soeben beschriebene Verfahren lässt sich nun beliebig skalieren. Wenn statt der
beiden Zeiger 3.6 und 3.7 die folgenden drei Zeiger verwendet werden:
z = k/3
k+1
z =
3
k+2
z =
3
(3.8)
(3.9)
(3.10)
so wird der Abstand zwischen Start- und Zielpunkt pro Schritt gedrittelt. Dies geschieht
auf Kosten der Länge der Routing-Tabelle, die sich um den Faktor 32 verlängert, da an
Stelle von 2 Zeigern nun 3 Zeiger pro Knoten gespeichert werden müssen. Die Anzahl
der verwendeten Zeiger d ist der Parameter von dem die Komplexitäten 3.3 und 3.4
abhängen.
36
Kapitel 4
Konzept
In diesem Kapitel werden konzeptuelle Überlegungen dargelegt. Den Anfang bildet ein
Abschnitt zur geplanten Simulation, insbesondere zur Modellierung des zu simulierenden Systems und der Wahl einer geeigneten Plattform.
Darauf folgen einige Überlegungen zu dem zu implementierenden Algorithmus. Da
als Grundlage CAN verwendet wird und der Algorithmus bereits im letzten Kapitel
ausführlich erklärt wurde, werden hauptsächlich mögliche Optimierungen diskutiert.
4.1
Die Simulation
Dieser Abschnitt charakterisiert die geplante Simulation. Dabei wird zuerst das zu
simulierende System untersucht. Anschließend wird ein passendes Modell entwickelt.
Darauf folgt die Wahl einer geeigneten Simulationsumgebung auf Basis der gewonnenen
Erkenntnisse.
4.1.1
Das simulierte System
Das System besteht aus einer gegebenen Netzwerktopologie, über welche eine Reihe
von Knoten verbunden sind. Diese Knoten kommunizieren nach bestimmten Vorgaben
miteinander. Die Knoten werden von Benutzern gesteuert. Zu untersuchende Objekte
sind also die beteiligten Netzwerkkomponenten, die Knoten sowie die Benutzer.
37
Die Simulation
Konzept
Netzwerkkomponenten
Grundsätzlich unterschiedliche beteiligte Netzwerkkomponenten sind Hubs, Switches
und Router sowie die Knoten selbst. Eine Gemeinsamkeit all dieser Netzwerkkomponenten sind die Verbindungen zwischen ihnen, die bestimmte Kosten bei der Kommunikation verursachen. Außerdem verursachen die Netzwerkkomponenten durch ihre individuellen Eigenschaften Kosten. Die Kosten lassen sich über die zu übertragene Datenmenge, die maximale Paketgröße im verwendeten Netzwerkprotokoll sowie verfügbare
Bandbreite und Latenzeigenschaften charakterisieren.
Knoten
Die Knoten haben neben der Kommunikation über die Netzwerktopologie weitere Eigenschaften, die Kosten verursachen. Dazu gehören in erster Linie die Speicher. Festspeicher sowie flüchtige Speicher sind in ihrer Kapazität begrenzt und verursachen
Kosten, insbesondere Latenz und Bandbreite.
Benutzer
Die Benutzer lösen Ereignisse in Form von Befehlen an die Knoten aus und nehmen
die Reaktionen der Knoten auf diese Befehle entgegen. Sie haben selbst aber keine
Eigenschaften, die für die Simulation von Bedeutung sind. Sie verursachen somit im
System äußere Einflüsse, auf die die im System verbundenen Objekte, Knoten und
Netzwerkkomponenten, in geeigneter Form reagieren.
Damit ergeben sich weitere Eigenschaften für das System. Im Einzelnen sind das die
Zeitpunkte der Befehlsauslösung sowie die Dauer der Ausführung und eine Information
über den Erfolg der Befehlsausführung.
4.1.2
Entwicklung eines geeigneten Modells
Zuerst werden alle im System verbundenen Objekte und ihre Eigenschaften abgebildet.
Darauf folgt die Modellierung der Systemeigenschaften. Den Abschluss bildet eine kurze
Zusammenfassung aller Eigenschaften des Modells.
Netzwerkkommunikation
Stellvertretend für die Netzwerkkommunikation wird die sendende Netzwerkschnittstelle abgebildet und um Eigenschaften der daran angeschlossenen Netzwerkverbin38
Die Simulation
Konzept
dung ergänzt. Für die Untersuchung relevante Eigenschaften sind die durchschnittliche
Bandbreite bnet der Netzwerkverbindung und die Latenz lnet . Sie bestimmen die Übertragungszeit ts eines Netzwerkpaketes mit der Größe snet :
snet
(4.1)
bnet
Die minimale und maximale Größe eines solchen Netzwerkpaketes smin und smax
sowie der Overhead pro Netzwerkpaket sovh , also die durchschnittliche Größe, des nicht
durch Daten nutzbaren Teils, stellen weitere Eigenschaften der Netzwerkkommunika→
−
tion dar. Außerdem sind noch die Größe snet , der Inhalt i net und die Zieladresse znet
der Netzwerkpakete von Bedeutung.
ts = lnet +
Hub
Ein Hub wird als ein Objekt angenommen, das Netzwerkpakete empfängt, eine bestimmte Zeit - seine eigene Latenz lhub - wartet und dann das Paket über all seine
Netzwerkschnittstellen weiter versendet. Damit ergibt sich folgende Bearbeitungszeit
thub eines Paketes im Hub mit ts als die Übertragungszeit des Paketes am langsamsten
Interface (laut Formel 4.1):
thub = lhub + ts
(4.2)
Switch
Ein Switch sendet ein Netzwerkpaket anhand einer Logik nur an bestimmte Interfaces
und ist in der Lage bereits das nächste Paket zu bearbeiten während das vorangehende
Paket noch versandt wird. Eine maximale Queue-Länge wird nicht simuliert. Damit
berechnet sich die Bearbeitungszeit tswi eines Netzwerkpaketes im Switch nach Formel
4.3 aus der Bandbreite der Netzwerkverbindung bnet , von der das Paket empfangen
wird. Der Wert von aswi hängt vom Algorithmus Aswi ab, mit dem der Switch arbeitet.
Die beiden Extrema sind Cut Through und Store and Forward . Bei einem Switch,
der mit Aswi = Cut Through arbeitet, gilt aswi = 14, da nur der Ethernet-Header
gelesen und anhand dessen Inhalt das Ziel-Interface ausgewählt wird. Ein Switch, der
mit Aswi = Store and Forward arbeitet, liest das gesamte Paket ein und entscheidet
erst dann. Hier gilt aswi = snet .
tswi =
aswi
bnet
(4.3)
39
Die Simulation
Konzept
Router
Ein Router empfängt ein Netzwerkpaket zuerst vollständig und entscheidet anschließend, an welche Schnittstellen das Paket versandt wird. Dieser Entscheidungsprozess
nimmt Zeit in Anspruch, die Latenz lrou des Routers. Die Bearbeitungszeit eines Paketes trou ergibt sich demzufolge folgendermaßen aus der Latenz lrou , der Bandbreite bnet
der Netzwerkverbindung, von der das Paket empfangen wurde und der Größe snet des
zu bearbeitenden Netzwerkpaketes:
trou = lrou +
snet
bnet
(4.4)
Knoten
Der Knoten hat über seine Kommunikationsschnittstellen hinaus keine weiteren Eigenschaften in Verbindung mit der Netzwerkkommunikation. Die Speicherung von Daten
im Knoten findet über zwei mögliche Speicher statt, den Festspeicher und den Cache.
Diese werden im Anschluss modelliert.
Speicher
Ein Speicher hat eine maximale Kapazität kmem . Außerdem benötigt er zum Speichern
und Laden von Daten eine Latenzzeit lmem und überträgt auf sein Speichermedium Daten nur mit einer durchschnittlichen Bandbreite bmem . Die Zeit tmem für das Speichern
oder Laden einer Datenmenge der Größe s berechnet sich wie folgt:
smem
(4.5)
bmem
Außerdem hat ein Speicher einen Füllstand d, der die Menge der momentan dort
→
−
abgelegten Daten i netp widerspiegelt.
tmem = lmem +
Systemeigenschaften
Zusätzlich zu den zuvor aufgeführten Attributen der einzelnen Objekte gibt es noch
Eigenschaften, die sich keinem Objekt zuordnen lassen, aber für die Simulation von
Bedeutung sind. Die wichtigste Eigenschaft ist hierbei die Zeit t, auch als Simulationszeit bezeichnet. Außerdem sind noch der Startzeitpunkt Tcmd und die Ausführungszeit
−
tcmd der Befehle der Benutzer an die Knoten von Bedeutung sowie die Rückgabe →
r cmd
und der Ausführungsstatus zcmd dieser Befehle.
40
Die Simulation
Konzept
Zusammenfassung
Tabelle 4.1 stellt zusammenfassend alle Eigenschaften der Simulation dar. Dabei wird
zwischen konstanten Eigenschaften, wie Kommunikationskosten oder Grenzwerten, und
Variablen unterschieden. Die konstanten Eigenschaften werden zu Beginn der Simulation festgelegt und definieren die Ausgangssituation. Die Variablen verändern sich
während der Simulation.
Eine besondere Rolle spielen die Ausführungszeiten und Rückgabewerte von Befehlen an Knoten. Sie werden während des Ablaufes der Simulation ermittelt und stellen
damit die Ergebnisse dar.
4.1.3
Simulationsumgebung
Die Wahl einer geeigneten Simulationsumgebung findet in zwei Schritten statt. Zuerst
wird das entwickelte Modell hinsichtlich bestimmter Kriterien untersucht. Aus diesen
werden Rückschlüsse auf die Anforderungen an die Simulationsumgebung geschlossen.
Einordnung des Modells
Nachfolgend wird versucht, das zuvor entwickelte Modell des zu simulierenden Systems hinsichtlich der in 2.4.2 vorgestellten Kriterien einzuordnen, um eine geeignete
Simulationsumgebung zu finden.
statisch oder dynamisch Es handelt sich um ein dynamisches Modell, da die
Ausführung zeitabhängig ist.
stochastisch oder deterministisch Das Modell, wie es zuvor beschrieben wurde,
ist deterministisch, da keine der Eigenschaften und somit keine Variablenveränderungen
zufallsabhängig sind.
Es wäre denkbar, die Eigenschaften als Durchschnittswerte anzusehen und während
der Simulation mit zufallsabhängigen Abweichungen zu versehen, um eine möglichst
wirklichkeitsnahe Nachbildung des Systems zu erhalten. Ein solches Modell wäre dann
stochastisch.
Für den weiteren Verlauf der Arbeit wird das deterministische Modell benutzt.
kontinuierlich oder diskret Das Verhalten des Modells wird durch äußere und
innere Ereignisse beeinflusst. Diese können zu beliebigen Zeitpunkten auftreten und
41
Die Simulation
Eigenschaft
Konzept
Beschreibung
Kosten der einzelnen Komponenten - konstant
bnetn,p Bandbreite der reinen Netzwerkkommunikation zwischen Gerät n
und Gerät p
lnetn,p Latenz der reinen Netzwerkkommunikation zwischen Gerät n und
Gerät p
lhubh durch den Hub h verursachte Latenz
Aswis vom Switch s verwendeter Algorithmus
lrour durch den Router r verursachte Latenz
bmemk,m Bandbreite des Speichers m im Knoten k
lmemk,m Latenz des Speichers m im Knoten k
Eigenschaften der Netzwerkkommunikation - konstant
smin minimale Größe eines Paketes auf dem Netzwerk
smax maximale Größe eines Paketes auf dem Netzwerk
sovh Größe des Overheads pro Paket durch Header auf dem Netzwerk
Systemeigenschaften - konstant
Tcmdk,x Zeitpunkt, zu dem der Befehl x an den Knoten k abgesetzt wird
tcmdk,x Ausführungszeit des Befehls x an den Knoten k
→
−
r cmdk,x Antwort des Knotens k auf einen Befehl x
zcmdk,x Rückgabewert des Knoten k auf einen Befehl x
Variablen
t Simulationszeit
snetp Größe des Netzwerkpaketes p
→
−
i netp Inhalt der Nutzlast des Netzwerkpaketes p
znetp Zieladresse des Netzwerkpaketes p
fk,x Füllstand des Speichers x im Knoten k
→
−
i netp Inhalt des Speichers x im Knoten k
Tabelle 4.1: Liste aller Eigenschaften des Modells.
42
Algorithmenentwicklung
Konzept
bestimmen Veränderungen in den Variablen des Systems. Die Inhalte sämtlicher Variablen mit Ausnahme der Simulationszeit beschränken sich auf eine diskrete Wertemenge
und verändern sich ausschließlich durch das Auftreten von Ereignissen. Es handelt sich
somit um ein ereignisdiskretes Modell.
Wahl der Simulationsumgebung
Wie in Abschnitt 2.4.3 beschrieben, eignet sich zur Nachbildung eines ereignisdiskreten
Modells eine ereignisgesteuerte Simulation.
Ein Paket zur Realisierung ereignisgesteuerter Simulationen in Java ist simjava
[26]. Simjava unterstützt die Abbildung von Objekten und deren Eigenschaften sowie
die ereignisgesteuerte Simulation der Abläufe im Modell. Außerdem stellt es weitere
Möglichkeiten, darunter Pseudo-Zufall, die Visualisierung von Simulationsläufen, das
Sammeln und Auswerten von Ergebnissen sowie das Schreiben detaillierter Logfiles,
zur Verfügung
4.2
Algorithmenentwicklung
Die Grundlage für den zu implementierenden Algorithmus bildet CAN, obwohl dieser
Algorithmus in der einfachsten Form, betrachtet man der Länge der Routing-Pfade,
eine schlechte Komplexität aufweist. Nachfolgend werden die Gründe für diese Wahl
erläutert. Im Anschluss werden einzelne Optimierungen vorgeschlagen, die bei der Implementierung umgesetzt werden können.
Vorteile von CAN
Die Routingtabellen im CAN bestehen im einfachsten Fall aus den Nachbarn in allen
2d Richtungen. Damit sind die Routingtabellen im Vergleich zu einigen anderen Algorithmen sehr kurz und von einfacher Struktur. Einfach strukturierte Routingtabellen
vereinfachen den Algorithmus selbst. Die einzelnen Knoten werden durch das Routing
nur minimal belastet.
CAN bietet sehr viele Freiheiten in der Wahl der Routing-Pfade. Ohne Umwege benutzen zu müssen, bietet das adaptive x-y-z-Routing meist eine große Anzahl möglicher
Routing-Pfade, um von einem Startpunkt aus ein bestimmtes Ziel zu erreichen.
Ein weiterer Vorteil für die Benutzung von CAN gerade in Simulationen ist die gute
Visualisierbarkeit des zweidimensionalen Wertebereichs.
43
Algorithmenentwicklung
Konzept
Mögliche Optimierungen
Außerdem bietet CAN sehr viele Möglichkeiten zur Optimierung. Einige wurden bereits
in verschiedenen Forschungsprojekten validiert, andere können im Simulator untersucht
werden. Nachfolgend werden die für diese Arbeit interessantesten Optimierungen vorgestellt.
Lastoptimierung und Knotenausfall Wenn die im CAN verwendete HashFunktion nicht selbstständig für eine optimale Gleichverteilung sorgt, ist es möglich,
dass eine Zone überläuft und der Knoten, der diese Zone versorgt, entlastet werden
möchte. Außerdem ist es möglich, dass ein Knoten aus dem Speicher entfernt wird
und seine Zone mit keiner Nachbarzone mehr konvex zusammenfügbar ist. Beide Fälle
führen dazu, dass mehr Zonen als Knoten vorhanden sind und ein Knoten entgegen
seiner vorgesehenen Funktionsweise zwei Zonen verwalten muss.
Die Optimierung sieht vor, dass jeder Knoten im CAN in der Lage ist, zwischen
z1 und z2 voneinander unabhängige Zonen mit ihren jeweiligen Nachbartabellen zu
verwalten. Dabei gilt z1 < z2 . Ziel des CAN ist es, dass jeder Knoten genau z1 Zonen
verwaltet. In den zuvor beschriebenen Ausnahmefällen ist es nun möglich, überschüssige Zonen so auf andere Knoten zu verteilen, dass sie maximal z2 Zonen verwalten.
Damit läuft das gesamte CAN trotz dieser Ausnahmefälle noch immer innerhalb seiner
Spezifikation.
Diese Optimierung hat auch Einfluss auf die Länge der Routing-Pfade. Dadurch,
dass die z1 bis z2 Zonen, die ein Knoten verwaltet zufällig über den Wertebereich
verteilt sind, ist die Wahrscheinlichkeit, dass eine der Zonen dichter am Ziel liegt als
eine andere, sehr hoch. Dies geht allerdings mit einer Erhöhung der Anzahl der Zonen
insgesamt einher. Ob der Vorteil der Verteilung der Zonen hierbei den Nachteil der
größeren Zonenanzahl überwiegt, ist im Simulator leicht überprüfbar.
Lastoptimierung bei Einbringen eines neuen Knotens Einen neuen Knoten
per Zufall in das CAN einzubringen, kann auf Dauer zu einer Ungleichverteilung der
Datenlast im verteilten Speicher führen. Dies wird insbesondere dann passieren, wenn
die Hash-Funktion die Daten nicht gleichmäßig verteilt, weil sie für die Daten nicht gut
geeignet ist.
Um diesem Effekt entgegenzuwirken, ist es sinnvoll, einen neuen Knoten dort in
den Wertebereich einzubringen, wo er benötigt wird. Das heißt, der neue Knoten übernimmt Zonen von Knoten, die bereits z2 Zonen verwalten. Sollten keine solchen Knoten
44
Algorithmenentwicklung
Konzept
vorhanden sein, so teilen Knoten, die besonders stark gefüllte Zonen verwalten, diese
in zwei Hälften und geben eine Hälfte an den neuen Knoten ab.
Durch Broadcasts ermittelte Nachbartabellen Ein großes Problem aller DHTbasierenden Algorithmen ist die Diskrepanz zwischen Overlay- und IP-Routing. Um
diesem Effekt entgegenzuwirken, kann jeder Knoten im CAN über Layer-2-Broadcasts
alle Knoten ermitteln, die sich im gleichen Subnetz befinden und somit besonders
schnell zu erreichen sind und diese in eine zusätzliche Nachbartabelle aufnehmen.
Da diese, im weiteren Verlauf der Arbeit als Layer 2 Nodes (L2N) bezeichneten
Knoten im Overlay-Routing mit hoher Wahrscheinlichkeit nicht-benachbarte Zonen
verwalten, kann somit unter Ausnutzung eventuell vorhandener Lokalität im CANRouting abgekürzt werden.
Caching als Replikation In [34] werden zwei Möglichkeiten des Cachings vorgeschlagen. Eine davon ist das Replizieren von Daten auf die Nachbarn mit dem Ziel,
hotspots im CAN zu vermeiden. Diese Technologie kann zu einer Replikation häufig
verwendeter Daten ausgebaut werden.
Daten, die von einem Knoten im CAN angefragt werden, werden je nach RoutingPfad der Anfrage im entsprechenden Nachbarknoten des Datenverwalters repliziert.
Dies passiert natürlich unter Benutzung von Verdrängungsmechanismen auf Basis der
Häufigkeit von Anfragen, um den Speicherplatz der Nachbarknoten nicht zu überlasten.
Außerdem muss gewährleistet werden, dass bei Veränderung dieser Daten auch die
Replikatseigner informiert werden.
Neu bei diesem Verfahren ist, dass beim Bemerken eines Knotenausfalls durch den
Nachbarknoten sämtliche im Cache befindlichen Datensätze gerettet und an den neuen
Zonenverwalter übermittelt werden können.
Dieses Replikationsverhalten sichert die Replikation häufig verwendeter Datensätze
und spart die Kosten zur Replikation von Datensätzen auf die selten oder nie zugegriffen wird. Das ist immer dann sinnvoll, wenn in einem verteilten Speicher public data
verwaltet wird, also Daten die ohnehin bekannt sind und deren Verlust keine Probleme
mit sich bringt.
Maskierte Anfragen Da DHT-basierende Algorithmen auf Hash-Funktionen basieren, stellen maskierte Anfragen ein Problem dar. Es muss immer der gesamte Datenraum durchsucht werden.
45
Algorithmenentwicklung
Konzept
Dieses Problem kann mit speziellen Hash-Funktionen gelöst werden, die zu Gunsten ihrer Nachvollziehbarkeit Einschränkungen in der Gleichverteilung der Datensätze
über ihren Wertebereich hinnehmen, was auf Grund einiger der vorangehenden Optimierungen nicht mehr problematisch ist.
Nachvollziehbarkeit bedeutet in diesem Zusammenhang, dass die Anwendung der
0
Hash-Funktion auf die Maske M selbst wiederum eine Maske M erzeugt, mit deren
Hilfe im CAN gezielt nach Datensätzen gesucht werden kann, die auf die Maske M
passen. Im Idealfall wird M dabei in einen Flächenteil des Wertebereichs überführt,
dessen Verwalter direkt angesprochen werden können.
Um trotzdem eine annähernde Gleichverteilung der Schlüssel über den Wertebereich
zu gewährleisten, ist eine genaue Kenntnis der zu erwartenden Beschaffenheit und
Verteilung der Schlüssel notwendig. Die Hash-Funktion wird somit vom Einsatzszenario
des verteilten Speichers abhängig.
46
Kapitel 5
Implementation
Dieses Kapitel beschreibt die Implementation des Simulators und des darauf aufsetzenden assoziativen Speicherkonzeptes. Den Anfang bildet die Beschreibung des Schichtenmodells des entwickelten Simulators sowie der darin befindlichen Schnittstellen. Anschließend wird die Implementation des assoziativen Speicherkonzeptes beschrieben.
5.1
Realisierung des Simulators
Der zu realisierende Simulator lässt sich sehr effektiv in drei unabhängige Schichten
untergliedern. Die Simulation der Netzwerkkomponenten als äußere Schicht. Daran
schließt die Nachbildung der Eigenschaften eines Speicherknotens an. Die innere Schicht
stellt die Implementation des assoziativen Speicherkonzeptes dar. Eine schematische
Darstellung dieser Schichtenarchitektur befindet sich in Abbildung 5.1.
In den folgenden zwei Abschnitten werden die äußeren beiden Schichten des Simulators mit ihren Schnittstellen beschrieben. Eine Beschreibung der Implementation der
inneren Schicht erfolgt gesondert im nächsten Kapitel.
5.1.1
Der Netzwerksimulator
Die äußere Schicht des Simulators besteht hauptsächlich aus dem Netzwerksimulator.
Er stellt die notwendigen Netzwerkkomponenten, Hub, Switch, Router und Knoten zur
Verfügung mit denen sich beliebige Netzwerktopologien realisieren lassen.
Eine besondere Rolle kommt dabei dem Knoten zu. Er stellt zwar eine eigenständige
Netzwerkkomponente in der Simulation dar, ist aber über die Netzwerkfunktionalität
47
Realisierung des Simulators
Implementation
User
Algorithmus
Speicherknoten
Output Generator
Reply Receiver Statistics Generator
Console
Caching,
Replication, Data Management, Failure Management
Local Memory Management System Watchdog
Overlay Routing
Hub
Switch
Router
Communication
Host
Network Setup
HDs
Cache
Timer Trigger
Send Receive
Secondary Storage Event Management Network Access
Setup
Logging Setup
Netzwerksimulator
Command
Transmitter
Command Queue
Scenario Setup
Scheduler
Abbildung 5.1: Schematische Abbildung des Netzwerksimulators
hinaus nur abstrakt realisiert. Die jeweilige Implementation entscheidet über die Funktionalität, die auf diesem Knoten realisiert wird.
Zur äußeren Schicht des Simulators gehören außerdem eine Benutzerimplementation, in Abbildung 5.1 als User bezeichnet, und eine Setupkomponente.
Aufgabe der Benutzerimplementation ist die Steuerung der laufenden Simulation
durch das Auslösen externer Ereignisse. Von hier werden über einen Scheduler zu festgelegten Zeitpunkten Kommandos an einen Knoten gegeben, die dieser je nach Implementation verstehen und ausführen kann.
Das Setup ist für den Aufbau der Simulation bis zum Start der selben verantwortlich. Hier wird die Netzwerktopologie initiiert, die aktiven Knoten mit Benutzern und
diese wiederum mit Tasklisten versehen, in denen sich die Anweisungen für den jeweiligen Scheduler befinden. Außerdem werden grundsätzliche Parameter der Simulation,
wie zum Beispiel für das Logging, im Setup initialisiert.
Basierend auf diesem Netzwerksimulator lassen sich alle denkbaren netzwerkbasierten Probleme nachbilden, indem der Knoten mit einer entsprechenden Implementation
48
Implementation des verteilten Speicherkonzeptes
Implementation
versehen wird. Eine besondere Implementation stellt hierbei ein Speicherknoten eines
verteilten Speichers dar.
5.1.2
Ein einzelner Speicherknoten
Die mittlere Schicht besteht aus einer speziellen Implementation des Knotens. Sie stellt
über den Netzwerkzugriff weitere Schnittstellen zur Verfügung. Dazu gehören Nachbildungen von Festspeichern sowie ein Event-Management.
Der Festspeicher stellt zwei verschiedene Speicherformen zur Verfügung, Festspeicher und Cache. Diese können mit unterschiedlichen Werten für Latenz und Bandbreite
versehen werden. Ob und wie diese genutzt werden obliegt der Implementation, also
dem Algorithmus.
Das Event-Management bietet dem Algorithmus die Möglichkeit, unabhängig von
der Netzwerkschicht beim Ablauf von Timern bestimmte Funktionen auszulösen. Dies
ist zur Realisierung von Timeouts und regelmäßig wiederkehrenden Aufgaben sinnvoll.
Ein weiterer Bestandteil der mittleren Schicht verallgemeinert die Benutzerschnittstelle so, dass alle implementierten Algorithmen den gleichen Befehlssatz verarbeiten
und die Auswertungen der Simulation vom Algorithmus unabhängig stattfinden.
5.2
Implementation des verteilten Speicherkonzeptes
An die Implementation des verteilten Speicherkonzeptes werden verschiedene Anforderungen gestellt. Sie soll unabhängig vom darunter liegenden Simulator entwickelt werden. Dabei dürfen als Verbindung ausschließlich die von der Speicherknoten-Schicht
angebotenen Schnittstellen verwendet werden. Damit wäre es zum Beispiel möglich,
den Simulator gegen ein Network-Abstraction-Layer, also eine netzwerkfähige Implementation auszutauschen und das Speicherkonzept tatsächlich zu verwenden.
Sehr nah an der soeben gestellten Anforderung liegt die Forderung nach Austauschbarkeit. Das Speicherkonzept selbst soll ohne Probleme gegen die Implementation anderer Algorithmen ausgetauscht werden können, so dass auch diese auf dem Simulator
untersucht werden können.
Neben diesen Anforderungen ist es sinnvoll, die Implementation des Speicherkonzeptes übersichtlich zu gestalten, so dass spätere Veränderungen mit geringem Aufwand
möglich sind. Außerdem wäre es wünschenswert, dass Teile des Speicherkonzeptes durch
49
Implementation des verteilten Speicherkonzeptes
Implementation
veränderte Versionen austauschbar oder in anderen Algorithmen wiederverwendbar
sind.
5.2.1
Taskstruktur
Alle zuvor gestellten Anforderungen lassen sich durch die Realisierung des Speicherkonzeptes als eine Reihe von Tasks realisieren. Dazu ist eine Untergliederung des Algorithmus’ zur verteilten Datenspeicherung in einzelne Aufgaben notwendig, so dass diese
später als unabhängige Tasks implementiert und zu dem gewünschten Speicherkonzept
zusammengesetzt werden können. Tabelle 5.1 enthält eine solche Untergliederung.
Task
Beschreibung
Join
Ein neue Knoten tritt dem assoziativen verteilten Speicher
bei
Store
Ein Datensatz bestehend aus Schlüssel und Daten wird im
Speicher abgelegt
Query
Anhand eines gegebenen Schlüssels wird nach einem Datensatz im Speicher gesucht
Masked Query Anhand eines gegebenen Schlüssels und einer einfachen Bitmaske wird nach Datensätzen im Speicher gesucht
Leave
Ein Knoten tritt aus dem assoziativen verteilten Speicher
aus
Tabelle 5.1: Zerlegung eines verteilten Datenspeicherungsalgorithmus’ in einzelne
Tasks
Die einzelnen Tasks werden als Ableitungen einer abstrakten Basisklasse implementiert, um Austauschbarkeit und Transparenz zu gewährleisten. Da einige der Tasks, zum
Beispiel Join, in ihrer Realisierung noch immer sehr komplex sind, ist es sinnvoll die
weitere Zergliederung eines Tasks in mehrere Tasks zuzulassen.
Um das Konzept der Transparenz auf die simulierte Netzwerkkommunikation zu
übertragen, werden auch die über das Netzwerk transportierten Daten als Ableitung
einer abstrakten Basisklasse realisiert.
50
Messungen
5.2.2
Implementation
Graphische Schnittstelle
Der Ablauf einer Simulation diesen Umfanges ist sehr komplex. Jedes modellierte Objekt wird zum Beispiel als eigener Thread realisiert, der auf Ereignisse reagiert und
wiederum Ereignisse auslöst. Um die Simulation trotzdem nachvollziehbar zu machen
und das Finden von Fehlern zu erleichtern ist die Implementation einer grafischen
Schnittstelle sinnvoll.
Eine solche Schnittstelle wurde für den implementierten Algorithmus realisiert. Die
einzelnen Rechnerknoten und ihre Aktivität werden genauso dargestellt wie eine Übersicht über alle Zonen, in die der Wertebereich zergliedert ist. Dabei ist mit Hilfe verschiedener Farben eine Zuordnung zwischen Knoten und den von ihm verwalteten Zonen möglich. Eine Abbildung der realisierten grafischen Schnittstelle zeigt Abbildung
5.2.
Im oberen Teil der Grafik sieht man jeweils ein gefärbtes Rechteck pro Knoten.
Die grüne Umrandung bedeutet, dass der umrandete Knoten dem verteilten Speicher
erfolgreich beigetreten ist. Die Zonen, die er verwaltet sind unten in der Abbildung des
CAN-Wertebereichs mit der gleichen Farbe dargestellt.
In den Darstellungen der einzelnen Knoten erkennt man die relativen Füllstände
des Speichers des jeweiligen Knotens. In den einzelnen CAN-Zonen erkennt man die
absolute Anzahl der Datensätze pro Zone. Einziges begrenzendes Element ist die Speichergröße der Knoten. Die Anzahl der Datensätze pro Zone ist theoretisch unbegrenzt.
5.3
Messungen
Es werden verschiedene Simulationsläufe durchgeführt. Diesen liegen zwei unterschiedliche Netzwerktopologien zu Grunde, welche in den nächsten Abschnitten vorgestellt
werden. Anschließend werden die Simulationsläufe selbst vorgestellt. Eine Auswertung
der Ergebnisse erfolgt im nächsten Kapitel.
5.3.1
Topologie T1
Einen Überblick über die Netzwerktopologie T1 gibt Abbildung 5.3. Es handelt sich
hierbei um eine zwei- und drei dreistufige Netzwerke um einen Backbone wie sie zum
Beispiel auf einem Universitätscampus oder in einer mittleren Firma denkbar sind.
Den Backbone bildet der Switch S1. Daran angeschlossen sind die Router R1, R2,
R3 und R4. Die dazwischenliegenden Netzwerkverbindungen haben eine Latenz von
51
Messungen
Implementation
Abbildung 5.2: Grafische Repräsentation einer Simulation eines verteilten Speichers
aus 84 Rechnerknoten mit jeweils drei CAN-Zonen pro Knoten
52
Messungen
Implementation
K1 K2
K31 K32 K33 K34 K35
K3 K4 K5
S2
K6 K7 K8 K9 K10
R1
K45
K44
K43
K42
K41
H6
H8
H1
S5
R4
S1
R2
H7
S3
H2
H3
K11
K12
K13
K14
K15
R3
K40 K39 K38 K37 K36
H5
S4
K20 K19 K18 K17 K16
H4
K30 K29 K28 K27 K26
Rechenknoten
Switch
Router
Hub
K25 K24 K23 K22 K21
LWL − 100 Mb/s − 100 m
LWL − 100 Mb/s − 10 m
10BaseT − 10 Mb/s − 100 m
Abbildung 5.3: Schematische Darstellung der Netzwerktopologie T1
. Das entspricht unlnetS1,R∗ = 0, 505µs und eine Bandbreite von bnetS1,R∗ = 10.000 byte
ms
gefähr einem 100m langen Lichtwellenleiter (LWL) mit einer Bandbreite von 100Mb/s.
An den Router R1 sind über den Switch S2 fünf Knoten angeschlossen. Die anderen
Router führen über einen Switch auf mehrere Hubs und von dort auf fünf Knoten pro
Hub. Die Netzwerkverbindungen zwischen den Routern und den Switches bestehen
aus einem 10m langen LWL mit einer Bandbreite von ebenfalls 100Mb/s. Das ergibt
folgende Parameter:
lnetR∗,S[2−5] = 0, 0505µs
byte
bnetR∗,S[2−5] = 10.000
ms
(5.1)
(5.2)
53
Messungen
Implementation
Die restlichen Verbindungen bestehen aus 100m langem, einfach geschirmtem Kupferkabel 10BaseT mit einer Bandbreite von 10Mb/s, also folgenden Parametern:
lnetS[2−5],H∗ = 0, 570µs
(5.3)
lnetH∗,K∗ = 0, 570µs
byte
bnetR∗,S[2−5] = 1.000
ms
byte
bnetH∗,K∗ = 1.000
ms
(5.4)
(5.5)
(5.6)
Alle
eingesetzten
Switches
verwenden
den
Algorithmus
AswiS∗ = Store and Forward. Die Router haben eine Eigenlatenz von lrouR∗ = 0, 01ms
und alle Hubs kommen ohne Eigenlatenz aus.
5.3.2
Topologie T2
Topologie T2 ist in Abbildung 5.4 dargestellt. Sie ist in der Anzahl der Knoten und
den meisten Eigenschaften mit Topologie T1 identisch. Den wesentlichen Unterschied
stellt eine Verlagerung auf zwei Standorte dar. Es wären zum Beispiel zwei Firmen
oder Universitäten auf unterschiedlichen Kontinenten denkbar.
Den Backbone bilden hier zwei Switches S1 und S5, die sich örtlich weit voneinander
entfernt befinden. Die Verbindung wird als 10.000 km langer LWL mit einer Bandbreite
von 100 Mb/s simuliert. Das ergibt folgende Eigenschaften für diese Verbindung:
lnetS1,S5 = 50, 5ms
byte
bnetS1,S5 = 10.000
ms
5.3.3
(5.7)
(5.8)
Simulationen
Es werden zwei Simulationsreihen durchgeführt. Zuerst wird die Reaktion des Algorithmus’ auf verschiedene Optionen getestet. Anschließend wird die Performance des
verteilten Speicherkonzeptes in Abhängigkeit von der Anzahl der teilnehmenden Knoten ermittelt. Die beiden Simulationsreihen werden jeweils vergleichend auf beiden
Netzwerktopologien T 1 und T 2 durchgeführt.
Bei allen Messungen wird die Performance des verteilten Speicherkonzeptes im Wesentlichen durch drei Faktoren bestimmt. Diese sind in Tabelle 5.2 aufgelistet. Einen
indirekten Einfluss auf die Performance haben die Faktoren in Tabelle 5.3.
54
Messungen
Implementation
K26 K27 K28 K29 K30
K45
K44
K43
K42
K41
K40
K39
K38
K37
K36
K1 K2 K3 K4 K5
S6
S2
R4
R1
H6
S8
H1
R6
S5
S1
R2
H5
S3
K11
K12
K13
H2
R5
R3
S7
S4
K6
K7
K8
K9
K10
K14
K15
H3
H4
K31 K32 K33 K34 K35
K20 K19 K18 K17 K16
K25 K24 K23 K22 K21
Rechenknoten
Router
Switch
Hub
LWL − 100 Mb/s − 10.000 km
LWL − 100 Mb/s − 100 m
LWL − 100 Mb/s − 10 m
10BaseT − 10 Mb/s − 100 m
Abbildung 5.4: Schematische Darstellung der Netzwerktopologie T2
Alle Simulationen laufen wie folgt ab:
1. Alle teilnehmenden Knoten treten in pseudo-zufälliger Reihenfolge dem verteilten
assoziativen Speicher bei. Dabei werden die zeitlichen Abstände so gewählt, dass
es nicht zu Überschneidungen kommt, die die Messung beeinflussen.
2. In der gleichen Reihenfolge, wie die Knoten dem Speicher beigetreten sind, legen
sie jeweils 100 Datensätze mit pseudo-zufälligen Schlüsseln im verteilten Speicher
ab. Auch hier werden die zeitlichen Abstände zwischen den Befehlsausführungen
so gewählt, dass die Ergebnisse der Messungen nicht verfälscht werden.
55
Messungen
Faktor
tjoin
tstore
tquery
Implementation
Beschreibung
Zeit, die ein neuer Knoten benötigt, um sich vollständig in den verteilten Speicher zu integrieren
Zeit, die ein Knoten benötigt, um einen Datensatz im verteilten Speicher abzulegen
Zeit, die ein Knoten benötigt, um einen Datensatz im verteilten Speicher wiederzufinden
Tabelle 5.2: Faktoren, die die Performance des Algorithmus’ bestimmen.
Faktor
rstore
rquery
Beschreibung
Anzahl der Routingschritte beim Ablegen von Daten im verteilten
Speicher
Anzahl der Routingschritte bei der Suche nach Daten im verteilten
Speicher
Tabelle 5.3: Faktoren, die die Performance des Algorithmus’ indirekt bestimmen.
3. Nachdem alle Datensätze im simulierten System abgelegt sind, fragt jeder Knoten
in wiederum der gleichen Reihenfolge sämtliche soeben abgelegten Datensätze aus
dem Speicher ab.
Dabei werden jeweils tjoin , tstore und tquery für jeden Knoten beziehungsweise Datensatz gemessen und ausgewertet. Außerdem werden die Anzahl der Routing-Schritte für
das Ablegen rstore und Wiederfinden rquery im verteilten Speicher sowie verschiedene
Informationen zu den Auslastungen der Netzwerkkomponenten aufgezeichnet.
Die spezifischen Unterschiede der einzelnen Simulationsreihen und der dabei durchzuführenden Messungen werden in den folgenden Abschnitten kurz detailliert.
Vergleich verschiedener Optionen
Die erste Simulationsreihe soll zeigen, welchen Einfluss die Verwaltung mehrerer Zonen
pro Knoten sowie die Verwendung einer L2N-Tabelle auf die Performance des verteilten assoziativen Speichers haben. Dazu wird zuerst auf beiden Netzwerktopologien ein
verteilter Speicher mit 45 Knoten ohne jegliche Optimierungen vermessen. Daraufhin
wird die Anzahl der verwalteten Zonen pro Knoten schrittweise erhöht, um festzustellen, ob ein Trend zu einer besseren oder schlechteren Performance feststellbar ist.
Anschließend werden die gleichen Messungen mit L2N-Tabellen durchgeführt.
56
Messungen
Implementation
Von Interesse sind hier insbesondere tstore und tquery sowie rstore und rquery , da diese durch die Optimierungen verbessert werden sollen. Während die Auswirkung der
Verwaltung mehrerer Zonen pro Knoten nicht ohne weiteres abzuschätzen ist, sollte
die Verwendung der L2N-Tabellen vor allem in der Netzwerktopologie T 2 enorme Verbesserungen in der Ausführungsgeschwindigkeit sowohl der Datenablage als auch der
Datenwiedergewinnung aus dem Speicher mit sich bringen.
Skalierungsfähigkeit des Speicherkonzeptes
Mit dieser Simulationsreihe soll untersucht werden, wie gut das Speicherkonzept skaliert, also ob seine Performance unabhängig von der Anzahl der teilnehmenden Knoten
ist. Dazu werden auf beiden Netzwerktopologien Messungen an einem verteilten Speicher mit schrittweise acht bis 45 teilnehmenden Knoten durchgeführt. Dabei werden die
beiden in der vorangegangenen Simulationsreihe vermessenen Optionen entsprechend
der besten Performance aktiviert oder deaktiviert.
Von besonderem Interesse ist hier vor allem tjoin , da insbesondere die Zeit für das
Beitreten in den verteilten Speicher unabhängig von der Anzahl der teilnehmenden
Knoten sein muss damit der Algorithmus auch auf großen Knotenzahlen skaliert. Weiterhin sollten tstore und tquery nicht proportional zur Knotenanzahl, sondern möglichst
√
mit einer Komplexität von O( K) oder noch besser O(log K) mit K als Anzahl der
Knoten wachsen.
57
Kapitel 6
Ergebnisse und Diskussion
In den folgenden Abschnitten werden die zuvor beschriebenen Simulationsreihen ausgewertet. Begonnen wird mit dem Vergleich der Optionen des Algorithmus’, da sich
daraus Auswirkungen auf die Konfiguration der zweiten Simulationsreihe ergeben. Anschließend folgt die Diskussion der Feststellung der Skalierungsfähigkeit des Speicherkonzeptes. Abschließend werden die aus diesem Prozess gewonnen Erkenntnisse diskutiert.
6.1
Vergleich verschiedener Optionen
Die Simulationsreihe macht Aussagen über das Performanceverhalten des verteilten
Speicherkonzeptes unter dem Einfluss von zwei Optimierungen. Wie sich diese Optimierungen auswirken und welche Einstellungen sinnvoll sind, wird anschließend diskutiert.
In den Text dieses Abschnittes sind der Übersichtlichkeit halber nur einige ausgewählte Diagramme eingegliedert. Die fehlenden Ergebnisdiagramme aller Simulationen dieser Simulationsreihe befinden sich im Anhang A.
6.1.1
Die Benutzung von L2N-Tabellen
Diese, im Abschnitt 4.2 (durch Broadcasts ermittelte Nachbartabellen) vorgestellte
Optimierung verbessert die Geschwindigkeit des Zugriffs auf den verteilten Speicher
auf beiden Netzwerktopologien. Tabelle 6.1 gibt Auskunft über die genauen Werte.
58
Vergleich verschiedener Optionen
Parameter Topologie
rquery
rstore
tquery
tstore
tjoin
Ergebnisse und Diskussion
ohne Opt. optimiert relative Verbesserung
T1
T2
T1
T2
T1
T2
T1
T2
T1
T2
3,19
3,19
3,19
3,19
12,8ms
97,2ms
11,7ms
146ms
6,82ms
268ms
1,82
2,08
1,82
2,08
11,9ms
65,8ms
10,8ms
115ms
6,89ms
268ms
47%
35%
47%
35%
7,0%
32%
7,7%
21%
0,0%
0,0%
Tabelle 6.1: Ermittelte Werte für die zu untersuchenden Parameter mit und ohne L2NTabellen bei einer Zone pro Knoten.
Auswirkung auf das Routing
Die durchschnittliche Anzahl von Routingschritten beim Ablegen von Datensätzen im
Speicher rstore sowie beim Wiederfinden dieser Datensätze rquery sinkt in beiden Netzwerktopologien um mehr als 30%.
Der Unterschied lässt sich mit der unterschiedlichen Anzahl an Subnetzen erklären.
In Topologie T 1 teilen vier Router die Knoten in vier Subnetze während in T 2 sechs
Router sechs Subnetze bilden. Die Auswirkung dieser Optimierung auf die Anzahl der
Routingschritte ist somit von der Topologie abhängig. In verteilten Speichern mit vielen
Knoten in unterschiedlichen Subnetzen wird die Auswirkung weniger stark sein.
Auswirkung auf das Speichern und Suchen von Datensätzen
Die Änderung in den Ausführungszeiten ist noch stärker von der Netzwerktopologie
abhängig. Eine Verbesserung wird aber auch hier deutlich. 7-8% Verbesserung in T 1
erscheinen sehr gering, relativieren sich aber bei Beachtung der durch den Zugriff auf
den Sekundärspeicher induzierten Latenz von 9ms in beiden Simulationen.
Bei Beachtung dieser Latenz, die bei jedem Zugriff auf Daten im verteilten Speicher
unabhängig von der Netzwerktopologie auftritt, ergeben sich relative Verbesserungswerte von 24% für tquery und 33% für tstore in T 1. In T 2 wirken sich diese 9ms kaum
aus, da dort die netzwerkinduzierte Latenz weit größeren Einfluss hat.
59
Vergleich verschiedener Optionen
Ergebnisse und Diskussion
Auswirkung auf die Beitrittszeit
Durch die Nutzung der L2N-Tabellen verändert sich die durchschnittliche Zeit, die
vergeht, bis ein Knoten im verteilten Speicher arbeiten kann, nur unwesentlich. Ursache
hierfür ist, dass der zur Initialisierung der zusätzlichen Nachbartabellen notwendige
Broadcast erst gesendet wird nachdem der Knoten dem CAN beigetreten ist.
Zur Überprüfung, ob sich die, durch die Optimierung verursachten Broadcasts in
einer höheren Belastung des Netzwerkes, auf dem der verteilten Speicher realisiert ist,
widerspiegeln, listet Tabelle 6.2 die durchschnittlichen Belastungen einer ausgewählten
zentralen Netzwerkkomponente pro Topologie auf.
Optimierung durchschnittliche Auslastung durchschnittliche Auslastung
während des CAN-Aufbaus
während der Simulation
deaktiviert
aktiviert
Veränderung
2.01% (0.077%)
5.43% (0.093%)
+170% (+121%)
2.61% (0.060%)
1.65% (0.050%)
-37% (-27%)
Tabelle 6.2: Auslastung des Switches S3 in T 1 (S8 in T 2) mit und ohne L2N-Tabellen
Anhand der Werte wird deutlich, dass bei der Belastung der Netzwerkkomponenten die Verbesserung der Routingschritte und die damit einhergehende Entlastung des
Netzwerkes bereits bei nur 100 Datensätzen pro Knoten deutlich überwiegt.
Diskussion
Die durch die Simulation getestete Optimierung des Algorithmus’ verbessert die Performance der verteilten Speichers in den getesteten Topologien besonders bei der Speicherung und dem Auffinden von Daten, da er das Routing im CAN signifikant beschleunigt.
Die L2N-Tabellen werden demzufolge bei der zweiten Simulationsreihe aktiviert.
Um Aussagen über das Verhalten der Optimierung im Allgemeinen treffen zu
können, ist eine Simulation auf zwei Netzwerktopologien keineswegs ausreichend. Auf
Grund der Wirkungsweise ist allerdings davon auszugehen, dass auch auf anderen,
größeren Netzwerktopologien mit ähnlicher Struktur eine vergleichbare Performanceverbesserung zu erwarten ist.
Nachteile der Optimierung sind eine minimale zusätzliche Belastung der Subnetze,
in denen sich die beteiligten Knoten des verteilten Speichers befinden, nachdem ein
neuer Knoten in den Speicher aufgenommen worden ist, sowie eine geringfügige Stei60
Vergleich verschiedener Optionen
Ergebnisse und Diskussion
gerung der Komplexität des Routingalgorithmus’ in jedem einzelnen Teilnehmer durch
die Verwaltung der L2N-Tabelle.
6.1.2
Die Verwaltung mehrerer Zonen pro Knoten
Wie aus den im Anhang A abgebildeten Diagrammen hervorgeht, führt die in 4.2
erklärte Optimierung, mehrere Zonen pro Knoten abzulegen, nicht zu einer wahrnehmbaren Verbesserung der Performance des verteilten Speichers.
Auswirkung auf das Routing
Mit der Erhöhung der Anzahl der pro Knoten verwalteten Zonen verändert sich die
durchschnittliche Anzahl der Routingschritte in beiden Netzwerktopologien nicht wesentlich.
Auswirkung auf das Speichern und Suchen von Datensätzen
Auch auf die durchschnittlichen Zeiten zum Speichern und Wiederfinden von Datensätzen hat eine Erhöhung der Anzahl der von einem Knoten verwalteten Zonen
keinen sichtbaren Einfluss.
Auswirkung auf die Beitrittszeit
Durch den deutlichen Mehraufwand an Kommunikation beim Einbringen eines neuen
Knotens in den verteilten assoziativen Speicher steigt die durchschnittliche Zeit für den
Beitritt eines Knotens mit der Anzahl der von ihm verwalteten Zonen proportional an.
Ein linearer Zusammenhang ist sowohl in der Netzwerktopologie T 1 (Abbildung 6.1)
als auch in T 2 (Abbildung A.5) deutlich erkennbar.
Diskussion
Der Zugriff auf mehrere gut verteilte Zonen als Ausgangspunkte überwiegt in den
beiden durchgeführten Simulationen nicht die Verlängerung des maximal möglichen
Routingpfades durch die einhergehende Vergrößerung des CAN und rechtfertigt damit
nicht den Mehraufwand beim Einbringen neuer Knoten in den verteilten Speicher. Für
die nachfolgenden Simulationen wird demzufolge mit einer Zone pro Knoten gearbeitet.
Um eine allgemeine Aussage über die Wirksamkeit der Optimierung zu machen, sind
die beiden simulierten Netzwerktopologien nicht ausreichend. Vor allem eine Erhöhung
61
Skalierungsfähigkeit des Algorithmus’
Ergebnisse und Diskussion
durchschnittliche tjoin [ms]
30
25
20
15
10
5
0
f (x) = ax + b mit a = 4.13 und b = 0.959
g(x) = ax + b mit a = 3.83 und b = 1.23
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung 6.1: Durchschnittliche Zeit für die Teilnahme eines Knotens am verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 1
der Anzahl simulierter Knoten ist für eine genauere Untersuchung dieser Optimierung
sinnvoll.
6.2
Skalierungsfähigkeit des Algorithmus’
Den Ergebnissen der zweiten Simulationsreihe lassen sich Aussagen zur Skalierungsfähigkeit des Algorithmus’, also dem Verhalten in Abhängigkeit von der Anzahl
der beteiligten Knoten, entnehmen.
Die nicht in diesem Abschnitt in Form von Diagrammen dargestellten Messdaten
der durchgeführten Simulationen finden sich wiederum im Anhang B.
6.2.1
Hinzufügen eines weiteren Knotens
Eine für die Skalierungsqualität wichtige Eigenschaft ist die Zeit tjoin . Sie muss weitestgehend unabhängig von der Anzahl der Knoten sein, die sich bereits im verteilten
Speicher befinden.
62
Skalierungsfähigkeit des Algorithmus’
Ergebnisse und Diskussion
Die Simulation mit dem implementierten Algorithmus auf der Netzwerktopologie
T 1 zeigt eine solche Unabhängigkeit. Sämtliche Messwerte gruppieren sich um eine
beinahe waagerechte Regressionsgerade. Auf Grund der geringen Anzahl an tatsächlich
fremden Nachbarn in einem zweidimensionalen CAN können die Zeiten für die ersten
vier Knoten tjoinK1 , tjoinK2 , tjoinK3 und tjoinK4 als Ausreißer betrachtet werden und sind
in der Regression in Abbildung 6.2 nicht beachtet.
10
tjoin [ms]
8
6
4
2
f (x) = ax + b mit a = 0.00723 und b = 5.03
0
0
5
10
f (x)
15
20
25
30
Anzahl der Rechnerknoten
35
40
45
tjoin
Abbildung 6.2: Zeit für die Teilnahme eines Knotens am verteilten Speicher in
Abhängigkeit von der Anzahl der bereits am Speicher teilnehmenden
Knoten auf Topologie T 1
Auch auf T 2 liegen die Werte für tjoin in einem festen Bereich ungefähr zwischen
100ms und 400ms. Allerdings ist durch die Verteilung von nur 45 Messwerten auf diesen
großen Bereich die Regressionsgerade sehr unzuverlässig und nicht wie in Abbildung
B.4 angedeutet mit einem Sinken von tjoin zu rechnen.
6.2.2
Durchschnittliche Routingkomplexität
Die durchschnittliche Routingkomplexität des verteilten Speicherkonzeptes gibt Auskunft darüber, wie sich rstore und rquery in Abhängigkeit von der Anzahl der im verteilten Speicher zusammenarbeitenden Knoten verändert.
63
Skalierungsfähigkeit des Algorithmus’
Ergebnisse und Diskussion
Die maximale Routingkomplexität errechnet sich aus der maximalen Pfad-Länge
und beträgt für CAN, wie in 3.2.3 angegeben, O(dN 1/d ). Die durchschnittliche Routingkomplexität liegt aufgrund der Gleichverteilung der Knoten über das CAN und der
eingebrachten Optimierungen deutlich geringer. Um sie abschätzen zu können, sind in
den Diagrammen 6.3 und B.3 für T 1 sowie B.5 und B.7 für T 2 verschiedene Regressionsfunktionen eingezeichnet.
1.9
durchschnittliche rstore
1.8
1.7
1.6
1.5
1.4
1.3
√
g(x) = a x + b mit a = 0.139 und b = 0.961
h(x) = a log(x) + b mit a = 0.33 und b = 0.611
1.2
1.1
5
10
g(x)
15
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
rstore
Abbildung 6.3: Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von der Anzahl der am
Speicher teilnehmenden Knoten auf Topologie T 1
Dabei scheint in beiden Topologien der Verlauf von rstore und rquery noch konvexer
zu sein als die Regressionsfunktion a log(x) + b. Das würde eine bessere Routingkomplexität als O(log(x)) nahe legen. Dies sollte aber zuvor mit einer größeren Anzahl an
Messwerten geprüft werden.
6.2.3
Zeitverhalten beim Speichern und Suchen
Von Interesse für den Anwender ist vor allem das Zeitverhalten des Algorithmus’ und
damit die Abhängigkeit von tstore und tquery von der Anzahl der Knoten im verteilten
Speicher. Hier liefern die Diagramme B.1 und B.2 für T 1 sowie 6.4 und B.6 für T 2
Informationen.
64
Simulationsdauer
Ergebnisse und Diskussion
Bei den Messwerten auf T 1 zeigt sich wiederum eine starke Ähnlichkeit zwischen
tstore und tquery zu rstore und rquery . Ursache hierfür ist, dass alle Routingpfade ähnliche
Kosten verursachen, also der zeitliche Unterschied zwischen zwei möglichen Pfaden im
Routing sehr gering ist.
Auf T 2 kann der Unterschied zwischen zwei beliebigen Routingpfaden erheblich
sein. Darin liegt auch die Ursache, dass die Aussagekraft der Diagramme 6.4 und B.6
minimal ist. Hier lassen sich keine Aussagen über die Komplexität gewinnen.
durchschnittliche tstore [ms]
120
118
116
114
112
110
108
√
g(x) = a x + b mit a = 1.88 und b = 106
h(x) = a log(x) + b mit a = 4.79 und b = 99.9
106
104
5
10
g(x)
15
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
tstore
Abbildung 6.4: Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 2
Um zu genaueren Erkenntnissen zu gelangen, ist wiederum eine größere Anzahl von
Messwerten notwendig.
6.3
Simulationsdauer
Die Dauer einer Simulation von Topologie T 2 mit 45 teilnehmenden Knoten, einer Zone
pro Knoten und aktivierten L2N-Tabellen stellt Tabelle 6.3 dar.
Die Testplattform basiert auf einem, mit 2.8 GHz getakteten Intel Pentium IV Prozessor mit aktiviertem Hyperthreading. Das Betriebssystem ist ein Gentoo Base System
65
Erkenntnisse aus den Simulationen
Ergebnisse und Diskussion
Grafische
Erfassung von
Simulationszeit Simulationszeit
Benutzeroberfläche Auslastungsdaten
Gentoo-Linux
Windows XP
aktiviert
deaktiviert
aktiviert
deaktiviert
aktiviert
aktiviert
deaktiviert
deaktiviert
155s
118s
112s
79s
119s
88s
90s
62s
Tabelle 6.3: Die Zeit für die gleiche Simulation in Abhängigkeit von verschiedenen Einstellungen und Betriebssystemen
Version 1.4.16.[22] auf einem 2.6.8er Linux Kern. Verwendet wurde die glibc Version
2.3.3.20040420[21] mit linuxthreads-patch, der die Threads auf Prozesse abbildet.
Als Alternative wurde ein Windows XP Home Edition der Firma Microsoft verwendet. In beiden Fällen kam als Java Virtual Machine (JVM) die Java HotSpot Client VM
(build 1.4.2 05-b04, mixed mode)[40] von Sun Microsystems zum Einsatz. Der JVM
wurde die Benutzung von 768MB Arbeitsspeicher als Heap gestattet.
Die Simulationszeit hängt stark davon ab, wie viele Informationen während der
Simulation aufgenommen werden und ob die grafische Benutzeroberfläche aktiviert ist.
Insbesondere die Erfassung der Auslastungsdaten der einzelnen Netzwerkkomponenten
hat einen großen Einfluss.
Eine wichtige Systemeigenschaft, die die Simulationszeit beeinflusst, ist die Umsetzung von Threads im verwendeten Betriebssystem. Die Realisierung als Prozesse ist
nicht die optimale Lösung. Auf einem Betriebssystem mit Unterstützung für native
Threads wie zum Beispiel Microsoft Windows XP sinkt die Simulationszeit deutlich.
6.4
Erkenntnisse aus den Simulationen
In den zuvor durchgeführten Simulationen hat sich gezeigt, dass zur Überprüfung des
Verhaltens verteilter Algorithmen und deren Optimierung Simulationen mit großen
Knotenzahlen notwendig sind, um eine große Anzahl an Messwerten zu generieren.
Insbesondere bei stark latenzbehafteten Netzwerktopologien sind aufgrund der weiten Streuung der Messergebnisse viele Messwerte notwendig, um Trends zu erkennen
oder Komplexitäten abzuschätzen.
66
Erkenntnisse aus den Simulationen
Ergebnisse und Diskussion
Außerdem hat sich gezeigt, dass bedingt durch die detaillierte Modellierung der
Netzwerktopologien, Simulationen mit großen Knotenzahlen enorm viel Rechenzeit und
Speicherplatz in Anspruch nehmen.
67
Kapitel 7
Zusammenfassung
Im Verlauf dieser Arbeit wurden die einem verteilten System zugrundeliegenden Strukturen untersucht, modelliert und ein Simulator entwickelt, der das Verhalten verteilter
Systeme auf Basis dieses Modells sehr genau nachbilden kann.
Weiterhin wurde ein verteiltes assoziatives Speicherkonzept, das auf dem DHTbasierenden CAN aufbaut und dieses um eigene Erweiterungen ergänzt, entwickelt
und auf diesem Simulator implementiert. Es ermöglicht den Aufbau eines verteilten
assoziativen Speichers, das Ablegen von Datensätzen und deren Verteilung auf die
einzelnen Knoten sowie das Suchen nach einzelnen Datensätzen. Außerdem ist die
Suche nach Datensätzen mit einer bitweisen Suchmaske möglich.
Für den Simulator wurde eine grafische Benutzerschnittstelle implementiert, die die
Verteilung der Daten auf die einzelnen Knoten und die Funktionsweise des implementierten Speicherkonzeptes veranschaulicht.
Durch verschiedene Simulationen wurde gezeigt, dass die Performance von CAN
durch gezielte Optimierungen enorm verbessert werden kann. Insbesondere die Erweiterung der Nachbartabellen im CAN-Routing um durch Broadcasts ermittelte Nachbarknoten kann die Gesamtperformance des Algorithmus deutlich verbessern. Die Verwaltung mehrere Zonen pro Knoten hingegen wirkt sich stark negativ auf die Beitrittszeit
der Knoten in den verteilten Speicher aus, während keine wahrnehmbare Verbesserung
der Routing-Zeiten auftritt.
Außerdem wurde gezeigt, dass die optimierte Version des CAN sehr gut skaliert.
Das Hinzufügen neuer Knoten in den assoziativen verteilten Speicher ist weitgehend
unabhängig von der Anzahl der bereits teilnehmenden Knoten. Die durchschnittliche
Routing-Komplexität des optimierten Algorithmus’ liegt dabei deutlich unter der für
ein nicht optimiertes CAN angegebenen maximalen Komplexität von O(n1/d ).
68
Zusammenfassung
Eine wichtige Erkenntnis aus den durchgeführten Simulationen ist, dass die detaillierte Simulation aller Eigenschaften der einem verteilten Speicher zugrundeliegenden
Netzwerktopologie enorm aufwändig ist und dadurch die Anzahl der simulierbaren
Knoten begrenzt.
69
Kapitel 8
Ausblick
Diese Arbeit stellt mit dem entwickelten Simulator ein Werkzeug zur exakten Nachbildung verteilter Systeme und deren Verhalten auf kleinen Netzwerktopologien mit bis
zu einigen hundert Knoten zur Verfügung. Simulatoren für die Nachbildung von verteilten Systemen mit einer großen Knotenzahl bis hin zu mehreren Millionen Knoten sind
verfügbar, aber nehmen aufgrund begrenzter Ressourcen betreffend Speicherverbrauch
und Rechenzeit keine Rücksicht auf die der Simulation zugrundeliegende Netzwerktopologie.
Wünschenswert wäre eine Kombination beider Prinzipien, also die Nachbildung
großer verteilter Systeme unter Beachtung der darunter liegenden Netzwerktopologie
durch die Einführung von Abstraktionsebenen. Da bei der Simulation vieler Knoten die
Nachbildung der Topologie in allen Einzelheiten zu aufwändig ist, ist die Entwicklung
weniger komplexer aber trotzdem möglichst exakter Modelle für das Verhalten von
verteilten Systemen notwendig. Hierfür kann der in dieser Arbeit entstandene Simulator
eine Grundlage bilden.
Der im Verlauf der Arbeit entwickelte Algorithmus kann weiter untersucht und mit
den aus den vorgenommenen und weiteren Untersuchungen gewonnenen Erkenntnissen
für verteilte Systeme implementiert werden und kann anschließend die Grundlage für
weitere Entwicklungen bilden.
Denkbar wäre zum Beispiel die Nutzung als Ressource für Grid-Systeme. Eine
Möglichkeit wäre die Nutzung als verteilter, dezentraler Namensdienst aber auch die
Implementation von Dateisystemen oder anderen Datenquellen ist auf Basis des entwickelten verteilten assoziativen Speicherkonzeptes möglich.
70
Abkürzungsverzeichnis
P2P Peer-to-Peer
HTTP Hypertext Transfer Protocol
I-WAY Information Wide Area Year
FAFNER Factoring via Network-Enabled Recursion
RSA Rivest, Shamir, Adelman
GRAM Globus Resource Allocation Manager
GridFTP Grid File Transfer Protocol
FTP File Transfer Protocol
MDS Monitoring and Discovery System
GSI Grid Security Infrastructure
GASS Global Access to Secondary Storage
GEM Globus Executable Management
GARA Globus Advanced Reservation and Allocation
OGSA Open Grid Service Architecture
WSDL Web Service Definition Language
GSH Grid Service Handle
DHT Distributed Hash Table
71
Ausblick
RPLG Random Power-Law Graphs
TTL Time to Live
RAM Random Access Memory
CAN Content-Addressable Network
LWL Lichtwellenleiter
L2N Layer 2 Nodes
JVM Java Virtual Machine
72
Literaturverzeichnis
[1] Aberer, K. und M. Hauswirth: An Overview on Peer-to-Peer Information
Systems. In: Litwin, W. und G. Lévy (Hrsg.): WDAS , Bd. 14 d. Reihe Proceedings in Informatics. Carleton Scientific, 2002.
[2] Banerjee, S.: myns Simulator .
myns/, Nov. 2004.
http://www.cs.umd.edu/˜suman/research/
[3] Banerjee, S., B. Bhattacharjee und C. Kommareddy: Scalable Application
Layer Multicast. In: ACM SIGCOMM ’02 , S. 205–220, August 2002.
[4] Banks, J., I. John S. Carson und B. L. Nelson: Discrete-Event System
Simulation. Prentice Hall, 2. Aufl., 1996.
[5] Bratley, P., B. L. Fox und L. E. Schrage: A Guide to Simulation. SpringerVerlag, 2. Aufl., 1987.
[6] Buyya, R. und A. Sulistio: GridSim. http://www.gridbus.org/gridsim/, Nov.
2004.
[7] www.CactusCode.org. http://www.cactuscode.org/, Nov. 2004.
[8] Casanova, H. und A. Legrand: SimGrid . http://gcl.ucsd.edu/simgrid/, Nov.
2004.
[9] Chien, A. A.: MicroGrid - Emulation Tools for Computational Grid Research (a part of the GrADS project). http://www-csag.ucsd.edu/projects/grid/
microgrid.html, Nov. 2004.
[10] Chu, Y. hua, S. G. Rao und H. Zhang: A Case for End System Multicast. In:
Measurement and Modeling of Computer Systems, S. 1–12, 2000.
73
LITERATURVERZEICHNIS
LITERATURVERZEICHNIS
[11] The DataGrid Project. http://eu-datagrid.web.cern.ch/eu-datagrid/, Nov. 2004.
[12] Distributed.Net. http://www.distributed.net/, Nov. 2004.
[13] FAFNER. http://www.npac.syr.edu/factoring.html, Nov. 2004.
[14] Forschungszentrum Jülich, Z.: UNICORE .
zam/RD/coop/unicore/unicore.html, Nov. 2004.
http://www.kfa-juelich.de/
[15] Foster, I.: The Grid: A New Infrastructure for the 21st Century Science. Physics
Today, 2002.
[16] Foster, I.: What is the Grid: A Three Point Checklist. Grid Today, July 2002.
[17] Foster, I., J. Geisler, W. Nickless, W. Smith und S. Tuecke: Software Infrastructure for the I-WAY High-Performance Distributed Computing Experiment.
S. 562–571. IEEE Computer Society Press, 1996.
[18] Foster, I. und C. Kesselman: Globus: A Metacomputing Infrastructure Toolkit.
The International Journal of Supercomputer Applications and High Performance
Computing, 11(2):115–128, Summer 1997.
[19] Foster, I., C. Kesselman, J. Nick und S. Tuecke: The Physiology of the
Grid: An Open Grid Services Architecture for Distributed Systems Integration.
http://www.globus.org/research/papers/ogsa.pdf, 2002.
[20] Foster, I., C. Kesselman und S. Tuecke: The Anatomy of the Grid: Enabling
Scalable Virtual Organizations. Lecture Notes in Computer Science, 2150, 2001.
[21] Free Software Foundation: GNU C Library. http://www.gnu.org/software/
libc/libc.html, Nov. 2004.
[22] Gentoo Foundation: gentoo linux . http://www.gentoo.org/, Nov. 2004.
[23] Gil, T. M., F. Kaashoek, J. Li, R. Morris und J. Stribling: p2psim - a
simulator for peer-to-peer protocols. http://www.pdos.lcs.mit.edu/p2psim/, Nov.
2004.
[24] The Gnutella Protocol Specification v0.4 . http://www.stanford.edu/class/cs244b/
gnutella protocol 0.4.pdf, Nov. 2004.
74
LITERATURVERZEICHNIS
LITERATURVERZEICHNIS
[25] Grimshaw, A. S., W. A. Wulf, J. C. French, A. C. Weaver und P. F.
Reynolds Jr.: Legion: The Next Logical Step Toward a Nationwide Virtual Computer . Techn. Ber. CS-94-21, University of Virginia, August 1994.
[26] Howell, F. und R. McNab: simjava.
hase/simjava/, Nov. 2004.
http://www.dcs.ed.ac.uk/home/
[27] Jelasity, M., A. Montresor und G. P. Jesi: Peersim Peer-to-Peer Simulator .
http://peersim.sourceforge.net/, Nov. 2004.
[28] Kohonen, T.: Content-Addressable Memories. Springer, 1987.
[29] Malkhi, D., M. Naor und D. Ratajczak: Viceroy: A scalable and dynamic
emulation of the butterfly, 2002.
[30] Naor, M. und U. Wieder: Novel Architectures for P2P Applications: the
Continuous-Discrete Approach. http://www.wisdom.weizmann.ac.il/˜uwieder,
2002.
[31] Napster . http://www.napster.com/, Nov. 2004.
[32] Overeinder, B. J.: Distributed Event-driven Simulation - Scheduling Strategies
and Resource Management. Dissertation, ASCI, 2000.
[33] Overnet - the german edonkey resource. http://www.overnet2000.de/, Nov. 2004.
[34] Ratnasamy, S., P. Francis, M. Handley, R. Karp und S. Schenker: A
scalable content-addressable network . In: Proceedings of the 2001 conference on
applications, technologies, architectures, and protocols for computer communications, S. 161–172. ACM Press, 2001.
[35] Richter, H.: Verbindungsnetzwerke für parallele und verteilte Systeme. Spektrum akademischer Verlag, 1997.
[36] Roure, D. D., M. A. Baker, N. R. Jennings und N. R. Shadbolt: Grid
Computing: Making The Global Infrastructure a Reality by Fran Berman, Anthony
J.G. Hey and Geoffrey Fox , Kap. The Evolution of the Grid, S. 65–100. John Wiley
& Sons, April 2003.
75
LITERATURVERZEICHNIS
LITERATURVERZEICHNIS
[37] Rowstron, A. und P. Druschel: Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to-Peer Systems. Lecture Notes in Computer
Science, 2218:329–350, 2001.
[38] SETI@home. http://setiathome.ssl.berkeley.edu/, Nov. 2004.
[39] Stoica, I., R. Morris, D. Karger, M. F. Kaashoek und H. Balakrishnan: Chord: A scalable peer-to-peer lookup service for internet applications. In:
Proceedings of the 2001 conference on applications, technologies, architectures, and
protocols for computer communications, S. 149–160. ACM Press, 2001.
[40] Sun Microsystems: Java Technology. http://java.sun.com/, Nov. 2004.
[41] Tavangarian, D.: Flagorientierte Assoziativspeicher und -prozessoren. Springer,
1990.
[42] Tavangarian, D., U. Lucke und T. Lucke: Hypercomputing: Ein verteiltes
System zur Vearbeitung von DV-Problemen in Weitverkehrsnetzen. Techn. Ber.,
Universität Rostock, 2001.
[43] the globus alliance: Globus Toolkit. http://www-unix.globus.org/toolkit/,
Nov. 2004.
[44] Zeigler, B. P., H. Praehofer und T. G. Kim: Theory of Modeling and Simulation - Integrating Discrete Event and Continuous Complex Dynamic Systems.
Academic press, 2. Aufl., 2000.
[45] Zhao, B. Y., J. D. Kubiatowicz und A. D. Joseph: Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and Routing. Techn. Ber. UCB/CSD01-1141, UC Berkeley, apr 2001.
76
Abbildungsverzeichnis
2.1
2.4
2.5
2.6
Darstellung der Systemschichten, auf denen das P2P-Konzept angewandt werden kann [1] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gegenüberstellung der Zusammenarbeit zwischen informationsverarbeitenden Systemen beim Client-Server-computing und beim P2P-computing
Ausschnitt aus der Schichtenarchitektur des Globus-Toolkit in den Versionen 2.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Das von Foster in [15] vorgestellte “hourglass model” . . . . . . . . . .
Aufbau eines einfachen wortorientierten inhaltsadressierten Speichers .
Methodik des Studiums eines Systems [32] . . . . . . . . . . . . . . . .
11
14
17
19
3.1
3.2
3.3
3.4
3.5
CAN-Gitter mit Datensatz . . . . . . . . . . . . . . . . . . . . . . . . .
Zonen eines Knotens in einem CAN mit drei Realitäten. . . . . . . . .
Caching durch Replikation im Nachbarknoten . . . . . . . . . . . . . .
Chord-Wertebereich mit Knoten und Fingerknoten . . . . . . . . . . .
Wertebereichsaufteilung und Routing im Distance-Halving-Algorithmus
29
31
31
33
35
5.1
5.2
Schematische Abbildung des Netzwerksimulators . . . . . . . . . . . . .
Grafische Repräsentation einer Simulation eines verteilten Speichers aus
84 Rechnerknoten mit jeweils drei CAN-Zonen pro Knoten . . . . . . .
Schematische Darstellung der Netzwerktopologie T1 . . . . . . . . . . .
Schematische Darstellung der Netzwerktopologie T2 . . . . . . . . . . .
48
2.2
2.3
5.3
5.4
6.1
Durchschnittliche Zeit für die Teilnahme eines Knotens am verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
52
53
55
62
77
ABBILDUNGSVERZEICHNIS
6.2
6.3
6.4
ABBILDUNGSVERZEICHNIS
Zeit für die Teilnahme eines Knotens am verteilten Speicher in
Abhängigkeit von der Anzahl der bereits am Speicher teilnehmenden
Knoten auf Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 1 . . . . . . . . . . . . . . .
Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden
Knoten auf Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1 Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von den Einstellungen des
Algorithmus’ auf Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . .
A.3 Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’
auf Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4 Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf Topologie T 1 . . . . . . . . . . . . . . . . . .
A.5 Durchschnittliche Zeit für die Teilnahme eines Knotens am verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6 Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7 Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von den Einstellungen des
Algorithmus’ auf Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . .
A.8 Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’
auf Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
64
65
81
81
82
82
83
83
84
84
78
ABBILDUNGSVERZEICHNIS
ABBILDUNGSVERZEICHNIS
A.9 Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . .
B.1 Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden
Knoten auf Topologie T 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 1 . . . . . . . . . . . . . . . . . . .
B.3 Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der
am Speicher teilnehmenden Knoten auf Topologie T 1 . . . . . . . . . .
B.4 Zeit für die Teilnahme eines Datensatzes am verteilten Speicher in
Abhängigkeit von der Anzahl der bereits am Speicher teilnehmenden
Knoten auf Topologie T 2 . . . . . . . . . . . . . . . . . . . . . . . . . .
B.5 Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 2 . . . . . . . . . . . . . . .
B.6 Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 2 . . . . . . . . . . . . . . . . . . .
B.7 Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der
am Speicher teilnehmenden Knoten auf Topologie T 2 . . . . . . . . . .
85
87
87
88
88
89
89
90
79
Anhang A
Messergebnisse Simulationsreihe 1
Die folgenden Diagramme bestehen aus jeweils zwei Messreihen mit eingezeichneter
linearer Regression. Dabei sind auf der X-Achse die Algorithmeneinstellung für die
Anzahl der Zonen pro Knoten und davon abhängig auf der Y-Achse die ermittelten
Größen eingezeichnet. Eine Punktmenge steht dabei jeweils für die Simulationen mit
und ohne L2N-Tabellen (L2NT).
A.1
Simulationsreihe 1 auf Topologie T1
Die Diagramme 6.1, A.1, A.2, A.3 und A.4 beziehen sich auf die Simulationen auf der
Netzwerktopologie T 1.
A.2
Simulationsreihe 1 auf Topologie T2
Die Diagramme A.5, A.6, A.7, A.8 und A.9 beziehen sich auf die Simulationen auf der
Netzwerktopologie T 2.
80
Simulationsreihe 1 auf Topologie T2
Messergebnisse Simulationsreihe 1
durchschnittliche tstore [ms]
12
11.5
11
10.5
10
9.5
9
f (x) = ax + b mit a = 0.00321 und b = 10.9
g(x) = ax + b mit a = −0.0219 und b = 11.5
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.1: Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 1
durchschnittliche rstore [ms]
3.5
3
2.5
2
1.5
1
f (x) = ax + b mit a = 0.00422 und b = 1.81
g(x) = ax + b mit a = −0.0536 und b = 3.21
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.2: Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von den Einstellungen
des Algorithmus’ auf Topologie T 1
81
Simulationsreihe 1 auf Topologie T2
Messergebnisse Simulationsreihe 1
durchschnittliche tquery [ms]
12
11.5
11
10.5
10
9.5
9
f (x) = ax + b mit a = 0.00224 und b = 10.1
g(x) = ax + b mit a = −0.0225 und b = 10.7
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.3: Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem
verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf Topologie T 1
durchschnittliche rquery [ms]
3.5
3
2.5
2
1.5
1
f (x) = ax + b mit a = 0.00422 und b = 1.81
g(x) = ax + b mit a = −0.0536 und b = 3.21
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.4: Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf Topologie T 1
82
Simulationsreihe 1 auf Topologie T2
Messergebnisse Simulationsreihe 1
durchschnittliche tjoin [ms]
1000
800
600
400
200
0
f (x) = ax + b mit a = 149 und b = 147
g(x) = ax + b mit a = 149 und b = 147
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.5: Durchschnittliche Zeit für die Teilnahme eines Knotens am verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 2
durchschnittliche tstore [ms]
180
170
160
150
140
130
120
f (x) = ax + b mit a = 1.46 und b = 115
g(x) = ax + b mit a = 1.72 und b = 152
110
100
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.6: Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf
Topologie T 2
83
Simulationsreihe 1 auf Topologie T2
Messergebnisse Simulationsreihe 1
durchschnittliche rstore [ms]
3.5
3
2.5
2
1.5
1
f (x) = ax + b mit a = −0.00551 und b = 2.06
g(x) = ax + b mit a = −0.0536 und b = 3.21
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.7: Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von den Einstellungen
des Algorithmus’ auf Topologie T 2
durchschnittliche tquery [ms]
120
110
100
90
80
70
f (x) = ax + b mit a = 0.999 und b = 66.6
g(x) = ax + b mit a = 1.27 und b = 103
60
50
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.8: Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem
verteilten Speicher in Abhängigkeit von den Einstellungen des Algorithmus’ auf Topologie T 2
84
Simulationsreihe 1 auf Topologie T2
Messergebnisse Simulationsreihe 1
durchschnittliche rquery [ms]
3.5
3
2.5
2
1.5
1
f (x) = ax + b mit a = −0.00551 und b = 2.06
g(x) = ax + b mit a = −0.0536 und b = 3.21
1
f (x)
2
3
4
Anzahl der Zonen pro Rechnerknoten
g(x)
mit L2NT
ohne L2NT
5
Abbildung A.9: Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem Speicher in Abhängigkeit von den Einstellungen des
Algorithmus’ auf Topologie T 2
85
Anhang B
Messergebnisse Simulationsreihe 2
Die folgenden Diagramme bestehen aus jeweils einer Messreihe. Dabei sind auf der
X-Achse die Algorithmeneinstellung für die Anzahl der am simulierten Speicher teilnehmenden Knoten und davon abhängig auf der Y-Achse die ermittelten Größen dargestellt. Die eingezeichneten Linien sind Versuche verschiedener Regressionen. Welche
Funktion zur Anpassung auf die Punktmenge im Einzelfall verwendet wurde, ist im
Diagramm selbst angegeben.
In den Abbildungen 6.2 und B.4 beginnt die lineare Regression erst mit dem fünften
Wert, also dem Wert bei x = 4, da es sich bei den ersten vier Werten bedingt durch
die Funktionsweise des Algorithmus’ um Ausreißer handelt.
B.1
Simulationsreihe 2 auf Topologie T1
Die Diagramme 6.2, B.1, 6.3, B.2 und B.3 beziehen sich auf die Simulation auf der
Netzwerktopologie T 1.
B.2
Simulationsreihe 2 auf Topologie T2
Die Diagramme B.4, 6.4, B.5, B.6 und B.7 beziehen sich auf die Simulation auf der
Netzwerktopologie T 2.
86
Simulationsreihe 2 auf Topologie T2
Messergebnisse Simulationsreihe 2
durchschnittliche tstore [ms]
11.05
11
10.95
10.9
10.85
10.8
10.75
√
g(x) = a x + b mit a = 0.0636 und b = 10.6
h(x) = a log(x) + b mit a = 0.154 und b = 10.4
10.7
10.65
5
10
15
g(x)
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
tstore
Abbildung B.1: Durchschnittliche Zeit für das Ablegen eines Datensatzes im verteilten
Speicher in Abhängigkeit von der Anzahl der am Speicher teilnehmenden Knoten auf Topologie T 1
durchschnittliche tquery [ms]
10.15
10.1
10.05
10
9.95
√
g(x) = a x + b mit a = 0.043 und b = 9.83
h(x) = a log(x) + b mit a = 0.104 und b = 9.72
9.9
9.85
5
10
g(x)
15
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
tquery
Abbildung B.2: Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem
verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher
teilnehmenden Knoten auf Topologie T 1
87
Simulationsreihe 2 auf Topologie T2
Messergebnisse Simulationsreihe 2
1.9
durchschnittliche rquery
1.8
1.7
1.6
1.5
1.4
1.3
√
g(x) = a x + b mit a = 0.139 und b = 0.961
h(x) = a log(x) + b mit a = 0.33 und b = 0.611
1.2
1.1
5
10
15
g(x)
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
rquery
Abbildung B.3: Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der
am Speicher teilnehmenden Knoten auf Topologie T 1
600
f (x) = ax + b mit a = −1.66 und b = 308
500
tjoin [ms]
400
300
200
100
0
0
5
10
f (x)
15
20
25
30
Anzahl der Rechnerknoten
35
40
45
tjoin
Abbildung B.4: Zeit für die Teilnahme eines Datensatzes am verteilten Speicher in
Abhängigkeit von der Anzahl der bereits am Speicher teilnehmenden
Knoten auf Topologie T 2
88
Simulationsreihe 2 auf Topologie T2
Messergebnisse Simulationsreihe 2
durchschnittliche rstore
2.2
2
1.8
1.6
1.4
√
g(x) = a x + b mit a = 0.193 und b = 0.862
h(x) = a log(x) + b mit a = 0.452 und b = 0.394
1.2
1
5
10
15
g(x)
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
rstore
Abbildung B.5: Durchschnittliche Routingschrittanzahl für das Ablegen eines Datensatzes im verteilten Speicher in Abhängigkeit von der Anzahl der am
Speicher teilnehmenden Knoten auf Topologie T 2
durchschnittliche tquery [ms]
72
70
68
66
64
62
60
√
g(x) = a x + b mit a = 1.53 und b = 58.6
h(x) = a log(x) + b mit a = 4.07 und b = 53.4
58
56
5
10
g(x)
15
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
tquery
Abbildung B.6: Durchschnittliche Zeit für das Abfragen eines Datensatzes aus dem
verteilten Speicher in Abhängigkeit von der Anzahl der am Speicher
teilnehmenden Knoten auf Topologie T 2
89
Simulationsreihe 2 auf Topologie T2
Messergebnisse Simulationsreihe 2
durchschnittliche rquery
2.2
2
1.8
1.6
1.4
√
g(x) = a x + b mit a = 0.193 und b = 0.862
h(x) = a log(x) + b mit a = 0.452 und b = 0.394
1.2
1
5
10
g(x)
15
20
25
30
Anzahl der Rechnerknoten
h(x)
35
40
45
rquery
Abbildung B.7: Durchschnittliche Routingschrittanzahl für das Abfragen eines Datensatzes aus dem verteilten Speicher in Abhängigkeit von der Anzahl der
am Speicher teilnehmenden Knoten auf Topologie T 2
90
Anhang C
Thesen
1. Durch seine übersichtlichen und einfachen Strukturen und das vorhandene Verbesserungspotential bildet ein optimiertes CAN eine geeignete Grundlage für weitere Entwicklungen auf dem Gebiet der verteilten Speicherung von Daten.
2. Eine geringe Anzahl an Routing-Schritten ist, besonders auf Netzwerktopologien
mit wenigen stark latenzbehafteten Verbindungen, kein Garant für kurze Anfragezeiten. Hier ist außerdem die Lokalität des Algorithmus’ von Bedeutung.
3. Die Erweiterung der Nachbartabellen im CAN-Routing um durch Broadcasts
ermittelte Nachbarknoten kann die Gesamtperformance des Algorithmus deutlich
verbessern.
4. Die Verwaltung mehrerer Zonen pro Knoten wirkt sich stark negativ auf die Beitrittszeit der Knoten in den verteilten Speicher aus, während keine wahrnehmbare
Verbesserung der Routing-Zeiten auftritt.
5. Das Hinzufügen neuer Knoten in den assoziativen verteilten Speicher ist im vorgestellten optimierten Speicherkonzept weitgehend unabhängig von der Anzahl
der bereits teilnehmenden Knoten.
6. Die durchschnittliche Routing-Komplexität des optimierten Algorithmus’ liegt
deutlich unter der für CAN angegebenen maximalen Komplexität von O(n1/d ).
7. Die Performance von CAN als dem Algorithmus mit einer relativ hohen Routingkomplexität in seiner einfachsten Form kann durch gezielte Optimierungen
enorm verbessert werden.
91
Thesen
8. Zur Gewinnung verwertbarer Erkenntnisse über das Verhalten eines Algorithmus’
auf stark latenzbehafteten Netzwerktopologien sind Simulationen mit vielen teilnehmenden Knoten notwendig.
9. Die detaillierte Simulation aller Eigenschaften der einem verteilten Speicher zugrundeliegenden Netzwerktopologie ist enorm aufwändig und begrenzt dadurch
die Anzahl der simulierbaren Knoten.
92
Thesen
Konformitätserklärung
Ich erkläre, dass ich die vorliegende Arbeit selbstständig und nur unter Vorlage der
angegebenen Literatur und Hilfsmittel angefertigt habe.
Rostock, den . . . . . . . . . . . . . . . . . .
.....................
Henry Ristau
93