M. Feindt, U.Kerzel, Th. Kuhr, M. Milnik, T. Müller, G. Quast Universität Karlsruhe Grid-computing bei CDF

März 2006Michael Milnik - DPG Dortmund2 Warum Grid bei CDF Wachsende Datensätze Simulation: offizielle und private (re-)Prozessieren der Daten ! Eine große, zentrale Farm reicht nicht mehr ! Signifikante Resourcen außerhalb vom Fermilab Aber: Datennahme läuft schon lange Design-, Entwicklungs- und Testphase gleichzeitig Benutzer nicht an Grid-Entwicklung interessiert

März 2006Michael Milnik - DPG Dortmund3 CDF Resourcen siteCPU/GHzdisk/TB CAF (FNAL) Italy48032 Korea Taiwan San Diego Rutgers Toronto Japan Spain501.5 MIT GridKa215(4270)40.0/80.0

März 2006Michael Milnik - DPG Dortmund4 Grid Grundidee: Benutzer gibt vor: Programm, Datensatz, etc. Benutzer bekommt:ntuple, Plots, etc. ! Grid kümmert sich um den Rest: wo am besten gerechnet wird Datenbereitstellung etc. Analogie zum Stromnetz: versteckte Komplexität vor Benutzern

März 2006Michael Milnik - DPG Dortmund5 Weg zum Grid für CDF Ansatz: Starte mit funktionierendem Systemen und migriere zum Grid Central Analysis Farm: CAF ausserhalb FNAL: MC Production Klon der CAF falls 100% CDF Resourcen Migration: 1. SAM: zum Verwalten der Daten 2. Frontier: zur Entlastung der DB 3. GlideCAF: CAF Interface, aber weltweit einsetzbar

März 2006Michael Milnik - DPG Dortmund6 Beispiel GridKa GridKa: Deutsches Grid Kompetenzzentrum 8 Experimente (LHC, BaBar, Tevatron, Compass) Tier1 für LHC, TierA für BaBar 1 Vorrechner/Ex., Farm für alle Vorteil: Freie Resourcen können von anderen Experimenten genutzt werden (z.B. zwischen LHC data- challenges) Aber: nur bei gleichem Aufbau der Farm für alle möglich nominell Beispiel

März 2006Michael Milnik - DPG Dortmund7 SAM Sequential Access via Metadata = SAM einzelner Datensatz enthält viele tausende Dateien ! automatisches System SAM: Metadaten steuern Auswahl der Daten transferiert Daten zum Job Integriert in CDF Analyseumgebung AC++ (auch Python-, shell-, ROOT- und C++Interface)

März 2006Michael Milnik - DPG Dortmund8 : SAM SAM verwaltet Datenzugriffe: langsame Bänder via dCache schnelle Zugriffe via Netzwerk auf Festplatten automatisches Kopieren automatisches Speichern importierte Datensätze auf Band unabhängiger vom FNAL komplette Analyse am GridKa: Quanten Zahlen des X(3872)

März 2006Michael Milnik - DPG Dortmund9 : Frontier Jeder CDF Job kontaktiert zentrale DB (Kalibration, etc) ! Latenzzeiten, etc. verlangsamen Analysen ! Datenbank Proxy: Frontier basierend auf Squid: Web Proxy Cache lokaler Cache: keine Verbindung zum FNAL nötig einfache Installation und Betrieb im userspace ! sehr gute Erfahrung bei CDF trotz späterer Integration ! Weiterentwicklung und Integration bei LHC

März 2006Michael Milnik - DPG Dortmund10 : GlideCAF Letzter Schritt zum Grid: GlideCAF GlideCAF genauso zu benutzen wie CAF Enduser bemerkt kaum einen Unterschied CAF kein Cluster mehr, nur noch Portal Globus Tools des lokalen Clusters werden genutzt Job startet auf WN via Condor Glide-Ins ! keine spezielle Installation im Cluster nötig, nur ein Portal

März 2006Michael Milnik - DPG Dortmund11 : GlideCAF 1. Job startet auf WN 2. Condor deamon wird gestartet 3. Deamon meldet sich zurueck ! WN wird Teil des Condor Pools 4. Job wird geladen und ausgeführt Glide-Ins:

März 2006Michael Milnik - DPG Dortmund12 Zusammenfassung CDF Gruppe am GridKa entwickelt sich mit dem Experiment ¼ 500TB Daten analysiert SAM seit über 2 Jahren im Produktionsbetrieb Frontier seit über einem Jahr in Benutzung GlideCAF wird gerade aufgesetzt CDF hat signifikante Resourcen ausserhalt FNAL: GridKA und Italien am aktivsten CDF hat sich vom zentralen System zum Grid während es läuft entwickelt. Physik Analysen sind nicht mehr ans FNAL gebunden