Bericht des GridKa Technical Advisory Boards 1 Inhalt: Günter Quast & Christian Zeitnitz, 19.7.'07 Aktivitäten der Experimente Jan. - Jun. '07 TAB Empfehlungen: - Administratoren der Experimente - zukünftige Struktur des TAB - Problematisches Quellen: - Experimentberichte TAB Jun. '07
CPU-Nutzung 2 LHC-Experimente Hauptnutzer der CPU Deutliche Zeitabhängigkeit der Nutzung durch einzelne Experimente Sehr gute Auslastung: Zahl der wartenden Jobs typischerweise sehr hoch
Datenspeicher dcache dcache-nutzung (LHC- Exp.: hauptsächlich SRM-Interface in dcache ) 3 Problem: Verfügbarkeit des MSS!
Alice @ GridKa 4 GridKa liegt gut im Vergleich mit anderen T1-Zentren GridKa (grün) dritt-größter Beitrag Nov'06-Jun07 GridKa share among all ALICE sites: 8.2%
Alice @ GridKa (2) 5 (-) GridKa RB zu langsam (2 min. submission time; Standard etwa 8-15 sec.) RB Probleme: timeout bei edg-job-submit Grid Information System hatte erhebliche Stabilitätsprobleme (+) Deutlich besser seit der letzten Maintenance. (-) häufige NFS Blockaden auf VO-box (+) ALICE software directory am GridKa lief voll, mehr Plattenplatz sehr schnell bereit gestellt. Danke für die gute Zusammenarbeit mit GridKa
TAB Kontinuierliche Teilnahme an MC Produktion (GridKa + assoziierte T2) Ca 190,000 Jobs, 28,000 CPU Tage, 82% Effizienz ATLAS@ GridKa 6 Seit Ende 2006 systematisches Replizieren der weltweit produzierten Daten -> GridKa + T2s mittels ATLAS DDM System Ca 1.5 M Files, 80 TB bei GridKa Parallel weitere Tests zu Stabilität und Performance T0 T1 Transfers: Nominneller Durchsatz (90 MB/s) erreicht und für 1 Tag um Faktor 2 übertroffen Speicherplatz: Krise bei ATLAS Frühjahr 2007: - Deutlich mehr Platz nötig als geplant. Fast alle ATLAS T1 voll März/April. - GridKa ebenfalls für ca. 2 Woche blockiert. Schnell gelöst durch vorzeitige Bereitstellung der Ressourcen für Juli'07 (VIELEN DANK!) Momentan ausreichend Kapazität (280 TB Disk), aber kritisch bis April'08. Verzicht auf LHC Pilot-run bewirkt keine Reduktion des T1 Resourcen Bedarfs: Stattdessen ausgiebige Cosmic Runs für Commissioning, Datentransfers T1/2 Weitere T1-Tests zu Tape -I/O, re-processing, ESD Analyse u.a. dringend erforderlich. Ca. 40 TB in dchace verfügbar, ausreichend für momentanen Betrieb/Tests
ATLAS (2) GridKa und assoziierte Tier-2s 7 7 (von 9) ATLAS-Tier-2s-Sites@GridKa sind voll in Produktion und Datenmanagement integriert. 2 Sites fehlen wg. Manpower für Support, aber seit kurzem gelöst. Dedizierte Tests zu Datentransfer und Daten-Replizierung zwischen GridKa und assoziierten T2's erfolgreich: GridKa Unterstützung für zentrale Services wie dcache-storage und Filetransfers verbessert in den letzten Monaten Service nach wie vor kritisch an Wochenenden, Brückentagen, Ferien wiederholt mehrtägige Ausfälle GridKa ist zentraler Service für die gesamte 'ATLAS-GridKa-Cloud', wenn GridKa ausfällt, steht i.w. ATLAS-Betrieb in allen Tier-2
TAB ATLAS - Manpower 6 BMBF Stellen für ATLAS-spezifische Services bei GridKa und Tier-2 Es war sehr schwierig, die Stellen zu besetzen: Bewerber mit guten Erfahrungen gibt es praktisch keine. Alternative sind Post-Docs mit wenig Computing Hintergrund oder Aufsplitten der Stellen und Einbeziehen von Doktoranden. Mittlerweile (1.7.2007!) i.w. alle Stellen besetzt, aber teilweise noch erhebliche Einarbeitungszeit erforderlich Aufgaben verteilt auf: T-1 Support T-2 Support, data management, production, monitoring und user Support Mailing-Liste, Meetings, Wiki Seiten, etc, eingerichtet John Kennedy (LMU) als Cloud operations manager Kritischer Punkt ist Tier-1 Support, ATLAS Kontakt-Person bei GridKa Übergangslösung 1.HJ: D. Meder (Wuppertal), erfahrener Grid-Experte Seit April, S. Nderitu (BN), in Einarbeitung. 8
CMS@ GridKa 9 CMS nutzt GridKa sehr intensiv: - MC Produktion und Daten-(Re)-Prozessierung - Transfer-Tests T0 T1, T1 T1, T1 T2 mit PhEDEx - Vorbereitung CSA '07 ( 50% challenge ) Erfahrungen: Licht & Schatten Transfers T0 T1
CMS (2) 10 Export von GridKa zu oft fehlerhaft häufig Problem des empfangenden Endes! Transfers zu T0, anderen T1 und DESY, RWTH Aachen und CSCS (Schweiz) funktionieren aber prinzipiell! Hauptproblem der letzten Monate: - zu geringer Platten- Cache vor Band- Speicher führte zu time-outs beim Daten-Export Umorganisation des MSS und der Disk- Chaces seit letztem Monat noch im Gang. Deutliche Verbesserung erwartet!
CMS (3) GridKa aüßerst sichtbar bei MC-Produktion drittgößter Beitrag (aber eigentlich eine T2-Aufgabe) 11 Gespeicherte MC-Ereignisse pro CMS-Site - RWTH-Beitrag gut sichtbar; - DESY wegen Umorganisation des dcache-systems mit kleinem Beitrag
CMS (4) Stellensituation: - nahezu alle Computing-Stellen besetzt; 1+1/2+1/2 Tier1 (Karlsruhe), 3 T2-Stellen Aachen und Uni Hamburg; 1 FTE CMS core-beitrag im Bereich der zentralen MC-Produktoin - gemeinsame Überwachung zentraler Services an allen Zentren, auch mit CSCS (login über VO-Box, zentrale Software-Installation, PhEDEx, Site-Configuration etc.) CMS Resource Request update : CMS Pledged New request 2006 (Jul) 2007 (Jul) 2008 2008 new 2009 2010 CPU 220 620 1260 1200 1800 3400 Disk 120 330 650 650 1000 1500 Tape 180 500 900 1280 2000 3000 % of 2008 18/18/20 52/51/55 100 150/154/220 280/230/330 WAN 800 Numbers in magenta: rebalanced CMS request for 2008 (CRB, July 2007): - includes 250 TB of tape for local backup of imported data sets (low bandwidth, allows local handling of potential disk failures) - change will be included in next version of LCG Mega-Table 12 CMS CRB 17. Juli '07 Bitte an OB um Mittel-Zusage für Beschaffung der Medien!
LHCb @ GridKa 13 Gridka Gute Zusammenarbeit LHCb Gridka! + wichtiger Beitrag zu LHCb MC-Produktion (TIER-2 Aufgabe) - grundsätzlich Probleme mit vielen (> 400) simultanen Jobs massive Probleme bei Rekonstruktion (TIER-1 Funktion) Zugriff auf Tapes zu langsam - Timeout nach 24h! * beginnendetier-2 Aktivitäten der deutschen LHCb Gruppen Universitäten, (DESY/Zeuthen) und MPI
BaBar 14 einige Personen haben Experiment verlassen z.zt nur ein TAB Vertreter (Miriam Fritsch) Hauptaktivitäten: Skimming, MC (ca. 5% aller Ereignisse) und Datenanalyse Keine nennenswerten Problem am GridKa. Anpassung der Software an SL4 führten zur nicht-nutzung von Ressourcen Import von ca. 1TB / Tag Teilweise Probleme am SLAC mit Datenexport
@ GridKa 15 MC und n-tuple Produktion sehr erfolgreich am GridKa CDF profitierte von ungenutzten Ressourcen anderer Experimente Lese-Zugriff auf Bänderetwa einen Monat lang nicht möglich Hohe Zuverlässigkeit der CPUund Disk-Resourcen am GridKa hat zu verstärkter Nutzung geführt Übernahme von Teilen der offiziellen MC-Produktion
CDF (2) 16 Datenvolumen der Tevatron-Experimente wächst weiter sehr stark an (bisher Faktor ~2 pro Jahr). Datennahme bis Ende 2008 (evtl. sogar 2009). Zur Zeit hoher Output an Physik-Resultaten. Weitere Daten- und rechenintensive Analysen (wie z.b. CP-Verletzung im B s -System) in Karlsruhe in Arbeit. Ressourcenplanung >2008 bis November
Compass @ GridKa 17 Datenanalyse am GridKa ohne ernsthafte Probleme Reorganisation des Plattenspeichers mit GridKa diskutiert: Verhältnis 40/8 zwischen dcache / NFS
TAB DØ @ GridKa Personalprobleme führten im Frühjahr zu einem Stop der MC-Produktion Neuer Softwareserver wurde mit der neuen SAM Version aufgesetzt Problem mit einem Plattensystem (inkl. Softwarebereich) führte zu weiteren Verzögerungen Leider konnte kein Backup der Partition gefunden werden, obwohl diese als Backup-Partition festgelegt war TAB hat dieses Problem diskutiert und GriKa überprüft in Zusammenarbeit mit den TAB-Vertretern die Backup-Policy Seit Juni ist die MC-Produktion wieder voll im Gange 18
TAB Empfehlungen Members: 2 members per supported experiment - one (senior) computing contact - one software- and computing expert Experiments with large T2 community should nominate T2 contact Only one vote per experiment GridKa is represented by (at least) two persons (GridKa project leader plus one person), additional GridKa persons to be invided depending on the agenda) KET and KHuK each nominate one contact TAB may invite experts (as needed) from major Tier1/2 or from the LHC computing grid (so far, had regular participation of a DESY representative) Meetings: 19 Zukünftige Struktur des TAB Monthly meetings / phone conferences software expert of each experiment must be present At least twice per year or on request by the TAB a full TAB meeting with all members is to be held Ergebnis TAB #59 and #6:
TAB Empfehlungen (2) 20 Administratoren der Experimente - Introduce concept of a Local Experimental Admin ( LEA ) for each experiment - LEA must participate in weekly GridKa operations meetings - can obtain needed rights to aid in the management of experimentspecific services and/or machines - special right permissions to be negotiated with GridKa in each case; TAB will consider conflicting cases; Ergebnis von TAB#59 and #62 Schon erfolgreich für ATLAS und CMS umgesetzt: - Management der VO boxes - Administration der FTS-Kanäle - Änderung der UID für Fehlersuche und Datenmanagement
TAB Empfehlungen (3) Nach wie vor problematischer Punkt: TAB besorgt über den hohen Anteil an Zeitstellen bei mit Ausbau und Betrieb des GridKa befassten Mitarbeitern. Zur Vermeidung der Abwanderung und des damit drohenden Verlustes an Kompetenz und Know-How empfiehlt das TAB eine Erhöhung des Anteils von Dauerstellen auf ein an anderen Zentren übliches Niveau. Unverändet seit dem letzten OB!!! Klare Perspektiven für Mitarbeiter wichtig etwa wie Tenure Track bei Bewährung 21 TAB unterstützt Planungen bzgl. 7/24 support, d.h. vorläufige Verlängerung der gegenwärtigen Regelung. Massenspeichersystem als zentrale T1-Komponente bedarf hoher Aufmerksamkeit (Stabilität, Verfügbarkeit, Leistungsfähigkeit, Backup) Vorschlag zur zukünftigen Struktur des TAB stärkt dessen Aufsichtsfunktion!
Danke! 22 Amtszeit des TAB-Vorsitzenden und Stellvertreters endet im Sept. 2007 Neuwahl im TAB im September / Oktober TAB Vertreter im OB danken für gute Zusammenarbeit! DANK an GridKa Team für erfolgreichen Betrieb Dez. 06 Jul. '07, manchen freiwilligen Einsatz und für gute Zusammenarbeit!