Studienarbeit Partitionierung von Netzwerkbeschreibungen für

Universität Paderborn
Fachbereich Mathematik–Informatik
Studienarbeit
Partitionierung von
Netzwerkbeschreibungen für verteilte
Simulationen
Andreas Goebels
Matrikelnummer 3661581
vorgelegt bei
Prof. Dr. Hans-Ulrich Heiß
Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne
unerlaubte Hilfe Dritter angefertigt habe. Alle Stellen, die inhaltlich
oder wörtlich aus Veröffentlichungen stammen, sind kenntlich gemacht. Diese Arbeit lag in gleicher oder ähnlicher Weise noch keiner
Prüfungsbehörde vor und wurde bisher noch nicht veröffentlicht.
Andreas Goebels
Paderborn, 15. April 2002
1
Zusammenfassung
Diese Studienarbeit beschäftigt sich mit der Partitionierung von Netzwerkbeschreibungen. Durch diese Partitionierung soll ermöglicht werden, große und zeitaufwendige Berechnungen von Netzwerksimulationen auf beliebig viele verteilte Systeme
aufzuteilen. Dazu wurde ein Tool implementiert, das Beschreibungsdateien für den
Netzwerk-Simulator ns“ einliest und aus den darin enthaltenen Informationen Be”
schreibungsdateien für die parallele Version des ns, den PDNS“, generiert. In das
”
Tool wurden beispielhafte Partitionierungs- und Bewertungsheuristiken eingebunden, wobei Wert auf eine Schnittstelle für zusätzliche Algorithmen gelegt wurde.
2
Inhaltsverzeichnis
Abbildungsverzeichnis
5
1. Einleitung
6
2. PNDG - Architektur und Arbeitsweise
2.1. Einlesen der ns Beschreibungsdatei . . . . . . . . . . . .
2.2. Gewichtung des Graphen . . . . . . . . . . . . . . . . . .
2.3. Partitionierung des Graphen . . . . . . . . . . . . . . . .
2.4. Generierung der endgültigen PDNS Beschreibungsdateien
2.5. Systemvoraussetzungen . . . . . . . . . . . . . . . . . . .
2.6. Konfigurationsdatei . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
3. Bewertung und Partitionierung des Netzwerk-Graphen
3.1. Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Bewertungsalgorithmen . . . . . . . . . . . . . . . . . . . . .
3.2.1. Bewertung der Knoten durch Agentenpositionen . . .
3.2.2. Bewertung der Knoten durch Agentenpositionen und
Sende-/Empfangsdauer . . . . . . . . . . . . . . . . .
3.2.3. Bewertung der Kanten . . . . . . . . . . . . . . . . .
3.2.4. Kanten fixieren oder trennen . . . . . . . . . . . . . .
3.3. Partitionierungsalgorithmen . . . . . . . . . . . . . . . . . .
3.3.1. Partitionierung durch Aufteilungen
(partition by modulo und partition by simple) . . . .
3.3.2. Partitionierung durch fm partition (partition by fm)
3.3.3. Partitionierung durch ratio cut partition
(partition by ratio cut) . . . . . . . . . . . . . . . . .
3.3.4. Einbindung eigener Partitionierungsalgorithmen . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
9
12
12
12
15
16
17
. . . . . 17
. . . . . 17
. . . . . 19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
20
21
. . . . . 21
. . . . . 22
. . . . . 23
. . . . . 23
4. Auswertung
4.1. Probleme bei der Simulation . . . . . . . . . . . . . . . . . . . . . . .
4.2. Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Messergebnisse und Auswertung . . . . . . . . . . . . . . . . . . . . .
25
25
26
27
5. Zusammenfassung und Ausblick
30
3
Inhaltsverzeichnis
A. Unterstützte OTCL-Befehle
31
B. Konfigurationsdatei-Einträge
33
C. Implementierte Funktionen
34
Literaturverzeichnis
36
4
Abbildungsverzeichnis
1.1. Ein komplexes Netzwerk aus 800 Knoten . . . . . . . . . . . . . . . .
7
2.1. Ablaufdiagramm des PNDG . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Generierung eines Remote Links . . . . . . . . . . . . . . . . . . . . . 13
2.3. Generierung einer Remote Connection . . . . . . . . . . . . . . . . . 14
3.1. Bewertung eines Netzwerkgraphen . . . . . . . . . . . . . . . . . . . . 18
3.2. Aufgabe von neuen Partitionierungsalgorithmen . . . . . . . . . . . . 24
4.1. PassThrough-Problematik . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Ein komplexes Netzwerk: 8 Teilnetze mit je 100 Knoten (Testnetz I) . 27
4.3. Einfache Netzwerke mit 8 Knoten (Testnetze II und III) . . . . . . . 28
5
1. Einleitung
Bei der Untersuchung von sehr großen und komplexen Netzwerken greift man auf
Simulatoren zurück, da ein Test in einem realen Netz aus Kosten- und Zeitgründen
häufig kaum zu realisieren ist. Ein gutes Hilfsmittel für solche Berechnungen ist
der Netzwerk-Simulator ns[1]. Dieser wird durch eine Beschreibungsdatei, die in der
Sprache OTCL1 geschrieben ist, gesteuert.
Diese Nutzung von TCL zeigt aber - gerade bei komplexen Netzen - schnell ihre Grenzen. Der Speicherverbrauch (und auch die Laufzeit) ist so hoch, dass ab
mehreren hundert Knoten eine Simulation häufig nicht mehr in annehmbarer Zeit
durchgeführt werden kann. Ein Beispiel für ein schlecht vom ns zu berechnendes
Netzwerk ist in Abbildung 1.1 zu sehen.
Um diese Defizite zu umgehen, wurde vom Georgia Institute of Technology eine parallele Version des ns entwickelt, der PDNS (Parallel/Distributed Network
Simulator)[2]. Dieses Programm nutzt das ebenfalls an diesem Institut entwickelte
RTIKIT, um den PDNS auf mehrere Rechner bzw. Prozessoren zu verteilen. Dabei
wurde nicht ein vollständig neues Programm entwickelt, sondern eine Art Middle”
ware“ eingeführt, welche die Befehlssyntax des Netzwerksimulators erweitert. Durch
diese zusätzliche Schicht ist eine Kommunikation zwischen den einzelnen Instanzen
auf verteilten Systemen möglich.
Zur Nutzung des PDNS muss eine Netzwerkbeschreibung für den ns in einzelne Teile
aufgespalten werden, welche jeweils mit einer PDNS-Instanz parallel berechnet werden. Bisher musste diese Aufteilung von Hand“ geschehen. Hiermit war bei sehr
”
komplexen Netzen, für die die Nutzung des PDNS erst Sinn macht, ein sehr großer
Aufwand verbunden, außerdem war es schwierig, bei solchen Netzwerken geeignete
Partitionierungen zu finden, welche alle PDNS-Instanzen gleichmäßig auslasten und
den realen Netzwerkverkehr, der zwischen den Instanzen ausgetauscht werden muss,
so gering wie möglich halten.
An dieser Stelle setzt die Studienarbeit an. Es wurde ein Tool entwickelt, das den
Partitionierungsprozess automatisiert. Jetzt ist es möglich, ein komplexes Netzwerk,
welches für den ns in OTCL beschrieben wurde, direkt aufzuteilen und somit die
gesamte Simulation parallel mit beliebig vielen Instanzen des PDNS durchzuführen.
Erste Ergebnisse haben gezeigt, dass dabei die Partitionierungsmethode einen großen
Einfluss auf die Gesamtlaufzeit der Simulation hat. Es wurden mehrere Partitionie1
objektorientierte Abwandlung von TCL
6
1. Einleitung
Abbildung 1.1.: Ein komplexes Netzwerk aus 800 Knoten
rungsverfahren eingebunden und einige Versuchsreihen durchgeführt.
In diesem Dokument wird zuerst auf das entwickelte Tool eingegangen, die Arbeitsweise und die Architektur werden aufgezeigt. Danach werden in einem separaten
Kapitel Bewertungs- und Partitionierungskonzepte erläutert und verglichen. Nach einem abschließenden Ausblick folgt im Anhang eine detaillierte Beschreibung der entwickelten Funktionen und der unterstützten Konfigurations- und OTCL-Syntaxen.
7
2. PNDG - Architektur und
Arbeitsweise
In diesem Kapitel wird die Vorgehensweise des entwickelten PNDG (PDNS Network
Description Generator) erläutert. Der Augenmerk wird auf die Architektur und die
grundlegenden Algorithmen gelegt. Die Abbildung 2.1 stellt abstrakt die einzelnen
Schritte, die durchgeführt werden müssen, dar. Die jeweiligen Positionen werden in
den folgenden Abschnitten näher erläutert.
Im Anhang C befindet sich eine Auflistung aller wichtigen entwickelten Funktionen
mit einer Kurzbeschreibung, so dass eine Weiterentwicklung oder Ergänzung der
Bewertungs- und Partitionierungsalgorithmen einfach vorgenommen werden kann,
indem bestehende Programmteile genutzt werden. In der Tabelle 2.1 werden die
wichtigsten OTCL Objekte erläutert.
Abbildung 2.1.: Ablaufdiagramm des PNDG
8
2. PNDG - Architektur und Arbeitsweise
Objekt
Agent
Traffic
Source
Erklärung
Ein Agent bildet einen Start- bzw. Endpunkt einer Netzwerkkommunikation. Mit Hilfe eines Agenten können
Pakete zu weiteren Agenten geschickt werden. Der Netzwerksimulator ns bietet verschiedene Typen von Agenten an (z.B. UDP- oder TCP), die das Übertragungsprotokoll des Pakettransportes bestimmen. Ein Agent ist
immer an einen speziellen Knoten gebunden, von dem
aus die Pakete zu den jeweiligen Zielagenten geschickt
werden.
Eine Traffic Source ist ein OTCL-Objekt, das zu definierbaren Zeitpunkten Datenpakete mit bestimmten
Attributen (Sendeintervall, Paketgröße etc.) losschicken
kann. Sie ist immer an einen Agenten gebunden und
dieser bestimmt das Ziel der einzelnen Pakete. An einen
Agenten können beliebig viele Traffic Sourcen gebunden
sein.
Tabelle 2.1.: Wichtige ns-Objekte
2.1.
Einlesen der ns Beschreibungsdatei
Das Einlesen der OTCL-Kommandos geschieht mit Hilfe eines Parsers, welcher
durch einen Parsergenerator automatisch erzeugt wurde (siehe 2.5). Kann ein Befehl interpretiert werden, werden die Daten in internen Datenstrukturen und gegebenenfalls auch in einem Netzwerkgraphen1 gespeichert. Bei einigen Ursprungsbefehlszeilen können zu diesem Zeitpunkt noch keine Angaben über die endgültige
Syntax gemacht werden, da sich Veränderungen aufgrund der späteren Partitionierung ergeben können. Diese können also nicht direkt in die endgültigen PDNSBeschreibungsdateien übernommen werden, sondern es müssen die zusätzlichen Befehle des PDNS genutzt werden, um z.B. Netzwerkverbindungen der Simulation auf
reale Verbindungen abzubilden (Remote Links).
Es können grundsätzlich zwei Arten von Befehlen unterschieden werden:
1. Globale Befehle
Globale Befehle können in jeder PDNS-Beschreibungsdatei vorhanden sein und
werden aus der Ursprungsdatei für den ns ohne Modifikationen übernommen.
Ein Überblick über diese Kommandos gibt Tabelle 2.2.
1
Eine Datenstruktur, in der das gesamte Netzwerk als Graph gespeichert ist
9
2. PNDG - Architektur und Arbeitsweise
Globale Befehl
Erzeugung eines
neuen Simulators
Starten/Beenden der
Simulation,
Tracing-Kommandos,
Kommentare
Reaktion des PNDG
Beim Auftreten einer solchen Zeile wird ein neuer Netzwerkgraph initialisiert
Diese Zeilen werden ohne Veränderungen in die späteren
Beschreibungsdateien übernommen2
Tabelle 2.2.: Globale Befehle
2. Spezielle Befehle
Die Befehle in Tabelle 2.3 sind noch einzeln zu überprüfen, da sie entweder
nicht in alle PDNS-Dateien hineingehören oder noch verändert werden müssen,
weil sie von einer Partitionierung betroffen sind. Zum Beispiel enthält die
Beschreibungsdatei für eine einzelne PDNS-Instanz nur genau die Knoten und
Agenten, die auch auf ihr berechnet werden.
2
Die Übernahme von Kommentaren kann durch die Konfigurationsdatei gesteuert werden
10
2. PNDG - Architektur und Arbeitsweise
Spezielle Befehle
Generierung eines
Knotens
Generierung eines
Links
Starten/Stoppen
einer Traffic
Source
Generierung eines
Agenten
Agenten an einen
Knoten binden
Verbinden von
zwei Agenten
Generierung einer
Traffic Source
Traffic an einen
Agenten binden
Reaktion des PNDG
Im Netzwerkgraphen wird ein neuer Knoten angelegt.
Gleichzeitig wird dieser Knoten in einer internen Datenstruktur gespeichert.
Im Netzwerkgraphen wird eine neue gerichtete Kante
angelegt. Wenn der Link als Duplex-Link spezifiziert
ist, wird auch eine Kante in die entgegengesetzte Richtung eingerichtet3 . Da ns keinen eindeutigen Namen
für einen Link fordert, wird vom Programm ein Name
generiert. Dieser ist von der Form startNode endNode,
ein Link von node12 zu node37 bekommt also den Namen node12node37, unter dem er auch in einer Datenstruktur gespeichert wird, zusätzlich mit den Informationen über Bandbreite und Delay. Unter diesem Namen
kann der Link auch angesprochen werden, wenn er durch
die Konfigurationsdatei gesteuert getrennt werden soll
(CUT/UNCUT-Wert) (siehe 3.2.4).
Die Start- bzw. Endzeit der entsprechenden Traffic Source wird in einer Datenstruktur, in der diese verwaltet
werden, gespeichert. Mit Hilfe dieser Daten kann die
Sendedauer und die übertragene Datenmenge berechnet
werden.
Wird in der ursprünglichen Datei ein Agent generiert,
wird dieser in einer Agenten-Datenstruktur gespeichert.
Der Name des Agenten wird in der KnotenDatenstruktur eingetragen und die Daten, die ggf.
später in weiteren Befehlszeilen hinzukommen und
den Agenten parametrisieren, werden in der AgentenDatenstruktur gespeichert.
Bei diesem Befehl wird in der Agenten-Datenstruktur
für beide Agenten ein Verweis auf den jeweiligen Kommunikationspartner eingetragen.
Die Traffic-Source wird in einer Traffic-Datenstruktur
gespeichert.
In die Traffic-Datenstruktur wird ein Verweis auf den
Agenten aufgenommen, und bei dem betreffenden Agenten die Traffic-Source an eine Liste angehängt.
Tabelle 2.3.: Spezielle Befehle
3
Der Netzwerkgraph ist gerichtet
11
2. PNDG - Architektur und Arbeitsweise
2.2.
Gewichtung des Graphen
Die Gewichtung des eingelesenen Netzwerkgraphen bildet die Grundlage für die
spätere Partitionierung. Es können sowohl die Kanten als auch die Knoten gewichtet werden. Auf einem Graphen können vor der Partitionierung beliebig viele Gewichtungen durchgeführt werden. Es sind also Vorgehensweisen denkbar, die erst
alle Knoten gewichten, danach - in einem zweiten Algorithmus - die Kanten und als
letztes spezielle Bewertungen für neu implementierte Funktionalitäten (Paketfilter,
Firewall etc.) erzeugen. (siehe 3.2).
2.3.
Partitionierung des Graphen
Mit Hilfe der Partitionierungsalgorithmen wird der gewichtete Netzwerkgraph in die
benötigte Menge von PDNS-Instanzen zerlegt. Dabei kann die Partitionierung die
Gewichtung des Graphen berücksichtigen, dieses muss aber nicht zwingend erfolgen
(siehe 3.3).
2.4.
Generierung der endgültigen PDNS
Beschreibungsdateien
Nachdem der Graph partitioniert wurde, kann jeder Knoten in eine spezielle PDNSDatei eingeordnet werden. Dadurch ergeben sich auch automatisch die Menge der
Links, welche zwischen zwei PDNS-Instanzen gezogen werden müssen (rLinks) und
die Menge der Verbindungen von Agenten, deren Start- und Endpunkte in unterschiedlichen Instanzen liegen (rConnections).
Der nächste Schritt beinhaltet nun folgende Aufgaben:
• Globale Befehle in alle Dateien übernehmen
Hierzu gehören z.B. Initialisierungsbefehle für den Simulator, die ohne Modifikationen aus der Ursprungsdatei in jede PDNS-Beschreibungsdatei übernommen werden können (siehe auch Tabelle 2.2).
• lokale Links / lokale Knoten verteilen
Links, die nur zwischen Knoten aus einer einzelnen PDNS-Datei gezogen werden, können ebenfalls problemlos aus der ursprünglichen Datei übernommen
werden. Dieses ist möglich, da die Knoten jeweils in die durch den Partitionierungsalgorithmus bestimmte Datei übernommen werden, ohne dass ihre
Namen geändert werden.
• rLinks generieren
Remote Links treten genau dann auf, wenn ein ursprünglicher Link zwischen
12
2. PNDG - Architektur und Arbeitsweise
zwei Knoten verläuft, die durch die Partitionierung in unterschiedliche PDNSDateien platziert wurden. Ein rLink4 wird in diesem Fall als ein Link von
einem lokalen Knoten zu einer IP-Adresse5 definiert. Diese IP-Adresse hat auf
der Startseite des Links die Form n.n.n.1, auf der Zielseite n.n.n.2.
Wegen der Übersichtlichkeit wurde für die erste Position der IP-Adresse eine
Zahl festgelegt (diese kann in der Konfigurationsdatei eingestellt werden). Die
beiden mittleren Positionen werden durch fortlaufendes Zählen aller rLinks
generiert, der erste rLink erhält also z.B. die Nummer 10.0.1.16 , der zweite
10.0.2.1, der 257te die Nummer 10.1.1.1 usw. Die maximale Anzahl von rLinks
wird durch den PDNS begrenzt, der durch diese Zählweise zur Verfügung Zahlenraum (2562 IP-Adressen) reicht vollkommen aus. Auf der Gegenseite wird
gleichzeitig ein rLink generiert, welcher mit der entsprechenden IP-Adresse
(10.0.1.2, 10.0.2.2 bzw. 10.1.1.2) versehen wird. Die Attribute dieses Links
(Bandweite, Delay) werden vom Ursprungslink übernommen.
Abbildung 2.2.: Generierung eines Remote Links
• Traffic Sources und Agenten verteilen
Traffic Sources und Agenten müssen nicht gesondert behandelt werden, sie sind
immer an einen bestimmten Agenten bzw. Knoten gebunden und befinden sich
daher mit ihren Ursprungsbefehlen in genau einer einzelnen Datei, die durch
den betreffenden Knoten bestimmt wird.
• Agenten verbinden
Das Verbinden von zwei Agenten geschieht auf ähnliche Art und Weise wie
die Generierung eines Remote Links. Auch hier gibt es einmal den trivialen
Fall, dass sich Quelle und Senke jeweils in der selben PDNS-Datei befinden.
In diesem Fall ist keine Veränderung notwendig, die ursprünglichen Befehle
können einfach übernommen werden.
Der kompliziertere Fall tritt dann auf, wenn sich der Knoten, auf dem sich der
sendende Agent befindet, in einer anderen Datei - und damit in einer anderen
4
Remote Link
nur lokal für die PDNS-Simulation gültige IP
6
Die 10 entsteht durch eine Konfigurationsdateidefinition
5
13
2. PNDG - Architektur und Arbeitsweise
PDNS-Instanz - befindet, als der Knoten, auf dem sich die Senke befindet. In
diesem Fall sind mehrere Schritte notwendig:
1. Der sendende Agent bekommt die Port-Nummer 0, d.h. er horcht auf dem
Port, den der Empfänger zur Verfügung stellt. Der Zielagent bekommt
eine fortlaufende Portnummer zugewiesen7 .
2. Der Knoten, auf dem sich der Agent befindet, benötigt eine eindeutige IPAdresse. Diese wird aber nicht an den Knoten selbst gebunden, sondern
an den herausgehenden Link, auf dem der Agent sendet bzw. empfängt.
Diese IP-Adresse wird nach einem ähnlichen Prinzip gebildet wie beim
rLink. Die erste Position wird durch einen in der Konfigurationsdatei anzugebenden spezifischen Wert festgesetzt. An der zweiten Stelle befindet
sich ein Wert, der die Nummer der PDNS-Datei repräsentiert, in der dieser Agent angesiedelt ist. Die dritte und die vierte Stelle werden durch
eine fortlaufende Nummer berechnet und gebildet (siehe Abbildung 2.3).
Abbildung 2.3.: Generierung einer Remote Connection
3. Im nächsten Schritt werde Routinginformationen für die Knoten erzeugt,
auf denen sich sendende bzw. empfangende Agenten befinden. Diese Informationen legen fest, über welchen Remote Link und damit, über welchen
Knoten die Pakete aus der PDNS-Datei herausgeschickt werden sollen,
um den Zielknoten zu erreichen, d.h. welcher Knoten als Router fungieren
soll.
Vom PNDG wird dazu der Knoten ausgewählt, der im Originalgraphen
auf dem kürzesten Weg vom Start- zum Zielknoten als letzter in der
PDNS-Datei vorhanden ist.
4. Als abschließender Schritt folgt noch das Verbinden der Agenten. Dieses
ist ein rConnect8 eines Agenten mit einer IP-Adresse. Diese Adresse ist
7
8
Der Startwert der Portnummern kann in der Konfigurationsdatei festgelegt werden
Remote Connect
14
2. PNDG - Architektur und Arbeitsweise
genau der Wert, der für den Zielagenten festgesetzt wurde. Somit wird
der connect Befehl aus der ns-Syntax vollständig auf die PDNS-Syntax
abgebildet.
2.5.
Systemvoraussetzungen
Das im Verlauf dieser Studienarbeit entwickelte Tool wurde vollständig in C++
geschrieben und sollte auf Linux-Systemen benutzt werden. Bei umfassenden Beschreibungsdateien benötigt es zur Laufzeit viel (> 400 MB) Speicher und einen
großen Stack9 , es sollte daher auf ausreichend performanten Systemen eingesetzt
werden. Die folgenden Bibliotheken und Programme werden benötigt:
• Die Graph Template Library (GTL)
Im Tool PNDG werden die Informationen aus der ursprünglichen Netzwerkbeschreibungsdatei als Netzwerkgraph dargestellt. Zur Repräsentation dieser
Datenstruktur wurde die Graph Template Library (GTL) der Uni Passau eingesetzt. Diese bietet bereits einige implementierte Partitionierungsalgorithmen. Gleichzeitig wurden jedoch alle Funktionen, die auf diese Datenstruktur
zugreifen, so weit wie möglich unabhängig von der GTL entwickelt, wodurch
ein Wechsel der Graph Library einfach zu vollziehen ist. Die Erweiterbarkeit
um neue Partitionierungs- und Bewertungsalgorithmen stand im Vordergrund,
eine Spezialisierung auf eine einzelne Library oder Library-spezifische Befehle
wurde daher vermieden.
Die GTL kann unter [3] angefordert werden. Für akademische Zwecke ist sie
kostenlos einsetzbar.
• Scanner- und Parsergeneratoren (flex / bison)
Der Scannergenerator flex [4] generiert ein Modul, das zum Einlesen der nsBeschreibungsdatei benötigt wird. Er reagiert auf Schlüsselwörter und liefert
die identifizierten Token an den Parsergenerator weiter. Die Interpretation der
ursprünglichen Beschreibungsdatei geschieht dann durch ein Modul, das durch
den Parsergenerator bison[5] generiert wurde. In der momentanen Version werden nicht alle Elemente der Beschreibungsdateisprache OTCL unterstützt, es
wurden nur einige grundlegende implementiert (siehe Anhang A).
In dem vom Parsergenerator generierten Modul werden die vom Scanner gelieferten Token Sprach- bzw. Befehlselementen zugeordnet.
Durch den Einsatz von Scanner- und Parsergeneratoren ist eine schnelle und
einfache Erweiterung auf zusätzliche OTCL-Sprachelemente möglich. Ein neuer OTCL-Befehl kann somit einfach in die Grammatik eingefügt werden, ohne
dass spezielle String-Operationen durchgeführt werden müssen. Im Verlauf der
Studienarbeit sind auf diese Weise diverse Befehle problemlos zusätzlich hinzugefügt worden.
9
Die Stackgröße von Linux sollte auf unlimited gesetzt werden
15
2. PNDG - Architektur und Arbeitsweise
2.6.
Konfigurationsdatei
Zur Steuerung des Tools dient eine Konfigurationsdatei. In dieser befinden sich Anweisungen, die das Vorgehen des PNDG festlegen, z.B. die Anzahl der zu generierenden PDNS-Beschreibungsdateien oder die intern genutzten IP-Adressen und
Portnummern. Des weiteren können hiermit auch die Bewertungen des Netzwerks
und die Partitionierung gesteuert und parametrisiert werden. Nähere Informationen
zum Aufbau einer Konfigurationsdatei sind im Anhang B zu finden.
16
3. Bewertung und Partitionierung des
Netzwerk-Graphen
3.1.
Übersicht
Eine Graph-Datenstruktur verwaltet das Netzwerk, welches durch das Tool intern
erzeugt worden ist. Um daraus die einzelnen Beschreibungsdateien für den PDNS
zu erzeugen, wird dieser Graph partitioniert. Jeder Teilgraph entspricht dabei einer
Beschreibungsdatei für eine Instanz des PDNS.
Bei dieser Partitionierung müssen zwei Dinge berücksichtigt werden:
1. Gleichmäßige Belastung der PDNS-Instanzen
Die einzelnen PDNS-Instanzen sollten - wenn möglich - gleichmäßig belastet
werden. Das heißt nicht nur, dass die Knoten einheitlich verteilt werden, sondern vor allem, dass der Verkehr zwischen einzelnen Knoten geschickt auf die
Instanzen verteilt wird.
2. Minimierung des realen Netzwerkverkehrs zwischen den PDNS-Instanzen
Da bei Nutzung des PDNS zwischen den einzelnen Instanzen Informationen
ausgetauscht werden müssen, belasten diese den realen Netzwerkverkehr und
dadurch unter Umständen die Gesamteffizienz der Simulation. Eine Partitionierung muss diese Tatsache berücksichtigen, indem Links hauptsächlich dann
durchtrennt werden, wenn über sie kein oder sehr wenig Verkehr fließt.
Ein großes Problem für diese intelligente“ Partitionierung ist, dass der wirkliche
”
Verkehr nicht bekannt ist, ohne dass die vollständige Simulation durchgeführt wurde. Daher muss der Verkehr durch Heuristiken abgeschätzt werden.
Im Folgenden werden die beispielhaft implementierten Partitionierungs- und Bewertungsalgorithmen vorgestellt.
3.2.
Bewertungsalgorithmen
Einige Partitionierungsalgorithmen berücksichtigen bei der Partitionierung des
Netzwerkgraphen das Gewicht der einzelnen Knoten, der einzelnen Kanten oder
beides. Mit Hilfe von Bewertungsalgorithmen wird eine solche Bewertung durchgeführt.
17
3. Bewertung und Partitionierung des Netzwerk-Graphen
Es können für einen Netzwerkgraphen mehrere Bewertungsalgorithmen nacheinander angewandt werden, z.B. kann der erste Algorithmus nur die Knoten gewichten,
der zweite dagegen nur die Kanten. Durch dieses modulare Vorgehen ist es sehr
einfach, neue Bewertungsheuristiken zu entwickeln und zu testen und damit ggf.
spezielle Netzwerke bzw. Netzwerkverkehrssituationen besser anzunähern als es die
bereits implementierten Funktionen es können.
Eine weitere Möglichkeit, dieses Konzept auszunutzen, bietet sich bei sehr rechenaufwendigen Konstrukten, z.B. einem speziellen Paketfilter oder einer Firewall. Diese können durch einen zusätzlichen Bewertungsalgorithmus ausgewählte Knotengewichte separat erhöhen. Durch unterschiedliche Kombination mehrerer Bewertungen
kann dann die für den jeweiligen Partitionierungsalgorithmus geeignetste Gesamtbewertung erzeugt werden.
Generell sollten bei der Bewertung die Knoten stärker belastet werden, die als Datenquelle bzw. -senke fungieren, da hier ein erhöhter Aufwand auf den Simulator
zukommt.
Ähnlich verhält es sich bei der Berechnung der Kantengewichte. Hier sollte eine
Abbildung 3.1.: Bewertung eines Netzwerkgraphen
stärkere Gewichtung genau der Kanten erfolgen, die durch Netzwerkverkehr, der
darüber fließt, stärker belastet werden als Kanten, die in der Simulation nicht genutzt werden. Dadurch wird der reale Netzwerkverkehr, der über den Partitionierungsschnitt geschickt wird, so gering wie möglich gehalten, wenn diese Bewertung
von den Partitionierungsalgorithmen korrekt weiterverarbeitet wird.
In der Abbildung 3.1 ist ein Ausschnitt aus einem bewerteten Graphen zu sehen.
Hier wurden sowohl die Knoten als auch die Kanten auf dem Weg von der source zum
18
3. Bewertung und Partitionierung des Netzwerk-Graphen
target unterschiedlich bewertet. Als Datenquelle für eine differenzierte Bewertung
können die zu jedem Agenten gespeicherten Werte (z.B. Sendedauer oder Paketgröße) und Werte aus der Konfigurationsdatei hinzugezogen werden.
3.2.1.
Bewertung der Knoten durch Agentenpositionen
Durch diesen Algorithmus werden alle Agenten betrachtet und das Gewicht eines
Knotens für jeden Agenten, der darauf lokalisiert ist, erhöht. Es kann dabei unterschieden werden, ob der Agent als Quelle oder als Senke fungiert. Beiden Agentenarten kann ein eigenes Gewicht zugeordnet werden, da diese gegebenenfalls unterschiedlichen Simulationsaufwand nach sich ziehen1 . Diese Zuordnung geschieht
durch die folgenden Konfigurationsdatei-Einträge:
• set assess_by_agent_position enable
• set assess_by_agent_position_source_agent_weight [INTEGER]
• set assess_by_agent_position_target_agent_weight [INTEGER]
Durch diese Bewertung und im Zusammenspiel mit den geeigneten Partitionierungsalgorithmen (siehe auch 3.3.2 und 3.3.3) kann das Gewicht der Knoten gleichmäßig
auf alle PDNS-Instanzen verteilt werden. Die einzelnen Systeme haben annähernd
gleichgroße Mengen an Knoten zu verwalten.
3.2.2. Bewertung der Knoten durch Agentenpositionen und
Sende-/Empfangsdauer
Hier wird ähnlich wie unter 3.2.1 das Gewicht der Knoten durch die darauf platzierten Agenten berechnet. Die Bewertung erfolgt aber jetzt nicht mehr nur alleine
aufgrund der Tatsache, dass ein Agent vorhanden ist, sondern es wird zusätzlich
die Dauer der Übertragung berücksichtigt. Dadurch bekommt ein Knoten, der über
einen sehr langen Zeitraum Pakete schickt, ein höheres Gewicht als ein Knoten, welcher nur für eine sehr kurze Zeit sendet.
Das Gewicht, mit dem ein betroffener Knoten belastet wird, berechnet sich nach der
folgenden Formel:
agentenGewicht * (trafficEndZeit - trafficStartZeit)
Gleichzeitig gibt es die Möglichkeit, alle Knoten zu gewichten, über die der Netzwerkverkehr fließt, und nicht nur die Start- und Endknoten. Um dieses zu nutzen,
muss der Wert für die intermediate nodes > 0 gesetzt werden. Insgesamt ergeben
sich für diese Gewichtung folgende Parameter, die in der Konfigurationsdatei gesetzt
werden müssen:
• set assess_by_agent_position_time enable
1
abhängig vom Agententyp (UDP / TCP / Multicast)
19
3. Bewertung und Partitionierung des Netzwerk-Graphen
• set assess_by_agent_position_time_source_agent_weight [INTEGER]
• set assess_by_agent_position_time_target_agent_weight [INTEGER]
• set assess_by_agent_position_time_intermediate_agent_weight [INTEGER]
3.2.3.
Bewertung der Kanten
Mit diesem Algorithmus werden alle Kanten, die von Netzwerkverkehr betroffen sind,
mit Gewichten versehen. Dazu werden alle Sender/Empfänger-Paare betrachtet und
der kürzeste Weg im Graphen vom Sender zum Empfänger bestimmt. Da ns und
damit auch PDNS den Weg auf die selbe Art bestimmen, ist gewährleistet, dass die
hier bewerteten Kanten auf die Kanten abgebildet werden können, über die in der
Simulation Pakete geschickt werden. Alle Kanten, die auf diesem Weg liegen, werden
gewichtet mit dem Wert:
(trafficEndZeit-trafficStartZeit) * Paketgröße * Sendeintervall
In der Konfigurationsdatei aktiviert der Eintrag
set assess_by_agent_traffic enable
diese Bewertung.
3.2.4.
Kanten fixieren oder trennen
Wenn die zu simulierende Netzwerktopologie bekannt ist und manuell in die Partitionierung eingegriffen werden soll, kann es sinnvoll sein, einzelne Kanten festzulegen,
welche - wenn möglich - getrennt werden sollen, oder aber festzulegen, dass eine
Kante - wenn möglich - nicht getrennt werden soll. Um diese Wünsche berücksichtigen zu können, gibt es in der Konfigurationsdatei die Möglichkeit, für jede Kante
separat festzulegen, ob diese getrennt werden soll (CUT), oder ob sie untrennbar“
”
ist (UNCUT).
Diese Festlegungen sind allerdings nicht hundertprozentig bindend. Der Partitionierungsalgorithmus muss ebenfalls passend entwickelt worden sein, da ein CUT-Link
einfach ein Link ist, dessen Gewicht - unabhängig vom darüberfließenden Verkehr immer den Wert besitzt, der für solche CUT-Links festgesetzt wurde; ebenso wird
mit UNCUT-Links verfahren.
In der aktuellen Implementierung berücksichtigen die Partitionierungsalgorithmen
(ratio cut und fm) das Gewicht des Schnittes, was bedeutet, dass ein mit einem sehr
großen Wert belegter Link wahrscheinlich nicht durchtrennt wird, ein mit einem sehr
kleinen Wert belegter dagegen sehr schnell. Die folgenden Konfigurationseinträge
haben in Verbindung mit den vorhandenen Partitionierungsalgorithmen recht gute
Ergebnisse erzielt, um CUT- und UNCUT-Links zu realisieren:
• set cut_value 0
20
3. Bewertung und Partitionierung des Netzwerk-Graphen
• set uncut_value 999999
Um festzulegen, dass eine Kante zwischen zwei Knoten n1 und n2 getrennt bzw.
nicht getrennt werden soll, kann ebenfalls in der Konfigurationsdatei ein Eintrag
vorgenommen werden:
• set n1n2 CUT
oder
• set n1n2 UNCUT
Diese Knotenfixierung ist im Endeffekt wieder ein Bewertungsalgorithmus, der aber
jetzt durch Konfigurationseinträge gesteuert wird. Das Besondere an diesem Algorithmus ist, dass dieser immer als letzter aller Bewertungsalgorithmen ausgeführt
werden muss, ansonsten könnten die CUT- bzw. UNCUT-Werte von einer später
ausgeführten Bewertung noch verändert werden. Dies muss auch bei der Einführung
neuer Bewertungsalgorithmen beachtet werden.
3.3.
Partitionierungsalgorithmen
Die Partitionierung eines Graphen gestaltet sich als besonders schwierig, wenn
zusätzlich zu unterschiedlichen Knotengewichten noch Kantengewichte und das Gewicht des Schnittes berücksichtigt werden soll. Der Schwerpunkt dieser Studienarbeit lag nicht in der Entwicklung von Partitionierungsalgorithmen, sondern in der
Entwicklung eines Werkzeuges, in welches einfach unterschiedliche Partitionierungsalgorithmen eingeführt werden können. Aus diesem Grund sind die Ergebnisse, die
diese Algorithmen liefern, nicht unbedingt optimal. Sie können bei Bedarf jederzeit
ausgetauscht werden.
In der aktuellen Version des PNDG sind zwei Arten von Algorithmen eingebunden.
Einmal wurden sehr einfache Aufteilungen neu implementiert (modulo und simple),
welche hauptsächlich zu Testzwecken und Vergleichen herangezogen worden sind.
Des weiteren wurden zwei Algorithmen (fm und ratio cut) aus der GTL soweit modifiziert, dass sie für den PNDG geeignete Ergebnisse liefern. Die Eigenschaften der
einzelnen Algorithmen werden in den folgenden Abschnitten genauer beschrieben.
3.3.1. Partitionierung durch Aufteilungen
(partition by modulo und partition by simple)
Diese Partitionierungs-Algorithmen sind sehr einfach und dienen hauptsächlich als
Vergleich für die Güte anderer, intelligentere“ Partitionierungsalgorithmen. Die
”
Partitionierung geschieht hier nicht im Hinblick auf die Güte der resultierenden
Partitionen bzw. Schnitte, sondern nur in Hinblick auf Nachvollziehbarkeit und Beeinflussbarkeit. Dadurch ist es möglich, von vorneherein auch bei sehr großen Netzwerken festzulegen, welche Knoten auf welchen Instanzen berechnet und wo Schnitte gesetzt werden. Dieses Verfahren bietet sich bei bekannten Netzwerktopologien
21
3. Bewertung und Partitionierung des Netzwerk-Graphen
an. Die Wahl, welche dieser beiden Partitionierungen angewandt werden soll, ist
abhängig von den Informationen, die über die Ursprungsdatei bekannt sind.
Die Anzahl der gewünschten PDNS-Beschreibungsdateien wird aus der Konfigurationsdatei an den Algorithmus übergeben. Im nächsten Schritt werden die Knoten
in der Reihenfolge ihres Auftretens in der Originaldatei betrachtet und jeweils der
entsprechenden PDNS-Datei zugewiesen. Im Modulo-Fall sieht das folgendermaßen
aus:
for (i=0; i < nodeCount; i++)
schreibe node[i] in Datei (node[i] % numberOfPDNSFiles)
Der partition by simple Algorithmus arbeitet sehr ähnlich, nur dass hier z.B. bei 500
Knoten und 5 Instanzen die ersten 100 Knoten in die erste PDNS-Instanz platziert
werden, die nächsten 100 in die zweite usw. Bei diesen Partitionierungsmethoden
wird jeglicher simulierter Netzwerkverkehr unberücksichtigt gelassen. Allerdings ist
gewährleistet, dass jede PDNS-Instanz annähernd die gleiche Anzahl an Knoten
zu bearbeiten hat. Außerdem besteht nicht die Einschränkung, dass nur PDNSInstanzen der Anzahl 2n (siehe 3.3.2 und 3.3.3) berechnet werden können.
3.3.2.
Partitionierung durch fm partition (partition by fm)
fm partition ist eine Heuristik für die bi-Partitionierung eines Graphen. Sie wurde
1982 von Fiduccia und Mattheyses entwickelt. Bei der fm partition-Heuristik wird
von einer initialen Partitionierung des Graphen ausgegangen und versucht, durch
Knotenaustausch zwischen den Partitionen zwei gleichmäßig gewichtete Partitionen
zu erhalten[6]. Näheres zur genauen Vorgehensweise dieser Partitionierung ist unter
[7] zu finden.
Diese Partitionierung funktioniert nur für eine Anzahl von PDNS-Instanzen aus 2n .
Durch den Algorithmus wird erst der gesamte Graph halbiert und dann iterativ
die daraus resultierenden Teilgraphen, bis die gewünschte Anzahl an Teilgraphen
entstanden ist. Bei der Partitionierung werden sowohl die Kantengewichte als auch
die Knotengewichte des Graphen berücksichtigt. Die Laufzeit dieses Algorithmus ist
O(|E|) (Mit E = Anzahl der Kanten im Graphen).
Da dieser Partitionierungsalgorithmus sowohl die Knoten- als auch die Kantengewichte möglichst gleichmäßig auf die einzelnen Teilgraphen verteilt, können alle Knoten und Kanten mit initialen Werten belegt werden2 . Hierdurch wird vermieden, dass
eine PDNS-Instanz einen Großteil der Knoten verarbeiten muss, wenn diese keine
Agenten beinhalten und auch nicht vom Netzwerkverkehr betroffen sind. Es kann
also auch der Verwaltungsaufwand für diese unbenutzten Knoten minimiert werden.
Um diesen Algorithmus nutzen zu können, sind folgende Konfigurationseinträge notwendig:
• set partition_by_fm enable
2
Diese initiale Bewertung kann auch durch Bewertungsalgorithmen geschehen
22
3. Bewertung und Partitionierung des Netzwerk-Graphen
• set partition_by_fm_initial_node_weight [INTEGER]
• set partition_by_fm_initial_link_weight [INTEGER]
3.3.3. Partitionierung durch ratio cut partition
(partition by ratio cut)
Auch bei dieser Partitionierung werden sowohl die Kantengewichte als auch die
Knotengewichte des Graphen berücksichtigt. Die Laufzeit ist O(|E|) (Mit E =
Anzahl der Kanten). Es gelten dieselben Eigenschaften und Einschränkungen wie
bei fm partition, allerdings hat diese Partitionierungsmethode bei einigen Tests geringfügig bessere Ergebnisse geliefert. Diese Konfigurationseinträge parametrisieren
den Algorithmus:
• set partition_by_ratio_cut enable
• set partition_by_ratio_cut_initial_node_weight [INTEGER]
• set partition_by_ratio_cut_initial_link_weight [INTEGER]
Weiterführende Informationen können unter [8] nachgelesen werden.
3.3.4.
Einbindung eigener Partitionierungsalgorithmen
PNDG wurde so entwickelt, dass andere bzw. zusätzliche Partitionierungsalgorithmen ohne Probleme eingebunden werden können. Dieses erfolgt in zwei Schritten
(siehe auch Abbildung 3.2):
1. Konvertierung des Netzwerkgraphen und der Kantengewichte in eine Datenstruktur, die der neue Partitionierungsalgorithmus verarbeiten kann. Wird
dieser neu implementiert, können die in der GTL vorhandenen Funktionen
benutzt werden, um auf diese Graph-Datenstruktur zuzugreifen.
2. Zurückliefern eines nodeTargetStruct, einer einfachen Hashtable (map), welche
dem Knoten (mit dem Namen, den er in der originalen TCL-Datei besitzt als
Key) einen Integer-Wert zuweist. Dieser Wert ist die Nummer der Datei, in
der dieser Knoten eingeordnet werden soll.
23
3. Bewertung und Partitionierung des Netzwerk-Graphen
Abbildung 3.2.: Aufgabe von neuen Partitionierungsalgorithmen
Es sind ebenfalls einfache Funktionen vorhanden, um auf die Werte aus der
Konfigurationsdatei zugreifen zu können. Näheres dazu ist im Anhang und in den
beispielhaften Implementierungen von Partitionierungsalgorithmen im Quellcode zu
finden.
24
4. Auswertung
4.1.
Probleme bei der Simulation
Bei der Entwicklung des PNDG und der damit verbundenen Nutzung der vom PDNS
zur Verfügung gestellten Befehle traten während der Testphase mehrere Probleme
auf. Aus diesem Grund war es nicht möglich, alle gewünschten Versuchsreihen zu
simulieren.
Die wichtigsten Einschränkungen, die einer erfolgreichen Simulation im Wege standen, lassen sich in folgenden Punkten zusammenfassen:
1. PDNS macht einige Einschränkungen aufgrund fehlerhafter und unvollständiger Implementierung:
a) Ein sendender Agent darf nicht an der Außenseite“ einer PDNS-Instanz
”
liegen. Wenn die einzige Möglichkeit zu senden direkt über einen rLink
führt, kann keine Verbindung zum Zielagenten hergestellt werden, da diesem rLink keine gültige IP-Adresse zugewiesen werden kann. PNDG versucht, durch Wahl eines Ausweichweges diese Problematik zu umgehen,
dieses funktioniert allerdings nicht bei beliebigen Netzen, außerdem wird
hierbei ein anderer Weg für den Netzwerkverkehr gewählt, als in der originalen Datei gewählt worden wäre. Es wird demzufolge keine hundertprozentig identische Simulation mehr durch den PDNS durchgeführt, er
liefert gegebenenfalls andere Ergebnisse als der ns.
b) Pakete, deren Ziel-IP-Adresse nicht in der simulierten PDNS-Instanz
liegt, können nicht weitergeleitet werden. Daher ist kein Routing über
mehrere Instanzen möglich. Die mittlere PDNS-Instanz in Abbildung
4.1 kann zum Beispiel Pakete, die aus der Source-Instanz an die TargetInstanz geschickt werden, nicht korrekt weiterleiten. An diesem Problem
arbeitet der Entwickler des PDNS. Soweit dieses passthrough-Routing in
der Dokumentation beschrieben ist, ist es bereits in der aktuellen Version
des PNDG implementiert, bei einer Behebung des Fehlers im PDNS sollte
es also direkt unterstützt werden.
2. Die Netzwerkbeschreibungsdatei darf nicht beliebige Befehle enthalten, es ist
nur der im Anhang aufgeführte Befehlssatz gültig.
Da zusätzliche Sprachelemente jedoch sehr schnell und ohne aufwändige
25
4. Auswertung
Abbildung 4.1.: PassThrough-Problematik
Veränderungen hinzugefügt werden können, kann der Sprachumfang sukzessive ausgebaut werden, bis ein kompletter OTCL-Parser vorhanden ist.
Zusätzlich zu den beschriebenen Problemen traten bei den Simulationen unterschiedliche weitere Fehler im PDNS auf, die teilweise auch auf die benutzte Hardwareumgebung zurückzuführen sind.
4.2.
Testumgebung
Um den PDNS mit dem ns zu vergleichen, aber auch, um die unterschiedlichen Partitionierungsalgorithmen zu untersuchen, wurde ein komplexes Netzwerk erzeugt.
Dieses muss aufgrund mehrerer Fehler im PDNS (siehe 4.1) einige Voraussetzungen
erfüllen. Das in Abbildung 4.2 visualisierte Netzwerk erfüllt diese Voraussetzungen.
Es besitzt 800 Knoten, 1600 Links und 256 Agenten (siehe Abbildung 4.2). Die
Agenten sind gleichmäßig auf alle 8 Teilgraphen verteilt, 30 Agenten senden dabei jeweils zum benachbarten Graphen, 2 zu einem Knoten innerhalb des Graphen.
Die Knoten sind in der Beschreibungsdatei so angeordnet, dass sie durch die simple partition Methode einheitlich in bis zu 8 Teilgraphen aufgeteilt werden können.
Bei dieser Partitionierungsmethode können aufgrund der bekannten Positionen der
Agenten genaue Angaben über den Netzwerkverkehr zwischen den Instanzen gemacht werden.
Da der PDNS bei der Simulation dieses komplexen Netzwerks häufig Fehler produziert hat, wurde zusätzlich ein sehr einfaches, kleines Netzwerk aus 8 Knoten erzeugt,
um Messergebnisse für spezielle Situationen zu erhalten (siehe Abbildung 4.3).
26
4. Auswertung
Abbildung 4.2.: Ein komplexes Netzwerk: 8 Teilnetze mit je 100 Knoten (Testnetz
I)
4.3.
Messergebnisse und Auswertung
Die Messergebnisse sind aufgrund der oben beschriebenen Probleme des PDNS und
der diversen Fehler bei den Testläufen nicht vollständig und nur eingeschränkt interpretierbar. Trotzdem lassen sich auch schon bei diesen wenigen Ergebnissen Erkenntnisse sowohl über Simulationen mit dem PDNS als auch über unterschiedliche
Partitionierungsmethoden gewinnen1 .
Der Test 1 und die Tests 3 - 6 wurden auf einem Workstation Cluster mit Doppelprozessormaschinen (P3) durchgeführt, Test 2 lief auf dem HPCline Cluster des
P C 2.
Die einzelnen Tests wurden mit den in Tabelle 4.1 aufgelisteten Parametern durchgeführt. Dabei wurde die Menge des Netzwerkverkehrs, der während der Berechnung
simuliert werden sollte, über die Sendedauer2 reguliert.
1
Da die einzelnen Zeiten auf unterschiedlichen Hardwareplatformen gemessen wurden, können
nicht alle Tests untereinander verglichen werden
2
Die Zeit, in der ein Agent Pakete sendet
27
4. Auswertung
Abbildung 4.3.: Einfache Netzwerke mit 8 Knoten (Testnetze II und III)
Test
1
2
3
4
5
6
Agenten
256
256
200
200
200
200
Testnetz
I
I
II
II
III
III
Sendedauer
10s
50s
100s
400s
400s
400s
rLinks
ja
ja
nein
nein
ja
ja
rLink Kommunikation
ja
ja
nein
nein
nein
ja
Tabelle 4.1.: Parameter der Tests
Anzahl der
Instanzen
2 (PDNS)
2 (PDNS)
8 (PDNS)
Partitionierungsmethode
simple
fm
simple
Test 1
Test 2
38s
27s
137s
39s
Tabelle 4.2.: Testergebnisse für das Testnetz I
Die Zeitmessungen auf dem komplexen Testnetzwerk I in Tabelle 4.2 lassen folgende
Schlüsse zu:
1. In Test 1 ist zu erkennen, dass der Einsatz unterschiedlicher Partitionierungen einen deutlichen Geschwindigkeitsunterschied zur Folge hat. Die fmPartitionierung berücksichtigt sowohl die Knoten- als auch die Kantengewichte
und versucht, alle Instanzen gleichmäßig zu belasten.
28
4. Auswertung
2. Eine Erhöhung der Anzahl der PDNS-Instanzen kann laut Test 2 eine Verringerung der Laufzeit bewirken.
Anzahl der
Instanzen
1 (ns)
2 (PDNS)
4 (PDNS)
Partitionierungsmethode
simple
simple
Test 3
Test 4
Test 5
Test 6
32s
18s
12s
168s
81s
169s
105s
171s
185s
Tabelle 4.3.: Testergebnisse für die Testnetze II und III
Auf dem Netzwerk mit 8 Knoten (siehe Abbildung 4.3) wurden einige Extremfälle
getestet, um das Verhalten des PDNS in solchen speziellen Situationen zu bestimmen.
Die Messdaten, die mit diesem Netzwerk gewonnen wurden, unterstützen größtenteils die für das komplexe Netzwerk gewonnenen Erkenntnisse, zusätzlich kann aufgrund von diesen Ergebnissen noch festgestellt werden:
3. Bei diesem Netzwerk bewirkt die verteilte Simulation mit dem PDNS eine
deutliche Verkürzung der Gesamtsimulationsdauer. Die Simulationszeiten des
ns sind bei Test 3, Test 4 und Test 5 deutlich höher als die Zeiten der Simulationen mit dem PDNS.
4. Das Vorhandensein von Remote Links beeinflusst die Laufzeit der Simulation,
auch, wenn kein Netzwerkverkehr über die reale Verbindung simuliert werden
muss (siehe Test 5 ).
5. In Simulationen, bei denen zwischen den PDNS-Instanzen aufgrund von
ungünstig gewählten Partitionierungen sehr viel realer Netzwerkverkehr fließt,
kann die PDNS-Simulationsdauer durchaus die ns-Simulationsdauer überschreiten (siehe Test 6 ).
29
5. Zusammenfassung und Ausblick
Das in dieser Studienarbeit entwickelte Werkzeug PNDG kann sehr einfach eingesetzt werden, um große Netze zu partitionieren und damit effizient zu simulieren.
Allerdings gibt es dabei auch wichtige Einschränkungen, die es nicht möglich machen, beliebige Netzwerke ohne Modifikationen als Eingabe zu Nutzen. Das größte
Problem stellen die Fehler bzw. Einschränkungen im PDNS dar, die komplexe Partitionierungen mit intelligenten Algorithmen von Netzwerken mit unbekannter Topologie quasi unmöglich machen (siehe 4.1).
Allerdings haben die Messergebnisse in Kapitel 4 gezeigt, dass bei einer erfolgreichen
Partitionierung auf bestimmten Netzwerken eine deutliche Verringerung der Gesamtlaufzeit der Simulation zu erreichen ist. Außerdem hat der Vergleich zwischen einer
sehr einfachen und einer intelligenteren Partitionierung erkennen lassen, dass auch
hier noch Potential steckt, die Laufzeit zu verbessern. Durch neue Algorithmen ist
hierdurch möglicherweise eine noch größere Effizienzsteigerung zu erreichen.
Prinzipiell kann der PNDG jede Art von Netzwerken partitionieren und für eine
verteilte Simulation vorbereiten, wenn die Fehler im PDNS korrigiert worden sind.
Allerdings machen die statischen Bewertungen und Partitionierungen, mit denen
der PNDG arbeitet, nur bei statischen Netzwerken Sinn. Wenn ns-Funktionalitäten
genutzt werden, die Links dynamische verändern (z.B. bei der Simulation eines LinkAusfalls), kann der PNDG dieses Netzwerk nicht geeignet partitionieren und damit
auch keine effiziente Simulation durch den PDNS ermöglichen, da eine Anpassung
der PDNS-Beschreibungsdateien während der Simulation nicht möglich ist.
Einer der wichtigsten Punkte einer Weiterentwicklung des PNDG ist das Einpflegen
neuer Versionen des PDNS, damit die aufgeführten Probleme eine verteilte Simulation nicht sofort unmöglich machen.
Die eingeschränkte Syntax stellt kein schwerwiegendes Problem dar, da sie problemlos sukzessive ausgebaut werden kann, wenn ein für eine Simulation notwendiger
OTCL-Befehl noch nicht unterstützt wird.
Es scheint - besonders für sehr komplexe Netzwerke - sinnvoll, den PNDG automatisch zu konfigurieren und durch Scripte nach einer Partitionierung direkt die
Simulation durch den PDNS auszuführen, also im Endeffekt den PNDG nicht mehr
als eigenständiges Programm zu betreiben, sondern zusammen mit dem PDNS zu
einem verteilten Simulationstool zu kombinieren. Durch die Konfigurationsdatei als
Schnittstelle zum PNDG ist hierzu bereits der Grundstein gelegt.
30
A. Unterstützte OTCL-Befehle
Die zu dieser Studienarbeit durchgeführte Implementierung kann nur eine Auswahl
aller möglichen OTCL-Befehle interpretieren. Grundsätzlich werden keine Schleifenund Blockstrukturen verarbeitet.
Im Folgenden befindet sich eine Auflistung aller gültigen Sprachelemente. Diese reichen aus, viele Netzwerksimulationen zu beschreiben.
• set simulatorName [new Simulator]
Generierung eines neuen Simulators.
Werden in einer Beschreibungsdatei zwei Simulatoren erstellt, wird lediglich
der zweite bearbeitet. In diesem Fall können unvorhergesehene Probleme auftreten.
• set nodeName [$simulatorName node]
Generierung eines neuen Knotens
• set agentName [new Agent/AGENTTYPE]
Generierung eines Agenten
• set trafficName [new Application/Traffic/TRAFFICTYPE]
Generierung einer Traffic Source
• $linkName simplex-link $startNode $targetNode bandwidth delay queue
Generierung eines simplex-Links
z.B. $link0 simplex-link $node1 $node2 1.5Kb 120ms DropTail
• $linkName duplex-link $startNode $targetNode bandwidth delay queue
Generierung eines duplex-Links
z.B. $link0 duplex-link $node1 $node2 1.5Mb 10ms DropTail
• $simulatorName at time $trafficName start“
”
Starten einer Traffic Source
• $simulatorName at time $trafficName stop“
”
Stoppen einer Traffic Source
• $trafficName set packetSize packetSize
Setzen der Paketgröße für die Pakete, die diese Traffic Source sendet
31
A. Unterstützte OTCL-Befehle
• $trafficName set interval interval
Setzen der Frequenz, in der die Pakete von dieser Traffic Source gesendet
werden
• $simulatorName at endTime
$simulatorName at endTime
Beendet die Simulation
finish“
”
exit 0“
”
• $simulatorName connect $agent1Name $agent2Name
Mit diesem Befehl werden zwei Agenten verbunden
• $simulatorName attach-agent $nodeName $AgentName
Platzierung eines Agenten auf einen Knoten
• $trafficName attach-agent $agentName
Verbinden einer Traffic Source mit einem Agenten
• # comment line
Kommentarzeile
• puts string
Ausgabe. Der Text string wird auf den Bildschirm ausgegeben
• $simulatorName namtrace-all $namTraceFile
Tracing aller Ergebnisse
• set identifier [open fileName w]
Öffnen einer Datei zum Schreiben
• set identifier [clock seconds]
Die aktuelle Zeit wird in einer Variablen gespeichert. Dieser Befehl kann in
Verbindung mit puts eingesetzt werden, um Zeitmessungen durchzuführen.
Die letzen drei Befehle sind Spezialfälle, welche nicht vollständig unterstützt werden. Sie sind nur eingeführt worden, da diese Befehle regelmäßig in den ns-Dateien
vorkommen und deshalb beim Parsen keine Fehler erzeugen sollten.
Im Allgemeinen gilt, dass die Implementierung lediglich diese Befehle unterstützt.
Sollte der Parser beim Bearbeiten der Originaldatei ein unbekanntes Kommando
finden, bricht er die Bearbeitung mit einer Fehlermeldung ( PARSE ERROR“) ab.
”
32
B. Konfigurationsdatei-Einträge
Mit Hilfe der Konfigurationsdatei können Angaben für die resultierenden Beschreibungsdateien des PDNS gemacht werden. Außerdem besteht hiermit die Möglichkeit,
Bewertungen und Partitionierungen zu steuern und zu parametrisieren. Die Syntax
der Konfigurationsdatei lehnt sich an die OTCL-Syntax an, d.h. die Zuweisung eines
Wertes an eine Variable geschieht durch die Syntax:
set variablenName zuzuweisenderWert
Z.B. weist die Zeile
set number_of_tcl_files 16
der Variablen number of tcl files den Wert 16 zu.
Beginnt eine Zeile mit #, wird diese als Kommentarzeile angesehen und nicht bearbeitet. Sollte die Konfigurationsdatei ungültige Zeichen oder Befehle enthalten,
bricht die Verarbeitung ab und es wird eine Fehlermeldung ausgegeben.
33
C. Implementierte Funktionen
• int showStatistics()
Die Informationen, die diese Funktion liefert, sind hilfreich, um die Güte der
Partitionierung zu überprüfen. Sie gibt tabellarisch Auskunft über die in jeder PDNS-Datei enthaltene Knoten-, Link-, rLink- und Agentenanzahl und
summiert das Knotengewicht für jede Datei auf. Im besten Fall sollten die
Knotengewichte gleichmäßig verteilt und in jeder PDNS-Datei eine ähnlich
große Anzahl von Agenten vorhanden sein.
• int showInformation()
Mit Hilfe dieser Funktion können sehr detailliert Informationen angezeigt werden, die in den einzelnen internen Datenstrukturen gespeichert sind. Im einzelnen werden dargestellt:
– Alle Knoten, die darauf lokalisierten Agenten und alle Kanten, die an
diesem Knoten starten
– Alle Agenten, alle Traffic Sources zu diesen Agenten und die Agenten,
mit denen sie verbunden sind.
– Alle Traffic Sources mit Typ, Start-, Endzeit, Paketgröße, Intervall und
Agenten, mit denen sie verbunden sind
– Alle Links mit Start- und Endknoten, Bandbreite und Delay
– Der generierte Netzwerkgraph in einer Adjazenzdarstellung
• int createTCLFiles(nodeTargetsStruct nodePositions)
Diese Funktion führt einen wichtigen Schritt durch: Sie generiert die endgültigen PDNS-Beschreibungsdateien. Als Parameter erwartet sie eine Liste aller
Knoten mit deren PDNS-Dateinummern. Diese Liste wird bei der Partitionierung des Netzwerkgraphen erstellt.
Näheres zum Vorgehen dieser Funktion kann unter 2.4 nachgeschlagen werden.
• int startPartitioning()
Ein Netzwerkgraph kann mit verschiedenen Algorithmen bewertet und partitioniert werden. In dieser Funktion werden die Bewertungs- und Partitionierungsalgorithmen aufgrund der Einstellungen in der Konfigurationsdatei ausgeführt. Wichtig ist hierbei, dass nur genau ein Partitionierungsalgorithmus
34
C. Implementierte Funktionen
ausgeführt werden kann, jedoch beliebig viele Bewertungsalgorithmen. Sollten mehrere Partitionierungsalgorithmen aktiviert sein, wird nur einer durchgeführt und die restlichen Einstellungen ignoriert.
Nachdem die Bewertungen und die Partitionierung vorgenommen wurden, ruft
diese Funktion die createTCLFiles-Funktion mit den Daten auf, die sie aus der
Partitionierung erhalten hat.
• int createGraph()
Diese Funktion wurde eingesetzt, um das Programm soweit wie möglich unabhängig von einer Graph Library zu entwickeln. Falls von der GTL zu einer
anderen Implementierung gewechselt werden soll, ist an dieser Stelle die Initialisierung des Graphen durchzuführen.
• int createNode(string nodeName)
An dieser Stelle wird, aus denselben Gründen wie bei createGraph(), ein Knoten im Graphen angelegt. Da auf diesen Knoten später noch zugegriffen werden soll, wird sowohl in der Knotenliste ein Verweis auf den Graphen-Knoten
angelegt, als auch für die Gegenrichtung im Graph-Knoten ein Verweis auf
den Knoten in der Datenstruktur. Adressiert werden die Knoten über ihren
eindeutigen Namen.
• int createLink(node startNode, node endNode, string linkName)
siehe createNode()
• node findOutgoingLink(graph graphToSearch, node startNode, node
targetNode)
Um einem Knoten eine IP-Adresse zu geben, benötigt man den nächsten Knoten vom Startknoten auf dem Weg zum Zielknoten. Diese Information wird
von dieser Funktion geliefert.
• node findBorderNode(graph graphToSearch, nodeTargetsStruct
nodePositions, node startNode, node targetNode)
Zum Festlegen eines Routingknotens, der als letzter Knoten aus einer PDNSBeschreibungsdatei den Verkehr über einen rLink zu einer weiteren PDNSInstanz leitet, liefert diese Funktion einen Knoten zurück. Sie geht den Weg
vom Startknoten zum Zielknoten und liefert den Knoten zurück, der am Rand
eines Teilnetzes liegt.
• int assessLinks(string startNode, string targetNode, float
increaseValue)
Diese Hilfsfunktion wird von Gewichtungsfunktionen eingesetzt. Sie erhöht
jeden Link, der auf dem Weg vom Start- zum Zielknoten benutzt wird, um
den Wert increaseValue.
35
Literaturverzeichnis
[1] Network Simulator NS. http://www.isi.edu/nsnam/ns/, November 2001.
[2] Georgia Institute of Technology.
PDNS - Parallel/Distributed NS.
http://www.cc.gatech.edu/computing/compass/pdns/index.html, June 2001.
[3] Raitner Forster, Pick. Graph Template Library. http://www.infosun.fmi.unipassau.de/GTL/.
[4] Scannergenerator flex. http://www.gnu.org/software/flex/flex.html.
[5] Parsergenerator bison. http://www.gnu.org/software/bison/bison.html.
[6] James Demmel. CS 267 Applications of Parallel Computers Lecture 15: Graph
Partitioning - II. http://www.cs.berkeley.edu/∼demmel/cs267 Spr99, 1999.
[7] C.M Fiduccia and R. M. Mattheyses. A Linear Time Heuristic for Improving
Network Partitions. Proc. ACM/IEEE Design Automation Conf., pp. 175-181,
1982.
[8] Y. Wei and C. Cheng. Ratio cut partitioning for hierarchical designs. IEEE,
Transactions on Computer-Aided Design, 10:911–921, 1991.
36