Übersicht über die Wuppertaler Arbeiten im GRID-Computing Torsten Harenberg 13. Mai 2004.

Präsentation zum Thema: "Übersicht über die Wuppertaler Arbeiten im GRID-Computing Torsten Harenberg 13. Mai 2004."—  Präsentation transkript:

1 Übersicht über die Wuppertaler Arbeiten im GRID-Computing Torsten Harenberg 13. Mai 2004

2 Gliederung Motivation Einführung in das GRID European DataGRID / LCG Wuppertaler Arbeiten D0 HEP Grid Status, Zusammenfassung

3 The Application Data crisis Wissenschaftliche Experimente generieren: Bio-Informatik Abfragen: 500 GByte pro Datenbank Satellitenbilder (Welt): ~ 5 TByte pro Jahr Heutige Teilchenphysik: 1 PByte pro Jahr LHC Physik (2007): 10-30 PByte pro Jahr Wissenschaftler in weltweiten Kollaborationen verteilt Entweder die Daten sind an einem Ort und die Wissenschaftler verteilt (Hochenergiephysik!) Oder die Daten sind über die Erde verteilt und die Wissenschafter konzentriert (Erdbeobachtung)

4 Das GRID - eine Vision Forscher arbeiten über den Erdball verteilt. Sie teilen Daten und Resourcen mit Kollegen Das GRID: vernetzte Rechenzentren verbunden durch Middleware Wiss. Experimente liefern enorme Datenmengen

5 Rückblick Grid war der nächste logische Schritt in Ende der 1990er: Steigende Rechenleistung der Desktop-PCs 1988: Condor, später: SETI@Home, Entropia, Distributed.NET Peer-to-peer Datenprotokolle erschienen 1999: Napster, later: Gnutella, KaZaa, BitTorrent Netzwerke wurden extrem schnell: 1997: wide area Bandbreite verdoppelt sich alle 9 Monate! 1997: Globus startet die Entwicklung grund- legender Middleware 1996: Middleware von Legion, 2000: Unicore 1999: Massives Auftreten der Grid Vision In Europa entstand das EU DataGrid Andere: NASA-IPG, CrossGrid, GridLab, PPDG, Alliance,..

6 European DataGRID Zielsetzung: build the next generation computing infrastructure providing intensive computation and analysis of shared large-scale databases, from hundreds of TeraBytes to PetaBytes, across widely distributed scientific communities Gestartet 2001, Ende 01.04.2004 Pilotanwender: Erdbeobachtung, Biomedizin, HEP Weitergeführt durch EGEE LCG (LHC Computing GRID) ist eine Anwendung des EDG!

7 Das EDG aus Benutzersicht

8 GridElements

9 Status des LCG

10

11 Wuppertal Arbeiten Wuppertal ist an 4 Fronten aktiv: Innerhalb von D0: Monte-Carlo Generierung und Reprozessierung (T. Harenberg, E. Pauna, NIKHEF) Bereitstellung von zentralen Diensten (RLS) Innerhalb HEP Grid Installationssupport für andere Institute (TH, EP) Erstellung eines graphischen Benutzerinterface (Dietrich Vogel) Erstellung eines Systems zur Lastverteilung der Resource Broker (Ralf Kahrl)

12 D0 in EDG/LCG D0 Software nicht für GRID- Umgebungen angepasst Datenverwaltung SAM hat einige Funktionalität des DataGRID Leichte Anpassung der D0-Software nötig (Willem van Leeuwen, NIKHEF)

13 Zusammenspiel SAM/EDG Replica Location Service Neu: SAM-client mode macht Hilfskonstruktion überflüssig

14 Status D0 in EDG/LCG MC ist in EDG lauffähig Repro war in EDG lauffähig Für LCG: MC läuft im NIKHEF-Teil des LCG Zum weltweiten Betrieb noch ein sog. RLS- Server nötig wird in Wuppertal aufgesetzt Bookkeeping soll vereinheitlicht werden (London Workshop) Datenbank-Zugriff noch zu klären

15 Diplomarbeit Ralf Kahrl: Resource Broker Thema: Entwicklung eines skalierbaren Ressource Broker Systems in der Programmiersprache Java Allgemeines Vorgehen: Analyse der vorhandenen Architektur Erstellung eines Konzeptes Evaluierung verschiedener Techniken Implementierung

16 Aufgaben des Ressource Brokers Prüfung Benutzer-VO für Rechenberechtigung Verwaltung von Benutzer Proxy-Zertifikaten Finden von passenden Ressourcen für Job-Kriterien Erzeugung einer eindeutigen JobID Übergabe des Jobs an den Job Submission Service Melden des Jobs an Logging & Bookkeeping Service

17 Struktur des EDG-Brokers job-submit list-job-match job-cancel get-job-output get-logging-info User Interface Ressource Broker job-submit list-job-matches job-cancel Job-get-output-sandbox notify job-submit job-cancel Job Submission Service Logging & Bookkeeping LogEvent Query JobLog JobStatus ClearJob Computing Element Workload Management

18 Schnittstellen

19 Problematik des derzeitigen Systems Das User Interface ist durch Konfiguration an einen einzigen Ressource Broker (RB) gebunden!!! Nachteile: Hohe Last des RB Lange Wartezeit für Clients Ausfall des RB es können kein Jobs mehr verschickt werden Single Point of Failure Klassischer Client/Server-Ansatz nicht skalierbar

20 Kurzfristige Lösung Einrichten zusätzlicher RBs für jede VO einen eigenen RB. CE RB D0 Atlas CMS UI CE

21 erster Ansatz Analyse der derzeitigen Implementierung und Entwicklung eines neuen RB Systems Aufgetretene Probleme: unzureichende Dokumentation… zu viele Ports und Protokolle sehr hohe Kopplung zu anderen Workload-Komponenten (nicht alle direkt identifizierbar) Implementierung ist nicht transparent Weiterentwicklung des ursprünglichen RB würde nicht berücksichtigt werden Spaghetticode

22 aktueller Ansatz Beibehaltung der RB-Implementierung Vorschalten eines eigenen Dienstes, der Jobs entgegennimmt und mittels Auswahlkriterien auf verschiedene Ressource Broker verteilt. Vorteil: Bestehende Infrastruktur bleibt erhalten Kommunikation läuft weiterhin über den original RB Load Balancing wird ermöglicht Ausfallsicherheit

23 Mögliches Szenario Client OGSI/ SOAP Container OGSI/ SOAP Container OGSI/ SOAP Container OGSI/ SOAP Container RB-Agent EDG RB EDG RB EDG RB RB Client API RB-Agent 1. Create Service 2. Put in Tuplespace 3. Free agent takes request 4. Submit job 1 Information Tuplespace {Request Tuple} 2 3 4 {Response Tuple} 5 6 7 8 5. Set Response Tuple 6. Available Container will get Response 7. Job Handle 8. Further Job Communication

24 Diplomarbeit Dietrich Vogel: GUI für das LCG-System Ziel: Erstellung einer benutzerfreundlichen grafischen Schnittstelle für DataGrid (LCG) Job Management Data Management Plug-In Möglichkeit für spezielle Aufgaben (z.B. Reprocessing)

25 Jobs für DataGrid werden mit Hilfe von Job Description Language beschrieben, die mit Hilfe eines Formulars automatisch erzeugt werden müssen. Jobs müssen an DataGrid geschickt werden können Jobs müssen abgebrochen werden können Status der Ausführung muss ermittelbar sein Output eines zu Ende gelaufenen Jobs muss abrufbar sein. Anforderungen an das Job Management

26 Anforderungen an das Data Management Die Daten müssen auf dem DataGrid ermittelt werden können Die Daten müssen auf das DataGrid transportiert werden können Die Daten müssen auf dem DataGrid gelöscht, kopiert und verschoben werden können

27 Realisierung Eine webbasierte Applikation mit Java Servlet Technologie Servlets generieren HTML Seiten Design der HTML Seiten wird durch Style Sheets beschrieben Benutzerhistory wird in XML abgelegt Schnittstelle zu DataGrid Globus API und WMS API Location: User Interface Webserver - Plattform: Apache Tomcat 4.1 (ist bereits installiert)

28 Klassendiagramm

29 Hierarchische Aufbau der HTML Seiten

30 Status Grundfunktionalität steht: Ein Job kann gestartet und ausgewertet werden Die Benutzerinformationen bleiben erhalten Die Hierarchie der HTML-Seiten ist implementiert.

31 TODO Authentifizierung durch im Browser installiertes Zertifikat Verwaltung der benutzerspezifischen Informationen Job- und Datenmanager entwerfen und realisieren Dokumentation

32 Zusammenfassung In großen GRIDs liegt die Zufunkt, LCG hat schon bedeutende Ausmaße erreicht Wuppertal von Anfang an dabei (Vorreiter in Deutschland, erste Uni nach GridKa) Innerhalb von D0 enge Zusammenarbeit mit dem NIKHEF Erste Diplomarbeiten!