m. feindt, u.kerzel, th. kuhr, m. milnik, t. müller, g. quast universität karlsruhe grid-computing...
TRANSCRIPT
M. Feindt, U.Kerzel, Th. Kuhr, M. Milnik, T. Müller, G. QuastUniversität Karlsruhe
Grid-computing bei CDF
März 2006 Michael Milnik - DPG 2006 - Dortmund 2
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 2006 Michael Milnik - DPG 2006 - Dortmund 3
CDF Resourcen
site CPU/GHz disk/TB
CAF (FNAL) 3200 300.0
Italy 480 32
Korea 178 5.1
Taiwan 134 3.0
San Diego 380 4.0
Rutgers 100 4.0
Toronto 576 10.0
Japan 152 5.0
Spain 50 1.5
MIT 322 3.2
GridKa 215(4270) 40.0/80.0
März 2006 Michael Milnik - DPG 2006 - Dortmund 4
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 2006 Michael Milnik - DPG 2006 - Dortmund 5
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 2006 Michael Milnik - DPG 2006 - Dortmund 6
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 alleVorteil: 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 2006 Michael Milnik - DPG 2006 - Dortmund 7
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 2006 Michael Milnik - DPG 2006 - Dortmund 8
CDF@GridKa : 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 2006 Michael Milnik - DPG 2006 - Dortmund 9
CDF@GridKa : 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 2006 Michael Milnik - DPG 2006 - Dortmund 10
CDF@GridKa : GlideCAF
Letzter Schritt zum Grid: GlideCAF
GlideCAF genauso zu benutzen wie CAFEnduser 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 2006 Michael Milnik - DPG 2006 - Dortmund 11
CDF@GridKa : GlideCAF
1. Job startet auf WN2. Condor deamon wird gestartet3. Deamon meldet sich zurueck ! WN wird Teil des
Condor Pools4. Job wird geladen und ausgeführt
Glide-Ins:
März 2006 Michael Milnik - DPG 2006 - Dortmund 12
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