1 / 22

Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS

Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS. Claudio Grandi (INFN Bologna). 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.

beauregard
Download Presentation

Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evoluzione dei modelli di calcolo distribuito nell’esperimento CMS Claudio Grandi (INFN Bologna) 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 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) Workshop Commissione Calcolo

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

  5. Monarc analysis process DAQ -------------- Raw Slow C -------------- Calibration Trigger Info Reconstruction ---------------------- ESD/Rec. Obj 1st time at CERN (then at RC? ==> Parameters? 4 times per Year? (per Exp.) +TAG DB x n WG Selection --------------- AOD/Anal. Obj Selection --------------- AOD/Anal. Obj Different WG at different site? ==> Parameters? Once per Month? (per WG) x n Users in the WG Analysis ------------- Selected AOD/Anal. Obj & TAG DB Analysis ------------- Selected AOD/Anal. Obj & TAG DB 4 times per Day? (per User) RC or Desktop? ==> Parameters? 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 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. • La 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”). • [Terzo pilastro!: occorre fare uso il piu’ possibile della realta’ della commodity (budget and availability)] By P.Capiluppi, Jul 1999 Workshop Commissione Calcolo

  7. ~PBytes/sec ~100 MBytes/sec Offline Processor Farm ~20 TIPS There is a “bunch crossing” every 25 nsecs. There are 100 “triggers” per second Each triggered event is ~1 MByte in size ~100 MBytes/sec Online System Tier 0 CERN Computer Centre ~622 Mbits/sec or Air Freight (deprecated) Tier 1 FermiLab ~4 TIPS France Regional Centre Germany Regional Centre Italy Regional Centre ~622 Mbits/sec Tier 2 Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS Caltech ~1 TIPS Tier2 Centre ~1 TIPS Tier2 Centre ~1 TIPS HPSS HPSS HPSS HPSS HPSS ~622 Mbits/sec Institute ~0.25TIPS Institute Institute Institute Physics data cache ~1 MBytes/sec 1 TIPS is approximately 25,000 SpecInt95 equivalents 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 Pentium II 300 MHz Pentium II 300 MHz Pentium II 300 MHz Pentium II 300 MHz Tier 4 Physicist workstations Monarc: computing model By H.Newman 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 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 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 Workshop Commissione Calcolo

  11. Definizione del Computing Model 2003 2004 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) 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!) 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 Workshop Commissione Calcolo

  15. Remote Site 1 Batch Queue Master Site GridFTP DAGMan Condor-G IMPALA mop_submitter GridFTP Remote Site N Batch Queue GridFTP 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. UW Madison is the MOP master for the USCMS Grid Testbed FNAL is the MOP master for the IGT and the Production Grid Workshop Commissione Calcolo

  16. Job output filtering Runtime monitoring CE CE CE CE parameters CMS software CMS software CMS software CMS software SE JDL data registration Push data or info WN Pull info Produzioni grid con EUDataGrid SE RefDB BOSS DB Workload Management System SE UI IMPALA/BOSS input data location SE CE Replica Manager SE 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. 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 Workshop Commissione Calcolo

  19. LHC1E34 Average slope =x2.5/year LHC2E33 DC06 Readiness DC05 LCG TDR DC04Physics TDR DAQTDR CMS Data Challenges 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 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) Workshop Commissione Calcolo

  21. Computer farm DAG job job job job Tools per PCP03 User’s Site Resources Production Manager defines assignments RefDB Phys.Group asks for an official dataset shell scripts Local Batch Manager JDL EDG Scheduler Site Manager starts an assignment LCG-1 testbed MCRunJob DAGMan (MOP) User starts a private production Chimera VDL Virtual Data Catalogue Planner 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 Workshop Commissione Calcolo

More Related