, den Ort Datum Unterschrift des Autors

Transkript

1 i Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig ohne unzulässige fremde Hilfe angefertigt habe. Die verwendeten Quellen und Hilfsmittel sind vollständig zitiert., den Ort Datum Unterschrift des Autors

2 Inhaltsverzeichnis 1 Einleitung Beschreibung der Aufgabenstellung Vorgehensweise Einführungen Einführung in Grids Definition des Begriffs Grid Die Geschichte des Grid Die Open Grid Service Architecrure (OGSA) Virtual Organisation (VO) Grid Services Zusammenfassung und Aussichten Wireless Grid Einführung in Wireless Grids Ansatz von wirelessgrids.net Wireless Grid Szenarien Projekte ii

3 iii 4 Material und Software Verwendete Geräte Anwendungsszenario Anforderungen des Szenarios Bewertung der ähnlichen Projekte Prüfung der vorhandenen Gridsoftware Legion Cactus Access Grid Grid Bus Globus Toolkit Sicherheit - Grid Security Infrarstructure (GSI) GridFTP Reliable File Transfer (RFT) Informatmion Service (MDS) Replica Location Service (RLS) Umsetzung Beschreibung des Document Sharing Service Erster Entwurf Vorschlag für die Umsetzung Sicherheit - GSI Virtuelles Verzeichnis

4 iv Transfer - GridFTP Grafisches Interface Analyse Performance Messungen Was soll gemessen werden? Messablauf Umsetzung mit den EDG - Tools Umsetzung von DSS Erweiterungen Zusammenfassung Ausblicke Literaturverzeichnis 83 A Unterlagen 86 A.1 Messergebnisse A.2 Working Paper zur Bewerbung zur 4th IFIP A.3 Cdrom mit Quellen zur Diplomarbeit und der Diplomarbeit in digitaler Form

5 Vorwort Gridcomputing ist spätestens seit 1 oder distributed.net 2 in aller Munde, zwei Projekten, die die Leerlaufzeit (ungenutzte Ressourcen) auf einem beliebigen Rechner zur verteilten Berechnung wissenschaftlicher Projekte nutzen. Dieses Verfahren spiegelt das Ziel eines Grids gut wieder: Verschiedene Ressourcen aller Art sollen gemeinsam genutzt werden um für den Benutzer als eine virtuelle Maschine verfügbar zu sein. Im Internet können viele Forschungsprojekte gefunden werden, die sich mit Gridcomputing befassen, in Zeitschriften kann gelesen werden, dass Grid kommt [8] und einige Entwickler beschreiben sogar Szenarien, in denen das Grid allgegenwärtig sein wird [19]. Es werden schon Parallelen zwischen der rasanten Entwicklung, die das Internet hinter sich gebracht hat und der Entwicklung, die das Grid nehmen wird, gezogen. Heute ist das Internet ein wichtiger Bestandteil der Gesellschaft zum Informationsaustausch und diese Stellung wurde in weniger als 10 Jahren erreicht - vom Forschernetz zum Massenmedium. Das Grid soll vielmehr werden. Es soll die gemeinsame Nutzung von Ressourcen aller Art ermöglichen: Von der Bedienung der Kaffeemaschine über die Ausrichtung von Teleskopen bis zu der Nutzung von Massenspeichern und dies alles unter der Berücksichtigung von Sicherheit, Vertrauenswürdigkeit und Konsistenz, um nur einige Fähigkeiten aufzuzählen. Erreicht werden soll dies über eine einfache, standardisierte Architektur, der Open Grid Service Architecture (OGSA): Einfach, v

6 VORWORT vi weil so das Internet erfolgreich wurde. Da es nicht möglich ist in einer Diplomarbeit das ganze Potential von Gridcomputing zu untersuchen, soll sich diese Diplomarbeit auf ein Teilgebiet, das sich noch in den Kinderschuhen der Entwicklung befindet, konzentrieren: das Wireless Grid! Hierbei handelt es sich um die Nutzung der Grid Technik in drahtlosen Netzen mit mobilen Geräten. Mit einem Wireless Grid soll die Möglichkeiten der Nutzbarkeit der mobilen Geräte noch erweitert werden. Z.B. wäre es denkbar, dass ein Handy, dass mit einem Wireless Grid verbunden ist, die Rechenkraft eines Supercomputers zur Verfügung steht. Aber das sind noch Zukunftsvisionen. Dieses Diplomarbeit soll anhand eines Szenarios untersuchen, inwieweit mit heutiger Technik ein Wireless Grid aufgebaut werden kann: Stellen Sie sich vor, Sie sitzen in einer Besprechung. Jeder der Teilnehmer hat einen Laptop und jeder der Teilnehmer hat Dokumente, die er den anderen zukommen lassen will. Was tun? Über die Anwendung, die in dieser Ausarbeitung vorgestellt wird, ist dies ohne Problme möglich. Sobald man über ein Wireless LAN verbunden ist, wird automatisch ein Virtual Directory aufgebaut. In dieses virtuellen Verzeichnis werden alle Daten, die von den Mitgliedern verteilt werden sollen, integriert. Es entsteht der Eindruck, das alle Daten lokal zur Verfügung stehen und es wird ermöglicht, auch so mit den Daten zu arbeiten.

7 Kapitel 1 Einleitung In diesem Kapitel wird die Aufgabe beschrieben und die Vorgehensweise dargestellt. 1.1 Beschreibung der Aufgabenstellung Das Grid wurde anfänglich für rechenintensive Aufgaben konzipiert. Es sollte möglich sein eine heterogene Computerinfrarstruktur zusammen zu schalten, um Ressourcen, wie z.b. Datenspeicherplatz und CPU - Ressourcen, on demand zur Verfügung zu stellen. Durch die Entwicklung von Standards wie der Open Grids Service Architectur (siehe Abschnitt 2.2) und der damit verbundenen Einführung eines Service orientierten Ansatzes, ist das Grid nicht mehr nur ein Lieferant von Rechenkraft, sondern vielmehr eine verteilte Umgebung, die gemeinsames Arbeiten ermöglicht: a distributed environment for collaborative work. Das Grid ist also eine interessante Umgebung, um neue Anwendungen zu entwickeln und alte zu verbessern. Das Grid soll es möglich machen, einem Benutzer jederzeit, überall und unabhängig von einer Plattform und einem Provider einen interaktiven Arbeitsraum zur Verfügung zu stellen, der die Zusammenarbeit mit Mitarbeitern und Kollegen unterstützt. Eine sogenannte Virtual Organisation soll 1

8 EINLEITUNG 2 einen gemeinsamen virtuellen Arbeitsraum erlauben, der sogar über die Grenzen von Organisationen ausgedehnt werden kann, ohne dabei die Sicherheitsrichtlinien zu verletzen. Die Idee des Wireless Grid geht noch einen Schritt weiter. Die Ansätze des verkabelten Grid, eine kollaborative Arbeitsumgebung zu schaffen, sollen noch durch die Möglichkeit, dies alles mobil abzuwickeln, erweitert werden. Ad hoc sollen Arbeitsgruppen gebildet werden können, neue Anwendungen und Anwendungsmöglichkeiten (siehe Abschnitt 3.2) geschaffen werden. An diesem Punkt setzt diese Diplomarbeit an. Ziel dieser Arbeit ist es, ein einfaches Anwendungsszenario für ein Wireless Grid zu entwickeln, zu prüfen, ob es umsetzbar ist und schließlich, anhand vorhandener Gridsoftware, dieses auch umzusetzen. Dabei sollen zuerst theoretische Grundlagen geschaffen werden, sowohl für das herkömmliche, verkabelte Grid, als auch für das Wireless Grid. Abgrenzung der Fragestellung Diese Diplomarbeit soll als Anfang einer Reihe von Arbeiten mit dem Thema: Collaborative Working with Grids 1 dienen, die mit ihren einzelnen Anwendungen zum Ziel haben sollen, eine kollaborative Gridumgebung zu schaffen. Die Umsetzung des Szenarios soll aber keine fertige Software ergeben. Vielmehr wird geprüft werden müssen, ob es mit der heutigen Technik des Grid schon möglich ist, ein Wireless Grid aufzubauen. Begründung der Eignung der Thematik Das Thema eignet sich hervorragend für eine Diplomarbeit, besonders im Hinblick auf den Fachbereich Computer Networking. Die Forschung der neuesten Generation der Grids steckt noch in den Kinderschuhen. Deswegen existieren wenige oder teilweise keine Lösungen für eine Fragestellung. Dadurch ergibt sich eine breite 1 Der Name dieser Reihe von Arbeiten existiert so nicht, gibt aber den Sinn in kurzen Worten wieder

9 EINLEITUNG 3 Palette von Möglichkeiten, das gesteckte Ziel zu erreichen und aktiv an einer weltweiten Forschungsarbeit teilzunehmen. 1.2 Vorgehensweise Das Thema Gridcomputing war zu Beginn dieser Diplomarbeit neu für mich. Ich hatte zwar schon davon gehört, wusste aber eigentlich gar nichts darüber. Deswegen bestand der Anfang dieser Arbeit darin, mich in das Thema einzulesen und die nötigen Grundlagen für einen praktische Umsetzung zu schaffen. Es war von Anfang an klar, dass die Informationsquelle mit dem höchsten Stellenwert das Internet darstellt, da Gridcomputing ein aktuelles Forschungsgebiet ist und hauptsächlich von der Opensource - Gemeinde vorangetrieben wird. Über Google 2 und deren auf Universitäten spezialisierte Suchmaschine Google - Scholar 3 wurde ich schnell fündig. Des weiteren informierte ich mich, ob es in Computerzeitschriften interessante Artikel zum Thema Gridcomputing gab. Ein Heft [8, Titelblatt] glaute ich gefunden zu haben, doch bei näherer Betrachtung beschäftigte sich dieses Heft mit den falschen Themenbereichen. Als die nötigen Grundlagen geschaffen waren, begann ich, mich Wireless Grids zu beschäftigen und stellte die ersten Unterschiede zu einem herkömmlichen Grid fest. Auf der Suche nach Informationsquellen führte mich wiederum Google, aber auch Links von den Informationsmedien über normale Grids zu einem Ergebnis. Ich folgte vor allem der Fragestellungen: Was ist der Unterschied zu herkömmlichen Grids? und Wie weit ist die Forschung auf diesem Gebiet?, wollte also die Anforderungen des Wireless Grid herausfinden und bekannte Projekte identifizieren. Nach dieser Einarbeitungszeit folgte der praktische Teil. Ich arbeitete ein Szenario aus, das sinnvoll und zugleich wenig komplex für den Einsatz in einem Wireless Grid ist. Ich definierte Anforderungen, wählte nach diesen die Gridsoftware aus und setzte das Szenario mit den von der

10 EINLEITUNG 4 Software gegebenen Mitteln um. Damit war die Aufgabe erfüllt. Es stellte sich aber heraus, dass die Umsetzung mit den von der Software bereitgestellten Tools zwar funktionierte, der Einsatz aber aus Performancengründen nicht sinnvoll gewesen wäre. Also erarbeitete ich ein Konzept zu einem Service, der, mit wenigen Abstrichen, den Anforderungen an ein Wireless Grid gerecht wird.

11 Kapitel 2 Einführungen In diesem Kapitel wird zu dem Begriff Grid hingeführt. 2.1 Einführung in Grids Wie im Vorwort bereits erwähnt, ist Gridcomputing durch die beiden Projekte SE- TI@Home 1 und distributed.net 2 in der Öffentlichkeit bekannt geworden. Durch die rasante Entwicklung der Prozessoren im Bezug auf die Leistungsfähigkeit und Preis (immer schnellere Prozessoren werden immer preisgünstiger), gibt es immer mehr Computer, die üppig ausgestattet sind. Die Rechner werden nur für das Surfen im Internet,den Empfang un das Versenden von s oder für die Textverarbeitung verwendet. Dadurch sind die meisten Prozessoren nicht einmal ansatzweise ausgelastet; es existieren also ungenutzte Prozessor - Ressourcen. Die beiden Projekte nutzen diese ungebrauchten Prozessor - Ressourcen, um sie für komplexe Berechnungen einzusetzen. Benutzer, die einen Computer besitzen, können sich ein Programm herunterladen, einen sogenannten Client, und diesen installieren. Die Clients holen sich von den Servern der Projekte Aufgaben, die sie berechnen

12 EINFÜHRUNGEN IN GRIDS 6 müssen. Für die Berechnungen werden dabei nur die Leerlaufzeiten der Prozessoren genutzt. Surft der Benutzer z.b. im Internet, hat er nur einen Browser geöffnet. Dies belastet seinen aktuellen Prozessor jedoch nur minimal, unterstellen wir zu 5 Prozent 3. Der Client kann nun also, ohne den Benutzer bei seiner Tätigkeit zu stören, 95 Prozent der Rechenzeit des Prozessors nutzen. Genutzt wird diese Rechenzeit, um Aufgaben, die von den Servern der Projekte automatisch abgeholt werden, zu berechnen. Anschließend werden die berechneten Aufgaben wieder an die Server gesandt, um dort zusammengesetzt werden. Durch das Aufteilen einer umfangreichen Aufgabe in Teilaufgaben und der Nutzung so vieler Ressourcen, entsteht ein gewaltiger virtueller Computer, der schneller ist als der schnellste Computer der Welt; The most powerful computer, IBM s ASCI White, is rated at 12 TeraFLOPS and costs $110 million. SETIhome currently gets about 15 Tera- FLOPs and has cost $500K so far. [2] Diese Rechenleistung setzt SETI@Home ein, um das SETI (The Search for Extraterrestrial Intelligence) Radio Projekt [25] zu unterstützen, das Funksignale aus dem All abfängt. Mit SETI@Home werden diese dann entschlüsselt. Ziel des Projektes ist es, Nachrichten aus entfernten Galaxien zu finden, um somit Leben auf anderen Planeten nachzuweisen. Distributed.net stellt Berechnungen für diverse Forschungsprojekte in öffentlichem Interesse an. Beide Projekte bieten Clients an, die auf den einzelnen Rechnern installiert werden. Ein Projekt ganz anderer Art ist das European DataGrid 4. Es beschäftigt sich nicht mit den Ressourcen von Heimanwendern, sondern vielmehr mit der Zusammenschaltung wissenschaftlicher Einrichtungen. Gegründet von der Europäischen Union hat es zum Ziel, ein rechen- und datenintensives Ressourcennetzwerk (Grid) zu schaffen, um Daten wissenschaftlicher Projekte zu verarbeiten. Das Projekt will eine technologische Infrastruktur entwickeln und testen, die es ermöglicht, an wis- 3 Diese Zahl ist frei erfunden und beruht auf keinen Messungen; die Unterstellung dient lediglich als Hilfsangabe, um das Beispiel erkl ären zu k önnen 4

13 EINFÜHRUNGEN IN GRIDS 7 senschaftlichen Projekten, unabhängig vom Aufenthaltsort der Projektmitglieder, gemeinsam zu arbeiten und zu forschen. Jedes Mitglied soll den gleichen Zugriff auf Geräte und Daten haben. Auf dieses Projekt aufbauend wurde 2004 das Enabling Grids for E-science (EGEE) Projekt gegründet, das grundsätzlich die gleichen Ziele hat: Unabhängig vom Aufenthaltsort der Mitglieder eines Projektes sollen allen die gleichen Möglichkeiten haben. Grids sollen es also ermöglichen, Ressourcen aller Art, unabhängig vom Ort, zu teilen. Dieses Prinzip ist wohl bekannt. An jedem Aufenthaltsort kann man, sofern eine physische Schnittstelle vorhanden ist, Strom beziehen. Zwischen elektrischen Grids und Computer Grids 5 gibt es einige Gemeinsamkeiten (siehe [32]). Das Stromnetz eines Landes bietet zum Beispiel überall einheitliche Stromspannung, gleich ob der Strom aus Kohle, Gas, Atomenergie, Wind oder Sonne gewonnen wurde. In Grids kann die Leistung von Workstations, Laptops, Rechenzentren oder Clustern produziert werden, der Endanwender merkt davon nichts, er bekommt nur Rechenleistung zur Verfügung gestellt. Auch der Aufbau der Netzwerke ähnelt sich. Ein Stromnetz der Energieunternehmen unterhält große Überlandleitungen, dazu ein lokales Netz in den einzelnen Ortschaften und das Stromnetz in den Häusern. In einem Grid gibt es das Internet, Wide Area Networks (WAN) und Local Area Networks (LAN) Definition des Begriffs Grid Es wurde beschrieben, wofür Grids eingesetzt werden und was Grids leisten sollten. Doch ab wann ist eine Anwendung ein Grid? Diese Frage stellte sich auch Ian Foster, einer der vorantreibenden Kräfte und der bekanntesten Entwickler der Grid Welt: If by deploying a scheduler on my local area network I create a Cluster Grid, then doesn t my Network File System deployment over that same network provide 5 An dieser Stelle sind die Grids, die Rechenleistung und Datenspeicherplatz liefern, gemeint, die sog. Computational Power Grids

14 EINFÜHRUNGEN IN GRIDS 8 me with a Storag Grid? Indeed, isn t my workstation, coupling as it does processor, memory, disk, and network card, a PC Grid? Is there any computer system that isn t a Grid? [22, S.1] Deswegen erstellte er eine Three-Point-Checklist, aus der hervorgeht, wann ein Grid die Bezeichnung Grid tragen kann. Nach Foster sollte ein Grid nach den Anwendungen, dem Business Value und den wissenschaftlichen Ergebnissen, die es liefert, bewertet werden und nicht nach dessen Architektur. Foster ist an vielen Standardwerken, die das Grid beschreiben, beteiligt. Die Definitionen wurden weiterentwickelt. In [20] wurde ein Grid noch als eine Hard- und Softwareinfrastruktur bezeichnet, die zuverlässigen, konsistenten, überall vorhandenen und billigen Zugang zu high-end computational capabilities bereitstellt. In The Anatomy of the Grid [21], einem weiteren Standardwerk für Grids, in dem das erste Mal eine Standardarchitektur definiert wurde, wird von einem Grid gesprochen, dessen Schlüsselkonzept es sein sollte, verschiedenen Parteien, die Ressourcen sharen, zu einer Gruppierung zu verbinden und den daraus entstandenen Ressourcenpool für einen bestimmten Zweck zu nutzen. Diese Gruppierungen werden Virtual Organisations (siehe Abschnitt 2.2.1) genannt: The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problem- solving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals andor institutions defined by such sharing rules form what we call a virtual organization.

15 EINFÜHRUNGEN IN GRIDS 9 Diese Definitionen werden von Foster in der oben erwähnten Checkliste zusammengefasst. Ein Grid ist ein System, das 1. Ressourcen, die nicht zentral kontrolliert werden, koordiniert. Ein Grid integriert und koordiniert Ressourcen und Benutzer verschiedener Kontroll - Domains und befasst sich mit Problemen, wie z.b. Sicherheit, Richtlinien, Bezahlung und Mitgliedschaften, die sich aus den Einstellungen ergeben. Andernfalls handelt es sich um ein lokales Managementsystem; 2. standardisierte und offene Mehrzweckprotokolle und -schnittstellen benutzt. Ein Grid wird auf Basis von Vielzweckprotokollen und - schnittstellen, die sich mit grundsätzlichen Dingen, wie Authentifikation, Resource Discovery und dem Zugang zu Ressourcen befassen, erstellt. Diese Protokolle und Schnittstellen sollten standardisiert und offen sein. Andernfalls handelt es sich um ein anwendungsspezifisches System. 3. einen nicht trivialen Quality of Service liefert. Ein Grid ermöglicht das koordinierte Nutzen der einzelne Ressourcen. Damit wird ein Quality of Service z.b. in Bezug auf die Antwortzeit, den Durchsatz, die Verfügbarkeit und die Sicherheit erreicht, so dass das Zusammenwirken im Verbund effektiver ist, als das alleinige Arbeiten der einzelnen Komponenten. Ganz besonderen Wert legt Foster auf die Offenheit und die Standards, auf denen die Protokolle und Schnittstellen beruhen sollten. Das sei der Unterschied von einem Grid zu dem Grid ( The Grid 6 ), einem weltumspannenden Grid, in dem jeder mit jedem die Möglichkeit zu sharen hat. 6 So wird die Vision genannt, die eine Entwicklung der Grid - Technik, wie die des Internet, erwarten.

16 EINFÜHRUNGEN IN GRIDS Die Geschichte des Grid Die Geschichte des Grid kann in drei Phasen [18] aufgeteilt werden: Die erste Generation, die als Vorgänger der heutigen Grids bezeichnet werden. Die zweite Generation, die sich auf Middleware konzentrierte, um große Datenmengen und rechenintensive Aufgaben verarbeiten zu können. Und die dritte Generation, deren Hauptmerkmale die Schaffung einer globalen, verteilten Kollaborationsumgebung und ein Serviceorientierter Ansatz sind [18]. Die erste Generation: Das erste Mal, dass ein Projekt als Grid - Projekt bezeichnet werden konnte, war der Versuch, Supercomputerzentren miteinander zu verbinden; es wurde als Metacomputing bezeichnet. Der Name Grid tauchte dann erstmals 1989 im CASA Projekt auf, das eines von vielen US Gigabit Testumgebungen war. Larry Smarr, NCSA Direktor, machte diesen Ausdruck schließlich populär. Anfang der 1990er kamen dann Metacomputing und Gridumgebungen auf, deren Ziel es war, bestimmte Ressourcen einer großen Zahl von High Performance Anwendungen bereitzustellen. FAFNER und I-WAY sind Beispiele solcher Techniken. Obwohl die beiden Projekte verschieden Ziele verfolgten - FAFNER war für den Gebrauch auf einfachen Workstationen konzipiert, wobei I-WAY die Ressourcen von Supercomputerzentren verbinden sollte - hatten sie doch einige Ziele gemeinsam: die Kommunikation,das Ressourcenmanagement und die Manipulation entfernter Daten sollte tatsächlich und wirksam ablaufen. Die zweite Generation: Der Schwerpunkt der ersten Generation der Grids lag auf der Verbindung von Supercomputerzentren. In der weiteren Entwicklung reichte es allerdings nicht aus, nur einige spezialisierte Ressourcen zu verknüpfen. Das Ziel war es, die Ressour-

17 EINFÜHRUNGEN IN GRIDS 11 cen einer heterogenen Computerlandschaft, die mit der Zeit entstand, zu nutzen. Möglich wurde dies durch das Aufkommen von Breitbandnetzwerken und der Einführung von Standards. Das Grid wurde nun neu als eine verteilte Infrastruktur gesehen, die auch die Durchführung von Anwendungen, die große Rechenleistungen und Datenmengen benötigten, ohne den Einsatz von Supercomputer, möglich machte. Diese Vision des Grids wurde im Juli 1998 in dem Artikel The Grid: Blueprint for a New Computing Infrarstructure [20] unter anderem von Ian Foster, einem der bedeutendsten Entwickler eines standardisierten Grids, veröffentlicht. Es gab hauptsächlich drei Problemstellungen, die man gegenüberstellen musste: Heterogenität: ein Grid besteht aus vielen heterogenen Ressourcen, die sich global und über mehrere verschiedene Administrationsdomänen verteilen können. Skalierbarkeit: ein Grid kann von wenigen Ressourcen auf Millionen anwachsen. Dabei muss auf die Performance geachtet werden, die von den teilnehmenden Ressourcen abhängt und stark schwanken kann. Es wird also eine Fehlertoleranz benötigt. Mit dem anwachsen eines Grids wächst auch das Sicherheitsrisiko. Methoden müssen entwickelt werden, die auch die Authentifizierung über die Grenzen einer Domain hinweg ermöglichen und auch vertrauenswürdig ist. Anpassungsfähigkeit: Ein Fehler bei einer Ressource ist die Regel nicht die Ausnahme. So ist die Möglichkeit, dass eine Ressource in einem Grid verschwindet, h hoch und es müssen Verfahren entwickelt werden, dieses Fehlverhalten zu korrigieren. Die zweite Generation des Grid will eine einheitliche, homogene Anwendungslandschaft für den Entwickler und Anwender schaffen. Um die zugrunde liegenden, heterogenen Ressourcen soll sich niemand kümmern müssen. Die Ressourcen können entweder direkt über Standardschnittstellen oder über standardisier-

18 EINFÜHRUNGEN IN GRIDS 12 te Services angesprochen werden. Beispiele für diese Phase finden wir in einer Vielzahl von Anwendungen. Zwei davon sollen hier kurz vorgestellt werden. Das Globus Toolkit 7 in einer frühen Entwicklungsphase, stellt eine Softwareinfrastruktur bereit, die es Anwendungen ermöglicht, eine Vielzahl verteilter, heterogener Ressourcen als eine virtuelle Maschine zu benutzen. Die geographische Lage der Ressourcen oder der geographische Ort des Anwenders spielt dabei keine Rolle. Ein zentrales Element in diesem Projekt nimmt das Globus Toolkit ein, das auch später für den Testaufbau verwendet wird. Es definiert ein festes Set von Services und Interfaces, wie Security, Ressource Location, Ressource Management und Kommunikation, mit denen ein computational Grid aufgebaut werden kann. Das Toolkit unterstützt ein großes Feld von Applikationen, da es nicht eine starres Programmiermodel vorgibt, sondern Services anbietet, die jeder Entwickler von bestimmten Tools nach eigenen Bedürfnissen verwenden kann. Die Voraussetzung dafür ist eine konsequente und wohldefinierte Interfacestruktur. Legion 8, das in der Universität von Virginia entwickelt wurde, stellt eine Softwareumgebung dergestalt bereit, dass ein System von heterogenen, geographisch verteilten, High Performance Maschinen nahtlos miteinander arbeiten können. Legion will Anwendern an ihren Workstations eine einfache integrierte Struktur anbieten, ungeachtet des Aufenthaltsortes, der Programmiersprache oder des zugrunde liegenden Betriebssystems. Der große Unterschied zum Globus Projekt besteht im Ansatz, wie eine Grid Umgebung erreicht werden kann: In der Legion Umgebung sind alle Komponenten Objekte, womit natürlich alle Vor- aber auch die Nachteile der objektorientierten Welt verbunden sind. In dieser Zeit wurden auch große Projekte gestartet, die die bereitgestellten Techniken zur Anwendung brachten, wie zum Beispiel das DataGrid Projekt der europäischen Union. Ziel ist es ein rechen- und datenintensives Grid bereitzustellen, das von wissenschaftlichen Forschungsprojekten genutzt werden kann. DataGrid, wie auch ein weiteres Beispiel, CACTUS 9, basiert auf legion/ 9

19 EINFÜHRUNGEN IN GRIDS 13 dem Globus Toolkit. CACTUS ist eine Opensource Umgebung, die Probleme von Wissenschaftlern lösen soll. Es kann viele rechenintensive Applikationen parallel auf verteilten Ressourcen ablaufen lassen. Auch und ditributed.net sind der zweiten Generation zuzuordnen. Zu Beginn der zweiten Generation war es das Ziel der Projekte, eine Umgebung für rechenintensive High Performance Applikationen bereit zu stellen. Dieses änderte sich aber im Laufe der Zeit zu einer allgemeineren und offeneren Entwicklung. Während dieser Phase entwickelten sich weitere Middleware Techniken, die die Entwicklung des Grid beeinflussten, wie zum Beispiel Distributed Object -, Peer-to-Peer und Ressource Broker System. Die dritte Generation: In der weiteren Entwicklung der Gridtechnik wurden andere Gesichtspunkte wichtig. Antatt immer wieder neue Gridapplikationen zu schreiben, war es unerlässlich, alte Strukturen wieder zu verwenden und diese flexibel in neue Anwendungen einzuflechten. Die angewandten Lösungen verstärkten den Einbau von Service Orientierten Modellen und Metadaten, zwei wichtigen Gesichtspunkten der dritten Generation des Grids (siehe Abschnitt 2.2.2). Bis zu diesem Zeitpunkt wurde das Grid immer mit Daten- und rechenintensiven Anwendungen und Supercomputerzentren in Verbindung gebracht, doch mit der dritten Generation tauchten neue Begriffe, wie distributed collaboration und Virtual Organisation auf. Der Sinn eines Grid wurde dadurch von virtuellen Rechenmaschinen zu Kollaborationsumgebungen umgewandelt, zu Umgebungen, die ideal für den Einsatz z.b. im Unternehmensbereich sind. Die dritte Generation des Grids zeichnet sich durch eine starke Automatisierung der Abläufe aus. Benutzer können z.b. nicht mehr die Skalierbarkeit und die Heterogenität beeinflussen oder verändern, sondern übergeben diese Aufgabe an Prozesse. Dies setzt wiederum voraus, dass Prozesse gut programmiert und definiert sind. Durch die vorhin erwähnte hohe Auswahlmöglichkeit einer Ressource und der Automatisierung der Ressourcenverteilung, ist es nicht länger not-

20 EINFÜHRUNGEN IN GRIDS 14 wendig, Fehler manuell beheben zu müssen. Daher muss eine automatische und autonome Fehlerbehebung, ähnlich wie in biologischen Systemen und dem Nervensystem, vorhanden sein. Diese Ansätze versucht das Open Grid Forum 10 mit der Open Grid Service Architechture (siehe 2.2 auf Seite 15) umzusetzen. Vergleich mit dem World Wide Web Der heutige Stand des Grid ist mit dem des Web vor einigen Jahren zu vergleichen (nach [18]): es wird nur wenig entwickelt, aber diese Entwicklung wird von einigen enthusiastischen Wissenschaftlern und Communities vorangetrieben. Es existieren Standards und ein aufkommendes Interesse der Wirtschaft zu verzeichnen. Das Web bietet heute eine Mensch zu Maschine (HTML) und eine Maschine zu Maschine (XML) Kommunikation an, genau das, was das Grid als Infrastruktur braucht. Betrachtet man sich diese Ausgangssituation, scheint es, dass das Grid den gleichen schnellen Weg wie das Web gehen wird. Aber es müssen auch die Unterschiede beachtet werden. Während eine Gridapplikation eine große Anzahl von koordinierten Prozessen benötigt, kommt eine Transaktion im Web mit einer kleinen Anzahl von Hosts (z.b.. Server, Cache, Browser) aus. Beachtet man die technischen Anforderungen, die ein großes verteiltes System stellt, folgt daraus, dass das Web dafür nicht geeignet ist, Web Services aber eine annähernde Möglichkeit darstellen. Wir haben festgestellt, dass das Web dem Grid eine Infrastruktur bietet. Was aber bietet das Grid dem Web. Als eine Webapplikation eröffnet es neue Möglichkeiten, die zu Weiterentwicklung von Web Services führen kann, was wiederum, da das Grid Services nutzt, dieses voranbringt. Das Grid stellt weiterhin eine Infrastruktur für Webanwendungen bereit, wie zum Beispiel Recherche, Data Mining, Übersetzung und Multimedia - Anwendungen. 10

21 EINFÜHRUNGEN IN GRIDS Die Open Grid Service Architecrure (OGSA) Die OGSA [24] bietet, aufbauend auf Technologien und Konzepten der Grid und Web Communities, eine Architektur, die eine einheitlich, offene Service Semantik (Grid Service) bereitstellt, einen Standardmechanismus zur Erstellung, Namensgebung und Durchsuchung verschiedener Grid Service Instanzen definiert, Ortstranzparenz und multiple Protokoll Bindungen für Service Instanzen bietet und die Integration von unterhalb liegenden Plattform unterstützt. Außerdem definiert die OGSA, mit Hilfe der Web Services Discription Language (WSDL) Interfaces und damit verbundenen Vorgaben, Mechanismen zur Erstellung von verteilten Systemen. Darin enthalten sind Lifetime Management, Change Management und Notification. Wenn nötig können Services auch vertrauenswürdige Aufrufe, Authentifikation, Authorisation und Delegation unterstützen Virtual Organisation (VO) Ein großes Problem, das dem Grid Konzept unterliegt, ist ein koordiniertes Ressourcensharing in einer dynamischen, über Organisationsgrenzen hinweg verteilten Virtual Organisation [24, S.2]. Das hier erwähnte Ressourcen Sharing ist nicht nur ein einfacher Datei Transfer sondern vielmehr ein direkter Zugriff auf Computer, Daten, Software und allen Ressourcen, die zur Verfügung stehen und von collaborativen, problemlösenden Strategien aus Wissenschaft und Industrie gebraucht werden. Das Sharen der Ressourcen wird notwendigerweise stark kontrolliert, indem die Ressourcenanbieter und -verbraucher klar definieren können, was geteilt

22 EINFÜHRUNGEN IN GRIDS 16 werden soll und wer darauf zugreifen darf. Eine Gruppe, die aus Personen und / oder Institutionen besteht und von solchen Regeln definiert wurde, ist eine Virtual Organisation [24, S.2]. Folgende Beispiele sollen den Begriff Virtual Organisation veranschaulichen: Die Application Service Provider, Storage Service Providers, Cycle Providers und Berater, die ein Unternehmen bei der Planung und der Durchführung des Baus einer neuen Fabrik unterstützen sollen, bilden eine VO. Sie sollen gemeinsam ein Problem lösen und sind von den Ergebnissen oder Ressourcen der jeweils anderen abhängig. Ein Krisenmanagement Team, die Datenbanken und Simulationssysteme, die benutzt werden, um einen Plan zu entwickeln, wie auf eine bestimmte Situation zu reagieren ist, bilden eine VO. Verschiedene Wissenschaftler aus der ganzen Welt, die an dem gleichen Projekt arbeiten und ihre Gerätschaften, Ergebnisse und Computer teilen, bilden ein VO. In Kopenhagen steht z.b.. ein Instrument, das es nur dort gibt, und von einem Wissenschaftler aus New York benötigt wird. Er kann es, weil er in der VO ist, von New York aus benutzen, ohne erst nach Kopenhagen fliegen zu müssen. Diese Beispiele aus ganz veschiedenen Teilen von Forschung und Wirtschaft sollen zeigen, wie VOs sich in Dauer, Nutzen, Größe, Ziel, Struktur, und Art der Mitglieder unterscheiden, gleichzeitig aber auch Vieles gemeinsam haben. Alle bestehen aus Mitgliedern mit unterschiedlichen Berechtigungen, die, um eine Aufgabe zu lösen, verteilte Ressourcen nutzen wollen. Und sie wollen direkten Zugang zu diesen Ressourcen. Daraus ergibt sich ein breites Spektrum von Anforderungen. Es müssen flexible Beziehungen, die von Client - Server bis zu Peer-to-Peer Systemen reichen, gemanagte werden. Mit der heutigen Technik im Internet alleine ist diese Aufgabe in ihrer Gesamtheit nicht zu lösen. Es können Teilprobleme, wie z.b.

23 EINFÜHRUNGEN IN GRIDS 17 der Zugriff auf das vorhin erwähnte Instrument, mit einer beliebigen Anwendung gelöst werden, aber für das Data-sharing wäre wieder eine andere Anwendung nötig. Ein weiteres Problem wäre die Authentifikation. Es müsste eine von der lokalen Sicherheitsumgebung getrennte Authorisationsumgebung verwaltet werden, damit die lokalen Sicherheitsrichtlinien nicht umgangen werden können. Die heutige Technik stellt also keine gesamte, komplette Umgebung bereit, sondern nur vereinzelte Insellösungen. Mit der OGSA und damit dem Grid könnten diese Probleme gelöst werden. Die Layer der OGSA Ziel der OGSA ist es, eine Struktur bereitzustellen, die eine generelle Beschreibung der Komponenten bereithält und nicht die genaue Implementation von APIs und Interfaces vorgibt. Durch diese Struktur werden die einzelnen Komponenten auf Ebenen, sog. Layer, verteilt. Komponenten auf einer Ebene haben ähnliche Charakteristiken und können die Eigenschaften und Merkmale von Komponenten der darunter liegend Ebenen nutzen. Um eine effektive Struktur umsetzen zu können, sind wenige effektive Protokolle, wie z.b. im Internet (vgl. TCP und HTTP im Internet) sinnvoll. In der OGSA sind diese in der zweiten (Connectivity Layer) und dritten Schicht (Resource Layer) angesiedelt und nutzen die einzelnen Ressourcen der ersten Schicht (Fabric Layer). Sie bilden das Grundgerüst eines Grids. Der Collective Layer (vierte Ebene) ermöglicht die Nutzung vieler Ressourcen als eine Ganze. Fabric Layer: Interface zu Lokalen Kontrollmechanismen. Der Fabric Layer stellt die Ressourcen, auf die zugegriffen werden kann, zur Verfügung. Ressourcen sind zum Beispiel Speichersysteme, Rechensysteme, Kataloge, Netzwerkressourcen und Sensoren. Die Fabric Layer Komponenten stellen die Funktionalität, die das lokale

24 EINFÜHRUNGEN IN GRIDS 18 System anbietet, in der verteilten Umgebung bereit. Es existiert also eine Beziehung zwischen den Fähigkeiten, die lokal zur Verfügung stehen und der der Fabric Layer Komponente. Einerseits ergibt eine größere Funktionalität der Fabric Komponente bessere Sharing Eigenschaften; Weniger Anforderungen an die Komponente auf der anderen Seite schafft eine leichtere und besser Administration des Grids. Es hat sich herausgestellt, dass Ressourcen Funktionen bereitstellen sollten, die es verbieten, die Struktur, den Status und die Möglichkeiten zu erfahren aber Ressource Management zur Bereitstellung von Quality of Service zuzulassen. Connectivity Layer: Einfache und sichere Kommunikation. Dieser Layer definiert grundsätzliche Protokolle zur Kommunikation und deren Sicherheit bei grid-spezifischen Transaktionen. Die Kommunikation ermöglicht den Datenaustausch zwischen Fabric Layer Komponenten, die Sicherheit dieser, durch Verschlüsselung und Verifizierung der Benutzer und Ressourcen. Die Abbildung 2.1: Die Layer des OGSA Kommunikation wird, obwohl es alternativen gibt, über den TCP/IP Protokoll Stack umgesetzt, denn dieser bringt alle Anforderungen ( Transport, Routing, Naming) mit sich. Die Sicherheitsmechanismen sollten auf offenen, bereits bestehenden und sicheren Standards aufsetzen, um höchste Sicherheit zu gewährleisten. Folgende Anforderung bringt das Grid mit sich: Single Sign on, Delegation, Integration in verschiedenen lokalen Sicherheitsmechanismen und benutzerbasierte Vertrauensbeziehungen.

25 EINFÜHRUNGEN IN GRIDS 19 Resource Layer: Einzelne Ressourcen sharen. Der Resource Layer benutzt die Protokolle des Conectivity Layers, um Protokolle für eine sichere Initiierung, Kontrolle, Authentifikation und Monitoring bei Sharing Operation auf einzelnen Ressourcen zu definieren. Die Implementationen des Resource Layers rufen Funktionen des Fabric Layers auf, um lokale Ressourcen zu kontrollieren. Der Resource Layer ist ausschließlich für die einzelnen Ressourcen zuständig und somit nicht für globale Transaktionen verantwortlich. Collective Layer: Koordination mehrerer Ressourcen. Während der Resource Layer für die einzelnen Ressourcen verantwortlich ist, kümmert sich der Collective Layer um globale Aspekte. Ein weitere großer Unterschied zum Resource Layer liegt darin, dass die Protokolle im Resource Layer generell eingesetzt werden müssen, wohingegen im Collective Layer generelle aber auch stark an Applikationen angepasste, spezialisierte Protokolle existieren können. Der Collective Layer beschreibt Protokolle und Services, die es ermöglichen, mehrere Ressourcen als eine benutzen zu können. Wie schon erwähnt basiert der Collective Layer auf dem Resource - und dem Connectivity Layer - diese beiden Layer bilden das Grundgerüst des Grids - und kann dadurch eine Vielzahl von Services bereitstellen, ohne neue Anforderungen an die zu sharende Ressource zu stellen. Beispiele hierfür sind Directory Services, Co-allocation Scheduling oder Software Discovery Services. Funktionen im Collective Layer können als persistente Services mit Bindungen zu Protokollen oder als SDKs, die Bindungen zu APIs haben, entworfen werden, um von Applikationen benutzt werden zu können.

26 EINFÜHRUNGEN IN GRIDS 20 Application Layer: Die oberste Ebene in der OGSA ist der Application Layer, der die Applikationen beinhaltet. Applikationen sind in diesem Kontext nicht als Endanwender - Programme zu verstehen, sondern eher als hoch entwickelte Frameworks oder Bibliotheken, wie z.b. Common Component Architechture, SciRun, CORBA und Cactus. Diese Frameworks können eigene Protokolle, APIs oder Service definieren. Die OGSA soll ja nur eine einheitliche Kommunikationsplatttform für ein Grid beschreiben, nicht mehr und nicht weniger Grid Services Bisher wurde beschrieben, wie ein Grid die Ressourcen behandelt und wie mit den Ressourcen umgegangen wird, also welche Ressourcen geshared werden und wer darauf Zugriff hat. Die Benutzer jedoch wollen in der Regel nicht direkt die Ressourcen nutzen, sondern einen Anwendung, die einen Dienst bereitstellt, der die Ressourcen transparent nutzt. Deshalb wird in der OGSA eine Service orientierte Verfahrensweise [23] eingeführt. Jede Komponente im Grid, sei es eine Ressource, ein Programm, ein Netzwerk oder eine Datenbank ist ein Service. Um diese Services zu nutzen, bedarf es zweier Mechanismen: Zum einen die Definition einer Schnittstelle zu diesem Service, um auf ihn zugreifen zu können und zum anderen ein Protokoll, das benutzt werden kann, um die Schnittstellen aufzurufen. Um auch eine komplette Umgebung bieten zu können, müssen die Schnittstellen nach einem Standard definiert werden. Standards ermöglichen die einfache Erweiterbarkeit einer Anwendung, da jeder Service nach der gleichen Art aufgerufen werden kann. In der OGSA werden die Schnittstellen mit der Web Service Description Language (WSDL) 11 definiert. WSDL bringt den Vorteil, dass Schnittstellen getrennt von den Protokollen definiert werden können. Des weiteren unterstützt WSDL mehrere Protokollbindungen zu einem Interface, was die Kommunikation zwischen lo- 11

27 EINFÜHRUNGEN IN GRIDS 21 kalen Anfragen und lokalen Service Prozessen erlaubt. Weitere Eigenschaften von Bindungen sollten Vertrauenswürdigkeit, Authentifikation und die Möglichkeit der Delegation von Berechtigungen, sein. Die Wahl der Protokolle sollte transparent geschehen aber mit der Möglichkeit des Eingreifens für den Benutzer. Zusätzlich sollten die Schnittstellendefinitionen unabhängig von der Implementation des Service geschehen. Ein Service kann auf viele Arten implementiert werden, um den Ansprüchen der verschiedenen Plattformen gerecht zu werden, sollte aber immer die gleiche Funktionalität bieten. Dadurch wird es möglich, verschieden Implementationen als nach außen hin eine Implementation darzustellen (Virtualisierung). Die Service Orientierte Sichtweise erleichtert also die Virtualisierung (siehe Abschnitt 2.2.1). Die Funktionalität eines Service kann über die Grenzen einer Organisation hinaus genutzt werden, ganz gleich welche Plattform oder welches Betriebssystem genutzt wird. In einer heterogenen Umgebung können durch die Virtualisierung die angebotenen Service transparent genutzt werden. Abschließend zu diesem Abschnitt möchte ich hier aus The Physiolgy of the Grid [23] ein Zitat anführen, das zusammenfasst, was mit dem Service Orientierten Ansatz erreicht wird: Thus, our service architecture supports local and remote transparency with respect to service location and invocation. It also provides for multiple protocol bindings to facilitate localized optimization of services invocation when the service is hosted locally with the service requestor, as well as to enable protocol negotiation for network flows across organizational boundaries where we may wish to choose between several intergrid protocols, each optimized for a different purpose. Finally, we note that an implementation of a particular Grid service interface may map to native, nondistributed, platform functions and capabilities. [23, S.11]

28 EINFÜHRUNGEN IN GRIDS Zusammenfassung und Aussichten Grids wurden anfänglich entwickelt, um spezielle Ressourcen (z.b. Supercomputerzentren) mit dem Ziel zu verbinden,mehr Rechenkraft zu erreichen. In der weiteren Entwicklung konnten und sollten auch andere nicht spezialisierte Ressourcen eingebunden werden. Aus einer heterogenen Umgebung sollte eine Virtuelle Maschine werden. Heute ist die Gridforschung auf dem Weg in das Semantic Grid 12, die nächste Generation des Grids. Der Sinn von Grids ist es, nicht mehr Rechenleistung und Datenspeicherplatz zur Verfügung zu stellen, sondern eine kollaborative Arbeit zu ermöglichen. Dazu ist es wichtig, offene Standards, seien es Protokolle oder Schnittstellen, zu benutzen und diese einheitlich und wohldefiniert zu beschreiben. Den Anfang dazu machte das Globus Grid Forum 13 mit der Open Grid Service Architektur 2.2. Will man diese Entwicklung in andere Worte fassen, so kann man Gridanwendungen in drei Gruppen aufteilen: 1. intensive Computing: Ein Grid wird als Lieferant für Rechenleistung und Datenspeicher benutzt. 2. Powersaling: Eine Firma stellt Rechenkapazität über eine Gridschnittstelle zur Verfügung. Hier kommt der wirtschaftliche Aspekt zum Zuge. Die Technik steht nicht mehr nur Wissenschaftlern zur Verfügung, sondern auch der Öffentlichkeit. 3. Endanwender: Ein Grid wird für die Umsetzung einer kollaborativen Umgebung benutzt. Die Software ist ausschließlich für die Unterstützung der Arbeit des Endanwenders konzipiert. Auch in dieser Aufteilung befindet sich die Forschung gerade auf dem Weg in die 3. Generation. Nach den Forschern des Semantic Grid Forums ist es das Ziel der dritte Generation, das Grid zu ermöglichen:

29 EINFÜHRUNGEN IN GRIDS 23 Our vision is of a generically useable eresearch infrastructure, comprised of easily deployed components whose utility transcends their immediate application, providing a high degree of easy-to-use and seamless automation and in which there are flexible collaborations and computations on a global scale

30 Kapitel 3 Wireless Grid In diesem Kapitel wird der Unterschied zwischen einem Grid und einem Wireless Grid vorgestellt und die Anforderungen definiert. Des weiteren werden Szenarien vorgestellt, die zeigen sollen, wie ein Wireless Grid zukünftig genutzt werden kann. Aufbauend darauf werden Projekte vorgestellt, die sich mit mobilen Techniken befassen. 3.1 Einführung in Wireless Grids Bis jetzt wurde beschrieben, was man sich unter einem Grid vorzustellen hat und was Grids leisten können. Doch diese Erklärungen bezogen sich, der Einfachheit halber, auf sog. Wired Grids [29], das heißt Grids, die über ein Kabelverbindung zusammen geschaltet sind, sei es nun über ein internes Netzwerk (LAN) oder das Internet. Das wiederum heißt, dass man durch diese Art des Grids stark in der Mobilität eingeschränkt ist. Denkt man an die in Abschnitt 2.3 beschriebene Aufteilung der Anwendungsgebiete eines Grids und betrachtet die Kategorien intensive Computing und Powersaling, so spielt diese Einschränkung keine Rolle. Doch für die Zielgruppe Endanwender ist zu Zeiten von Wireless LAN, Centrino Laptops, Handys und PDAs die Mobilität ein wichtiger Gesichtspunkt geworden. 24

31 EINFÜHRUNG IN WIRELESS GRIDS 25 Mit dem Hinweis auf Mobilität kann Geld verdient werden und deshalb setzen sich mobile Produkte vielfach durch. Will man also im Endanwenderbereich die Grid - Technik weiter vorantreiben, muss man sich mit der Mobilität auseinander setzen - hier also mit dem Wireless Grid. Wireless Grids sind Grids, die über drahtlose Übertragungstechniken zusammen geschaltet werden und so dem Benutzer eine höhere Mobilität erlauben. Nach [29] sind Wireless Grids Netze, die aus allen möglichen nomadischen Geräten bestehen können, zum Beispiel Laptops, Handys und PDAs und deren Übertragungstechniken stark variieren können. Darauf wird später genauer eingegangen. In dieser Arbeit genügt es, ein Wireless Grid mit Laptops und PC s in einem WLAN zu untersuchen, um einen Überblick über diese Technik zu schaffen. Geht man davon aus, dass der Übergang vom verkabelten Grid zum Wireless Grid dadurch gelöst wird, die Kabel durch ein drahtloses Übertragungsmedium zu ersetzen, irrt man sich. Durch die drahtlose Übertragung und den Anspruch auf mehr Mobilität entstehen weitere Anforderungen an das Grid. Die Bandbreite in einem Wireless LAN bleibt deutlich hinter der eines LAN zurück. Steht in einem herkömmlichen, geswitchtem LAN (inzwischen der Quasistandard im Heim- und Officebereich) eine Datengeschwindigkeit von 100 MBit/s pro Person zur Verfügung, so erreichen die schnelleren gängigen WLAN - Standards 1 gerade 54 MBit/sec. Diese Bandbreite muss zwischen den Nutzern aufgeteilt werden und wird zusätzlich durch Störungsfaktoren wie Wände und Entfernung zum Accesspoint vermindert. Durch zunehmende Entfernung zwischen zwei über ein WLAN verbundene Geräte, wird nicht nur die Übertragungsgeschwindigkeit verringert, sondern auch Verbindungsausfälle möglich, die es in dieser Form in einem LAN nicht gibt. Weitere Störungsfaktoren sind Funkübertragungstechniken, wie z.b. Bluetooth, das das gleiche Frequenzband wie die WLAN Standards b/g/i nutzt. Ganz aktuell wird über den neuen Standard n entschieden. Nach einer Meldung 2 soll dieser Standard durch die MIMO-Technik (Multiple Input, Multiple Output) auf einen Durchsatz

32 EINFÜHRUNG IN WIRELESS GRIDS 26 auf Anwendungsebene bei einer guten Funkverbindung etwa 160 MBit/s (Netto) respektive 320 MBit/s (Brutto) erreichen, also ungefähr anderthalb bis dreimal soviel wie Fast Ethernet. Dies wird die Entwicklung eines Wireless Grids über WLAN deutlich vereinfachen. Eine weitere Schwachstelle eines WLAN ist die Sicherheit. Die gängigen Sicherheitsmechanismen gelten für den Schutz vertraulicher Daten als angreifbar, zum Teil sogar als unwirksam [31]. Es existiert ein neuer, bis jetzt unentschlüsselter Standard i 3 ;er hat sich jedoch noch nicht durchgesetzt. Ein nicht zu vernachlässigender Punkt sind die geringen Ressourcen der mobilen Geräte. Diese Geräte haben weniger Ressourcen (Speicher, Prozessor, Energie, usw.) als ein PC. Der hohe Stromverbrauch ist besonders zu beachten. Einem PC, der Strom aus dem Netz bezieht, steht dieser i.d.r. für einen unbegrenzten Zeitraum zur Verfügung, während die Batterie eines Laptops schnell entladen ist. Der Energieverbrauch wird durch die drahtlose Verbindung weiter erhöht. Ein letzter wichtiger Punkt in Hinblick auf Mobilität der Endanwender ist die Spontanität. In Wired Grids ist Spontanität nicht wichtig oder auch nicht sehr wichtig. Die Geräte der Endanwender sind meist fest installiert und es existieren keine Anwendungsszenarien für spontane Vernetzung. Im Wireless Grid muss es den Anwendern mit Ihren mobilen Geräten möglich sein, spontan oder anders ausgedrückt ad hoc, ein Grid aufzubauen, und zwar ohne komplizierte Konfigurationen durchzuführen. Anforderungen an das Wireless Grid Mit den Schwachstellen der mobilen Übertragungstechniken (hier: WLAN) ergeben sich folgende Anforderungen an ein Wireless Grid : Da weniger Bandbreite als in einem verkabelten Netzwerk zur Verfügung steht, müssen Anwendungen sparsam mit der Bandbreite umgehen, also den Overhead im Datenverkehr minimieren; 3

33 EINFÜHRUNG IN WIRELESS GRIDS 27 Um eine sichere Benutzung einer Wireless Grid -Anwendung zu gewährleisten, müssen zusätzlich zu den vom WLAN bereitgestellten Sicherheitsmechanismen, zusätzliche Sicherheitstechniken implememtiert werden; Um die Ressourcen der Geräte zu schonen, müssen Anwendungen, rechenintensive Aktionen und unnötigen Datenverkehr vermeiden ANFORDERUNG AN WIRELESS GRIDS - Bandbreite beachten - Sicherheit - Resourcenschonung Tabelle 3.1: Anforderungen eines Wireless Grid Ein Wireless Grid hat zwar andere Anforderungen und andere Anwendungsgebiete als ein Wired Grid, doch sollte man beide Richtungen auf derselben Grundlage, der OGSA, entwickeln. Es ist wichtig, dass gemeinsame Schnittstellen verwendet werden. Natürlich ist es sinnvoll, ein eigenes Protokoll für Wireless Grids zu schreiben, aber nur auf der Grundlage der OGSA mit den einheitlichen Standards. Deswegen soll im weiteren Verlauf dieser Arbeit untersucht werden, ob mit aktueller Grid-Software oder Erweiterungen dieser, basierend auf der OGSA, der Aufbau eines Wireless Grid unter Berücksichtigung der eben dargelegten Anforderungen, möglich ist Ansatz von wirelessgrids.net Einen ganz anderen Weg ist die Forschergemeinschaft von wirelessgrids.net gegangen; sie wollen einen neuen Standard schaffen und nicht auf dem des Wired Grid, also der OGSA, aufbauen. Die Forschungsarbeiten sind eng mit dem Telecomcity Projekt [11] der Städte Everett, Malden und Medford verbunden. Das Telecomcity Projekt ist ein Zusammenschluss von Forschung und Wirtschaft, der versucht, die erzielten Ergebnisse direkt in die Schulen und damit der Bildung

34 EINFÜHRUNG IN WIRELESS GRIDS 28 einfließen zu lassen, um so die erzielten Ergebnisse und Anwendungen direkt an den Endanwendern zu testen. Ein Teilgebiet ist das Projekt Virtual Markets and Wireless Grids [27], das den enormen Wertebeitrag untersuchen will, den Wireless Grids bieten. Sie sollen den Zugang zu drahtlosen Kommunikationsdiensten erhöhen und neue wirtschaftliche Sektoren schaffen, indem der Zugang zu Griddiensten über die allgegenwärtige Netzwerke genutzt wird. Devices on the wireless grid will be not only mobile but nomadic [29], ist der Grundsatz, mit dem diese Forscher an ihre Aufgabe, ein neues Wireless Grid - Protokoll [28] zu erstellen, herangehen. Wie weiter oben erwähnt, sind nomadische Geräte als mögliche mobile Einheiten, die ein Benutzer mit sich führen kann, bestimmt. Mit nomadisch wollen die Forscher ausdrücken, dass ein Wireless Grid überall und nicht nur in statischen Gebieten genutzt werden soll. Das Wort nomadisch ist von den Nomaden abgeleitet, die nicht seßhaft von einem Ort zum nächsten ziehen. Wireless Grid - Anwendungen werden in drei Teilbereiche unterteilt: Anwendungen, die Informationen der verschiedenen Interfaces der nomadischen Geräte sammeln; Anwendungen, die Ort und Kontext der Geräte wirksam einsetzen; Anwendungen, die das Potential aus vernetzten Gruppen wirksam einsetzen; Die Wireless Grid -Architektur basiert auf den Vorbild - Architekturen: Peer to Peer Verbindungen, Grid Computing und Webservices. Die Abbildung 3.1 veranschaulicht, wo - nach [29] - das Wireless Grid einzuordnen ist. Folgende Anforderungen sollten nach [28] ein Wireless Grid - Protokoll erfüllen: Resource Discription: Eine Ressource soll richtig, ausführlich und mit einer standartisierten Sorache beschrieben werden können.

35 EINFÜHRUNG IN WIRELESS GRIDS 29 Abbildung 3.1: Einordnug des Wireless Grids nach wirelessgrids.net Resource Discovery: Eine Funktion soll es ermöglichen Ressourcen in einem Grid zu finden. Hierzu soll WSDL 4 genutzt werden. Ein Beispiel sind die Zeroconf - Protokolle 5 Coordination Systems: Zugriffe auf Ressourcen und Mechanismen, mit denen die Ressourcen geshared werden (z.b. SAMBA, NFS, FTP X), sollen koordiniert werden, um eine Kommunikation ohne gemeinsame Standards zu ermöglichen. Trust Establishment. Bei Zugriffen auf Ressourcen müssen Anbieter sowie Nutzer der Ressource sicher sein, dass das Gegenüber auch das ist, für das es sich ausgibt. Mit einem Public-Key-Verfahren sollen Man-in-the-Middle Attacken vermieden werden

36 EINFÜHRUNG IN WIRELESS GRIDS 30 Clearing Mechanism: Es sollen Bedingungen definiert werden können, mit deren Hilfe ein Zugriff auf die Ressourcen beschränkt werden kann. Beispiele sind die Authentifikation oder die Einschränkungen wie bei Tauschbörsen: Nur wer shared, shared!, d.h. nur wer Ressourcen anbietet, darf auch Ressourcen nutzen. Zu diesem Ansatz existiert auch ein Referenzprojekt, das später in Abschnitt 3.3 erläutert wird. 3.2 Wireless Grid Szenarien Um die Idee des Wireless Grid zu veranschaulichen, sollen im Folgenden einige Szenarien [9] aufgeführt werden : Bar Video In einer Diskothek filmt ein Anwender seinen Freund beim Tanzen. Da es ein Fernsehgerät in der Diskothek gibt, auf dem Musik - Videos abgespielt werden, möchte er seinen gedrehten Film dort abspielen, diesen aber vorher noch mit digitalen Effekten versehen. Nach der Bearbeitung muss der Film allerdings erst gerendert werden. Das eigene Gerät hat aber weder die Leistung noch die Energie dies zu bewerkstelligen. Also kontaktiert der Anwender alle Geräte seiner Freunde in der Disco und vielleicht sogar die Computer der Diskothek und verschickt einzelne Pakete, die von den anderen kontaktierten Geräten gerendert werden. Sobald die einzelnen Pakete bearbeitet sind, werden die einzelnen Teile wieder zusammengesetzt. Nun wird das Fernsehgerät kontaktiert und um Erlaubnis gefragt, einen Film abzuspielen. Das Fernsehgerät akzeptiert die Anfrage; es ist für solche Zwecke vorgesehen, und der Film kann auf dem Fernsehgerät gezeigt werden.

37 EINFÜHRUNG IN WIRELESS GRIDS 31 Internetzugang für LKW - Fahrer Ein LKW - Fahrer möchte auf einem Parkplatz irgendwo im Niemandsland seine abrufen und das WWW besuchen. Doch besteht keine Möglichkeit, sich direkt mit dem Internet zu verbinden, da es keine Übertragungsinfrarstruktur in dieser Gegend gibt. Also verbindet sich sein Gerät mit dem Gerät eines vorbeifahrenden LKW s. Dieses verbindet sich zum nächsten erreichbaren und dieses dann wieder zum nächsten Gerät, solange bis eines dieser Geräte eine Verbindung zum Internet aufbauen kann.auf diese Weise können die Anfragen des ersten LKW - Fahrers ins Internet geroutet werden. Verteiltes Fischschwarmfinden für Fangflotten Fischfangflotten haben immer einige Schiffe auf dem Meer, die nach Fischschwärmen suchen, um diese dann zu fangen. Die Schiffe sind meist hochtechnisiert, kommunizieren aber nicht untereinander. Dies führt oft zu doppelter Erfolgsmeldung oder zu gar keinem Ergebnis. Wären diese Schiffe über ein Grid miteinander verbunden und würden ihre gesammelten Information gemeinsam genutzt werden, könnte die Effizienz deutlich gesteigert werden. Discovery und Display Sharing Bei einem Treffen mehrerer Leute möchte jeder Teilnehmer eine Präsentation halten und jeder Teilnehmer bringt den eigenen Laptop mit. Anstatt den Beamer, der für die einzelnen Präsentationen benötigt wird, immer wieder neu an die einzelnen Geräte anzuschließen, wird dieser nur an ein Gerät angeschlossen und als Ressource definiert (dies könnte auch direkt im Beamer implementiert sein). Über Resource Discovery finden die einzelnen Teilnehmer den Beamer und können ihn so nacheinander oder sogar gemeinsam als Splitscreen benutzen.

38 EINFÜHRUNG IN WIRELESS GRIDS Projekte In diesem Abschnitt sollen einige Projekte beschrieben werden, die einen Bezug zu dieser Arbeit haben. Adhocfs und Xmiddle beschäftigen sich hauptsächlich mit einem ressourcenschonenden Datentransfer und der Möglichkeit, auch ohne eine Verbindung die Dateien anderer manipulieren zu können. Alien und das European Datagrid sind Beispiele, wie in Grids entfernte Daten manipuliert werden. Deren Augenmerk liegt aber hauptsächlich auf dem Transfer großer Datenmengen. DARC ist das Beispiel Projekt von wirelessgrids.net und zeigt wie ein Wireless Grid aufgebaut und genutzt werden kann. AdhocFs Adhocfs [15] ist ein verteiltes Dateisystem, das es Benutzern ermöglichen will, zu jeder Zeit an jedem Ort Daten ad hoc transparent und sicher auszutauschen. Um die Sicherheit zu gewährleisten, werden Gruppen erstellt. So ist es nur Mitgliedern einer Gruppe möglich, Daten auszutauschen. Adhocfs baut auf dem ext2 Dateisystem auf und verwendet das lokale Dateisystem als Cache. Die Dateinamen werden in die verschiedenen Orte, von denen sie kommen, aufgelöst. Ein Ort besteht aus der Adresse des sog. Home Servers, eventuellen lokalen Cachedateien und eventuellen entfernten Cachedateien, die durch das Discovery Protokoll ausfindig gemacht werden. Adhocfs ist in Objective Caml 3 geschrieben, und verwendet zur Verschlüsselung Blowfish und zur Service Discovery OpenSDL. Als wichtigste Gesichtspunkte bei diesem Projekt gelten: Ressourcen- und Energieeinsparungen Anpassung an die Dynamik des Netzwerkes sowie Sicherheit.

39 EINFÜHRUNG IN WIRELESS GRIDS 33 XMIDDLE XMIDDLE [10] ist eine Data Sharing Middleware für Ad-hoc-Netzwerke. Das Ziel des Projektes ist es, strukturiert Daten zwischen mobilen Hosts zu sharen; bei diesen Verbindungen ist ein Verbindungsausfall eher normal als die Ausnahme. XMIDDLE ermöglicht es, Daten zu synchronisieren und zu replizieren. Ist dieser Vorgang vollzogen, ist es sogar möglich, Daten im nicht verbundenen Zustand zu manipulieren, das heißt zu bearbeiten. Umgesetzt wurde das Projekt in Java und XML. Die Daten und Verzeichnisstrukturen werden in XML Dokumenten abgebildet. So können die Daten über die DOM API manipuliert werden. Der XMIDD- LE Controller macht die Kommunikation mit den Transportprotokollen möglich. Der XMIDDLE Manager stellt die Schnittstelle bereit, über die Anwendungen mit XMMIDDLE arbeiten können. Alien Alien (Alice Environment) [16] ist eine Data Sharing Umgebung, die aus den Anforderungen der Alice Arbeitsgruppe hervorgegangen ist. Die Alice Arbeitsgruppe beschäftigt sich mit nuklearen Forschungsprojekten. Dabei fallen sehr große Mengen an Daten an - bis zu 2GB pro Datei und 10 9 Dateien/Jahr. Die Dateien müssen allen Forschungseinrichtungen aus 20 teilnehmenden Staaten zugänglich sein. Die wichtigsten Features in Alien sind ein verteilter Dateikatalog, Dateireplikation und Cache Unterstützung. Der Dateikatalog ist ein Interface, das auf eine Datenbank zurückgreift, die physikalische auf logische Namen abbildet. Alien ist ein Client - Server Modell. Von den Servern wird ein virtuelles Verzeichnis erstellt, sodass die Clients damit arbeiten können. Es können in dem Virtuellen Verzeichnis mit verschieden Benutzerschnittstellen dem Benutzer bekannte Interaktionen wie Kopieren, Verschieben, Verzeichnis anlegen, Löschen, usw., ausgeführt werden. Eines der Benutzerschnittstellen zum Beispiel ist eine Shell, die Kommandos aus der UNIX/Linux Welt bereitstellt: ls, mkdir, cp, rm, mv. Das entfernte Manipulieren

40 EINFÜHRUNG IN WIRELESS GRIDS 34 der Daten ermöglicht ein verteiltes Dateisystem, AlienFs [30], das in das lokale Dateisystem der Server integriert werden kann. Alien ist in Perl geschrieben und nutzt die Fähigkeiten verschiedener Opensource Projekte, wie dem Globus Toolkit, Apache, Condor und Jabber. Durch das Nutzen der Interfaces der verschieden Opensource Projekte, mussten die Entwickler nur geringem Umfang eigenen Code generieren; sie konnten so viel Zeit sparen. Die Tools des European Data Grid Das in Abschnitt 2.1 schon vorgestellte European Datagrid Project bietet zur Manipulation von Daten ein ganzes Set an Tools an. In Anlehnung an die Benutzung einer UNIX/Linux Shell stehen dem Benutzer Befehle wie ls (list), mkdir (make directory), rm (remove), rmdir (remove directory) zur Verfügung, um entfernte Daten zu managen. Die Befehle können in der eigenen Shell benutzt werden, ohne dass eine manuelle Verbindung zu dem Computer hergestellt werden muss, auf dem die Daten manipuliert werden sollen. Diese Tools basieren auf dem Globus Toolkit (siehe Abschnitt 4.6). Sie beinhalten Sicherheitsmechanismen und unterstützen Signle Sign on. Die Sicherheit wird mit der Globus Security Infrarstructure (siehe Abschnitt 4.6.1) umgesetzt, die auf Zertifikaten basiert. DARC DARC basiert auf den in Abschnitt dargestellten Forschungen von wirelessgrids.net und demonstriert, wie verteiltes Ad-hoc-Ressourcen-Sharing genutzt werden kann. DARC kann Geräte, die keine vorherigen Kenntnisse voneinander besitzen, koppeln, um gemeinsam ein Audiosignal (eine Rede oder ein Konzert) zu mischen und aufzunehmen. Das Projekt zeigt die Möglichkeiten von Wireless Grids und verteilten Ad-hoc-Ressourcen-Sharing. Durch alleiniges Nutzen einzelner Geräte, können Nachteile entstehen. Einzelne Geräte haben

41 EINFÜHRUNG IN WIRELESS GRIDS 35 begrenzte Aufnahmekapazitäten oder nur Mono Signalverarbeitung. Auch durch schlechte Platzierung können schlechte Aufnahmen entstehen. DARC will diese Nachteile durch Kopplung der einzelnen Geräte ausgleichen. Die virtuelle Anwendung besteht aus einem Mixer und mindestens zwei Aufnahmegeräten, wobei ein Gerät auch gleichzeitig als Mixer fungieren kann. Will ein User eine Aufnahmesession starten, so wählt er die Geräte, die er benutzen will und deren Funktion, aus. Sobald ein Mixer und zwei Aufnahmegeräte gekoppelt sind, beginnt die Aufnahme. Die Aufnahmegeräte streamen die Aufnahmen zum Mixer, wobei darauf geachtet wird, dass die Aufnahmegeräte wenig Ressourcen zur Verfügung haben. Dann initiieren die Aufnahmegeräte einen listening Service, um die gemischten Aufnahmen wieder zu empfangen. Das Finden der Geräte (Resource Discovery) Rin diesem Wireless Grid erfolgt über Rendezvous 6. Das anwendungsspezifische Protokoll basiert auf acht einfachen Nachrichten. Session Management und Security werden momentan noch von BEEP 7 geregelt; sie sollen aber auf den Webservice Framework (SOAP + WDSL) umgestellt werden. Die Anwendung ist in Java umgesetzt

42 Kapitel 4 Material und Software In diesem Kapitel werden die zur Verfügung stehenden Geräte vorgestellt und die Software ausgewählt, die für die Umsetzung des Szenarios notwendig ist. Um die Software auswählen zu können, wird das zuvor geschilderte Szenario beschrieben und analysiert. 4.1 Verwendete Geräte In Tabelle 4.1 auf Seite 38 sind alle mir zur Verfügung stehenden Geräte aufgelistet. Auf dem Computer Desktop2 wurden alle durchgeführten Installationen und deren Funktionsweisen getestet. Im weiteren Verlauf diente dieser Rechner dann als Client2 (siehe Abschnitt 6.1). Der Computer Desktop1 wurde als Gateway benutzt, um für den Desktop2, der keine WLAN - Karte besitzt, eine WLAN Verbindung zu simulieren. Auch wurde über dieses Gateway alle nötigen Messungen durchgeführt: So wurden die Clients, auf denen die Gridsoftware installiert war, nicht durch Messprogramme beeinflusst. Der Laptop diente als Client1. Die eingesetzte Hardware erfüllte voll und ganz ihren Zweck und reichte aus, um die gesetzten Ziele zu erreichen. Auf allen Computern ist das Betriebssystem Linux installiert. Zum 36

43 MATERIAL UND SOFTWARE 37 einen, weil Linux, gerade im Netzwerkbereich gut zu konfigurieren ist, zum anderen weil Gridsoftware in der jetzigen Entwicklungsphase fast ausschließlich für Linux vorhanden ist. Für die Messungen wurde das Tool Iptraf 1 verwendet. Iptraf stellt dar, wieviel Byte gerade über ein ausgewähltes Interface laufen und errechnet daraus die Geschwindigkeit. Durch die Berechnug enstehen Verzögerungen, die es bei kleinen Transfers nicht gestatten die, Transferrate anzuzeigen. Folgende Software wurde zu erstellen der Diplomarbeit verwendet: OpenOffice.org für Diagramme und Abbildungen L A TEX für die Formatierung des Textes Gedit für den Text TheGimp für Abbildungen Iptraf für die Messungen Globus Toolkit für die Erstellung der Testumgebung 4.2 Anwendungsszenario Um die bisher vorgestellten Ergebnisse meiner Recherche zu veranschaulichen und zu prüfen, soll nun die Einsatzfähigkeit von aktueller Gridsoftware für ein Wireless LAN untersucht werden. Um aber nicht einfach ziellos verschiedene Software zu installieren, wurde ein sinnvolles Szenario ausgesucht und an die Anforderung eines Wireless Grid angepasst. Es musste ein Szenario sein, das in die Kategorie Endanwender (siehe Abschnitt 2.3) passt. In Hinblick auf eine große Kollaborations - Plattform, die in mehreren Diplomarbeiten und Semesterprojekten umrissen und mit einem Grid realisiert werden soll, entwickelte ich die Idee, einer Data 1

44 MATERIAL UND SOFTWARE 38 LAPTOP HP nx5000 mit Hardware Betriebssystem Intel Centrino 2200 Minipci Adapter b/g Intel Pentium Centrino 1,5, 512 RAM Ubuntu 4.10 DESKTOP1 Desktop mit Hardware Betriebssystem ZyxelAirB220 USB Wireless b only AMD Athlon XP 2000+, 512 RAM Ubuntu 4.10 DESKTOP2 Desktop Computer ohne ACCESS POINT Hardware Betriebssystem Hardware Wireless LAN Karte no WLAN Intel Pentium PIII 600, 384 RAM Debian woody 3.0rc4 Zyxel Air B b Access Point Router Tabelle 4.1: Benutze Geräte Sharing Umgebung. Über ein virtuelles Verzeichnis soll es Nutzern möglich sein, Daten - speziell Dokumente- in einem Wireless LAN zu sharen. Um das Konzept - ich habe es Document Sharing Service (DSS) genannt (siehe Abschnitt 5.1) - zu veranschaulichen, sollen zwei Anwendungsszenarien aufgeführt werden, die die Vorteile des Konzeptes erkenen lassen.

45 MATERIAL UND SOFTWARE 39 Document Sharing in einer Besprechung Während einer Besprechung ist es oft notwendig, Dokumente zu verteilen. Es gibt viele Möglichkeiten, Dokumente von einem Computer auf den anderen zu bringen, doch wird dafür meist eine proprietäre Software, ein File - Server, eine homogene Umgebung oder sogar Kenntnisse der Netzinfrarstruktur vorausgesetzt oder benötigt. Auch wollen die Teilnehmer einer Besprechung ohne Kabel das Netzwerk und die Vorteile des Wireless LAN nutzen. Dies erfordert aber zusätzliche Sicherheitsmaßnahmen, damit nicht wichtige Dokumente entwendet oder ausspioniert werden können. Diese Anforderungen können alle erfüllt werden, wenn eine Besprechung geplant und vorher bekannt ist, dass Dokumente getauscht werden sollen. Wie ist es aber, wenn eine spontane Besprechung stattfindet und sogar Teilnehmer aus anderen Firmen teilnehmen wollen? Wie steht es in diesem Fall mit der Sicherheit? Mit dem DSS (Document Sharing Service) können die Teilnehmer der Besprechung auf einfachem und verschlüsseltem Weg die Dokumente der anderen Teilnehmer einsehen. Über ein virtuelles Verzeichnis werden alle Dateien von jedem Rechner angezeigt, die den anderen Teilnehmern zur Verfügung gestellt werden sollen. Nur autorisierte Teilnehmer, das heißt Mitglieder der Virtuellen Organisation BesprechungXYZ, erhalten Einsicht. Durch einfaches Markieren der Dokumente, kann das Dokument dann lokal gespeichert werden, gleich auf welchem Rechner sich die Dokumente befinden. Document Sharing in der Vorlesung Die Vorlesung an modernen Universitäten werden inzwischen mit Laptops und Beamer gehalten; Damit soll eine erhöhte Interaktion zwischen Professor und Student erreicht werden. Während einer Programmiersprachenvorlesung wäre es manchmal praktisch, wenn die Studenten direkt die Programmierbeispiele auf Ihren Laptops einsehen könnten. Dies jedoch setzt voraus, dass die Studenten vorher sich diese Beispiele aus dem Campusnetz laden müssten, denn während der

46 MATERIAL UND SOFTWARE 40 Abbildung 4.1: Bildung eines Virtual Directory Vorlesung die Beispiele zu verteilen, würde bedeuten, dass alle eine Sharing Software installiert haben. Mit DSS können alle Studenten einfach auf die Beispiele über das Campus - WLAN zugreifen. Als Mitglieder der Virtuellen Organisation Programmiersprachen Vorlesung können sie über das Virtuelle Verzeichnis durch einfaches Markieren des Beispiels, dieses lokal auf dem Laptop verfügbar machen. Nur Mitgliedern dieser VO ist es möglich, darauf zuzugreifen. Ein weiterer Nutzen von DSS ist die direkte Weitergabe der Übungsaufgaben und der Vorlesungsfolien während der Vorlesung über das Virtuelle Verzeichnis. Bei diese beiden Anwendungsbeispielen gehe ich von einer bestehenden Grid Infrastruktur aus (siehe Abschnitt 5.1).

47 MATERIAL UND SOFTWARE Anforderungen des Szenarios Im vorherigen Abschnitt wurde ein Szenario vorgestellt- ich nannte es DSS (Abschnitt 4.2). Um dafür eine Anwendung zu konzipieren, müssen erst die genauen Anforderungen spezifiziert werden. Später in dieser Arbeit wird geprüft, inwiefern die Anforderungen von dem Konzept (siehe Abschnitt 6) erfüllt wurden. Das Ziel ist es zu prüfen, ob es mit aktueller Gridsoftware möglich ist, eine kollaborative Grid Anwendung zu erstellen, die das Sharen von Dokumenten in einem Wireless LAN ermöglicht. Daraus ergeben sich zwei Anforderungen. 1. Anforderungen, die sich aus einem Wireless Grid ergeben (siehe Abschnitt 3.1) 2. Anforderungen, die die benutzerfreundliche Bedienung der Anwendung betreffen Wie in Abschnitt 3.1 erwähnt wurde, ist bei einem Wireless LAN besonders auf die Sicherheit zu achten. Ein Anwender muss sich einerseits sicher fühlen (subjektives Moment), andererseits muss die Anwendung auch dementsprechend sicher sein (objektives Moment). Ein weiterer Aspekt ist die begrenzte Bandbreite eines WLAN. Hier muss die Verzögerung beachtet werden, die eine Aktion von deren Ausführung bis zu deren Abschluss mit sich bringt. Sie darf das kollaborative Arbeiten nicht behindern. Das Wireless LAN und in diesem Fall damit das Wireless Grid sollen dem Benutzer eine erhöhte Mobilität und damit eine erhöhte Effizienz beim gemeinsamen Arbeiten ermöglichen. Deshalb ist es wichtig, dass alle Abläufe möglichst transparent sind. Es muss möglich sein, Daten von einem Rechner auf den anderen Rechner zu übertragen und dabei zu synchronisieren. Dies sollte über ein intuitives, dem Dateibrowser angepasstes Benutzerinterface geschehen. Es dürfen auf keinesfalls Daten, die denselben Namen besitzen, durch Überschreiben verloren gehen. Des weiteren muss ermöglicht werden, ad hoc eine

48 MATERIAL UND SOFTWARE 42 Virtuelle Organisation oder eine vergleichbar sichere Umgebung zu schaffen, ohne einen Server zu kontaktieren oder Konfigurationsdateien bearbeiten zu müssen. Es steht zur Diskussion, ob es die Aufgabe der Grid Anwendung sein muß, ad hoc ein Netzwerk zu konfigurieren:meiner Meinung nach nicht. Dies kann zwar die Aufgabe der Gridsoftware sein. Aber die Gridsoftware nutzt in der Regel die Netzwerkfähigkeiten des darunter liegenden Betriebssystem, daher müßte die Ad-hoc- Netzwerkkonfiguration in den Aufgabenbereich des Betriebssystems fallen. Gute Ansätze dazu sind die von DARC verwendeten Netzwerktools des Zeroconf Projekts (siehe Abschnitt 3.3). Die Tabelle 4.2 erweitert die Tabelle 3.1 um die eben aufgeführten Anforderung an das Szenario. ANFORDERUNG AN WIRELESS GRIDS ANFORDERUNG AN DIE ANWENDUNG - Bandbreite beachten - Sicherheit - Resourcenschonung - Transparenter Datentransfer - Datenkonsistenz - ad hoc VO - Resource Discovery - intuitives Benutzerinterface Tabelle 4.2: Anforderungen an den Document Sharing Service 4.4 Bewertung der ähnlichen Projekte Auf Basis der soeben gestellten Anforderungen (Abschnitt 4.3) kann nun geprüft werden, ob eines der in Abschnitt 3.3 beschriebenen Projekte dieses ganz oder teilweise erfüllt. Xmiddle und Adhocfs Xmiddle ist den Weg gegangen, die Daten neu zu strukturieren. Die Daten werden mit XML beschrieben und dann in einem DOM Bau abgelegt. Mit diesem Projekt

49 MATERIAL UND SOFTWARE 43 wurde direkt auf die Belange mobiler Geräte eingegangen und den damit verbundenen Problemen wie z.b. begrenzte Bandbreite oder dem Verlust der Verbindung. Die Daten können auch bei Verlust der Verbindung bearbeitet werden, um dann schließlich wieder synchronisiert zu werden. Eine ähnliche Funktionalität bietet auch die Middleware Adhocfs. Bei diesem Projekt handelt es sich um ein verteiltes Dateisystem, das direkt in das Linux - Dateisystem, das heißt direkt in das Betriebssystem, integriert werden kann. Beide Projekte unterstützen einen Ad-hoc- Verbindungsaufbau und beide Projekte bieten ressourcenschonenden Datentransfer. Beide Projekte jedoch sind reine Insellösungen. Es sind Studien, die zeigen, wie möglichst effizient Daten mobiler Geräte geshared werden können. Diese Projekte zeigen keinen Ansatz, die Technik später in ein Grid zu implementieren. Jedoch zeigt hier gerade Xmiddle, das die Datenstruktur mit XML beschreibt, einen viel versprechenden Ansatz. Adhocfs erweist sich dagegen, da es sich um ein fest in das Betriebssystem integrierbares Dateisystem handelt, das gegen die Grundsätze einer Gridsoftware verstößt, als nicht einsetzbar. Alien Alien hingegen ist eine Gridsoftware. Mit Alien wurde das Ziel, ein Virtuelles Verzeichnis zu schaffen, bereits erreicht. Das Virtuelle Verzeichnis bietet alle Möglichkeiten, die auch ein lokales Verzeichnis bietet; es arbeitet dabei transparent. Zum Beispiel wird transparent zwischen verschiedenen Übertragungsprotokollen gewechselt, je nachdem, welches Protokoll das darunterliegende Betriebssystem bietet und welches für die Größe der Datei geignet ist. Doch Alien ist nicht nur auf die Anforderungen mobiler Gruppen ausgelegt, sondern vielmehr auch auf das Arbeiten in großen statischen Gruppen mit sehr umfangreichen Datenmengen. Auch liegen die Daten nicht auf den verschiedenen Clients, sondern auf Servern, das heißt, dass die Datenserver ein Virtuelles Verzeichnis für die Clients bereitstellen. Dieses Client Server Modell erlaubt es somit den Clients nicht, eigene Daten direkt zu sharen, also ein virtuelles Verzeichnis

50 MATERIAL UND SOFTWARE 44 zwischen den Clients aufzubauen;die Daten müssen zuerst in das Virtuelle Verzeichnis, d.h. auf einen Server kopiert werden. Des weiteren sind keine Mechanismen für Ad-hoc-Gruppenbildung und Authentifizierung implementiert. DARC DARC, die Beispielimplementation zu den Forschungen von wirelessgrids.net (siehe 3.1.1), will lediglich zeigen, welche Möglichkeiten Wireless Grids haben. Zur Implementierung wurden, um ein lauffähges Ergebnis zu erzielen, vorhandene Techniken aus den Bereichen der mobilen Netzwerke benutzt aber nicht das angestrebte Protokoll. Auch hier wurde nicht auf der Basis der Gridforschung aus dem Wired Bereich aufgebaut. egd - Tools Der Vorteil der edg - Tools liegt eindeutig in der Fähigkeit, in Verzeichnisstrukturen auf entfernten Rechnern arbeiten zu können, ohne vorher eine manuelle Verbindung (wie z.b. bei SSH 2 ) herstellen zu müssen. Doch bringt diese Eigenschaft auch einen Nachteil mit sich. Für jede Aktion, z.b. für jedes Listen eines Verzeichnisses, muss eine Neu-Authentifikation durchgeführt werden. Eine Authentifikation benötigt Zeit, und deshalb würde der Aufbau des virtuellen Verzeichnisse unnötig verzögert. Was also fehlt, ist eine Anwendung, die auf der Software der Wired Gridforschungen aufbaut (siehe Abschnitt 2.2), gleichzeitig aber den Anforderungen an ein Wireless Grid gerecht wird (siehe Abschnitt 3.1). Damit wird zum einen eine Kompatibilität erzielt, die es auch Anwendern eines festen Arbeitsplatzes erlaubt, Daten mit mobilen Nutzern sharen zu können, zum anderen werden die Möglichkeiten des Grids, die es bisher nur in verkabelten Netzwerken gab, in die 2

51 MATERIAL UND SOFTWARE 45 Welt der kabellosen Benutzeranwendungen gebracht. Solch eine Anwendung soll im Folgenden beschrieben werden. 4.5 Prüfung der vorhandenen Gridsoftware In diesem Abschnitt werden die einzelnen Gridumgebungen, Gridsoftwares und Toolkits vorgestellt, die momentan existieren und zum Aufbau einer Testumgebung genutzt werden könnten. Diese Aufzählung erhebt keinerlei Anspruch auf Vollständigkeit. Es werden lediglich beispielhaft Projekte aufgeführt, um einen Überblick über die verschiedenen Techniken zu schaffen Legion Legion 3 ist eine Middleware, die Netzwerke, Supercomputer und Workstations zu einem System verbindet. Es ist gleich, welche Architektur verwendet wird, welches Betriebssystem eingesetzt ist oder an welchen Ort sich die Ressourcen befinden. Legion hat zum Ziel, Probleme, die über Organisationsgrenzen hinweg gehen, zu lösen. In einem Legionsystem gibt es keine zentrale Einheit. Jede Ressource ist ein unabhängiges Element, das über ein Framework in ein Metasystem eingegliedert wird. Das Metasystem ist für den Nutzer eine Virtuelle Maschine. Legion will die steigende Bandbreite in Wide Area und Local Area Networks nutzen, ohne die Netzwerksicherheit und -funktionalität zu beeinflussen, um so eigentlich inkompatible Plattformen zu vereinen. Erreicht wird das, indem Legion als Mittelschicht zwischen dem Betriebssystem und anderen Legionressourcen arbeitet. Dabei laufen die Legionprozesse, die auf Bibliotheken, Source Code und ausführbaren Binary Dateien basieren, als Programm im Betriebssystem ab. Legion baut auf dem Konzept eines einzelnen, einheitlichen Objekt Models auf. Alles in Legion ist ein Objekt. Jedes dieser Objekte ist ein aktiver Prozess, der mit anderen Objekten kom- 3 legion/

52 MATERIAL UND SOFTWARE 46 muniziert. Einzelne Objekte werden von ihrem jeweiligen Klassenobjekt verwaltet, das eine System Anlage ist. Anwendung findet Legion zum Beispiel in Avaki 4, die dem Kunden eine einfache, verteilte Datenintegration versprechen Cactus Cactus 5 ist eine Open Source Umgebung, die entwickelt wurde, um Forscher und Entwickler bei der kollaborativen Arbeit zu unterstützen. Durch den modularen Aufbau, ermöglicht Cactus ein Arbeiten über die Grenzen der verschiedenen Betriebssysteme und Architekturen hinweg. Der Name Cactus kommt vom Design des Toolkits, mit einem zentralen Kern (dem Fleisch), über den r sich über ein einheitliches Interface mit den verschiedenen Modulen (den Stacheln, Thorns) stülpt. Thorns können entweder spezielle wissenschaftliche oder kollaborative Anwendungen sein oder sie stellen Kernfunktionalitäten, wie parallel Ein - / Ausgabe, verteilte Datenhaltung oder Checkpointing bereit. Solche Thorns sind Teil des von Cactus bereitgestellten Standard Toolkit. Das Fleisch speichert die Variablen eines Grids, also die Einstellungen jedes einzelnen Thorns, in einer Datenbank. Für das Erstellen und Verwalten der Variablen ist aber der Driver Thorn zuständig. Dieser teilt den einzelnen Thorns Ressourcen zu und verwaltet Schleifen. Die Philosophie des Projektes lautet: Portabilität Erweiterbarkeit Modularität

53 MATERIAL UND SOFTWARE Access Grid Dieses Projekt ist kein Toolkit, das Grundfunktionalitäten bereitstellt, um ein Grid zu erstellen, sondern es baut auf bereits bestehenden Funktionen vom Globus Toolkit (siehe Abschnitt 4.6) auf. Ich erwähne diese Projekt, da hier eine Kollaborationsumgebung anhand eines Grids umgesetzt wurde. Dies könnte für nachfolgende Arbeiten interessant sein. Das Access Grid 6 ist ein Zusammenspiel von Ressourcen, die zur kollaborativen Arbeit genutzt werden können. Solche Ressourcen sind z.b. Multimedia Bildschirme, Präsentations- und Interaktionumgebungen oder Schnittstellen zur Gridmiddleware. Das Access Grid soll eine Gruppe zur Gruppenkommunikation über das Grid unterstützen und damit zum Beispiel online-meetings, Besprechungen und Schulungen ermöglichen. So genannte designed spaces sollen durch ihre High-Tech Audio- und Videoaustattung eine ideale Umgebung für solche Szenarien bieten. Um eine Kollaboration in Gruppen zu ermöglichen, werden Virtual Venues [12] gegründet. Virtual venues sind virtuelle Räume, deren Eigenschaften denen eines wirklichen Raumes ähneln. Es gibt Ein- und Ausgänge, die Räume sind nur für bestimmte Benutzer betretbar und auch sicher. Eine Kommunikation ist nur innerhalb dieser Räume und nur mit Benutzern, die sich in diesen Räumen aufhalten, möglich. Virtual Venues basieren auf zwei Dingen [13]: Die Virtual Venues stellen die Grundlagen, wie Sicherheit, Eindeutigkeit der Benutzer und die Authentifikation bereit. Die Venue Server stellen ein Interfaces, mit dem Virtual Venues erstellt, zerstört und verwaltet werden können bereit. Des weiteren kann ein Server mehrere Venues managen. Er stellt diesen folgende Funktionen zur Verfügung: Datenspeicherung, Multicast-Adressreservierung und eine Liste mit Services, die jedem Virtual Venue zur Verfügung steht. Umgesetzt wird das Projekt in Python. Die Gridbasisfunktionen stellt das Globus Toolkit bereit und wird über pyglobus eingebunden. 6

54 MATERIAL UND SOFTWARE Grid Bus Das Gridbus Projekt 7 sucht nach Lösungen, um ebussines- und esience- Interaktionen mit einem hohen Datenaufkommen zu ermöglichen. Um dies zu erreichen, wurde ein Toolkit erstellt, das auch Teile des Globus Toolkits verwendet, nämlich GRAM, GASS, MDS und GSI (siehe Abschnitt 4.6. Gridbus stellt visuelle Entwicklungstools für Grid Applikationenen, einen wettbewerbsfähigen Grid Scheduler, einen Cluster Scheduler, ein Webservice basiertes Grid Market Directory (GDM) und ein Grid Accounting Service, bereit, um nur einige Features zu nennen [17]. Die Services werden in High- und Lowlevel - Services aufgeteilt. In der in verschiedenen Ebenen gegliederten Architektur, liegen unter den Services die Ressourcen und darüber die Anwendungen. Der Grid Service Broker [17] entscheidet, wo die Grid Jobs im Grid bearbeitet werden. Dabei achtet er auf die Eigenschaften der Ressourcen (Verfügbarkeit, Fähigkeit, Kosten), die Quality of Service Anforderungen des Benutzers und die Entfernung der benötigten Daten oder deren Replikationen. Für den entfernten Zugriff aus Daten wird ein transparentes Verfahren verwendet, das logische auf physische Namen abbildet. Jobs könne im Gridbus Grid vom Benutzer über den G-Monitor gestartet werden, der ein Webportal bereitstellt und auch Monitoring sowie die Verwaltung laufender Jobs erlaubt. Über das Grid Market Directory (GDM) werden die Virtual Organisations verwaltet. GDM ist eine Registry, in der Services eingetragen und gesucht werden können - hierdurch wird Service Discovery ermöglicht. GDM basiert auf SOAP und XML. Ein wichtiger Bestandteil des Projekts in Bezug auf den Einsatz im ebusiness ist GridBank. GridBank ist ein Accounting System, das die verbrauchten Ressourcen der einzelnen User speichert und aufbereitet. Das Service Orientierte Gridbus Projekt ist die Lösung einer australischen Forschergemeinschaft und wird von großen Firmen, wie zum Beispiel IBM 8 unterstützt

55 MATERIAL UND SOFTWARE Globus Toolkit Das Globus Toolkit ist das Standard Toolkit, um eine Gridumgebung zu erstellen. Das Toolkit wurde und wird nach den Vorgaben der Open Grid Service Architektur (siehe Abschnitt 2.2) entwickelt. Die Entwickler der OGSA sind auch an der Entwicklung des Globus Toolkits beteiligt. Sonst wird die Entwicklung von dem Globus Consortium und dem Global Grid Forum vorangetrieben. Das Tool- Abbildung 4.2: Figur zeigt die Komponenten und deren Unterteilung in der Version GT4 kit ermöglicht es, Rechenleistung, Datenbanken und andere Ressourcen über die Grenzen von Organisationen hinweg sicher zu sharen, ohne die Autonomie und die lokalen Sicherheitsrichtlinienen zu beeinflussen. Globus beinhaltet Software für die Sicherheit, die Infrastruktur der Informationen, das Resource Management,

56 MATERIAL UND SOFTWARE 50 das Daten Management, die Kommunikation, die Fehlerfindung und die Portabilität. Die Software ist in Pakete unterteilt, die unabhängig voneinander benutzt werden oder im Verband eine mächtige Gridumgebung bilden können. Diese Umgebung, bestehend aus den Core Services, den Interfaces und den Protokollen, bietet dem Nutzer die Möglichkeit, entfernte Ressourcen so zu nutzen, als ob sie lokal zur Verfügung stünden. Das Globus Projekt ist im Umbruch zu einer Service Orientierten Grid Umgebung. Deswegen gibt es in der aktuellen Version GT3 (Ver ) ein Gemisch von Webservice Komponenten und Non-Webservice Komponenten. In der nächste Version GT4 wird es zwar weiterhin Non-Webservice Komponenten geben, doch werden diese nach und nach verschwinden und durch Webservice Komponenten ersetzt. Dieser Schritt wird vollzogen, um der OGSA gerecht zu werden. Das Globus Toolkit ist in verschiedenen Ebenen unterteilt. Auf der untersten Ebene befinden sich die lokalen Services, die für die Ressourcen zuständig sind. In der nächsten Ebene sind die Coreservices (z.b. Resource Broker, Datentransfer, Service Verwaltung) platziert, die ein Grid erst ermöglichen und darüber die High Level Services, die auf den Coreservices aufbauen und die große Funktionalität bereitstellen. Darüber befindet sich die Ebene der Applikationen. Diese können entweder auf die Highlevel Services oder direfkt auf die Core Services zugreifen. Die Services werden in logische Gruppen unterteilt: Security Data Management Execution Management Information Service Common Runtime

57 MATERIAL UND SOFTWARE Sicherheit - Grid Security Infrarstructure (GSI) Die Grid Security Infrarstructure ist die Sicherheitsstruktur, mit der im Globus Toolkit die Authorisation und Verschlüsselung durchgeführt wird. Sie wurde entwickelt, weil ein Bedarf an sicherer Kommunikation (Authentifikation und Verschlüsselung des Transfers) zwischen den einzelnen Elementen eines Grids, ein Bedarf an der Unterstützung von Sicherheit, die über die Grenzen von Organisationen hinweg geht und demnach ein zentrales Sicherheitssystem verbietet und, ein Bedarf an der Unterstützung für single-sign-on, das auch die Delegation von Rechten ermöglicht besteht. Das Prinzip auf dem GSI basiert ist die Public Key Kryptographie [4]. Diese Kryptographie [14, Kapitel 8] arbeitet mit zwei Schlüsseln. Allgemein kann ein geheimer Schlüssel zum Beispiel ein Passwort oder eine PIN sein. Wird ein Objekt mit dem sog. privaten und geheimen Schlüssel verschlossen, kann es nur mit dem passenden anderen Schlüssel, dem sog. öffentlichen Schlüssel, entschlüsselt werden. Es existieren also zwei Schlüssel. Der private und geheime Schlüssel mit dem die Nachrichten verschlüsselt werden. Und der öffentliche Schlüssel, mit dem die Nachricht entschlüsselt werden kann. Da GSI den privaten Schlüssel auf der lokalen Festplatte benötigt, um zu funktionieren, wird der private Schlüssel durch ein Passwort (Paraphrase) gesichert. Diese Public Key Kryptographie kann dazu verwendet werden, Dokumente digital zu signieren. Dazu wird ein Hashwert des Dokumentes erstellt - ein Hashwert ist eine SZusammenfassung des Objektes in Zahlen - dieser mit dem privaten Schlüssel verschlüsselt und an das Dokument angehängt. Soll die Unterschrift geprüft werden, wird der verschlüsselte Hashwert mit dem öffentlichen Schlüssel entschlüsselt und mit dem bekannte Hashwert verglichen. Außerdem eignet sich dieses Verfahren auch, um Vertrauensverhältnisse

58 MATERIAL UND SOFTWARE 52 und damit eine Authentifikation zu schaffen. Dies wird mit sog. Zertifikaten umgesetzt. Ein Zertifikat repräsentiert dessen Besitzer. Die Echtheit des Zertifikates wird durch eine Certificate Authority (CA) bestätigt, indem das Zertifikat von der CA digital signiert wird. Dies ist ein wichtiger Punkt. Auf die CA muss man sich verlassen, darauf beruht das notwendige Vertrauensverhältnis. Die CA bestätigt die Echtheit des Zertifikats und damit die Vertrauenswürdigkeit sowie Identität des Besitzers. Ein GSI - Zertifikat enthält einen Namen, der den Eigentümer oder das Objekt repräsentiert (CName), den dazugehörigen öffentlichen Schlüssel, die Identität der CA und die digitale Unterschrift der CA. Die Zertifikate sind nach dem X.509 Format der IETF 9 kodiert und können so auch von anderen Public-Key-Mechanismen genutzt werden (z.b. von Webbrowsern). Besitzen also zwei Partner ein Zertifikat und das Vertrauen der CA, die das Zertifikat signiert hat, dann können sie wechselseitig ihre Identität sichern. Der CA vertrauen heißt, den öffentlichen Schlüssel der CA zu besitzen. Die sichere Identifikation erfolgt in mehreren Schritten. Person 1 muss Person 2 ihhre Identität nachweisen und umgekehrt. Dies nennt man Mutual Authentication. Um diese Schritte durchzuführen, benutzt GSI den Secure Socket Layer (SSL/TLS) 10. Authorisierungsablauf bei SSL/TLS Nehmen wir an, A will sich bei B authentifizieren. A schickt also nach dem Verbindungsaufbau B sein Zertifikat. B prüft die Identität von A, indem B kontrolliert, ob auch wirklich die angegebene CA das Zertifikat signiert hat. An dieser Stelle

59 MATERIAL UND SOFTWARE 53 muss B der CA trauen, die das Zertifikat von A signiert hat. Ist B sich der Echtheit des Zertifikates sicher, muss nun geprüft werden, ob A tatsächlich der Absender des Zertifikats war. Also generiert B eine zufällige Nachricht für A und bittet A diese verschlüsselt an ihn zu senden. Kommt die Nachricht zurück und kann B sie mit dem erhaltenen Zertifikat entschlüsseln, ist sichergestellt, dass A sicher der Absender ist. Nun muss A noch die Identität von B sicherstellen: Hier müssen die gleichen Schritte noch einmal durchgeführt werden, also 1. B schickt A sein Zertifikat. 2. A prüft die Echtheit. 3. A generiert eine Nachricht, die B verschlüsselt zurücksenden soll. 4. A versucht mit dem Zertifikat von B die Nachricht zu entschlüsseln. 5. Ist die Entschlüsselung erfolgreich, trauen sich A und B. Abbildung 4.3: Die Bildung einer Vertrauenskette single-sign-on Durch eine Erweiterung des SSL Protokolls von GSI wird single-sign-on ermöglicht. single-sign-on bedeutet, dass sich ein Benutzer nur einmal autorisieren muss und damit alle Dienste des Grid nutzen kann. Da normalerweise jeder Service eine Authorisation verlangt, müsste bei jeder Aktion das Passwort eingeben. Mit GSI wird dies umgangen, indem ein Proxy-Zertifikat erstellt wird. Ein

60 MATERIAL UND SOFTWARE 54 Proxy-Zertifikat besteht aus einem neuen Zertifikat mit einem neuen öffentlichen Schlüssel und einem neuen privaten Schlüssel. Signiert wird das Proxy Zertifikat mit dem eigenen privaten Schlüssel. Das neu erstellte Zertifikat enthält die leicht abgeänderte Identität des Benutzers, um es als ein Proxy zu identifizieren. Das Proxy Zertifikat enthält einen Zeitstempel, der angibt, bis wann das Proxy gültig ist. Da das Proxy-Zertifikat also nur eine bestimmte Gültigkeitsdauer hat, kann der private Schlüssel durch einfache Benutzerrechte im lokalen Dateisystem aufbewahrt werden, und so immer, ohne ständig ein Passwort eingeben zu müssen, vom System zur Authentifikation benutzt werden. Die Authentifikation läuft mit einem Proxy aber etwas anders ab als die der Authentifikation mit SSL/TLS. Der Empfänger der Authorisationsanforderung empfängt nicht nur das Proxy, sondern auch das echte Zertifikat des Antragstellers. Über das originale Zertifikat prüft er die Echtheit des Proxys, um dann die Authentizität des Originales anhand der CA zu prüfen. So entsteht eine Vertrauenskette (siehe GridFTP GridFTP [3] [7], der de facto Standard für Datenübertragung in einem Grid [33], ist ein Datenübertragungsprotokoll, das für große Datenmengen, große Bandbreite und Wide Area Netzwerke (WAN) konzipiert wurde, also eigentlich kein Protokoll, das den Anforderungen eines Wireless Grid (siehe Abschnitt 3.1) entspricht. Doch es bietet eine Anzahl nützlicher Eigenschaften, wie Sicherheit und Vertrauenswürdigkeit. GridFTP baut auf dem bekannten FTP 11 Protokoll auf und wurde hauptsächlich durch Sicherheitseigenschaften durch die Nutzung von GSI (siehe Abschnitt 4.6.1) erweitert. GridFTP bietet folgende Eigenschaften [3] GSI Sicherheit in den Kontroll und Datenkanälen Viele Datenkanäle für parallele Übertragung 11

61 MATERIAL UND SOFTWARE 55 Partiellen Datentransfer Third-Party Transfer, d.h. ferngesteuerte Server zu Server Übertragung Authentifizierte Datenkanäle Wiederverwendbare Datenkanäle Parallelverarbeitung von Kommandos Reliable File Transfer (RFT) RFT [33] erweitert GridFTP zu einem OGSA kompatiblen Service. Durch das Hinzufügen von weiteren Eigenschaften wird der Datentransfer im Grid noch skalierbarer. RFT verhält sich aus der Sicht des Benutzers wie ein Proxy. Diesem Proxy werden Aufträge erteilt. Danach erledigt der Proxy den Auftrag ohne weiteres Eingreifen des Users, d.h. dass ein User seinen Client auch vom Netzwerk trennen kann. Sobald der User wieder mit dem Netzwerk verbunden ist, führt der Proxy den Transfer fort Informatmion Service (MDS) Mit jeder Service-Instanz im Globus Toolkit sind Service Daten verknüpft. Service Daten beschreiben die Instanz und geben z.b. Auskunft über deren Status, können also statisch oder dynamisch sein. Der Information Service stellt eine Schnittstelle zu den Service Daten bereit. Dadurch wird es möglich Service Daten zu erstellen, zu sammeln und zu durchsuchen. Der Index Service benutzt dazu ein erweiterbares Framework. Jedem Service sind bestimmte Service Daten durch seine Konfiguration zugeteilt und nur auf diese Daten kann der Index Service erstellen. Der Index Service stellt folgende Möglichkeiten zur Verfügung [6]:

62 MATERIAL UND SOFTWARE 56 Eine Schnittstelle um Programme externer Service Daten Anbieter mit den Service Instanzen zu Verbinden Der Index Service stellt einen standardisierten Mechanismus bereit, mit extern Programme dynamisch Service Daten erstellen können. Ein einfaches Framework, um Service Daten zu sammeln Service Daten, die auf verschiedenen Wegen erstellt werden können, können auch auf verschiedene Arten indexiert werden, um verschiedene Sichtweisen auf die Daten zu ermöglichen. Der Index Service nutzt die standardisierten Benachrichtigungsmechanismen, um eine Benachrichtigung (notification) und Indexierung (subscription) umzusetzen. Eine Grid Service Registrierung: Eine Anzahl von Grid Services wird in einer Registry verwaltet. Dort können Services soft-state registriert werden und, falls nötig, ihre Einträge periodisch aktualisiert werden. Die Registry ermöglicht es, verschiedene Operationen an dem Service auszuführen, z.b. lifetime, query und Service-data-aggregation. Eine Registry wird auch eine Servicegruppe (Service Group) genannt. Ein dynamischer Knoten, der Daten erstellt und indexiert, die zu hierarchischen oder föderalen Services passen Replica Location Service (RLS) Der Replica Location Service [5] hat die Fähigkeit, Informationen logischer Namen auf Dateien abzubilden und verwaltet diese Verknüpfungen. Im Replica File Cataloge (RFC) wird der Status der festen Verknüpfungen gespeichert. Hier werden die Mappings der logischen Namen (LFN, Logical File Name) auf die physischen Namen (PFN, Physical File Name) verwaltet. Im Replica Location Indice (RLI) werden Gruppen von LFNs und deren Beziehungen zu RFCs verwaltet. Damit kann bei einzeln Gruppen die Performance geregelt werden (Lastverteilung).

63 MATERIAL UND SOFTWARE 57 Über ein soft-state Protokoll teilen die LRC den RLI ihren Status mit. So kann die Lastverteilung optimiert und Ausfälle oder Überlastungen verhindert werden. Auswahl des Globus Toolkits Weil ich es -wie die Entwickler der OGSA - für wichtig erachte, einem Standard zu folgen, habe ich mich für das Globus Toolkit entschieden. Mit der OGSA wurde ein Standard definiert und das GT basiert auf der OGSA. Das GT ist zwar nicht die optimale Lösung für ein Wireless Grid, weil es eigentlich für Daten- und rechenintensive Grids geschaffen wurde. Aber durch die Wandlung in eine Service Orientierte Software, bieten sich für Anwendungen im Endanwenderbereich neue Möglichkeiten. Und damit auch für ein Wireless Grid. Das GT habe ich nicht nur gewählt, weil es auf der OGSA basiert. sondern es bildet mit den oben beschriebenen Core Services eine gute Grundlage, um das in Abschnitt 4.2 vorgestellte Szenario auch umzusetzen.

64 Kapitel 5 Umsetzung 5.1 Beschreibung des Document Sharing Service Nun soll eine Software beschrieben werden,die die in Abschnitt 3.1 gestellten Anforderungen erfüllt. Diese Software soll ein OGSA konformer Service sein (DSS), der auf dem Globus Toolkit basiert. Um eine OGSA konformen Service zu erstellen, benutzt man die zu den Services dokumentierten Interfaces. Dies ergibt sich von selbst, will man die Services des Globus Toolkits nutzen Erster Entwurf Ein erster Entwurf, das virtuelle Verzeichnis zu erstellen war kein Service, sondern vielmehr ein Skript, das die Fähigkeiten einiger Tools nutzte. Den wichtigsten Bestandteil stellte, aus den edg - Tools (siehe Abschnitt 3.3), edg-gridftp-ls dar. Mit diesem Tool können, ohne ein Passwort eingeben zu müssen (sofern ein Proxy Zertifikat erstellt ist (siehe Abschnitt 4.6.1), Verzeichnisse auf entfernten Computern gelisten werden. Das Tools ist an des ls - Befehl aus den UNIX/Linux -Shells angelehnt. Sollte also ein virtuelles Verzeichnis erstellt werden, musste mit edggridftp-ls jedes Verzeichnis, das zum Sharen angeben war, auf jeden teilnehmenden 58

65 UMSETZUNG 59 Computer aufgelistet werden. Das Skript kümmerte sich dann um das Sortieren zu einem virtuellen Verzeichnis. Zu jeder Datei des virtuellen Verzeichnisses war der Pfad hinterlegt, sodass, bei Bedarf, mit GridFTP der Datentransfer gestartet werden konnte. Diese Aktion konnte schon transparent gestaltet werden, doch gab es viele Nachteile. Um die Aktualität des virtuellen Verzeichnisses zu gewährleisten, musste in regelmäßigem Abstand, jedes Verzeichnis der Teilnehmer von jedem Teilnehmer neu eingelesen werden. Dieser PULL - Mechanismus ergab einen unnötig hohen Datentransfer, ohne dass überhaupt Dokumente oder andere Dateien transportiert wurden. Des weiteren resultiert aus der Tatsache, dass bei jedem Listen eine Authentifikation mit dem Proxy - Zertifikat bei dem entfernten Rechner stattfinden muss, eine deutlich spürbare Verzögerung, die den Benutzer unnötig aufhält (siehe Abschnitt 6.1) Vorschlag für die Umsetzung Da die Entwicklung in Richtung Grid Services geht, gerade weil das von der OGSA vorgeschrieben wird, floss der Service Ansatz auch in den zweiten, jetzigen Entwurf ein. Der Document Sharing Service nutzt für die Sicherheit die Grid Security Infrarstructure (siehe Abschnitt 4.6.1) und für den Datentransfer GridFTP (siehe Abschnitt 4.6.2). In Abbildung 5.1 wird die Integration des Document Sharing Service in das Globus Toolkit gezeigt. Die anderen Anforderungen sollen mit DSS umgesetzt werden. Für eine eventuelle Erweiterung des DSS wird später noch auf das Monitoring and Discovery System (siehe Abschnitt 4.6.4) und auf den Replica Location Service (siehe Abschnitt 4.6.5) eingegangen. Der Document Sharing Service folgt folgendem Muster: Discovery and Join: DSS - Stationen werden entdeckt, indem HELLO Pakete (broadcast) verschickt werden. Empfängt eine DSS - Station ein HELLO Paket, so kann der Benutzer entscheiden, ob der neue Teilnehmer seinem virtuellen Verzeichnis beitreten kann.

66 UMSETZUNG 60 Authentication: Die Authentifikation kann nur gewährt werden, wenn der Benutzer ein gültiges Zertifikat, das von einer vertrauenswürdigen Certification Authority gezeichnet wurde, besitzt und ein Proxy-Zertifikat erstellt hat. Usage: Ist das virtuelle Verzeichnis erstellt, kann der Benutzer Dokumente kopieren, lesen und synchronisieren. Withdrawl: Wird ein Benutzer vom WLAN getrennt oder entscheidet er sich, das virtuelle Verzeichnis zu verlassen indem er ein GOODBYE Paket sendet, so werden alle Inhalte des Verlassenden aus dem virtuellen Verzeichnis entfernt. Service Discovery Die Service Discovery wird mit dem DSS umgesetzt. Jede DSS - Station sendet, solange sie noch kein Mitglied des virtuellen Verzeichnisses ist, so genannte HELLO Pakete. Diese Pakte beinhalten im Header eine DSS Versionsnummer, die sie als DSS - HELLO - Paket auszeichnen. Des weiteren ist das Zertifikat und der Rechnername des Benutzers enthalten. Die einzelnen DSS - Station lauschen im Netzwerk auf solche Pakete. Wird eines empfangen, kann ein virtuelles Verzeichnis mit dem Sender des HELLO - Paketes aufgebaut werden. Da DSS momentan nur für die Verwendungen in einem abgeschlossenen kleinen Netzwerk mit wenigen Teilnehmern vorgesehen ist, ist dies eine schnelle und praktikable Lösung. Im Einsatz in einem großen, nicht abgeschlossenen Netzwerk, mit einer größeren Teilnehmerzahl oder sogar Teilnehmern aus anderen Netzen, muss ein anderer Mechanismus eingesetzt werden (siehe Abschnitt 6.4).

67 UMSETZUNG 61 Abbildung 5.1: Die Integration des DSS in das Globus Toolkit Sicherheit - GSI Die Sicherheit, d.h. die Authorisation, die Benutzerrechte und die Verschlüsselung, basieren auf der Grid Security Infrarstructure. Im Abschnitt wurde diese ausführlich beschrieben. GSI ist von Grund her eine statische Struktur. Nach den in Abschnitt 4.3 definierten Anforderungen, muss die Authorisation aber dynamisch durchführbar sein. Um dies zu ermöglichen, wurde in DSS ein dynamisches Authorisationsverfahren integriert, nach dem Vorbild einer Authorisationsanfrage in einem Messenger Protokoll, z.b. ICQ s OSCAR 1. Nachdem ein HELLO - Pakete empfangen wurde, wird als erstes überprüft, ob der Sender des HELLO - Paketes schon bekannt ist. DSS greift auf eine Datenbank zurück, in der autorisierte Benutzer abgelegt sind. Ist der Sender noch nicht bekannt, wird der Benutzer gefragt, ob der Sender autorisiert werden soll. Der Benutzer hat drei Auswahlmöglichkeiten: 1 ss auth.html

68 UMSETZUNG 62 accept: Er akzeptiert den Sender und der Authorisationsvorgang kann fortgeführt werden dismiss: Er lehnt den Sender für diese Sitzung, also für eine bestimmte Zeitspanne, ab. Bei einer neuen Sitzung oder nach einer bestimmten Zeitspanne, wird die Authorisationsanfrage des Senders neu geprüft ignore: Der Sender wird blockiert, d.h. alle Anfragen werden verworfen und nicht geprüft. Die Sperrung kann nur manuell vom Benutzer widerrufen werden, indem er den Sender freischaltet. Hat der Benutzer den Sender akzeptiert, so wird ein Vertrauensverhältnis geschaffen (siehe 4.6.1), d.h. das Zertifikat wird auf Echtheit und der Sender auf Vertrauenswürdigkeit geprüft. Ist der Sender nicht vertrauenswürdig, so wird er ignoriert und der Benutzer informiert. Ist der Sender vertrauenswürdig, so wird von DSS ein dynamischer Eintrag in das grid-map File geschrieben. Der CName des Senders wird auf einen speziell für DSS angelegten Sharing User abgebildet. Es ist mit GSI möglich, mehrere CNames auf einen lokalen User abzubilden, so haben alle DSS - User die gleichen Benutzerrechte. Des weiteren wird der Sender in die Benutzerdatenbank eingetragen. Nun kann das virtuelle Verzeichnis erstellt werden Virtuelles Verzeichnis Das virtuelle Verzeichnis wird nach dem Vorbildern des Meta Directory System (siehe Abschnitt 4.6.4), dem Replica Location Service (siehe Abschnitt 4.6.5) und Alien (siehe Abschnitt 3.3) erstellt. Nachdem die User Authentifiziert sind, werden die jeweiligen Inhalte der zu sharenden Verzeichnisse an den anderen Teilnehmer geschickt. Dies könnte nach dem Vorbild von Xmiddle (siehe Abschnitt 3.3) über ein XML Dokument geschehen. In einer Datenbank werden die physikalischen Namen auf logische Namen abgebildet (Tabelle 5.1). DSS prüft die Dateinamen und

69 UMSETZUNG 63 hängt, bei der Existenz von Konflikten, den CName des Besitzer an den Logischen Namen der Datei. Ein Eintrag könnte wie folgt lauten: physical name testrechner/shared directory/test.txt logicale name Tabelle 5.1: Eine physische Dateie wird auf einen logischen Namen gemappt Nach Wunsch könnten dann solche Dateien auch synchronisiert werden. Dies ist aber noch nicht in den Entwurf integriert. Sollten zwei Dateien auch vom Inhalt her identisch sein, würde nur eine dieser Dateien im virtuellen Verzeichnis gezeigt und in der Datenbank wären auf einen logischen Namen, zwei physische Namen abgebildet (Tabelle 5.2). physical name testrechner/shared directory/test.txt testrechner2/shared directory/test.txt logicale name test.txt Tabelle 5.2: Zwei physische Dateien mit gleichen Namen werden auf einen logischen Namen gemappt Die Datenbakeinträge existieren nur, solange der Benutzer auch im virtuellen Verzeichnis arbeitet. Verlässt dieser das virtuelle Verzeichnis, wird die Datenbank gelöscht und es wird an die anderen Benutzer ein GOODBYE - Pakte gesendet. Dies ist ein Multicast - Paket dessen Inhalt der CName des Benutzers und eine Meldung (Withdrawl) enthält. Um Dead Members, also Benutzer die vom WLAN getrennt wurden, zu vermeiden, wird in einer bestimmten Periode ein ALIVE - Paket gesendet, das nur den CName des Benutzers beinhaltet. Wird dieses nach einer bestimmten Zeit nicht mehr von den Teilnehmern empfangen, wird dieser Benutzer automatisch aus dem virtuellen Verzeichnis gelöscht. Möchte man eine lokale Kopie einer Datei, so wird gridftp (siehe Abschnitt 4.6.2) gestartet. Bei Änderungen an dem lokalen Verzeichnis, wird an alle Mitglieder des virtuellen Verzeichnisse, die neue Verzeichnisstruktur gesendet und die

70 UMSETZUNG 64 Datenbanken können so ab geglichen werden. Durch dieses PUSH - Verfahren entsteht nur Datenverkehr, wenn die auch nötig ist Transfer - GridFTP Der Transfer der Daten wird über GridFTP (siehe Abschnitt 4.6.2) abwickelt. Das Protokoll kann über die OGSA kompatiblen Interfaces eingebunden werden Grafisches Interface Das grafische Interface zu DSS sollte intuitiv und einem gängigen Dateibrowser ähnlich gestaltet sein. Dies ergibt sich aus den in Abschnitt 4.3 gestellten Anforderungen. In Abbildung 5.2 wird ein Prototyp des grafischen Benutzerinterfaces dargestellt. Wie bei einem gängigen Dateibrowser - hier: an den Aufbau des Nautilus - Dateimanager 2 des Gnome - Projektes angelehnt - gibt es eine Menüleiste (1 in Abb. 5.2), in der Funktionen, wie z.b. Ordner erstellen, Datei kopieren und Datei suchen untergebracht sind. Die Navigation erfolgt, ebenfalls wie von einem Dateibrowser gewohnt, entweder durch klicken auf die Ordner (3 in Abb. 5.2), über die Tastatur oder über die Navigationselement (2 in Abb. 5.2). Die Dateien können wahlweise in Listenform (3 in Abb. 5.2) oder in Symbolansicht gezeigt werden. Im Beispiel sieht man, wie zwei Dateien mit gleichem Namen der Benutzername angehängt wird. In Listenansicht können die Eigenschaften der Dateien, wie Größe und Änderungsdatum angezeigt werden. Das besondere am DSS - Interface, im Gegensatz zu herkömmlichen Dateibrowsern, sind die drei Eigenschaften (4 in Abb. 5.2). sync: Existieren zwei Dateien mit gleichem Dateinamen, können diese auf Wunsch synchronisiert werden. Entweder über einen Eintrag im Menü oder direkt über das angezeigte Symbol 2

71 UMSETZUNG 65 save: Ist eine Datei nicht lokal gespeichert, kann diese entweder über das Menü oder direkt über das Symbol lokal verfügbar gemacht werden local: Ist die Eigenschaft mit einem Haken gekennzeichnet, bedeutet dies, dass die Datei lokal gespeichert ist Abbildung 5.2: Entwurf eines grafischen Interfaces für den DSS

72 UMSETZUNG 66 Abbildung 5.3: Ablaufdiagramm: Der komplette Ablauf eines Aufbaus eines Virtual Directories mit DSS

73 Kapitel 6 Analyse In diesem Kapitel soll geprüft werden, inwieweit die Ergebnisse, die getsellten Anforderungen erfüllen. 6.1 Performance Messungen Die Diplomarbeit beschäftigt sich mit den Möglichkeiten, die aktuelle Grid Software einem Wireless LAN bietet und inwieweit diese Software schon in einem WLAN genutz werden kann. Ein wichtiger Bestandteil für einen sinnvollen Einsatz ist neben den Features auch die Performance der Software. Es ist nicht sinnvoll eine Software einzusetzten, die zwar alle gestellten Anforderungen erfüllt, aber durch ihre Trägheit den Arbeitsablauf Abbildung 6.1: Der Testaufbau im Ad-hoc-Modus stört, statt ihn zu verbessern. Dabei darf aber nicht außer acht gellassen werden, dass gewisse Anforderungen, meist Sicherheitsanforderungen, auch automatisch zu Performanceverlusten führen. Mit dieser Messung soll nun festgestellt werden, 67

74 ANALYSE 68 ob der Einsatz von Grid Software, mit speziellem Augenmerk auf die Performance, sinnvoll ist Was soll gemessen werden? Bei dieser Messung soll die Performance der einzelnen Komponeneten von DSS (siehe Abschnitt 5.1) untersucht werden. Dabei werden folgende Daten erhoben: Dauer des listens der Verzeichnisse in Sekunden Dauer des Daten Transfers in Sekunden Geschwindigkeit des Transfers in Kilo Byte pro Sekunde (kbyte/s) Das Listen der Verzeichnisse wird mit edg-gsiftp-ls (siehe Abschnitt 3.3) ausgeführt. Diese Tool wird in Messung miteinbezogen, obwohl es letzendlich keine Verwendung in DSS gefunden hat hat. Es zeigt aber interressante Fähigkeiten und war lange Zeit ein wichtiger Bestandteil des Projektes. Einen Nutzen hat die Verwendung des Tools aber in Bezug auf die Performance Messung: Durch die geringe Größe der zu übertragenden Daten bei einem Listen, kann die Dauer der Authentifikation gezeigt werden. Um ein Vergleich zu aktuellen Techniken zu haben, wird auch die Performance von SAMBA 1 untersucht. SAMBA bietet allerdings nicht direkt die Möglichkeiten, die DSS bietet. SAMBA hat weder die Möglichkeit remote Verzeichnisse zu listen, noch Dateien zu übertragen. Auch bietet SAMBA nicht solch umfangreiche Sicherheitsoptionen. Um Dateien und Verzeichnisse über die Konsole zu übertragen und zu listen, müssen diese in Linux gemountet werden. Die Test Aktionen müssen über die Konsole erfolgen, um eine eventuelle Verzögerung durch eine Grafische Benutzeroberfläche, zu vermeiden. Vergleichbare Daten sind also nur: 1

75 ANALYSE 69 Dauer des Daten Transfers in Sekunden Geschwindigkeit des Transfers in Kilo Byte pro Sekunde (kbyte/s) Messablauf Der Testaufbau besteht aus 3 Computern (siehe Abbildung 6.1 und 6.2): Ein Laptop der als Client1 bezeichnet wird, ein Desktop Rechner der als Client2 bezeichnet wird und ein Desktop Rechner, der als Messsation genutzt wird. Der Messvorgang ist für jede Variante (DSS, SAMBA) in 2 Durchläufe aufgeteilt. Einmal sollen die Messdaten in einem Ad-Hoc-Wireless LAN erhoben werden und einmal in einem managed Wireless LAN (WLAN mit Access Point). Diese Aufteilung soll ausschliessen, dass durch einen Accesspoint die beiden Verfahren beeinträchtigt werden. Desweiteren wird darauf geachtet, dass beiden Verfahren die gleiche Bandbreite zur Verfügung steht. In jedem Durchlauf wird nach festen Vorgaben nacheinander das listen der Verzeichnisse und der Transfer von Daten. gemessen. Es werden jeweils 3 Dateien übertragen. Eine kleine (< 10kB), eine mittlere (< 1, 5MB) und einer grossen Datei (> 30MB). Hiermit soll festgestellt werden, ob bei verschiedener Anzahl der Elemnte, also verschiedener Grösse, in den Verzeichnissen, die Performance sich verändert. Jede Aktion wir zweimal vom Client1 auf den Client2 durchgeführt, um die gemessen Ergebnisse zu bestätigen. 6.2 Umsetzung mit den EDG - Tools Bei dieser ersten Variante eines Virtual Directory wurde für die Sicherheit, dass heisst Authentifikation und Verschlüsselung die Grid Security Infrarstructure

76 ANALYSE 70 (siehe Abschnitt 4.6.1) und für den Datentransfer GridFTP (siehe Abschnitt 4.6.2) verwendet. Das virtuelle Verzeichnis sollte mit mit edg-gridftp-ls erstellt werden. Die Benutzung der Tools sollte über ein Skript gesteuert werden. Damit konnten die Anforderungen wie Sicherheit und transparenter Datentransfer erfüllt werden. Aber um die Aktualität des virtuellen Verzeichnisses zu erhalten, musste in kurzen Abständen dieses mit edg-gridftp-ls überprüft und abgeglichen werden. Dieses PULL - Verfahren erhöhte unnütz den Datenverkehr im Netzwerk und war zusätzlich träge, da jede Aktualisierung eine Authentifikation bei jedem Mitglied des Virtual Directory erforderlich macht. Desweitern ist diese Umsetzung über ein Skript kein OGSA - konformer Service. Das bedeutet, dass dieses Konzept, bevor es richtig ausgearbeitet wurde, schon veraltet wäre. Aktuelle Gridanwendungen sollten nur noch als Service realisiert werden. Wie bereits erwähnt, wäre der Aufbau eines Virtuellen Verzeichnisses mit dieser Variante äußerst Träge, da die Inhalte der Verzeichnisse der anderen Teilnehmer über ein PULL Verfahren geholt werden müsste. Diese Aussage kann mit Messungen (siehe Abschnitt 6.1) belegt werden. Wie aus Tabelle A.1, dauert ein Listen eines Verzeichnisses auf einem entfernten Computer (hier: von Client1 auf Client2) ca. 4 Sekunden. Die Dauer des Aufrufs kommt Abbildung 6.2: Der Testaufbau hauptsächlich durch die Authentifikation auf im managed Modus dem entfernten Rechner zustande. Daduch ist die größte Aktualität, die mit diesem Verfahren erreicht werden kann 4 Sekunden, und zwar nur, wenn jede Sekunde alle Teilnehmer überprüft werden. Das heisst jede Sekunde müssten alle Teilnehmer an alle anderen einen entfernten Aufruf starten. So würde eine dauerhafter Netzwerkverkehr enstehen und somit die Batterie des Gerätes unnötig belastet. Verringert man die Anzahl der Aufrufe, um den Da-

77 ANALYSE 71 tenverkehr zu verkleinern, so wird das Risiko eingegangen, auf Daten zugreifen zu wollen, de schon nicht mehr verfügbar sind. Natürlich existiert auch die Lösung über einen PUSH den PULL zu starten, d.h. bei einer Änderung über eine Nachricht die Teilnehmer zu informieren, um dann edg-gridftp-ls zu starten, aber das würde wiederum eine Nachrichtenkette vorraussetzen, wie sie in DSS integriert ist, die es so aber im Globus Toolkit nicht gibt. 4 Sekunden sind eine spürbare Verzögerung, die aber bei einem Aufbau des Virtual Directory hinnehmen kann. Ändert man aber etwas am Virtual Directory, d.h. kopiert man z.b. eine Datei hinein, und diese Änderung wird im Betrieb frühestens nach 4 Sekunden wirksam, so ist das einen äußerst störende Beieinträchtigung der Arbeit. Da der Datentransfer dem in DSS gleicht, wird die Auswertung dieser Messung auf den nächsten Abschnitt verwiesen. 6.3 Umsetzung von DSS Auch DSS (siehe Abschnitt 5.1) baut auf der Grid Security Infrarstructure (siehe Abschnitt 4.6.1) für die Sicherheit und GridFTP für den Datentransfer (siehe Abschnitt 4.6.2) auf. Doch im Gegensatz zu dem im Abschnitt 6.2 beschriebenen Konzept wird das Virtual Directory über eine Datenbak aufgebaut. Auf jedem teilnehmenden Rechner existiert eine Datenbank. Diese werden mit DSS synchronisiert. Nur bei Änderungen des lokalen Verzeichnisses wird ein Multicast Paket verschickt. Dies hat zum einen den Vorteil, dass nur Datenverkehr anfällt, wenn Änderungen auftreten, zum anderen wird pro Änderung nur eine Nachricht geschickt und nicht eine Anfrage und die Antwort darauf. Zusätzlich werden in einem bestimmtem Zeitintervall Pakete an alle Teilnehmer versendet, die die Verfügbarkeit des Verzeichnisses bestätigen. Somit könnte eine Aktualität von einer Sekunde erreicht werden 2. Um aber einen andauenden Datenverkehr zu ver- 2 Da DSS nicht implemntiert ist, konnte keine Messungen vorgeniommen werden, deswegen beruht diese Aussage auf Sch ätzungen

78 ANALYSE 72 meiden, ist dies nicht empfehlenswert. Die Ad-hoc-Authentifizierung wird über eine Benutzerdatenbank, die von DSS verwaltet wird, ermöglicht. Die Datenkonsitenz wir durch eine einfachen Funktion, die bei doppelten Namen einfach den CName des Besitzers anhängt, gewährleistet. Indem das grafische Benutzerinterface an einen Dateibrowser angelehnt werden soll, ist dieses einfach und für jeden zu benutzen. Mit diesem Service können alle gestellten Anforderungen erfüllt werden. Doch stimmt auch die Performance? Da, wie gesagt, DSS nur ein Konzept ist und noch nicht umgesetz wurde, können die nur Grundfunktionalitäten diese Services, also Datentransfer mit GridFTP und Abbildung 6.3: Samba und GridFTP im managed Sicherheit mit GSI, getestet Modus werden. Dabei kam heraus, dass je größer die Datei, desto schneller der Transfer im Gegesatz zu SAMBA ist. Dies ist gut in den Abbildungen 6.3 und 6.3 zu sehen. Sie stellen die Dauer des Transfers (Y-Achse) für die einzelen Dateien (X-Achse) dar. Ist SAMBA bei einer Dateigrösse von 7,3 kb (klein) noch mehr als 4 Mal schneller als GridFTP, so ist die Dauer bei einer Dateigrösse von 1163 kb (mittel) schon gleich und bei einer Grösse der Datei von kb (gross) ist GridFTP die schnellere Übertragungstechnik (ca. 1,6 mal schneller).

79 ANALYSE 73 GridFTP erreicht zwar eine höhere Transferrate (siehe Tabelle A.1), doch dauert der Transfer wegen des Sichertheitsmechanismus länger. Die Authorisation dauert ca. 3-4 Sekunden. Dies kann indirekt aus den Mesergebnissen geschlossen werden, vergleicht man die Dauer der Übertragungen der kleinsten Abbildung 6.4: Samba und GridFTP im Ad-hoc- Datei und SAMBA, ohne Authorisation, ist der Transfer in Modus weniger als einer Sekunde abgewickelt; mit GridFTP dauert dieser 4 Sekunden. Bei der kleinen Menge, die Übertragen wird, kann man von etwa der gleichen Übertragungsgeschwindigkeit ausgehen. Also kann man auch für die reine Übertragung der Datei mit GridFTP weniger als eine Sekunde rechnen. Aus der Differenz zwischen angenommener Übertragung und tatsächlicher Dauer, ergibt sich dann ein Wert von 3-4 Sekunden. Aus diesen Messergergebnissen lässt sich schließen, dass DSS durchaus in der Lage wäre, einen Dateiaustausch in angemssener Geschwindigkeit durchzuführen. Die enstehenden minimalen Verzögerungen, lassen sich mit dem angewandten Sicherheitsmechanismus erklären. In Tablle 6.1, eine Erweiterung der Tablle 4.2, sind noch einmal alles Anforderung und ob diese erfüllt wurden aufgelistet. 6.4 Erweiterungen Damit sind alle Anforderungen erfüllt und die Aufgabe gelöst. Doch müssen auch Abstriche gemacht werden. Die vorgestellte Lösung ist nur auf Laptops in Verbin-