2004_03_24_DGrid_AK2..
Werbung
D-Grid – AK2 Middleware und Services Bestandsaufnahme Datum Status Autor 13.05.2016 in Bearbeitung Dr. Ramin Yahyapour Inhaltsverzeichnis Inhaltsverzeichnis ................................................................................................................................................ 2 1 Überblick....................................................................................................................................................... 3 2 Bestehende Middleware-Komponenten ................................................................................................ 4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 3 Globus........................................................................................................................................................4 UniCore ................................................................................................................................................... 10 Fraunhofer Resource Grid ................................................................................................................. 12 Storage Resource Broker ................................................................................................................... 14 Platform LSF ........................................................................................................................................... 17 Platform Community Scheduler ..................................................................................................... 20 Sun Java System Portal Server ........................................................................................................ 22 Sun Grid Engine ................................................................................................................................... 24 GridSphere ............................................................................................................................................ 26 Resource Broker .................................................................................................................................. 28 Condor.................................................................................................................................................... 30 AVAKI ...................................................................................................................................................... 32 NSF Middleware Initiative ................................................................................................................ 34 Projekte ....................................................................................................................................................... 37 3.1 3.2 3.3 3.4 3.5 3.6 3.7 GRIP ......................................................................................................................................................... 37 GridLab GAT ......................................................................................................................................... 38 EGEE ........................................................................................................................................................ 40 Zertifizierung ........................................................................................................................................ 42 Zertifizierungsdienst GridKA............................................................................................................ 43 Conferencing ........................................................................................................................................ 45 Roaming ................................................................................................................................................. 47 1 Überblick Die vorliegende Bestandsaufnahme spiegelt die aktuellen Arbeiten im AK2 des D-Grid wieder. Hierzu fanden mehrere Treffen der beteiligten Partner statt, in denen die Vorgehensweise abgestimmt und eine Aufteilung der Themengebiete vorgenommen wurde. Die in den einzelnen Abschnitten vorgenommenen Bewertungen spiegeln die Meinungen der jeweiligen Partner wieder und stellen noch keine abschließende Bewertung im Arbeitskreis dar. Aufgrund der kurz- bis mittelfristigen Umsetzung einer ersten Version des D-Grids stehen für die Auswahl der verfügbaren Software-Komponenten insbesondere bestehende und allgemein akzeptierte Lösungen für den Produktionsbetrieb im Vordergrund. Es wurden daher die verfügbare Komponenten und existierende Lösungen identifiziert, die im folgenden auf ihre Verfügbarkeit, Verbreitung, Funktionsumfang, Schnittstellen, Vor- und Nachteile betrachtet werden sollten. 2 Bestehende Middleware-Komponenten 2.1 Globus Name der Komponente (des Systems, des Projektes): Globus Funktion der Komponente (des Systems): Eigenständiges System zum Betrieb eines Grids. Produzent der Komponente (des Systems): In der aktuellen Form entwickelt von der Globus Alliance (www.globus.org). In der Globus Alliance sind verschiedene wissenschaftliche Einrichtungen wie das Argonne National Laboratory, das Information Sciences Institute der Universitaet Sued Kalifornien, die Universitaet Chicago, die Universitaet Edinburgh, und das Center for Parallel Computers in Schweden zusammengeschlossen. Darueber wird das Projekt aus der Industrie von IBM, Microsoft und Cisco Systems unterstuetzt. Die Komponente (das System) wird zurzeit eingesetzt von: Globus wird als eigenständiges System wie auch als technische Grundlage spezialisierter Grid-Systeme in einer Vielzahl von Projekten eingesetzt. So dient Globus als Grundlage des European Data Grid und wird in mehreren Projekten aktiv weiterentwickelt, wie z. B. durch OGSA-DAI ( http://www.ogsadai.org.uk), welches einen einfachen Datenzugriff ueber ein Globus Grid zum Ziel hat. Wird auch vom Fraunhofer Resource Grid verwendet. Einbettung der Komponente (des Systems, des Projektes): Globus ist sowohl als eigenständiges System wie auch als Grundlage spezieller Grid-Systeme stark verbreitet. Es wird inzwischen als quasi-Standard fuer Grid-Systeme angesehen, weswegen weitere Projekte zur Entwicklung von Grid-Systemen häufig eine Interoperabilitaet mit Globus zum Ziel haben (z. B. Condor-G). Das Projekt GRIP entwickelte eine Middleware, die die Interoperabilitaet der Grid-Systeme Globus und UNICORE ermöglicht. Zum eigenständigen Einsatz von Globus sind keine weiteren Grid-Komponenten erforderlich. Bedeutung der Komponente (des Systems) im D-Grid Globus sollte im D-Grid eingesetzt werden, da es sich um den quasi-Standard fuer GridSysteme handelt, weswegen eine vergleichsweise gute Interoperabilitaet zu anderen GridSystemen gegeben ist. Es existieren eine Reihe von Komponenten, die aufbauend auf Globus weitere Funktionalitaeten wie erweitertes Scheduling bereitstellen (Globus Metascheduler CSF). In der neuesten Version des Globus Toolkit, GT3, werden GridServices als neuer Ansatz fuer Gridcomputing im Rahmen einer Erweiterung von WebServices durch OGSI/OGSA (Open Grid Services Infrastructure/Architecture) spezifiziert. Dieses neue Konzept wird derzeit in ersten Implementierungen evaluiert und hat bereits eine erweitertende Revision durch die Definition des WSRF (Web Services Resource Framework) erfahren, fuer die zur Zeit noch keine Implementierung verfuegbar ist. Globus stellt vier grundlegende Grid-Funktionalitaeten als Dienste bereit: 1. Ausfuehren von Anwendungen über GRAM: Globus Resource Allocation Manager Protokoll des Globus-Toolkit, das den Zugriff auf verteilte Grid-Resourcen ermöglicht. Er ermöglicht das Ausführen, Überwachen und Beenden eines Jobs auf einer bestimmten Ressource. Dazu nimmt er Anfragen entgegen, reserviert die nötigen Ressourcen und startet den Job. Die Anfragen werden mittels der Beschreibungssprache RSL formuliert. Während der Abarbeitung informiert er den Client über den Status des Auftrages und aktualisiert den MDS. Der Zugriff auf den GRAM erfolgt über eine einheitliche Schnittstelle. Diese wird als gatekeeper bezeichnet. Realisiert wird der gatekeeper als Serverdienst, der über einen bestimmten Port angesprochen werden kann. Dieser Dienst muss in der Lage sein die lokalen Ressourcenmanagementmechanismen zu nutzen. Dadurch wird die Verbindung zu der ressourcenspezifischen Software hergestellt. Ein Coallocator ist nötig, wenn ein Job über mehrere Ressourcen verteilt bearbeitet werden soll. Er ist dafür zuständig die Kommunikation mit den verschiedenen GRAMs zu koordinieren. Als Beispiel implementation liefert das Globus Toolkit den Coallocator Dynamically Updated Request Online Coallocator DUROC mit. Für das GRAM-Protokoll gibt es verschiedene Implementierungen, z.B. für Java im Rahmen des Java-CoG. Probleme: Arbeitet schlecht mit Firewalls zusammen, da Monitoring in der Regel über einen HTTPS-Callback erfolgt. Eine mögliche Lösung ist die Einrichtung eines Virtual Private Network VPN, welches einen einheitlichen IP-Adressraum gewährleistet. Relative lange Zeitdauer, bis ein Job wirklich abgeschickt ist (ca. 1-5 Sekunden). Kann bei vielen kleinen Jobs zu Engpässen führen. Jeder Nutzer, der GRAM verwenden möchte, muss im lokalen gridmap-file mit seinem Zertifikat eingetragen sein. 2. Zugriff auf und Transfer von Dateien ueber GridFTP: Grid File Transfer Protocol GridFtp ist ein reliable data transfer protocol fuer den Zugriff auf entfernte Dateien. Es basiert auf dem Standard-FTP-Protokoll (RFC 959) und wurde um folgende Features erweitert: Datensicherheit: unterstuetzt werden GSI- und Kerberos-Authentisierung partial file transfer synchroner und asynchroner file-to-memory Datenuebertragung third-party file transfer (direkte Server-to-Server Dateiuebertragung) paralleler/striped Datentransfer ueber mehrere data channels Restart-Funktionalitaet manuelle und automatische Aushandlung von TCP-Buffergroessen Globus Implementation Globus implementiert des GridFTP-Protokoll als API: unterteilt in globus_ftp_client und globus_ftp_control libraries Tools: GridFTP-Server, FTP client tools (interaktive/batch mode, third-party transfer) 3. Informationssystem MDS: Monitoring and Discovery Service Die Informationsdienste des Globus Toolkits werden unter dem Namen Monitoring and Discovery Service (MDS) zusammengefasst. Der MDS besteht aus zwei Arten von Diensten, dem Grid Resource Information Service GRIS und dem Grid Index Information Service GIIS. Der MDS dient der Speicherung von Daten über die Art und den Zustand von Ressourcen in so genannten Verzeichnissen. Dabei handelt es sich um statisch und dynamische Informationen. Zur Abfrage und Speicherung von Informationen wird das Lightweight Directory Access Protocol LDAP verwendet. Dieses Schema kann natürlich erweitert werden und an die jeweiligen Bedürfnisse angepasst werden. Für den Datenaustausch mit den GRIS und GIIS sind zwei Protokolle vorgesehen. Das Grid Information Protocol (GRIP) dient dem Abfragen der Daten von GRIS und GIIS. Das Grid Registration Protocol GRRP dagegen ist dafür gedacht, um Informationen in die Verzeichnisdienste zu "pushen". Ab GT3 hat sich der MDS grundlegend erweitert. Durch die Einführung von OGSI, ist es möglich geworden Dienste (Grid Services) auf einheitlichem Art und Weise abzufragen. Mit Hilfe von sogenannten Service Data Elements (ähnlich wie CORBA Property Service) kann man beliebig Informatioin an einen Dienst binden, abfragen oder aktualisieren. Jeder Dienst speichert seine Informationen selbst. MDS2 Clients können ohne Modifikation nicht direkt mit GT3 Index Service oder GT3 Service Data Elements kommunizieren. Das liegt daran das GT3 Index Service ausschließlich auf XML baut, hingegen MDS2 GIIS LDIF nutzt. 4. Sicherheitsinfrastruktur GSI: Grid Security Infrastructure Das Globus Toolkit nutzt die Grid Security Infrastructure (GSI) um eine sichere Kommunikation über das Netzwerk zu gewährleisten. Die wichtigste Komponenten der GSI ist der Secure Conversation Service, diesem stehen verschiedene Sicherheitsmechanismen zur Verfügung: TSL/SSL: für sichere Authoriserung und Nachrichteverschlüsselung. SOAP Security nutzt die offiziellen W3C Standards für WS-Security, XML Encryption und XML-Signature X.509 Identitäts Zertifikat: Authentifizierung der Nutzer X.509 Proxy Zertifikat: Kommunikation und Authentifizierung Zwei der wichtigsten Sicherheitsanforderungen, die mit GSI realisiert wurden, sind Single Sign on und Delegation. Mit Hilfe dieser Mechanismen muss sich der Nutzer nur einmal authentifizieren und kann dann entsprechend seiner Berechtigung alle Ressourcen und Dienste nutzen. Durch das gegenüber von GT2 verbesserte Sicherheitsmodell vereinfacht sich die Integration von GT3 in geschützte Umgebungen. II. Globus Versionen Globus 2.x: GT2 Globus 3.x: GT3 Globus 2.x: GT4 III. Benutzung durch Grid-Anwender Bislang stellt Globus drei unterschiedliche Programmierschnittstellen zur Nutzung durch Grid-Anwender bereit: Ein natives C-API: Diese Schnittstelle stellt Bibliotheken und APIs, die es ermoeglichen Basis-Dienste von Globus (low level middleware) in C/C++ Programmen zu nutzen, bereit. Diese Basis-Dienste existieren in dieser Form seit der Version 2 des Globus Toolkit und umfassen u.a. Job Submission (GRAM), Data Transfer (GridFTP), Service Access (MDS) und Security (GSI). Die CoGs (Commodity Grid Kits): Ein CoG besteht aus programmiersprachenspezifischen Bibliotheken und APIs, die es ermoeglichen BasisDienste von Globus in Programmen, die nicht in C/C++ geschrieben sind, zu nutzen. Der Funktionsumfang eines CoGs entspricht im Wesentlichen dem des C-APIs. CoGs existieren fuer verschiedene Programmiersprachen wie Java, Perl, Python, fuer die Middleware CORBA und zur Integration in Matlab. WSRF (Web Service Resource Framework) bzw. OGSI/OGSA: Die Globus Alliance entwickelt in einer derzeitigen Initiative das WSRF, eine Erweiterung von OGSA. OGSA (Open Grid Services Architecture) basiert auf den Web Services Standards des W3C (SOAP, WSDL etc.) und definiert eine verteilte GRID Architektur auf Basis dieser Standards. Ausser begrifflichen Definitionen umfasst OGSA die technische Spezifikation von OGSI, einer moeglichen OGSA Implementierung. Das Globus Toolkit (GT3) stellt eine konkrete Implementierung von OGSI inkl. diverser Tools dar. Im WSRF sind die OGSI Spezifikationen in mehrere Einzelspezifikationen unterteilt und um neue Features erweitert. Aufgaben und Funktionsweise der einzelnen Technologien werden im folgenden kurz zusammengefasst. C-API, CoGs Um integrierte Grid Computing Environments (GCE) in Form eigener, problemspezifischer Clientanwendungen zu entwickeln, stehen in Globus mit dem CAPI bzw. den Commodity Grid Kits (CoGs, http://www-unix.globus.org/cog/) Programmierschnittstellen zur direkten Nutzung von GRAM, GridFTP, MDS und GSI zur Verfuegung, die die benoetigte Funktionalitaet zur Jobausfuehrung vergleichbar der Kommandozeilenprogramme bereitstellen. Mithilfe des C-API oder eines CoGs koennen Client-Anwendungen entwickelt werden, die direkt ohne Benutzung von Kommandozeilentools Dienste konfigurieren und Funktionalitaet von Globus nutzen koennen. Die CoGs benutzen spezielle Konstrukte der jeweiligen Sprache, um dem Entwickler eine moeglichst nahtlose Integration von Anwendungslogik und GlobusInteraktion in der Clientanwendung zu ermoeglichen. Das C-API und die CoGs bieten somit die Moeglichkeit des Zugriffs auf ein JobSubmission-System. Fuer die einzelnen Jobs selbst steht keine globusspezifische Funktionalitaet bereit, Job-Synchronisation und -Kommunikation in verteilten Anwendungen sind Aufgaben des Entwicklers. Globus bietet fuer das Anwendungsszenario solcher weit verteilten Anwendungen die nachfolgend beschriebenen GridServices, deren HTTP-basierte Kommunikation zudem moegliche Probleme mit Firewalls und Gateways einer auf anderen Kommunikationsprotokollen basierenden Loesung vermeidet. WSRF, OGSI/OGSA Dieser Teil der Bestandsaufnahme stellt den derzeitigen Status der Spezifikation von WSRF und OGSI dar. WSRF ist eine Erweiterung von OGSI. Die derzeit verfuegbare GT3 Implementierung umfasst bislang nur die fuer OGSI spezifizierten Features. Im folgenden wird aufgezeigt welche Features OGSI beinhaltet, worin die Erweiterungen von WSRF gegenueber OGSI bestehen und welche Defizite die derzeitige Spezifikation aufweist. OGSI nutzt die Features von WebServices : Web Services sind plattform- und sprachunabhaengig, da die Kommunikation auf XML basiert. Folglich kann beispielsweise ein C-Programm unter Windows einen Web Service, der in Java programmiert wurde und auf einem Linux Rechner laeuft, ansprechen. Der Nachrichtenaustausch ist mittels HTTP moeglich. Daher bieten sich Web Services als Verteilungstechnologie, insbesondere fuer Internet-weite Applikationen an (HTTP Nachrichten koennen problemlos ueber Internet-Proxyund Firewall-Grenzen hinweg uebertragen werden im Ggs. zu CORBA, RMI etc.) Typische Grid Anwendungen sind z.B. komplexe mathematische Berechnungen, die i.A. nicht durch Ausfuehrung einer einzelnen Operation durchgefuehrt werden koennen, sondern durch eine Abfolge vieler Operationen, die evtl. abhaengig voneinander sind. Web Services sind zur Implementierung solcher Dienste nicht unmittelbar geeignet, da sie zustandslos und intransient sind. Zustandslos bedeutet, dass ein Web Service keine Informationen ueber die Dauer eines Aufrufs hinweg bereithalten kann. Verschiedene Web Services Container ermoeglichen es inzwischen, Informationen zwischenzuspeichern, so dass ein Web Service beim Ausfuehren einer Operation auf Informationen aus vorhergehenden Aufrufen zurueckgreifen kann. Dabei koennen sich durch die Intransienz von Web Services Probleme ergeben. Intransienz bedeutet, dass alle Clients mit demselben Web Service kommunizieren, dessen Fortbestand alle Clients ueberdauert. Folglich kann es beim Zugriff auf dauerhaft gespeicherte Informationen durch mehrere Clients zu Konflikten kommen. OGSI erweitert plain Web Services daher um das Konzept der Factories. Eine Factory ist dabei ein Web Service, der einen Verbund so genannter Service-Instanzen bereithaelt und diese auf Anforderung von Clients zur Verfuegung stellt. ServiceInstanzen sind zustandsbehaftet und transient und werden in OGSA als Grid Services bezeichnet. WSRF umfasst neben den OGSI Basisklassen und Schnittstellendefinitionen fuer Factories und Service-Instanzen weitere Features, die bei der Implementierung von Grid Services benutzt werden: Lifetime Management: Durch standardisierte Callback Methoden kann in bestimmte Vorgaenge bei der Verwaltung von Grid Services (z.B. Bereitstellung durch die Factory, Deaktivierung etc.) eingegriffen werden. Nuetzlich ist das z.B. fuer Logging, Runtime-Loadbalancing, Resource Management. Service Data: WSDL beschreibt nur technische Details, wie z.B. Operationen, Signaturen etc. Fuer einen Grid Service, koennen zusaetzlich Charakteristika wie Leistungsfaehigkeit etc. (Resource Properties) gespeichert werden. Asynchrone Benachrichtigungen: WSRF spezifiziert sog. Notifications. Dabei handelt es sich um einen Messaging-Mechanismus nach einem Publish/SubscribePrinzip ueber den Grid Services und Clients asynchron Nachrichten austauschen koennen. Delegationsmodell: Komplexe Grid Services koennen oftmals nicht als Erweiterungen der in OGSI vordefinierten Basisklasse implementiert werden, da bereits Vererbungsbeziehugen zu anderen Klassen bestehen. Daher ist es auch moeglich Services durch implementierung sogennannter Operation Provider Schnittstellen zu implementieren. Die Konfiguration eines solchen Delegationsmodells ist etwas aufwendiger als fuer Standard-Grid Services, dafuer jedoch flexibler und bei objektorientierten Technologien, die keine Mehrfachvererbung zulassen (Java) evtl. unumgaenglich. Stateful Resource Addressing: Um zustandsbehaftete Service Instancen in einem Container zu identifizieren, enthalten die Reference Properties (Bestandteil der XML-Deskriptoren eines WSRF Services) eine zusaetzliche Kennung. Dieses Prinzip wurde aus den kuerzlich vom w3c veroeffentlichten WS-Addressing Spezifikationen uebernommen. Welche Schwachstellen hat die Komponente (das System) zurzeit: Das Grid Information System basiert zur Zeit auf LDAP, welches sich zum Teil als ungeeignet für den Grid-Betrieb erwiesen hat. Da die verschiedenen Bausteine des Globus Toolkits relativ unabhängig voneinander verwendet werden können, kann das Grid Information System auch durch andere Dienste (z.B. [create Ganglia]) realisiert werden. Durch WSRF ist eine Verteilungsplattform fuer Internet-weite verteilte Programme definiert. Um eine universelle Programmierschnittstelle fuer Grid-Anwendungen bereitzustellen, muessen in der derzeitigen Implementierung in GT3 noch verschiedene Defizite behoben werden. Folgende Probleme sind aufgefallen: Generische Grid Services werden unzureichend unterstuetzt: Die OGSI Spezifikation beschreibt derzeit nicht, wie Services mit beliebigem Code parametrisiert werden koennen (MMJS ist dafuer unzureichend) Die CoGs sowie die APIs fuer OGSI sind Globus-spezifisch, fuer Globus entwickelte Client-Anwendungen sind somit nicht ohne weiteres auf andere Grid-Systeme uebertragbar. Im Rahmen des D-Grid, in dem eine Integration verschiedener GridSysteme zu erwarten ist, sollte eine moeglichst einheitliche Programmierschnittstelle fuer saemtliche Services verschiedener Grid-Systeme genutzt werden, die in dieser Form nicht exisitert. Eine solche Schnittstelle wird ebenfalls in der Bestandsaufnahme "einheitliche Programmierschnittstelle fuer Grid Middleware (s. a.SAGA)" gefordert. Es ist unklar, welche Basisdienste auf welche Weise in OGSA integriert sind: Fuer einzelne Basisdienste wie GridFTP oder GRAM gibt es entsprechende Services (RFTS bzw. MMJS), fuer andere (z.B. MDS) nicht. Hier ist zu klaeren ob diese in OGSAAnwendungen (mittels CoGs) vom Anwendungsentwickler selbst angesprochen werden muessen oder unnoetig sind. Der Zusammenhang zwischen den CoGs und OGSA ist in der derzeitigen Dokumentation unklar. Derzeitige Grid Services sind teilweise mithilfe von CoGs implementiert. Hier ist zu klaeren ob das sinnvoll ist oder ob bei zukuenftigen Globus Toolkit Versionen die Funktionalitaet der CoGs vollstaendig in die OGSIImplementierung integriert sein wird. Es gibt derzeit keine Referenzanwendung, anhand der die Verwendung von Globus als Grid-System vollstaendig aufgezeigt wird. Die Beispiele der Tutorials beschraenken sich entweder auf low-level Middleware (Verwendung der Basis-Dienste wie Job-Submission und File-Transfer mittels CoGs) oder high level Service Implementierungen, die Grid Services voellig unabhaengig von einer darunterliegenden Middleware beschreiben und meist nur triviale Funktionalitat (z.B. einfache Arithmetik) bereitstellen. Globus basierte Grid Anwendungen sind derzeit nur bei Organisationen, die nicht der Globus Alliance angehoeren, zu finden (z.B. ICENI beim Imperial College of London) und daher zu speziell bzw. nicht dokumentiert. Bislang exisitiert als offizielle Implementierung des GridFTP-Protokolls nur der in Globus enthaltene GridFTP-Server. Er gewaehrleistet einen sicheren effizienten Dateizugriff auf entfernte Filesysteme (insbesondere mit sehr grossen Datenmengen). Hoehere, fuer ein Data Repository Server erforderliche Funktionalitaet (Caching, Versioning, MetadatenVerwaltung, etc.) fehlen. GridFTP kann aber als Grundlage zur Implementierung dieser Funktionalitaet genutzt werden. Desweiteren implementiert der Globus-GridFTP-Server nur die im GridFTP-Protokoll spezifizierte Basisfunktionalitaet. Es fehlen Moeglichkeiten zu dessen einfacher Erweiterung um nutzerdefinierte Funktionen, z.B. der flexiblen Einbindung von eigenen Server-side Plugins, deren Unterstuetzung im Protokoll explizit vorgesehen ist. Da die Architektur der gegenwaertigen GridFTP-Server-Implementierung auf dem wuftpd-Code basiert, erweist sich dessen Erweiterung um solche Funktionalitaet als schwierig und wird von den GlobusEntwicklern deshalb auch nicht angestrebt. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Das Globus-Team entwickelt derzeit einen eigenen Globus Striped FTP Server (SFTPD), der Server-side Plugin Funktionalitaet unterstuetzt und die wuftpd-basierte GridFTPImplementierung voraussichtlich in einer der naechsten Globus-Releases ersetzen wird. Erarbeitet von: Jens Müller, Uni-Münster Andreas Hoheisel, Fraunhofer FIRST Thomas Radke, AEI Golm Jan Duennweber, Uni-Münster … (bitte ergänzen) Diese Arbeiten laufen in enger Zusammenarbeit mit dem GridLab-Projekt, in dessen Rahmen (WorkPackage 8) applikationsspezifische GridFTP-Server-Plugins fuer effiziente entfernte Visualisierungsmethoden entwickelt werden. 2.2 UniCore Name der Komponente (des Systems, des Projektes): UNICORE (Uniform Interface to Computing Resources) Funktion der Komponente (des Systems; Ziel des Projektes): Vertikal integriertes Grid System/Grid Software Produzent der Komponente (des Systems; Projektbeteiligte): Intel (Klient), Fujitsu (Server plus Klientenbibliothek), die Teilnehmer der Projekte UNICORE, UNICORE Plus, EUROGRID, GRIP, OpenMolGRID, NaReGI, … Die Komponente (das System) wird zurzeit eingesetzt von: Deutsche Höchstleistungsrechenzentren, DWD, Cineca, diversen Projekten weltweit (OpenMolGRID, NaReGI, DEISA, RealityGrid, …), unbekannte Anzahl weiterer Benutzer Einbettung der Komponente (des Systems, des Projektes): Es existiert eine Anbindung an Globus (siehe Bestandsaufnahme GRIP), eine Anbindung an Condor ist in Entwicklung (NaReGI). UNICORE hat eine Schnittstelle (Target System Interface, TSI; Incarnation Data Base, IDB) zu Betriebssystem und Resource Management System des Ziel-Rechners. Diverse NQS-Dialekte, LL, LSF, PBS, Sun Grid Engine sowie verschiedene Unix Systeme inklusive Linux sind bisher angebunden. Das Interface wird auch genutzt zur Einbindung von Globus-verwalteten Ressourcen. Die Grenzen zwischen reinen Ressourcenmanagern wie NQS, PBS und Grid Systemen wie Globus sind fließend. Der Einsatz einer anderen Komponente aus der D-Grid Bestandsaufnahme ist nicht notwendig, da UNICORE ein „vollständiges“ Grid System ist. Die hier gemachten Aussagen basieren auf den Erfahrungen des FZ Jülich und HLRS, welche seit Beginn an der Entwicklung von UNICORE beteiligt sind, und des ZHR. Bedeutung der Komponente (des Systems) im D-Grid: UNICORE als vertikal integriertes System auf Benutzerinterface und Workflow-Management bietet Benutzers bestimmter Anwendungsfelder gute Unterstützung, so dass es auf jeden Fall Bestandteil vom D-Grid sein sollte. UNICORE bietet Ende-zu-Ende Sicherheitsmechanismen mit X.509 Zertifikaten und Single sign-on, verschlüsselter Kommunikation, Zugang zu /Mitgliedschaft in verschiedenen Virtuellen Organisationen (VO) und den Übergang zur Globus Sicherheit (Generierung von Proxy Zertifikaten). statische Informationen über verfügbare Rechner innerhalb von VOs und die dem Benutzer zugreifbaren / anforderbaren Ressourcen. Informationen über den Job-Status und den Status der einzelnen Job-Schritte einschließlich eines Ablaufprotokolls und Standardoutput- und StandarderrorInformationen. Zugriff auf Rechner und Daten einschließlich Datenbanken. Daten werden pro UNICORE Job in einem temporären Job-Verzeichnis verwaltet (Trennung der Daten pro Job). Aufbau und Bearbeitung von komplexen Workflows mit Kontrollstrukturen wie Schleifen, Breakpoints, Überprüfung von Rückgabewerten, if-then-else, sequentielle Abhängigkeit, etc. Workflows können im graphischen Klienten komponentenweise erstellt oder über eine XML-Beschreibung (aus OpenMolGRID) automatisch erzeugt werden. Resource Management und Scheduling derart, dass der Benutzer den Tasks in seinem Workflow die Ressourcen-Anforderungen mitgibt (Defaults existieren), der UNICORE Server (NJS) übergibt die Tasks gemäß der Abhängigkeiten an den TSI, welches den Auftrag an das lokale Resource Management System übergibt. einen Resource Broker (entwickelt in EUROGRID, GRIP), der es erlaubt, RessourcenInformationen von Sites abzufragen und QoS Anforderungen zu stellen. Unterstützung für existierende Anwendungen (legacy codes). eine Server Administrator Schnittstelle mit Logging und Job-Kontrolle nach vielfältigen Kriterien. Ausführung aller Programme und Tools, die das Zielsystem bietet. z.Zt. keine Unterstützung für Metacomputing / MPI-Jobs und Co-Scheduling. die Schnittstellen Klient - Server Protokoll (UNICORE Protocol Layer, UPL), Jobbeschreibung (Abstract Job Object , AJO, Repräsentation eines UNICORE Jobs), UNICORE Server – Zielsystem (TSI), NJS – Resource Broker, NJS – File Transfer (zur Einbindung von z.B. GridFTP). Dokumentation für Benutzer (Klient), Administratoren (Gateway, NJS, TSI) und Entwickler (Plugin Interface, Quellcode (JavaDoc)). UNICORE ist verfügbar über den UNICORE Forum e.V. unter der Sun Community License (http://www.unicore.org/downloads.htm). In Kürze (April/Mai 2004) wird die komplette Software bei SourceForge unter einer BSD-ähnlichen Lizenz zur Verfügung stehen. Welche Schwachstellen hat die Komponente (das System) zurzeit: Als eine Schwachstelle von UNICORE wird das Fehlen eines dynamischen Informationsdienstes angesehen (die UNICORE Information Database ist statisch). Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: An UNICORE (und auch an der Entwicklung eines dynamischen Informationsdienstes) arbeiten sowohl die tragenden Firmen Intel und Fujitsu, als auch diverse Projekte (NaReGI, OpenMolGRID, UniGridS, ...), Institutionen und Personen im Umfeld des Grid. Zudem wird UNICORE in absehbarer Zeit via SourceForge als Open Source Software verfügbar gemacht, was die Einbindung weiterer Entwickler mit sich bringen wird. Erarbeitet von: Ph. Wieder, M. Romberg, FZJ; St. Wesner, HLRS; R. Müller-Pfefferkorn, ZHR 2.3 Fraunhofer Resource Grid Name der Komponente (des Systems, des Projektes): Fraunhofer Resource Grid Funktion der Komponente (des Systems): Institutsübergreifende Grid-Infrastruktur der Fraunhofer Gesellschaft basiert auf den Ergebnissen des durch das BMBF geförderten Prokjekts I-Lab. Ressource-Broker und Scheduler Werkzeuge zur Erstellung komplexer Grid-Job-Workflows für Nutzer mit wenigen ITKenntnissen Dienst zur Ausführung von Grid-Job-Workflows auf Basis von Globus-Protokollen. XML-basierte Ressourcen- und Grid-Job-Beschreibungssprache Portalzugang mit Taskmapping über Globus hinausgehende Sicherheitsinfrastruktur und Accounting Dienste werden als Webservice angeboten, Beispiel: Grid Job Handler (WorklflowManagement) Benutzung von X509 Standard-Zertifikaten User Management (zentrales mapfile-Deployment mit lokaler Zustimmung) Unterstützung von Ganglia (Cluster Monitoring) Der Großteil der entwickelten Middlewarekomponenten wird als Open-Source-Beitrag (GPL) unter dem Namen eXeGrid der Öffentlichkeit kostenlos zur Verfügung gestellt ( http://www.eXeGrid.net/). Produzent der Komponente (des Systems): Fraunhofer FIRST, IAO, IGD, ITWM, SIT Die Komponente (das System) wird zurzeit eingesetzt von: Fraunhofer Gesellschaft Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? basiert auf Globus Toolkit 2.4, Interoperabilität mit Globus basierten Grids Unterstützung/Anbindung von Batch-Systemen (z.B.: PBS mit Maui, condor) über Globus Scheduling setzt Ganglia-Installation voraus lässt sich leicht auch auf andere (nicht-Globus-basierte) Grid-Basis-Dienste umstellen Bedeutung der Komponente (des Systems) im D-Grid Die Komponente (das System) sollte im D-Grid eingesetzt werden, da sie die Fraunhofer-Gesellschaft mit ihren vorhandenen Grid-Ressourcen in das D-Grid einbindet sie leicht in andere (Globus Toolkit basierte) Grids eingebunden werden kann die einfache Erstellung und Ausführung von komplexen Anwendungen ermöglicht (vor allem aus dem Bereich Ingenieurwesen) eine industrielle Nutzung des Grids erleichtert Welche Schwachstellen hat die Komponente (das System) zurzeit: erbt trotz eigener Sicherheitsinfrastruktur Schwachstellen von Globus eigene Sicherheitsinfrastruktur muss ausgebaut werden, ist proprietäre Lösung noch in Prototyp-Stadium Derzeit Komponentenmodell, welches nur eine lose Kopplung von Komponenten unterstützt. Unterstützung von parallelen Anwendungen mit engerer Kopplung (MPI, CORBA) nur als "Atomic Jobs". Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Fraunhofer Gesellschaft Erstellt von: Uwe Der Andreas Hoheisel 2.4 Storage Resource Broker Name der Komponente: Storage Resource Broker (SRB) Funktion der Komponente: Am San Diego Supercomputer Center (SDSC) wir ein System entwickelt, das den Zugang zu unterschiedlichen Datenquellen vereinheitlichen soll. Im wesentlichen besteht das System aus den drei Komponenten: Storage Resource Broker (SRB), der als Client-Server Middleware den Zugang zu unterschiedlichen Datenquellen unter einer grafischen Oberfläche ermöglicht. Metadata Catalog (MCAT) zur Verwahrung der Metadaten, implementiert als eine relationale Datenbank: Oracle or DB2 or Sybase or PostgreSQL High Performance Storage System (HPSS) als zentrales Dateimanagement- und Speichersystem Durch im MCAT abgelegte, sogenannte data sets wird der konkrete physische Speicherort logisch zugeordnet. Die sets können zu Collections zusammengefasst werden. ReplicaManagement wird unterstützt. Produzent der Komponente: http://www.npaci.edu/DICE/SRB Die Komponente (das System) wird zurzeit eingesetzt von: Astronomy o CACR Computing Resource, National Virtual Observatory, 2 MASS Collection, DPOSS Collection, Hayden Planetarium Ecology and Environmental Sciences o CEED, Bionome, Hyper LTER, Land Data Assimilation System (LDAS), Knowledge Networks for BioComplexity(KNB) Medical Sciences o Visible Embryo Project Molecular Sciences o SSRL - Synchrotron Data Repository, AFCS - Alliance for Cellular Signaling Neuro Sciences o Biomedical Information Research Network (BIRN), TeleScience Portal, Brain Database, Brain Data Archiving, NPACI REU Physics and Chemistry o PPDG - Particle Physics Data Grid, GriPhyN, GAMESS, BaBar Digital Libraries and Archives o SIO Digital Libraries, National Archives and Records Agency, ADEPT, NSDL National Science Digital Library, California Digital Library, (CDL), Stanford Digital Library Project Data Grids : The following projects use the data grid capabilities of SRBMCAT. o ROADNet - Real-time Observatories Application and Data management, etwork, e-science at CLRC, UK Grid Starter, DOE ASCI Data, Visualization Corridor, NASA Information Power Grid, DOE SciDAC - Portal Web Services, NPACI Portal Projects, National Virtual Observatory, GriPhyN Education o Transana, Digital Insight Application o DataStreaming, AppLeS, DataCutter Fraunhofer Ressource Grid (Testbetrieb) Einbettung der Komponente: SRB ist ein Verteiltes Dateisystem Data Grid Management System Digitale Bibliothek Semantic Web SRB und Grid Technologien? “SRB ist ein komplettes Data-Grid-System Verbindungen zu Data Grid Research und Development / Produktion (PPDG, GriPhyN, BaBar, CDL, NASA Information Power Grid, …) Support Globus Grid Security Infrastructure (GSI) als Authentication Methode. Web Service Definition Language (WSDL) interface to the SRB (working area) OGSA-compliant SRB in Planung. Abstraction of User Space Single sign-on Multiple authentication schemes: certificates, passwords, tickets, group permissions, roles Virtualization of Resources Resource Location, Type & Access transperancy Logical Resource Definitions - bundling Abstraction of Data and Collections Virtual Collections: Persistent Identifier and Logical Name Space Replication & Segmentation Data Discovery User-defined Metadata Attribute-based Access (path names become irrelevant) Uniform Access Methods APIs, Command Line, GUI Browsers, Web-Access (WSDL, CGI) Parallel Access with both Client and Server-driven strategies MCAT: Metadata Catalog Stores metadata about Data sets, Collections, Users, Resources, Proxy Methods Maintains replica information for data & containers Provides “Collection” abstraction for data Provides “Global User” name space & authentication Provides Authorization through ACL & tickets Maintains Audit trail on data & collections Maintains metadata for methods and resources Provides Resource Transparency - logical resources Implemented as a relational database: Oracle or DB2 or Sybase Bedeutung der Komponente (des Systems) im D-Grid: Sollte eingesetzt werden, da weite Verbreitung. Welche Schwachstellen hat die Komponente (das System) zurzeit: Sicherheitsprobleme Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: SDSC SRB Group Erarbeitet von: Uwe Der 2.5 Platform LSF Name der Komponente (des Systems, des Projektes): Platform LSF (=Load Sharing Facility); Platform LSF Family of Products Funktion der Komponente (des Systems; Ziel des Projektes): LSF ist das umfassendste Distributed Resource Management System, seit 12 Jahren kontinuierlich weiterentwickelt und ebenso kontinuierlich erfolgreich im Markt. Auf eine Featureliste wird hier zugunsten von 3 ausgewählten D-GRID relevanten Aspekten verzichtet. (Mehr Details? www.platform.com oder Email an [email protected]) LSF als logisch lokaler Workload Management Cluster für heterogene Umgebungen o Lokaler Cluster über praktisch alle Betriebssysteme und Architekturen o Industrietaugliche Produkt-Qualität, Zuverlässigkeit, Durchsatz und Skalierung. o Der modulare Scheduler erlaubt die gleichzeitige zusätzliche und/oder alternative Verwendung kundenspezifischer Plug-Ins. Dies ist essentiell wichtig, um verschiedene Rechner-Architekturen aber auch System- (GRID-)-Topologien intelligent umsetzen zu können. Die Verwendung und Erstellung dieser Scheduler-Plug-Ins ist einfach, gut dokumentiert und mit offen gelegtem Source Code unterstützt (ftp.platform.com, login: anonymous, pwd: <your_email>) o Mit Beispiel Source Code offen gelegte und dokumentierte Schnittstellen, CLI, APIs für C und Java, SDK-Dokumentation o Web-Interface für User und Administration. Erweiterbar über offen gelegte Architektur und Schnittstellen. Somit auch Integration in Portale sehr einfach. o Logisch lokale Cluster können geographisch verteilt sein. Anwendungsbeispiel: Deutsche Bank: ein logischer LSF Cluster über Frankfurt und London LSF als logisch und ggfs. geographisch verteilter heterogener Workload Management Cluster = LSF MultiCluster GRID o Verbindet LSF Cluster verschiedener Eigentümer und überbrückt unterschiedliche Administrations-Standards und Security-Policies (Beispiel: DoD). o Industrietaugliche Produkt-Qualität, Zuverlässigkeit, Durchsatz und Skalierung. o Seit 1996 industrielle Referenzen für z.T. weltumspannende „Enterprise GRIDs“: Texas-Instruments, AMD, ENEA, Pharmacia, GM, DoD – Department of Defence (USA), DoE… viele mehr o LSF MultiCluster bildet wahlweise zentrale oder dezentrale Strukturen, hierarchischeoder Partner-GRIDs. o Durch die Möglichkeit, Partner-GRIDs unter „Gleichrangigen“ zu bilden, werden die wichtigsten nicht-technischen Hürden für eine GRID-Einführung umgangen. Siehe auch http://www.platform.com/barriers/ . LSF Applikations-Integration o LSF, ob im lokalen Cluster oder im GRID, geht nach dem Prinzip „Remote Execution“ vor. Daraus folgt, dass grundsätzlich jede Applikation, ohne Anpassung oder Recompilation, über LSF laufen kann. o LSF unterstützt erschöpfend viele MPI Implementierungen und PVM. o Integrationen umfassen Fragestellungen des User-Environments und der Verfügbarkeit gewisser Infrastruktur-Dienste auf den möglichen Execution-Hosts der komfortablen Nutzung im aktuellen verteilten Umfeld der Problemzerlegung und Ergebnis-Aggregation wie z.B. bei einigen Life-Science Applikationen o Beispiele: In dieser Weise sind Applikationen der folgenden ca. 60 Partner mit LSF integriert worden http://www.platform.com/alliances/listing/swvendors.asp o Produzent der Komponente (des Systems; Projektbeteiligte): Platform Computing Corp., Toronto Die Komponente (das System) wird zurzeit eingesetzt von: Mehr als 1600 Kunden weltweit: HPC Computing (viele der Super-Computer TOP500 Liste) Science & Government: CERN, DoD, DoE, TACC, MPI/GWDG, … Industrie: EDA, MDA, Pharma / Life-Science, Finance, ERP/CRM, Automotive & Aerospace… Mehr unter http://www.platform.com/customers/ Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Systeme Globus Toolkit 2+3. Platform stellt „debuggte“ Globus Toolkits zur Verfügung. CSF für Globus. Über CSF auch mit SGE und PBS und anderen Direkte Integration wird für NQS beispielhaft mitgeliefert. FlexLM für Applikations-Lizenz-Management AVAKI Data-Grid Architekturen und Betriebssysteme Alle HPC Architekturen (NEC-SX & TX, IBM SPx & Regatta & z-&p-Series, HPSC&SuperDome, SGI Origin & Altix, SUN, alle Linux Cluster backbones…) Alle gängigen Betriebssysteme, auch in heterogenen Clustern (alle industriellen UNIXes, Linux’e, MAC-OS+X, MS-Windows 2003, XP, 2000, NT, 98) Spezielle Environments: AFS, DFS, DCE, TRIX, .. Mit welchen Systemen gibt es keine reibungslose Kooperation, Nicht bekannt Welche anderen Komponenten sind für den Einsatz notwendig? Keine Worauf basieren diese Aussagen? LSF Dokumentation Bedeutung der Komponente (des Systems) im D-Grid: Gundsätzlich sollte D-GRID den optionalen Einsatz von LSF als lokalem Workload Management System, als RMS, vorsehen und unterstützen. Vorschlag zur D-GRID Realisierung Version 1.0 LSF bietet mit seinen GRID-Fähigkeiten die Option, ausgewählte Resource Provider für das D-GRID in Teil-GRIDs zusammenzufassen. Diese Teil-GRIDs stellen durchsatzstark und in Industriequalität Ressourcen zum verteilten Zugriff bereit. Die Einbindung in ein bundesweites D-GRID würde über GLOBUS und CSF erfolgen. Vorteile für das D-GRID Projekt entstehen durch die unmittelbare Verfügbarkeit dieser Lösung, die somit eine produktive Ausgangsbasis für weitere Entwicklungen und Forschung darstellt. Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Integration mit UNICORE ist noch nicht erfolgt. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: 1. Direkte Integration UNICORE mit LSF als RMS: wurde im UNICORE Verein besprochen und steht zur Realisierung an. 2. Kooperation UNICORE mit GLOBUS/CSF/LSF-MultiCluster-GRID. Durch das GRIP Projekt wurde die Kooperation GLOBUS mit UNICORE bereits sichergestellt. Also entsteht hier der Bedarf, die erweiterten CSF Funktionen wie „Load-Balancing Across Sites“, mit UNICORE abzustimmen = Neues Teilprojekt im D-GRID Rahmen. Erarbeitet von: Bernhard Schott Platform Computing GmbH Direct Fax Mobile Email: Web: +49 (0) 69 348 123 35 +49 (0) 69 348 123 34 +49 (0) 171 6915 405 [email protected] <http://www.platform.com/> 2.6 Platform Community Scheduler Name der Komponente (des Systems, des Projektes): Community Scheduler Framework (CSF) GLOBUS Funktion der Komponente (des Systems; Ziel des Projektes): Das Community Scheduler Framework (CSF) ist ein Set von Grid Services, implementiert auf Basis des Globus Toolkit Version 3.x (www.globus.org), welcher eine Umgebung für die Entwicklung von Metaschedulern darstellt. Ein Metascheduler bietet Workload Scheduling zwischen mehreren, möglicherweise heterogenen, Workload Management Systems, wie zum Beispiel Sun Grid Engine, LSF, oder PBS. Ein White Paper, welches die Implementierungs-Details der Grid Services bschreibt, ist erhältlich unter http://www.platform.com/resources/whitepapers (Registration required). Darüber hinaus ist CSF gedacht als Referenz-Implementierung der durch das GGF (www.ggf.org) definierten und sich entwickelnden Grid Standards. Ein aktuelles Beispiel: der „Reservation Factory Service“ bietet ein "WS-Agreement" Interface. Indem eine Open Source Referenz-Implementierung dieser Standards vorliegt, wird der Einsatz und die Adaption durch Organisationen und Anwenderfirmen erleichtert. CSF ist implementiert in Java, im Rahmen des Globus Toolkit 3 Container Environment, und bietet ein Plug-In Framework zur Implementierung von Scheduling Algorithmen. Aktuell unterstützt wird: Submit von Jobs vermittels Grid Service „RM Adapter“ in LSF Erzeugung von Advanced Reservations durch den RM Adapter Submit von Jobs an den Globus GRAM, welcher viele verschiedene Resource Managers unterstützt, so zum Beispiel SGE and PBS. Produzent der Komponente (des Systems; Projektbeteiligte): CSF ist eine Open Source Contribution von Platform Computing. Projektbeteiligte, siehe www.ggf.org & www.globus.org Die Komponente (das System) wird zurzeit eingesetzt von: TACC at U Texas (www.tacc.utexas.edu). Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Globus Toolkit Version 3.x (www.globus.org) Der CSF Metascheduler bietet Workload Scheduling zwischen mehreren, möglicherweise heterogenen, Workload Management Systems, wie zum Beispiel Sun Grid Engine, LSF, oder PBS. Mit welchen Systemen gibt es keine reibungslose Kooperation, unbekannt Welche anderen Komponenten sind für den Einsatz notwendig? Globus Toolkit version 3.x (www.globus.org) Worauf basieren diese Aussagen? www.ggf.org & www.globus.org , Ein White Paper, welches die Implementierungs-Details der Grid Services beschreibt, ist erhältlich unter http://www.platform.com/resources/whitepapers (Registration required). Bedeutung der Komponente (des Systems) im D-Grid; Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ... Im Rahmen der GLOBUS Nutzung ist CSF ein massiver Vorteil für D-GRID. Gerade für die terminkritische Erst-Implementierung bietet sich zunächst die Übernahme des Metaschedulers an. Durch den Einsatz des CSF Metaschedulers kann die zentrale GRID-Funktionalität WorkloadScheduling im heterogenen Umfeld den Anwendern schon in D-GRID 1.0 zur Verfügung stehen. Ein gewisser Forschungsaufwand kann für eine Integration oder Service-Koordination mit UNICORE vorgesehen werden, soweit im GRIP Projekt noch nicht erfolgt. Aufgrund des transparenten modularen Aufbaus von CSF und dem guten Zugriff auf Entwickler-Ressourcen ist diese Aufgabe mit begrenztem Aufwand und geringem Risiko einzuschätzen. Ein Einsatz der Komponente (des Systems) sollte nicht eingesetzt werden, da ... n/a Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Einige aktuelle Themen, an denen gearbeitet wird, sind: die Integration mit Data Management Systemen zwecks Staging von Compute Job relevanten Daten, Neue Scheduling Algorithmen (Inklusive Algorithmen für das Data Aware Scheduling) weitere RM Adapter erweiterte Client Side Tools Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Laufende CSF Aktivitäten umfassen eine Serie von "Developer Meetings". Das erste hat bereits stattgefunden an der TACC / Universität von Texas (www.tacc.utexas.edu). Ein Gruppe von Entwicklern hat dort begonnen, Erweiterungen zum CSF zu schreiben, inklusive Scheduling Plug-Ins, neue RM Adapter und Integration mit Portalen (GridPort). Bei Komponenten (Systemen) die nicht eingesetzt werden sollen Welche Teildienste sollten funktionell in das D-Grid übernommen werden; n/a Erarbeitet von: Bernhard Schott Platform Computing GmbH Frankfurt Office Direct +49 (0) 69 348 123 35 Fax +49 (0) 69 348 123 34 Mobile +49 (0) 171 6915 405 Email: [email protected] Web: <http://www.platform.com/> 2.7 Sun Java System Portal Server Name der Komponente (des Systems, des Projektes): Sun Java System Portal Server (Grid Engine Portal) Funktion der Komponente (des Systems; Ziel des Projektes): Das Sun Grid Engine Portal (GEP) basiert auf dem Sun Java System Portal Server. - Integriertes Identity Management o Authentifizierung und fein-granulare Autorisierung für Ressourcen o Flexible Authentifizierungs-Mechanismen einschließlich LDAP, RADIUS, X.509v3 Zertifizierungen, SafeWord Token-Karten und AuthentifizierungsServices für UNIX-Plattformen, o Single-Sign On und föderatives SSO (wichtig, wenn z.B. mehrere lokale GridPortale betrieben werden) nach dem Liberty Standard. o Benutzerprovisionierung und Self-Service - Unterstützung der JSR 168 Spezifikation zur Einbindung von Portlets, die im Rahmen der Initiative entwickelt werden oder schon existieren. - Mandantenfähig - Open Source GEP Servlet zur Einbindung von Grid Services - Sichere Mobility/Roaming Services o VPN on Demand; sicherer Zugriff über Browser (z.B. Internet Kiosk) mittels VPN. Es ist keine zusätzliche Soft- oder Hardware nötig. o Zugang via mobiler Devices (Handheld, Handy, PDA, etc.) ist unterstützt. - Grid Interface - File-Management (upload, download, view) via Mouse-Click - High-Performance Visualisierung der Daten - Integrierte Suchmaschine - Submit von Jobs - Abschicken der Jobs mittels Formulare (kein UNIX Kenntnisse erforderlich) - Dynamische Überprüfung des Job-Status - E-Mail Benachrichtigung nach Beendigung eines Jobs - Daten sharing - Diskussionsforen - Portlets für Webservices und die Einbindung weiterer eScience Community-Anwendungen (Kalender, Mail, Instant Messaging, Content- und Dokumentenmanagement Systeme, News-Channels, Collaboration-Tools) Produzent der Komponente (des Systems; Projektbeteiligte): Sun Microsystems Die Komponente (das System) wird zurzeit eingesetzt von: Ausschnitt aus der Portal Server Referenzliste: - Advocate Health Care, Illinois - USA, 24.500 Mitarbeiter - Air Canada, Montreal – Canada, 38.600 Mitarbeiter - BASF, Ludwigshafen – Deutschland, 90.000 Mitarbeiter - Back Bay Technologies, Massachusetts – USA - Bell South, Atlanta – USA, 90.000 Mitarbeiter - BMW, München – Deutschland - Cutler-Hammer, Pennsylvania – USA - Eurocontrol, Brüssel – Belgien, 2000 Mitarbeiter - Europäische Union - Belgien - General Electric Corporate, Connecticut – USA, weltweites Portal für 300.000 Mitarbeiter - General Motors Corporation (DCI Portal Excellence Award), 192000 Mitarbeiter HPCVL (High Performance Computing Virtual Laboratory) - Kanada JPL/NASA, Kalifornien – USA Mobilkom Austria National Semiconductor, Kalifornien – USA, 5000 Mitarbeiter Pepperdine University Poznan Supercomputing and Networking Center - Polen PSA Peugeot Citroen, Paris – Frankreich, 120000 Mitarbeiter Shanxi Mobile, Hongkong Sherwin-Williams, Ohio – USA Siemens A&D, Erlangen – Deutschland State of New Jersey, New Jersey – USA, 3400 Mitarbeiter Sun Microsystems, Kalifornien – USA, 39000 Mitarbeiter T-Mobile, Bonn - Deutschland Textron, Inc., Rhode-Island – USA Universität Ulm - Deutschland U.S. Army Accessions Command, Kentucky – USA U.S. Department of Defense - USA Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Mit der Sun Grid Engine oder ähnlichen Lösung mittels open-source servlet oder WebServices. Mit welchen Systemen gibt es keine reibungslose Kooperation, Nicht bekannt. Die Anbindung wird bei Bedarf systemspezifisch analysiert. Welche anderen Komponenten sind für den Einsatz notwendig? Web – oder Application Server Worauf basieren diese Aussagen? Technisches Requirement. Bedeutung der Komponente (des Systems) im D-Grid: Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ... Unterstützung föderativer Authentifizierung und Autorisierung. Einbindung der D-Grid Services in ein Portal ist eine Anforderung aus der Benutzerschaft. Einbindung weiterer Community Services, Roaming/Mobility/Collaboration/Content Management/..., via Portal. Ein Einsatz der Komponente (des Systems) sollte nicht eingesetzt werden, da ... Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Web Service Ressource Framework ist z.Zt. noch nicht implementiert. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Ist bei Sun in der Planung. Bei Komponenten (Systemen) die nicht eingesetzt werden sollen Welche Teildienste sollten funktionell in das D-Grid übernommen werden; Erarbeitet von: Dr. Wilfried Stüttgen, [email protected] 2.8 Sun Grid Engine Name der Komponente (des Systems, des Projektes): Sun Grid Engine Funktion der Komponente (des Systems; Ziel des Projektes): Distributed Management Produkt für Rechen-Ressourcen (Campus Grid) - Dynamisches Ressource-Balancing - Policy-basierende Ressourcen Zuweisung - Flexible, hierarchische Policies für die Job-Ausführung - Transfer Queues zum Versenden von Jobs an externe Grids - Management von parallelen Anwendungen - MPI und PVM - Fehler tolerant - Checkpointing Funktionalität - OpenSSL basierendes Sicherheits Framework - Standard API – DRMAA - Unterstützung externer Datenbanken (Oracle, MySQL, ...) zur Speicherung und Auswertung von Reporting/Accounting Informationen - Heterogener Plattform-Support - Eingebunden in das Sun Grid Engine Portal (siehe Bestandsaufnahme Sun Grid Engine Portal) Produzent der Komponente (des Systems; Projektbeteiligte): Sun Microsystems Die Komponente (das System) wird zurzeit eingesetzt von: Beispiele sind: - Sun Center of Excellence for CFD, RWTH Aachen - ICENI, Imperial College e-Science Networked Infrastructure, London - GRIDS, Grid Computing & Distributed Systems Lab, Melbourne - Delaware Biotechnology Institute, Delaware - EZ-Grid, Sun Center of Excellence for Grid Computing, Houston - White Rose Grid, Universities of Leads, Sheffield, York, UK - NCSV, Nanyang Center for Supercomp.& Visualization, Singapore - EPCC Edinburgh Sun Data & Compute Grid Project - HPCVL (High Performance Computing Virtual Laboratory) Canada, Secure innovative HPC Portal/Grid environment - GridLab European Project for Grid Application Infrastructure - myGrid Infrastructure for an e-Biologist Workbench, Manchester - Sun Center of Excellence for BioInformatics, Ohio Supercomputing Center Ohio - AIST Advanced Industrial Science & Technology Institute, Tokyo - PROGRESS, Poznan Supercomputing and Networking Center - University of Notre Dame - Ford Motor Company - Motorola - Synopsis - U.v.m. Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Globus Toolkit 2 und 3 Alle DRMAA kompatible Systeme Mit welchen Systemen gibt es keine reibungslose Kooperation, Nicht bekannt. Sun Grid Engine ist kompliant zu Grid Engine Open Source Project. Welche anderen Komponenten sind für den Einsatz notwendig? RDBMS für Reporting. Worauf basieren diese Aussagen? Entfällt. Bedeutung der Komponente (des Systems) im D-Grid; Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ... Langjähriges etabliertes kommerzielles Produkt (Sun N1 Grid Engine Enterprise Edition) für Grid Computing mit entsprechendem Support zur Einhaltung von SLA und QoS. (Sun Grid Engine steht auch als open source Version zur Verfügung.). Sie wird in vielen globalen Grid Projekten als lokales System mit den entsprechenden Schnittstellen für z.B. Globus eingesetzt. Ein Einsatz der Komponente (des Systems) sollte nicht eingesetzt werden, da ... Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: ‚Globale’ Mechanismen, ist allerdings auch nicht primäre Einsatzrichtung des Produktes. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Sun in Zusammenarbeit mit Kunden aus dem Forschungs-Umfeld. Bei Komponenten (Systemen) die nicht eingesetzt werden sollen Welche Teildienste sollten funktionell in das D-Grid übernommen werden; Erarbeitet von: Dr. Wilfried Stüttgen, Sun Microsystems GmbH 2.9 GridSphere Name der Komponente (des Systems, des Projektes): Gridsphere Portal Framework, GridLab Funktion der Komponente (des Systems; Ziel des Projektes): Bereitstellung einer einheitlichen, webbasierten, industriestandbasierenden Benutzeroberfläche für Endnutzer und Administratoren. Das Projekt soll es Wissenschaftlern und Forschern ermöglichen einen einfachen Zugriff auf GridServices und Ressourcen zu erhalten. Dies soll einfach bedienbar, unabhängig vom Betriebssystem und Aufenhaltsorts und minimale Anforderungen an den Rechner des Anwenders sein. Produzent der Komponente (des Systems; Projektbeteiligte): EU Projekt GridLab; AEI Golm Die Komponente (das System) wird zurzeit eingesetzt von: AEI Golm, San Diego Supercomputing Center (GEOScience Network), Canadian NRC Grid Infrastructure Project, Australian Virtual Observatory Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Da das Portalframework eine Mittelschicht zwischen den (Grid)Services und dem Endnutzer/Administrator ist kooperiert es durch seine Erweiterbarkeit prinzipell mit allen Komponenten. Das Framework ist läuft zusammen mit dem CACTUS Toolkit und GLOBUS. Mit welchen Systemen gibt es keine reibungslose Kooperation, Über andere System als CACTUS und GLOBUS kann keine Aussage getroffen werden. Welche anderen Komponenten sind für den Einsatz notwendig? Das Portalframework basiert auf Java und ist somit auf allen Systemen verfügbar auf denen eine entsprechende Java Virtual Machine installiert ist. Weiterhin benötigt es einen Jakarta Tomcat Servlet Container. Dieser ist Open Source und frei verfügbar. Worauf basieren diese Aussagen? Diese Aussagen basieren auf Erfahrungen/Tests und der Projektdokumentation. Bedeutung der Komponente (des Systems) im D-Grid; Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ... Das Gridsphere Framework stellt eine webbasierte, open source Portallösung zur Verfügung. D-Grid sollte einen webbasierten Zugriff auf Ressourcen und Informationen bereitstellen weil dies zu einer hohen Akzeptanz bei Forschern und Wissenschaftlern führt. Es sind keine externe Programme zu installieren die eventuell spezielle Schreibrechte benötigen und nur von Administratoren bereitgestellt werden können. Die einzig benötigte Komponente die der Nutzer braucht um Zugriff auf Ressourcen zu erhalten ist ein normaler Webbrowser der seit einigen Jahren zur Grundausstattung jedes Computers gehört. Weiterhin kann der Nutzer so unabhänging von seinem Arbeitscomputer (z.B. Zugangssysteme auf Konferenzen, andere Einrichtungen, Internet Cafe) auf alle Informationen/Programme schnell und problemlos zugreifen. Erste Anpassungen des Gridsphere Frameworks an Besonderheiten einer Gridumgebung sind bereits vorhanden, diese weisen aber in mehreren Punkten noch deutlichen Verbesserungsbedarf (inbesondere Anpassungen an andere Applikationen, Aufgabenstellungen) auf. Bereits in dieser Phase zeigte sich aber die Eignung als schneller und komfortabler Zugriff auf im Grid bereitgestellte Services. Auch Administratoren profitierten von einem einheitlichen Webinterface, da sie alle von ihrer Einrichtung bereitgestellten Services nun von einer Oberfläche aus konfigurieren/verwalten können. Alle diese Punkte sind nicht spezifisch einer Community zuzuordnen, das gesamte D-Grid und alle Nutzergruppen können von dieser Technologie profitieren. Ein Einsatz der Komponente (des Systems) sollte nicht eingesetzt werden, da ... Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Endnutzer: Das Benutzerinterface der „Cactus und GridPortlets“ ist zur Zeit ohne zusätzliches Wissen über Gridcomuting nicht intuitiv genug um Wissenschaftlern ohne diesen Hintergrund einen einfachen Zugang zu Ressourcen zu geben. Administration: Die Integration in andere (Servlet)Umgebungen als Jakarta Tomcat ist nicht gegeben. Mittelfristiger Entwicklungsbedarf besteht in den Bereichen: - Authentifikation gegenüber verschiedenen Identitysystemen - Sicherheitsmodell um fein garnulierte Zugriffsrechte zu ermöglichen - Unterstützung von Workflow Jobs/anderen Jobschedulern - Entfernte Visualisierung via Webinterface um (Zwischen)ergebnisse darzustellen - Support für Remote Portlets (WSRP) um Portlets lokal bereitzustellen die in anderen Einrichtungen erstellt wurden oder um mit Services installierte Portlets zu nutzen - Entwicklung von „Grid-Ready“ visuellen Komponenten um eine schnellere und einfachere Anbindung von Applikationen zu gewährleisten - Benutzerinterface (Unterstützung JSF, Struts) - Anpassung der „Cactus und GridPortlets“ an JSR 168 (http://www.jcp.org/en/jsr/detail?id=168) Standard. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Meines Wissens arbeitet im Augenblick niemand an den oben genannten Schwachstellen. Bei Komponenten (Systemen) die nicht eingesetzt werden sollen Welche Teildienste sollten funktionell in das D-Grid übernommen werden: Das gesamte System sollte übernommen werden. Erarbeitet von: Oliver Wehrens ([email protected]) 2.10 Resource Broker Name der Komponente (des Systems, des Projektes): Resource Broker zur Optimierung des Durchsatzes von Benutzeraufträgen Funktion der Komponente (des Systems; Ziel des Projektes): Entwicklung eines Resource Brokers, der ausgehend von den verfügbaren und geeigneten Ressourcen einerseits und den neuen und noch nicht begonnenen Aufträgen andererseits eine optimale Belegung der Gridressourcen unter Einhaltung von vorgegebenen Restriktionen durchführt. Dabei soll eine globale Mehrzieloptimierung (insbesondere Kosten, Durchsatz, Fertigstellungszeit etc. ) durchgeführt werden. Eine global optimierende Belegungsplanung ist auch immer dann notwendig, wenn aufgrund von Ressourcenausfall oder dem Hinzukommen neuer Ressourcen eine Neuplanung des gesamten Auftragsbestands nötig wird. Da die Verfügbarkeit der Ressourcen im Grid mit wachsendem Einsatz in steigendem Maße dynamisch sein wird, werden solche Neuplanungssituationen immer häufiger auftreten. Dies stellt eine Erweiterung zu den bisher existierenden Resource Brokern dar, die im wesentlichen die verfügbaren Ressourcen ermitteln, die günstigste aussuchen und dem Auftrag zuteilen. Eine globale Optimierung findet nicht statt. Produzent der Komponente (des Systems; Projektbeteiligte): Ein Resource Broker mit dem oben beschriebenen, erweiterten Funktionsumfang könnte am Institut für Angewandte Informatik des Forschungszentrums Karlsruhe ausgehend von unseren Erfahrungen und Werkzeugen zur globalen Mehrzieloptimierung entwickelt werden. Die Komponente (das System) wird zurzeit eingesetzt von: Konventionelle Resource Broker werden zur Zeit unter anderem eingesetzt von: UNICORE Condor-G Nimrod/G European DataGrid Avaki Data Grid (ehem. Legion) Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Mit welchen Systemen gibt es keine reibungslose Kooperation, Welche anderen Komponenten sind für den Einsatz notwendig? Worauf basieren diese Aussagen? Der erweiterte Resource Broker ersetzt die bisherigen unter Ausnutzung der vorhandenen Schnittstellen, die vereinheitlicht (siehe auch „Einheitliche Programmierschnittstelle für Grid Middleware“) und eventuell erweitert werden müssen. Bedeutung der Komponente (des Systems) im D-Grid; Die Komponente (das System) sollte im D-Grid eingesetzt und mittelfristig entwickelt werden, da nur eine global optimierende Ressourcenzuteilung einen hohen Ausnutzungsgrad der vorhandenen Gridressourcen erreichen kann. Ein weiterer wichtiger Vorteil globaler Ressourcenoptimierung liegt darin, dass die divergierenden Anforderungen von verschiedenen Benutzern einerseits und konkurrierenden Anbietern andererseits möglichst weitgehend erfüllt werden. Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Einen Schritt in Richtung der Zielvorstellung einer globalen Optimierung geht z.B. der Resource Broker von Nimrod/G. Er enthält konventionelle Optimierungsalgorithmen für Budget-, Zeit- und Budget/Zeit-Optimierungen, die statisch alle zeitlich geeigneten Ressourcen ermitteln und davon die preiswerteste auswählen. Eine gesamtheitliche Betrachtung bereits geplanter und noch nicht begonnener und aller zu planenden Aufträge erfolgt nicht. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Arbeiten in Richtung Workflow-Interpretation, Scheduling sowie die optimierte Einplanung einzelner Aufträge erfolgen im Rahmen von UNICORE. Darauf aufbauend würde die hier vorgestellte Resource Broker Erweiterung eine globale Optimierung und damit eine Ausnutzung des gesamten Optimierungspotentials ermöglichen. Erarbeitet von: Wolfgang Süß, Wilfried Jakob, Karl-Uwe Stucky Forschungszentrum Karlsruhe, Institut für Angewandte Informatik 2.11 Condor Name der Komponente (des Systems, des Projektes): Condor Funktion der Komponente (des Systems; Ziel des Projektes): Condor ist ein Resource Management- und Scheduling-System für das High Throughput Computing durch Ausnutzen brachliegender Rechenzeit auf Workstations innerhalb einer Organisation. Produzent der Komponente (des Systems; Projektbeteiligte): Condor wird seit 1988 von der University of Wisconsin entwickelt. Obwohl Condor seit etwa einem Jahr unter einer BSD-ähnlichen Lizenz frei erhältlich ist, ist der Source-Code bisher noch nicht verfügbar. Eine offene, verteilte Entwicklung im Sinne von Open Source fand bisher nicht statt. Homepage: http://www.cs.wisc.edu/condor/ Die Komponente (das System) wird zurzeit eingesetzt von: Evaluation an der Uni Karlsruhe und Uni Jena; hier bisher kein Produktivbetrieb; ist jedoch Bestandteil verschiedener Grid-Projekte: – NMI: http://www.nsf-middleware.org/documentation/NMI-R4/0/CondorG/ – GriPhyN: http://www.griphyn.org bzw. Virtual Data Toolkit (http://www.lscgroup.phys.uwm.edu/vdt/) – Einsatz im Rahmen von TeraGrid: http://www.teragrid.org/userinfo/guide_jobs_condorg.html Einbettung der Komponente (des Systems, des Projektes): Condor ist auf vielen Plattformen lauffähig: MacOS X, Tru64 Unix, HP-UX, Irix, Linux, Solaris, Windows. Allerdings gibt es diverse Einschränkungen hinsichtlich der Betriebssystem- und Library-Versionen (s.u.). Seit den ersten Anfängen von Globus existiert auch eine Version von Condor, die die GlobusSchnittstellen verwendet, um Jobs über das Grid starten zu können bzw. aus dem Grid Jobs entgegennehmen zu können (CondorG: http://www.cs.wisc.edu/condor/condorg). Erwähnenswert ist, dass es über den sog. Glide-In Mechanismus möglich ist, einen (lokalen) Condor-Pool auf externe Grid-Ressourcen auszudehnen, indem dort zunächst automatisch Condor-Binaries installiert werden (glide-in), die dann Kontakt zum lokalen CondorMasterserver aufnehmen. Dadurch kann temporär ein virtueller, vergrößerter Pool erzeugt werden. Die Evaluation an der Uni Jena hat gezeigt, dass Condor relativ empfindlich gegenüber den verwendeten Betriebssystem- und Standardbibliothek-Versionen ist. Für einen reibungslosen Betrieb ist es notwendig, seine Betriebsumgebung exakt auf die verwendete Condor-Version abzustimmen. Das Selbst-Compilieren der Condor-Sourcen gestaltet sich nach wie vor sehr schwierig, auch wenn es mittlerweile möglich ist, den Source-Code zu erhalten (die Uni Karlsruhe bekam ihn auf Nachfrage). Bedeutung der Komponente (des Systems) im D-Grid: Condor könnte seinen Platz im D-Grid finden als lokaler Scheduler, der ungenutzte Kapazitäten von PC-Pools u.ä. für das D-Grid zur Verfügung stellt. Stärken sind u.a. – Aufspüren unterbelasteter Rechner, relativ mächtiges Matchmaking, um auch in heterogenen Rechnerlandschaften (Workstation-Zoo) den geeignetsten Rechner für einen gegebenen Job zu finden, – automatisches, transparentes Checkpointing, – automatische Prozessmigration. – Für die geplante Startversion des D-Grid kann Condor helfen, schnell zu ersten Lösungen für Anwendungen aus dem Bereich des High-Throughput-Computing zu kommen. Die auf jeden Fall noch vorhandenen Schwachstellen (s.u.) könnten dann in ersten Probebetrieben genauer bestimmt und in den Folgejahren beseitigt werden. Insbesondere besteht noch Untersuchungsbedarf, ob und in wie weit sich Condor (bzw. CondorG) auch als globaler Scheduler bzw. Request Broker für eine verteilte Infrastruktur eignet, da konzeptuell stark vom Begriff des lokalen Pools ausgegangen wird. Andererseits sind aus der Condor-Entwicklung wesentliche Features in den Globus Resource Manager GRAM 1.5 eingeflossen (http://www.globus.org/toolkit/contributors.html). Welche Schwachstellen hat die Komponente (das System) zurzeit: Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: – Fehlende Flexibilität/Portabilität. Das Condor-Team arbeitet schon seit einer Weile an einem Source-Release, bisher ohne Ergebnisse. – Die Unterstützung für Parallelrechnersysteme (SMP, MPP, Cluster) ist im Vergleich zu hieraus spezialisierten Schedulern (LSF, SGE u.a.) relativ dünn geraten, so dass hier von einem Einsatz noch abzuraten ist. In Bezug auf diese Funktionalität sind momentan keine nennenswerten Entwickelungsaktivitäten zu erkennen. – Netzwerkstruktur: Eine Folge aus dem Condor zu Grunde liegenden Workstation-PoolModell ist, dass Condor keine Unterstützung für Multihomed Hosts bietet, sondern überall durchgängiges IP-Routing erfordert. Hier kann es in Zusammenhang mit komplexen Netzwerktopologien (also nicht alles an offiziellen IP-Adressen oder nicht alles in einem einzigen VPN) zu Problemen kommen. Dies ist eine typische P2P-Problematik. Weitere Lösungsansätze neben dem Einsatz von VPNs werden z.B. in http://www.cs.wisc.edu/condor/doc/CCGRID2003.pdf vorgeschlagen. Welche Teildienste sollten funktionell in das D-Grid übernommen werden: – Aufspüren unterbelasteter PCs/Workstations und deren Nutzbarmachung für das D-Grid, – Transparentes Checkpointing und Migration (innerhalb eines Pools), – Matchmaking zur Ressourcen-Lokalisierung. Erarbeitet von: Dietmar Fey, FSU Jena <[email protected]> Rudolf Lohner, RZ Uni Karlsruhe <[email protected]> Christian Kauhaus, FSU Jena <[email protected]> 2.12 AVAKI Name der Komponente (des Systems, des Projektes): AVAKI Data Grid 4.0 Funktion der Komponente (des Systems; Ziel des Projektes): AVAKI Data Grid organisiert die Datenhaltung in verteilten Umgebungen. Dabei können Anwender wie Applikationen auf Daten zugreifen, als ob diese lokal wären. Erreicht wird dies durch einen „unified data catalog“ in Verbindung mit progressivem Caching. AVAKI Data Grid ist organisiert in drei Layern: Access o Zugriff auf Daten „As if Local“, o „unified data catalog“, o ODBC, JDBC, o Web Services/ SOAP, o file read, o JSP/Tag library Integration o Datenformat Konversion, o Relational XML/XSLT, o Automatisierung von Data-Flows zwecks Propagation von Updates durch eine ausgedehnte Organisation. o Sicherstellung der Cache-Konsistenz Provisioning o Integration der Datenquellen: o NAS, SAN, o Application Data, o Oracle, DB2, … o DWH-solutions Die Fähigkeit, Daten passend zur jeweiligen Applikation / User im jeweiligen Zielformat darzustellen, ist innovativ. Dies erlaubt die GRID-Integration verschiedenster Legacy und Commercial Applications ohne diese verändern zu müssen. Gerade auch die Aggregation von Daten aus verschiednen Quellen und deren einheitliche Darstellung erlaubt neue GRID basierte Dienste und Dienstleistungen. Die Organisation des Caching stellt sicher, dass Daten nur einmal im System „valid“ sind – alles andere sind transiente Kopien ohne Persistenz. Detaillierte Informationen sind bitte der Webseite: www.avaki.com zu entnehmen. Produzent der Komponente (des Systems; Projektbeteiligte): AVAKI Corporation, www.avaki.com Die Komponente (das System) wird zurzeit eingesetzt von: The North Carolina Bioinformatics Grid (NC BioGrid) (Weitere Informationen von AVAKI angefordert) Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? GRID: GLOBUS, GLOBUS-CSF, LSF-MultiCluster-Grid RMS: LSF, SGE, … Datenbanken: Oracle, DB2, … Storage: NAS, SAN, NFS, … Mit welchen Systemen gibt es keine reibungslose Kooperation, unbekannt Welche anderen Komponenten sind für den Einsatz notwendig? keine Worauf basieren diese Aussagen? AVAKI Dokumentation Bedeutung der Komponente (des Systems) im D-Grid: Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ... AVAKI bietet eine sehr fortgeschrittene Datenintegration für GRID-Umgebungen die auch einem automatisierten FTP weit überlegen ist. Da AVAKI auch Integrationsmöglichkeiten mit verschiedenen Applikationstypen bereitstellt, wäre eine solche Komponente im D-GRID sehr willkommen und erlaubt neue, innovative Anwendungen. Die detaillierte Caching-Steuerung erlaubt die feingranulare Anpassung an die GRIDTopologie, die Lokationen der Daten und die Verbindungsbandbreiten. Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Es ist zu prüfen, inwieweit das Thema AVAKI besser bei einem anderen Arbeitskreis angebracht ist oder in AK2 verfolgt werden sollte Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Erarbeitet von: Bernhard Schott Platform Computing GmbH Direct Fax Mobile Email: Web: +49 (0) 69 348 123 35 +49 (0) 69 348 123 34 +49 (0) 171 6915 405 [email protected] <http://www.platform.com/> 2.13 NSF Middleware Initiative Name der Komponente (des Systems, des Projektes): NSF Middleware Initiative Funktion der Komponente (des Systems; Ziel des Projektes): Die NSF Middleware Initiative (NMI) besteht aus einer Sammlung einzelner SoftwareSysteme, die in einem Paket mit Dokumentation angeboten werden. Die Initiative ist Bestandteil des Internet2 Projektes in den USA, das im Jahr 1997 begonnen hat. Es handelt sich bei der NMI-Software um keine eigenständige und in sich kohärente Gesamtlösung. Stattdessen ist es eine Sammlung von bekannten und bestehenden SoftwarePaketen, die als Komponenten für die NMI ausgewählt wurden. Das NMI bietet diese Pakete als Bundle mit einer angepassten Dokumentation für die separate Installation der Einzelkomponenten an. Ein Großteil der betrachteten Software sind die schon bekannten Standard-Pakete: Globus Als übergreifende Middleware zwischen den beteiligten Grid-Partnern. (Eigene Bestandsaufnahme innerhalb des AK2.) Condor-G Als lokale Cluster-Management-Software mit Anbindung an das Grid. (Eigene Bestandsaufnahme innerhalb des AK2.) Network Weather Service (NWS) für Bandbreiten-Monitoring und statistische Prognose der Netzwerk-Eigenschaften zwischen den Grid-Knoten. Wäre Gegenstand von AK4. GSI-OpenSSH Anpassung, um OpenSSH auch mit GSI zu nutzen. Ist ein von vielen Zusatztools für Globus, für die keine separate Betrachtung erfolgt. KX.509/KCA Als Brücke zwischen Kerberos und X.509 PKI. Sollte nur dann näher betrachtet werden, wenn von Seiten der Resource-Besitzer Kerberos eingesetzt wird. MPICH-G2 Das bekannte MPICH erweitert für heterogene Plattform-Kommunikation, in der das Nachrichtenformat zwischen einzelnen Knoten über unterschiedliche Protokolle verlaufen kann. Dies kann genutzt werden, um MPI effizient innerhalb eines Clusters und gleichzeitig zwischen Grid-Einrichtungen zu nutzen. Ist möglicher Teil einer Programmierschnittstelle (ähnlich zu PAX-MPI vom HLRS). Darüberhinaus existieren einige Tools, für die Verwaltung der Grid-Software: My Proxy Ein Archiv für die eigenen Zertifikate für die Proxies auf entfernten Systemen. Für den Einsatz eines solchen Tools in einer Grid-Infrastruktur, ist erforderlich, dass die übrigen Software-Komponenten, diese Schnittstelle verwenden. Uns ist zurzeit keine breite Verwendung bekannt. Grid Packaging Tools Kleinere Tools um Daten und Source-Code mit Abhängigkeiten beschreiben zu können. Aus der Dokumentation geht es nicht hervor, ob es sich um eine reine Installationshilfe oder um ein Tool für die Grid-Verwendung handelt. Im letzteren Fall könnte es ein Teil einer Programmierschnittstelle sein. Gridconfig Tools Python-Skripte um Konfigurationsdateien für die Grid-Komponenten des NMI Paketes aus einer mySQL Datenbank zu erzeugen. GridSolve Programmierschnittstelle für Programme, die dynamisch im Netzwerk nach freien Ressourcen suchen und diese nutzen. Hierbei handelt es sich um eine Erweiterung des NetSolve-Paketes. Es basiert auf Globus (verteilt) oder Condor-G (lokal). PyGlobus liefert Zugriff auf Globus über die Python Skriptsprache UberFTP Ein interaktiver GridFtp Client In Ergänzung gibt es einen Satz von Tools and Software, die insbesondere für die Authentifizierung und das Benutzer-Management genutzt werden können. CPM Tool für die vereinfachte Erzeugung von x509 Zertifikaten. Look Perlskript, um regelmäßig Daten aus Suns iPlanet LDAP Server auszulesen und in ein Format zu bringen, damit ein OpenSource Plotting-Tool daraus Web-Bilder machen kann. Hintergrund ist die Web-Anzeige von statischen Daten über die RessourcenAuslastung (weitestgehend Netzwerk-Informationen aus dem NWS). OpenSAML Libraries, um über Java und C++ SAML-Dateien zu erzeugen und auszutauschen. SAML ist ein Standard um Security Attribute von Diensten XML-basiert zu beschreiben und auszutauschen. PERMIS Infrastruktur, um x509 AC Zertifikate auszuwerten und damit Zugang zu Ressourcen auf Basis von Rollenkonzepten bestimmen zu können. Shibboleth Authentifizierungssystem für den Zugriff auf Web-Server, d.h. Web-Inhalte können z.B. auf Benutzerkreise eingeschränkt werden, wobei der lokale Administrator die Zugangsrechte nicht individuell lokal verwalten muss. Es ist zu beachten, dass es hier nicht um Web-Services oder den Login-Zugang zu einem entfernten Rechnersystem geht. Die Verwendung beschränkt sich auf Web-Inhalte für z.B. Online-Kurse, Campus-Bibliotheken oder geschützte Projekt-Bereiche im WWW. WebISO (Web Initial Sign-on) Drei alternative sign-on Systeme für Web-Server. Die genannten Komponenten beziehen sich auf die Version 4 des NMI-Paketes vom 15. Dezember 2003. Dabei fällt auf, dass einzelne Komponenten insbesondere für den Sicherheitsbereich, wie z.B. Shibboleth auf das Jahr 2002 zurückgehen und wenige aktuelle Veränderungen erkennbar sind. Weitergehende Informationen zum NMI finden sich unter http://www.nsf-middleware.org/ Produzent der Komponente (des Systems; Projektbeteiligte): NSF Projekt unter Einbindung mehrerer Forschungseinrichtungen in den USA Die Komponente (das System) wird zurzeit eingesetzt von: University of Alabama at Birmingham, University of Alabama in Huntsville , Georgia State University, University of Florida, Florida State University, University of Michigan, Texas Advanced Computing Center, University of Virginia, University of Southern California Einbettung der Komponente (des Systems, des Projektes): Als Sammlung von bekannten Grid-Lösungen sind die einzelnen Komponenten zu betrachten. Die zentralen Bestandteile mit Globus und Condor werden entsprechend separat in diesem Dokument behandelt. Eine komplette Betrachtung des NMI ist nicht sinnvoll, da die einzelnen Komponenten von sehr unterschiedlichem Umfang, verschiedenen Produzenten und eigenen Zielsetzungen sind. Eine koherente Gesamtsicht ist nicht vorgesehen, sondern die Einzelbestandteile können individuell von den Partnern genutzt werden. Bedeutung der Komponente (des Systems) im D-Grid: Eine Bewertung der gesamten NMI ist schwer möglich und wenig sinnvoll, da es sich um eine Sammlung von Software handelt, die man einzeln bewerten muss. Die wesentlichen Kernkomponenten sind Globus, Condor, die Verwendung von Kerberos und x.509 Zertifikaten. Im Bereich der Sicherheitsstrukturen sind die vorhandenen Programme fast ausschließlich für die Authentifizierung gegenüber Web-Servern ausgerichtet. Damit lässt sich z.B. geschützte Kollaboration im Web durchführen. Im Bereich des Computational Grids finden sich jedoch keine eigenen Lösungen. Durch die Verwendung von Globus und damit GSI ist weiterhin die Nutzung von "normalen" x.509 Zertifikaten notwendig. Eine vollständige Übernahme ist aus den oben genannten Gründen nicht angebracht. Erarbeitet von: Ramin Yahyapour CEI, Universität Dortmund [email protected] 3 Projekte 3.1 GRIP Name der Komponente (des Systems, des Projektes): Grid Interoperability Project (GRIP) Funktion der Komponente (des Systems; Ziel des Projektes): Projekt: Standards (GGF), interoperable Middleware (UNICORE – Globus) und Anwendungen Middleware: Kopplung der Systeme bezüglich Job Submission von UNICORE zu Globus Ressourcen inklusive Job Monitoring und Kontrolle, Datentransfer, Sicherheitsinfrastruktur und Resource Brokering Produzent der Komponente (des Systems; Projektbeteiligte): (alphabetisch) Argonne National Laboratory, Deutscher Wetterdienst, Forschungszentrum Jülich, Fujitsu Laboratory Europe, Intel, University of Manchester, University of Southampton, Warschau University Die Komponente (das System) wird zurzeit eingesetzt von: Projektpartnern, NaReGI Projekt, einige weitere Benutzer Einbettung der Komponente (des Systems, des Projektes): Die entwickelte Middleware realisiert die Kopplung von UNICORE und Globus (sowohl Globus Toolkit 2.x, als auch 3.0), die Nutzung der Middleware setzt die Installation eines UNICORE Servers und eines Globus Servers voraus, sowie Teile des Globus Klienten (zur Jobsubmission). Kooperation mit anderen Systemen ist nicht vorgesehen. Diese Aussagen beruhen auf Informationen direkt aus dem Projekt heraus (FZJ hat die Projektleitung). Bedeutung der Komponente (des Systems) im D-Grid: Da sowohl UNICORE als auch Globus mit großer Wahrscheinlichkeit zur Basis des initialen DGrids zählen werden, bietet die in GRIP entwickelte Software die Möglichkeit, Ressourcen zu kombinieren und Erfahrungen mit Interoperabilität zu sammeln. Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Die Schwachstelle des Systems ist ihre Basis: die beiden Grid Systeme UNICORE und Globus sind derzeit aufgrund der Entwicklung von Grids hin zu dienstorientierten Systemen (serviceoriented Grids) und dem Fehlen von verbindlichen Standards steten Änderungen unterworfen. Daher ist die existierende Software möglicherweise schnell obsolet. Allerdings wird Globus 2.x aus Mangel an einem verläßlichen Nachfolger noch länger Verbreitung finden und daher auch der Einsatz der GRIP Software Sinn machen, da eine Kompatibilität mit älteren Versionen von UNICORE auf der Ebene von GRIP noch länger gewährleistet sein wird. Der Globus 3.0 Version der GRIP Software wird allerdings keine Zukunft bescheinigt. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Ein FP6 Projekt mit Beteiligung vieler Partner aus GRIP befindet sich momentan in der Verhandlung mit der Europäischen Union. Dieses Projekt wird sich der Interoperabilität dienstorientierter Grids annehmen. Erarbeitet von: Philipp Wieder, Forschungszentrum Jülich 3.2 GridLab GAT Name der Komponente (des Systems, des Projektes): Einheitliche Programmierschnittstelle für Grid Middleware (s.a. GGF WG SAGA: Simple API for Grid Applications) Funktion der Komponente (des Systems; Ziel des Projektes): Erarbeiten eines einfachen und einheitlichen API’s für verschiedene Grid Middleware Services, die den Anwendungsprogrammierer von der dynamischen Struktur des Grid selbst abstrahieren. Produzent der Komponente (des Systems; Projektbeteiligte): Derzeitige Arbeiten an einer derartigen Schnittstelle werden im Rahmen des Gridlab Projektes durchgeführt (bis Ende 2004). Besonderes Interesse wurde aus der Community Astro- und Teilchenphysik bekundet. Die Komponente (das System) wird zurzeit eingesetzt von: Noch kein Einsatz unter Produktionsbedingungen, erster prototypischer Einsatz von Teiles eines solchen API’s im Testbed des Gridlab Projektes. Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Mit welchen Systemen gibt es keine reibungslose Kooperation, Welche anderen Komponenten sind für den Einsatz notwendig? Worauf basieren diese Aussagen? Das es bisher keinen Produktionseinsatz einer derartigen Schnittstelle gibt, lassen sich keine Systeme nennen, mit denen diese Schnittstelle kooperiert, Erfahrungen mit dem derzeit getesteten Prototypen zeigen jedoch, dass faktisch beliebige Grid Middleware Services anbindbar sind. Dieser Fakt entspricht jedoch auch gleichzeitig dem ursprünglichen Ansatz, eine einheitliche Programmierschnittstelle zu schaffen. Der existierende Prototyp (GAT – Grid Application Toolkit) arbeitet mit Globus Datenservices, verschiedenen Gridlab Services (Resourcebroker, Authentication Service, Replica Service, Monitoring Service) zusammen, erste Arbeiten zu Anbindung des UNICORE Resourcebroker Services werden zurzeit durchgeführt. Bedeutung der Komponente (des Systems) im D-Grid; Die Komponente (das System) sollte im D-Grid eingesetzt und entwickelt werden, da Sie die Erstellung von Grid basierenden Anwendungen vereinfacht und vereinheitlicht. Mit Hilfe einer derartigen einheitlichen Schnittstelle kann der Anwendungsprogrammierer seine Anwendungen ohne Berücksichtigung einer konkreten Grid Struktur bzw. ohne Bezug auf einen bestimmten Grid- Service schreiben. Dies führt zu einer Verbesserung der Nutzung der D-Grid Ressourcen und zu einer Beschleunigung der Amortisation der eingesetzten Mittel. Bei Komponenten (Systemen) die eingesetzt werden sollen Welche Schwachstellen hat die Komponente (das System) zurzeit: Die im derzeitigen Prototyp (GAT) implementierte Schnittstelle (API) bedarf eines grundlegenden Abgleichs mit den Anforderungen anderer Communities, so dass eine Erweiterung und Anpassung erforderlich und zu erwarten ist. Die derzeitige Implementation basiert auf der Programmiersprache ‚C’, weitere Sprachanbindungen (C++, Fortran, Java, Perl, Python …) sind erforderlich um einen möglichst breiten Einsatz zu gewährleisten/ermöglichen. Anbindungen an andere existierende und ggf. an im Rahmen der D-Grid Initiative zu entwickelnde Grid- Services müssen erstellt werden. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Gridlab Projekt Erarbeitet von: Hartmut Kaiser, AEI Golm 3.3 EGEE Name des Projektes: Enabling Grids for E-science in Europe (EGEE) (http://www.eu-egee.org/) kann als Nachfolgeprojekt vom European DataGrid (EDG) (http://www.eu-datagrid.org/) angesehen werden, das auf die Entwicklung von Grid Middleware abzielte, und auf dem das LHC Computing Grid (LCG) (http://cern.ch/lcg/) basiert. Ziel des Projektes: EGEE zielt auf die Integration nationaler, regionaler und themenspezifischer Rechen- und Daten Grids in eine EU-weite e-Science Infrastruktur (Grid) ab. Die Mission von EGEE ist: die Schaffung von produktionsreifen (production-level) Grid-Diensten, die professionelle Überarbeitung (re-engineering) der Grid-Middleware, Verbreitung, Ausbildung und Training. Produzent des Projektes: Im Rahmen des sechsten Rahmenprogramms (FP6) der Europäischen Union umfaßt das EGEE Konsortium, mit CERN als Vertragspartner der EU, 70 führende Institutionen aus 27 Ländern, die in 10 Föderationen organisiert sind. Weitere internationale Partner aus Wissenschaft und Industrie sind angeschlossen. Zur Deutschen Föderation, vertreten durch FZK, gehören DESY, DFN, DKRZ, FhG, FZK und GSI Darmstadt. Der Projekt Start ist für den 1. April 2004 geplant, und es stehen 32M€ für die ersten zwei Jahre eines auf vier Jahre ausgelegten Programmes zur Verfügung. EGEE ist ein EU I3 Projekt, das drei Aktivitätsbereiche umfaßt: Betrieb (Service Activities, SA) Netzwerke (Networking Activities, NA) F&E (Joint Research Activities, JRA) Die Komponenten des Projektes werden eingesetzt von: EGEE zielt auf die ganze europäische Wissenschaftslandschaft ab (e-Science). Folgende Bereiche werden explizit genannt: Teilchenphysik, Bioinformatik, Industrie, Astronomie, Chemie, Erdbeobachtung, Geophysik, Biologie, Nanotechnologie und Klimamodellierung. An der Startversion werden sich die Teilchenphysik und die Bioinformatik beteiligen. Einbettung der Komponenten des Projektes: Die Teilchenphysik soll die Pionierrolle übernehmen, um kurzfristig eine Grid Infrastruktur aufzubauen, auf die andere Wissenschaftsbereiche aufbauen können. Als Middleware wird aller Vorraussicht nach die LCG-2 Software zum Einsatz kommen, die auf Globus Toolkit 2 (http://www.globus.org/) Komponenten und EDG 2 Middleware basiert. Die Kooperation mit anderen Grid Projekten sowie zur Standardisierung mit dem Global Grid Forum (GGF) (http://www.gridforum.org/) wird dabei ausdrücklich hervorgehoben. Bedeutung der Komponenten des Projektes im D-Grid: Die in Europa allgemein akzeptierte GRID Infrastruktur für Experimente der Teilchenphysik ist LCG. Auch wenn sie speziell für den LHC entwickelt wurde, dient LCG auch anderen Experimenten (CDF, D0, BaBar, HERA). Die internationale Einbindung der Experimente der Teilchenphysik macht es erforderlich, die in der Anwendergemeinde akzeptierten Standards zu benutzen. Die Institute der Elementarteilchenphysik in Deutschland haben sich auf LCG als gemeinsame Plattform geeinigt. Auch in der theoretischen Teilchenphysik, insbesondere der Gittereichtheorie, ist ein großer Bedarf an Datentransfer in der Zukunft zu erwarten. Die Gittereichtheoriegruppen werden im International Lattice Data Grid verankert sein, die als sogenanntes Grid-of-Grids die einzelnen Storage Elements und Replica Catalogues der beteiligten Institute verbindet. Welche Schwachstellen haben die Komponenten des Projektes zurzeit: Es gibt einige bekannte Schwachstellen in EDG/LCG, die auch die Produktionsreife von LCG in Frage stellen. Darüber hinaus ist zurzeit noch keine Einigung mit dem amerikanischen LHC Partnern, die generell ungern Ergebnisse aus EU-Projekten anwenden, über die Verwendung von Middleware erzielt worden. Für die Teilchenphysik seien insbesondere das Job und Ressource Management, das Bookkeeping und das Modelling erwähnt. Letzteres ist notwendig, um Ressourcenabschätzungen für die Zukunft auf Grundlage aktueller Erfahrungen zu erlangen. Weiterhin bietet die Globus Grid Security Infrastructure (GSI) zwar Authentifizierungsdienste und SSL-Verschlüsselung der Datenverbindungen an, die Daten selbst liegen jedoch unverschlüsselt vor. Darüber hinaus ist es notwendig Firewalls für die verschiedenen Dienste wie GridFTP zu öffnen, um Datentransfer zu ermöglichen. Ein weiterer wichtiger Punkt ist Portabilität der LCG Software, die zurzeit nur für die Linux Distribution RedHat 7.3 für die Intel ix86 Architektur zur Verfügung gestellt wird. Die automatische Installation über LCFGng beinhaltet diese. Die manuelle Installation der RPMs auf z.B. SuSE Linux Systemen ist zwar möglich, erfordert aber erheblichen zusätzlichen Aufwand. Weitere Betriebs-systeme werden nicht unterstützt. Wünschenswert wäre mindestens Solaris als Serverplattform und weitere Betriebssysteme für die Worker Nodes. EDG/LCG Middleware unterstützt im wesentlichen die Konzepte der Datenprozessierung in der experimentellen Teilchenphysik, bei der in sich abgeschlossene Datenpakete sogenannte Events – unabhängig voneinander (parallel) prozessiert werden. Der Workflow ist der einfachst mögliche, da die Jobs auf einzelne Computing Elemente abgebildet werden können. Andere Ressourcen-intensive Anwendungen, z.B. in der Astrophysik, benötigen hingegen gekoppelte Applikationen, für die Erweiterungen auf der Middleware-Ebene (Integration einer Grid-MPI-Kommunikationsschicht) und im Job- und Resource Mananagement (Resource Reservation, Co-Scheduling) erforderlich wären. Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Ein großer Teil der Aufgaben soll innerhalb der verschiedenen Arbeitsgruppen des LCG Projektes angegangen werden. Zum Teil besitzen die Ergebnisse aber noch keine Produktionsreife und erfordern eventuell eine größere Revision der Konzepte. Die Forderung nach der Unterstützung anderer Linux Distributionen und anderer Betriebssysteme ist wiederholt laut geworden und auch – zumindest verbal - als EGEE Ziel formuliert worden. Erstellt von: D-GRID AK2 Astro- und Teilchenphysik Community Editiert von: Andreas Gellrich , DESY 3.4 Zertifizierung Name der Komponente (des Systems, des Projektes): Zertifizierungsdienst Funktion der Komponente (des Systems): Eine Zertifizierungsdienstleistung ist eine wesentliche Basis für Authentifizierung und Autorisierung in offenen Netzen. Die DFN-PCA (Policy Certification Authority) betreibt eine solche Zertifizierungsdienstleistung seit 1995 für die Verfahren PGP und insbesondere X.509 und hat dafür Policies entwickelt, die unterschiedliche Anforderungen an Sicherheitsniveaus widerspiegeln. Es werden sowohl untergeordnete CAs zertifiziert als auch fortgeschrittene Zertifikate im Sinne des Signaturgesetzes für Endnutzer und –geräte ausgestellt. Zur Unterstützung der Zertifizierungsdienstleistung wird ein Verzeichnisdienst betrieben, über den Zertifikate, Schlüssel und Widerrufslisten bereit gestellt werden. Produzent der Komponente (des Systems): Der Zertifizierungsdienst wird vom DFN-Verein über seine DFN-PCA erbracht (www.dfnpca.de) . Die Komponente (das System) wird zurzeit eingesetzt von: Die Zertifizierungsdienstleistung wird seit Jahren in weiten Teilen des Deutschen Forschungsnetzes, also in Wissenschafts- und Forschungseinrichtungen in Deutschland, genutzt. Ein aktuelles Beispiel: Nach Ablauf der Aktivitäten der Globus-CA im Januar 2004 hat die DFN-PCA für das LRZ München das Ausstellen der entsprechenden Grid-Zertifikate übernommen. Einbettung der Komponente (des Systems, des Projektes): Die Integration der Dienstleistung erfolgt i.W. über das Einbringen von Zertifikaten und Schlüsseln in die entsprechenden Anwendungen. Gleichzeitig muss über die Policies sicher gestellt sein, dass die Zertifizierungsdienstleistung dem erforderlichen Sicherheitsniveau entspricht. Bedeutung der Komponente (des Systems) im D-Grid Es wird im D-Grid in jedem Fall eine Zertifizierungsdienstleistung geben müssen, um Dienste, Systeme und Personen im D-Grid zu identifizieren und authentisieren. Welche Schwachstellen hat die Komponente zurzeit: Um den aktuellen online-Zugriff auf Widerrufslisten zu ermöglichen, sollte das Verfahren OCSP (Online Certificate Status Protocol) bereit gestellt werden. Zusätzliche könnte eine Integration des Root-Zertifikats in die Standard-Browser den Gesamtprozess vereinfachen. Um die Dienstleistung auf das D-Grid abzubilden, muss geprüft werden, inwieweit die vorhandenen Policies den Anforderungen genügen bzw. wo Anpassungen erforderlich wären. Erarbeitet von: Marcus Pattloch, DFN-Verein <[email protected]> 3.5 Zertifizierungsdienst GridKA Name der Komponente (des Systems, des Projektes): Zertifizierungsdienst GridKA Funktion der Komponente (des Systems; Ziel des Projektes): Die Certification Authority (CA), die am FZ Karlsruhe aufgebaut wurde, dient zwei Zwecken. Zum einen der Ausgabe von Zertifikaten an Nutzer aus der HEP Community, zum anderen zur Ausgabe von Zertifikaten an Nutzer und Ressourcen an EDG verwandte Grid Projekte. Vor allem das zweite Kriterium hat dabei entscheidend die Policy Dokumente (CP/CPS) beeinflusst, da sonst die CA nicht in der Gemeinschaft anerkannt worden w"are. Die Komponente (das System) wird zurzeit eingesetzt von: das EU DataGrid Projekt das EU CrossGrid Projekt das LCG Projekt DESY (Hamburg) folgende Hochenergiephysik Experimente: Alice, Atlas, BaBar, CDF, CMS, COMPASS, D0, LHCb. Einbettung der Komponente (des Systems, des Projektes): Mit welchen anderen Systemen kooperiert die Komponente? Mit welchen Systemen gibt es keine reibungslose Kooperation? Welche anderen Komponenten sind für den Einsatz notwendig? Globus Security Infrastructure (X.509) Worauf basieren diese Aussagen? http://grid.fzk.de/ca/gridka-cps.pdf Bedeutung der Komponente (des Systems) in D-Grid: Es ist anzumerken, dass diese CA u.a. deshalb aufgebaut wurde, weil die Policy des DFN nicht im EDG grid Umfeld akzeptiert worden wäre. Da diese CA nun in verschiedenen EU-Grid Projekten (EDG, CrossGrid, EGEE) akzeptiert ist, ist geplant, diese unabhängig vom Einsatz in D-Grid weiterzuführen. Es erscheint daher aus FZK-Sicht machbar und sinnvoll, auch in D-Grid Zertifikate auszustellen, allerdings die arbeit der Registrierung durch den Aufbau von Registration Authorities zu verteilen. Der Aufbau einer hierarchischen Zertifizierungsstruktur erscheint dagegen weniger sinnvoll, da nicht nur säamtliche Zertifikate installiert, sondern auch viele Certificate Revokation Listen aktuell gehalten werden müssten. Zu prüfen bleibt, ob die Policy bzw. die RA Struktur der Jülicher CA kompatibel ist. Welche Schwachstellen hat die Komponente (das System) zurzeit: Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen: Welche Teildienste sollten funktionell in das D-Grid übernommen werden: Erarbeitet von: Marcus Hardt, Ursula Epting, Ariel Garcia. 3.6 Conferencing Name der Komponente (des Systems, des Projektes): Conferencing (collaborative work environment) Funktion der Komponente (des Systems): Mit einem Conferencing-Dienst können Grid-Nutzer (Mehrpunkt) Audio- und Videokonferenzen über das Internet durchführen. Zusätzlich ist das verteilte Bearbeiten von Dokumenten möglich. Produzent der Komponente (des Systems): Im Folgenden werden drei existierende Conferencing-Infrastrukturen beschrieben: DFNVideoConference (www.dfn.de/content/dienstleistungen/dfnvc) ViDeNet - Video Development Initiative (www.vide.net) VRVS - Virtual Room Videoconferencing System (www.vrvs.org) Die Komponente (das System) wird zurzeit eingesetzt von: Der Dienst DFNVideoConference wird im Deutschen Forschungsnetz eingesetzt, mit derzeit mehreren Tausend Konferenzen im Monat. Der Videokonferenzdienst im Wissenschaftsnetz ermöglicht Mehrpunktkonferenzen direkt vom Arbeitsplatz oder von einem Raumsystem unter Nutzung der DFN Multipoint-Control-Unit (MCU). Der Dienst ist international erreichbar. Verwendet wird eine Gatekeeper-Struktur mit einem weltweit abgestimmten Nummernplan (Global Dial Schema) zur Adressierung der Kommunikationspartner. Zusätzlich können ISDN-Teilnehmer in die Konferenz über einen Gateway eingebunden werden. Der Realisierung von verteilten Anwendungen ist möglich und erfolgt über das Protokoll T.120. Es findet eine Unterstützung der Administration durch DFN-Hotline, Schulungen und das Kompetenzzentrum für Videokonferenzdienste (http://vcc.urz.tu-dresden.de/) statt, für Nichtfachleute gibt es eine verständliche Benutzeroberfläche. Grundlage des Dienstes ist der H.323-Standard. ViDeNet bietet Video- und Voice-über-IP Dienste für Wissenschaft und Forschung in den USA. Der Dienst basiert auf H.323. ViDe wurde von Universitäten und Forschungseinrichtungen in den USA gegründet und basiert auf einer offenen, unentgeltlichen Mitgliedschaft von Anwendern und Entwicklern. Mittlerweile ist auch Internet2 aktives Mitglied bei ViDe geworden und nutzt ViDeNet. VRVS ist ein Web-basiertes System für Videokonferenzen und verteiltes Arbeiten in IPNetzen. Entwickelt und eingesetzt wird das System schwerpunktmäßig im Bereich Hochenergie- und Nuklearphysik, eine Ausdehnung auf andere Communities erfolgt seit einiger Zeit. Es werden Tools für verschiedene Plattformen (Mbone, H.323, Quicktime) unterstützt. Basiskonzept sind sogenannte "virtuelle Räume", in denen sich die Konferenzteilnehmer treffen. Einbettung der Komponente (des Systems, des Projektes): Aufgrund seiner Charakeristik als Dienstleistung wird der Conferencing-Dienst nicht direkt als Software-Komponente integriert werden. Vielmehr kann eine Integration z.B. über ein Zugangsportal erfolgen. Bedeutung der Komponente (des Systems) im D-Grid Es wird im D-Grid in jedem Fall einen Conferencing-Dienst geben müssen, um die interaktive Zusammenarbeit zwischen Nutzern des D-Grid zu befördern. Dass Bedarf in typischen GridCommunities besteht, zeigt z.B. die Entwicklung von VRVS. Welche Schwachstellen hat die Komponente zurzeit: Die Steuerung von Konferenzen mit mehr als 6-8 Teilnehmern ist teilweise aufwendig. Die Qualität der Audioströme beeinflusst die Qualität der Gesamtkonferenz i.A. mehr als die Qualität der Videoströme. Insofern muss die Audioqualität weiter verbessert werden. Die parallele Nutzung von Video-/Audiokonferenz und verteilter Bearbeitung von Dokumenten ist zum Teil organisatorisch komplex. Hier müssen vereinfachende integrative Mechanismen weiter entwickelt werden. Erarbeitet von: Marcus Pattloch, DFN-Verein <[email protected]> 3.7 Roaming Name der Komponente (des Systems, des Projektes): Roaming-Dienst Funktion der Komponente (des Systems): Ein leistungsfähiges Netz ist unbestritten eine wesentliche Infrastrukturkomponente zum Aufbau des D-Grid. Der Zugriff auf dieses Netz muss jedoch nicht nur in der jeweiligen Heimateinrichtung möglich sein, sondern auch die Anforderungen reisender Wissenschaftler berücksichtigen. Dies bedeutet insbesondere den transparenten Zugriff auf das Netz und somit das D-Grid von einer beliebigen (Wissenschafts)einrichtung aus, ohne, dass jeweils lokale Anmeldeprozeduren durchzuführen sind. Im Gegenteil muss der Netzzugang von jedem Ort aus auf die selbe Weise und mit den selben Login-Daten erfolgen können. Dabei ist offensichtlich, dass die Kapazität des Netzzugangs der Kapazität beim lokalen Zugang weitgehend entsprechen muss. Daraus folgt, dass z.B. die Einwahl über ein Mobiltelefon keine nennenswerte Alternative darstellt, da die Zugangsbandbreiten nicht im erforderlichen Rahmen liegen. DFNRoaming wird durch eine Nutzerverzeichnisstruktur realisiert und basiert auf dem PortAuthentifizierungsprotokoll IEEE 802.1X. Daneben wird auch die Interoperabilität mit anderen Verfahren wie z.B. VPN oder Web-basierten Ansätzen unterstützt. DFNRoaming greift dabei auf eine AA (Authentication / Authorization) Infrastruktur von RADIUS-Servern zurück. Produzent der Komponente (des Systems): DFN-Verein (www.dfn.de/content/dienstleistungen/dfnroaming) Die Komponente (das System) wird zurzeit eingesetzt von: Der DFN-Verein baut derzeit einen Roaming-Dienst auf, mit dem allen Nutzern des Deutschen Forschungsnetzes ein einfacher, sicherer und transparenter Roaming Zugriff auf das Wissenschaftsnetz ermöglicht wird (www.dfn.de/content/dienstleistungen/dfnroaming) . Einbettung der Komponente (des Systems, des Projektes): Der Roaming-Dienst wird als Funktionalität für einen weitgehend ortsunabhängigen transparenten Netzzugang zum D-Grid zur Verfügung gestellt. Bedeutung der Komponente (des Systems) im D-Grid Wenn die Vision des D-Grid u.a. als Basis für die Realisierung verteilter Organisationen umgesetzt werden soll, spielt der Netzzugang eine entscheidende Rolle. Die Vergangenheit hat in diversen Bereichen gezeigt, dass der Zugang zu Netzressourcen nicht mehr auf die Heimateinrichtung beschränkt werden kann. Insofern wird ein Roaming-Dienst mittelfristig eine wichtige Komponente im D-Grid sein. Welche Schwachstellen hat die Komponente zurzeit: Basis für einen Roaming-Dienst ist eine AA (Authentication / Authorization) Infrastruktur, z.B. auf der Basis von RADIUS-Servern. Neben dieser technischen Voraussetzung sind jedoch Bereitstellung und Pflege der darin enthaltenen Nutzer- und Identifikationsdaten von entscheidender Bedeutung. Die Konsistenz der Daten muss jederzeit sicher gestellt sein. Erarbeitet von: Marcus Pattloch, DFN-Verein <[email protected]>
