Calcolo LHCb Umberto Marconi INFN Sezione di Bologna Riunione CSN1, 18/09/2008.

Presentazione sul tema: "Calcolo LHCb Umberto Marconi INFN Sezione di Bologna Riunione CSN1, 18/09/2008."— Transcript della presentazione:

1 Calcolo LHCb Umberto Marconi INFN Sezione di Bologna Riunione CSN1, 18/09/2008

2 2 Modello LHCb

3 3 Modello (II) Reconstruction Stripping User Analysis Trigger (2 kHz) Detector (40 MHz) RAW rDST DST, TAG ntuple @Tier-1 Simulation @Tier-2 ~ 70 MB/s Tier-1 di LHCb non omogenei

4 4 Piano di sviluppo CNAF (marzo 2007)

5 5 Piano di sviluppo LHCb. Totale risorse. CPU Disco Tape

6 6 Risorse al CNAF Risorse in uso attualmente Tier-1 & Tier-2 (prestito Tier-1) CPU:  200 kSi2k (100 kSi2k del Tier-1) Disco: 10 TB (cache) + 40 TB, Tape: 90 TB. Risorse 2008 (@0.5 fb -1, 50% MC regime) Tier-1 CPU: 300 kSi2K Disco: 170 TB 30 TB per cache di Castor per la classe di storage T1D0. 140 TB per GPFS-StoRM per le classi di storage T0D1 e T1D1. Tape: 200 TB Tier-2 CPU: 700 kSi2K

7 7 Flussi e Storage Classes GPFS-StoRM Castor

8 8 Attivita’ INFN nel calcolo di LHCb Sistema di prioritizzazione dei job di LHCb G. Castellani, R. Santinelli Bookkeeping e Data Management M. Bargiotti, E. Lanciotti, R. Santinelli Test librerie storage SRM v2 E. Lanciotti, R. Santinelli Test storage al CNAF per LHCb A. Carbone, V. Vagnoni Collaborazione al progetto stoRM V. Vagnoni Data Base per LHCb G. Peco, V. Vagnoni Produzione eventi Monte Carlo A. Carbone, D. Bortolotti Collaudo strumenti di analisi distribuita A. Carbone, A. Sarti, S. Vecchi, V. Vagnoni Controllo, configurazione e monitoraggio D. Galli LHCb Computing Management U. Marconi

9 9 File-system paralleli al CNAF (GPFS) Stretta collaborazione di LHCb con il CNAF per la valutazione e la validazione dell’infrastruttura di storage. Studio comparativo delle prestazioni di varie soluzioni per l’accesso ai dati su disco, in particolare: dCache, Xrootd e GPFS. Articolo in preparazione https://lhcbweb.bo.infn.it/main.pdf Risultati presentati a CHEP 2007 (L. Dell’Agnello): http://indico.cern.ch/getFile.py/access?contribId=395&sessionId=2 4&resId=2&materialId=slides&confId=3580 http://indico.cern.ch/getFile.py/access?contribId=395&sessionId=2 4&resId=2&materialId=slides&confId=3580

10 10 Validazione di GPFS su grossa scala 8 racks di nodi di calcolo 1100 CPU slots 2 Gb/s uplink per rack verso lo switch centrale 2 sistemi disco Storage Area Network EMC CX3-80 130 TB ciascuno 500GB Fiber Channel disks 8x4 Gb/s Fiber Channel ports 24 Disk Servers Dual core bi-processor Xeon 1.6GHz 4 GB RAM Dual-port Qlogic 246x Fiber Channel card 1 Gb/s uplink to the switch Black Diamond 10000 (switch centrale) 20 Gb/s links verso il rack dei disk server 16 Gb/s dai rack dei nodi di calcolo

11 11 Prestazioni con analisi realistica di LHCb Test Tempo totale di elaborazione (s) GPFS9600 dCache14500 Xrootd16000 1000 job di analisi in esecuzione simultanea sui nodi di calcolo, selezione B  h + h - I job accedono allo stesso set di dati usando: dCache, Xrootd e GPFS con identico sistema hardware Throughput aggregato di trasferimento dei dati dai disk-server verso i nodi di calcolo in funzione del tempo Il throughput disco di un comune Linux PC è grosso modo qui (30 MB/s) Con ottimizzazione dell’I/O sull’applicazione questa configurazione può arrivare a circa 1.6 GB/s

12 12 StoRM. Configurazione e collaudo. Collaborazione con il CNAF StoRM è un implementazione del protocollo SRM v2 (Storage Resource Management) Il protocollo SRM è impiegato da tutti gli esperimenti LHC SRM consente la gestione remota e l’accesso ai dati alle applicazione in modo trasparente, indipendentemente dalla specifica implementazione dello storage. StoRM è sviluppato da INFN e ICTP StoRM è specificamente progettato per fornire le funzionalità SRM ai file-system paralleli, in particolare GPFS Impiegato attualmente al CNAF per la classe di storage T0D1 (puro disco) che LHCb utilizza per l’analisi finale dei dati. Particolarmente indicato come soluzione per i Tier-2. Validazione di StoRM effettuata su un sistema di media scala 4 server Gridftp/GPFS 38 TB di file-system GPFS 3 server StoRM bilanciati dinamicamente

13 13 StoRM. Test di trasferimento dal CERN al CNAF 14 hours 120 processi di transferimento simultanei 15 streams paralleli per ciascun trasferimento Dai disk pool di LHCb (Castor - CERN) a GPFS-StoRM (CNAF) Totale di file trasferiti: ~100K Più di 400K interazioni con StoRM Percentuale di fallimento nella copia = 0.2% Totale di dati trasferiti: 17 TB in 14 ore Throughput sostenuto: 370 MB/s (~3 Gb/s) Risultati del test accettati a conferenza IEEE Draft disponibile a https://lhcbweb.bo.infn.it/submission_94.pdf

14 14 rmdir ricorsiva da client SRM remoto 17 TB di dati distribuiti in 50 directory sono stati cancellati, dando l’ordine da un client remoto, in circa 20 minuti. Occupazione del file-system GPFS in funzione del tempo Inizio della procedura Nell’esperienza di LHCb con i sistemi esercitati fino ad oggi un’operazione simile può richiedere giorni, con innumerevoli problemi. GPFS-StoRM rimozione file

15 15 Attivita’ LHCb. Obiettivi Simulazione con produzione dei dati RAW, impiegando tutte le risorse LCG disponibili. Ricostruzione presso i centri Tier-1, con produzione degli eventi rDST, come se i dati provenissero dal rivelatore. Selezione degli eventi rDST presso i centri Tier-1 e produzione degli eventi DST utili all’analisi. Analisi degli eventi DST presso i centri Tier-1 Trasferimento dei dati: Nella distribuzione dei dati RAW dai siti di produzione MC al CERN. Nella distribuzione dei dati RAW dal CERN a tutti i centri Tier-1. Nella distribuzione degli eventi DST da ciascun centro Tier-1 ad almeno 3 centri Tier-1 (compreso il CERN) per la successiva fase di analisi.

16 16 Attivita’ di calcolo LHCb. Numeri Utilizzati tutti i Tier-1 700 milioni di eventi prodotti nel DC06, a partire da maggio 2006. 1.5 milioni di job eseguiti con successo. Fino a 10 4 job in esecuzione simultaneamente su 120 siti differenti. 100 milioni di eventi ricostruiti 2  10 5 file recuperati da Tape 10 milioni di eventi pre-selezionati Ricostruzione e selezione sono operazioni complesse: Accesso ai dati su disco, recupero dati da tape, instabilità SRM, consistenza dei cataloghi, qualita’ del software, ecc.

17 17 Simulazione dal 1/1/07 al 27/08/07 SiteEvents (%) LCG.CERN.ch18.93 LCG.CNAF.it10.74 LCG.RAL.uk9.00 LCG.Manchester.uk8.08 LCG.NIKHEF.nl5.02 LCG.Glasgow.uk4.27 DIRAC.Lyon.fr2.39 LCG.Lancashire.uk 2.18 LCG.USC.es1.61 LCG.Barcelona.es1.13 LCG.QMUL.uk2.29 LCG.GRIDKA.de5.36 LCG.PIC.es 10.57 CountryEvents (%) CH 19.65 DE 5.60 ES 13.63 FR 8.89 IT 11.77 NL 5.03 PL 1.42 UK30.04 Other4.0 Accounting collaborazione LHCb

18 18 Attivita’ LHCb. Cronologia Estate 2006 Produzione di eventi simulati Eventi di fondo (~100 Mevts b-inclusive e 300 Mevts minimum bias). Tutti i file di dati MC RAW trasferiti al CERN. Autunno 2006 I file dei dati RAW transferiti ai centri Tier1s (FTS) per simulare il flusso dell’acquisizione dati. I file di dati una volta trasferiti sono automaticamente registrati nel processing database di DIRAC che gestisce la successiva ricostruzione automaticamente. Nota: I file sono certamente su disco. Da dicembre 2006 Simulazione, digitizzazione e ricostruzione Produzione di eventi di segnale (200 Mevts) DSTs trasferiti agli SE dei Tier1 per l’analisi

19 19 Attivita’ LHCb. Cronologia (II) Da gennaio 2007 Produzione di eventi di fondo Re-ricostruzione di eventi presso i centri Tier1 Utilizzati 20 files RAW come input per job. I file dei dati RAW non piu’ in cache sono stati trasferiti da Tape a Disco. L’output rDST e’ memorizzato localmente presso il Tier1 utilizzato per la ricostruzione. Da maggio 2007 Produzione di eventi di fondo e segnale Preselezione (stripping) degli eventi di fondo presso i Tier1 Utilizzati 2 rDST di input per job Utilizzati i corrispondenti 40 file RAW per la ricostruzione completa degli eventi, selezionati e prodotti in formato DST. Eventi in formato DST distributi ai centri Tier1s per l’analisi.

20 20 Utilizzo CPU L’uso della CPU è relativamente elevato in corrispondenza della produzioni MC. 2007% utilizzo Gennaio9.7 Febbraio3.4 Marzo3.1 Aprile1.5 Maggio10.8 Giugno10.2 Luglio3.9 Agosto3.2 Sites CPU Time (%) Giugno-Settembre CNAF14.8 Manchester11.2 IN2P36.5 Lancashire7.4 Glasgow7.2 CERN5.0 Brunel5.7 NIKHEF5.2 USC4.2 RAL3.8 Barcelona2.7 Accounting CNAF Accounting LHCb

21 21 Analisi distribuita Ganga è la UI utilizzata per la sottoposizione dei job: Locale, LSF batch system, Grid. La sottoposizione alla Grid è realizzata attraverso DIRAC: uso dei pilot agent e delle code interne di prioritizzazione di LHCb. Client-side job splitting Job di analisi vs tempo

22 22 Analisi distribuita. Latenza Statistica su 1.5  10 4 job Tempo medio di attesa per l’esecuzione ~ 5 ore istante di avvio esecuzione – istante di arrivo al WMS Misure recenti: 3 giorni su lxplus LSF batch queue, 2 giorni su Grid.

23 23 Analisi distribuita. Efficienza Correlazione inefficienza – durata del job Fallimento nell’accesso ai dati (19%): Inconsistenze nei cataloghi (14%)  importanza dell’integrità dei dati e cataloghi. Instabilita’ nelle SRM che restituiscono TURL errati (5%). Stalled (8%): Non riceviamo più l’heartbeats: Scaduto il proxy, esaurito CPU time, ecc. Statistica su 2.0  10 4 eventi Efficienza:  70%

24 24 Data Base In collaborazione con il team dei DBA del Tier1 : Installazione, configurazione e gestione dei cluster Oracle di produzione pre- produzione e test (Real Application Cluster) Validation test del sistema Storage Area Network utilizzato come storage condiviso dai DB Implementazione del sistema di gestione e controllo centralizzato dei DB (Oracle Grid Control Console) Realizzazione dei test di scalabilita’, latenza e carico dei sistemi LFC di LHCb replicati T0  CNAF e T0  T1s https://indico.desy.de/contributionDisplay.py?contribId=21&sessionId=33&c onfId=257 https://indico.desy.de/contributionDisplay.py?contribId=21&sessionId=33&c onfId=257 http://indico.cern.ch/getFile.py/access?contribId=114&sessionId=21&resId=0&materi alId=slides&confId=7247 http://indico.cern.ch/getFile.py/access?contribId=114&sessionId=21&resId=0&materi alId=slides&confId=7247 http://indico.cern.ch/contributionDisplay.py?contribId=213&sessionId=28&confId=35 80 http://indico.cern.ch/contributionDisplay.py?contribId=213&sessionId=28&confId=35 80 Realizzazione dei collaudi preliminari di scalabilita’ del Conditions DB di LHCb replicato T0  CNAF http://indico.cern.ch/contributionDisplay.py?contribId=265&sessionId=31&confId=35 80 http://indico.cern.ch/contributionDisplay.py?contribId=265&sessionId=31&confId=35 80 In corso test di macchine virtuali con CPU multi-core di servizi ORACLE DB

25 25 Prioritizzazione dei job Pilot Agent Grid Central Task Queue Priority Agent Job Matcher Il Priority Agent valuta la priorita’ di un job in base a: group, user, Job Type, time spent in Task Queue, user defined priority, accounting information, required CPU power, memory and storage consumed in the past. Il Job Matcher trasmette i job da eseguire ai Pilot Agents che ne fanno richiesta, liberando le code riempite secondo le priorita’ stabilite. E’ stata sviluppata una soluzione basata su MOAB Service: prodotto commerciale, ampiamente configurabile, per ottenere una regolazione fine nell’assegnazione della priorita’. Prioritizzazione dei job centralizzata LHCb

26 26 Programma di lavoro Re-processing e pre-selezione degli eventi, con traferimento dei dati da Tape a Disco. Test di SRM v2.2. Completamento della transizione a SLC4. Analisi distribuita: GANGA e prioritizzazione. Replica dei cataloghi. Test di trasferimento Pit - Tier0