European DataGrid (EDG) Middleware CrossGrid (X#) Middleware Certification Authority (CA) in Karlsruhe

Transkript

1 European DataGrid (EDG) Middleware CrossGrid (X#) Middleware Certification Authority (CA) in Karlsruhe Marcus Hardt, Ariel Garcia, Ursula Epting 5. März European DataGrid (EDG) Das EDG-Projekt ( wurde von der EU finanziert vor ca. 3 Jahren gestartet und ist heute gerade in der Abschlussphase. Die entwickelten Dienste des EDG-Projekts orientieren sich dabei stark an den Bedürfnissen der vier CERN Experimente. Jeweils ein WorkPackage beschäftige sich mit Biomedizinischer Bilddatenverarbeitung bzw. mit Erdbeobachtungen (ESA/ESRIN). Im Rahmen von EDG sind einige, für unsern Arbeitskreis interessante Produkte entstanden. Diese werde ich später genauer beschreiben. Zunächst jedoch ein Überblick über die Architektur (siehe Abbildung 1). Site A Computing Worker Node Site B Storage Computing Worker Node Information Index Replica Location Server Site C Storage User Resource Broker Monitoring Replica Information Interaktion Computing Worker Node Abbildung 1: Informationsfluss und Interaktion im EDG 1

2 Jede Site besteht zumindest aus den zwei folgenden Komponenten: Computing (CE) Das CE ist wesentlichen ein modifizierter globus-gatekeeper. Er nimmt jobs entgegen und leitet diese mit Hilfe des lokalen Batchsystems an die Workernodes (WN) weiter. Der Zustand der WNs einer Site wird im Information Index veröffentlicht. Storage (SE) Das Storage (SE) bringt ein Mass-Storage-System (z.zt. Castor, DCache) ins Grid. Die Kommunikation geschieht dabei im wesentlichen mit Hilfe von GridFTP. Das Management von Dateien und deren Replikas auf den verschiedenen SE geschieht mit Hilfe des Replika Manager, der diese im Replica Location Server (RLS) registriert. Einer physikalischen Datei (PFN) wird dabei ein logischer Dateiname (LFN) zugewiesen. Bei Zugriff auf Dateien anhand logischer Dateinamen können Optimierungen eingeführt werden. Der Zustand der SEs wird im Information Index (II) veröffentlicht. Im folgenden werden spezielle Komponenten beschrieben, die im EDG-Projekt basierend auf dem Globus Toolkit entwickelt wurden. 1.1 Workloadmanagament System (WMS) Aufgabe des Workload Management System ist die optimale Verteilung von abgeschickten Jobs. Der User beschreibt dazu den Job mit Hilfe der JDL (Job Description language). Mit Hilfe von Kommandozeilen Tools wird der Job verschickt. Hier 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 = {"LF:BIG-file.dat"}; ReplicaCatalog = "ldap://rls.example.org:12345/lc=wpsixcollection,\ rc=wpsixrc,dc=testbed,dc=fzk,dc=de"; DataAccessProtocol = {"gridftp"}; Diese Information benutzt das WMS um den Job an das dafür beste Rechenzentrum zu schicken. Das WMS besteht aus zwei Komponenten. User Interface UI Hier schickt der User den Job von der Kommondozeile ab. Resource Broker RB Der RB (Abb. 2) ist das Herzstück der EDG Architektur (Abb. 1.) Er bezieht Informationen über den Status des Grid aus dem Information Index (II) und die Verteilung der Replikas (RLS). Anhand dieser Informationen und der Anforderung des Nutzers wählt er das optimale Rechenzentrum zur Ausführung aus und übergibt den Job dem dortigen Batch System. (Details auch hier 1 ) So werden nur solche CE ausgewählt, die sich nahe einer SE befinden, auf der die ausgewähltem Input-Daten (Input-Data in der JDL) vorhanden sind. Unterstützt wird momentan insbesondere VOMS für VO basierte Sicherheit. Interaktive jobs: stdin/stdout/stderr werden direkt übertragen 1 sgaravat/grid/wms-infngrid-ct.pdf 2

3 Abbildung 2: Komponenten des RB in Wechselwirkung innerhalb und ausserhalb des RB Checkpointing der einfach 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. bentigt 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. An der Integration eines workflow Mechanismus wie DAGman und am Accounting wird gearbeitet. 1.2 Relational Grid Monitoring Architecture (R-GMA) Der Informations Index MDS von Globus hat nicht die Anforderungen von EDG erfüllt. Deswegen kommt in der aktuellen Version von EDG die Eigenentwicklung RGMA (Abb. 3 zum Einsatz. Es wurde als Monitoring System geplant und lässt sich ebensogut als Informations System einsetzen. Es wurde nach dem GGF GMA Standard gebaut. Ferner bestehen keine Abhängigkteiten zu anderen EDG Komponenten. Das schönste an RGMA ist allerdings, dass es ein relationales Informationsmodell nutzt. D.h. Informationen daraus lassen sich mit an SQL angelehnten queries beschaffen. Beispiel latest select RunningJobs,TotalCPUs,HostName from GlueCE

4 Abbildung 3: Architektur von RGMA RunningJobs TotalCPUs HostName ce.gridpp.shef.ac.uk 4 4 ce001.fzk.de 4 28 grid0007.esrin.esa.int 0 4 grid001.pd.infn.it gw34.hep.ph.ic.ac.uk 5 10 heplnx11.pp.rl.ac.uk 9 32 tbn09.nikhef.nl 3 21 testbed001.phys.sinica.edu.tw Rows in set In RGMA werden Informationen produziert, gespeichert und konsumiert. Diese Komponenten registrieren sich in der Registry. Einzelne Produzenten könenen jeweils Teile von Tabellen füllen, die den Konsumenten mitgeteilt werden oder aus dem Speicher abgefragt werden können. Zur genaueren Beschreibung der Dokumentation siehe bitte hier 2 ) Es existieren bereits Schnittstellen zwischen RGMA und Nagios und Ganglia, do wohl hinreichen bekannt sind. 1.3 Mapcenter MapCenter ist ein flexibles Monitoring und Präsentationssystem. Es stellt ein Web-Frontend zur Verfügung, das verschiedene Ansichten auf ein Grid gibt. Gleichzeitig stellt es farblich dar, wie ob ein Service verfügbar ist oder nicht. Eine Demonstration findet sich hier 3. Diese Informationen entnimmt es dem Informationssystem (MDS oder RGMA) und eigenen Verbindungsversuchen auf entsprechende Dienste. 2 marcus/rgma.ppt 3 4

5 1.4 Daten Management Service Wie der Name DataGrid suggestiert, ist dies ein wesentlicher Output von Datagrid. Insgesamt bestehen diese Services aus den folgenden Komponenten: Replica Manager (RM) Replica Location Service (RLS) Replica Metadata Catalog (RMC) Replica Optimization Service (ROS) Die im Detail hier 4 gut beschrieben sind. Der Replika Manager ist das Werkzeug, das sowohl vom Benutzer als auch vom Resource Broker verwendet wird, um Daten zu Verwalten. Sinn der Sache ist, einen Überblick darüber zu haben, wo Kopien einer Datei liegen. Dieses Konzept ist zunächst nur für read-only Dateien anzuwenden. Die Basisfunktionalität, die der Replika Manager dazu zur Verfügung stellt, lieftert die Möglichkeit, Dateien im Katalog (RLS) zu registriert, zu kopieren in das Grid und wieder heraus zu kopieren, replikas zu listen und schliesslich zu löschen. Weitergehende Funktionen benutzen den Replica Optimization Service und stellt Funktionen wie getbestfile() oder getaccesscost() bereit, mit denen sich die am schnellsten verfügbare Instanz einer Datei respektive die Zeit sie zu erhalten ermitteln lässt. 1.5 VOMS VO-Management The early releases of EDG were based on a simple VO system designed to provide a distributed information source for Globus gridmapfile mechanism. Each VO administers a so called VO server (LDAP based) which contains a list of members of the VO. This information is used by mkgridmapfile to generate the local gridmapfile, containing all the users allowed to access that resource. To overcome the limitations of this method, an enhanced VO Management System (VOMS) was developed and incorporated in the later DataGrid releases. It supports the usage of extended proxies, which contain not only the user s identification but also a set of non-critical extensions with fine grained information about the user s membership to groups in the VO, roles, and capabilities. This additional information encoded in the proxy allows, for instance, the gatekeeper to grant or deny access to the cluster to users from different VO groups according to the time of the day based on local policies. The VOMS server is accessed through an http administrative interface. 1.6 Local authorization and credential mapping systems When a user request for access arrives to a local computing resource, two software components take care of deciding if access will be granted, and in that case which local rights will be granted for the processing of that job. Both are plugin based, and support the VOMS mechanism. The LCAS component decides if the incoming request should be allowed or banned, according to either a plain text VO-group-role policy file or a GACL language (XML ACLs) file. Then the request is passed to the LCMAPS component, which in turn maps it to the corresponding local credentials under which it should be run. First a policy engine decides, based on a configuration file, the order in which the Aquire and Enforce plugins are to be run. Then, based on the users credentials and on the job specification (JDL), the LCMAPS plugins either grant local credentials (Unix uid s, gid s, AFS tokens, etc) or enforce them, for instance in the running process by means of system calls setuid(), etc. This system is very extensible and modular, making it very easy for sites/organizations to add new functionality by writing new plugins. 4 marcus/datamanagementtutorial.ppt 5

6 2 CA 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äre. Dieser etwa 6 monatige Prozess hat zu folgenden Eigenschaften der CA geführt: CA Zertifikat ist max. 5 Jahre gültig, mind. Schlüssellänge beträgt 2048 Bit. CA-Maschine ist offline, Zugang nur CA-Personal gestattet. User-/Host-/Servicezertifikate sind max. 1 Jahr gültig, mind. Schlüssellänge 1024 Bit; wird ein neues Zertifikat beantragt muss ein neuer Schlüssel generiert werden. Ein Userzertifikat enthält die -adresse des Nutzers, bzw. den Full Qualified Domain Name des Hosts als X.509-Erweiterung Subject Alternative Name. (Weitere X.509 und Netscape Erweiterungen siehe Policy) Certification Policy (CP) und Certification Practice Statement (CPS) sind wie in RFC 2527 vorgeschlagen strukturiert und enthalten eine sog. Objektidentifier Nummer (OID von zugewiesen), diese ist auch in den Zertifikaten enthalten, so dass sichtbar ist, unter welcher Policy ein Zertifikat ausgestellt wurde. CA-Zertifikat, CP/CPS und Widerrufslisten (CRL s) werden im Web veröffentlicht. CRL s müssen nach Widerruf eines Zertifikats sofort und sonst alle 23 Tage erneuert werden. pro Projekt bzw. Institution existiert mind. eine verantwortliche Person, die persönlich bekannt ist und die die Berechtigung des Antragstellers durch die Unterschrift bestätigt. Ausserdem ist die CA-Policy im Hinblick auf einen mit vertretbarem Aufwand zu gewährleistenden Betrieb geschrieben worden. Das äussert sich darin, dass: 1. Ein Antragsteller sich ausreichend durch die Kombination von einer Kopie des Personalausweises und der Unterschrift eines Verantwortlichen ausweisen kann. Diese Kopie wird per Post (nicht FAX!) an die Zertifizierungsstelle gesendet. Nach Erhalt der Kopie wird der Antragsteller über seine offizielle Telefonnummer zurückgerufen, damit die Absendung des Requests noch einmal mündlich bestätigt werden kann. So entfällt eine Reise zum FZ Karlsruhe 2. Die Möglichkeit des Aufbaus von sogenannten Registration Authorities (RAs) ist vorgesehen (2. Halbjahr 2004). Es ist anzumerken, dass diese CA u.a. deshalb aufgebaut wurde, weil die Policy des DFN nicht im EDG grid Umfeld akzeptiert worden wäre. Da diese CA nun in verschiedenen EU-Grid Projekten (EDG, CrossGrid, EGEE) akzeptiert ist, ist geplant, diese unabhängig vom Einsatz in D-Grid weiterzuführen. Es erscheint daher aus FZK-Sicht machbar und sinnvoll, auch in D-Grid Zertifikate auszustellen, allerdings die arbeit der Registrierung durch den Aufbau von Registration Authorities zu verteilen. Der Aufbau einer hierarchischen Zertfizierungsstruktur erscheint dagegen weniger sinnvoll, da nicht nur sämtliche Zertifikate installiert, sondern auch viele Certificate Revokation Listen aktuell gehaltern werden müssten. Zu prüfen bleibt, ob die Policy bzw. die RA Struktur der Jülicher CA kompatibel ist. 3 CrossGrid / Roaming Access Server Im Rahmen von CrossGrid werden unter anderem ein Tools für den Remote Access von Grid Anwendungen (RAS) entwickelt. Dieses Tool dient als backend für grafische frontends (Java Desktop, Web Portal), die von verschiedenen Orten aus mit der immer gleichen Benutzeroberfläche genutzt werden können. Die 6

7 Benutzerdaten werden dabei in einem LDAP server gespeichert um diese unabhängig vom RAS server zu halten. Als backend nutzt es die EDG-API um Jobs zu verschicken und auf die Datenspeicher zuzugreifen. Der RAS Service befindet sich momentan noch in der Entwicklung, daher ist keine Umfangreiche Dokumentation vorhanden. 7