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