Netzwerksimulation- und optimierung von verteilten Ereignisverarbeitungssystemen

Transkript

1 Netzwerksimulation- und optimierung von verteilten Ereignisverarbeitungssystemen Bachelorarbeit im Fach Informatik vorgelegt von Christoffer Löffler geb. in Nürnberg angefertigt am Department Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität Erlangen Nürnberg (Prof. Dr. M. Philippsen) Betreuer: Dipl.-Inf. Christopher Mutschler Prof. Dr. Michael Philippsen Beginn der Arbeit: 1. Juli 2012 Abgabe der Arbeit: 5. November 2012

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Bachelorarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den 5. November 2012 Christoffer Löffler

4

5 Bachelorarbeit Netzwerksimulation- und optimierung von verteilten Ereignisverarbeitungs- Thema: systemen Hintergrund: Die Gruppe Sensorfusion und Ereignisverarbeitung am Fraunhofer Institut für Integrierte Schaltungen in Nürnberg arbeitet an der Generierung und Verarbeitung von Positionsdatenströmen in Echtzeit. Basierend auf diesen Positionsdaten können zur Laufzeit Ereignisse detektiert werden. Aufgrund der hohen Datenrate von Lokalisierungssystemen sowie der hohen Anzahl an parallelen Datenströmen entstehen hohe Anforderungen an die Effizienz und Skalierbarkeit von Systemen zur Ereignisverarbeitung. Hierfür wurde am Fraunhofer IIS ein verteiltes System entwickelt, um Ereignisse errechnen zu können. Dabei bleibt es allerdings schwierig, implementierte Features zu validieren sowie Algorithmen richtig zu parametrisieren. Aufgabenstellung: Ziel der Arbeit ist es, sich in das vorhandene System zur Ereignisverarbeitung einzuarbeiten und anschließend eine Software-Komponente zu entwickeln, die es ermöglicht, verschiedene Knoten in einem beliebigem Netzwerk zu simulieren, auf denen jeweils Instanzen der Ereignisverarbeitung gestartet werden können. Hierbei gilt es auch zu recherchieren, inwieweit herkömmliche virtuelle Maschinen hierfür in Betracht kommen könnten. Mit Hilfe dieser Simulationsumgebung sollen beliebige Rechencluster und Latenzen etc. vorgegeben werden können und Vorgänge und Verarbeitungszweige verfolgt werden. Darauf aufbauend soll die Verteilung der Event-Detektoren auf die einzelnen Knotenpunkte optimiert werden. Da die Verarbeitung von Ereignissen unter Umständen auf drahtlosen Endgeräten (Smartphones etc.) stattfindet, sollte die genutzte Bandbreite so gering wie nötig ausfallen, sich zugleich die CPU Last jedoch nicht geballt auf einem einzelnen Gerät konzentrieren. Damit soll es ermöglicht werden, das System und dessen Konfiguration (evtl. sogar zur Laufzeit) gezielt zu optimieren. Meilensteine: Recherche zum Thema Netzwerksimulation und verteilter Ereignisverarbeitung Einarbeitung in die bestehenden Systeme am Fraunhofer IIS Implementierung der benötigten Software-Komponenten Implementierung eines geeigneten Optimierungsverfahrens für die Verteilung der Detektoren Evaluation des Verfahrens in Simulation und im realen System Ausarbeitung der Ergebnisse

6 Literatur: Sachs, K.: Performance Modeling and Benchmarking of Event-based Systems. PhD thesis, TU Darmstadt (2010). E. Asensio, J. Ordua, and P. Morillo; Analyzing the Network Traffic Requirements of Multiplayer Online Games", The Second Intl. Conf. Advanced Engineering Computing and Applications in Sciences, pp , G. Lakshmanan, Y. Rabinovich, and O. Etzion: A stratified approach for supporting high throughput event processing applications, Proc. Third ACM Intl. Conf. Distributed Event-Based Systems, pp. 5:1 5:12, 2009 Betreuung: Bearbeiter: Dipl.-Inf. Christopher Mutschler; Prof. Dr. Michael Philippsen Christoffer Löffler

7 Abstract In dieser Arbeit wird eine Netzwerksimulations-Komponente für das verteilte Ereignisverarbeitungssystem des Fraunhofer IIS sowie ein Netzwerk-Optimierungsmodul entwickelt. Somit kann die Lastverteilung anhand verschiedener Kriterien zur Laufzeit gezielt verbessert werden. Hierzu wird zuerst ein Überblick über die Möglichkeiten der Netzwerksimulation und Virtualisierung von Computernetzwerken gegeben, und anschließend eine Implementierung präsentiert. Es wird gezeigt, dass die Anforderungen, beliebige Netzwerktopologien zu generieren, erfüllt ist. Dazu wird das Netzwerk-Simulations- Framework ns-3 mit der Linux-Kernelkomponente LXC kombiniert. Im zweiten Teil wird die Komplexität des Optimierungsproblems analysiert sowie verschiedene Heuristiken zur Lösung und Umsetzung diskutiert. Abschließend zeigen synthetische Benchmarks, dass die Heuristiken die Netzwerk-last des Systems zur Laufzeit minimieren. i

8

9 Inhaltsverzeichnis 1 Einleitung Ziele der Arbeit Anforderungen Related Work Netzwerksimulation Optimierung Aufbau der Arbeit Grundlagen Event Processing Allgemein EventCore Netzwerksimulation Nodevirtualisierung Netzwerksimulation Maschinenschicht Netzwerkschicht Versuchsaufbau Übertragungskanal Switch Routing Optimierung Überblick Problembeschreibung Komplexität Lösungsansätze Genetic Algorithms Cuckoo Search Modified Cuckoo Search iii

10 Inhaltsverzeichnis Partikelschwarm Hybride Heuristiken Implementierung Darstellung Fitnessfunktion Integration und Evaluation NetMon, ein EventCore Modul Synthetische Benchmarks Vorauswahl Netzwerklast Zusammenfassung Danksagung Appendix A 49 iv

11 Abbildungsverzeichnis 1.1 Abhängigkeit zwischen Event-Detektoren Aufbau der Simulationsumgebung Versuchsaufbau: TAP-Bridge links, CSMA-Kanäle blau mittig, Switch rechts CSMA Helper richtet Objekte ein Simulator setzt Parameter zeitdiskret Modelle der Datenübertragung: API (links) und modifiziert (rechts) Modifizierter Code des Übertragungskanals Originale Multicastbehandlung Request for comment (RFC) 3376, Membership Report Message RFC 3376, Group Record Multicastgruppen: Snooping von IGMP V Multicastgruppen: Tabellenverwaltung Multicastgruppen: Forwarding anhand von Mitgliederlisten Abhängigkeitsgraph: PlayerHitsBall Beispiel: Kreuzung link, Mutation rechts Links: Ordinary Movement, rechts: Lévy Flight [37] Wahrscheinlichkeitsdichten der Normalverteilung und der Levy-Verteiltung. Positiver x-achsenabschnitt Abhängigkeit entsprechend Beispielmatrix N Gemeinsame Fitnessfunktion aller Heuristiken Secure Subscriptions über unsichere Kanäle Abhängigkeitsgraph: Versuchsanordnung des Parcours Benchmarks von CS/PSO links und H/PSO rechts Modified Cuckoo Search links, PSO rechts Genetic Algorithm und HPSO/PSO im Detail Alle Durchschnittswerte im Vergleich. Gruppengröße 4 links, 3 rechts Versuchsaufbau, Abhängigkeiten in Phasen unterteilt Statische und initiale Verteilung der Detektoren auf die EventCores Optimale Verteilung der Detektoren auf die EventCores Messungen des Netzwerkverkehrs in Byte pro Sekunde v

12 Abbildungsverzeichnis 7.1 Pseudocode CS/PSO nach [30] vi

13 Tabellenverzeichnis 4.1 Variablen der gemischt-ganzzahligen Programmierung Skalierung der Algorithmen bei größerem Problem: 6 EventCores und 36 Detektoren vii

14

15 Algorithmenverzeichnis 4.1 Einfacher genetischer Algorithmus Cuckoo Search-Algorithmus Partikelschwarm-Algorithmus [31] ix

16

17 1 Einleitung Die Gruppe Sensorfusion und Ereignisverarbeitung am Fraunhofer IIS in Nürnberg entwickelt ein verteiltes System zur Ereignisverarbeitung für Echtzeitlokalisierungssysteme. Es werden Positionsdatenströme vieler drahtloser Sensoren zur Laufzeit verarbeitet und daraus komplexe Ereignisse detektiert. Die dazu nötige Leistung, besonders bei weiterer Skalierung des Lokalisierungssystems, kann durch eine verteilte Architektur am besten gewährleistet werden. Zur Entwicklung und Validierung des Systems ist, bei fortschreitender Projektgröße und - komplexität, ein gutes Analysewerkzeug für verschiedenste Netzwerke eine Grundvoraussetzung. So soll eine Erweiterung des Berechnungsclusters auf Smartphones getestet werden können, mit dem Ziel, deren Potential zur Detektion auszuschöpfen. Die Last des verteilten Systems entsteht durch viele einzelne, abhängige Berechnungen und dem zu deren Kommunikation nötigen Netzwerkverkehrs. Um auch bei vielen heterogenen Computern in einem heterogenen Netzwerk eine optimale Lastverteilung zu erreichen, muss eine automatische Ressourcenaufteilung implementiert werden. PositionStream BallChangedDirection near IsN ear change P layerhitsball hit Abbildung 1.1: Abhängigkeit zwischen Event-Detektoren Die Abbildung 1.1 zeigt als Beispiel die drei Ereignisdetektoren IsNear, BallChanged- Direction und PlayerHitsBall sowie die Kommunikation, symbolisiert durch Position- Stream, near, change und hit und die gerichteten Kanten. Eine Verteilung beinhaltet die Zuordnung der Detektoren auf Rechner, sodass die Rechner nicht durch die Berechnungen überlastet werden, und die Kommunikation über das Netzwerk minimiert wird. Diese Minimierung könnte dadurch erreicht werden, dass kommunizierende Detektoren, 1

18 1 Einleitung beispielsweise IsNear und PlayerHitsBall, auf dem selben Rechner ausgeführt werden, wodurch keine Netzwerkübertragungen notwendig würden. 1.1 Ziele der Arbeit Das Ziel der Arbeit ist es einerseits, eine Softwarekomponente zu entwickeln, die beliebige Netzwerktopologien simulieren und analysieren kann. Darauf aufbauend soll das bestehende verteilte Echtzeit-Ereignisverarbeitungsystem dahingehend erweitert werden, dass die Verteilung der Ereignisdetektoren des Systems hinsichtlich mehrerer Kriterien automatisch optimiert wird. 1.2 Anforderungen Die primäre Anforderung an die Netzwerksimulationskomponente ist, dass sie echtzeitfähig sein muss. Des weiteren muss auf jedem Rechner das Ereignisverarbeitungssystem gestartet werden können. Es müssen drahtlose und kabelgebundene Verbindungen simuliert werden können und Multicast-Gruppen korrekt im Netzwerk geroutet werden. Außerdem muss es möglich sein, den Netzwerkverkehr detailliert statistisch auszuwerten, um das verteilte System effizienter Entwickeln, Testen und parametrisieren zu können. Die Anforderungen an die Optimierungserweiterung sind, dass die Rechenlast der Knoten gleichmäßig verteilt wird und dabei die Netzwerklast, die die Kommunikation der verteilten Berechnungen verursacht, möglichst gering bleibt. Darüber hinaus ist es ein Ziel, die Netzwerklatenz der Berechnungspfade zu minimieren, um die aus der Heterogenität der Netzwerktechnologien entstehenden Nachteile, wie die Überlastung von WLAN-Kanälen, zu vermeiden. 1.3 Related Work Zu beiden Aufgaben gibt es relevante Veröffentlichungen.Bei der Netzwerksimulation sind sie vor allem zur Entwicklung von Protokollen zu finden. Dort setzt man auf diskrete Simulatoren und native Codeintegration in den Simulator. Echtzeitfähige Simulatoren, die mit externer Software zusammen arbeiten, sind deutlich seltener. Zur Lastoptimierung finden sich mehrere Frameworks, die für verschiedene, spezielle Arten von verteilten Systemen anwendbar sind. Die groben Konzepte sind in dieser Arbeit zum Teil aufgegriffen worden. 2

19 1.3 Related Work Netzwerksimulation Bajaj et al. [22] beschreiben die Skalierbarkeit von GloMoSim (Global Mobile Information System Simulator), einem diskreten Netzwerksimulationstools der University of California in Los Angeles. Es existiert darüber hinaus eine Veröffentlichung, die die Echtzeitfähigkeit der Simulation Tausender mobiler Geräte untersucht und diese implementiert [44]. Die praktischen Ergebnisse sind jedoch nicht öffentlich zugänglich. Des weiteren ist GloMoSim nicht in der Lage hybride drahtlos/drahtgebundene Netzwerke zu simulieren. Christoph P. Mayer und Thomas Gamer [33] schlagen vor, Software-Quelltexte externer Programme entweder mit dem Simulationsframework OMNeT++ zu kompilieren, oder als Bibliotheken einzubinden. Für unsere Anfor- derungen ist diese Lösung aber unpraktikabel, da nicht von jeder verwendeten Software Quelltexte frei verfügbar sind. Kevin Fall [27] implementierte 1999 einen Echtzeitsimulator in das NS-1 Framework zur Netzwerksimulation. Mahrenholz et al. [32] verbesserten in NS-2 nochmals die interne Taktung des Schedulers und ermöglichten so die Simulation von WiFi (IEEE ). In dieser Bachelorarbeit wird die dritte Iteration des NS-Frameworks [36] verwendet. Es bietet neben der Echtzeitfähigkeit auch die Möglichkeit verschiedene Netzwerktechnologien in einem heterogenen Netz zu simulieren, Datenraten und Latenzen festzulegen, mit externer Software zu kommunizieren und detaillierte Netzwerkanalysen vorzunehmen. Außerdem ist es quelloffen und dadurch erweiterbar. Details hierzu werden in Kapitel 3 behandelt Optimierung Abdelwahed et al. [19] stellen ein Framework vor, das zur Laufzeit die Lastverteilung eines verteilten Systems anhand mehrerer Kriterien optimieren kann. Zwischen den regelmäßigen Optimierungen wird durch einen Kalman-Filter eine Vorhersage der Ressourcenverwendung der Rechenknoten erzeugt, um im Folgeschritt eine bessere Verteilung bestimmen zu können. Die Optimierung wird in einem zeitlich beschränkten Horizont vorgenommen. Es wird ein globales Modul verwendet, das durch lokale, auf den Rechenknoten befindliche Module unterstützt wird, die schneller auf Lastspitzen reagieren. Das Konzept der globalen Optimierung wird im Lauf dieser Bachelorarbeit ebenfalls angewendet. Da es sich aber um eine andere Art von Arbeitsteilung zwischen Rechnern handelt, kann kein zeitlicher Horizont von abzuarbeitenden Aufgaben nach einem zukünftigen Optimum abgesucht werden. Die Voraussage von Lastspitzen ist ebenfalls nicht Teil dieser Arbeit. Cheung et al. [24] veröffentlichten 2006 ihre Forschung zur Lastverteilung in Content- Based Publish/Subscribe Systemen. Sie stellten einen umfassenden Ansatz vor, der dynamisches Load-Balancing in der Form von Lastabschätzung und Umverteilungsalgorithmen beinhaltet. Statt globaler Optimierung wird im Fall der Überschreitung eines 3

20 1 Einleitung Last-Thresholds auf einem beteiligten Rechner ein Teil der Detektoren auf den besten alternativen Rechner migriert. Die verwendeten Kriterien sind Netzwerk-, CPU- und Speicher-Last. Das Augenmerk liegt hier auf der Lastverteilung in zusammenhängenden Clustern von wenigen Publishern und vielen Subscribern. Diese Bachelorarbeit unterscheidet sich dahingehend, dass sie als Ziel die Optimierung komplexere Abhängigkeiten hat, da Subscriber auch gleichzeitig Publisher sein können. Auch im Hinblick auf die Latenz der Netzwerkleitung an sich soll optimiert werden. Im Zielsystem können Publisher und Subscriber bei Bedarf auf dem selben Rechner ausgeführt werden. 1.4 Aufbau der Arbeit Im folgenden Kapitel 2 werden zuallererst die Wissesgrundlagen auf den Gebieten Ereignisverarbeitung, Netzwerksimulation und Systemvirtualisierung erklärt. Hierbei werden Alternativen bei Simulation und Virtualisierung diskutiert und Präferenzen für die nachfolgenden Kapitel vorgestellt. In Kapitel 3 werden die in den Grundlagen eingeführten Werkzeuge ns-3 und LXC kombiniert, wobei nötige Modifikationen an ns-3 im Detail ausgeführt werden. Kapitel 4 stellt globale Optimierungsstrategien und Implementierungsdetails vor. Es werden die in den Kapiteln 3 und 4 erarbeiteten Ergebnisse in 5. Kapitel evaluiert. Abschließend sind eine kurze Zusammenfassung und Ideen zu mögliche Verbesserungen zu finden. 4

21 2 Grundlagen Ziel dieses Kapitels ist es, die Grundlagen in den Bereichen der ereignis-basierten Datenverarbeitung, der Netzwerksimulation und der Systemvirtualisierung zu erläutern. Zu den letzten zwei Themenblöcken werden konkrete Implementierungen genannt und auf ihre Eignung für die Anforderungen dieser Arbeit geprüft. 2.1 Event Processing Das Event Processing (ereignis-basierte Datenverarbeitung) wird erst theoretisch gegenüber klassischen Interaktionsverfahren verteilter Softwaresysteme abgegrenzt. Anschließend wird das System des Fraunhofer IIS vorgestellt und die Optimierungsproblematik erklärt, auf die in Kapitel 4 genauer eingegangen wird Allgemein Ereignis-basierte Verarbeitung ist eine weit verbreitete Technik in der Informatik. Es eignet sich gut, um flexible, skalierbare Systeme mit autonomen, heterogenen Komponenten zu betreiben und zu erweitern. Die Anwendungsgebiete sind vielfältig. Von der automatischen Informationsverteilung über Netzwerkmonitoring in der IT-Sicherheit, und Module zur Softwareinteroperabilität bis hin zu mobilen und allgegenwärtigen Systemen und Sensornetzwerken [29]. Der Ansatz ist eine Lösung für das Problem beschränkter Skalierbarkeit und Flexibilität von klassischen Middlewares. Das Konzept der Middleware dient dazu, zwischen he- terogenen Systemen zu vermitteln. Bei wachsender Größe und Dynamik eines Systems ist eine enge Kopplung, wie sie Request/Reply Architekturen mit Polling aufweisen, aber ein großer Nachteil [29]. Die Lösung sollte asynchrone und entkoppelte Methoden bereitstellen. Statt dem mit Request/Reply verbundenen Polling ist ein autonomes Pushing erwünscht, das konzeptionell einem Publish/Subscribe entspricht. Die ereignis-basierte Verarbeitung bietet genau das. Die Komponenten, Ereignis-Detektoren genannt, kommunizieren untereinander über Benachrichtigungen, die signalisieren, dass ein Ereignis aufgetreten ist. Ist ein Detektor auf die Benachrichtigung angewiesen, so kann er sie abonnieren (subscribe). Die Middleware hat nun die Aufgabe, zwischen Produzent (producer) und Konsument (consumer) der Benachrichtigungen (Notifications) transparent zu vermitteln. Das heißt, ein Produzent hat keine Kenntnis über 5

22 2 Grundlagen seine Konsumenten, und evtl. umgekehrt, ganz im Gegensatz zum Pollingbetrieb [29] EventCore Das vom Fraunhofer IIS eingesetzte Ereignisverarbeitungssystem (Event Processing System) dient zur verteilten Auswertung des Positionsdatenstroms eines Realtime- Locating-Systems. Es werden pro Sekunde Tausende von Positionen verarbeitet, 144 drahtlose Sensoren übertragen 200 Positionen per Funk, manche sogar In der Summe sind es Positionen pro Sekunde. Ein Ziel ist es, bestimmte Interaktionen der Spieler in einem Fußballspiel, die mit solchen Sensoren ausgestattet sind, automatisch zu erkennen und so beispielsweise einem Reporter Analysen bereit zu stellen, oder auch weiche Kamerafahrten zu automatisieren. Hierfür müssen in Echtzeit Ereignisse berechnet werden [35, 34]. Die Middleware heißt EventCore. Die von den Event-Detektoren generierten Notifications werden Events genannt [35]. Die Events selbst sind komplex und auf der Basis von Abhängigkeitshierarchien generiert. Beispielsweise muss sich der Ball erst in der Nähe eines Spielers befinden, bevor der Schussdetektor seine Arbeit aufnimmt und weitere Berechnungen anstellt. Durch den Echtzeitanspruch und hierarchische Abhängigkeiten ergeben sich neue Probleme. Die Latenz des Netzwerks, das die EventCores verbindet, muss so gering wie möglich sein, da sich sonst die Verzögerungen durch die Hierarchie hinweg ausbreiten. Außerdem dürfen die Berechnungsknoten selbst nicht durch Detektoren überlastet werden, da so die Latenz bei der Eventgenerierung selbst steigt und es das komplette System lahm legen kann. [35] Außer dieser sog. event broker congestion (Ereignisknoten-Überlastung), bei der einzelne Knoten überlastet sind, kann es auch zur network congestion kommen. Wenn Bandbreite ein limitierender Faktor ist, steigt so ebenfalls die Latenz des Systems [29]. Der Zeitpunkt der Ereigniserkennung verschiebt sich nach hinten und sorgt für Probleme und Mehraufwand bei der Verwaltung der Reihenfolge der ankommenden Events. In einem homogenen Gigabit-Clusternetzwerk spielt vor allem die event broker congestion und die Latenzminimierung eine Rolle. Sobald aber beispielsweise Smartphones über Wireless LAN (WiFi) als Berechnungsknoten hinzu kommen, wird auch die Datenrate ein wichtiges Problem, bzw. sogar ein limitierender Faktor. 2.2 Netzwerksimulation Ein Ziel dieser Arbeit ist es, eine Lösung zur Netzwerksimulation zu erarbeiten. Es sollen beliebige Netzwerktopologien simuliert werden, mit beliebigen Datenraten und 6

23 2.2 Netzwerksimulation Latenzen, um das Ereigniserkennungs-System effizienter weiterentwickeln und testen zu können. Die angeschlossenen Rechner müssen in der Lage sein, Instanzen des EventCores zu starten. Auf dem Gebiet der Netzwerkvirtualisierung gibt es mehrere Bereiche, die auf ihre jeweiligen Anwendungsbereiche zugeschnitten sind. In (kommerziellen) Rechenzentren werden aus Effizienzgründen virtuelle Maschinen verwendet. Diese laufen meist auf einem starken Hostrechner und sind über eine Netzwerkbrücke mit dem externen Netzwerk verbunden. Eine sehr fortschrittliche Netzwerkbrücke für diesen Anwendungszweck ist der Open vswitch [9]. Allerdings ist das sog. Traffic Shaping, das verschiedene Routing- und Priorisierungsmöglichkeiten bezeichnet, für beliebige Netzwerktopologien mit beliebigen Latenzen nicht geeignet. Das Tool netem [5] der Linux Foundation bietet viele Features zur Manipulation der lokalen Netzwerkgeräte. Es kann künstliche Latenzen, doppelte, korrupte Pakete, und vertausche Reihenfolgen simulieren und auch die Datenrate kontrollieren. Die Topologie ist jedoch nicht beeinflussbar. Network Simulator 3 (ns-3) [36] ist ein diskreter Netzwerksimulator, der unter der GNU GPLv2 Lizenz veröffentlicht ist. Er kann in einem Echtzeit-Modus ausgeführt werden, und ist daher für diese Arbeit sehr interessant. Hauptsächlich wird er verwendet um Wi- Fi, Worldwide Interoperability for Microware Access (WiMAX) oder Long Term Evolution (LTE)-Netzwerke zu simulieren. Es gibt aber auch Module für Point-To-Point oder Carrier-Sense-Multiple-Access (CSMA) Verbindungen, von denen letztere dem klassischen Ethernet nahe kommt. Seine große Stärke ist beliebige Netzwerktopologien, Datenraten, Latenzen und sogar Bewegungsmodelle drahtloser Endgeräte zu simulieren. Darüber hinaus ist der Quellcode frei verfügbar und dadurch beliebig veränderbar, was sich im Laufe der Arbeit als deutlicher Vorteil erweisen wird. Außerdem gibt es eine ausführliche Dokumentation, inklusive Tutorial, und eine sehr aktive Community, die den Einstieg in das System erheblich erleichtert. Daneben ist eine Vielzahl gut dokumentierter Beispiele vorhanden [36]. Das Featureset beinhaltet neben der flexiblen Topologie und den Verbindungsmodellen auch die Fähigkeit, eine vollständige Abspeicherung der Pakete aller simulierten Verbindungen separat im Pcap-Format [13] anzulegen. Werkzeuge wie Wireshark [17] können Packet Capture-Dateien detailliert analysieren. ns-3 arbeitet auf den Schichten 1 und 2 des OSI-Modells [45], also beispielsweise auf der Ethernet-Ebene, und ist so transparent für höhere Protokolle wie IP und ICMP [36]. Im Echtzeit-Modus kann man virtuelle Maschinen an ein simuliertes ns-3-netzwerk anschließen. Deren Anzahl ist nur durch die Kapazität des Hostrechners begrenzt. Falls sie nicht ausreicht, dann kann man mit ns-3 über ein echtes Netzwerk mehrere Rechner zu einem großen Simulator zusammen schalten. Weitere Informationen zur Skalierbarkeit von ns-3 sind in [21] zu finden. 7

24 2 Grundlagen 2.3 Nodevirtualisierung Um jeder EventCore Instanz ein eigenes Netzwerkinterface, einen eigenen Prozessorkern oder CPU-Zeiten, eigene Shared Memory (SHM) Bereiche und sonstige Ressourcen zuzuweisen, liegt es nahe, eine bereits bestehende Virtualisierungslösung zusammen mit ns-3 zu verwenden. Es existieren mehrere Ansätze, die jeweils Vor- und Nachteile haben, und sich unterschiedlich gut zur Virtualisierung der EventCores eignen. Full Virtualization, auch Hardware Emulation genannt, erlaubt es, ein unmodifiziertes Betriebssystem zu verwenden. Es wird ein Hypervisor verwendet, der privilegierte Befehle on-the-fly übersetzt oder ausführt, was zu signifikanten Performanceverlussten führen kann[39]. Beispiele sind VMWare [15], OpenBox [10] und VirtualBox [14]. Eine Verbesserung in diesem Modus bieten Intel-VT und AMD-V, die es Betriebssystemen erlauben nativ auf der amd64 Architektur ausgeführt zu werden[39]. Es ist mit einigem Overhead zu rechnen, da jeder Gast u.a. einen eigenen Linuxkernel und Bibliotheken verwaltet. Paravirtualization hat den Vorteil, dass die Gastsysteme die Ausführung privilegierter Befehle mit dem Hypervisor abstimmen können, wodurch die Performance deutlich besser ist. Unmodifizierte Systeme können aber nicht verwendet werden. Xen arbeitet mit Paravirt [39]. Operating System-level Virtualization verfolgt einen anderen Ansatz. Hier isoliert das Hostsystem selbst die Gastsysteme. Dies erfolgt auch, indem sich Host und Gäste gemeinsam einen Kernel teilen. Das hat große Performance-Vorteile, da keine privilegierten Befehle abgepasst, und für die Hostarchitektur übersetzt werden müssen. Aber auch eklatante Nachteile bei der Stabilität und Sicherheit, falls z.b. der Kernel kompromittiert wird [39]. OpenVZ [11], LinuxVServer [6] und Linux Container (LXC) [12] sind hier konzeptionell einzuordnen, wobei LXC im Linuxkernel ausgeliefert wird, während die beiden anderen Kernelpatches sind, also nachträgliche Erweiterungen. Bei einem Performancevergleich der drei Ebenen, repräsentiert durch OpenVZ, Xen und VMWare, schnitt OpenVZ insgesamt besser ab als seine Konkurrenten [39]. Die Netzwerklatenz der Virtualisierung auf Betriebssytemebene war besonders gut, aber auch parallele Berechnungen liefen schneller als bei den anderen Techniken. Wegen der gleichen Implementierungsebene ist davon auszugehen, dass LXC ähnliche Performance aufweisen kann. Linux Containers befinden sich noch in der Entwicklung. Manche Features sind noch nicht vorhanden, etwa harte Begrenzungen des Arbeitsspeichers. Man kann aber das Dateisystem, abgesehen von /proc, vom Hostsystem abkapseln. LXC erlaubt auch die Zuweisung eines Prozessorkerns zur virtuellen Maschine. Sind nicht genug vorhanden, dann lassen sich auch die CPU-Cycles relativ zueinander unter den VMs aufteilen. Zur Ausführung eines EventCores sind also alle für diese Arbeit kritischen Ressourcen rationierbar. 8

25 3 Netzwerksimulation Die Netzwerksimulation mit ns-3 und Linux Containern hat wie eingangs bereits erwähnt viele Vorteile und besitzt Eigenschaften, die gut zu den Spezifikationsanforderungen passen. Das folgende Bild veranschaulicht die Konfiguration mit beliebig vielen LXC- Instanzen, die an einem ns-3 Netzwerk teilnehmen. LXC 0 LXC 1... LXC n Linux Bridge 0 Linux Bridge 1... Linux Bridge n Maschinenschicht TAP 0 TAP 1... TAP n TAP Bridge 0 TAP Bridge 1 TAP Bridge n ns-3 Netzwerktopologie Netzwerkschicht Abbildung 3.1: Aufbau der Simulationsumgebung Die obere Ebene besteht aus Linux Containern, die jeweils ein virtuelles Linuxsystem darstellen. Auf solch einem Host kann man lokal beliebige Anwendungen ausführen. Der untere Teil entspricht dem durch ns-3 simulierten Netz. Hier können verschiedenste Netzwerktopologien konfiguriert werden. In Kapitel wird eine Konfiguration 9

26 3 Netzwerksimulation von mehreren LXC-Instanzen vorgestellt, die mit einem zentralen Switch, über einem Ethernet ähnliche Leitungen, verbunden sind. Möglich sind aber auch WLAN-Netzwerke und gemischte Anbindungstypen. 3.1 Maschinenschicht Der Begriff Maschinenschicht fasst die Linux Container, die Linux-Bridges und die TAP-Devices zusammen. TAP-Devics sind simulierte OSI-Layer 2 Ethernetgeräte [45]. Hier wird der EventCore des Fraunhofer Instituts in einem Container ausgeführt. Der komplette Netzwerkverkehr wird im Container jeweils über eine herkömlich erscheinende, aber virtuelle Ethernetschnittstelle geleitet. In der Konfigurationsdatei des Containers wird eine Bridge spezifiziert. Zur Bridge wird neben der virtuellen Schnittstelle des Containers auch ein TAP-Device hinzugefügt. Jeder LXC ist also über eine virtuelle Ethernetschnittstelle mit einer Linuxbridge verbunden, die den Datenverkehr zu einem TAP-Device überbrückt. Die Netzwerkschicht, die für dieses Projekt das Programm ns-3 bezeichnet, verfügt über eigene Bridges, die TAP-Devices in die Topologie des Netzwerks einbinden [1]. 3.2 Netzwerkschicht ns-3 ist ein objektorientiertes, sehr modular aufgebautes, in C++ und Python geschriebenes Netzwerksimulationsframework. Die Konfiguration, die ein Netzwerk der Abbildung 3.1 entsprechend implementiert, soll im folgenden Kapitel erklärt werden. Zwei Modifikationen an ns-3 sind nötig, um es unter den gegebenen Anforderungen verwenden zu können. Einerseits muss ein passendes Modell eines Übertragungsmediums implementiert werden. Die Erklärung hierzu ist in Kapitel nachzulesen. Andererseits fehlt die Verwaltung von Multicastgruppen. Sie ist in Kapitel beschrieben und in ns-3 integriert worden Versuchsaufbau Der Versuchsaufbau basiert auf einem Beispielcode für ein CSMA-Netzwerk [8], der hierfür angepasst wurde. Andere Topologien als die vorgestellte sind durch die eingängige API einfach umzusetzen. Das Netzwerk mit einem zentralen Switch wurde als erste Implementierung gewählt, weil es den aktuellen Bedarf am besten bedient. 10

27 3.2 Netzwerkschicht TAP n Ghost Nodes NodeContainer switch* TAP-Bridge NetDevice Container CsmaChannel NetDevice Container Switch install install install TAP-Bridge Helper CSMA Helper Bridge Helper Abbildung 3.2: Versuchsaufbau: TAP-Bridge links, CSMA-Kanäle blau mittig, Switch rechts. Die Hauptkomponenten in Abbildung 3.2 sind die TAP-Bridge links, die CSMA-Kanäle in der Mitte und der Switch rechts. Die TAP-Bridge überbrückt die TAP-Devices des Betriebssystemhosts in das ns-3-netzwerk. Sie verbindet sie mit sog. Ghost Nodes, die jeweils eine Netzwerkschnittstelle, das NetDevice, besitzen. Die Ghost Nodes leiten Netzwerkverkehr nur weiter. Auf der rechten Seite ist der Switch zu sehen, der auch über NetDevices verfügt. Das Objekt NodeContainer switch* beinhaltet eine CSMA-Bridge, auf die im Kapitel noch näher eingegangen wird. Jeder Ghost Node ist durch sein NetDevice über einen CSMA-Kanal mit einem NetDevice des Switches verbunden. Es können beliebig viele Ghost Nodes über beliebig viele Kanäle mit dem Switch verbunden werden. Die diversen Helper übernehmen die Einrichtung der Objekte, wie in Abbildung 3.3 zu sehen. Über sie kann man Eigenschaften parametrisieren. Bei den CSMA-Kanälen ist es so einfach möglich eine Leitungsverzögerung und die Datenrate vorzugeben. Das CSMA-Modell ist im Kapitel thematisiert. CsmaHelper csma; NetDeviceContainer vmsdevices; NetDeviceContainer switchdevices; for (int i = 0; i < num_nodes; ++i) { // DataRate: The bitrate for packet transmission on connected devices; // Delay: The speed of light transmission delay for the channel in ms csma.setchannelattribute ("DataRate", DataRateValue ( )); csma.setchannelattribute ("Delay", TimeValue (MilliSeconds (10))); 11

28 3 Netzwerksimulation } NetDeviceContainer link = csma.install (NodeContainer (vms.get (i), csmaswitch)); vmsdevices.add (link.get (0)); switchdevices.add (link.get (1)); Abbildung 3.3: CSMA Helper richtet Objekte ein Die Datenrate und die Leitungsverzögerung (Delay) sind im Verlauf einer Simulation anpassbar. Über den Scheduler von ns-3 sind die meisten Parameter der Simulation parametrisierbar. Beispiele sind in Abbildung 3.4 zu sehen. // Das Delay wird nach 42 Sekunden fuer alle Channels auf 130ms gesetzt Simulator::Schedule (Seconds(42.0), Config::Set, "/ChannelList/*/$ns3::CsmaChannel/Delay", TimeValue (MilliSeconds(130.0))); // Die Datenrate wird nach 23 Sekunden fuer Channel 3 auf 100kbps gesetzt Simulator::Schedule (Seconds(23.0), Config::Set, "/ChannelList/3/$ns3::CsmaChannel/DataRate", StringValue (100kbps))); // Die Simulation wird nach 1337 Sekunden beendet Simulator::Stop (Seconds (1337.0)) Abbildung 3.4: Simulator setzt Parameter zeitdiskret Übertragungskanal ns-3 fehlt das Modell eines Full-Duplex Ethernet. Full-Duplex bedeutet, dass gleichzeitiges Senden und Empfangen möglich ist. Die im System vorhandenen Modelle blockieren vollständig, sobald ein Datenpaket versendet wird, für die Dauer des vorgegebenen Delays. Sie sind nur Half-Duplex, es kann immer nur ein Teilnehmer gleichzeitig senden. IDLE IDLE T RANS T RANS P ROP P ROP Abbildung 3.5: Modelle der Datenübertragung: API (links) und modifiziert (rechts) 12

29 3.2 Netzwerkschicht Das linke Petrinetz in Abbildung 3.5 entspricht dem Übertragungsverhalten des CSMA- Modells, wie es in der API-Dokumentation [7] beschrieben ist. Das Modell besteht aus drei Phasen. IDLE ist der Ruhezustand, wenn nichts übertragen wird. TRANS ist die Phase, in der die Daten vom Empfänger auf die Leitung geschickt werden. In der Ausbreitungsphase, PROP, bewegen sich die Informationen über die Leitung zum Empfänger. Ein Zyklus läuft wie folgt ab. Sobald Daten übergeben werden wird der IDLE-Zustand verlassen. Nach dem die Übertragung (TRANS, transmission) stattgefunden hat, werden keine neuen Pakete in IDLE akzeptiert, bis die Ausbreitung (PROP, propagation) abgeschlossen ist. Das rechte Petrinetz zeigt das Modell eines Kanals, dessen Durchsatz primär durch die Einspeißungsgeschwindigkeit im Einspeißungsschritt (TRANS) bestimmt wird. Die Propagation läuft asynchron. Wie es dem gewünschten Verhalten entspricht können sofort nachdem das Transmit abgeschlossen ist neue Übertragungen gestartet werden. Durch diese Anpassung sind größere Latenzen konfigurierbar, ohne dass das Übertragungsmedium blockiert wird. Die Anpassungen am Quellcode beinhalten eine Sperre, die die Zahl der verbundenen NetDevices auf zwei begrenzt. So können an dem einen Ende des virtuellen Kabels das NetDevices eines Linuxhostes, an dem anderen ein Switch angeschlossen werden. Es werden außerdem zwei Leitungen vom Typ des rechten Petrinetzes verwendet, um beiden angeschlossenen Geräten ein gleichzeitiges Senden zu ermöglichen. Dieses Verhalten ist in der Methode TransmitStart in Abbildung 3.6 implementiert. Der physikalische Leitungspuffer des Propagationschrittes ist bereits in ns-3 integriert. Er wird durch einen Callback simuliert, der um die Leitungslatenz zeitversetzt aufgerufen wird, wie in Abbildung 3.6 in der Methode TransmitEnd zu sehen ist. int32_t CsmaChannel::Attach (Ptr<CsmaNetDevice> device) { // Begrenzen der angeschlossenen NetDevices auf 2 NS_ASSERT ((int) m_devicelist.size( < 2); } bool CsmaChannel::TransmitStart (Ptr<Packet> p, uint32_t srcid) { // Bei Zugriff, Uebertragung abbrechen if (m_state[srcid]!= IDLE) return false; // Das Paket in die zur srcid gehoerenden Warteschlange schieben m_currentpkt[srcid].push_back(p); // Status auf Transmitting, blockieren neuer Transmits m_state[srcid] = TRANSMITTING;.. } bool CsmaChannel::TransmitEnd (uint32_t srcid){ std::vector<csmadevicerec>::iterator it; 13

30 3 Netzwerksimulation for (it = m_devicelist.begin (); it < m_devicelist.end (); it++) if (it->isactive ()) // Es wird der Empfang eingeplant. m_delay bringt hier // die Verzoegerung ein. Die Daten werden kopiert. Simulator::ScheduleWithContext (it->deviceptr->getnode ()->GetId (), m_delay, &CsmaNetDevice::Receive, it->deviceptr, m_currentpkt[srcid].back()->copy (), m_devicelist[m_currentsrc[srcid]].deviceptr); // Das Paket wird aus der Queue geloescht, es ist bereits kopiert m_currentpkt[srcid].pop_front(); // Durch das setzen auf IDLE kann das naechste Paket aufgegeben werden // ohne, dass der Versender die Auslieferung abwarten muss m_state[srcid] = IDLE;.. } Abbildung 3.6: Modifizierter Code des Übertragungskanals Switch Das zweite Problem war das Fehlen einer Multicastverwaltung in der Bridge, die die Links miteinander verbindet. Zum Empfangen der Events treten Detektoren des Fraunhofer Systems Multicastgruppen bei, die sich als technisches Äquivalent der Netzwerktechnik zum Publish/Subscribe anbieten. Ein Event Typ ist während seiner aktiven Präsenz im Netzwerk eindeutig einer Multicastgruppe zugeordnet. Die Abbildung von Event Typen auf Multicastgruppen ist surjektiv, da es mehr Typen als verfügbare Gruppen geben kann. Ist das Netzwerkpaket vom Typ Multicast, so wird es in der derzeitigen Implementierung von der Bridge als Broadcast weitergeleitet, wie in Abbildung 3.7 zu sehen. case PACKET_MULTICAST: case PACKET_BROADCAST: ForwardBroadcast (incomingport, packet, protocol, src48, dst48); Abbildung 3.7: Originale Multicastbehandlung Wie in der Einleitung zu diesem Kapitel erwähnt, muss der Simulator zwingend Multicastgruppen verwalten können. Im Zielsystem wird hierzu der Standard Internet Group Management Protocol (IGMP) V3 [4] verwendet. Es galt die Bridge um die nötigen Verwaltungsstrukturen zu erweitern und eingehende Pakete auf etwaige Relevanz zu überprüfen. Ein typisches, für den Zweck wichtiges IGMP V3 Paket besitzt den in den Abbildungen 14

31 3.2 Netzwerkschicht 3.8 und 3.9 dargestellten Inhalt Type = 0x22 Reserved Checksum Reserve4d Group Record (1)... Group Record (M) No. Group Records M Abbildung 3.8: Request for comment (RFC) 3376, Membership Report Message Record Type Aux Data Len Multicast Address Source Address (1)... Source Adress (N) Auxiliary Data No. Sources (N) Abbildung 3.9: RFC 3376, Group Record Der Typ 0x22 gibt beim Membership Report an, dass es sich um ein die Mitgliedschaft betreffendes Paket handelt. In den Group Records wird übertragen, ob der Absender einer Gruppe beitritt, oder ob er sie verlässt. Dort steht 0x4 für einen Beitritt, 0x3 für einen Austritt. Genauer gesagt bedeutet der Beitritt, dass ein Filter im Switch angelegt wird, der alle Pakete einer Quelle an die Multicastgruppe entweder an das Gruppenmitglied weiterleitet oder blockiert. Im realen System werden so Pakete Empfangen, die entweder alle Quellen einer Multicastgruppe abonnieren, oder keine. Also ist ein Beitritt ein Exclude; Sources: 0, alle zulassen, und ein Austritt Include; Sources: 0, alle blockieren. Diese Informationen genügen, um An- und Abmeldungen im simulierten Netzwerk korrekt zu simulieren, wenn dieses nicht zirkulär ist. Der IGMP Standard legt darüber hinaus noch weitere Verhaltensrichtlinien für Router und Teilnehmer fest, die für uns nicht von Relevanz sind. In diesem Kapitel wird der naive Ansatz implementiert. Das Auslesen des Pakets, das im buffer serialisiert vorliegt, geschieht durch den Code in Abbildung

32 3 Netzwerksimulation case PACKET_MULTICAST: //.. //0x46=IPv4, 0x2=IGMP, 0x22=Membership Report if (buffer[0] == 0x46 && buffer[9] == 0x2 && buffer[24] == 0x22) { // Anzahl der Group Records: int num = buffer[31]; for (int i = 0; i < num; i++) { // Eindeutiger Schluessel einer Multicastgruppe ip = buffer[36+(i*8)] << 24 buffer[37+(i*8)] << 16 buffer[38+(i*8)] << 8 buffer[39+(i*8)]; // Join, src48 wird zur Mitgliederliste von ip hinzugefuegt if (buffer[32+(i*8)] == 0x4) addtotable(src48, ip); // Leave, src48 wird ausgetragen else if (buffer[32+(i*8)] == 0x3) delfromtable(src48, ip); } } Abbildung 3.10: Multicastgruppen: Snooping von IGMP V3 Die Funktionen addtotable und delfromtable in Abbildung 3.11 fügen die Media Access Control (MAC)-Adressen des Abonnenten (src48) einem std::vector in einer std::map von MAC-Adressen-Gruppen (ip) hinzu, bzw. entfernen sie. Hierfür eignen sich Werkzeuge der C++ Standard Template Library (STL) hervorragend. void BridgeNetDevice::addToTable(Mac48Address src48, uint32_t ip) { std::vector<mac48address>::iterator iter = std::find(igmp[ip].begin(), igmp[ip].end(), src48); if (iter == igmp[ip].end()) igmp[ip].push_back(src48); } void BridgeNetDevice::delFromTable(Mac48Address src48, uint32_t ip) { // erase-remove idiom igmp[ip].erase(std::remove(igmp[ip].begin(), igmp[ip].end(), src48), igmp[ip].end()); } Abbildung 3.11: Multicastgruppen: Tabellenverwaltung Neben der Buchhaltung über Mitgliedschaften musste eine Weiterleitungsfunktion implementiert werden, die angelehnt an vorhandene Funktionen, Multicastpakete durch die Zielports des Switches versendet. Sie ist in Abbildung 3.12 dargestellt. Hierfür iteriert man über den Vector der MAC-Adressen der angemeldeten Empfänger und verwendet die bereits verfügbare Funktion von ns-3 zum Ermitteln der entsprechenden Ports am 16

33 3.2 Netzwerkschicht Switch. Das Versenden selbst ist lediglich ein Aufruf der Funktion des Ports, also des NetDevices, das an die Leitung des Linux Hosts angeschlossen ist, der Mitglied der Gruppe ist. void BridgeNetDevice::ForwardMulticast (Ptr<NetDevice> incomingport, Ptr<const Packet> packet, uint16_t protocol, Mac48Address src, uint32_t ip) { // Lernen der Zugehoerigkeit von MAC und internem Port des Switches Learn (src, incomingport); std::vector<mac48address> dst = gettable(ip); std::vector<mac48address>::iterator iter = dst.begin(); while (iter!= dst.end()) { // Erfragen des Ports zu einer MAC-Adresse Ptr<NetDevice> outport = GetLearnedState(*iter); if (outport!= NULL && outport!= incomingport) // Versenden des Pakets outport->sendfrom (packet->copy (), src, *iter, protocol); ++iter; } } Abbildung 3.12: Multicastgruppen: Forwarding anhand von Mitgliederlisten Die Funktion Learn(..) greift auf eine interne Datenstruktur zu, in der die Zuordnung von internem Port des Switches und der MAC-Adresse des Korrespondenzhosts abgelegt ist. Die Datenstruktur wird bei Erstkontakt zwischen Switch und Hosts aufgebaut und ist als Vorwissen des Frameworks zu betrachten Routing Die vergleichsweise einfache Sterntopologie des in diesem Kapitel vorgestellten Beispiels erfordert nur die wenigen, vorgestellten Modifikationen am ns-3 Quelltext. Komplexere Netzwerke, die auch zirkuläre Verbindungen beinhalten, erfordern hingegen intelligentes Routing. Naive Implementierungen, wie die in diesem Kapitel, können zur Überflutung des Netzwerks führen. Zu den möglichen Lösungen für dieses Problem zählt die Protokollfamilie des Protocol Independent Multicast (PIM)-Routing [3] speziell für Multicastverkehr, sowie der Open Shortest Path First (OSPF)-Standard [2] für allgemeines IP-Routing. Beim PIM-Sparse-Mode (PIM-SM) Protokoll empfängt beispielsweise ein Switch, der sog. Rendezvous Point, alle Pakete einer Multicastgruppe und leitet sie per Unicast an Empfänger weiter. Die verschiedenen Unterarten des PIM-Routing eignen sich für bestimmte Topologien besser, für manche schlechter. Die konkrete Wahl einer Implementierung ist damit abhängig von der zu simulierenden Topologie. 17

34 3 Netzwerksimulation Beim OSPF-Standard werden in allen Routern Tabellen über kürzeste Pfade zwischen Endpunkten im Netzwerk vorgehalten und bei Änderungen aktualisiert. Dabei entstehen garantiert keine zirkulären Wege, dafür aber Aufwand bei der Verwaltung und Berechnung von unter Umständen großen Tabellen. Für das ns-3 Framework ist ein auf OSPF basierender Algorithmus für IP-Pakete verfügbar, aber noch kein dynamisches Multicast-Routing. Die Integration solcher Standards kann bei Bedarf durch das Einfügen virtueller Maschinen mit spezieller Routingsoftware vorgenommen werden. Sie dienen dann anstelle von Bridge-Modulen des Frameworks als Switch. Die Softwareplatform XORP [18] bietet beispielsweise OSPF, PIM und weitere Routingprotokolle, läuft unter Linux und ist quelloffen. In den folgenden Kapiteln sind auch die Modifikationen an ns-3 beschrieben, die man für nicht zirkuläre Netzwerke vornehmen muss. 18

35 4 Optimierung Mit dem Wort Optimierung ist in diesem Kapitel der Vorgang bezeichnet, bei dem eine optimale Verteilung der Event-Detektoren auf die Rechner im Netzwerk berechnet wird. Dies ist erforderlich, da suboptimale Verteilungen im Extremfall, bei Überlastung der Prozessoren der Rechenknoten oder der Netzwerkkapazität, die Ergebnisse der Berechnungen nutzlos machen. Abgesehen von der Vorbeugung von Worst-Case-Szenarien kann durch eine gute Arbeitsteilung auch die Effizienz des Systems verbessert werden. Datenabhängigkeiten unter den Detektoren benötigen, wegen der Echtzeitanforderung des Systems, möglichst geringe Latenzen bei der Berechnung und Auslieferung von Ergebnissen. Kommen Ereignis- Notifications zu spät bei einem Detektor an, dann steigt der interne Verwaltungsaufwand. Werden zwei abhängige Detektoren auf dem selben Rechner ausgeführt, dann können die Event-Notifications lokal übertragen werden, und brauchen nicht über das Netzwerk verschickt zu werden. Eine Überlastung des Netzwerks und der Prozessoren ist also zu vermeiden und die Latenzen zwischen den abhängigen Detektoren zu minimieren. 4.1 Überblick Konkret muss ein Optimierungsalgorithmus auf Basis der folgenden Informationen arbeiten: Die maximale Anzahl der Eventdetektoren pro Gerät, um die Überlastung des Prozessors zu vermeiden, die Anzahl der versendeten Events, die die Netzwerklast repräsentieren, und die Netzwerklatenz der Geräte. Die Wahrscheinlichkeit der zu erkennenden Events des Fraunhofer Ortungssystems sind nicht vorhersagbar, also a-priori unbekannt. Ein Ereignis ist beispielsweise, dass ein Fußballspieler gegen einen Ball tritt und ein Tor schießt. Wenn die Positionsströme des Fußballers, des Balls und des Tors in der richtigen Reihenfolge Werte liefern, die nah genug aneinander liegen, werden Events generiert und verschickt. Diese Erkenntnis ist wichtig für die Wahl des Berechnungszeitpunktes. Am sinnvollsten ist hier ein stetiges Beobachten und neu Verteilen, da sich unvorhersehbar Lastverteilungen und Latenzen verändern können. 19

36 4 Optimierung Andere Szenarien ermöglichen durch a-priori-wissen der Auftrittswahrscheinlichkeiten stattdessen einmalig eine optimale Verteilung zu ermitteln. So einen planbasierten Algorithmus stellen zum Beispiel Akdere et al. vor [20]. 4.2 Problembeschreibung Die Abhängigkeiten der Event-Detektoren untereinander entsprechen einem gerichteten Graphen, der in speziellen Fällen auch Schleifen beinhalten kann. Es erreichen mehrere Zehntausend Positionen pro Sekunde die Detektoren, die auf der zum Event gehörenden Multicastadresse lauschen. Diese Detektoren bestimmen jeweils auf der Datengrundlage, ob ihr zu veröffentlichendes Ereignis aufgetreten ist oder nicht. Falls ja, dann senden sie selbst ein Paket (Event) ins Netzwerk. PositionStream BallChangedDirection IsN ear change near P layerhitsball Abbildung 4.1: Abhängigkeitsgraph: PlayerHitsBall Teil der Aufgabe ist, die Detektoren basierend auf ihren Abhängigkeiten so zu gruppieren, dass möglichst wenige Pakete außerhalb der Gruppen verschickt werden. Dabei ist die Gruppengröße gut zu wählen, um keine Überlastung einzelner Knotenpunkte zu verursachen, wodurch die Latenz stiege. Am Beispiel in Abbildung 4.1 sind mögliche Gruppen bei einer Gruppengröße von 2 als Ziel zu sehen. Neben den drei bunten gibt es theoretisch auch noch die Möglichkeit jeden Detektor auf einem eigenen Knoten laufen zu lassen, oder alle auf einem einzigen Knoten. Beim ersten Fall wäre der Grund eine extrem hohe CPU-Auslastung durch jeden Detektor, beim zweiten Fall eine geringe zugunsten minimalen Latenzen und 20