Vorlesung: glite: Eine Grid Middleware für die HEP.

Transkript

1 Vorlesung: glite: Eine Grid Middleware für die HEP. Yves Kemp DESY IT FHTW Berlin

2 Was erwartet Sie die folgenden 60 Minuten? > HEP: Hoch-Energie-Physik (ein anderer Name für Teilchenphysik) Ein kurzer Einblick in die Welt der kleinsten Teilchen Die Methoden der Physiker Und was das mit Datenverarbeitung zu tun hat > Grid: Ein neues Paradigma im verteilten Rechnen Der prinzipielle Aufbau der Grid-Infrastruktur Was ist Middleware? > glite: Eine (hauptsächlich) in Europa entwickelte Middleware Typischer Workflow Support! > Die Vorlesung hat 90 Minuten: Unterbrechen Sie mich bitte bei Fragen! Yves Kemp glite: Eine Grid Middleware für die HEP Page 2

3 Die Natur und ihre Skalen m 10 7 m 10 1 m 10-5 m 10-9 m m Yves Kemp glite: Eine Grid Middleware für die HEP Page 3

4 Hoch-Energie-Physik > Wieso wird die Teilchenphysik auch Hochenergiephysik genannt: > Eine falsche aber einleuchtende Erklärung: Weil man grosse Maschinen und grosse Energiemengen braucht, um Experimente zu machen > Die korrekte Antwort lautet: Die umgesetzte Energie ist, im Vergleich zur Masse der physikalischen Teilchen sehr hoch Yves Kemp glite: Eine Grid Middleware für die HEP Page 4

5 Ein Beschleuniger: Der LHC Large Hadron Collider Umfang: 27 km Strahl-Energie: 7 TeV (Proton Proton) (Energie ~ Aufprall einer Fliege!) Unterirdisch: 100 m Temperatur: -271 C Energieverbrauch: 1 TWh/a (Vergleich: Kernkraftwerk ca 10 TWh/a (~1.2GW)) 4 grosse Experimente: CMS LHCb CERN (bei Genf) Yves Kemp glite: Eine Grid Middleware für die HEP Page 5 ATLAS ALICE

6 Zwei Experimente: CMS: Compact Muon Solenoid & ATLAS Gewicht: 12500T Durchmesser: 15 m Länge: 21.5 m Magnetfeld: 4 Tesla Gewicht: 7000T Durchmesser: 25 m Länge: 46 m Magnetfeld: 4 Tesla Yves Kemp glite: Eine Grid Middleware für die HEP Page 6

7 Ein paar Zahlen zu den Experimenten: > Atlas & CMS: Beobachten Kollision mit 40 MHz: 24/7 > CMS: 10 Millionen Kanäle Detektor besteht unter anderem aus 200 m 2 Silizium ~1 PetaByte Daten pro Sekunde! Online Reduktion auf 100Hz und 150 Mbyte/s die zur weiteren Analyse gespeichert werden > Heutige Experimente: Geplant, gebaut und betrieben von grossen Kollaborationen: Über 2000 Personen aus vielen Instituten weltweit verteilt! Pro Experiment! > Baukosten: ~500 Millionen Euro / Experiment Yves Kemp glite: Eine Grid Middleware für die HEP Page 7

8 Und nach langer Bauzeit (und Problemen...) Erste ProtonProton-Kollisionen am Yves Kemp glite: Eine Grid Middleware für die HEP Page 8

9 Status: CMS: Heute morgen > Aktuell Proton-Proton Kollisionen: Haupt Arbeitspunkt des LHC > Verbesserung des LHC 2013 geplant > Danach Mitte 2014 dann Datennahme mit voller Leistung mehr als bisher > Erste Physik-Ergebnisse schon erzielt > Hauptsächlich Wiederentdeckungen > Allerdings auch schon ein neuer Effekt > noch ein langer Weg zu Neuentdeckungen! (Higgs-Teilchen) Yves Kemp glite: Eine Grid Middleware für die HEP Page 9

10 Was wird beobachtet? Zwei Bilder von Kollisionen (Simulation, links CMS, rechts Atlas) Hochkomplex, viele Informationen, schwierig zu analysieren Yves Kemp glite: Eine Grid Middleware für die HEP Page 10

11 Von den Daten zur Analyse Delphi Experiment (LEP): Datensatz quasi-statisch (Statisch im diesem Beispiel) Daten werden wiederholt analysiert, unterschiedliche Programme/Versionen ~1000 Publikationen von ~500 Leuten mit ~1TB Daten Wettervorhersage: Neue Daten kommen kontinuierlich, alte Daten nicht mehr benötigt Die gleichen Programme werden zur Analyse neuer Daten benutzt Daten nur selten analysiert Yves Kemp glite: Eine Grid Middleware für die HEP Page 11

12 Welche Arten von Computing? CPU Bedarf Theorie- Rechnung Analyse User A Detektorsimulation Analyse User C Analyse User B Rekonstruktion Analyse User D Datenkonvertierung I/O zum Massenspeicher Yves Kemp glite: Eine Grid Middleware für die HEP Page 12

13 Unterschiedliche Profile, aber: > Die Basiseinheit ist Das Ereignis Alle unabhänig voneinander Trivial parallelisierbar #1 #2 #3 #4 #5 #6 #7 #8 Resultat #4 #8 #3 #2 #7 #6 #1 #5 = = Resultat Verteiltes Rechnen auf verteilten Daten natürlicher Ansatz #1 #4 + #3 #8 + #2 #6 + #5 #7 Res1 Res2 Res3 Res4 Resultat Yves Kemp glite: Eine Grid Middleware für die HEP Page 13

14 Verteiltes Rechen, verteilte Daten? > Wie muss ein Partner organisiert sein, damit er eingebunden wird? > Wir verteilen Daten, aber wohin? Einzelrechner? Rechencluster? Kopien auf einige wenige sehr grosse Zentren? > Wir rechen verteilt, aber wer sind die Partner? Einzelrechner? Rechencluster? Einige wenige sehr grosse Zentren? Yves Kemp glite: Eine Grid Middleware für die HEP Page 14

15 Das einzelne Ereignis ist einfach, aber: > Die Summe machts: Grosse Datenmengen schwer handhabbar Grössere Zentren (Absolutes Minimum z.b. 100CPU, 50TB, 1Gbit) > Physiker erwarten einen hohen Grad an Zuverlässigkeit Verfügbar ~24/7 Support muss nicht 24/7 sein, aber Prozeduren müssen klar sein ( Service Level Agreement ) > Es gibt unterschiedliche Anforderungsprofile Zentren unterschiedlicher Grösse erledigen unterschiedliche Aufgaben mit unterschiedlichen SLA LHC Tier Modell Yves Kemp glite: Eine Grid Middleware für die HEP Page 15

16 Das LHC Tier Modell Yves Kemp glite: Eine Grid Middleware für die HEP Page 16

17 Grid keine Erfindung der HEP: > Foster & Kesselmann coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations " the ability to negotiate resource-sharing arrangements among a set of participating parties (providers and consumers) and then to use the resulting resource pool for some purpose. > Checkliste Grid (Ian Foster) Computing Ressourcen nicht zentral administriert" Offene Standards werden benutzt" Nicht-triviale Quality of Service" Yves Kemp glite: Eine Grid Middleware für die HEP Page 17

18 und die Cloud? > Cloud ist das Buzzword der vergangenen Jahre in IT > XaaS: Platform, Software, Infrastructure, Grid kann als Platform as a Service angesehen werden Es gibt zwei Bestrebungen: > Grid an die Cloud annähern Virtualisierung auf den Rechner ermöglichen, eigene VMs zu starten Grundlegende Middleware wird dann immer noch Grid sein > Cloud in die Produktions-(Grid)-Infrastruktur integrieren Experimente haben Frameworks um Jobs zu verwalten Diese Frameworks lernen jetzt vermehrt auch, mit Clouds zu sprechen Cloud benutzen für Peak-Loads > Ausschliessliche Nutzung kommerzieller Clouds unrealistisch Noch keine Datenhaltung in der Cloud: Zu teuer, zu langsam, zu unflexibel > Sicherheitsaspekte in kommerziellen Clouds unklar > Akademia: Föderationen von Clouds m.m. nichts anderes als Grid Yves Kemp glite: Eine Grid Middleware für die HEP Page 18

19 Middleware > Die Middleware hält das Grid zusammen Die spezifische Applikation" ALICE, ATLAS, CMS,LHCb! BioMed! Other apps! Ressources auf der Gegenseite" High level GRID Middleware" Grundlegende Services" OS & Net services (Linux)" Authentisierung Authorisierung Dateitransfer Informations System Job Ausführung Yves Kemp glite: Eine Grid Middleware für die HEP Page 19

20 Middleware (2) > Implementiert Standards, welche die Zusammenarbeit der einzelnen Komponenten beschreiben > Unterschiedliche Implentierungen, für die HEP relevant: Globus Toolkit (Globus Consortium) glite (EGEE, EU) OpenScienceGrid (USA) ARC (Nordeuropa) > Im Folgenden werden die einzelnen Komponenten und deren Zusammenspiel anhand der glite Middleware erläutert > Im Praktikum werden wir die glite Middleware benutzen > Neue Initiative European Middleware Initiative EMI Vereinheitlichen einiger europaeischer Middlewares, und bessere Verbreitung Yves Kemp glite: Eine Grid Middleware für die HEP Page 20

21 Zugang zum Grid: Zertifikate Yves Kemp glite: Eine Grid Middleware für die HEP Page 21

22 Authentisierung/Authorisierung > Authentifizierung: Wer bin ich? Welcher Institution gehöre ich an? Wer bestätigt diese Angaben? Vergleichbar mit Reisepass > Authorisierung: Was darf ich? Welcher Organisation gehöre ich an? An welchen Projekten arbeite ich? Was darf ich machen? Wo darf ich das machen? Vergleichbar mit Visum Yves Kemp glite: Eine Grid Middleware für die HEP Page 22

23 Zertifikate: > Basiert auf asymetrischer Verschlüsselung Benutzer erstellt privaten und öffentlichen Schlüssel Öffentlicher Schlüssel an Zertifizierungsstelle (CA) > CA erstellt ein X509 Zertifikat mit: Öffentlicher Schlüssel des Benutzers Seiner Identität (Name, Institut ) Informationen über die CA Digitale Unterschrift > Verfahren ähnlich für Rechner, die Dienste anbieten Jedes Zertifikat ist an eine Person gebunden Benutzerzertifikate sind an Ausweise gekoppelt Yves Kemp glite: Eine Grid Middleware für die HEP Page 23

24 Authorisierung? Im Grid? > Zertifikat (Schlüsselpaar) langlebig: 1 Jahr Erzeuge ein Proxy von begrenzter Gültigkeit (O(Tag)) Proxy wird bei jeder Aktion ausgewertet > Authorisierung mittels VOMS Virtual Organisation Management System VOs bringen Leute aus einem Projekt zusammen Jede VO kann Rollen und Untergruppen definieren Jeder Benutzer kann mehreren VOs angehören Ein Anbieter kann mehrere VOs unterstützen > Der Benutzer agiert nicht als Person, sondern als Mitglied einer VO! Yves Kemp glite: Eine Grid Middleware für die HEP Page 24

25 Im Praktikum > Ich habe für jeden Teilnehmer ein Zertifikat beantragt (Dank an CA in Karlsruhe!) > Jedes Zertifikat ist in der VO DECH registriert (Dank an VO- Management!) VO DECH: Unter anderem Schulungs-VO > Die Zertifikate liegen auf einem Server (User Interface) in Hamburg Dort ist auch spezielle Software installiert > Jeder Teilnehmer erhält Unterlagen zum Einloggen > Zertifikate sind generisch, allerdings besteht eine Zuordnung Teilnehmer Zertifikat > D/CH Teil des Produktions-Grids der HEP! Yves Kemp glite: Eine Grid Middleware für die HEP Page 25

26 Jetzt haben wir Zugang zum Grid: Wir können einen Job losschicken Welche Grid- Komponenten werden wir antreffen? Yves Kemp glite: Eine Grid Middleware für die HEP Page 26

27 Ein einfaches Beispiel: Yves Kemp glite: Eine Grid Middleware für die HEP Page 27

28 Woher weiss das WMS alles? Unterschiedliche Zentren bieten unterschiedliche Dienste an (CPU, Storage, Software) Jedes Zentrum beschreibt sein Angebot Der Status der Zentren wird kontinuierlich überprüft Das Informationssystem ist die Intelligenz des Grid! Yves Kemp glite: Eine Grid Middleware für die HEP Page 28

29 Wenn das WMS entschieden hat: WMS sendet den Job zum Zielort Interface zwischen Grid und den CPU-Resourcen der lokalen Site ist das Computing Element (CE) Das CE rechnet selber nicht! Das CE wird: Mich auf dem lokalen Clustern einen lokalen Benutzer zuordnen Meinen Job in die lokale Batch Queue stecken Der Job wird auf einem Worker Node gerechnet Priorität mittels lokaler Regeln ( 50% VO X, 30% VO Y, 20% lokale Benutzer ) Den Status des Jobs verfolgen und nach aussen weitergeben Das Resultat (Output Sandbox) an den RB schicken Yves Kemp glite: Eine Grid Middleware für die HEP Page 29

30 Rechnen mit grossen Datensätzen? > Entweder als Input Experiment Daten, Genom Databank, Kundendaten, > oder als Output Monte Carlo Simulationen, kondensierte Daten,. Storage Element (SE): > Speichert die Daten nicht selber! > Interface zwischen Grid und lokaler Infrastruktur Fileserver, Serverpool, Bandlaufwerk Datensicherheit und Alloziierung: Lokale Regeln > Sowohl vom Grid als auch lokalem Worker Node erreichbar > SE muss unter Umständen im Job spezifiziert werden: Das nächste beim WN, mein Institut, grosses Zentrum... Zugriff mittels Grid-Befehlen oder eingebaut in Programme (API) Yves Kemp glite: Eine Grid Middleware für die HEP Page 30

31 Mehr zur Datenhaltung: > Dateiname im the Grid: Global Unique Identifier (GUID) LFN LFN LFN guid:3a69a a2a1-f581ab > Einfacher mit Logical File Name (LFN) GUID lfn:/grid/myexp/kemp/exitingdataset.dat lfn:/grid/myexp/myboss/datawithbaddetector.dat PFN PFN PFN SE SE SE > Physical File Name (PFN) Konkreter Pfad auf einem SE /storage/grid/experiments/cms/kemp/ver04/run2342/results/data/file124.dat Dateien können auf unterschiedliche SE repliziert werden (besserer Zugriff) > Datei-Kataloge verwalten diese Informationen Yves Kemp glite: Eine Grid Middleware für die HEP Page 31

32 Zugriffsberechtigung: VO > VO ist Zusammenschluss unterschiedlicher Leute die an gleichem Projekt arbeiten > Nicht jeder soll alles machen können: Medizin: Student soll nicht an die Patientenakten Meteorologie: Nur Datamanager soll Daten kopieren HEP: Nur Softwaremanger soll Software installieren > Innerhalb einer VO gibt es unterschiedliche Rollen und Gruppen mit eigenen Zugriffsrechten Der Benutzer kann beim Erstellen des Proxys die aktuelle Rolle/ Gruppe aus verfügbaren auswählen Yves Kemp glite: Eine Grid Middleware für die HEP Page 32

33 Monitoring und Support > Ein Produktivsystem muss überwacht werden > Alle Akteure in einem Produktivsystem in einer Supportstruktur > Monitoring: Funktional-Tests aller Komponenten Aufzeigen der Testresultate, Aktionen bei Probleme SAM (Service Availability Monitoring): Periodische Tests > Benutzer Support: Benutzer Training Einfacher Zugang zu unterschiedlichen Informationen Applikationen: Integration und Support Tagtäglicher Support fuer Benutzer im Grid: Daten, Rechen, Netzwerke, VO spezifische Probleme Yves Kemp glite: Eine Grid Middleware für die HEP Page 33

34 Zusammenfassung > Hochenergiephysik: Sehr hohe Anforderungen an Computing > Grid wichtiger Bestandteil des Computing in der HEP HEP Vorreiter im Grid Computing > Grid komplexe Infrastruktur Monitoring und Support wichtiger Bestandteil der Infrastruktur Verschiedene Middlewares noch in der Entwicklung Integration und Interoperabilität > Keine graue Theorie: Wird produktiv in allen Analyse-Schritten eingesetzt! Yves Kemp glite: Eine Grid Middleware für die HEP Page 34

35 Ausblick auf das Praktikum > Physik-Analyse! > Wie fragt man das Informationssystem ab? > Wie kann man einfache Jobs losschicken? > Wie werden Daten gehandhabt? > Wir funktioniert ein etwas komplizierter Job mit Daten? > Worauf muss man bei solchen Jobs aufpassen? > Sie bewegen sich auf dem deutsch-schweizerischen Teil des LHC-Grids Sie sind nicht alleine Sie bekommen Login-Informationen, bitte geheim halten Zugang nur zu Kurs-Zwecken benutzen! Yves Kemp glite: Eine Grid Middleware für die HEP Page 35

36 und vielleicht ausserhalb dieses Praktikums? > DESY betreibt wissenschaftliches Rechnen auf vielen Gebieten > Betrieb großer Infrastrukturen (Rechenleistung, Dienste, Massenspeicher), Weiterentwicklung der eigenen Infrastruktur Z.B. verbessertes Monitoring, automatisierte Fehlerbehandlung, Performance-messungen und Verbesserungen, Scheduling, > (Weiter)Entwicklung des Speicherproduktes, welches die meisten Daten im LHC-Grid speichert: dcache Entwicklung, Performancemessungen und Verbesserungen, > Softwareentwicklung für ILC: Ein zukünftigen Beschleuniger > Data preservation and long term analysis > Aufkommend: Neue Communities (Lichtphysik ), neue Probleme und Herausforderungen (MPI, GPU, ) > Interesse? Sprechen Sie Herrn Hessling an! Yves Kemp glite: Eine Grid Middleware für die HEP Page 36

37 Mehr Informationen: > Bietet einen Einstieg ins Grid, insbesondere glite Middleware. > Zum LHC: Yves Kemp glite: Eine Grid Middleware für die HEP Page 37