Übersicht über die Wuppertaler Arbeiten im GRID-Computing

Torsten Harenberg

13. Mai 2004

Gliederung

• Motivation

• Einführung in „das GRID“ European DataGRID / LCG

• Wuppertaler Arbeiten D0 HEP Grid

• Status, Zusammenfassung

„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)

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

Rückblick

Grid war der nächste logische Schritt in Ende der 1990er:Steigende Rechenleistung der Desktop-PCs1988: Condor, später: SETI@Home, Entropia, Distributed.NETPeer-to-peer Datenprotokolle erschienen1999: Napster, later: Gnutella, KaZaa, BitTorrentNetzwerke wurden extrem schnell:1997: wide area Bandbreite verdoppelt sich alle 9 Monate!1997: Globus startet die Entwicklung grund-

legender Middleware1996: Middleware von Legion, 2000: Unicore1999: Massives Auftreten der Grid VisionIn Europa entstand das EU DataGridAndere: NASA-IPG, CrossGrid, GridLab, PPDG, Alliance, ..

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!

Das EDG aus Benutzersicht

GridElements

Status des LCG

Zur Anzeige wird der QuickTime™ Dekompressor „TIFF (Unkomprimiert)“

benötigt.

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)

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)

Zusammenspiel SAM/EDG

SAM Station EDG Storage Element “classic” EDG UI machine

Back-end RAID disk array

NFS Mounts

ReplicaLocationService

Neu: SAM-client mode macht Hilfskonstruktion überflüssig

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

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

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

Struktur des EDG-Brokers

job-submitlist-job-matchjob-cancelget-job-outputget-logging-info

User Interface

Ressource Broker

job-submitlist-job-matchesjob-cancelJob-get-output-sandboxnotify

job-submitjob-cancel

Job Submission ServiceLogging & Bookkeeping

LogEventQueryJobLogJobStatusClearJob

Computing Element

Workload Management

Schnittstellen

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

Kurzfristige Lösung

• Einrichten zusätzlicher RBs für jede VO einen eigenen RB.

CE

CE

CECE

CECE

CECE

CECE

CE

CE

RB

RB

RB

D0

Atlas

CMS

UI

UI

UI

UIUI

UI

UI

UI

CE

CE

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

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

Mögliches SzenarioClient

OGSI/SOAP

Container

OGSI/SOAP

Container

OGSI/SOAP

Container

OGSI/SOAP

Container

RB-AgentEDGRB

EDGRB

EDGRB

RB

Client A

PI

RB-Agent

RB-Agent

1. Create Service2. Put in Tuplespace3. Free agent takes request4. Submit job

1

Information Tuplespace

{Request Tuple}

2

3

4

{Response Tuple}

5

6

7

8

5. Set Response Tuple6. Available Container will get Response7. Job Handle8. Further Job Communication

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)

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önnenJobs müssen abgebrochen werden könnenStatus der Ausführung muss ermittelbar seinOutput eines zu Ende gelaufenen Jobs muss abrufbar sein.

Anforderungen an das Job Management

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

Realisierung

Eine webbasierte Applikation mit Java Servlet TechnologieServlets generieren HTML SeitenDesign der HTML Seiten wird durch Style Sheets beschriebenBenutzerhistory wird in XML abgelegtSchnittstelle zu DataGrid „Globus API“ und „WMS API“Location: User InterfaceWebserver - Plattform: Apache Tomcat 4.1(ist bereits installiert)

Klassendiagramm

Hierarchische Aufbau der HTML Seiten

Status

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

implementiert.

TODO

• Authentifizierung durch im Browser installiertes Zertifikat

• Verwaltung der benutzerspezifischen Informationen

• Job- und Datenmanager entwerfen und realisieren

• Dokumentation

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!