Entscheidende Sicherheitsaspekte für Grid Computing
sind die
Möglichkeit den Zugriff auf Ressourcen für
autorisierte Teilnehmer zu gewährleisten. Die
Authentizität
und die Berechtigung die bereitgestellten Ressourcen zu nutzen wird
durch bereits bewährte Methoden und Technologien erreicht.
Zertifikate stellen die Identität eines Teilnehmers sicher,
Verschlüsselung der Datenpakete gewährleisten die
Übertragungssicherheit und Policies liefern den rechtlichen
Hintergrund zur Nutzung der angebotenen Ressourcen.
Durch den heterogenen Aufbau der Grids müssen die lokalen
Sicherheitslösungen integriert werden
können. Wird
der Zugriff auf ein Grid durch ein Gridportal bereitgestellt, kann die
Sicherheit duch einmaliges Anmelden (Single-Sign-On z.B. mit Kerberos)
erhöht werden und lokale Verzeichnisdienste (z.B. LDAP)
können durch ein Abbild der Organisation das
Berechtigungskonzept liefern.
Aus Sicht der Gridteilnehmer sind Funktionssicherheit (Safety), Autorisierung und Authentifizierung (Security) sowie die Vertraulichkeit (Confidentiality) der angebotenen Ressourcen entscheidend. Diesen Aspekten kann durch Schaffung von Standards und der Offenlegung der definierten Schnittstellen und Protokolle entspochen werden.
[top]In einem Grid muß die Möglichkeit
geschaffen werden die
Ressourcen horizontal dynamisch an das Grid anzubinden. Ihre
Verfügbarkeit
für die Teilnehmer unterliegt dabei den Nutzungsbedingungen der einzelnen Ressourcen Provider. Für
den Nutzer sind sämtliche Ressourcen eines Service Grids
virtualisiert. Selbst wenn die einzelnen Ressourcenprovider
gegenüber dem Nutzer bekanntgegeben werden, ist die konkret
genutzte Ressource, die Aufgabenzuteilung sowie die Verwaltung der
durch den Workflow des Services beschriebenen Abläufe für den
Nutzer transparent.
Die Grid Protokoll Architektur ist eine generelle Untergliederung der Protokolle in Funktionsschichten. Dabei werden die Komponenten einer Gridarchitektur den jeweiligen Funktionsschichten zugeordnet, sodass eine funktionale Trennung erfolgt. Die Komponenten einer Funktionsschicht sind im Bezug auf charakteristische Merkmale gleich und bauen auf die durch niedrigere Schichten bereitgestellten Funktionen auf.
Grid und Internet Protokoll Architektur im Vergleich
Auf dem Fabric Layer befinden sich die konkreten Ressourcen, auf die über offene Protokolle der höheren Layer zugegriffen werden soll. Die Komponenten des Fabric Layers stellen dabei die angebotenen Ressourcen eines Gridteilnehmers (z.B. einer beteiligten Organisation) da und unterliegen seiner administrativen Kontrolle. Auf diesem Layer werden daher die lokalen ressourcenspezifischen Operationen der sowohl physisch als auch logisch vorhandenen Komponenten bereitgestellt. Herstellerspezifische Protokolle müssen zur Anpassung in die Protokollarchitektur in neutralen Protokollen vereinfacht werden, um den Zugriff außerhalb des eigenen Bereiches zu gewährleisten. Weiterhin müssen auf diesem Layer Abfragemechanismen bereitgestellt werden, um die Struktur, den Status und die Möglichkeiten der angebotenen Ressourcen an höhere Layer zu übermitteln. Auch die Reservierung einzelner Ressourcen für die Zuteilung von Aufgaben sollte ermöglicht werden, um eine dynamische Aggregation und die Qualität der auf höheren Layern angebotenen Services zu sichern. Sollten die einzelnen Komponenten nicht über diese Funktionalität verfügen, übernimmt eine geeignete Middleware wie z.B. das Globus Toolkit die Bereitstellung der notwendigen Mechanismen.
Typische Komponenten und wichtige Operationen wären auf diesem Layer beispielsweise
Auf dem Connectivity Layer
werden die wesentlichen Kommunikations- und
Authentifizierungsprotokolle definiert, um die Kommunikation zwischen
den einzelnen Ressourcen des Fabric Layers zu ermöglichen und
die Identität der Benutzer und der angebotenen Ressourcen
sicherzustellen. Der Datentransport, das Routing und Naming wird
über bewährte Kommunikationsprotokolle und -techniken
der Internetarchitektur ermöglicht.
Die oben angesprochenen Sicherheitsaspekte werden ebenfalls mit den Standards des Internets umgesetzt, um dem Sicherheitskonzept der vituellen Organisation zu genügen. Autentizität und Authorisierung wird dabei durch
Auf dem Ressourcen Layer findet das Management der unteren
Layer und die Umsetzung des Teilens von Ressourcen statt. Eine sichere
Vermittlung, Initiierung, Überwachung und Steuerung der
verteilten Komponenten des Fabric Layers, sowie die Abrechnung der
einzelnen Ressourcen bei deren Nutzung, wird von diesem Layer mit
diversen Management- und Informationsprotokollen unterstützt.
Diese Protokolle müssen so einfach wie möglich
gehalten bleiben, um eine universelle Verwendbarkeit für das
breite Spektrum der unterschiedlichen Ressourcentypen zu
ermöglichen.
Die Informationsprotokolle liefern den Status der angebotenen
Ressourcen, um Informationen über die Konfiguration,
die Auslastung und die Nutzungsbedingungen zu erhalten. Die
Managementprotokolle und die dafür vorgesehenen
Softwareschnittstellen übernehmen dabei den Zugiff
auf die einzelnen Ressourcen, um beispielsweise Prozesse zuzuteilen
oder die Erreichbarkeit von Daten zu gewährleisten, jedoch
immer unter dem Vorbehalt den Policies des Anbieters zu
genügen und eine nachträgliche Verrechnung zu
ermöglichen.
Auf diesem Layer werden also die Protokolle bereitgestellt, die das Zusammenspiel der Teilnehmer einer virtuellen Organisation untereinander regeln. Das Globus Toolkit unterstützt diese Layerfunktionalität mit den standardbasierten Protokollen des Grid Ressource Information Protokolls (GRIP) und des HTTP basierten Grid Ressource Allocation and Management Protokolls (GRAM).
Während auf dem Ressourcen Layer noch einzelne Ressourcen betrachtet wurden und auf die Einfachheit der verwendeten Protokolle großen Wert gelegt wurde, wird auf dem Collective Layer eine globale Sicht auf die angebotenen Services über Protokolle und Softwareschnittstellen erreicht. Die verschiedenen Ressourcen werden hier gebündelt und es wird eine Differenzierung zwischen den verschiedenen Angeboten vorgenommen, wobei auch speziellen Aufgaben durch Definition spezieller Services genügt werden kann. Die eigentliche Gridfunktionalität wird so durch die unterschiedliche Verwendung der verschiedenen Services erreicht, indem Workflows definiert werden.
Typische Services dieses Layers sindAuf dem Application Layer steht die eigentliche Anwendung für die Benutzer einer virtuellen Organisation im Vordergrund. Aus der Anwendung heraus werden die Schnittstellen über die jeweiligen Protokolle der unteren Layer versorgt, so dass den speziellen Anforderungen der Anwendung durch die Verwendung der Services der unteren Layer entsprochen werden kann. Jede Benutzerinteraktion mit einer verteilten Ressource wird von diesem Layer angestoßen und an die Services der unteren Layer mit Hilfe der definierten Protokolle und Schnittstellen durchgereicht.
Das Globus Toolkit unterstützt die Funktionalität dieses Layers mit der Bereitstellung von Grid Service Frameworks und Bibliotheken für höhere Programmiersprachen wie C, Java und Python.
[top]Die Open Grid Service Architektur ist ist ein Modell des Global Grid Forums, um flexibel Komponenten in eine Problemlösungsumgebung mit Grid Computing zu integrieren. Dabei steht der Gedanke der Grid Services im Vordergrund. Die Grid Services basieren auf den bewährten Basistechologien der Web Services und erweitern deren Funktionalität, um dynamisches Binden der einzelen Services zur Schaffung dauerhafter Workflows.
Die OGSA beschreibt dabei das Verhalten von Grid Services und deren Instanzen in abstrakter Weise, so dass Themen wie die Semantik, das Erstellen, die Lebenszeit und die Kommunikation mit Insatnzen definiert werden, aber nicht die konkrete Arbeitsweise eines speziellen Services.
Vorerst wird der Gedanke der nutzerorientierten Services auf alle Bestandteile eines Grids ausgedehnt, womit alle Ressourcen des Grids zu Grid Services werden. Jeder Grid Service erhält standardisierte Service Daten im XML-Format, die die Informationen für eine konkrete Grid Service Instanz vorhalten und über standardtisierte Operationen abgefragt werden können. So können spezielle Service Schnittstellen veröffentlicht und verfügbar gemacht werden. Weiterhin muss das dynamische Erstellen solcher Grid Service Instanzen und das Benachrichtigen der Instanzen untereinander zur Abbildung von Workflows ermöglicht werden.
Die serviceorientierte Sicht ermöglicht die Definition von Schnittstellen, ohne sich Gedanken über die Protokolle machen zu müssen, die diese Schnittstellen umsetzen sollen. Das OGSA Modell sieht hierfür Standardschnittstellen (in WSDL Porttypen) vor, die die oben genannte Grundfunktionalität für Grid Services verwirklichen.
Jeder Grid Service muss wenigstens die Grid Service Schnittstelle implementieren, um seine Servicedaten erreichen zu können und ein definiertes Lifetime Management zu gewährleisten. Service Daten beschreiben die Anforderungen der Schnittstelle an einen Grid Service, der diese Schnittstelle implementiert. Die Implementierung weiterer Standardschnittstellen erweitert diese Grundfunktionalität.
Hier eine Liste der von der OGSA vorgeschlagenen Standardschnittstellen:| Port Typ | Operation | Beschreibung |
| Grid Service | Find Service Data | Abfrage einer Vielzahl von Informationen zu einem Grid Service (Handle, Referenz, Handle Map) |
| Set Termination Time | Setzen und Auslesen der Terminierungszeit für eine Grid Service Instanz | |
| Destroy | Terminieren einer Grid Service Instanz | |
| Notification Source | Subscribe to Notification Topic | Hinzufügen von Benachrichtigungen von servicebezogenen Ereignissen |
| Notification Sink | Deliver Notification | Asynchrones Versenden von Benachrichtigungsmeldungen |
| Registry | Register Service | Registrierung von Grid Service Handles |
| Unregister Service | Löschung einer Registrierung eines Grid Service Handles | |
| Factory | Create Service | Erstellen einer neuen Grid Service Instanz |
Ein Grid Service, der die Factory Schnittstelle implementiert ist in der Lage dynamisch neue Grid Service Instanzen zu erstellen. Diese neu erstellten Instanzen verfügen über einen Grid Service Handle, der die Instanz dauerhaft eindeutig identifiziert, und über eine Grid Service Referenz, die die aktuell verwendete Ressource ausweist. Das Mapping von Handle zur Referenz wird über die Handle Map vollzogen, wobei die einzelnen Handles über eine Registry bekannt gegeben werden.
Durch das Konzept von Handle und Referenz ist sichergestellt, dass eine Grid Service Instanz von ihrer konkreten Ressource losgelöst ist. Die Referenz ist nicht dauerhaft und dient zum dynamischen Binden der für die Service Instanz verantwortlichen Ressource an den Anfragenden (Client) des Services. Das Möglichkeit zwischen Service Referenzen zu wechseln garantiert dabei das unterbrechungsfreie Umschalten zwischen den Ressourcen während der Abarbeitung eines Jobs.
Ein Grid Service mit implementierter Registry Schnittstelle dient zur Registrierung der in der jeweiligen Hosting Umgebung angebotenen Services und ermöglicht die Instanzierung dieser durch Veröffentlichung der Factory Services. Weiterhin dient er zur Registrierung der in dieser Umgebung laufenden Service Instanzen.
Die Notification Schnittstellen ermöglichen die Kommunikation von Service Instanzen untereinander. Die Benachrichtigungsquelle kann sich über servicebezogene Ereignisse mit anderen Instanzen austauschen und eine Antwort aller angesprochenen Instanzen bekommen, die beispielsweise den Erhalt der Nachricht quittieren. Durch diese Schnittstellen lassen sich Workflows zur automatischen Verarbeitung definieren und weiterhin die Aktivität der Instanzen überprüfen. Ständige Kommunikation zwischen den Instanzen ist beispielsweise für das Aktualisieren der Lebenszeit einer Instanz sinnvoll, da bei deren Ablauf die Instanz beendet werden würde.
Konkrete Grid Services, wie z.B. Scheduler-, Broker- und
Ko-Allokationsservices, implementieren wenigstens die Grid Service
Schnittstelle und liefern so die im OGSA Modell geforderte Dynamik der
Grid Service Instanzen, die über die Handles und Referenzen
gewährleistet wird.
Beispielhaft für die Verwendung von Grid Services in einer Hosting Umgebung soll hier das Gegenüberstellen von einer einfachen und einer virtuellen Hosting Umgebung sein (entnommen aus "The Physiology of the Grid" von Ian Foster, Carl Kesselman, Jeffrey M. Nick und Steven Tuecke):
Die einfache Hosting Umgebung verfügt über eine
administrative Domäne und es werden durch die
bereitgestellten Services nur lokale Ressourcen angesprochen. Die
farbigen Services können als Verwaltungsservices und die
weißen als Nutzerservices verstanden werden.
