Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS Claudio Grandi.

Presentazione sul tema: "Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS Claudio Grandi."— Transcript della presentazione:

1 Claudio Grandi INFN Bologna Workshop Commissione Calcolo 12 giugno 2003 Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS Claudio Grandi (INFN Bologna)

2 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 2 Outline Il Computing Model di CMS nel 1999 –MONARC! Combiamenti nel Computing Model di CMS –L’utilizzo di meddleware grid –Il progetto LCG del CERN Data Challenges di CMS

3 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 3 CMS Computing Model ~1999 Software applicativo: –Migrazione a linguaggi Object Oriented (C++) –OODBMS per il data management  Objectivity/DB Data model e analysis model –MONARC (vedi oltre) Architettura –MONARC (vedi oltre)

4 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 4 Monarc Data Model Raw Data Slow control Calibration data Trigger Tag Simulation Data Reconstruction ESD/Rec.Obj. Data Tag Data Selection Anal.Obj. Data AOD (2 steps) Data 1 PB/Year + 0.001 PB/Year? + ~0.5 PB/Year? Input of  Analysis Local DB and/or Histograms Input of  Input of  1.1 PB/Year + 100 GB/Year or 0.1 PB/Year + 100 GB/year  CMS  ATLAS Off-Line Farm (and “other” resources for Simulation) RCs (including CERN) 0.2 TB/Year x 2 using TAG  CMS 20 TB/Year x 2 using TAG 2 TB/Year x 2 using TAG  ATLAS pass1  ATLAS pass2 RC (including CERN) and/or Desktops Huge amount of Data! But negligible for Users (if DB is out of Global Objy DB) By P.Capiluppi Jul 1999

5 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 5 Monarc analysis process DAQ -------------- Raw Slow C -------------- Calibration Reconstruction ---------------------- ESD/Rec. Obj +TAG DB Selection --------------- AOD/Anal. Obj Selection --------------- AOD/Anal. Obj Analysis ------------- Selected AOD/Anal. Obj & TAG DB Analysis ------------- Selected AOD/Anal. Obj & TAG DB Trigger Info x n WG x n Users in the WG 1st time at CERN (then at RC? ==> Parameters? Different WG at different site? ==> Parameters? RC or Desktop? ==> Parameters? 4 times per Year? (per Exp.) Once per Month? (per WG) 4 times per Day? (per User) Raw Data : On Tape, at CERN and at RC ESD/Rec.Obj : On Tape at CERN, on Disk at RC (Including CERN RC) for the samples needed by analysis at a given RC AOD/Anal. Obj : On Disk Selected AOD/Anal. Obj : On Disk TAG DB : On Disk By P.Capiluppi, Jul 1999

6 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 6 Modello di computing: Monarc –Il Modello di Computing e’ basato su due pilastri: Le risorse hardware (incluso il Network), software e “programming” non possono essere basate solo e principalmente al CERN. Distributed ComputingLa dispersione dei partecipanti agli Esperimenti richiede una organizzazione di “collaboration at a distance”, implicando (anche politicamente) un Distributed Computing di portata e complessita’ senza precedenti (anche per gli “Informatici”). commodity[Terzo pilastro!: occorre fare uso il piu’ possibile della realta’ della commodity (budget and availability)] By P.Capiluppi, Jul 1999

7 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 7 Monarc: computing model Tier2 Centre ~1 TIPS Online System Offline Processor Farm ~20 TIPS CERN Computer Centre FermiLab ~4 TIPS France Regional Centre Italy Regional Centre Germany Regional Centre Institute Institute ~0.25TIPS Physicist workstations ~100 MBytes/sec ~622 Mbits/sec ~1 MBytes/sec There is a “bunch crossing” every 25 nsecs. There are 100 “triggers” per second Each triggered event is ~1 MByte in size Physicists work on analysis “channels”. Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server Physics data cache ~PBytes/sec ~622 Mbits/sec or Air Freight (deprecated) Tier2 Centre ~1 TIPS Caltech ~1 TIPS ~622 Mbits/sec Tier 0 Tier 1 Tier 2 Tier 4 1 TIPS is approximately 25,000 SpecInt95 equivalents By H.Newman

8 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 8 Monarc: architettura –Definizione in termini di servizi –Servizi di dati: produzione MC reprocessing eventi produzione ESD/AOD/tags accesso a ESD/AOD/tags bookkeeping –Servizi Tecnici: Database maintenance tools for data services storage management CPU-DB-I/O usage monitoring/policing Documentation By L.Barone, oct 1999

9 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 9 Definizione di Tier-1 e Tier-2 –Un centro regionale tier-1 fornisce tutti i servizi tecnici, tutti i servizi dati per l’analisi ed è in grado di fornire almeno un’altra classe di servizi dati –Un RC tier-1 è dimensionato in rapporto al CERN –Dimensioni iniziali tra il 10 e il 20 % del CERN (singolo esperimento) –100,000 SI95, 150-300 boxes, 100 TB di disco, 0.2-0.3 PB su nastro –Evoluzione nel tempo –Tutti gli ESD/AOD/Tags –Tutte le calibrazioni –Bookkeeping aggiornato –Parte dei Raw Data ??? –Accesso trasparente per gli utenti –Datasets mossi preferibilmente via rete By L.Barone, oct 1999

10 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 10 Definizione di Tier-1 e Tier-2 –Un centro tier-2 è simile a un tier-1 ma su scala minore, fino al 25% di un tier-1 –Dedicato solo all’analisi (tutti gli AOD/tags, frazione degli ESD) –Scambia dati con un tier-1 piuttosto che con il CERN, per ottimizzare il traffico di rete By L.Barone, oct 1999

11 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 11 Definizione del Computing Model 20032004

12 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 12 CMS Computing Model ~2003 Software applicativo: –Migrazione a OO quasi completato Geant-4 è la componente “difficile” –Uso di OO-streaming library su flat files o RDBMS Soluzione quasi comune agli esperimenti LHC Data model e analysis model –Non sono fondamentalmente cambiati. Sono in fase di definizione i dettagli (ad es. dimensione dei dati) Architettura –MONARC, ma con il middleware di grid –Si ricercano soluzioni comuni (LCG)

13 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 13 Uso di grid Dove i tools di grid aiutano nell’implementazione del modello di calcolo: –Meccanismi di autenticazione e autorizzazione comuni –Interfaccia comune a diversis Local Resource Manager Systems –Interfaccia comune a diversi Mass Storage Systems –Unico entry-point verso le risorse –Unico entry-point verso i dati Per l’utente finale, cioè il fisico: –semplificato l’accesso ai dati e alle risorse di calcolo Per il production manager: –accesso diretto ad un maggior quantitativo di risorse (cioè è necessario un numero minore di production managers!) Per il system manager: –maggiore libertà nella scelta delle politiche locali di accesso –maggiore libertà nella scelta di LRSM e MSS (in prospettiva!)

14 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 14 Uso di grid Attenzione a non cadere in facili semplificazioni: –L’utente finale (il fisico) può beneficiare di un maggior livello di incapsulazione (dettagli, quali la locazione delle risorse e dei dati possono essere nascosti) Però: –Per garantire uno sfruttamento efficiente delle risorse, la dislocazione di risorse e di dati deve essere oculata. Utenti selezionati (production managers) devono poter agire direttamente sulle risorse! –Il nostro non è un vero modello provider-client: le founding agencies (INFN!) pagano sia le risorse e la loro gestione, sia i fisici che fanno analisi! Spesso le persone che gestiscono e utilizzano le risorse sono le stesse. –Un modello gerarchico di servizi rimane la chiave per il successo del sistema

15 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 15 Produzioni grid con MOP (VDT) MOP is a system for packaging production processing jobs into DAGMAN format Mop_submitter wraps Impala jobs in DAG format at the “MOP master” site DAGMAN runs DAG jobs through remote sites’ Globus JobManagers through Condor-G Results are returned using GridFTP. Though the results are also returned to the MOP master site in the current IGT running, this does not have to be the case. Master Site Remote Site 1 IMPALAmop_submitter DAGMan Condor-G GridFTP Batch Queue GridFTP Remote Site N Batch Queue GridFTP UW Madison is the MOP master for the USCMS Grid Testbed FNAL is the MOP master for the IGT and the Production Grid

16 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 16 SE CE CMS software Produzioni grid con EUDataGrid BOSS DB Workload Management System JDL RefDB parameters data registration Job output filtering Runtime monitoring input data location Push data or info Pull info UI IMPALA/BOSS Replica Manager CE CMS software CE CMS software CE WN SE CE CMS software SE

17 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 17 LHC Computing Grid Project The job of the LHC Computing Grid Project – LCG – is to prepare the computing infrastructure for the simulation, processing and analysis of LHC data for all four of the LHC collaborations.

18 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 18 The appliccation area Gli esperimenti contribuiscono a LCG con un considerevole numero di persone (circa 4 FTE da CMS…) Total of 49 FTE’s

19 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 19 CMS Data Challenges Average slope =x2.5/year DC04 Physics TDR DC05 LCG TDR DC06 Readiness LHC 2E33 LHC 1E34 DAQTDR 1999: 1TB – 1 month – 1 person 2000-2001: 27 TB – 12 months – 30 persons 2002: 20 TB – 2 months – 30 persons 2003: 175 TB – 6 months – <30 persons By V.Lefebure Sep 2002

20 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 20 DC04 e pre-production (PCP03) Simulazione del processo di ricostruzione e analisi del primo anno di running di LHC ad una scala pari al 25% delle dimensioni reali (5% delle dimensioni finali). –Un mese: febbraio 2004 –Processamento dati a 25 Hz (50 MB/s) al CERN –Distribuzione dei dati ai Tier-1 e Tier-2 e analisi con grid –50 milioni di eventi in input Pre-produzione da luglio a dicembre 2003 –simulazione e digitizzazione dei 50 milioni di eventi –circa 1M SpecInt2000, 175 TB di dati –75 TB di dati da trasferire al CERN in 2 mesi (~125 Mbit/s) –In Italia circa il 20% della pre-produzione ~200 KSpecInt2000 per 6 mesi, 34 TB di dati prodotti e archiviati ~25 Mbit/s bandwidth CNAF  CERN (nov-dic 03) ~20 Mbit/s bandwidth Tier-2’s  CNAF (lug-dic 03)

21 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 21 Tools per PCP03 MCRunJob Site Manager starts an assignment RefDB Phys.Group asks for an official dataset User starts a private production Production Manager defines assignments DAG job JDL shell scripts DAGMan (MOP) Local Batch Manager EDG Scheduler Computer farm LCG-1 testbe d User’s Site Resources Chimera VDL Virtual Data Catalogue Planner

22 Claudio Grandi INFN Bologna 12 giugno 2003 Workshop Commissione Calcolo 22 Conclusioni Utilizzo di tecnologia OO confermato. Sviluppo di soluzioni home-made per la gestione dei dati Data model e analysis model confermati. Organizzazione gerarchica delle risorse a-la- MONARC. I tools di grid semplificano alcuni aspetti della gestione ma non modificano l’architettura. La migrazione di manpower esperto in computing dagli esperimenti ai progetti grid e a LCG obbliga gli esperimenti alla ricerca di soluzioni comuni (e quindi a compromessi!) Data Challenges di dimensioni e complessità crescenti tentano di utilizzare tools di grid