ProgrammingModels - Distributed and Parallel Systems Group
Werbung
Seminararbeit aus Grid Computing - 703404 GRID Applications, Environments and Programming Models Lehrveranstaltungsleiter: T. Fahringer Gruppe: Name Matrikelnummer Evelyn Schgaguler 0215547 Wolfgang Beikircher 0217230 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Inhaltsverzeichnis: 1. Kurzfassung ........................................................................................................................ 2 2. Einleitung ........................................................................................................................... 3 3. 2.1 Was ist eigentlich das Grid? ....................................................................................... 3 2.2 Softwarearchitektur des Grid...................................................................................... 5 2.3 Grid Applikationen ..................................................................................................... 6 Projekt Pegasus .................................................................................................................. 9 3.1 Überblick .................................................................................................................... 9 3.2 Eingabe der Workflows .............................................................................................. 9 3.3 Abbildung der abstrakten Workflows ins Grid ........................................................ 12 3.3.1 4. Arbeitsweise von Pegasus ................................................................................ 12 3.4 Reduktion von Workflows ....................................................................................... 13 3.5 Ausführung der Workflows ...................................................................................... 14 3.6 Anwendungen mit Pegasus ...................................................................................... 15 3.6.1 LIGO ................................................................................................................ 15 3.6.2 SCEC ................................................................................................................ 17 Projekt Karajan ................................................................................................................. 18 4.1 Verteilung der Arbeit ............................................................................................... 18 4.2 Vorraussetzungen für Karajan .................................................................................. 19 4.2.1 Jini .................................................................................................................... 19 4.2.2 Rio .................................................................................................................... 20 4.3 Ziele von Karajan ..................................................................................................... 20 4.4 Architektur von Karajan ........................................................................................... 21 4.5 Client delegation API ............................................................................................... 22 4.6 Das Ensemble Ereignis Modell ................................................................................ 23 4.6.1 4.7 Konfigurationsdatei .......................................................................................... 23 4.6.1.1 Definition eines Workflows ......................................................................... 23 4.6.1.2 Definition der Services ................................................................................. 23 Lifecycle Ereignismodell ......................................................................................... 25 5. Zusammenfassung ............................................................................................................ 27 6. Bibliographie .................................................................................................................... 28 1 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 1. Kurzfassung Diese Arbeit befasst sich mit Grid Applikationen, Umgebungen und Programmier Modellen. Jedoch bietet die Arbeit keine tiefgründigen Informationen, sondern soll nur einen Überblick geben. Zu Beginn wird ein kurzer Einblick über das Grid gegeben, um die Leser zunächst zu dem gewählten Thema „Grid Applikationen, Umgebungen und Programmiermodelle“ zu geleitet. Dabei wird die Frage „Was ist das Grid“ beantwortet, die generelle Softwarearchitektur und die Applikationen beschrieben. Im Hauptteil wird das eigentliche Thema behandelt, indem zwei Grid Applikationen vorgestellt werden: Pegasus und Karajan. Dabei wird unter anderem auf die Architektur und Arbeitsweise eingegangen. Zum Schluss werden in der Zusammenfassung noch die Schlussfolgerungen der Autoren der Seminararbeit wiedergegeben. Da diese Arbeit von zwei Personen gemeinsam verfasst wurde, möchte ich nun kurz die Aufteilung der verschiedenen Kapitel erläutern: - die Kurzfassung sowie, - die Einleitung wurden von Evelyn Schgaguler verfasst. - Das Projekt Pegasus wurde zum größten Teil von Wolfgang Beikircher verfasst, - ausgenommen der Anwendungen mit Pegasus, welche von Evelyn Schgaguler verfasst wurden. - Das Projekt Karajan sowie - die Zusammenfassung wurden von Wolfgang Beikircher verfasst. - Die Bibliographie sowie - die graphische Aufarbeitung und Formatierung wurden von beiden Beteiligten übernommen. 2 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 2. Einleitung Statt zwischen zwei E-Mails im Leerlauf zu dösen, könnte so mancher PC weitaus besser ausgenutzt werden. Weltweit wird eine CPU durchschnittlich nur für ca. 5% bei PCs und ca. 10% bei Servern genutzt. Um jedoch die ganze Kapazität auszuschöpfen, könnte so mancher PC oder Server zum Beispiel der Forschung helfen oder seine CPU-Kapazität für andere Rechenleistungen bereitstellen. Genau diese Idee verfolgen einige Applikationen des Grid.[1] Abbildung 1: Mögliche Arten von Anwendungsgebieten, welche die ungenützten Ressourcen verwenden könnten.[2] 2.1 Was ist eigentlich das Grid? Mit Grid Computing (Standortunabhängiges Rechnen) bezeichnet man alle Methoden, welche die Rechenleistung vieler Computer innerhalb eines Netzwerks so zusammenfassen, dass über den reinen Datenaustausch hinaus eine parallele Lösung von rechenintensiven Problemen ermöglicht wird. Jeder Computer in dem so genannten Grid ist eine, den anderen Computern gleichgestellte, Einheit. Damit kann, zu deutlich geringeren Kosten, sowohl die Kapazität als auch die Rechenleistung heutiger Supercomputer übertroffen werden. [3] Als Ressourcen kommen dabei nicht nur Rechenleistungen und Speicherplatz in Frage, sondern beliebige Geräte können im Grid gemeinschaftlich verwendet werden. Als Beispiel 3 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 sind hier Hochleistungscomputer, Netzwerke, Datenbanken, Teleskope, Mikroskope und Elektronenbeschleuniger anzuführen. Ein Ziel des Grid ist es, dass man auf Geräte zugreifen kann, als ob man sie besitzen würde, ohne sie tatsächlich zu besitzen. Dabei ist es ganz egal wo sich die gewünschten Geräte befinden. [4] Abbildung 2: Ressourcen, welche im Grid gemeinschaftlich verwendet werden können.[5] Ian Foster, ein international anerkannter Forscher und Führer im Gebiet von Grid-Datenverarbeitung, bezeichnet das Grid (Gitter) als eine Infrastruktur, die Hochleistungsrechner, Netze, Datenbanken und Instrumente zu einem gemeinsam nutzbaren, problemorientierten Verbund vereint. [6] Abbildung 3: Ian Foster[7] Es gibt viele verschiedene Projekte, die über das Grid laufen bzw. das Grid weiterentwickeln. Um diese Projekte zu finanzieren, werden viele Fördergelder eingesetzt. Eine Institution, die solche Projekte fördert, ist die EU. Ein Forschungsprojekt das zurzeit mit 10 Millionen Euro durch die EU gefördert wird, ist ein Projekt des Europäischen Kernforschungsinstituts CERN in der Schweiz. Bei diesem Projekt geht es darum, das World Wide Grid als Weiterentwicklung des World Wide Web zu schaffen. Im Vordergrund steht dabei die Bewältigung von sehr großen Datenmengen. [8] 4 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Ein großer Vorteil von Grid-Projekten ist, dass durch den Zusammenschluss vieler PCs und Server weltweit die gewünschten Ergebnisse in wesentlich kürzerer Zeit erzielt werden können. Als Beispiel könnte man hier das „Centre for Computational Drug Discovery“Projekt der Oxford Universität anführen, bei dem mehr als eine Million private PCs an der Sichtung von Erfolg versprechenden Molekülen für Krebstherapeutika eingespannt werden. Das Projekt hat mittlerweile mehr als 50.000 CPU-Jahre gebraucht, das ohne das Grid nicht möglich gewesen wäre. [3] 2.2 Softwarearchitektur des Grid Der Kern des Grid basiert auf einer Menge von Standards und Protokollen. Eine Basis ist dabei die von Ian Foster mitentwickelte Idee der Open Grid Service Architecture (OGSA). OGSA ist eine Menge von Spezifikationen und Standards, das die Vorteile von Grid Computing mit denen von Webservices kombinieren soll. Damit will man eine Plattform schaffen, die eine gemeinsame Nutzung von Anwendungs- und Computer-Ressourcen über das Internet auch für den kommerziellen Bereich interessant macht. Die neue Menge an OGSA-Spezifikationen erweitert Standards wie XML, WSDL und SOAP mit Grid Computing Standards, die vom Globus-Projekt-Team entwickelt wurden. [4] Die verschiedenen Protokolle und Standards, sind der Grundstein der Grid Applikationen. Um einen genaueren Einblick in eine Softwarearchitektur zu bekommen, wird OGSA genauer durchleuchtet. In OGSA werden acht Kategorien von Dienstleistungen spezifiziert, welche die folgenden Services umfassen: - Infrastructure Services: Diese Services beseitigen die Barrieren die bei gemeinschaftlicher Ausnutzung von ungleichen Ressourcen entstanden sind. - Resource Management Services: Diese aktivieren das Überwachen, Reservieren und Konfigurieren von Grid Ressourcen, basierend auf den Serviceanforderungen. - Data Services: Diese aktivieren den Datenaustausch, verwalten Kopien, führen Abfragen und Updates aus und wandeln Daten in neue Formate um, falls dies gewünscht wird. 5 Grid Computing – Grid Applications, Environments and Progarmming Models - WS 2004/05 Context Services: Diese Services beschreiben zum Beispiel die benötigten Ressourcen für jeden Benutzer des Grids. Weiters aktivieren diese Services die Optimierung der Ressourcen basierend auf den Anforderungen des Services. - Information Services: Diese Services bieten eine effiziente Bereitstellung und Zugang zu Informationen über das Grid und dessen Ressourcen, einschließlich des Status und der Verfügbarkeit der einzelnen Ressource. - Self-Management Services: Diese unterstützen mit soviel Automatisierung wie möglich, das Erlangen von angegebenen Niveaus von Services, um die Kosten und die Komplexität der Systemverwaltung zu reduzieren. - Security Services: Diese Services erzwingen Sicherheitspolicen innerhalb (virtueller) Organisationen, empfehlen sichere Ressourceaufteilung und entsprechende Authentifizierung und Genehmigung durch die Benutzer. - Execution Management Services: Diese Services aktivieren sowohl einfache als auch komplexere Workflow-Aktionen die mit der Platzierung, Versorgung und Verwaltung der Lebenszyklen der Tasks ausgeführt werden. 2.3 Grid Applikationen Ein großer Teil von Anwendungsbereichen, in denen große Bearbeitungsprobleme leicht in Teilprobleme unterteilt und unabhängig von einander gelöst werden können, haben durch Grid computing einen großen Vorteil.[10] Dabei stellen die Grid Applikationen eine Schnittstelle zwischen dem Benutzer und der eigentlichen Grid Funktionalität dar. Es gibt heute folgende 6 verschiedene Arten von Grid Applikationen: - Distributed Supercomputing: Klasse von Applikationen dessen Anforderungen nur durch mehrere Ressourcen mit hoher Kapazität befriedigt werden können (wird auch verteilter Supercomputer genannt). Mit einer solchen Art von Grid-Applikation ist es möglich komplexe 6 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Analysen durchzuführen. Als Beispiele für die Verwendung sind Bereiche wie Astronomie, Klimatologie und Kampfsimulation zu nennen. - High-Throughput Computing: Ein solches Grid koordiniert die Nutzung von ungenutzten Ressourcen in schwach gekoppelten Systemen. Z.B.: seti@home - On–Demand Computing: Nutzt Gridkapazitäten um Kurzzeit-Anforderungen zu befriedigen. Ressourcen können Berechnungen, Software oder Daten sein. Z.B.: Bereich der Meteorologie - Data–Intensive Computing: Diese Art von Grid konzentriert sich auf die Synthetisierung von neuen Informationen aus großen verteilten Datenbeständen. - Collaborative Computing: Ermöglicht die bessere Koordination von Mensch–zu–Mensch Interaktionen. - Teleimmersion: Systeme, welche die virtuelle Zusammenarbeit fördern, sie werden auch „Collaborative Virtual Environments“ genannt. Heute wird Teleimmersion vor allem in der interaktiven wissenschaftlichen Visualisierung, in der Ausbildung und im Training, in der Kunst und im industriellen Design verwendet. [9] Folgende Graphik zeigt die unterschiedlichen Schichten des Grid. Dabei stehen bei dieser Arbeit, wie das Thema „Grid applications, environments and programming models“ schon sagt, die obersten zwei Schichten im Mittelpunkt. Des Weiteren werden nun, im folgenden Teil die zwei Projekte Karajan und Pegasus vorgestellt. 7 Grid Computing – Grid Applications, Environments and Progarmming Models Abbildung 4: Der Schichtenaufbau eines Grid mit den dazugehörigen Technologien.[10] 8 WS 2004/05 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 3. Projekt Pegasus Heutzutage werden für Grid Anwendungen nicht mehr der gesamte Kode in einem Projekt entwickelt, sondern man baut seine Anwendung aus schon bereits existierenden Einzelteilen zusammen. Generell werden diese Anwendungen durch Workflows1 definiert, wobei die Aktivitäten im Workflow individuelle Komponenten der Anwendung sind. Die Abhängigkeiten zwischen den Aktivitäten spiegeln den Daten- bzw. Kontrollfluss zwischen den Anwendungskomponenten wieder. Ein Workflow kann in einer abstrakten Form beschrieben werden, in welcher die Aktivitäten unabhängig von den Grid Ressourcen sind, auf denen er ausgeführt werden soll. Somit ist der Workflow auch portabel, da man keine spezielle Konfiguration berücksichtigen muss. Man bezeichnet diese Form als einen abstrakten Workflow. Pegasus nimmt nun diesen abstrakten Workflow und bildet ihn auf das Grid ab. Dabei kann entschieden werden, ob der gesamte Workflow oder nur Teile von ihm auf das Grid abgebildet werden soll. [11][12] 3.1 Überblick Der Name des Projekts, Pegasus, steht für Planning for Execution in Grids. Pegasus wurde entwickelt bei ISI2 und ist ein Teil der Projekte GriPhyN und SCEC/IT. Pegasus ist ein konfigurierbares System, welches komplexe Workflows auf das Grid abbilden und diese dort ausführen kann. Der momentane Entwicklungsstand ist, dass Pegasus komplett auf einer ahead-planning Technologie3 basiert um die Workflows abzubilden. Da sich das System ständig weiterentwickelt, soll aber auch noch in-time Planung und deffered Planung berücksichtigt werden. [13] 3.2 Eingabe der Workflows Wie bereits angedeutet arbeitet Pegasus mit der Definition eines abstrakten Workflows. Diese Definition kann beispielsweise durch Chimera konstruiert werden oder vom Benutzer direkt eingegeben werden. Die Eingaben in das Chimera System sind partielle Workflow Beschreibungen. Diese formulieren die logischen Eingabedateien, 1 Workflows: Ablaufmodelle welche die Abarbeitung der einzelnen Arbeiten bestimmen 2 ISI: Information Science Institute 3 ahead-planning Technologie: vorausplanende Technologie 9 die logischen Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Transformationen und ihre Parameter sowie die logischen Ausgabedateien und dessen Transformationen. Abbildung 6 zeigt eine partielle Workflow Beschreibung, welche in Chimera’s virtueller Daten Sprache (VDL)4 beschrieben wurde. Abbildung 5: Eingabedatei für Chimera. Es wird ein abstrakter Workflow beschrieben. Wenn nun eine solche VDL und die gewünschte Menge an logischen Ausgabedateien spezifiziert wurden, produziert Chimera einen abstrakten Workflow indem es die Namen der Eingabe- und der Ausgabedateien vergleicht. Chimera startet bei den vom Benutzer spezifizierten Ausgabedateien. Nehmen wir an, dass der Benutzer in dem Beispiel oben (Abbildung), die Datei f.c2 gerne hätte. Wenn also dieses VDL gegeben ist, verknüpft Chimera die partiellen Workflows basierend auf den Ein-/Ausgabedateien und erstellt den folgenden abstrakten Workflow: Abbildung 6: Ein abstrakter Workflow Der berechnete abstrakte Workflow wird in XML spezifiziert in Form eines DAX (DAG5 Beschreibung in XML). Einige Benutzer entscheiden sich auch, den DAX selbst zu schreiben. 4 VDL: Virtual Data Language 10 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Dies ist vor allem nötig, wenn die Liste der möglichen VDL Definitionen ziemlich lang wird. So beispielsweise bei der Anwendung für Astronomie Montage. Hier kann ein Benutzer einen Teil des Himmels eingeben, welcher ihn interessiert und Montage berechnet es ihm. Hier wäre es unsinnig alle Möglichkeit im Voraus zu berechnen. Die untenstehende Abbildung 8 zeigt einen Teil der XML-Datei des DAX, welcher über die VDL der Abbildung 7 erzeugt wurde. In der XML-Datei ist die Definition einer finalen Aktivität analyze für den Workflow zu erkennen. Weiters kann man seine Abhängigkeiten zu den beiden findrange Knoten (ID000002 und ID000003) erkennen. Abbildung 7: Beispiel einer XML-Datei. Diese wird direkt Pegasus übergeben. Es ist egal ob die Eingabe mit Hilfe von Chimera erzeugt wurde oder vom Benutzer selbst geschrieben wurde. Pegasus braucht sie in dem spezifizierten DAX Format. Ausgehend von dieser Spezifikation bildet Pegasus einen konkreten Workflow, welche dann zu Condor’s DAGMan6 weitergeleitet wird für dessen Ausführung.[14][15] 5 DAG: Gerichteter azyklischer Graph (Directed acyclic graph) 6 DAGMan: DAGMan (Directed Acyclic Graph Manager) ist ein meta-scheduler für Condor 11 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 3.3 Abbildung der abstrakten Workflows ins Grid Die abstrakten Workflows beschreiben die Berechnung durch logische Dateien und logische Transformationen zeigen die Abhängigkeiten zwischen den Workflow Komponenten. Wenn man nun die abstrakten Workflows in eine ausführbare Form bringen will, dann muss man verschiedene Dinge berücksichtigen. Darunter wären zum Beispiel: - Man muss die Ressourcen finden, die verfügbar und in der Lage sind die Berechnungen durchzuführen. - Man muss die Daten finden, die der Workflow braucht. - Man muss die nötige Software besitzen. 3.3.1 Arbeitsweise von Pegasus Pegasus befragt verschiedene Grid Informationsservices um die verschiedenen, aufgezählten Dinge zu finden. Es benutzt die logischen Dateien, welche durch das Workflow referenziert wurden, um den Globus Replica Location Service (RLS) zu kontaktieren. Dieser versucht die gewünschten Daten zu finden. Wenn alles erfolgreich abläuft, erhält Pegasus eine Menge von Standorten, wo sich die entsprechenden physischen Dateien befinden. Zu bemerken ist, dass wenn Pegasus neue Daten produziert, dann werden sie automatisch im RLS registriert und somit auch anderen Benutzern zur Verfügung gestellt. Außer der Benutzer wünscht es nicht. Um den Standort der logischen, in dem abstrakten Workflow definierten, Transformationen finden zu können, befragt Pegasus den Transformation Catalog (TC) und benutzt dabei die logischen Namen der Transformationen aus der XML-Datei. Der Service liefert die physischen Standorte der Transformationen (auch auf verschiedenen Systemen möglich) und die Umgebungsvariablen, die gebraucht werden, um die Abbildung 8: Interaktion mit externen korrekte Ausführung der Software sicherzustellen. Services während der Abbildung Pegasus kontaktiert weiters den Globus Monitoring and Discovery Service (MDS) um die verfügbaren Ressourcen und ihre Charakteristiken7 zu finden. Die Informationen des Transformation Catalog werden kombiniert mit den Informationen des MDS um die Scheduling Entscheidungen zu treffen. Wenn die 7 Charakteristiken: Zum Beispiel Länge der Warteschlage für den Scheduler oder verfügbarer Speicher. 12 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Entscheidung über die Ressourcenzuteilung gemacht wird, legt Pegasus darauf Wert, dass sich die Daten bereits an dem Berechnungsort befinden. Andernfalls wählt Pegasus zufällig die Ressourcen aus oder benutzt eine einfache Scheduling-Technik. Zusätzlich benutzt Pegasus MDS um Informationen über den Standort von gridftp Servern, Jobmanagern, Speicherstandorten, das RLS und vieles mehr zu finden. Diese Informationen sind erforderlich um die Ausgabedateien zu erstellen. Die Ausgabedateien beschreiben die nötigen Bewegungen der Daten, die Berechnung und die Aktualisierung des Katalogs. [14] 3.4 Reduktion von Workflows Die Informationen über die verfügbaren Daten kann dazu benutzt werden um einen konkreten Workflow weiter zu optimieren. Wenn Daten, welche durch den abstrakten Workflow beschrieben werden, bereits existieren, kann Pegasus diese wieder verwenden. Das reduziert natürlich die Komplexität des konkreten Workflows. Ein Beispiel: Ein anderer Benutzer hat bereits Teile der Daten, welche gebraucht werden, berechnet und in einer Datenbank abgelegt. Wenn diese Information im RLS registriert wird, kann Pegasus diese benutzen, um eine aufwendige Berechnung zu vermeiden. Daraus folgt, dass möglicherweise einige Komponenten, welche im abstrakten Workflow vorhanden sind, im konkreten Workflow gestrichen wurden. Zudem prüft Pegasus auch die Durchführbarkeit des Workflows. Es schaut die Anfangsknoten des abstrakten Workflows an und fragt das RLS, ob die Eingabedateien für diese Komponenten existieren. Der Workflow kann nur ausgeführt werden, wenn alle Eingabedaten für die Komponenten im Grid existieren und diese auch über das Datentransport Protokoll erreichbar sind. Abbildung 9: Ein konkrete Workflow Das Ergebnis von Pegasus ist ein ausführbarer Workflow, welcher die Ressourcen für die Berechnung, die Bewegung der Daten für die Ein- und Ausgabe der Berechnung und die Registrierung der berechneten Daten im RLS identifiziert. [14][15] 13 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 3.5 Ausführung der Workflows Der konkrete Workflow, der von Pegasus produziert wurde, hat die Form der Eingabedateien für DAGMan. Die Eingabedateien geben an, welche Operationen auf den entfernten Rechnern ausgeführt werden müssen und in welcher Reihenfolge diese ausgeführt werden sollen. DAGMan teilt den Workflow wieder auf, in einzelne Jobs, und leitet sie an Condor-G weiter. DAGMan ist dafür verantwortlich, dass die Abhängigkeiten zwischen den Jobs gewährleistet sind. Im Falle, dass ein Job ausfällt, kann DAGMan, je nach eingestellter Anzahl, probieren den Job wieder zu starten. Falls dies auch scheitert kann DAGMan einen temporären Graphen erstellen. Dieser kann verändert und später noch einmal ausgeführt werden. [15] Abbildung 10: Ablauf der Abarbeitung eines Workflows. Von der abstrakten Definition zum ausführbaren Workflow. 14 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 3.6 Anwendungen mit Pegasus 3.6.1 LIGO Gravitationswellen, welche durch die Relativitätstheorie von Einstein vorhergesagt wurden, wurden nie experimentell betrachtet. Durch Simulationen von Einsteins Gleichungen, berechneten Wissenschafter, dass diese Wellen durch aufeinander prallende Schwarzen Löcher, in sich stürzenden Supernovae, Erdbeben in Neutronensternen oder Pulsaren erzeugt worden seien. Das Laser Interferometry Gravitational-Wave Observatory (LIGO) Projekt hat sich als Ziel gesetzt solche Phänomene aufzuspüren. Mit 300 Millionen Dollar ist dies das größte eigenständige Unternehmen der National Science Foundation. LIGO hat Betriebsanlagen in Livingston, Louisiana und Hanford bei Washington. Zudem verbindet es Observatorien für Gravitationswellen in Italien, Deutschland und Japan um diese Signale zu suchen. Man glaubt, dass Pulsare Gravitationswellen erzeugen, deshalb durchsuchen Wissenschaftler mit größter Sorgfalt Gebiete mit bekannten Pulsaren, in der Hoffnung solche Signale zu finden. Der entwickelte Pegasus-Planer ist eines der Werkzeuge, die Wissenschaftler benützen können um Daten zu analysieren die von LIGO gesammelt wurden. Pegasus wurde 2002 benutzt um die virtuellen Daten, welche bei der LIGO Pulsar-Suche8 erfasst werden, auszuwerten. Im Herbst des Jahres 2002 wurden zum Beispiel 17 Tage lang Daten gesammelt, die in zwei Schritten ausgewertet wurden: einmal in einem 2monatigen Programmlauf und einmal in einem 6monatigen Programmlauf. LIGO-Instrumente wurden entworfen um die Wirkung von Gravitationswellen auf Masse in einem Vakuum zu testen. Die Beobachtungen werden durch Fourier-Transformationen und mittels Software, die Frequenzbereiche extrahiert, verarbeitet. Dabei kann es darum gehen, einen Workflow von Hunderten von Jobs zu bilden und diese auf entsprechenden Ressourcen auf dem Grid auszuführen. Dadurch kann man sehr schnell zu einem Ergebnis kommen. Pegasus wurde von LIGO benutzt um Daten, während des ersten wissenschaftlichen Laufes der Instrumente, zu sammeln. Dabei wurden eine Menge von Standorten von bekannten Pulsaren und auch zufällig gewählte Standorte im Himmel als Zielgruppe gewählt. Pegasus erzeugte end-to-end Grid Job Workflows, welche auf Datenverarbeitungs- Speicherressourcen von Caltech und mehreren Universitäten ausgeführt wurden. 8 LIGO-Pulsar-Suche: Suche nach Gravitationswellen in Pulsaren und anderen sternenartigen Objekten. 15 und Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Abbildung 11: Die folgende Abbildung zeigt die Visualisierung der Ergebnisse der LIGO Pulsar-Suche. Das oben angeführte Bild zeigt die Ergebnisse dieser LIGO-Pulsar-Suche. Die Bereiche der Suche wurden von Wissenschaftlern festgelegt und sind in der linken unteren Ecke angeführt. Die linke obere Ecke zeigt den festgelegten Bereich der in dem Bild gezeigt wird. Die hellen Punkte repräsentieren die durchsuchten Standorte. Die roten Punkte sind Pulsare innerhalb der für die Suche spezifizierten Sprünge. Die gelben Punkte sind diese außerhalb dieser Sprünge. Die blauen und grünen Punkte sind zufällig durchsuchte Punkte, die sich jeweils innerhalb und außerhalb der Sprünge befinden. [16][17][18] 16 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 3.6.2 SCEC Pegasus wird bei Demonstrationen von Erdbebenanalysen verwendet: als ein Teil der Demonstrationen bei der jährlichen SCEC (Southern California Earthquake Center) Versammlung, wurde das von GriPhyN und iVDGL entwickelte Virtual Data Toolkit zur Unterstützung der SCEC-Analyse verwendet. Dabei wurden drei unterschiedliche seismische gefahrenbezogene Kalkulationen geschaffen und mit dem SCEC Portal ausgeführt. Das System geht dabei folgendermaßen vor: es produziert Workflow Templates (diese identifizieren die notwendigen Berechungen und ihre Reihenfolge) füllt diese mit Daten, erzeugt die abstrakten Workflows und reicht jene dann dem GriPhyN Virtual Data System (VDS). Pegasus ist eines der Bestandteile des VDS und bildet die Workflows auf das SCECund das USC-Grid ab. Danach führen DAGMan und Condor-G die Workflow-Komponenten aus. Ein beeindruckender Aspekt des Systems war, dass es ein konsistentes Workflow-System unter unterschiedlichen seismischen Gefahrenprogrammen gab. Früher lief jeder SCEC-Weg in einer unabhängigen und unterschiedlichen Weise. [18][19] 17 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 4. Projekt Karajan Das Ereignis vom 11. September 2001 war wie ein Wachrütteln für die Softwareentwickler der ganzen Welt. Viele der großen Firmen, welche kritische Daten oder gar ganze Daten- und Rechenzentren haben, speicherten diese in den beiden Türmen. Die Wahrscheinlichkeit, dass beide Türme fallen würden, war verschwindend gering und somit dachte niemand, dass dies passieren würde. Aber es passierte. Dieses Szenario zeigte uns, dass die Aufbewahrung der Daten an einem Ort nicht optimal ist. [20] 4.1 Verteilung der Arbeit Die Lösung ist verteiltes Rechnen. Nur wenn man seine Daten und Dienste aufteilt, kann man eine Ausfallsicherheit bis zu einem gewissen Grad garantieren. Aber verteiltes Rechnen und somit auch das Grid ist gepflastert mit Hindernissen und Gefahren. Es können zum Beispiel ganze Netzwerke nicht mehr erreichbar sein, Maschinen kommen und gehen und Ressourcen, welche man benötigt, müssen erst gefunden werden. An dieser Stelle kommt das Projekt Karajan ins Spiel. Karajan ist ein Framework, welche sich auf das Grid stützt. Es nützt dabei Dienste, welche von der Middleware angeboten werden und schirmt den Anwendungsentwickler weitestgehend von den Einzelheiten ab. Die Middleware stellt in diesem Fall das Projekt Rio und das von Sun entwickelte Framework Jini zur Verfügung. Somit steht Karajan auf starken Schultern und gewährleistet ein hoch entwickeltes aber dennoch einfach zu handhabendes Managementsystem. Karajan selbst stellt eine Umgebung zur Verfügung, in welcher mehrere Gruppen von Applikationen in Form von Workflows nebeneinander laufen können und dabei gemeinsame Ressourcen nützen. Natürlich stellt Karajan dabei sicher, dass die einzelnen Applikationen unabhängig und sicher in der verteilten Umgebung arbeiten können. 18 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Abbildung 12: Eine schematische Darstellung, die zeigt, wie Karajan Anwendungen verwendet werden und sie zeigt auch die Rollen der verschiedenen Softwareschichten. Eine Karajan-Anwendung ist eine Sammlung von Clients und gemeinsamen Ressourcen, zusammen mit einer Gruppe von Diensten, welche über das Grid zur Ausführung verteilt werden. Wie jede gute Anwendung, können Karajan Applikationen gestartet, gestoppt oder von der Umgebung entfernt werden, ohne dass laufende Applikationen gestört werden. Dieses System ist zum Beispiel perfekt für gleichzeitig entwickelte Programme bei denen viele Entwickler sich überlappende Versionen von gleichem Kode laufen lassen wollen. [20] 4.2 Vorraussetzungen für Karajan Da Karajan ein Vertreter für die Anwendungen des Grid ist, setzt es eine bestimmte Middleware voraus, welche grundlegende Funktionen bietet. 4.2.1 Jini Jini stellt eine Gruppe von Werkzeugen für Java Entwickler zur Verfügung, welche eine verteilte, auf Services basierte Anwendung, schreiben wollen. Jini Services sind automatisch auffindbar, wenn Anwendungen oder andere Services diese brauchen. Jini bietet die Werkzeuge für Karajan an, ist aber auf einem tieferen Level. Weiters bietet Jini eine Struktur, 19 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 welche JavaSpace genannt wird. Die JavaSpace ist wie eine magische Box, worin alle Services hineingelegt und wiedergefunden werden können. [21] 4.2.2 Rio Bei Rio können Services mittels eine speziellen Struktur spezifiziert werden, welche als Operational String bezeichnet wird. Dieser Operational String ist eine XML Datei, in welcher der Service und dessen Systemvoraussetzungen beschrieben sind. Man kann sie auch miteinander verketten um ein größeres Netzwerk von Services zu erstellen und somit ein großes Potential für Unternehmen zu bieten. Der Operational String wird an einen Systemservice übergeben, der diesen interpretiert. Zuletzt bietet Rio noch eine Struktur welche Cybernode9 genannt wird und Jini’s Möglichkeit die Services untereinander zu verbinden. Der Systemservice lädt also die XML-Datei und diese teilt ihm mit, welche JiniServiceBeans er erstellen muss und auf welche Cybernode sie laufen sollen. Weiters hat der Service die Aufgabe, die Objekte, welcher er generiert hat zu beobachten und evtl. neu zu starten. [22][23][24] 4.3 Ziele von Karajan Die Hauptziele des Projekts werden im Folgenden aufgelistet: Erzeugung einer vererbbaren, verteilten Anwendungsinfrastruktur welche alle Unternehmenskriterien erfüllt. Solche Kriterien sind z.B.: Sicherheit, Skalierbarkeit, Einfachheit, Robustheit, u.v.m. Client – Server – Service Programmierung so einfach und skalierbar wie nur irgendwie möglich zu machen. Das bedeutet, dass der Entwickler von allen Anforderungen der Koordination von Services und Workflows abgeschirmt ist. Eine Umgebung zur Verfügung zu stellen, in der Services Kommandos asynchron und unabhängig von einander ausführen können. Damit können große Rechenaufgaben zeitsparend gesammelt werden und später von den verfügbaren Services ausgeführt werden. Die Entwicklung einer Infrastruktur, in welcher alle Applikationen und Workflows vollkommen von einander getrennt werden und jede einzelne Komponente beendet, verändert und neu gestartet werden kann, ohne dass dies Auswirkungen auf die anderen laufenden Komponenten hat. [25] 9 Cybernode: Ist eine Art Virtual Machine mit Quality of Service Tags. 20 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 4.4 Architektur von Karajan Workflows werden in Karajan durch eine strukturierte Sprache definiert, welche auf XML basiert und erweiterbar durch Java ist. Der Baustein der Sprache ist das Element, welches die freie Übersetzung in einen XML-Behälter bewerkstelligt. Verschiedene Elemente werden hierbei mit eingeschlossen, wie zum Beispiel Elemente für parallele Bearbeitung, parallele Iteratoren und Grid-Elemente (z.B. Datenübertragung via Grid). Übliche Aufgaben können nach Benützungsschablonen gruppiert werden und sie können von mehreren Standorten wiederbenützt werden. Der Motor von Karajan, welcher einen Workflow startet, basiert auf einem Ereignismodell, das eine eindeutige Trennung zwischen der Workflow Spezifikation (durch die XML-Datei) und dem Ausführungszustandes des Workflow herstellt. Workflowelemente reagieren auf Ereignisse die von anderen Elementen empfangenen wurden und erzeugen selbst ihre eigenen Ereignisse. Diese Ereignisse sorgen dafür, dass sich der Status innerhalb der Durchführung ändert oder sie können auch benutzt werden, um die Durchführung von Elementen zu steuern. Da der ganze Ausführungszustand innerhalb der Ereignisse enthalten ist, wird es den Elementen ermöglicht auf unterschiedlichen Ressourcen zu existieren. Dieser Mechanismus erlaubt es auch einem externen Controller, welcher Zugang zu diesen Ereignissen hat, die Durchführung der Workflows vollkommen zu beherrschen. Weiters ermöglicht es auch bis zu einem gewissen Grad die Modifikation der Elemente bei Laufzeit. Die Modifikationen werden hierbei ausgeführt, ohne die Durchführung von anderen Elementen zu beeinflussen. Um dieses Ereignismodell zu gewährleisten, wird in Karajan auf die Technologie JavaSpaces gesetzt. Sie bildet das Rückgrad von den Karajan Workflow Ensembles. Es gibt 2 verschiedene Ereignismodelle, welche in Karajan benutzt werden. Beide werden über das sogenannte „client delegation API“ angesteuert und garantieren ein sicheres Übermitteln der Nachrichten in „client-to-service“ und „service-to-service“ Kommunikationen. Zusätzlich ist eine Schnittstelle zu Standard Jini vorgesehen, welche für nicht kritische Ereignisbehandlung (z.B. bei einer Client-to-Client Schnittstelle) verwendet wird. [26][27] 21 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 4.5 Client delegation API Um einen Workflow in das Grid übertragen und steuern zu können, bietet Karajan eine einfache und leicht zu handhabende Schnittstelle zu der Serviceumgebung an. Karajan definiert das so genannte Connectable Interface, welches aus den folgenden 5 grundlegenden Operationen besteht: create(): wird benutzt um ein Zielobjekt an Karajan zu übergeben retrieve(): liefert ein einzelnes Objekt von Karajan zurück. update(): bewirkt eine Änderung an dem Objekt, welches mit der übergebenen Objekt ID übereinstimmt. delete(): löscht ein Objekt von Karajan heraus. exists(): testet ob ein Objekt in Karajan schon existiert. Zusätzlich bietet Karajan noch eine Reihe von verschiedenen Ereignisbehandlungsmodellen, welche über die folgenden Operationen angesteuert werden: addLifecycle(): Wird benutzt um ein Zielobjekt über ein lifecycle Ereignis 10 an Karajan weiterzugeben. removeLifecycle(): entfernt ein bereits existierendes lifecycle Ereignis aus Karajan. issueTrigger(): gibt eine Trigger Aktion an Karajan weiter. Die Methode aktiviert dabei lifecycle Ereignisse. notifyEvent(): Damit werden Event Listener installiert. Für die Implementierung des Connectable Interfaces wird das Factorypattern11 verwendet. Die Fabrik selbst erzwingt Instantiierungsauthentifizierung und -genehmigung und definiert eine Menge von anwendungsspezifischen Service Ensemble tags, welche von der XML– Konfigurationsdatei der Anwendung gelesen werden. So ein Ensemble Tag stellt eine Liste von Services dar, welche bei der Ankunft des Objekts im JavaSpace benachrichtigt werden. Sie bilden die Grundlage des unten erklärten Ensemble Ereignismodells. [20] 10 Lifecycle Ereignis: siehe Kapitel 1.5 11 Factorypattern: Spezielles Entwurfsmuster 22 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 4.6 Das Ensemble Ereignis Modell Wenn Objekte an Karajan übermittelt werden, dann werden diese immer mit einem Ensemble Tag übermittelt. Dieser Tag wird dann mit dem Objekt während der ganzen Lebensdauer gespeichert. 4.6.1 Konfigurationsdatei Karajan Anwendungen werden spezifiziert durch eine XML-Datei welche eine ganze Menge von benannten Services beinhaltet. Weiters wird hier auch noch eine Zeichenkette spezifiziert, welche an Rio weitergereicht wird. 4.6.1.1 Definition eines Workflows Ein Workflow wird in Karajan in der XML-Datei zusammen mit Spezifikation den Services beinhaltet spezifiziert. einfache Diese Elemente, wie beispielsweise. Parallelität (Abbildung 15), die durch einen Interpreter in Karajan an Rio weitergeleitet werden. Die Schlüsselwörter sind natürlich vordefiniert und können im Handbuch nachgeschlagen werden. Abbildung 13: Möglicher Workflow in Karajan. 4.6.1.2 Definition der Services Die Service-Ensembles werden wie folgt definiert: Abbildung 14: Ein Beispiel für einen Service Jeder Servicemodus bezieht sich auf einen Servicenamen, welcher benachrichtigt wird, wenn ein Zielobjekt in die JavaSpace kommt. Hier sei angemerkt, dass viele Serviceinstanzen einen gleichen Servicenamen haben können. Diese bilden dann eine so genannte Servicegruppe wobei dann der erste abrufbare Service die Nachricht des Zielobjekts erhält. Zusätzlich wird noch ein Parameter für jeden Modus mitgegeben. Zum Beispiel, ein Service für die Archivierung kann entweder archivieren oder dearchivieren. Abhängig vom Parameter. 23 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Wenn ein Objekt an Karajan übergeben wird, dann wird die Operation als vollständig angesehen. Hinter diesem Vorgang ist es die Aufgabe der Infrastruktur allen Services die an diesem Objekt beteiligt sind, eine Nachricht zu senden. Es gibt 2 verschiedene Modelle der Nachrichtenbehandlung in Karajan. Das erste Modell zeigt das so genannte Client distribution model. Diese Technik ist synchron, das heißt, der Client wird erst beendet, wenn das Zielobjekt und alle seine Servicenachrichten mit Hilfe einer Transaktion in die JavaSpace geschrieben worden ist. Diese Technik ist effizient, wenn nur wenige Services in dem Serviceensemble sind. Abbildung 15: Client distribution model: Der Client ist dafür verantwortlich, ein Service-Nachricht-Objekt zu jedem Service in dem Ensemble der Transaktion A(t1) zu schreiben. Daraufhin werden atomare Operationen der Services in den Transaktionen B(t2) und C(t3) durchgeführt. Abbildung 18 zeigt das Service distribution model. Wenn viele Services in einem Ensemble sind dann ist es intelligenter, diese Technik zu verwenden. Diese Vorgehensweise ist asynchron, d.h., der Client kommt schon zurück nachdem er das Service Flag für den Verteilungsservice geschrieben hat. Der Verteilungsservice hat dann die Aufgabe alle Services in dem Ensemble asynchron zu benachrichtigen. Die Schattenseite dieser Technik ist 24 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 die steigende Latenzzeit für das Benachrichtigen des zusätzlichen Services. Als Hinweise sei hier angeführt, dass die Latenzzeit für das 2. Modell ca. um 50ms größer ist als bei dem 1. Modell. [28] Abbildung 16: Service distribution model: Der Client schreibt nur ein Service Flag in der Transaktion A(t1). Dieses Flag leitet die Ereignisbehandlung dann weiter zu dem Distribution Service mit Hilfe der Transaktion B(t2). Die Services erhalten dann diese Nachrichten mit Hilfe der Transaktionen C(t3) und D(t3). 4.7 Lifecycle Ereignismodell Das Ziel von so genannten lifecycle events ist, eine Methode für das Spezifizieren von persistenten, garantierten Serviceensemble Nachrichten bereitzustellen. Hierbei sollen diese Nachrichtenobjekte aber nicht gleich von den jeweiligen Services verarbeitet werden, sondern erst zu einem späteren Zeitpunkt. Diese Eigenschaft wird erreicht, indem man die Nachrichten mittels eines Triggerobjekts an Karajan übergeben kann. Dieses Objekt spezifiziert dann, wie oft und wann die Nachrichten ausgeführt werden soll. Diese Nachrichten werden dann ganz normal, wenn eine übereinstimmende Trigger-Nachricht im Javaspace ankommt, in Karajan als Serviceensemble Nachrichten platziert. 25 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 Abbildung 18: Die Abbildung zeigt, wie ein Lebenszyklus hinzugefügt wird. Dieser Lebenszyklus wird über ein Ereignis durch das Connectable Interface eingefügt. Das Ereignis wird dann vom Service, der für die Lebenszyklen zuständig ist, verarbeitet und in einer Triggerliste platziert. Abbildung 19: Die Abbildung zeigt, wie ein Trigger an Karajan übergeben wird. Dieser Trigger wird dann vom Service für die Lebenszyklen gelesen und es wird gegenüber anderen Ereignissen den Lebenszyklus betreffen verglichen. Wenn eine Übereinstimmung auftritt, wird das Ereignis für diesen Service in die Javaspace geschrieben. Trigger können in 2 Kategorien aufgeteilt werden, je nachdem wie oft sie aufgerufen werden: Nur einmal: Wenn ein Triggerereignis empfangen wird und das zugehörige Ensemble Ereignis dieses Triggers ausgeführt wurde, wird das Lebenszyklus Flag aus der Liste entfernt. Öfters: Dieser Typ eines Triggers führt das zugehörige Ensemble Ereignis immer aus, wenn das Ereignis für den Trigger im Space abgelegt wird. [28] 26 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 5. Zusammenfassung Das Grid steckt erst in den Kinderschuhen und wird wohl noch einige Zeit brauchen, um sein volles Potential zu entfalten. Die Einsatzmöglichkeiten, welche das Grid bietet, sind sehr vielseitig und die Probleme der Menschheit noch lange nicht gelöst. Momentan gib es noch keine genaue Programmierrichtlinien und man kann auch nicht genau sagen, wohin sich alles entwickeln wird. Eines ist aber sicher: Es wird immer verschiedene Modelle geben ein Problem zu lösen. Hier wurden lediglich 2 Modelle vorgestellt. Jedes hat seine Vorteil und Nachteile und alle beide befinden sich noch in der Entwicklung. Somit ist noch viel möglich. Aus der Sicht der Autoren dieser Arbeit ist Pegasus momentan das stärkere System zur Übertragung von Workflows in das Grid. Es hat gute Mechanismen zu Findung und Auswahl von Ressourcen sowie zur Findung und Sammlung von Daten. Es bringt weiters eine gute Dokumentation und API mit sich und überzeugt in den Applikationen, in welchen es eingesetzt wurde. Das Team von Pegasus will sich in den nächsten Zeit verstärkt um sein AI-planning System und die Optimierung kümmern, während Karajan kaum weiterentwickelt wird. Das darum, da die Aufgaben von Karajan mittlerweile fast komplett in RIO übernommen wurden und man nicht weiß, ob das Projekt fortgesetzt wird. 27 Grid Computing – Grid Applications, Environments and Progarmming Models WS 2004/05 6. Bibliographie [1] http://www.heise.de/cebit/highlights/allgemein/2003/grid/ [2] http://www.dlr.de/sc/themen/grid [3] http://de.wikipedia.org/wiki/Grid_Computing) [4] http://www.par.univie.ac.at/~brezany/teach/kfk/03ws-vo/skriptum/GridCompDeutsch.ppt [5] http://info.web.cern.ch/Press/PressReleases/Releases2003/PR13.03ELCG-1.html [6] http://www-ai.cs.uni-dortmund.de/DOKUMENTE/9 [7] http://www.dtc.umn.edu/ seminars/050603.html [8] http://de.wikipedia.org/wiki/World_wide_grid [9] http://www.ifi.unizh.ch/richter/ Classes/sem_cutting_edge/Slides_Grid.pdf [10] http://www.gridcomputing.com [11] http://pegasus.isi.edu [12] http://www.globusworld.ord/program/abstracts/Pegasus.htm [13] http://www.isi.edu/~deelman/Pegasus/pegasus%20overview.pdf [14] http://www.isi.edu/~deelman/Pegasus/publications/architecture.pdf [15] http://www.isi.edu/~deelman/Pegasus/Pegasus_final.pdf [16] http://www.isi.edu/%7Edeelman/agw_ppam2004.pdf [17] http://www.isi.edu/ikcap/cognitive-grids/status.html [18] http://www.isi.edu/pegasus/applications.htm [19] http://www.isi.edu/pegasus/presentations/pegasus_9_04.ppt [20] http://karajan.jini.org/public/intro.html [21] http://www.jini.org/standards/ [22] http://rio.jini.org [23] http://www.jini.org/docs/rio-overview.pdf [24] http://www.jini.org/docs/Rio-DynamicServiceArchitecture.pdf [25] http://karajan.jini.org [26] http://www.cogkit.org/wiki/cog/moin.cgi/Projects/ANL/Workflow [27] http://www.sc-conference.org/sc2004/schedule/index.php [28] http://karajan.jini.org/public/event_model.html 28
