Dezentrale Datenproduktion und -analyse bei DØ

Transkript

1 Dezentrale Datenproduktion und -analyse bei DØ Thomas Nunnemann LMU München DPG Mainz Computing: Aufgaben/Anforderungen Datenaustausch verteilter Datenbankzugriff Prozessierung von Datenereignissen Ausblick Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

2 Computing in DØ: Aufgaben/Anforderungen MC Produktion Datenproduktion Datenanalyse input (pro event) keiner 250 kb 25 kb output (p.ev.) 800 kb 250 kb gering Rechenzeit (p.ev) 1 min 8 s 0.1 s (Xeon 2.3 GHz) (abh. von Kanal) I/O Anforderung gering hoch sehr hoch (lokal auf Knoten) (zentral, Paralleljobs) (zen., P.j.) Datentransfer (FNAL GridKa) Datenbank-Zugriff nein ja (für Rohdaten) teilweise Sample, gesamt 60M 500M 70k-170M pro job/file k Komplexität Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

3 Datentransfer via Mass storage (router) Fermilab Remote Region A (router) Mass storage Grid von verteilten Stationen File-Kopie Zugriff über optimale Route Datentransfer mit gridftp (Globus) (Sequential Access through Meta-data) beinhaltet: Daten-Katalog, optimierter Zugriff auf files, Buchführung Definition von Datensets über Meta-Daten z.b. Datenformat, Selektion, Kanal, Produktionsversion Übersetzung in Liste von files (Zugriff-optimierte Reihenfolge) effektive Transferrate (für DØ) zwischen FNAL und GridKa: 200 GB pro Tag Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

4 Dezentraler Datenbankzugriff Neben den Ereignisdaten (Rohdaten, DST, micro-dsts, root-tree) benötigen Datenproduktion und -analyse zusätzlich Informationen, die sich nicht auf einzelne Ereignisse beziehen: Run basiert: Kalibrationsdaten der einzelnen Subdetektoren Konfiguration (z.b. Magnet) bezogen auf kleineren Abschnitt (entspricht etwa 1 min) für Luminositäts-System relationale Datenbank (Oracle) verteilter Zugriff über Proxies Kalibrationsdaten file basierte Datenbank für Luminositäts-System Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

5 Funktionsweise des Datenbank-Proxys Proxy: bereits erfolgte DB Abfragen werden lokal gespeichert (cache) vergleiche Web proxy/cache Anzahl der Zugriffe auf zentrale Oracle Datenbank wird minimiert. reduzierte Abhängigkeit von (nicht-lokalen) Netzwerk: kürzere Abfragezeiten, ausfallsicherer Client Network (local) C++ Cache Server Kommunikation über CORBA Mehrstufiger cache: Client Python DB Server C++ Cache Server Python DB Server Network (remote) Oracle DB C++ server (RAM): schneller und kompakter (benötigter Speicherplatz) Python server (RAM und disk) Network (local) Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

6 DB Proxy am GridKa Erstinstallation für DØ am GridKa Motivation: geplante Produktion von Rohdaten Erfahrung, Optimierung der Konfiguration, Lasttests Prototyp für weitere Installationen im DØ Grid schnellere DB Abfrage: z.b. Zeit um ein Kalibrationsdatensatz für Silicon Tracker (800k Kanäle) zu erhalten: vom Fermilab: 720 s vom lokalen Python server: 60 s vom lokalen C++ server: 45 s Extensive Tests am GridKa: DB server kann mehere hundert parallele Rekonstruktions-Jobs problemlos bedienen. Einschränkungen: caching von potentiell sich ändernde Parameter unmöglich Kompatibilität mit Grid bei dynamischer job-submittierung (EDG/LCG)? Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

7 Reprozessierung von DØ Daten Motivation für Reprozessierung (zusätzliche Datenproduktion): signifikante Verbesserung des Rekonstruktionsprogramms (insbesondere tracking: alignment, clustering, track finding) großer konsistenter Datensatz ( 200 pb (Zeitvorgabe: Winterkonferenzen) ) Vollständige Produktion aller aufgenommenen Daten bis M events, jeweils 100 TB input und output, 300 GHz-Jahre Rechenzeit FNAL: 80%, 5 verteilte Rechenzentren (F, GB, D, CDN, NL): 20% davon 20% am GridKa (setup, Optimierung und Durchführung durch LMU München) Technische und organisatorische Herausforderung: keine eigenen CPUs außerhalb FNAL (Konkurrenz: LHC, Barbar) Datentransfer, Zertifizierung, global book-keeping offsite reprocessing von DSTs (noch fehlende DB Proxies) Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

8 Datenproduktion am GridKa Import von DST Daten FNAL 5 TB, Transferrate: GridKa via 200 GB pro Tag pre-staging für verbesserte Effizienz, on-demand Lieferung auch möglich Semi-automatische Job-Submittierung (runjob, DØ und CMS) software releases auf dedizierter head node dynamischer Daten-input via I/O über paralleles file system (GPFS, IBM) bis zu 300 parallele Rechenjobs (keine I/O Limitierung) book-keeping, Tests auf Datenintegrität automatische Definition von Datensets für fehlgeschlagende jobs Resubmittierung Export der rekonstruierten Daten (micro-dsts) zum FNAL, lokale Speicherung der DSTs Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

9 Datenproduktion am GridKa: Ergebnisse/Erfahrungen million events per day Produktionsrate: 1M events/tag (bei freien Resourcen) insgesamt 21M events in 6 Wochen Produktionsl ücken aufgrund technischer Probleme day Limitierungen, Probleme: global: Datentransfer-Engpass: FNAL enstore (tape Roboter) Ausfall (kein redundantes Ersatzsystem) lokal: Fehlerquote: 16% der jobs vollständige Automatisierung oder job-ablauf im Grid nicht praktikabel hauptsächlich Probleme mit NFS und GPFS Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz

10 Fazit und Ausblick DØ-Computing: hohe Anforderungen an CPU und I/O für Datenproduktion und -analyse Datenaustausch realisiert über und Datenbank Proxies Erfahrungen durch umfangreiche Reprozessierung von DØ Daten demnächst: Datenproduktion von Rohdaten ( Datenbank) Thomas Nunnemann, Dezentrale Datenproduktion und -analyse bei DØ, DPG Mainz