Vorstudie Grid Sicherheits-Infrastruktur (GSI) Ergebnisse des Arbeitspakets 1: Relevante Grid-Szenarien und ihr Schutzbedarf. Version 9.

Transkript

1 Vorstudie Grid Sicherheits-Infrastruktur (GSI) Ergebnisse des Arbeitspakets 1: Relevante Grid-Szenarien und ihr Schutzbedarf Version 9.3

2 An der Erstellung dieser Studie waren beteiligt: Prof. Dr Hans Ludwig Stahl, FH Köln Prof. Dr. Stefan Karsch, FH Köln Dr. Helmut Reiser, Ludwig-Maximilians-Universität München Manuel Atug, SRC (Security Research & Consulting GmbH) Bonn Randolf Skerka, SRC (Security Research & Consulting GmbH) Bonn Dr. Anastasia-Maria Leventi-Peetz, BSI Dr. Rainer Plaga, BSI Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Internet:

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 RELEVANTE GRID-SZENARIEN BEGRIFFSBILDUNG Definition Grid Virtualisierung und Transparenz Rollen und Organisationsformen im Grid Arten von Grids STANDARDISIERUNG VON GRIDS Open Grid Service Infrastructure (OGSI) Web Services Resource Framework (WSRF) Open Grid Service Architecture (OGSA) Infrastruktur Dienste (Infrastructure Services) Ausführungsmanagement (Execution Management Services) Data Services Ressource Management Services Security Services Self Management Services Information Services GRID MIDDLEWARE Globus Toolkit Historie, Unterschiede zwischen den Globus Versionen Globus Web Services Globus Komponenten Sicherheit: Grid Security Infrastructure (GSI) UNICORE Architektur und Komponenten Job Modell Ressourcen Modell Kommunikation UNICORE Sicherheit UNICORE Client Unterschiede zu Globus Interoperabilität zwischen UNICORE und Globus EINSATZ DER GRID TECHNOLOGIE IN DER PRAXIS UND IHR SCHUTZBEDARF AKTUELL LAUFENDE WISSENSCHAFTLICHE GRID-PROJEKTE DEISA (Distributed European Infrastructure for Supercomputing Applications) D-Grid ABLEITUNG DER BETRACHTETEN GRID SZENARIEN Vorgehensweise Unterkapitel Darstellung des Szenarios anhand eines Beispiels Unterkapitel Analyse des Szenarios Unterkapitel Schutzbedarfsermittlung DIE GRID-SZENARIEN IM DETAIL UND IHR SCHUTZBEDARF Szenario 1: Unternehmensinternes Grid Darstellung des Szenarios anhand eines Beispiels: Berechnung von Motorblöcken Analyse von Szenario Schutzbedarfsfeststellung Szenario 2: Grid für den unternehmensübergreifenden industriellen Einsatz Darstellung des Szenarios anhand eines Beispiels: Shell-Grid Analyse von Szenario Schutzbedarfsfeststellung Szenario 3: Offenes e-science Grid Version 9.3 Seite I

4 Inhaltsverzeichnis Darstellung des Szenarios anhand eines Beispiels: D-Grid Analyse von Szenario Schutzbedarfsfeststellung Szenario 4: Grids mit personenbezogenen bzw. personenbeziehbaren Daten (z. B. MammoGrid) Darstellung des Szenarios anhand eines Beispiels: MammoGrid Analyse von Szenario Schutzbedarfsfeststellung Szenario 5: Sicherheitskritisches national wichtiges Grid / Katastrophenschutz (K-Grid) Darstellung des Szenarios anhand eines Beispiels Analyse von Szenario Schutzbedarfsfeststellung FAZIT UND ZUSAMMENFASSUNG ANHANG A REFERENZEN Version 9.3 Seite II

5 1 Relevante Grid-Szenarien Im ersten Kapitel wird zunächst der Begriff Grid genau definiert. Anschließend werden Arten von Grid Systemen und gebräuchliche Middleware Komponenten detailliert beschrieben. 1.1 Begriffsbildung Definition Grid Das Grid Computing hat sich aus Bestrebungen heraus entwickelt, die Ressourcen nationaler Supercomputing- Zentren zu verbinden und einfach nutzen zu können. Die Rechenpower sollte so einfach zugreifbar sein, wie der elektrische Strom aus dem Stromnetz (engl. Power Grid). Auf diese Aspekte bezieht sich auch die frühe Definition des Grid Computing von Ian Foster und Carl Kesslemann: A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities. [23] In dieser Definition steht der Aspekt einer technischen Infrastruktur im Vordergrund. Diese sollte eine zuverlässige, konsistente und kostengünstige Nutzung von Höchstleistungsrechnern quasi von überall ermöglichen. Obwohl in dieser Definition nicht explizit genannt, ist die Überwindung der Domänengrenzen, zwischen technisch und rechtlich autonomer Organisationen, bereits ein wichtiges Thema. In den frühen Tagen des Grid waren jedoch die technischen Fragen einer Infrastruktur von entscheidender Bedeutung. Im Laufe der Zeit hat sich dieser sehr technische Fokus der Koppelung von Hochleistungsrechenzentren jedoch deutlich verallgemeinert. Heute steht nicht mehr nur die Nutzung von Supercomputern im Vordergrund, sondern es wird ganz allgemein von Ressourcen gesprochen. Unter diesen Ressourcenbegriff fallen Rechner, Software, Daten, Speicher- und Plattenplatz, aber auch andere Ressourcen wie wissenschaftliche Großgeräte (z. B. Beschleunigerring am CERN, astronomische Teleskope) u. ä. Die Nutzung dieser Ressourcen ist weiter gefasst. Es soll nicht nur der Austausch von Daten und Jobs, sondern der direkte Zugriff auf die Ressource ermöglicht werden. Bei der Nutzung von Grids rückt das kollektive und kollaborative Lösen von Problemen und das Teilen von Ressourcen in den Vordergrund. Eine gemeinsame Nutzung verteilter Ressourcen, die von verschiedenen autonomen Organisationen zur Verfügung gestellt werden, erfordert natürlich große Kontroll- und Einflussmöglichkeiten für den Ressourcen-Anbieter und Absprachen zwischen Nutzern und Anbietern von Ressourcen. Die entscheidende Neuerung in der Definition von Grid ist jedoch die Virtualisierung und der Begriff der Virtuelle Organisation (VO). Die spätere Arbeit von Foster, Kesselmann und Tuecke zur Definition des Begriffes Grid trägt die Virtuelle Organisation bereits im Titel [24]. Im nächsten Abschnitt werden diese Begriffe näher erläutert. Zusammenfassend lässt sich ein Grid charakterisieren als eine kontrollierte sowie koordinierte Ressourcen-Teilung und -Benutzung in dynamischen, skalierbaren und verteilten virtuellen Organisationen Virtualisierung und Transparenz Eine Grid-Infrastruktur ermöglicht einem Nutzer den Zugriff auf Ressourcen, die außerhalb der lokalen administrativen Domäne liegen, d. h. die Kollaboration erfolgt domänenübergreifend. Unter einer Domäne wird eine technisch (und häufig auch rechtlich) autonome Organisationseinheit verstanden, die einer einheitlichen operationalen Verantwortung unterliegt und in der es ein einheitliches Betriebskonzept mit entsprechenden Policies gibt. Unter einer Domäne wird beispielsweise ein Unternehmen oder eine Forschungseinrichtung verstanden. Eine ganze Universität kann eine Domäne bilden, es kann aber auch der einzelne Lehrstuhl in seinen Entscheidungen und bezüglich seiner Infrastruktur autonom sein und damit als eigene Domäne auftreten Version 9.3 Seite 3

6 Die Beteiligten, die domänenübergreifend ein gemeinsames Ziel verfolgen oder gemeinsame Interessen haben, teilen sich ihre Ressourcen. In [24] wird dieses Teilen näher spezifiziert. 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 problemsolving 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 and/or institutions defined by such sharing rules form what we call a virtual organization. [15] Außerdem wird hier der für das Grid zentrale Begriff der Virtuellen Organisation (VO) eingeführt. Eine Virtuelle Organisation wird bestimmt durch eine Menge von Individuen, Ressourcen und/oder Institutionen, die sich durch Regeln (Policies) definiert, die das Teilen von Ressourcen regeln. Eine virtuelle Organisation umfasst also verschiedene autonome Domänen. Aber nicht nur im Hinblick auf die organisatorische Gliederung sondern auch bei den Ressourcen selbst wird das Prinzip der Virtualisierung angewendet. Ein Grid-Benutzer soll und muss im Idealfall überhaupt nicht mehr wissen, wo sich eine Ressource (z. B. der Speicherplatz für Daten und Replikate dieser Daten) befindet. Er gibt seinen Auftrag an das Grid und das Grid sorgt dafür, dass dieser Auftrag ausgeführt wird. Für den Nutzer ist die Diensterbringung durch das Grid transparent. Diese Transparenz kann Ort, Zeit und sogar die verwendete Technologie umfassen. Der Benutzer muss sich nicht mehr darum kümmern, in welcher Domäne (Ort), zu welcher Zeit und mit welcher konkreten technischen Realisierung der Ressource sein Auftrag ausgeführt wird. Zusammenfassend lässt sich feststellen, dass ein Grid durch die folgenden Punkte charakterisiert ist: - Rechtlich und technisch autonome Organisationen bilden die Grid-Infrastruktur - (i. Allg.) keine zentrale Kontrolle der Ressourcen - Verschattung der Domänengrenzen bei gleichzeitig großer Kontroll- und Einflussmöglichkeit für Ressourcenanbieter - Gemeinsame Nutzung von Ressourcen (Resource Sharing) - Kollektive und kollaboratives Problemlösung - Virtualisierung und Transparenz - Bildung skalierbarer virtueller Organisationen (VO) Rollen und Organisationsformen im Grid Um Grid-Infrastrukturen und die Interaktionen im Grid sicherheitstechnisch bewerten zu können, ist es erforderlich sich die unterschiedlichen Rollen der Akteure sowie die verschiedenen Organisationsformen näher zu betrachten. Klar ist, dass es die Rolle des Grid-Nutzers einerseits und des Ressourcen-Providers auf der anderen Seite gibt. Diese Rollen sind aber nicht exklusiv, ein Grid-Nutzer kann im Grid selbst wieder als Ressourcen-Provider auftreten und umgekehrt. Diese Rollen sind in organisatorische Strukturen und lokale Domänen eingebunden. Zur Verdeutlichung wird der Aufbau eines Grids zwischen zwei autonomen Organisationen und die Bildung einer neuen Virtuellen Organisation (vgl. Abbildung 1) betrachtet. Die beiden Organisationen A und B bilden jeweils eine eigene abgeschlossene Domäne mit ihren jeweiligen Ressourcen. Jede Domäne ist bereit, einen Teil ihrer Ressourcen (im Bsp. Sub-Domain A1 und B1) in das Grid einzubringen, d. h. sowohl A als auch B treten als Ressourcen-Provider auf. Ziel ist, dass ein Grid-Nutzer in der Domäne A einen Auftrag (Task) absetzen kann, der dann vom Grid unter Nutzung von Server X und Server Y bearbeitet wird. Grundsätzlich kann man jedoch nicht davon ausgehen, dass zwischen A und B ein Vertrauensverhältnis besteht, es kommt zum sogenannten Trust Mismatch. Auch die verwendete Technologie bei den Servern ist möglicherweise inkompatibel und es kommt zum Mechanisms Mismatch Version 9.3 Seite 4

7 No Cross- Domain Trust Domain A Certification Authority Certification Authority Domain B Policy Authority Task Server X Sub-Domain A1 Trust Mismatch Mechanism Mismatch Server Y Policy Authority Sub-Domain B1 Abbildung 1: Aufbau einer virtuellen Organisation [33] Um eine gemeinsame VO bilden zu können (vgl. Abbildung 2), muss eine Vertrauensbeziehung (Trust Relationship) zwischen A und B aufgebaut werden. Die technologischen Inkompatibilitäten werden durch die Grid- Middleware (vgl. Abschnitt 1.3) beseitigt. Eine wichtige Vorraussetzung für eine Vertrauensbeziehung ist eine Klärung der Frage des Policy Mappings. Jede Domäne hat eigene administrative Regeln, d. h. legt Domänen-spezifisch fest, wer z. B. in welcher Art und Weise auf die Ressourcen zugreifen darf. Diese lokalen Regeln innerhalb einer Domäne werden im Grid als Site-Local Policies bezeichnet. Auch der Nutzer einer Ressource kann bestimmte Vorgaben machen, beispielsweise wie mit seinen personenbezogenen Daten zu verfahren ist. Diese Regeln bezeichnet man als User Policies. Innerhalb einer Domäne (z. B. A) sind diese Regeln festgeschrieben und werden durch technische Mechanismen umgesetzt. Im Grid kommen zu diesen bestehenden Policies neue hinzu. Auch Domäne B hat natürlich eigene Policies und falls der Task des Grid-Nutzers aus der Domäne A Ressourcen der Domäne B nutzt, muss man sich mit diesen Policies den Target-Site Policies in der Domäne B auseinandersetzen. Gleichzeitig kann sich die VO auf einen Satz gemeinsamer Policies einigen, die innerhalb der VO gelten sollen ( VO-Policies ). Trotzdem kann man nicht davon ausgehen, dass diese Policies alle einheitlich sind. Im Normalfall wird es immer Policies geben, die sich widersprechen, d. h. es kann zu Policy-Konflikten kommen. Diese Konflikte sind innerhalb der VO zu lösen. Hierzu gibt es verschiedene Ansätze: 1. Policy Hierarchie: Es wird eine Ordnung auf den Policies definiert und im Konfliktfall wird die höherwertige Policy wirksam. Im Beispiel könnte die Ordnung VO-, Target-Site-, User-, Local-Site-Policy angenommen werden, d. h. die VO-Policy hätte das höchste Gewicht. Hier zeigt sich deutlich, dass die Ordnungsrelation einen entscheidenden Einfluß auf die Semantik und die Entscheidungsbefugnis innerhalb der VO hat. Natürlich kann man auch eine partielle Ordnung definieren, bei der es gleichwertige Policies gibt (wenn z. B. Target-Site- und Local-Site Policy gleich sein sollten). In diesem Fall müssen Konflikte durch die folgende Strategie gelöst werden Version 9.3 Seite 5

8 2. Explizite Konfliktlösung: Konflikte werden ex ante oder ex post erkannt und dann zwischen den Beteiligten (auf-)gelöst. Diese Vorgehensweise ist aber weder im Hinblick auf die Erkennung noch bezüglich der Konfliktlösung trivial. 3. Zentrale Entscheidungsbefugnis: Dies ist ein Spezialfall von Variante 1. In diesem Fall treten alle beteiligten Domänen die Rechte an Ihren Ressourcen z. B. an die VO ab, die dann einheitliche Policies für die gesamte VO festlegt. Certification Authority Certification Authority Policy Authority Sub-Domain A1 Policy Authority Sub-Domain B1 Domain A Task Federation Service Domain B GSI Server X Virtual Organization Domain Server Y Abbildung 2: Bildung einer virtuellen Organisation [33] Arten von Grids Grids lassen sich in Abhängigkeit ihres Verwendungszweckes klassifizieren. Diese Vorgehensweise wurde bspw. in der Britischen e-science Gap Analysis [29][30] verfolgt. In dieser Studie wurden im April 2003 in Großbritannien Wissenschaftler zum Zustand und Anwendungsspektrum von Grid-Technologien befragt. Aus dieser Befragung entstand eine Defizit-Analyse sowie eine Klassifikation von Grids nach ihrem Verwendungszweck. Eine gängigere und allgemein breiter akzeptierte Klassifikation von Grids richtet sich nach der Art der vernetzten Objekte. Hier werden die beiden Klassen Ressource-Grids und Service Grids unterschieden. Bei den Ressource-Grids steht die gemeinsame Nutzung von Ressourcen aller Art im Vordergrund. Das Grid virtualisiert und vereinheitlicht dabei den Zugang zu heterogenen Ressourcen. Die Klasse der Ressource Grids wird weiter unterteilt in Computing Grids, Data-Grids sowie Access Grids. Beim Computing-Grid steht die Verfügbarkeit von Rechenleistung im Vordergrund. Das Daten-Grid (manchmal auch als File-Grid bezeichnet) soll erhebliche Mengen von Daten zuverlässig und ausfallsicher speichern und einfach wieder zugänglich machen. Das Daten- Grid stellt auch Methoden zur effizienten Suche oder ggf. zu lokalen Verdichtung oder (vor-) Filterung der Daten zur Verfügung. Insbesondere in wissenschaftlichen Großexperimenten lässt sich nicht immer zwischen Computingund Daten-Grid trennen. In diesen Fällen kommt eine Mischform aus Computing- und Daten-Grid zum Einsatz Version 9.3 Seite 6

9 Hier fallen sehr große Datenmengen an, die auch innerhalb des Grid weiterverarbeitet oder analysiert werden. Beim Access Grid handelt es sich um eine Infrastrukturen, die spezifische Werkzeuge zur Kollaboration beinhaltet, wie z. B. Video-Konferenz-Systeme mit Whiteboard und gemeinsam nutzbaren Applikationen. Den Service Grids liegt eine Service Oriented Architecture (SOA), im Deutschen auch als dienstorientierte Architektur bezeichnet, zugrunde. Ein Service in diesem Kontext ist als eine Funktionalität definiert, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann. Die technische Abbildung auf eine konkrete Ressource wird dabei für den Nutzer verschattet. Die Dienste eines Service Grid werden unterliegenden Ressourcen eines Ressource Grids zugeordnet. Die in den folgenden Abschnitten vorgestellten Standards stützen sich ebenfalls auf SOA Prinzipien ab. 1.2 Standardisierung von Grids Das Global Grid Forum (GGF) setzt sich aus Nutzern, Entwicklern und Herstellern zusammen. Deren Ziel ist eine weltweite Standardisierung für Grid Computing. Organisatorisch gibt es drei Arten von Gremien innerhalb des GGF: Working Groups zur Entwicklung von Standards, Research Groups zur Diskussion neuer Fragen sowie zur Entwicklung neuer Use Cases und Community Groups die sich mit bestimmten Funktionsbereichen (z. B. Sicherheit) befassen. Die Working Groups können aus den anderen Gruppen gebildet werden. Das GGF arbeitet ähnlich wie die Internet Engineering Task Force (IETF). In der IETF wird ein Dokument, das als RFC veröffentlicht wird, zum De-facto-Standard. Im GGF heißt das vergleichbare Dokument GGF proposed recommendation. Die wichtigen Standards des GGF sind die Open Grid Service Infrastructure (OGSI) [80] und die Open Grid Service Architecture (OGSA) [26]. Sowohl die Standards als auch viele Middleware-Implementierungen stützen sich auf Web Services ab. Ein Grid Service kann als Web-Service realisiert werden. Ein Web Service ist ein Dienst, der über einen Uniform Resource Identifier (URI) eindeutig identifizierbar und referenzierbar ist. Die Schnittstellen des Dienstes werden mit Hilfe der Extensible Markup Language (XML) spezifiziert. Der Zugriff auf den Dienst erfolgt unter Verwendung von XML-basierter Nachrichten mit Hilfe internetbasierter Protokolle. Ein Anbieter eines Web Service beschreibt diesen mit Hilfe der Web Service Description Language (WSDL) [13], einer XML basierten Spezifikationssprache. Mit Hilfe eines Verzeichnisdienstes, z. B. UDDI (Universal Description, Discovery and Integration) [14] wird der Web Service mit der Dienstbeschreibung und seiner URI beim Verzeichnisdienst registriert. Ein Nutzer kann dann das UDDI-Verzeichnis nach einem für seine Zwecke geeigneten Dienst durchsuchen und diesen dann nutzen. Für den Aufruf des Dienstes wird das Simple Object Access Protocol (SOAP) [56][42][43] oder XML-RPC (Remote Procedure Call) [88] verwendet. Beide Protokolle basieren wiederum auf XML. Damit wird einerseits erreicht, dass auf jeder Plattform die Methodenaufrufe dekodiert werden können. Anderseits kann man die verschiedensten Protokolle (z. B. TCP, HTTP, SMTP u. a.) verwenden, um SOAP- oder XML-RPC-Nachrichten zwischen Nutzer und Web-Service zu übertragen. Die Web Services sind nicht primär für einen menschlichen Nutzer gedacht, sondern für die Nutzung durch andere Web Services oder sonstige Programme, die damit automatisiert Daten austauschen oder Funktionen auf entfernten Rechnern aufrufen. Google bietet beispielsweise Web Services an, um mit eigenen Programmen automatisiert auf die Suchfunktion von Google zuzugreifen [36] Open Grid Service Infrastructure (OGSI) Grid Services lassen sich als Web Service implementieren. Die Open Grid Service Infrastructure (OGSI) war der erste Versuch dies standardisiert umzusetzen. OGSI beinhaltet eine detailliertere formale Spezifikation von Grid Services. Dazu werden Verhaltensweisen, Schnittstellen und WSDL/XML-Schematas verwendet. Die OGSI erweitert auch die besehenden Web Services Standards, um deren Defizite im Hinblick auf Grids zu beseitigen. Diese Erweiterungen umfassen die folgenden Punkte: - Zustandsbehaftete und potentiell transiente Dienste. Klassische Web Services sind persistent und zustandslos. Viele Grid Services sind zustandsbehaftet und kurzlebig Version 9.3 Seite 7

10 - Mechanismen zum Management des Lebenszyklus von Diensten (Lifecycle Management) - Dienst Informationen (Zustandsinformationen und Metadaten) - Asynchrone Benachrichtigungen (Notifications) - Dienstgruppen - Erweiterungen der Schnittstellendefinitionen eines Web Services (porttype-erwieterungen) - Grid Service Handle (GSH) zur global eindeutigen Identifikation eines Grid-Dienstes und Grid Service Reference (GSR) als Netzwerk-Pointer, um auf den Grid-Dienst zugreifen zu können. D. h. ein GSH muss auf eine GSR abgebildet werden, um den Dienst verwenden zu können. Ein Grid Service ist nach OGSI ein Web Service mit erweiterten wohldefinierten Schnittstellen. Die Implementierung der erweiterten Schnittstellen erfolgt mittels WSDL porttypes. Diese Erweiterungen der klassischen Web Services Standards wurden von OGSI proklamiert. OGSI wurde vom GGF die Web Services von der OASIS standardisiert. Allerdings wurde OGSI nur von der Grid Community akzeptiert. Aus Sicht der Web Service Community gingen die proprietären Erweiterungen zu weit und wurden nicht akzeptiert. Die vom Global Grid Forum erhoffte Konvergenz zwischen OGSI und den Web Services Standards trat nicht ein. Dies führte auf Seite der Grid Community zur Entwicklung von OGSA (vgl. Abschnitt 1.2.3) Web Services Resource Framework (WSRF) Von den Standardisierungsgremien für Web Services wurde aber auch erkannt, dass es Bedarf nach entsprechenden Erweiterungen gab. Um dennoch eine Konvergenz zu erreichen, wurde 2004 eine Standardisierungsbemühung ins Leben gerufen. Diese Initiative mündete in eine Gruppe von Standards, die als Web Services Resource Framework (WSRF) bezeichnet werden und von der OASIS (Organization for the Advancement of Structured Information Standards) standardisiert wurden. Das WSRF ist im Gegensatz zu OGSI integraler Bestandteil der Web Services und kein Aufsatz oder Patch wie OGSI. Funktional betrachtet, werden dieselben Erweiterungen wie bereits bei OGSI vorgegeben umgesetzt. Mittlerweile hat WSRF eine deutlich höhere Akzeptanz erreicht und OGSI ersetzt Open Grid Service Architecture (OGSA) OGSA ist ein allgemeiner architektureller Rahmen zur Beschreibung und Organisation von Grid-Infrastrukturen. Der Standard stellt gewissermaßen ein Modell dar, wie Grids entwickelt werden sollen, gibt aber keinerlei Hinweise, die beispielsweise eine konkrete Umsetzung oder Implementierung betreffen. OGSA verwendet als Basiskonzept eine Service Oriented Architecture (SOA, z. B. in [7]). OGSA adressiert die Standardisierung der wichtigsten Kernkomponenten eines Grids. Das OGSA-Dienst-Framework, mit seinen Diensten ist in Abbildung 3 dargestellt, wobei die Autoren in [26] bereits anmerken, dass diese Darstellung nicht erschöpfend ist. Die Zylinder repräsentieren individuelle Dienste. Diese Dienste werden nach den Web-Services-Standards implementiert. Dadurch das OGSA auf die Standards der Web Services Familie aufbaut können die spezifizierten Konzepte und Standards wie z. B. SOAP, WSDL, WS-Inspection, WS-Security usw. sehr einfach integriert werden. Zum Teil werden sie aber auch um Grid-spezifische Aspekte erweitert Version 9.3 Seite 8

11 Abbildung 3: OGSA Framework [26] OGSA spezifiziert Dienste, deren Schnittstellen, ihre Semantik bzw. ihr Verhalten und die Interaktionen zwischen den Diensten. Die Interna des Dienstes oder seine Implementierung sind nicht Gegenstand von OGSA. Die Architektur ist weder geschichtet (wie z. B. das OSI Referenzmodell [46]) noch objekt-orientiert, wenn auch viele Konzepte objekt-orientiert erscheinen. Dienste sind lose gekoppelt und erfüllen ihre Funktion entweder alleine oder in einer Gruppe. Diese Gruppen werden durch Komposition oder über Interaktionen zwischen den Diensten gebildet. Komplexere Dienste können durch eine Orchestration, d. h. die Kopplung einfacher Dienste mit Hilfe eines Workflows, realisiert werden. Der Standard definiert acht Dienstklassen, die im Folgenden kurz vorgestellt werden Infrastruktur Dienste (Infrastructure Services) Der Standard setzt auf die Familie der Web-Service-basierten Standards auf. Zur Beschreibung der Dienstschnittstellen wird die Web Service Description Language (WSDL) [13] verwendet. Als Lingua Franca zur Beschreibung und Spezifikation wird XML eingesetzt. Als Kommunikationsprotokoll wird SOAP spezifiziert. Die Definition von Diensten muss konsistent erfolgen und die Interoperabilität dieser Dienstspezifikationen wird durch Web Service Interoperability (WS-I) [5] sichergestellt. Durch konsequente Verwendung bestehender Web Service Standards können auch ganz einfach Erweiterungen dieser Standards innerhalb von OGSA verwendet werden. Dies trifft insbesondere für die Gruppe der Sicherheitsstandards (WS-Security) zu, auf die sich OGSA abstützt Version 9.3 Seite 9

12 Ausführungsmanagement (Execution Management Services) Die Execution Management Services (OGSA-EMS) befassen sich mit dem Lebenszyklus von Aufgaben (Units of Work), die im Grid ausgeführt werden sollen. Unter Aufgaben werden OGSA-Anwendungen, Jobs ebenso wie Legacy-Anwendung, verstanden. Das Management dieser Units of Work umfasst die Identifikation geeigneter Ausführungskandidaten, deren Lokalisierung, Vorbereitung für die Ausführung, Instanziierung und Ausführung sowie die Beendigung. Um dieses komplexe Problem zu lösen, verwendet OGSA das Prinzip der Dekomposition der großen EMS- Problematik in viele kleinere funktionale Einheiten. Die grundsätzliche Struktur besteht aus zwei Seiten: der Angebots- (Supplier) und der Nachfragerseite (Demand Site). Suppliers bieten Ressourcen (CPU, Speicher- und Plattenplatz oder Dienste) an, die auf der Nachfragerseite von Konsumenten genutzt werden. Auf der Angebotsseite gibt es Dienste, die Ressourcen bereitstellen und verwalten sowie Policies und Dienstvereinbarungen durchsetzten. In Abbildung 4 ist dieses Framework skizziert. Abbildung 4: EMS-Meta-Modell mit Unterteilung in Demand- und Supply-Seite [26] Jeder helle Block in dieser Abbildung repräsentiert einen OGSA-EMS Service. Aber wie bereits in der Abbildung angegeben, werden nicht alle diese Dienste im Standard beschrieben. Innerhalb des EMS gibt es drei grundsätzliche Klassen, die durch Dienste modelliert und implementiert werden: 1. Ressourcen 2. Job-Management- und Monitoring-Dienste 3. Auswahl-Dienste Version 9.3 Seite 10

13 Ressourcen Die OGSA-Dienste, die stellvertretend für Ressourcen stehen, modellieren Berechnungen, Speicherung, Anwendungen, das Management der Ressourcen und deren Bereitstellung. Dazu definiert OGSA Service Container und einen Persistent State Handle Service (PSHS). Ein Service-Container beinhaltet ausführbare Entitäten, das können Jobs oder Web-Services in Ausführung sein. Ein Container kann also beispielsweise eine Warteschlange, einen Unix-Rechner oder auch einen J2EE-Container repräsentieren. Container beinhalten die Eigenschaften der Ressourcen, die sowohl statische Informationen über die (Ausführungs-) Umgebung als auch dynamische Informationen wie z. B. Last oder Qualitätseigenschaften (QoS- Parameter) umfassen. Ein Container muss auch (mindestens eine Teilmenge) der Schnittstellen einer Managed Resource des Web Service Distributed Management (WSDM) Standards [59] implementieren, um ihn administrieren zu können. Container haben Verbindungen zu anderen Ressourcen und verwenden andere Dienste wie z. B. Reservierungs-, Logging-, Informations-, Job Management- und Provisionierungs-Dienste. Der Persistent State Handle Service (PSHS) verwaltet den Zustand einer Entität in Ausführung in dem er den Ort an dem dieser persistente Zustand gespeichert wird verfolgt. Dazu verwendet er so genannte Resource Handle (RH) und Resource Addresses (RA). Den RH kann man sich wie einen Pointer auf den Zustand vorstellen, der dann mit Hilfe einer RA auf die konkrete Instanz im Netz abgebildet wird. Der PSHS ist kein Datendienst. Er verfolgt lediglich den Speicherort für Zustandsinformationen und ermöglicht einen schnellen Zugriff darauf Job-Management und -Monitoring Der Job-Begriff von OGSA-EMS erweitert den klassischen Job-Begriff. Ein Job kapselt alle Informationen die Über eine bestimmte Unit of Work zur Verfügung stehen. Ein Job ist die kleinste administrierbare Einheit im Grid (Manageability of a Unit of Work) und implementiert ebenfalls die Schnittstellen einer WSDM Managed Resource. Der Job beinhaltet Informationen über seinen Zustand im Lebenszyklus (gestartet, suspendiert, terminiert oder beendet), Ressourcenzuweisungen und -vereinbarungen usw. Die Zustandsinformationen werden in einem so genannte Job Document gespeichert, das mit Hilfe einer Job Submission Description Language (JSDL) [2] spezifiziert wird. Alle Aspekte der Ausführung eines Jobs oder einer Menge von Jobs werden im Job Manager (JM) gekapselt. Dabei kann eine Job-Menge strukturiert (z. B. durch einen Workflow oder Abhängigkeitsgraphen) oder unstrukturiert sein. Der JM ist für die Orchestration der Dienste verantwortlich, die nötig sind, um einen Job oder eine Menge von Jobs zu verwalten. Zu diesen Aufgaben gehört das Aushandeln von Service Level Agreements, die Interaktion mit Containern, das Monitoring, u. a. Der JM kann auch das Scheduling von Jobs und deren Zuweisung zu konkreten Ressourcen sowie die Reservierung von Ressourcen übernehmen Auswahl-Dienste (Selection Services) Die Selection Services entscheiden, wo eine Unit of Work ausgeführt wird. Die Selection Services setzten sich aus dem Execution Planning Service (EPS), dem Candidate Set Generator (CSG) und den Reservation Services zusammen. Der Execution Planning Service (EPS) erstellt Abbildungen zwischen Jobs und Ressourcen, die zeitlich beschränkt sein können oder auch Alternativen beinhalten können. Diese Abbildungen werden als Schedules bezeichnet. Typischerweise arbeitet der EPS mit einer Optimierungsfunktion, um z. B. Kosten, Ausführungszeiten o. ä. zu minimieren oder die Ausfallsicherheit zu maximieren. Für eine erste Informationsgewinnung verwendet EPS den CSG. Der Candidate Set Generator (CSG) beantwortet die Frage Wo wäre es möglich, eine Unit of Work ausführen zu lassen?. Dazu müssen die durch die Unit of Work bestimmten Constraints eingehalten werden. Das heißt der CSG muss z. B. prüfen ob bestimmte Binaries auf dem Zielsystem verfügbar sind, ob die Ressource die Anforderungen bezüglich Hardware Ausstattung sowie Sicherheits- und Vertrauensanforderungen erfüllt sind. Der CSG er Version 9.3 Seite 11

14 zeugt eine Menge von Containern (genauer: eine Liste von Resource Handles (RHs)), die in der Lage wären, die Unit of Work auszuführen. Die eigentliche Entscheidung, wo die Unit of Work tatsächlich ausgeführt wird, ist nicht Aufgabe des CSG. Der Reservation Service erlaubt die Reservierung von Ressourcen und interagiert mit einem Abrechnungsdienst, falls Gebühren für eine Reservierung fällig werden Data Services Die Data Services sollen einen möglichst einfachen und effizienten Zugang zu den unterschiedlichsten Daten im Grid ermöglichen. Dazu ist es notwendig Daten zu migrieren, zu aktualisieren, Replikate anzulegen und zu verwalten sowie Daten zwischen unterschiedlichen Formaten zu transformieren. Eine effiziente Suche und Abfrage der Daten soll ermöglicht werden. Der Standard definiert eine Daten-Ressource sehr allgemein als eine Entität, die als Datenquelle oder senke auftreten kann. Die heterogenen Struktur von Grids muss dabei die unterschiedlichsten Datentypen unterstützten. Dies beinhaltet ist aber nicht beschränkt auf die folgenden Beispiele: Flat Files: Einfach Dateien ohne oder mit Applikations-spezifischer interner Struktur. Streams: Potentiell unendliche Sequenzen von Daten. Datenbanken: Daten in relationalen, objektorientierten und XML-Datenbanken. Kataloge und Verzeichnisse: Daten in Verzeichnissen mit interner Struktur und eigenem Datenmodell. Abgeleitete Daten: Daten die das Ergebnis asynchroner Abfragen oder Transformationen aus anderen Daten darstellen. Datendienste: Dienste selbst können als Datenquelle für andere Dienste auftreten. Auch bei den Datendiensten wird ein Demand- und Supply-Modell analog zu den EMS (vgl. Abschnitt ) zugrunde gelegt (vgl. Abbildung 5) Funktionale Eigenschaften Der Standard beschreibt welche funktionalen Eigenschaften die Data Services zur Verfügung stellen sollen. Ein wichtiger Aspekt ist die Transparenz und Virtualisierung. Da die Daten in heterogenen Formaten auf heterogenen Architekturen und an verteilten Orten gespeichert werden, muss ein Datendienst in der Lage sein diese technischen Unterschiede, die verschiedenen Zugriffsverfahren und Protokolle sowie die örtliche Lokalisation vor dem Benutzer zu verschatten. Der Zugriff auf die Daten sollte immer einheitlich erfolgen. Da es nicht möglich ist alle zukünftigen Daten-Ressourcen vorauszusagen, muss der Datenservice in der Lage sein, sich durch entsprechende Erweiterbarkeit an neue Datentypen und Zugriffsoperationen anzupassen. Mit Hilfe des Data Location Management können Daten zuverlässig zwischen verschiedenen Orten transferiert werden. Hier kann entweder das Original verschoben oder eine Kopie angelegt werden. Zur Erhöhung der Ausfallsicherheit und der Effizienz muss es die Möglichkeit geben, Replikate zu erzeugen. Der Zugriff auf die Daten sollte möglichst einfach erfolgen. Der Datendienst stellt dazu Lese- und Scheiboperationen zur Verfügung, die aus logischer Sicht eine Menge von zusammenhängenden Bytes lesen oder schreiben (egal wie die zugrunde liegenden Daten aufgebaut sind) Version 9.3 Seite 12

15 Abbildung 5: Meta Model für Data-Services [26] Der Datendienst bietet auch effiziente Mechanismen zur Abfrage von Daten. Es werden relationale Abfragsprachen wie SQL oder auch XML Query unterstützt. Außerdem gibt es auch Mechanismen zum Update. Transformationsdienste die zwischen den unterschiedlichen Datenformaten konvertieren können werden ebenso gefordert Ressource Management Services Das Ressource-Management, d. h. die Administration der Grid Ressourcen, betrachtet OGSA auf drei Ebenen: 1. Ressource Level: Das Management der eigentlichen Hard- und Software-Ressourcen (Endsysteme, Netzkomponenten, Betriebssysteme usw.) 2. Infrastructure Level: Das Management der (virtualisierten) Grid Ressourcen (z. B. Ressource Reservierung, Monitoring und Kontrolle) 3. OGSA Functions Level: Management der OGSA Infrastruktur selbst, die selber wieder aus Ressourcen zusammengesetzt ist (z. B. Monitoring eines Data Services) Auf Ebene 1 werden die Ressourcen unmittelbar mit Hilfe klassischer Managementprotokolle und Systeme (SNMP, WBEM u. ä.) administriert. Hier steht das Monitoring, das Starten und Beenden und die Steuerung der Ressourcen im Vordergrund. Die Eigenschaften, Operationen und Alarme der Ressourcen sowie deren Beziehungen untereinander müssen mit Hilfe einer Ressourcenbeschreibung formal spezifiziert werden. Dann lassen sich die Ressourcen mit Hilfe von WSDM [59] administrieren. WSDM unterscheidet das Management mit Hilfe von Web Services ( Management using Web Services ; MUWS) [83][84] und das Management von Web Services ( Management of Web Service ; MOWS) [66]. MUWS beschreibt das Management Modell wohingegen MOWS das generische Web Service Interface beschreibt mit Hilfe dessen die OGSA Dienste administriert werden können Version 9.3 Seite 13

16 Da die anderen beiden Ebenen bereits mit Hilfe von Web Services realisiert sind, lassen sich diese per WSDM administrienren Security Services Innerhalb der OGSA Security Working Group (OGSA-SEC-WG) entstand die Sicherheitsarchitektur für OGSA [58] sowie die OGSA Security Roadmap [68]. Die Sicherheitsarchitektur wurde größtenteils in den OGSA- Standard [26] übernommen, ist aber an manchen Stellen ausführlicher als der Standard und wird im Folgenden vorgestellt. Das Papier über die Sicherheitsarchitektur (und damit auch die OGSA) ist allerdings mehr eine Anforderungsanalyse mit einer Identifikation möglicher Sicherheitsmechanismen und Protokolle, um die Sicherheitsanforderungen umzusetzen, denn eine konkrete Architektur. Nach [58] lassen sich alle Überlegungen zum Thema Grid-Sicherheit im Spannungsfeld zwischen drei Herausforderungen ( Security Challenges ) einordnen: 1. Integration Challenge: Im Grid ist es nicht möglich, allen beteiligten Domänen eine einheitliche Sicherheitstechnologie vorzuschreiben. Damit muss die Sicherheitsarchitektur von OGSA unabhängig von konkreten Implementierungen einsetzbar und bestehende Sicherheitsmechanismen einfach integrierbar sein. Wegen der hohen Dynamik sollte die Sicherheitsarchitektur auch einfach erweiterbar sein. 2. Interoperability Challenge: Die verschiedenen Sicherheitsmechanismen in den einzelnen Domänen müssen zusammenarbeiten ohne dabei das globale Sicherheitsniveau zu verringern. Kommen unterschiedliche Protokolle zum Einsatz, muss es Abbildungsmechanismen bzw. Gateways zur Übersetzung geben. 3. Trust Relation Challenge: Die Sicherheit basiert an vielen Stellen auf Vertrauensbeziehungen zwischen den beteiligten Domänen. Es sind Mechanismen erforderlich, die diese Vertrauensbeziehung explizit machen, d. h. formale Beschreibungsverfahren für Vertrauensbeziehungen und Vertrauens-Level. Dazu bedarf es dann auch Verfahren, um solche Vertrauensbeziehungen zu etablieren und den Partner zuzuweisen. Aufbauend auf eine allgemeine Diskussion über Grid Sicherheit werden dann die folgenden Sicherheitsanforderungen abgeleitet: - Authentisierung - Delegation von Rechten und von Policies - Single Sign On - Beschränkte Lebenszeit von Rechten und Möglichkeiten diese zu verlängern ( Credential Lifespan and Renewal ) - Autorisierung - Datenschutz ( Privacy ) - Vertraulichkeit - Integrität der Kommunikation - Austausch von Policies - Sicheres Logging - Formalisierung und Zuweisbarkeit eines Sicherheitslevels (Quality of Protection, QoP ) - Administrierbarkeit Version 9.3 Seite 14

17 - Absicherung der OGSA Infrastruktur - Durchlässigkeit von Firewalls. Eines der Hauptprobleme bei der Etablierung eines Grid sind existierende Firewalls. Hier sind Konzepte zu entwickeln, die es ermöglichen OGSA Dienste sicher hinter einer Firewall zu betreiben ohne die Funktionalität und Nutzbarkeit des Grids zu beschränken. Die OGSA Sicherheitsarchitektur geht, basierend auf die Service Oriented Architecture (SOA) davon aus, dass Sicherheit als Dienst bzw. als Menge von Diensten umgesetzt und realisiert werden kann. Dementsprechend beschreibt das Dokument auf einem relativ hohen Abstraktionsniveau Sicherheitsdienste und Komponenten, die ein OGSA-basierendes Grid umsetzen soll (vgl. Abbildung 6). Abbildung 6: Komponenten der OGSA Sicherheitsarchitektur [57] Als Basis dient die Bindings Security, die für die Sicherheit der Nachrichtenübertragung sorgt. Im Policy Expression and Exchange Layer ist festzulegen, wie Policies spezifiziert werden, wie diese ausgetauscht und durchgesetzt werden können. Eng damit zusammen hängen die Spezifikation und Umsetzung von Autorisierungs-, Datenschutzund Ressourcen-Policies. Es wird auch eine Komponente vorgesehen, die Policies in die verschiedenen Policy- Sprachen transformieren und die bei Policy Konflikten die Konflikte auflösen soll (Policy Mapping). Daneben werden Dienste für eine Ende-zu-Ende Vertraulichkeit (Secure Conversations) für die Durchsetzung und Kontrolle der Zugriffsrechte (Access Control) und das Auditing sowie die Non-Repudation gefordert. OGSA geht davon aus, dass sich ein einheitliches Grid-weites Namensschema nicht durchsetzen lässt. Aus diesem Grund wird eine Komponente benötigt, die einen Namen oder ein Recht (Credential) aus einer entfernten Domäne auf eine lokale Benutzer-ID bzw. auf ein lokales Recht abbilden kann. Neben diesen spezifischen Diensten wird ein übergreifendes Trust-Modell und eine Komponenten für das sichere Logging benötigt. Im Block links in Abbildung 6 sind Dienste angegeben, die für das Sicherheitsmanagement und die Administration der Infrastruktur benötigt werden. Die OGSA Sicherheitsarchitektur gibt, ebenso wie OGSA selbst, keine konkreten Hinweise für die Umsetzung der abstrakt definierten Dienste. Allerdings wird auf die verschiedenen Web Services Standards als Building Blocks Version 9.3 Seite 15

18 für eine konkrete Sicherheitsarchitektur verwiesen (vgl. Abbildung 7). Die Standards- und Mechanismen werden auch einzelnen Schichten zugeordnet und damit eine grobe Abbildung auf die Sicherheitsdienste vorgegeben. Abbildung 7: Building Blocks für eine Grid Sicherheitsarchitektur [57] Vom Grundprinzip der OGSA Sicherheitsarchitektur kann jede Domäne seine eigenen Sicherheitsmechanismen verwenden. Die Dienste müssen lediglich eine Web Service Schnittstelle bieten, damit sie von der Grid Middleware verwendet werden können. In Abbildung 8 ist dies exemplarisch mit zwei Domänen, die eine VO bilden, dargestellt. In diesem Beispiel verwendet jede Domäne eigene Sicherheitsmechanismen. Für die sichere Kommunikation zwischen Nutzer und Dienst müssen sich die Beteiligten auf einen gemeinsamen Mechanismus einigen und einen entsprechenden WS-Stub implementieren. Die VO selbst kann auch Sicherheitsmechanismen umsetzen und es besteht die Möglichkeit, dass sich die Beteiligten auf einheitliche Mechanismen einigen. Für alle anderen Dienste muss, falls diese nicht interoperabel sind, von der VO ein Übersetzungsdienst (Bridge/Translation Service) zur Verfügung gestellt werden. Hier ist anzumerken, dass (abgesehen von dem Aufwand einen solchen Dienst für eine Abbildung zwischen zwei Sicherheitsmechanismen zu implementieren) die Komplexität dieses Übersetzungsdienstes quadratisch mit der Anzahl der an der VO beteiligten Domänen wächst Version 9.3 Seite 16

19 Abbildung 8: Grid Dienste in verschiedenen Domänen [26] In der OGSA-Security-Roadmap [68] wird die OGSA Sicherheitsarchitektur aufgegriffen mit dem Ziel, eine Zusammenstellung zu liefern, die darstellt welche Standardisierungsbemühungen noch notwendig sind, um zu einer interoperablen OGSA Sicherheitsarchitektur zu kommen. Das Ergebnis dieser Untersuchung ist in Abbildung 9 zusammengefasst. Auf der linken Seite ist angegeben, um welche Sicherheitsanforderungen bzw. um welche Kategorie von Sicherheitsdiensten es sich handelt. Auf der rechten Seite, welche Standardisierungsbemühungen dafür noch umzusetzen sind. Obwohl die Arbeit bereits aus dem Jahr 2002 stammt ist bisher nur ein kleiner Teil dieser geforderten Spezifikationen beim GGF auf den Weg zur Standardisierung gebracht worden Version 9.3 Seite 17

20 Abbildung 9: Notwendige Standards zur Erreichung von Interoperabilität in der Sicherheit [68] Version 9.3 Seite 18

21 Self Management Services Mit Hilfe von Prinzipien des Self Management wird versucht, die Kosten sowie die Komplexität für die Administration großer heterogenen IT-Infrastrukturen zu reduzieren. Das Ziel ist, dass sowohl Hardware Komponenten, Betriebsysteme als auch Anwendungen sich selbst konfigurieren (self-configuring), selbst reparieren (self-healing) und sich auch selbst optimieren (self-optimizing). OGSA definiert Attribute die für das Self-Management von Grids benötigt werden. Der Standard schränkt die Betrachtungen auf einen konzeptionellen Level ein und macht keinerlei Annahmen oder Vorschläge für deren Umsetzbarkeit. Ein Grundkonzept, das für Self-Management benötigt wird, sind Service Level Agreements (SLAs). Ein SLA ist eine Vereinbarungen zwischen einem (Dienst-) Provider und einem Kunden, in der die Eigenschaften und die Güte der abonnierten Dienste vertraglich fixiert werden. Die Dienstgüte wird auch als Quality of Service (QoS) bezeichnet. Innerhalb eines SLA werden Pflichten und Ziele (Service Level Objectives (SLOs)) der Diensterbringung festgelegt. In einer Betriebsumgebung ist es oft erforderlich, das Verhalten von Komponenten und Diensten zu kontrollieren. In einem Self Management System wird dies häufig dadurch erreicht, dass Policies aus Geschäftszielen abgeleitet werden. Diese Policies werden von so genannten Service Level Managern (SLM) festgelegt und ggf. angepasst und steuern dann das Verhalten der zu administrierenden Komponenten. SLMs sind Software-Komponenten und werden selbst durch Policies gesteuert. Monitoring Action Analysis Projection Job Level Grid System Level Abbildung 10: SLM Regelkreis [26] In Abbildung 10 ist der SLM Regelkreises angegeben der verwendet wird, um Dienste zu kontrollieren und anzupassen. Dieser Regelkreis kann auf den unterschiedlichen Abstraktionsebenen verwendet werden. Im Beispiel wird er auf Ebene der Jobs verwendet. Die Analyse-Komponente des Regelkreis überwacht unablässig die Einhaltung von SLAs und QoS Parametern. Falls gegen SLAs verstoßen wird, die Gefahr einer SLA oder QoS Verletzung besteht, wird in der Projektionsphase untersucht,welche zusätzlichen Ressourcen oder Maßnahmen erforderlich sind, um die SLA Verletzung zu verhindern. In der Action Phase werden diese Ressourcen zur Verfügung gestellt bzw. zusätzliche Maßnahmen ergriffen Version 9.3 Seite 19

22 Für ein Self Management ist es erforderlich, Policies und ein modellbasiertes Management zu unterstützen. Der SLM orchestriert die dynamischen Änderungen in der Managment Infrastruktur basierend auf den Policies, die das Verhalten der Infrastruktur beschreiben. Dazu ist es erforderlich, sowohl den SLM als auch die Dienste durch geeignete Modelle zu beschreiben. Eine Planungskomponente ermittelt die Anforderungen einer Ressource, damit diese optimal betrieben werden kann. Zusätzliche Ressourcen werden durch ein geeignetes Capacity Management zur Verfügung gestellt, das u. a. auch das Inventory und Asset Managemtn beinhaltet. Die tatsächliche Instantiierung und Konfiguration zusätzlicher Ressourcen übernimmt das Provisioning. Die Analyse-Komponenten muss in der Lage sein, eine Problem und Root Cause Analysis durchzuführen. Dabei wird versucht, aus den Monitoring Daten die Ursachen der Probleme zu ermitteln. In diesem Zusammenhang werden zur Verdichtung der Monitoring Daten Filter und Korrelations-Komponenten verwendet. Neben dieser retrospektiven Betrachtung muss die Analyse-Komponente auch in der Lage sein prädiktiv die Auswirkungen von Änderungen in der Infrastruktur oder der Konfiguration vorherzusagen Information Services Die OGSA Informationsdienste sollen einen effizienten Zugriff auf Informationen über Anwendungen, Ressourcen und Dienste des Grid liefern. Sie sind nicht dafür gedacht als Zugriffsschnittstelle für Anwendungsdaten (z. B. Messdaten) in einem Daten-Grid zu dienen. Information im Sinne des OGSA Informationsdienstes sind statische und dynamische Daten der OGSA Infrastruktur. Der Informationsdienst muss ein einheitliches Namensschema unterstützen und Mechanismen zur Informationsübermittlung, zur Suche, zum Logging und zum Monitoring bieten. Dabei wird von einem generischen Producer/Consumer Muster ausgegangen. Der Producer erzeugt oder besitzt die Daten, die der Consumer nutzen möchte. Die beiden können entweder direkt miteinander kommunizieren oder aber über einen Intermediary, der zwischen Producer und Consumer sitzt, eine Vorverarbeitung der Daten durchführen. Ein Consumer kann sich beim Intermediary oder direkt beim Producer für bestimmte Daten registrieren und erhält diese sobald neue Daten erzeugt werden. Funktional betrachtet, muss ein Informationsdienst ein eindeutiges Namensschema zur Beschreibung der Informationen festlegen. Es bedarf eines Discovery-Dienstes, um nach Informationen suchen zu können. Daneben benötigt man effiziente Kommunikationsverfahren zur Übertragung der Daten sowie Logging und Monitoring Komponenten. 1.3 Grid Middleware Die technische Umsetzung der Grid-Dienste und der Anforderungen aus den vorhergehenden Abschnitten erfolgt durch eine so genannte Grid Middleware. Die Middleware ist auch in der Lage, die Heterogenität der tatsächlichen Ressourcen und Ausführungsumgebungen zu verschatten. Das heißt, dass die Grid Middleware die Unterschiede in Hardware Plattformen und der verschiedensten Betriebssystemen vereinheitlicht. Im Folgenden werden zwei der wichtigsten Vertreter der Grid Middleware, das Globus Toolkit und Unicore, exemplarisch vorgestellt Globus Toolkit Die Globus Alliance leitet die wissenschaftliche Untersuchung und die Entwicklung von Grid-Technologien und will Wissenschaftler und Entwickler zusammenbringen, um Standards ebenso wie die Grid Middleware Globus Toolkit (GT) weiter zu entwickeln und zu verbessern Die wichtigsten Partner dieser Allianz sind das Argonne National Laboratory, die Universitäten von Southern California, Chicago, Edinburgh, das Schwedische Center for Parallel Computers sowie das National Center for Supercomputing Applications (NCSA) Version 9.3 Seite 20

23 Historie, Unterschiede zwischen den Globus Versionen Die erste Version des Globus Toolkit wurde im Herbst 1998 veröffentlicht [34]. Zu einer Anwendung in breiterem Rahmen kam es aber erst mit der Veröffentlichung von GT2 im Jahre Mit der Version 3 des Globus Toolkit wurden für die Implementierung der Komponenten Web Services verwendet und es wurde OGSI implementiert. Aus den oben genannten Gründen konnte sich OGSI jedoch außerhalb der Grid Community nicht durchsetzen. Dies führte auch dazu, dass sehr viele Grid-Nutzer nicht bereit waren, von GT2 auf GT3 zu wechseln. Deshalb entschloss man sich mit der aktuellen Version GT4, die im Jahr 2005 freigegeben wurde, verstärkt auf das Web Services Ressource Framework zu setzen. GT4 ist auch eine Referenzimplementierung für OGSA. In Abbildung 11 sind die Kommunikation zwischen dem Globus Client und verschiedenen Globus Diensten (die auf einem Server laufen) sowie die Komponenten des Globus Toolkit dargestellt. In der Abbildung sind auch die Unterschiede zwischen GT2 und GT3/GT4 verdeutlicht. Die GT2 Komponenten, die noch keine Web Services unterstützen sind, weiß hinterlegt. Die Kommunikation dort erfolgt über Globus eigene Mittel. Erst ab Version 3 wurden die Komponenten als Web Services implementiert und die Kommunikation erfolgt hier über Web Service Standards und mittels SOAP. Abbildung 11: Kommunikation zwischen Globus Client und Server; Globus Komponenten [28] Im Folgenden wird ausschließlich die Web Services basierte aktuelle Version (GT4) weiter betrachtet Globus Web Services GT4 stützt sich auf verschiedene Web Service Standards ab, d. h. insbesondere das Globus Dienste als Web Services implementiert sind. Aus der Sicht eines Clients ist ein Web Service eine über das Netz erreichbare Einheit, die in der Lage ist SOAP (Simple Object Access Protocol) Nachrichten zu verarbeiten [56][42][43]. D. h. zur Kommunikation zwischen einem Client und einem Grid Service wird SOAP verwendet, das über verschiedenste Kommunikationsprotokolle (z. B. HTTP, TCP, Mail, u. ä.) übertragen werden kann Version 9.3 Seite 21