Anhang Bestandsaufnahme

Transcrição

D-Grid – AK2
Middleware und Services
Anhang Bestandsaufnahme
Datum
04.05.2004
Seite 1
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
2.14
2.15
2.16
2.17
2.18
2.19
3
Projekte..................................................................................................................... 51
3.1
3.2
3.3
3.4
3.5
3.6
4
GRASP ............................................................................................................... 51
GeneSyS............................................................................................................. 53
GRIP .................................................................................................................. 55
DAMIEN ............................................................................................................. 56
GridLab GAT ...................................................................................................... 58
EGEE ................................................................................................................. 60
Zertifizierung und Sicherheit ......................................................................................... 62
4.1
4.2
4.3
4.4
5
Globus ................................................................................................................. 4
UNICORE........................................................................................................... 10
UNICORE Resource Broker .................................................................................. 12
Fraunhofer Resource Grid .................................................................................... 13
Storage Resource Broker ...................................................................................... 15
Platform LSF ........................................................................................................ 18
Community Scheduler Framework (CSF) ................................................................ 21
Sun Java System Portal Server ............................................................................... 23
Sun Grid Engine .................................................................................................. 26
GridSphere ......................................................................................................... 28
EDG Resource Broker .......................................................................................... 31
Relational Grid Monitoring Architecture (R-GMA) ................................................... 33
Condor............................................................................................................... 35
AVAKI................................................................................................................. 38
NSF Middleware Initiative ..................................................................................... 40
Ganglia Toolkit ................................................................................................... 42
Distributed Simulation and Virtual Reality Environment (DSVR)................................. 46
Grid-Enabled MPI (Grid-MPI)................................................................................ 48
PACX-MPI ........................................................................................................... 50
Zertifizierungsdienst DFN...................................................................................... 62
Zertifizierungsdienst GridKA.................................................................................. 63
Zertifizierungsservice im FZ Jülich.......................................................................... 64
EDG Autorisierungsmechanismus.......................................................................... 66
Kollaborations Dienste ................................................................................................ 68
5.1
5.2
5.3
5.4
H.323-basierte Videokonferenz-Systeme und Infrastruktur und DFNVC ..................... 68
VRVS .................................................................................................................. 70
Access Grid ........................................................................................................ 71
Virtual Network Computing (VNC)......................................................................... 72
Seite 2
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.
Seite 3
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 GridSysteme 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. Viele der in dieser Bestandsaufnahme beschriebenen Systeme basieren auf
Globus und erfordern somit dessen Einsatz.
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
Seite 4
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
Beispielimplementierung 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 HTTPSCallback erfolgt. Eine mögliche Lösung ist die Einrichtung eines Virtual Private Network
VPN, welches einen einheitlichen IP-Adressraum gewährleistet.
Relativ 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: unterstützt 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 implementiert das 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 Informationen 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, dass
GT3 Index Service ausschließlich auf XML baut, hingegen MDS2 GIIS LDIF nutzt.
Seite 5
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 4.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 ermöglichen
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 ermöglichen 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 für verschiedene Programmiersprachen wie Java, Perl, Python, für die
Middleware CORBA und zur Integration in Matlab.
WSRF (Web Service Resource Framework) bzw. OGSI/OGSA: Die Globus Alliance
entwickelt in Zusammenarbeit mit der Industrie (z. B. IBM und HP) derzeit das WSRF, als
eine Erweiterung von OGSA. Dieses Konzept erweitert die Spezifikation von Web
Services des W3C hinsichtlich zustandsbehafteter und transienter Ressourcen. Durch
dieses Konzept ist mit den SOAP-Client-APIs (JAX-RPC etc.) implizit eine
Programmierschnittstelle hierfür gegeben.
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 C-API
bzw. den Commodity Grid Kits (CoGs, http://www-unix.globus.org/cog/)
Seite 6
Programmierschnittstellen zur direkten Nutzung von GRAM, GridFTP, MDS und GSI zur
Verfügung, die die benoetigte Funktionalitaet zur Jobausfuehrung vergleichbar der
Kommandozeilenprogramme bereitstellen. Mithilfe des C-API oder eines CoGs können
Client-Anwendungen entwickelt werden, die direkt ohne Benutzung von
Kommandozeilentools Dienste konfigurieren und Funktionalität von Globus nutzen
können. Die CoGs benutzen spezielle Konstrukte der jeweiligen Sprache, um dem
Entwickler eine möglichst nahtlose Integration von Anwendungslogik und GlobusInteraktion in der Clientanwendung zu ermöglichen.
Das C-API und die CoGs bieten somit die Möglichkeit des Zugriffs auf ein JobSubmission-System. Für die einzelnen Jobs selbst steht keine globusspezifische
Funktionalitaet bereit, Job-Synchronisation und -Kommunikation in verteilten
Anwendungen sind Aufgaben des Entwicklers.
Globus bietet für das Anwendungsszenario solcher weit verteilten Anwendungen die
nachfolgend beschriebenen Grid Services, deren HTTP-basierte Kommunikation zudem
mögliche Probleme mit Firewalls und Gateways einer auf anderen
Kommunikationsprotokollen basierenden Lösung vermeidet.
WSRF, OGSI/OGSA des W3C
Dieser Teil der Bestandsaufnahme stellt den derzeitigen Status der Spezifikation von
WSRF und OGSI dar. WSRF ist eine Umstrukturierung und Erweiterung von OGSI. Die
derzeit verfuegbare GT3 Implementierung umfasst bislang nur die für OGSI spezifizierten
Features. Im folgenden wird aufgezeigt welche Features OGSI beinhaltet, worin die
Erweiterungen von WSRF gegenüber OGSI bestehen und welche Defizite die derzeitige
Spezifikation aufweist.
OGSI nutzt die Features von WebServices :
Web Services sind plattform- und sprachunabhaengig, beispielsweise kann ein CProgramm unter Windows einen Web Service, der in Java programmiert wurde und
auf einem Linux Rechner läuft, ansprechen.
Der Nachrichtenaustausch ist mittels HTTP möglich. Daher bieten sich Web Services
als Verteilungstechnologie, insbesondere fuer Internet-weite Applikationen an (HTTP
Nachrichten können problemlos über Internet-Proxy- und Firewall-Grenzen hinweg
übertragen werden im Ggs. zu CORBA, RMI etc.)
Typische Grid Anwendungen sind z.B. komplexe mathematische Berechnungen, die i.A.
nicht durch Ausführung einer einzelnen Operation durchgeführt werden können, sondern
durch eine Abfolge vieler Operationen, die evtl. abhängig 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 über 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 können sich durch die Intransienz
von Web Services Probleme ergeben. Intransienz bedeutet, dass alle Clients mit
demselben Web Service kommunizieren, dessen Fortbestand alle Clients überdauert.
Folglich kann es beim Zugriff auf dauerhaft gespeicherte Informationen durch mehrere
Clients zu Konflikten kommen. OGSI erweitert reine Web Services daher um das
Konzept der Factories. Eine Factory ist dabei ein Web Service, der auf Anforderung von
Clients Service-Instanzen anlegt und zur Verfügung stellt. Service-Instanzen sind
zustandsbehaftet und transient und werden in OGSA als Grid Services bezeichnet.
WSRF umfasst neben den OGSI Basisklassen und Schnittstellendefinitionen für
Factories und Service-Instanzen weitere Features, die bei der Implementierung von Grid
Services benutzt werden:
Seite 7
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. für Logging,
Runtime-Loadbalancing, Resource Management.
Service Data: WSDL beschreibt nur technische Details, wie z.B. Operationen,
Signaturen etc. Fuer einen Grid Service, können zusätzlich Charakteristika wie
Leistungsfähigkeit etc. (Resource Properties) gespeichert werden.
Asynchrone Benachrichtigungen: WSRF spezifiziert sog. Notifications. Dabei handelt
es sich um einen Messaging-Mechanismus nach einem Publish/Subscribe-Prinzip
über den Grid Services und Clients asynchron Nachrichten austauschen können.
Delegationsmodell: Komplexe Grid Services können oftmals nicht als Erweiterungen
der in OGSI vordefinierten Basisklasse implementiert werden, da bereits
Vererbungsbeziehungen zu anderen Klassen bestehen. Daher ist es auch möglich
Services durch Implementierung sogennannter Operation Provider Schnittstellen zu
implementieren. Die Konfiguration eines solchen Delegationsmodells ist etwas
aufwendiger als für Standard-Grid Services, dafür jedoch flexibler und bei
objektorientierten Technologien, die keine Mehrfachvererbung zulassen (Java) evtl.
unumgänglich.
Stateful Resource Addressing: Um zustandsbehaftete Service Instanzen in einem
Container zu identifizieren, enthalten die Reference Properties (Bestandteil der XMLDeskriptoren eines WSRF Services) eine zusätzliche 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. Ganglia) realisiert werden.
Folgende Probleme sind aufgefallen:
Generische Grid Services werden unzureichend unterstützt: Die OGSI Spezifikation
beschreibt derzeit nicht, wie Services mit beliebigem Code parametrisiert werden können
(MMJS ist dafür unzureichend).
Die CoGs sowie die APIs für OGSI sind Globus-spezifisch, für Globus entwickelte ClientAnwendungen sind somit nicht ohne weiteres auf andere Grid-Systeme uebertragbar. Im
Rahmen des D-Grid, in dem eine Integration verschiedener Grid-Systeme zu erwarten ist,
sollte eine möglichst einheitliche Programmierschnittstelle fuer sämtliche Services
verschiedener Grid-Systeme genutzt werden, die in dieser Form nicht existiert. Eine
solche Schnittstelle wird ebenfalls in der Bestandsaufnahme "einheitliche
Programmierschnittstelle für Grid Middleware (s. a. GridLab GAT)" 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 klären ob diese in OGSAAnwendungen (mittels CoGs) vom Anwendungsentwickler selbst angesprochen werden
müssen oder unnötig 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 zukünftigen Globus
Toolkit Versionen die Funktionalität der CoGs vollständig in die OGSI-Implementierung
integriert sein wird.
Seite 8
Es gibt derzeit keine Referenzanwendung, anhand der die Verwendung von OGSI als
vollstaendig aufgezeigt wird. Die Beispiele der Tutorials bieten meist nur triviale
Funktionalitat (z.B. einfache Arithmetik)
Bislang existiert als offizielle Implementierung des GridFTP-Protokolls nur der in Globus
enthaltene GridFTP-Server. Er gewährleistet einen sicheren effizienten Dateizugriff auf entfernte
Filesysteme (insbesondere mit sehr grossen Datenmengen). Höhere, für ein Data Repository
Server erforderliche Funktionalitaet (Caching, Versioning, Metadaten-Verwaltung, etc.) fehlen.
GridFTP kann aber als Grundlage zur Implementierung dieser Funktionalität 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 Funktionalität als schwierig und wird von den Globus-Entwicklern
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 Funktionalität unterstützt und die wuftpd-basierte GridFTP-Implementierung
voraussichtlich in einer der nächsten 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
Seite 9
2.2
UNICORE
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, …
Deutsche Höchstleistungsrechenzentren, DWD, Cineca, diversen Projekten weltweit
(OpenMolGRID, NaReGI, DEISA, RealityGrid, …), unbekannte Anzahl weiterer Benutzer
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 Standarderror-Informationen.
• 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 XMLBeschreibung (aus OpenMolGRID) automatisch erzeugt werden.
Seite 10
•
•
•
•
•
•
•
•
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.
Als eine Schwachstelle von UNICORE wird das Fehlen eines dynamischen Informationsdienstes
angesehen (die UNICORE Information Database ist statisch).
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
Seite 11
2.3
UNICORE Resource Broker
UNICORE Ressource Broker
Suchen und Anzeigen von verfügbaren Ressourcen, die zur Berechnung von Jobs benötigt
werden
University of Manchester (UoM), GB, im Rahmen der EU GRIP und EUROGRID Projekte
Ehemaligen Projektpartnern des GRIP und EUROGRID Projekts
Der Ressource Broker ist eine eigenständige Server-Komponente von UNICORE. Der Benutzer
sendet eine Anfrage an den Ressource Broker mit Informationen über die von ihm zur
Berechnung eines Jobs benötigte Rechen, bzw. Speicherleistung.
Für den Betrieb des Ressource Brokers ist die Installation eines Java Runtime Environment
(JRE 1.4.x oder höher) erforderlich. Zusätzliche Komponenten werden nicht benötigt.
Diese Aussagen basieren auf den Projekterfahrungen in GRIP und EUROGRID.
Der Ressource Broker sollte im D-Grid eingesetzt werden, da er verfügbare verteilte Ressourcen
findet, die zur Berechnung eines Jobs benötigt werden.
Der Ressource Broker kann ohne großen administrativen Aufwand in die UNICORE Architektur
integriert werden.
Bei Komponenten (Systemen) die eingesetzt werden sollen
Welche Schwachstellen hat die Komponente (das System) zur Zeit?
Der zur Zeit implementierte Ressource Broker stellt eine statische Lösung dar. Das bedeutet,
dass der Benutzer auf seine Anfrage eine Liste mit den seinen Anforderungen entsprechenden
Ressourcen erhält. Aus dieser Liste muss der Benutzer selber ein passendes Zielsystem
auswählen.
Momentan können nur verfügbare Ressourcen, die über UNICORE zugreifbar sind, gefunden
werden. Außerdem ist der Ressource Broker derzeit nicht in der Lage, Software-Ressourcen
oder Kostenfaktoren bei der Ressourcensuche zu berücksichtigen.
Eine dynamische Lösung soll Bestandteil eines EU FP6 Projektes sein, das sich zur Zeit in
Verhandlungen mit der Europäischen Union befindet. Mit dieser Lösung wird der Job
automatisch an die Zielsysteme geschickt, die den Anforderungen des Benutzers genügen.
Zudem ist geplant, eine Grid übergreifende Lösung des Ressource Brokers zu implementieren,
um so auch in von anderen Grid-Middleware-Systemen verwalteten Ressourcen nach
verfügbaren Ressourcen zu suchen.
Auch soll der Ressource Broker innerhalb dieses Projektes so erweitert werden, dass er in der
Lage ist, die Kosten für die Berechnung auf den jeweiligen Systemen zu ermitteln.
Seite 12
Erarbeitet von:
Michael Rambadt, Forschungszentrum Jülich
2.4
Fraunhofer Resource Grid
Fraunhofer Resource Grid
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/).
Fraunhofer FIRST, IAO, IGD, ITWM, SIT
Fraunhofer Gesellschaft
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
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
Seite 13
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".
Fraunhofer Gesellschaft
Erstellt von:
Uwe Der
Andreas Hoheisel
Seite 14
2.5
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
•
•
•
•
•
•
•
•
•
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 SRB-MCAT.
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
Seite 15
•
•
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
Sollte eingesetzt werden, da weite Verbreitung.
Seite 16
Sicherheitsprobleme
SDSC SRB Group
Erarbeitet von:
Uwe Der
Seite 17
2.6
Platform LSF
Platform LSF (=Load Sharing Facility); Platform LSF Family of Products
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“: TexasInstruments, AMD, ENEA, Pharmacia, GM, DoD – Department of Defence (USA), DoE…
viele mehr
o LSF MultiCluster bildet wahlweise zentrale oder dezentrale Strukturen, hierarchische- oder
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
Seite 18
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
Platform Computing Corp., Toronto
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/
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
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 DGRID 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.
Integration mit UNICORE ist noch nicht erfolgt.
Seite 19
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 +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/>
Seite 20
2.7
Community Scheduler Framework (CSF)
Community Scheduler Framework (CSF) GLOBUS
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.
CSF ist eine Open Source Contribution von Platform Computing.
Projektbeteiligte, siehe www.ggf.org & www.globus.org
TACC at U Texas (www.tacc.utexas.edu).
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.
unbekannt
Globus Toolkit version 3.x (www.globus.org)
www.ggf.org & www.globus.org ,
Seite 21
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
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
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
Frankfurt Office
Direct +49 (0) 69 348 123 35
Fax
+49 (0) 69 348 123 34
Mobile +49 (0) 171 6915 405
Seite 22
2.8
Sun Java System Portal Server
Sun Java System Portal Server (Grid Engine Portal)
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 Authentifizierungs-Services 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, NewsChannels, Collaboration-Tools)
Sun Microsystems
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
Seite 23
-
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
Mit der Sun Grid Engine oder ähnlichen Lösung mittels open-source servlet oder Web-Services.
Nicht bekannt. Die Anbindung wird bei Bedarf systemspezifisch analysiert.
Web – oder Application Server
Technisches Requirement.
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.
Web Service Ressource Framework ist z.Zt. noch nicht implementiert.
Ist bei Sun in der Planung.
Seite 24
Erarbeitet von:
Dr. Wilfried Stüttgen, [email protected]
Seite 25
2.9
Sun Grid Engine
Sun Grid Engine
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)
Sun Microsystems
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.
Globus Toolkit 2 und 3
Seite 26
Alle DRMAA kompatible Systeme
Nicht bekannt. Sun Grid Engine ist kompliant zu Grid Engine Open Source Project.
RDBMS für Reporting.
Entfällt.
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.
‚Globale’ Mechanismen, ist allerdings auch nicht primäre Einsatzrichtung des Produktes.
Sun in Zusammenarbeit mit Kunden aus dem Forschungs-Umfeld.
Erarbeitet von:
Dr. Wilfried Stüttgen, Sun Microsystems GmbH
Seite 27
2.10
GridSphere
Gridsphere Portal Framework (http://www.gridsphere.org), GridLab
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. Es sind zur Zeit u.a. Jobsubmission,
Filemanagement, Jobstatusabfragen und ein Single Sign On in Gridsphere und GridPortlets
enthalten.
EU Projekt GridLab; AEI Golm
AEI Golm, San Diego Supercomputing Center (GEOScience Network), Canadian NRC Grid
Infrastructure Project, Australian Virtual Observatory, Louisianna State University, Poznan
Supercomputing Center
Das Framework läuft zusammen mit dem CACTUS Toolkit und GLOBUS.
Über andere System als CACTUS und GLOBUS kann keine Aussage getroffen werden.
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.
Diese Aussagen basieren auf Erfahrungen/Tests und der Projektdokumentation.
Das Gridsphere Framework stellt eine webbasierte, open source Portallösung zur Verfügung. DGrid sollte einen webbasierten Zugriff auf Ressourcen und Informationen bereitstellen weil dies
Seite 28
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. Weiterhin unterstützt Gridsphere den JSR 168 Standard welches einen
einfachen Austausch von Komponenten anderer Portallösungen ermöglicht.
Endnutzer:
Das Benutzerinterface der „Cactus und GridPortlets“ ist zur Zeit ohne zusätzliches Wissen über
Gridcomputing 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.
Meines Wissens arbeitet im Augenblick niemand an den oben genannten Schwachstellen.
Welche Teildienste sollten funktionell in das D-Grid übernommen werden:
Das gesamte System sollte übernommen werden.
Seite 29
Erarbeitet von:
Oliver Wehrens ([email protected])
Seite 30
2.11
EDG Resource Broker
Der Resource Broker (RB) ist das Herzstück des Workload Management System (WMS) in der
EDG Architektur. Er bezieht Informationen über den Status des Grid aus dem Information Index
(II) und die Verteilung der Replikas (RLS, Replica Location Service). Anhand dieser
Informationen und der Anforderung des Nutzers wählt er das optimale Rechenzentrum zur
Ausführung aus und übergibt den Job dem dortigen Batchsystem. So werden nur solche
Computing Elements (CEs) ausgewählt, die sich nahe einem Storage Element (SE) befinden,
auf dem die ausgewählten Input-Daten (InputData in der JDL) vorhanden sind.
Figure 1. Komponenten des RB in Wechselwirkung innerhalb und ausserhalb des RB
Das User Interface (UI) ist die Komponente, die den Benutzern den Zugang zu den
Funktionalitäten des WMS ermöglicht.
Der User beschreibt den Job mit Hilfe der JDL (Job Description Language).
Ein Beispiel einer JDL-Datei:
Executable
= "./myexecutable";
Arguments
= "--config small-file.cfg --data BIG-file.dat";
StdOutput
= "std.out";
StdError
= "std.err";
InputSandbox = {"small-file.cfg"};
OutputSandbox = {"std.out","std.err","run.log"};
InputData
= {"lfn:BIG-file.dat"};
DataAccessProtocol = {"gridftp"};
Requirements = other.GlueCEInfoTotalCPUs > 4;
Seite 31
Der Network Server ist ein generischer Netzwerkdaemon, der für die Annahme der eingehenden
Aufträge (Requests) von der UI (z.B. Auftragseinreichung und Entfernung) verantwortlich ist.
Wenn es sich um einen zulässigen Auftrag handelt, wird er zum Workload Manager
weitergeleitet.
Der Workload Manager ist die Kernkomponente vom RB. Wenn der Workload Manager einen
gültigen Auftrag (Job) bekommt, leitet er die angebrachten Aktionen ein, um die gestellten
Anforderungen zu erfüllen.
Die Matchmaker/Broker Komponente stellt einen Ressourcenvermittlerdienst (Matchmaking) zur
Verfügung: Zu einem gegebenen JDL Ausdruck (z.B. für Job Submission oder für
Ressourcenreservierung), findet es die Ressource, die am Besten zu dem Auftrag passt.
Der Broker kann in drei Submodule zerlegt werden:
•
•
•
Ein Submodul welches für die Ressourcenvermittlung (Matchmaking) zuständig ist und
die passenden Ressourcen für den gegebenen JDL Ausdruck zurückgibt.
Ein Submodul welches eine Rangliste von den passenden Ressourcen erstellt und die
“Beste” Ressource für den gegebenen JDL Ausdruck zurückliefert.
Ein einfügbares Submodul welches die ausgewählte Planungsstrategie (Scheduling)
implementiert.
Der Job Adapter führt die letzten Anpassungen am JDL Ausdruck des Jobs aus, bevor es an
Condor-G zur eigentlichen Jobeinreichung (Job Submission) weitergeleitet wird. Neben der
Erstellung der Condor-G Submissiondatei erstellt dieses Modul ein Wrapper Script, welches
dafür verantwortlich ist, dass eine passende Ausführungsumgebung auf dem Computing
Elemente geschaffen wird (das beinhaltet den Transfer der Input und Output Sandbox).
Condor-G ist das Modul, welches die eigentlichen Job Management Operationen (Job
Submission, Job Removal etc.) auf Auftrag des Workload Managers durchführt.
Der Log Monitor ist für die Überwachung der Condor-G Log Datei verantwortlich. Er fängt
„interessante“ Ereignisse der aktiven Jobs ab (z.B. Job beendet, Job abgebrochen etc.) und
veranlasst entsprechende Aktionen.
Abschließend speichert der Logging und Bookkeeping Dienst (LB) die Information ab, welche
durch verschiedene Komponenten des WMS erzeugt wurden.
Basierend auf diese Informationen hält der LB Dienst eine „Statusmaschinenansicht“ für jeden
einzelnen Job.
Unterstützt wird momentan insbesondere:
Virtual Organisation Management Systems (VOMS) für VO basierte Sicherheit.
Interaktive Jobs: stdin/stdout/stderr werden direkt übertragen.
Checkpointing in „einfacher“ Form, d.h. der Entwickler ist verantwortlich für das Sichern des
Zustandes seines Jobs. Ein gescheiterter Job wird resubmitted und bekommt seinen Status
vom RB mitgeteilt.
– Parallele Jobs: Dies ermöglicht es, MPI Jobs zu verschicken. Der RB achtet hierbei darauf,
dass auf einer Site ausreichen freie CPUs zur Verfügung stehen.
• Gangmatching: Ermöglicht, verschiedene Randbedingungen gleichzeitig zu berücksichtigen.
Z.B. benötigt ein Job 10 CPUs und ein SE in der Nähe der CPUs auf dem noch 5GB frei sind.
• Automatische Registrierung von Ausgabedaten im Replika Katalog.
–
–
–
Seite 32
An der Integration eines Workflowmechanismus wie DAGman und am Accounting wird
gearbeitet.
Erarbeitet von: Marcus Hardt, Ariel Garcia, Horst Wenske.
Letzte Aktualisierung: 16.04.2004
2.12
Relational Grid Monitoring Architecture (R-GMA)
Relational Grid Monitoring Architecture (R-GMA)
Der Informationsindex MDS von Globus hat nicht die Anforderungen von EDG erfüllt, deswegen
kommt in der aktuellen Version von EDG die Eigenentwicklung RGMA zum Einsatz. Es wurde
als Monitoring-System geplant und lässt sich ebenso gut als Informationssystem einsetzen.
RGMA wurde nach dem GGF GMA Standard gebaut und benötigt keine weiteren EDG
Komponenten.
RGMA ist eine Java Serveranwendung, die auf jeder Platform lauffähig ist, die Java und einen
Webserver mit Java Servelet Unterstütutzung zur Verfügung stellt. Es ist ursprünglich mit einem
Webservice Konzept entworfen worden, welches nicht dem Webservice Standard entpricht.
Inzwischen ist RGMA mit einem überarbeiteten Webservice Design reimplementiert worden und
wird sich nach dem WSRF Standard richten, sobald er einen ausreichenden Reifegrad erreicht
hat.
Figure 2. R-GMA Architecture
Seite 33
In RGMA werden Informationen produziert, gespeichert und konsumiert.
Das ganze System agiert wie eine verteilte SQL Datenbank. Ein Producer Servlet registriert sich
bei der Registrierung (Registry) und kann den Inhalt für einen Teil einer Tabelle dieser
"Datenbank" liefern. Die Information, welche Tabellen zur Verfügung stehen, wird im
Datenbankschema (Schema) gespeichert. Wenn ein Consumer Servlet Informationen aus einer
Tabelle benötigt, befragt es zuerst die Registry nach den registrierten Produzenten. Danach
kontaktiert es direkt die Produzenten und fragt die Daten ab. Das bedeutet, dass es keinen
aktiven Datenfluss im System gibt, wenn keine aktiven Konsumenten existieren.
Es existieren verschiedene Typen von Produzenten: Stream-, DataBase-, Latest-Producer
unterstützen Datenflüsse (data streaming) zum Konsumenten, Archievierung von Daten oder
Anfragen von “aktuellen” Daten, um das System zu kontrollieren. Ein Sonderfall stellen die
Archievierer (Archivers) dar: Diese bestehen aus einem Konsumenten, der Information
abspeichert, und außerdem aus einem Produzenten, der die Informationen wieder publiziert,
wodurch historische Informationen zugänglich werden.
Besondere Features von RGMA
RGMA benutzt ein relationales Informationsmodell, wodurch man Informationen mittels SQL
angelehnten Anfragen bekommt.
Beispiel:
latest select RunningJobs,TotalCPUs,HostName from GlueCE
+-------------+-----------+---------------------------+
| RunningJobs | TotalCPUs | HostName
|
+-------------+-----------+---------------------------+
| 3
| 16
| ce.gridpp.shef.ac.uk
|
| 4
| 4
| ce001.fzk.de
|
| 4
| 28
| grid0007.esrin.esa.int
|
| 0
| 4
| grid001.pd.infn.it
|
.......................................................
| 0
| 2
| gw34.hep.ph.ic.ac.uk
|
| 5
| 10
| heplnx11.pp.rl.ac.uk
|
| 9
| 32
| tbn09.nikhef.nl
|
+-------------+-----------+---------------------------+
20 Rows in set
Es existieren bereits Schnittstellen zwischen RGMA und Nagios und Ganglia.
Für weitere Details siehe bitte http://www.r-gma.org/
Erarbeitet von: Marcus Hardt, Ariel Garcia, Horst Wenske.
Letzte Aktualisierung: 06.04.2004
Seite 34
2.13
Condor
Condor, Condor-G
Condor ist ein Resource Management- und Scheduling-System für High Throughput Computing
durch Ausnutzen brachliegender Rechenzeit auf Workstations innerhalb einer Organisation.
Condor-G hat zusätzlich Anbindung an Globus.
Condor wird seit 1988 von der University of Wisconsin entwickelt und seit etwa einem Jahr unter
einer BSD-ähnlichen Lizenz frei erhältlich. Solange der Sourcecode noch bereinigt/überarbeitet
wird, bekommt man ihn momentan nur auf Anfrage (die UNI Karlsruhe verfügt über die
Sourcen). Homepage: http://www.cs.wisc.edu/condor/
Evaluation an der Uni Karlsruhe und Uni Jena; hier bisher kein Produktivbetrieb;
Condor 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.lsc-group.phys.uwm.edu/vdt/)
Einsatz im TeraGrid: http://www.teragrid.org/userinfo/guide_jobs_condorg.html
Condor ist auf vielen Plattformen lauffähig: MacOS X, Tru64 Unix, HP-UX, Irix, Linux, Solaris,
Windows. Es gibt diverse Einschränkungen hinsichtlich der Betriebssystem- und LibraryVersionen (s.u.).
Die Variante Condor-G (http://www.cs.wisc.edu/condor/condorg) verwendet Globus, um Jobs
über das Grid starten bzw. aus dem Grid Jobs entgegennehmen zu können.
Der sog. Glide-In Mechanismus ermöglich es, einen (lokalen) Condor-Pool auf externe GridRessourcen auszudehnen, indem dort zunächst automatisch Condor-Binaries installiert werden
(glide-in), die dann Kontakt zum lokalen Condor-Masterserver aufnehmen. Dadurch kann
temporär ein virtueller, vergrößerter Pool erzeugt werden.
Die Evaluation an der Uni Jena mit einer älteren Condor-Version hat gezeigt, dass Condor
relativ empfindlich gegenüber den verwendeten Betriebssystem- und StandardbibliothekVersionen ist. Für einen reibungslosen Betrieb von Condor an der Uni Jena, war es notwendig,
dass die Betriebsumgebung exakt auf die verwendete Condor-Version abgestimmt wird. Bei
neueren Condor Versionen sollten diese Schwierigkeiten nicht mehr auftreten (konnte noch nicht
getestet werden).
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 (WorkstationZoo) den geeignetsten Rechner für einen gegebenen Job zu finden,
automatisches, transparentes Checkpointing,
Seite 35
automatische Prozessmigration,
Definition von Workflows über den Condor Dagman,
Unterstützung von interaktiven Jobs via Condor on Demand (COD),
hochentwickelte Monitoring Tools z.B. Condor Hawkeye,
Produktionsstabilität (ist bereits seit Jahren im industriellen Einsatz),
Unterstützung von GSI und Kerberos Authentifizierung,
ein sehr aktives Projekt mit ca. 40 Entwicklern,
viele ergänzende Projekte, die die Funktionalitäten von Condor besonders im I/O Bereich
erweitern.
Ein paar ausgewählte Condor Projekte:
Stork
Ein Datenplazierung Scheduler der Daten analog wie Jobs als „First Class Citizens“ im Grid
behandelt (Daten Queuing, Monitoring, Check-Pointing etc.).
GCB, DPF, eGCB
Der Generell Connection Broker (GCB) und der Dynamic Port Forwarder (DPF)
zusammengefasst in den extended Generell Connection Broker (eGCB) ermöglichen es, dass
Condor Pools in privaten Netzwerken über Firewalls hinweg miteinander verbunden werden
können (via Condor Flocking).
SOAP API / Webservice Unterstützung
Es existiert bereits ein Prototyp von einer Condor SOAP API, die in die nächste Developer
Version einfließen wird.
Weitere Condorprojekte kann man auf der Condor Homepage finden.
Bedeutung für das D-Grid:
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, so dass sich die Konzepte nicht nur für lokale Pools einsetzen lassen
(http://www.globus.org/toolkit/contributors.html).
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-Pool-Modell 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
Seite 36
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.
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:
Rudolf Lohner, RZ Uni Karlsruhe <[email protected]>
Horst Wenske, RZ Uni Karlsruhe <[email protected]>
Dietmar Fey, FSU Jena <[email protected]>
Christian Kauhaus, FSU Jena <[email protected]
Seite 37
2.14
AVAKI
AVAKI Data Grid 4.0
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.
AVAKI Corporation, www.avaki.com
The North Carolina Bioinformatics Grid (NC BioGrid)
(Weitere Informationen von AVAKI angefordert)
GRID: GLOBUS, GLOBUS-CSF, LSF-MultiCluster-Grid
RMS: LSF, SGE, …
Datenbanken: Oracle, DB2, …
Storage: NAS, SAN, NFS, …
Seite 38
unbekannt
keine
AVAKI Dokumentation
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.
Es ist zu prüfen, inwieweit das Thema AVAKI besser bei einem anderen Arbeitskreis
angebracht ist oder in AK2 verfolgt werden sollte
Erarbeitet von:
Bernhard Schott
Direct +49 (0) 69 348 123 35
Fax
+49 (0) 69 348 123 34
Mobile +49 (0) 171 6915 405
Seite 39
2.15
NSF Middleware Initiative
NSF Middleware Initiative
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
Software-Paketen, 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.
Seite 40
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
Ressourcen-Auslastung (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.
Seite 41
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/
NSF Projekt unter Einbindung mehrerer Forschungseinrichtungen in den USA
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
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.
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]
2.16
Ganglia Toolkit
Name der Komponente:
Seite 42
Ganglia Cluster Toolkit
http://ganglia.sourceforge.net
Funktion der Komponente:
Ganglia ist ein skalierbares verteiltes System für das Monitoring von high-performance
Systemen (z.B.: Clustern und Grids).
• auf jedem Node wird ein Monitoring-Dämon (gmond) installiert
• auf dem zentralen Knoten zusätzlicher Dämon (gmetad), es kann meherer zentrakle
Konten gegeben
• Verteilung der Messdaten im Abstand von einigen Sekunden über Multicast
• Daten werden mit Hilfe von RRDTool in Round Robin Databases gesammelt
(stündlich, täglich, wöchentlich, monatlich, jährlich)
• Neben voreingestellten Metriken lassen sich eigene Messpunkte in Ganglia
einspeisen
Ganglia besteht aus:
• Ganglia Monitoring Daemon (gmond): Gmond has four main responsibilities: monitor
changes in host state, multicast relevant changes, listen to the state of all other
ganglia nodes via a multicast channel and answer requests for an XML description of
the cluster state. Each gmond transmits in information in two different ways:
multicasting host state in external data representation (XDR) format or sending XML
over a TCP connection.
• Ganglia Meta Daemon (gmetad): Federation in Ganglia is achieved using a tree of
point-to-point connections amongst representative cluster nodes to aggregate the
state of multiple clusters. At each node in the tree, a Ganglia Meta Daemon (gmetad)
periodically polls a collection of child data sources, parses the collected XML, saves
all numeric, volatile metrics to round-robin databases and exports the aggregated
XML over a TCP sockets to clients. Data sources may be either gmond daemons,
representing specific clusters, or other gmetad daemons, representing sets of clusters.
Data sources use source IP addresses for access control and can be specified using
multiple IP addresses for failover. The latter capability is natural for aggregating data
from clusters since each gmond daemon contains the entire state of its cluster.
•
Ganglia PHP Web Frontend: It provides a view of the gathered information via realtime dynamic web pages. Most importantly, it displays Ganglia data in a meaningful
way for system administrators and computer users. Although the web frontend to
ganglia started as a simple HTML view of the XML tree, it has evolved into a system
that keeps a colorful history of all collected data. The Ganglia web frontend caters to
system administrators and users. For example, one can view the CPU utilization over
the past hour, day, week, month, or year. The web frontend shows similar graphs for
Memory usage, disk usage, network statistics, number of running processes, and all
other Ganglia metrics. The web frontend depends on the existence of the gmetad
which provides it with data from several Ganglia sources. Specifically, the web
frontend will open the local port 8651 (by default) and expects to receive a Ganglia
XML tree. The web pages themselves are highly dynamic; any change to the Ganglia
data appears immediately on the site. This behavior leads to a very responsive site,
but requires that the full XML tree be parsed on every page access. Therefore, the
Ganglia web frontend should run on a fairly powerful, dedicated machine if it presents
a large amount of data. The Ganglia web frontend is written in the PHP scripting
language, and uses graphs generated by gmetad to display history information. It has
been tested on many flavours of Unix (primarily Linux) with the Apache webserver
and the PHP 4.1 module.
Seite 43
Ziel des Projektes
Ganglia is a scalable distributed monitoring system for high-performance computing systems
such as clusters and Grids. It is based on a hierarchical design targeted at federations of
clusters. It relies on a multicast-based listen/announce protocol to monitor state within
clusters and uses a tree of point-to-point connections amongst representative cluster nodes
to federate clusters and aggregate their state. It leverages widely used technologies such as
XML for data representation, XDR for compact, portable data transport, and RRDtool for data
storage and visualization. It uses carefully engineered data structures and algorithms to
achieve very low per-node overheads and high concurrency. The implementation is robust,
has been ported to an extensive set of operating systems and processor architectures, and is
currently in use on over 500 clusters around the world. It has been used to link clusters
across university campuses and around the world and can scale to handle clusters with 2000
nodes.
(Quelle: Ganglia Webseite)
Open Source Lösung
weltweit,
Fraunhofer Ressource Grid, auch an anderen Forschungseinrichtungen innerhalb
Deutschlands bzw. innerhalb von D-Grid
Einbettung der Komponente:
Integration von Portable Batch System (PBS) Informationen (sararocks)
Mit welchen Systemen gibt es keine reibungslose Kooperation?
Stand alone Lösung, aber Integration in Globus MDS (ungetestet)
http://www.globus.org/mds/gangliaprovider.html
Bedeutung der Komponente im D-Grid
Die Komponente sollte im D-Grid eingesetzt werden, da sie ein guter Ersatz für Globus MDS
ist. (z.B. deutlich bessere Skalierbarkeit)
Darstellungsfehler im grafischen Frontend
Seite 44
Ganglia Entwickler. Open Source
Erarbeitet von:
Uwe Der
Seite 45
2.17
Distributed Simulation and Virtual Reality Environment
(DSVR)
Name der des Systems:
DSVR (Distributed Simulation and Virtual Reality Environment)
Das Software-Framework DSVR beinhaltet Middleware- und Service-Komponenten für die
parallele Aufbereitung von Zwischenergebnissen aus parallelen Simulationsrechnungen in
3D-Visualisierungen, den Transport von somit generierten 3D-Szenensequenzen, die
Speicherung und Ausspielung sowie die kollaborative 3D-Betrachtung (libDVRP, dvrserver,
npdvr). Mit Hilfe der Bibliothek libDVRP werden Daten aus parallelen (MPI-basierten)
Simulationsrechnungen extrahiert, in 3D-Visualisierungsobjekte konvertiert und zu einem so
genannten 3D-Streamingserver (dvrserver) transportiert und dort gespeichert. Von dort
können synchron oder asynchron 3D-Animationen abgerufen und in einem Viewer-Plugin
(npdvr) auf einer 3D-Grafikworkstation (PC, Workstation oder
Hochleistungsvisualisierungsrechner) mit angeschlossenen Präsentations- und
Interaktionsgeräten (z. B. stereoskopischer Bildschirm, Holobench, 3D-Tracking) dargestellt
werden. Für Computational Steering bietet das DSVR-System auch einen Rückkanal an, der
es ermöglicht, im Viewer-Plugin bei synchroner Nutzungsform in die laufende
Simulationsrechnung – etwa durch Änderung von Parametern – steuernd einzugreifen. Der
Viewer-Plugin beinhaltet eine Integrationsmöglichkeit von Video-Conferencing-Techniken
(Einblendung des Video-Bildes in die VR).
Produzent des Systems:
Regionales Rechenzentrum für Niedersachsen (RRZN), Universität Hannover.
Das System wird zurzeit eingesetzt von:
verschiedenen HLR-Anwendungen, z. B. im HLRN (Norddeutscher Verbund für Hoch- und
Höchstleistungsrechnen): PALM (Parallel Large Eddy Simulation Model) des Instituts für
Meteorologie und Klimatologie (IMUK, Universität Hannover), zur Simulation von
atmosphärischen und ozeanischen turbulenten Strömungsphänomenen.
Vorarbeiten z. B. im Rahmen des DFN/BMBF-Projekts „Tele-Immersion“.
Einbettung des Systems:
MPI, TCP/IP.
Bedeutung des Systems im D-Grid:
Das System sollte im D-Grid zur Unterstützung integrierter, wissenschaftlicher
Arbeitsumgebungen – „Virtual Labs“ – eingesetzt werden, in denen effiziente Mechanismen
zur grafischen Aufbereitung komplexer Simulationsergebnisse, zur Kopplung
„großer“ Simulations- und Visualisierungsinfrastrukturen bzw. -anwendungen sowie
verschiedene synchrone und asynchrone Nutzungsszenarien angeboten werden.
Welche Schwachstellen hat das System zurzeit:
•
•
•
•
•
Statische, wenig nutzerfreundliche Konfiguration.
Zentralisierte 3D-Streamingserver-Komponente, d. h. keine Proxy-Server.
AAA-Mechanismen (Authentication, Authorization, Accounting) wurden bisher nicht
implementiert.
Übergreifendes (Parallelrechner, Server, Grafikrechner, 3D-Displays, Netzbandbreiten)
Ressourcen-Scheduling nicht realisiert.
Begrenzte Unterstützung von Daten- bzw. Gittertypen.
Seite 46
RRZN.
Erarbeitet von:
Stephan Olbrich <[email protected]>
Seite 47
2.18
Grid-Enabled MPI (Grid-MPI)
Allgemeine Bescheibung :
Message Passing Interface (MPI) Libraries sind der de facto Standard für massiv parallele
Computer und Cluster von Workstations. Sie werden in weitem Umfang in
wissenschaftlichen Rechnen verwendet. Es liegen sowohl vendor-spezifische
Implementationen, als auch OpenSource Implementationen des MPI-Standards vor.
Weiteste Verbreitung hat zur Zeit der MPI Standard 1.2, Implementationen des MPI 2.0
Standards liegen vor, sind aber noch nicht ubiquitär. 1
Als Bestandteil der D-GRID Middleware ist eine grid-enabled MPI-Implementation (im
folgenden Grid-MPI) erforderlich. Die Bereitstellung dieser MPI-Suite ist eine notwendinge
Bedingung für wissenschaftliches Rechnen unter Benutzung des D-GRID in vielen
Bereichen, z.B. astrophysikalische Simulationen.
Eine MPI-Implementation besteht aus einer Suite von Compiler-Tools, Headers und Libraries, die
eine Parallelisierung von Computer-Programmen durch standardisierte Kommunikations- und
Kontrollstrukturen ermöglicht. Für die Grid-Middleware ist zudem erforderlich, daß die Implementation
'grid-aware' ist, d.h. die bereitgestellte Grid-Infrastruktur benutzt.
Implementationen von Grid-MPI
Was ist mit Stampi und LAM?
MPICH-G22 :
Die in Zusammenarbeit mit der Globus-Developper-Community entwickelte MPICH-G2 stellt
eine Suite bereit, die den MPI-1.1 Standard implemetiert.
– MPICH-G2 benötigt Globus 2.4x.
Für den Einsatz im D-Grid ist zu empfehlen, einheitlich von der Version 1.2.5.2
auszugehen, die allerdings mit früheren Versionen inkompatibel ist. Die genannte
Version kann lokal vendor-spezifische MPI (eg. SGI-MPI, IBM-SP) und OpenSource
MPICH integrieren.
3
– MPICH-G2 liegt für alle Unix-Systeme als Source-Paket vor . Sie muss gegen die
Globus-Source-Distribution kompiliert werden.
– MPICH-G2 erfordert wie Globus spezielle Firewall-Settings, dh einen kontrollierten
freien Port-Range4 und evtl. zusätzliches Routing, weil zB Cluster i.a. private
Netzwerk-Adressen für die Node-to-Node-Kommunikation benutzen, MPI aber
Node-to-Node-Kommunikation auch über Site-Grenzen hinweg erfordert.
PACX-MPI (PArallel Computer eXtension)5
Die am HLRS (Hochleistungs Rechenzentrum Stuttgart) entwickelte Implementation
unterstützt MPI-1.2 und Teile des 2.0-Standards.
– PACX-MPI benutzt lokal vendor-spezifische MPI-Implementationen.
– PACX-MPI liegt für Unix-Systeme als Source-Paket vor.
1Zu Standard und Implementation von MPI: http://www-unix.mcs.anl.gov/mpi/
2MPICH-G2 -Homepage: http://www3.niu.edu/mpi/ . G2 bezieht sich auf die Globus-Version, nicht auf
den MPI-Standard.
•
3MPICH ist auch für Windows-NT verwendbar, die Grid-Kompatibilität aber unklar.
4http://www.globus.org/security/firewalls/Globus%20Firewall%20Requirements-5.pdf
5PACX-MPI -Homepage http://www.hlrs.de/organization/pds/projects/pacx-mpi
Seite 48
–
–
–
–
–
•
Vorteil des PACX-Ansatzes: die MPI-Kommunikation zwischen Clustern und/oder
PVM-Maschinen wird an dedizierten Nodes (Daemons) gebündelt, sodaß die
Firewall-und Routing-Anforderungen reduziert werden.
PACX-MPI kann grid-aware gemacht werden, ist daher kompatibel mit andern
Middleware-Komponenten; es wurde erfolgreich aus Globus heraus gestartet
PACX-MPI unterstützt für P2P-Kommunikation interoperables MPI (IMPI).
PACX-MPI bietet für die Topologie des Metacomputers optimierte kollektive
Operationen.
PACX ist nicht so weit verbreitet und getestet wie MPICH-G2.
Neben diesen beiden Implementationen gibt es noch weitere Projekte6 wie NAREGI, die eine
Verbesserung der Grid-MPI anstreben. Bislang ist aber keine Implementation veröffentlicht.
Empfehlung zur Grid-MPI:
Im ersten Release der Middleware sollte die MPICH-G2 Suite( mpich 1.2.5.2) enthalten sein.
Für einen effizienten Einsatz von MPI-basierten Applikationen im D-Grid ist es erforderlich, die Latenz
und Geschwindigkeit der Netzwerk-Verbindungen erheblich zu verbessern.
6Homepage: http://www.gridmpi.org. Es gibt auch weitere Ansätze für die Interoperabilität der MPISuite, die aber nicht direkt Grid-basiert sind, eher einen dazu orthogonalen Ansatz verfolgen, zB
IMPI (http://impi.nist.gov/IMPI/impi-report/impi-report.html)
Seite 49
2.19
PACX-MPI
PACX-MPI
PACX-MPI ist eine Middleware um HPC-Ressourcen über ein gemeinsames Netzwerk
transparent für die MPI-Applikation zu koppeln. Hierfür kann ein dediziertes
Hochleistungsnetzwerk oder aber auch das Internet dienen. Die Applikation muß neu mit der
Bibliothek übersetzt werden. Kommunikation zwischen Prozessen innerhalb des HPCRechners findet durch die für die jeweilige Plattform optimierte MPI-Bibliothek statt.
Kommunikation zu externen Prozessen wird über zwei spezielle Prozesse ermöglicht.
Dadurch hat PACX-MPI im Vergleich zu anderen MPIs den Vorteil, Cluster mit lokalen IPAdressen verbinden zu können. Außerdem nutzt PACX-MPI das Wissen um die Topologie
des Rechners bei kollektiven Operationen.
Höchstleistungsrechenzentrum der Universität Stuttgart
Universität Houston, Technische Universität Katalonien, Freie Universität Barcelona
Vendor-MPI (bsp. LAM, MPIch, MPIpro, MPI-SX), Integration in Globus
Die Zusammenarbeit mit Queueing Systemen ist bei keinem der Alternativen einfach. Es
fehlt ein Scheduler mit „globalen“ Queues.
ANSI C-Compiler, MPI, evtl. Fortran-Compiler.
PACX-MPI bietet für MPI-Applikationen die oben angesprochenen Vorteile bei der
Koppelung von HPC-Ressourcen.
Wenn die Applikation nicht auf die hierarchiesche Struktur, d.h. die Topologie, eines
Metacomputers optimiert wurde, ist der Einsatz eines Metacomputers als Gesamtes nicht
sinnvoll.
Die Netzwerkperformance ist damit das allerwichtigste Kriterium.
HLRS.
Erarbeitet von: Stefan Wesner
Seite 50
3 Projekte
3.1
GRASP
Das EU Projekt GRASP realisiert aufbauend auf dem OGSI.NET Toolkit eine Reihe von
Diensten und Komponenten, die den Einsatz von Grid für Application Service Provider
ermöglicht. In diesem Zusammenhang werden neben der Realisierung eines Prototypen und
der Validierung mit Anwendungen aus den Bereichen E-Learning und verteilte Datenanalyse
auch untersucht welche Geschäftsmodelle auf Basis von Grid Technologie möglich sind.
Die folgende Liste ist keine vollständige Liste der Komponenten sondern fasst lediglich die
Schlüsselemente zusammen.
Service Locator/Broker
Dieser Dienst ist von entscheidender Bedeutung bei der Formierungsphase einer Virtuellen
Organisation und spielt ebenfalls bei automatisierter Fehlerbehandlung eine wichtige Rolle.
Diese Komponente erlaubt die Identifizierung und Auswahl von Diensten anhand einer Reihe
von Paramtern, die neben Art des gesuchten Services und der Funktionalität auch Quality of
Service Anforderungen, Preisinformation und Präferenzen für bestimmte Anbieter sein
können.
Service Instantiation
Ein grundlegendes Konzept in GRASP ist die so genannte “Virtual Hosting Environment
(VHE)”. Eine VHE kann eine Vielzahl von Ressourcen/Diensten enthalten, die innerhalb
einer Virtuellen Organisation angeboten werden sollen. Alle Ressourcen innerhalb einer VHE
werden von einer Entität überwacht. Wichtige Komponenten einer VHE sind der Service
Instantiator der die Erzeugung eines Services innerhalb einer VHE durchführt und auch die
Performanz und Verfügbarkeit dieser Dienste überwacht.
Service Orchestration
Die Bereitstellung der Funktionalität für den ASP Anbieter kann nicht durch einzelne Services
bereitgestellt werden sondern diese werden durch einen Workflow in einer Koordinierten
Weise zusammengebracht. Innerhalb von GRASP wurde auf Standardprodukte für
Workflow-Management im Web Services Bereich (Biztalk 2004) unter Nutzung von
BPEL4WS zurückgegriffen. Da BPEL4WS nicht für die Orchestrierung von Grid Services
ausgelet ist wurden die entsprechenden Komponenten innerhalb von GRASP entwickelt.
SLA Management
Als Teil der Service Auswahl werden wie oben beschrieben auch QoS Parameter
berücksichtigt. Diese Parameter müssen während der Ausführung überwacht werden und
gegebenenfalls auch entsprechend z.B. durch Service re-location behandelt werden. Die
Service Level Agreements werden dabei in einem automatisch zu verarbeitenden XML
Format (WSLA + Extensions) beschrieben
Die Projektteilnehmer des Projektes GRASP. http://eu-grasp.net
Nicht im produktionsbetrieb.
GRASP basiert auf OGSI.NET von University of Virginia und verwendet Microsoft Biztalk
2003 als workflow engine.
Seite 51
GRASP entwickelt wichtige Komponenten im Umfeld Application Service Provision diese
sind jedoch gegenwärtig nicht im Produktionszustand. Aus diesem Grund kann eine direkte
Verwendung (noch) nicht empfohlen werden.
Die Ergebnisse von GRASP werden die Basis für Weiterentwicklungen auf europäischer
Ebene im Bereich Kommerzialisierung von Grid sein und sollten in D-Grid
Forschungsaktivitäten, die eine Integration von kommerziellen Anbietern von
Dienstleistungen eine Ausgangsbasis bieten.
Erarbeitet von:
Stefan Wesner (HLRS)
Seite 52
3.2
GeneSyS
Das EU Projekt GeneSyS realisiert mit Web Service Technology ein Framework für die
Überwachung und Kontrolle von verteilten Anwendungen. Dabei werden verschiedene
Schichten einer verteilten Anwendung von Netz über Middleware bis hin zur Applikation in
einer integrierten Weise behandelt.
Die folgende Liste ist keine vollständige Liste der Komponenten, sondern fasst lediglich die
Schlüsselzemente zusammen. Zurzeit sind nur folgende Version 1 GeneSyS Komponenten
verfügbar:
GeneSyS Komponenten
GeneSyS Core
Beschreibung
Stellt eine potentiell verteilte Registry für
Informationen über alle verfügbaren und aktiven
Services bereit. Zum testen und entwickeln
eigener Agenten wird zur Zeit ein Core vom
HLRS bereitgestellt und ist verfügbar unter:
http://dotnet.rus.unistuttgart.de:8080/axis/services/GenesysService
Generic Console/System
Console/…
Eine generische graphische Konsole für die
Visualisierung der ermittelten Werte des
verteilten Systems.
Darüber hinaus existieren weitere spezialisierte
Klienten.
Dient zur Überwachung der Systemauslastung
(z.B. Memory, CPU, Freier Plattenplatz)
Bildet die Schnittstelle zu SNMP basierten
Aktiven Informationsquellen wie Router, HUB’s.
Auch passive Komponenten wir NIC werden
unterstützt
Zur Zeit wird nur die Round Trip Time zwischen
einzelnen Hosts ermittelt.
Ermittelt die relevanten Performance Daten des
Tomcat Web Servers. Tomcat ist eine wichtige
Hosting Environment für Web Services.
System monitoring agent
(W2K/Linux)
Passive/Active Network Agent
Network Quality Agent
Tomcat monitoring agent
In einer zweiten Version (verfügbar Q3/2004) werden eine Reihe weitere Services und ein
deutlich verbessertes Kommunikationsprotokoll vorliegen. Darüber hinaus werden Services
mit Schnittstellen zur Beeinflussung des Systemzustandes ausgestattet werden. Diese
Maßnahmen können dann entweder durch Benutzer aber auch durch Regel- und Workflow
basierte Services im Sinne von „Autonomic Computing Light“ automatisch angewendet
werden.
Die Projektteilnehmer des Projektes GeneSyS, siehe http://genesys.sztaki.hu Partner aus
Deutschland HLRS und NAVUS GmbH.
Im Rahmen des Projektes im Testbetrieb am HLRS für die Überwachung von WebServer
Systemen.
Seite 53
Basiert auf WebServices und ist daher generell einsetzbar. Überwachbare Elemente siehe
obige Tabelle
Web Service Interop Tests und eigenen Erfahrungen.
Die Ergebnisse von GeneSyS sind in Ihrer Funktionalität fortgeschrittener als z.B. GMA und
bilden eine Basis für Weiterentwicklungen im Rahmen von D-Grid.
Ein direkter produktiver Einsatz ist zur Zeit nur bedingt möglich.
Schwachstellen sind insbesondere das Sicherheitsmodell. Diese wird im rahmen des
projektes vorraussichtlich nicht vollständig gelöst und wird Teil der kommerziellen
Verwertung durch die Fa. NAVUS sein.
GeneSyS is jedoch unter W3C Lizenz als open source unter source forge verfügbar und
kann potentiell von jedem weiterentwickelt werden.
Sourceforge Distributionsseite: http://sourceforge.net/projects/genesys-mw/
Erarbeitet von:
Stefan Wesner (HLRS)
Seite 54
3.3
GRIP
Grid Interoperability Project (GRIP)
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
(alphabetisch) Argonne National Laboratory, Deutscher Wetterdienst, Forschungszentrum
Jülich, Fujitsu Laboratory Europe, Intel, University of Manchester, University of Southampton,
Warschau University
Projektpartnern, NaReGI Projekt, einige weitere Benutzer
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).
Da sowohl UNICORE als auch Globus mit großer Wahrscheinlichkeit zur Basis des initialen
D-Grids zählen werden, bietet die in GRIP entwickelte Software die Möglichkeit, Ressourcen
zu kombinieren und Erfahrungen mit Interoperabilität zu sammeln.
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
(service-oriented 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.
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
Seite 55
3.4
DAMIEN
DAMIEN (Distributed Applications and Middleware for Industrial use of European Networks)
Das Ziel von DAMIEN (Distributed Applications and Middleware for Industrial use of
European Networks) war es Tools und Middleware zu entwickeln, die es erlauben verteilte
Simulationen
auf
einer
Grid
Infrastruktur,
basierend
auf
Europäischen
Hochgeschwindigkeitsnetzen, durchführen zu können. Ein wichtiger Gesichtspunkt war dabei
die Benutzer bei der Optimierung ihren spezifischen Anwendungen zu unterstützen. Deshalb
sollten bei den Benutzern schon etablierte Tools erweitert und mit neuen Funktionalitäten
ausgestattet werden, damit sie in Grid Umgebungen eingesetzt werden können. Ein weiterer
Aspekt war die Integration eines Netzwerk QoS Managers, der es erlauben soll, direkt aus
der Applikation heraus Netzwerkparameter zu ändern und damit bestmögliche Performance
zu erreichen. Diese Tools wurden mit einer reellen Anwendung aus dem Bereich
Multiphysiks (entwickelt von EADS) in verschiedenen Testbeds getestet.
1. Middleware
Das in DAMIEN unterstützte Programmiermodell ist MPI. Deshalb wurde die am HLRS
entwickelte und für Grid Umgebungen optimierte MPI-Bibliothek PACX-MPI verwendet.
Im Rahmen von DAMIEN wurde PACX-MPI erweitert, um gleichzeitig mehrere
Netzwerkverbindungen zwischen den Rechnern verwenden zu können (bessere
Ausnutzung von Bandbreiten).
Für die Kopplung zweier Applikationen (z.B. Strukturmechanikcode mit einem
Akkustikcode) wurde MpCCI verwendet. Die Bibliothek wurde auf PACX-MPI portiert. Es
wurden neue Interpolationsmethoden eingebaut.
2. Performance Analyse und Vorhersage
Performance Analyse
Vampirtrace: wurde auf PACX-MPI portiert damit es auch für Grid Applikationen
verwendet werden kann
Vampir wurde mit neuen Funktionalitäten ausgestattet um die Informationen über die
Prozesse der Grid Applikation sinnvoll darstellen zu können
a. Performance Vorhersage
Dimemas: Tool zur Vorhersage des Laufzeitverhaltens von MPI-Applikationen
basierend auf Traces, Parameter wie Latenz und Bandbreite können dabei variiert
werden
Dimemas wurde erweitert, um Vorhersagen auch für Anwendungen, die in Grid
Umgebung laufen, machen zu können (Einbau neuer Kommunikationsmodelle)
3. Grid Konfigurations Manager (GCM):
Erleichtert Umgang mit verschieden Grid Umgebungen, die den Zugang zu den
Hardware Ressourcen (Hosts) regeln entwickelt
erstellt und verschickt automatisch die Konfigurationsdateien, die von PACX-MPI
benötigt werden
Erstellung der Sicherheitskonfigurationen für verschiedene Grid Umgebungen.
Anwendungen gleichzeitig für Unicore, Globus (GT 2) und per ssh zu starten und zu
überwachen -> Grid Terminals, in dem gleichzeitig alle an der verteilten Simulation
beteiligten Hosts gehandhabt werden können
Seite 56
4. QoS-Manager:
QoS Manager wurde auf Basis von IPv4/IPv6 implementiert, damit Applikationen in der
Lage sind, zur Laufzeit Anforderungen (Bandbreite, Latenz) and die Netzwerkschicht
zu senden
Realer Einsatz allerdings nicht wirklich möglich, da zur Zeit noch keine Möglichkeit
besteht, diese Anforderungen auf Netzwerkebene automatisch zu verarbeiten
5. Anwendung und Testbeds
a. EADS Anwendung und Testbed
Gekoppelte Anwendung bestehend aus mechanischen Code (NASTRAN) und
Akkustic Code (entwickelt von EADS)
Anwendung lief gleichzeitig auf Cluster in Paris und Toulouse
b. Weltweites Testbed für RNAfold und FastDNAml
Anwendungen aus dem Bereich Bioinformatik
Testbed zur SC2002 bzw. SC2003 mit Supercomputerbeteiligung aus der ganzen
Welt
Erarbeitet von:
Peggy Lindner (HLRS)
Seite 57
3.5
GridLab GAT
Einheitliche Programmierschnittstelle für Grid Middleware (s.a. GGF WG SAGA: Simple API
for Grid Applications)
Erarbeiten eines einfachen und einheitlichen API’s für verschiedene Grid Middleware
Services, die den Anwendungsprogrammierer von der dynamischen Struktur des Grid selbst
abstrahieren.
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.
Noch kein Einsatz unter Produktionsbedingungen, erster prototypischer Einsatz von Teiles
eines solchen API’s im Testbed des Gridlab Projektes.
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.
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.
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.
Seite 58
Gridlab Projekt
Erarbeitet von:
Hartmut Kaiser, AEI Golm
Seite 59
3.6
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:
Seite 60
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.
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
Seite 61
4 Zertifizierung und Sicherheit
4.1
Zertifizierungsdienst DFN
Zertifizierungsdienst
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.
Der Zertifizierungsdienst wird vom DFN-Verein über seine DFN-PCA erbracht (www.dfnpca.de) .
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.
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.
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]>
Seite 62
4.2
Zertifizierungsdienst GridKA
Zertifizierungsdienst GridKA
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.
das EU DataGrid Projekt
das EU CrossGrid Projekt
das LCG Projekt
DESY (Hamburg)
folgende Hochenergiephysik Experimente: Alice, Atlas, BaBar, CDF, CMS, COMPASS,
D0, LHCb.
Globus Security Infrastructure (X.509)
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 EUGrid 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.
Erarbeitet von:
Marcus Hardt, Ursula Epting, Ariel Garcia.
Seite 63
4.3
Zertifizierungsservice im FZ Jülich
UNICORE Certification Authority (UNICORE-CA)
Signierung von UNICORE Server- und Benutzerzertifikaten
Zentralinstitut für Angewandte Mathematik (ZAM) im Forschungszentrum Jülich (FZJ)
Forschungszentrum Jülich und ehemaligen Projektpartnern aus dem EUROGRID und GRIP
Projekten
Die UNICORE-CA besteht aus einem Registrierungsserver und einem Zertifizierungsserver.
Der Registrierungsserver bildet die Schnittstelle zwischen Benutzer und Zertifizierungsserver.
Auf dem Registrierungsserver kommen die eingehenden Zertifikatanfragen an und werden
von da aus weiter zum Zertifizierungsserver geleitet. Der Registrierungsserver ist die einzige
Schnittstelle zum Zertifizierungsserver. Um ein Schlüsselpaar generieren zu können, wird
empfohlen, den UNICORE Klienten zu verwenden. Alternativ kann die Anfrage mittels
OpenSSL Befehlen direkt generiert werden.
Keinem.
Für den Betrieb des Registrierungsservers ist Java (JRE 1.4.x) erforderlich. Der
Zertifizierungsserver verwendet Perl Skripten, die OpenSSL Kommandos verwenden.
Registrierungs- und Zertifizierungsserver kommunizieren über eine dedizierte Verbindung.
Der Registrierungsserver per HTTPS erreichbar. Für die Kommunikation zwischen Benutzer
und Registrierungsserver und zwischen den Komponenten muss jeweils ein Webserver (z.B.
Apache) auf dem Registrierungs- und dem Zertifizierungsserver laufen.
Diese Aussagen basieren auf den Erfahrungen, die die Entwickler der UNICORE-CA im
Produktionsbetrieb bisher gemacht haben.
Da UNICORE voraussichtlich eines der Systeme sein wird, die die Basis des D-Grids bilden
sollen, muss eine Umgebung existieren, die sowohl dem Benutzer als auch dem
Administrator eine komfortable und zugleich sichere Schnittstelle zur Signierung von
UNICORE Zertifikaten bietet. Die vom FZJ entwickelte Lösung erfüllt bereits diese
Anforderungen einer funktionierenden Zertifizierungsinstanz. Die UNICORE-CA erlaubt dem
Benutzer, eine neue Zertifikatanfrage zu senden und signiert die Anfrage. Der signierte
öffentliche Schlüssel wird dem Benutzer per E-Mail zugeschickt. Falls Probleme beim
Signieren aufgetreten sind, wird der Benutzer auch darüber informiert. Außerdem erlaubt die
UNICORE-CA, bereits signierte Zertifikate auch wieder zurückzurufen. Die signierten und
zurückgerufenen Zertifikate werden automatisch veröffentlicht.
OpenSSL und Java bilden zwar die Grundlage der UNICORE-CA, aber diese Komponenten
können auch eine gewisse Schwachstelle bedeuten. Zum einen, weil es vorkommen kann,
Seite 64
dass bisher noch nicht bekannte Sicherheitslücken im OpenSSL Paket entdeckt werden und
zum anderen, weil man nicht immer davon ausgehen kann, dass Weiterentwicklungen von
OpenSSL und Java kompatibel mit den Vorgängerversionen sind. Zudem muss zur Zeit noch
jeder Benutzer, der ein Zertifikat beantragt, von den UNICORE-CA Administratoren in eine
UNICORE Datenbank eingetragen werden. In dieser wird das jeweilige Zertifikat auf den
Benutzernamen auf dem entsprechenden Zielsystem abgebildet. Das bedeutet zur Zeit noch
einen erhöhten Administrationsaufwand.
Auf die Entwicklung von OpenSSL und Java haben die UNICORE-CA Administratoren
keinen Einfluss. Wie die Vergangenheit jedoch gezeigt hat, sind die Änderungen, die die
UNICORE-CA betreffen könnten, in der Regel so marginal, dass eine Anpassung an eine
neue Version weitgehend problemlos verlaufen sollte.
Eine automatische UNICORE Datenbankerweiterung soll Bestandteil eines FP6 Projektes
sein, das sich zur Zeit in Verhandlungen mit der Europäischen Union befindet. Falls die
Verhandlungen positiv verlaufen, wird das FZJ als einer der Projektpartner die automatische
Datenbankerweiterung implementieren.
Erarbeitet von:
Michael Rambadt, Forschungszentrum Jülich
Seite 65
4.4
EDG Autorisierungsmechanismus
Grundsätzlich sind die Authentifizierung und die Autorisierung zu unterscheiden. Während
bei der Authentifizierung die Echtheit der digitalen Unterschrift in Form eines Zertifikates
überprüft wird, berechtigt die Autorisierung Benutzer zum Zugriff auf Ressourcen.
Zur Authentifizierung von Benutzern (und Diensten) in der EDG/LDG Middleware kommt die
Globus Security Infrastructure (GSI) zur Anwendung. Sie basiert auf der Private/Public Key
Infrastructure (PKI) mit X.509 Zertifikaten.
Die Autorisierung beinhaltet bereits in frühen Versionen der EDG/LCG Middlware einige
Veränderungen im Vergleich zu Globus. In späteren Entwicklungen wurden weitere
Änderungen vorgenommen, die im Anhang erwähnt werden, da sie für eine erste Version
einer D-GRID Infrastruktur nicht notwendig sind.
Der Globus Autorisierungsmechanismus
Jeder Benutzer besitzt ein eigenes Zertifikat, das aus einem Private/Public Key Pair besteht.
Das Zertifikat enthält das sogenannte Subject, die eindeutige Kennung des Benutzers als
Distinguished Name (DN). Das Subject eines Zertifikates für einen DESY-Benutzer
ausgestellt vom GridKa in Karlsruhe sieht so aus:
"/O=GermanGrid/OU=DESY/CN=Manfred Mustermann"
Mit jedem Auftrag (Job) wird ein Stellvertreter (Proxy) des Benutzerzertifikates versendet,
das vom Benutzer zuvor unter Verwendung eines Passwortes erzeugt worden ist (grid-proxyinit). In einer einfachen Globus 2.x Installation geschieht die Autorisierung über das
sogenannte grid-mapfile. Das grid-mapfile muß auf allen Systemen, die lokale
Zugangsberechtigungen erfordern, vorhanden sein. Dazu gehören der Resource Broker (RB)
und das Computing (CE) und Storage Elemente (SE); die einzelnen Rechenknoten (Worker
Nodes) normlerweise nicht, da sie einfache Klienten eines Batchsystems des CE sind. Das
grid-mapfile kann manuell vom Systemadministrator oder automatisch mit einem regelmäßig
ausgeführten Skript gepflegt werden. Sobald die Gültigkeit eines Benutzerzertifikates
überprüft wurde (Authentifizierung), wird im grid-mapfile nach dem Subject gesucht. Das
grid-mapfile enthält Zeilen der Form:
"/O=GermanGrid/OU=DESY/CN=Manfred Mustermann" muster001
Wenn eine Übereinstimmung gefunden wurde, wird der Job des Benutzers unter dem
lokalen Benutzerkonto am Ende der Zeile (in diesem Beispiel: muster001) ausgeführt. Das
Benutzerkonto wird hier statisch einem Subject zugewiesen.
Der EDG Autorisierungsmechanismus
Die EDG/LCG Middleware erweitert das Globus Schema um das Konzept der Virtual
Organization (VO). Das VO System stellt verteilte Informationsquellen für den Globus
Mechanismus zur Verfügung, aus denen die grid-mapfiles automatisch generiert werden.
Eine VO ist in diesem Sinne eine Ansammlung von autorisierten Benutzern bzw. deren
Subjects, etwa einer HEP Kollaboration.
Technisch gesehen gibt es zu jeder VO einen LDAP-Server, der die Subjects der
zugehörigen Benutzer enthält. Diese Informationen werden automatisch und regelmäßig
mehrmals täglich abgerufen, und es wird ein grid-mapfile generiert. Zur Anwendung kommt
das Perl-Skript edg-mkgridmap, das die Informationen über die abzurufenden VOs und
deren LDAP-Server aus einem Konfigurationsfile bezieht (/opt/edg/etc/edg-mkgridmap.conf).
Da die Mitglieder einer VO im allgemeinen nicht auf allen am Grid teilnehmenden Systemen
lokale Benutzerkonten haben, kann auch keine statische Zuweisung zu diesen erfolgen.
Stattdessen werden die Subjects einer VO einem Konto aus einem Pool (Pool Account)
Seite 66
zugewiesen, der zum Zeitpunkt der Ausführung des Jobs nur einmal vergeben wird. Die
tatsächlichen Konten würden im Beispiel einer VO=muster mit dem Pool muster etwa
muster001, muster002, usw. heissen. Das grid-mapfile hat dann Zeilen der Form:
"/O=GermanGrid/OU=DESY/CN=Manfred Muster" .muster
Dies Verfahren wurde vom Globus Konsortium übernommen. Das aktuell in EDG/LCG
verwendete Globus 2.4 Toolkit wird vom Nord-amerikanischen Vitual Data Toolkit (VDT)
Projekt (http://www.lsc-group.phys.uwm.edu/vdt/) bereitgestellt und enthält Pool Accounts.
Diese Funktionalität kann durch das Setzen der Umgebungsvariablen GRIDMAPDIR mit dem
Pfad zu den Konten aktiviert werden.
Das VO Schema unterstützt die Verwendung von Ausschlusslisten (Black Lists), um einzelne
Subjects zu sperren. Andererseits können Benutzer, die nicht Mitglied einer VO sind, explizit
eingetragen werden.
Anhang: Erweiterungen zum Sicherheitsmechanismus
Drei Komponenten sind bisher nicht beschrieben worden, obwohl sie bereits Teil der
EDG/LCG Middleware sind. Sie könnten von Nutzen für eine spätere Version der D-GRID
Infrastruktur sein. Die Komponenten bieten erweiterte Funtionalitäten und mehr Flexibilität
und sind im folgenden beschrieben.
VOMS VO-Management:
Das einfachen VO System beinhaltet gravierende Schwächen, z.B. kann ein Subject nur zu
genau einer VO gehören. Will eine Person Mitglied mehrerer VOs sein, muss er/sie mehrere
Zertifikaten mit unterschiedlichen Subjects besitzen. Rollen sind nicht vorgesehen. Deshalb
wurde das erweiterte Virtual Organization Membership System (VOMS) entwickelt. Es
kommt in späteren EDG Versionen zur Anwendung. Als Verbesserung arbeitet VOMS mit
erweiterten Proxies, die zusätzlich zur Identität genauere Informationen über die
Mitgliedschaft des Benutzers zu VOs, seine Rollen und Rechte enthalten. Dadurch wird es
möglich Ressourcenverteilung auf der Basis von Regeln (Policies) durchzuführen. Die VOMS
Server werden über eine HTTP-basierte Schnittstelle über das WWW administriert.
Systeme zur lokalen Autorisierung (LCAS) und Rechte Zuweisung (LCMAPS):
Wenn ein Benutzer Zugriff auf lokale Rechenressourcen erbittet, entscheiden zwei
Softwarekomponenten, ob der Zugriff erlaubt wird und welche lokalen Rechte dem
ausgeführten Job eingeräumt werden. Beide Komponenten sind als Plug-Ins realisiert und
unterstützen den VOMS Mechanismus.
Das Local Authorization System (LCAS) entscheidet über die Zugangsgewährung entweder
auf Basis eines einfachen Textfiles der VO-Gruppen-Rolle oder eines GACL (XML ACL)
Files. Dann wird die Anfrage an das Local Credential Mapping System (LCMAPS) übergeben,
das diese den entsprechenden Rechten zuweisst, unter denen der zugehörige Job
ausgeführt werden soll. Zuerst wird aufgrund der vorgegebenen Regeln, die konfigurierbar
sind, entschieden, ob lokale Berechtigungen wie Unix UIDs/GIDs, AFS-Tokens usw.
verwendet werden sollen, oder passende erzwungen werden (z.B. durch setuid()).
Durch die Verwendung von Plug-Ins ist das System sehr modular und ausbaufähig und
ermöglicht es leicht neue Funktionalitäten zu implementieren.
Es bleibt desweiteren anzumerken, dass für den Datentransfer meistens das GridFTP
Protokoll verwendet wird, das zwar die Autorisierungs Informationen über den Kontrollkanal
aber nicht den Datenkanal verschlüsselt.
Der Datenzugriff wird über die Unix-Dateigruppenrechte geregelt.
Weiterhin ist die Rechnungsstellung (Accounting) ein offenes Thema.
Erarbeitet von: Ariel Garcia (FZK) und Andreas Gellrich (DESY)
Seite 67
5 Kollaborations Dienste
5.1
H.323-basierte Videokonferenz-Systeme und Infrastruktur
und DFNVC
H.323-basierte Videokonferenz-Systeme und Infrastruktur und DFNVC
Funktion der Komponente (des Systems, des Projektes):
Ermöglicht qualitativ hochwertige Videokonferenzen mit mittlerem Bandbreitenbedarf (~ 1
Mbit/s je Teilnehmer)
Produzent der Komponente (des Systems, Projektbeteiligte):
Standards: ITU. Die IETF arbeitet an dem verwandten SIP („H.323-light“)
Diverse kommerzielle Systemhersteller, Endgeräte z.B. Polycom und Tandberg; Gatekeeper,
Gateways und MCUs etc. von denselben Herstellern.
Ein sehr guter Gatekeeper/Proxy aus dem GNU-Umfeld.
Der H.323 basierte Dienst DFNVideoConference wird im Deutschen Forschungsnetz
angeboten, mit derzeit mehreren Tausend Konferenzen im Monat. (Rahmenverträge mit
HGF, MPG und 5 Bundesländern sowie Einzelverträge mit ca. 70 Einrichtungen)
Der Videokonferenzdienst im Wissenschaftsnetz ermöglicht Mehrpunktkonferenzen direkt
vom Arbeitsplatz oder von einem Raumsystem unter Nutzung der DFN Multipoint-ControlUnit (MCU). Der Dienst ist international erreichbar. Verwendet wird eine Gatekeeper-Struktur
mit einem weltweit abgestimmten Nummernplan (Global Dial Schema) zur Adressierung der
Kommunikationspartner. (Kompatibilität/Direktwahl mit nationalen Gatekeepern in USA,
Niederlanden, Grossbritanien, Schweiz,...)
Zusätzlich können ISDN-Teilnehmer in die Konferenz über ein Gateway eingebunden
werden. Die 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.
Einen entsprechenden Dienst bietet in USA ViDeNet an. Mittlerweile ist auch
Internet2 aktives Mitglied bei ViDe geworden und nutzt ViDeNet, auch unter der
Projektbezeichnung Internet2 Commons (Die Gemeindewiese).
(siehe auch generische Beschreibung VK- und Kollaborationssysteme)
Es bestehen Standards zur Einbettung bezüglich Verzeichnisdiensten (H.350) und DataCollaboration (H.239)
Seite 68
Ein Übergang zu ISDN-Basierten (H.320) Konferenzen existiert und ist häufig wichtig bei
Projekten mit Industrie oder anderweitig per Internet schlecht zu Erreichenden.
(siehe generische Beschreibung VK- und Kollaborationssysteme)
Welche Schwachstelle hat die Komponente (das System) zurzeit
Der Standard H.350 zur Einbettung von VK-relevanten Informationen in Directories ist zwar
verabschiedet, aber von Endgeräteherstellern noch nicht umgesetzt. Scheduling- und
Reservierungslösungen sind bisher proprietär; dito Interfaces z.B. zu Lotus Notes.
Die von den Endgeräte- (und MCU-) Hersteller angebotenen Interfaces zu „DataCollaboration“ bestanden bisher überwiegend in T.120-Unterstützung – welches wegen der
NetMeeting Orientierung obsolet ist. Der Standard H.239 zur Übertragung eines zweiten
Stroms, geeignet auch zur Übertragung von XGA-Signalen, etwa Präsentationen, ist
verabschiedet, aber noch nicht durchgängig umgesetzt (wiewohl die beste Hoffnung unter
den Security-mässig einfach zu implementierenden „Standards“)
Wer arbeitet an einer Verbesserung der Schwachstellen
DFN, Internet2, Hersteller, http://www.gnugk.org/, ...
Erarbeitet von:
Hans Pfeiffenberger <[email protected]>
Marcus Pattloch < [email protected]>
Ulrich Schwenn <[email protected]>
Seite 69
5.2
VRVS
VRVS
Wird für qualitativ mittelwertige Videokonferenzen mit „geringem“ Bandbreitenbedarf (~ 128
kbit/s mal Anzahl Teilnehmer, je Teilnehmer) „cross-platform“ eingesetzt.
Es nutzt die MBone Systeme VIC & RAT und bietet darüber hinaus eine komfortable
Weboberfläche für Verbindungsaufnahme, Reservierung etc.
Gateways zu H.323 und AccessGrid werden angeboten. Das H.323 Gateway wurde
innerhalb der MPG (IPP) intensiv getestet und als nicht akzeptabel bezüglich Qualität und
Betriebsstabilität abgelehnt
http://www.vrvs.org/About/ ( ~ Caltech, CERN ?? )
(in D: unbekannt)
Bild- und vor allem Tonqualität sind eher randständig.
Nutzung ist recht unzuverlässig und personalaufwendig.
Gateways funktionieren eher schlecht.
Keine Verbindung zur Grid-Welt bekannt
Das System sollte für D-Grid nicht propagiert werden
Erarbeitet von:
Seite 70
5.3
Access Grid
Access Grid
Ermöglicht qualitativ hochwertige Videokonferenzen mit hohem Bandbreitenbedarf (~ 10
Mbit/s je Teilnehmer)
Für das eigentliche Audio- und Videokonferenzing werden die MBone Tools vic und rat
benutzt. Es werden vom System auch Unicast/Multicast Bridges unterstützt wodurch nicht
zwingend ein funktionierendes Multicast vorhanden sein muß. Es werden unterschiedliche
Konfigurationen unterstützt, vom großen Seminarraum mit mehreren Projektoren,
getrennten Rechnern für Audio- und Videoaufnahme und hardwarebasierter Audiofeedbackunterdrückung bis hin zum einfachen Laptop mit Headset. Das Access Grid stellt
Schnittstellen zur Verfügung, um eigene Applikationen einbinden zu können. Unter anderem
wurde ein Shared Webbrowser und ein Shared MS-PowerPoint implementiert. Ein Text-Chat
ist mit im Basissystem integriert. weitere Infos unter http://www.accessgrid.org . Dort gibt es
unter anderem ein ausführliches online tutorial.
http://www.accessgrid.org/ ( ~ Argonne Natl. Lab ? )
Derzeit gibt es etwa 150 US, 30 UK, 7 D und weitere ca 70 weltweit registrierte Standorte,
überwiegend Unis. Man beachte die starke Verbreitung in England.
Für die größeren Einrichtungen ist Multicast ein MUSS, mit allen damit verbundenen
Problemen (Router, Manpower).
Das DEISA Projekt der EU wird Access Grid verwenden, einige deutsche GRID Anwender
(AEI Potsdam, FZ Jülich) haben AG Nodes.
Hoher Bandbreitenbedarf, hoher Personalbedarf, Hardware eher noch teurer als H.323.
Eher auf komplette, dedizierte Räume ausgerichtet.
Erarbeitet von:
Uwe Wössner <[email protected]>
Seite 71
5.4
Virtual Network Computing (VNC)
VNC (Virtual Network Computing);
verschiedene, zueinander kompatible Versionen (RealVNC, TightVNC, UltraVNC).
Allgemein: Fernzugriff auf den Windows-Desktop (MS Windows, XWindows) über das Netz;
damit: Echtzeit-Verteilung von Präsentationen, kollaboratives Arbeiten.
Open Source; RealVNC (hervorgegangen aus einem Team der AT&T Laboratories in
Cambridge)
Verbreitetes Standardsystem z. B. für E-Learning, Fernwartung.
VNC ergänzt den Einsatz von Videokonferenz bzw. Videoübertragungssystemen,
insbesondere von H.323-Mehrpunktkonferenzen durch die Übertragung von
Bildschirminhalten, wie z. B. Präsentationen. Es stellt damit eine Alternative zu T.120 (z. B.
MS NetMeeting) dar. Das System ist weit gehend plattformunabhängig (MS Windows, Linux,
Solaris, Java u. a.). Lediglich die Übertragung von Bildschirm-Overlays (Video, Open-GL) ist
nicht möglich. Speziell UltraVNC liefert sehr gute Ergebnisse bzgl. Darstellungsqualität und
Wiederholrate bei Bitraten um 1 Mbit/s. Weitere Komponenten sind für den Einsatz nicht
erforderlich, bei einer höheren Anzahl parallel zugreifender Teilnehmer kann der Einsatz
eines VNC-Replikators vorteilhaft sein. VNC wurde im RRZN z. B. für den Einsatz in ELearning-Szenarien evaluiert.
VNC ergänzt das H.323-Videokonferenzsystem um die oft benötigte Verteilung von
Bildschirmdarstellungen. Die Open-Source-Architektur ermöglicht gegebenenfalls individuelle
Anpassungen an individuelle Applikationen.
VNC wurde ursprünglich für die System-übergreifende Fernwartung und damit 1:1Verbindungen entwickelt. Die Weiterentwicklungen bieten 1:n-Verbindungen, wobei
zwischen passivem und aktivem Zugriff differenziert werden kann. Der parallele aktive Zugriff
mehrerer Teilnehmer ist jedoch nicht (wie etwa bei NetMeeting) reglementiert und gestaltet
sich daher bei einer großen Teilnehmeranzahl als schwierig.
Alle drei genannten Versionen werden aktiv von den jeweiligen Teams (Real, Tight, Ultra)
weiterentwickelt.
Erarbeitet von:
Ralf Einhorn <[email protected]>,
Stephan Olbrich <[email protected]>
Seite 72

Anhang Bestandsaufnahme

Transcrição

Documentos relacionados

Das Morfeus GRID - Aufbau und Anwendungen

2K-PU Anti-Graffiti Schutzlack

nano-glasversiegelung - Koch

PipeDraft Quick Reference Card

Globus

Impressionen zum

Ein Wettkampfschuh für neue Bestzeiten Der Grid Type A4 von

BFLUBER-Silvester Berlin 29.12.10

Infostand Globus Lahnstein 9.6.12

Stil- und Farbberatung – Für ihren typ - fema