Il Computing di ATLAS Gianpaolo Carlino CSN1 Roma, 2 Luglio 2008 Il Computing Challenge I Tier2 I Tier2 Attività e Risorse per il 2008 Attività e Risorse per il 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 2 Attività di Commissioning del Computing in ATLAS CCRC08 – Fase 2 (maggio 2008) CCRC08 – Fase 2 (maggio 2008)

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 3 Attività Computing ATLAS ATLAS ha svolto un’intensa attività di test nel 2008 sia nell’ambito del CCRC08 (combinato con gli altri esperimenti) che indipendentemente: FDR e Pre CCRC08-2  Febbraio 2008:  FDR-1: simulazione dell’intera catena di software & computing  CCRC08–1: test della distribuzione dei dati T0  T1  T2 sosprattutto un test delle operazioni al Tier0, di funzionalità del sistema e di installazione e configurazione di SRM 2.2 e canali FTS sosprattutto un test delle operazioni al Tier0, di funzionalità del sistema e di installazione e configurazione di SRM 2.2 e canali FTS Esercizio molto utile per Atlas, metriche (di carattere qualitativo) rispettate Esercizio molto utile per Atlas, metriche (di carattere qualitativo) rispettate  Marzo-Aprile 2008:  Pre CCRC08-2: test di computing preparatori per il CCRC08-2 ripetizione test di funzionalità e configurazione canali Tier1  Tier1 ripetizione test di funzionalità e configurazione canali Tier1  Tier1  Maggio 2008  CCRC08-2: test intensivo di DDM, T0  T1  T2 e T1  T1 test di funzionalità e throughput test di funzionalità e throughput metriche molto esigenti metriche molto esigenti 4 settimane di test con incremento graduale delle complessità dei test 4 settimane di test con incremento graduale delle complessità dei test impossibilità a svolgere test di lunga durata; durante il weekend priorità per cosmici e commissioning dei rivelatori. impossibilità a svolgere test di lunga durata; durante il weekend priorità per cosmici e commissioning dei rivelatori.  Giugno 2008  FDR-2 test delle procedure di validazione, ricostruzione e analisi distribuita dei dati test delle procedure di validazione, ricostruzione e analisi distribuita dei dati

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio CCRC08 – Fase 2 Durata 4 settimane. Attività durante la settimana (mar-ven.) per consentire la presa dati con i cosmici e il commissioning dei rivelatori nei fine settimana (attività prioritarie) Week 1 Functional Test: Trasferimenti Tier0  Tier1s Studio dell’efficienza del sistema di trasferimento dei dati Week 2 Tier1-Tier1 Test: Trasferimenti Tier1  Tier1 Studio dell’efficienza del sistema di distribuzione dei dati prodotti nel reprocessing (Tier1-Tier1 transfer matrix). Sottoscrizioni contemporanee ! 18 TB corrispondente a 90 MBps di import rate per ogni Tier1 (superiore al rate nominale) Week 3 Throughput Test: Trasferimenti Tier0  Tier1  Tier2 Simulazione dell’export dal Tier0 per 200 Hz (150% del rate nominale) Week 4 Full Exercise: Trasferimenti contemporanei Tier0  Tier1  Tier2 e Tier1  Tier1 In aggiunta intensa simulazione ai Tier2 con aggiunta di trasferimenti ai Tier1

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio CCRC08 – Fase 2 Le Metriche stabilite con un crescendo di complessità nelle 4 settimane Le Metriche stabilite con un crescendo di complessità nelle 4 settimane Functional Tests Replica completa al 90% dei dataset dal momento della sottoscrizione in 48h (week 1) 48h (week 1) 6h (week 4) 6h (week 4) Tier1 – Tier1 Test Per ogni canale (Tier1-Tier1 pair) il 90% dei dataset deve essere completamente replicato in 52 h (week2) 52 h (week2) 6h, mantenendo il rate del reprocessing con il Tier1 gemello per tutta la durata del test (al CNAF: 10 MBps di ESD e 20 MBps di AOD) (week 4) 6h, mantenendo il rate del reprocessing con il Tier1 gemello per tutta la durata del test (al CNAF: 10 MBps di ESD e 20 MBps di AOD) (week 4) Throughput Tests Ogni sito deve essere in grado di sostenere il peak rate per almeno 24 ore e il nominal rate per 3 giorni (week 3) il peak rate per almeno 24 ore e il nominal rate per 3 giorni (week 3)

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K II W E K III W E K IV Functional Test CNAF (97% complete) CCRC08 – Fase2 Test superato da tutti i Tier1 Atlas e dal CNAF

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K III W E K IV CCRC08 - Fase 2 Attività concorrente con CMS sebbene non visualizzata in GridView!!! I trasferimenti nei canali Tier1-Tier1 non erano ancora monitorati Tier1 – Tier1 Test

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio DAY1 All days All days (errors) CCRC08 – Fase 2 W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K III W E K IV Tier1 – Tier1 Test

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Frazione di dataset completati FROMFROM TOTO = Not Relevant 0% 20% 40% 60% 80% 100% W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K III W E K IV CCRC08 – Fase 2

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K III W E K IV CCRC08 – Fase 2 Analisi dei Risultati: Il test è stato superato dalla gran parte dei canali dei Tier1 Il test è stato superato dalla gran parte dei canali dei Tier1 efficienze ~ 99% e picchi di throughput di 500 MBps (bulk of data, 16 TB, trasferito in sole 4 ore) in alcuni siti Al CNAF: bassa efficienza e throughput nell’import da molti siti ! Efficienza media 45% e throughput medio 40 MBps Problemi individuati:  Alto carico sui server GridFTP dovuto a una non completa compatibilità con i sever GPFS (file system usato da Storm): traffico in uscita dai server doppio di quello in ingresso dovuto alla riscrittura dello stesso dato. Ciò limita le efficienze e il traffico in ingresso. Problemi parzialmente risolti alla fine della settimana: Alta efficienza ma ancora basso throughput verificato in test successivi durante il weekend.

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K II W E K III W E K IV CCRC08 – Fase 2 Data transfer complessivo Throughput Test

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio NOMINAL PEAK ERRORS WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K II W E K III W E K IV CCRC08 – Fase 2

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Rate Attesi Rates(MB/s)TAPEDISK Total BNL IN2P SARA RAL FZK CNAF ASGC PIC NDGF TRIUMF Sum CCRC08 – Fase 2 WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K II W E K III W E K IV CNAF share del 5% corrispondente a 56 MBps Test parzialmente superato Rate nominale raggiunto ma non superato in caso di backlog determinato da periodi di inefficienze alla sorgente o alla destinazione. Non si riusciva ad “accelerare” i trasferimenti. Problema causato da un banalissimo errore di installazione di un nuovo pool di storage in cui venivano scritti i dati del test da parte degli installatori Throughput Test

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Test di backlog recovery Primi dati generati in 12 ore e sottoscritti in bulk 12h di backlog recuperati in 90 minuti in tutti i siti! Tier0  Tier1 W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L W E K III M M G V S D W E K IV CCRC08 – Fase 2 Risolti problemi di throughput per trasferimenti dal Tier0: ~ 200 MBps per 2h

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Trasferimenti complessivi Blocco trasferimenti per 12 h il 27 Power-cut il 30 Expected Rate W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L W E K III M M G V S D W E K IV CCRC08 – Fase 2

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio YELLOW boxes Effetto del power-cut YELLOW boxes Effetto del power-cut DARK GREEN boxes Double Registration problem DARK GREEN boxes Double Registration problem Grande miglioramento rispetto a Week2 W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L W E K III M M G V S D W E K IV CCRC08 – Fase 2 Tier1 - Tier1 transfer matrix

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio CCRC08 – Fase 2 Considerazioni finali sul CCRC  Il sistema di distribuzione dei dati era un item critico di Atlas. Preoccupazione negli utenti (scarsa fiducia sulla possibilità di reperire i dati con velocità ed efficienza). Il commissioning di questo sistema ha focalizzato l’attenzione durante il CCRC.  Grande collaboriazione tra il gruppo ADC e le clouds. Delocalizzazione delle attività  Il giudizio finale è positivo: efficienze e throughput molto alti !  È stato effettuto un debugging approfondito delle configurazioni di tutte le parti del sistema testando, ben oltre gli use cases previsti per il data taking 2008, tutti i tipi di trasferimenti previsti dal CM  Al CNAF alcuni aspetti del sistema di storage non erano perfettamente compresi e i testi effettuati in precedenza non erano stati sufficientemente accurati da evidenziarli.  Operations e support: la stretta collaborazione tra esperimento e Tier1 ha permesso di migliorare le strategie di supporto alle attività. Necessità di automatizzare le procedure di controllo. Il sistema è ancora poco robusto e richiede attenzione continua.  Vero problema per i prossimi mesi: IL DISCO!!! Il ritardo dell’acquisizione dei pledge 2008 mette l’esperimento in seria difficoltà. Necessità di spostare alcune attività e dati ai Tier2. Attività principali dei prossimi mesi: Reprocessing ai Tier1 e uso del tape

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio i Tier2 partecipazione ai test CCRC e FDR-2 utilizzo delle risorse

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Attività di Computing nei Tier2 Partecipazione dei Tier2 italiani al CCRC e al FDR  Il Computing Model di ATLAS prevede che i Tier2 “interagiscano” essenzialmente con il Tier1 della propria cloud dei quali sono satelliti. pro: modello molto agile e poco caotico pro: modello molto agile e poco caotico contro: il Tier1 è un single point of failure contro: il Tier1 è un single point of failure  CCRC08 – Fase 2: test di distribuzione dei dati i Tier2 hanno partecipato al test replicando i dati trasmessi al CNAF dal Tier0 i Tier2 hanno partecipato al test replicando i dati trasmessi al CNAF dal Tier0 studio dell’efficienza dei trasferimenti studio dell’efficienza dei trasferimenti studio del timing dei trasferimenti studio del timing dei trasferimenti  FDR: test dell’intera catena di computing e in particolare, per i Tier2, del sistema di analisi distribuita studio dell’efficienza delle repliche dei dati necessari per l’analisi: AOD e DPD studio dell’efficienza delle repliche dei dati necessari per l’analisi: AOD e DPD studio della possibilità di accesso ai dati da parte degli utenti e dell’utilizzo dei tool di analisi distribuita studio della possibilità di accesso ai dati da parte degli utenti e dell’utilizzo dei tool di analisi distribuita

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 20 W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L W E K III M M G V S D W E K IV CCRC08 – Fase 2. I Tier2 Tier0  Tier1  Tier2 Oversubscription a Na e Rm: 100% AOD  Dataset  Files Eff Thr. MB/s LNF %2.64 MI %2.88 NA %12,02 RM %12,02

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 21 MB/s W E K II WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L W E K III M M G V S D W E K IV CCRC08 – Fase 2. I Tier2 I Tier2 acquisiscono i dati molto velocemente: max 1.5h dalla richiesta di sottoscrizione e max 0.5h per completare un dataset Throughput Throughput: Time structure nei trasferimenti. I Dataset vengono sottoscritti dopo che la replica completa al Tier1, ogni 4h.

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 22 CCRC08 – Fase 2. I Tier2 Affidabilità del Tier2 Affidabilità del Tier2: Recupero immediato del backlog Esempio: interruzione dei trasferimenti a NA per la scadenza del certificato del DPM. Recupero dei dati in 30 min con un throughput di 100 MBps WEEKIWEEKI L M M G V S D L M M G V S D L M M G V S D L M M G V S D W E K II W E K III W E K IV Errori

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Final Dress Rehearsal Esercizio completo dell’intera catena, dall’on-line/trigger all’analisi distribuita, per integrare i test svolti fino ad ora in modo indipendente:  Simulazione di 1 fill di presa dati 4 Run di 1 hr a e 250 Hz, 350 nb -1, con configurazioni diverse, ripetuti più volte 4 Run di 1 hr a e 250 Hz, 350 nb -1, con configurazioni diverse, ripetuti più volte Dati MC pesati con le corrette sezioni d’urto Dati MC pesati con le corrette sezioni d’urto  Immissione dei dati nel TDAQ e running a partire dagli SFO  5 physics stream: mu, e/gamma, multijets, Bphys, minbias + Express stream e calibrazioni  Completo utilizzo del Tier-0 merging, scrittura su tape, ricostruzione, calibrazione, validazione etc merging, scrittura su tape, ricostruzione, calibrazione, validazione etc i dati vengono ricostruiti e validati sulla ES per verificare la qualità dei dati. Meeting di sign-off alle 4 pm per autorizzare la replica dei dati i dati vengono ricostruiti e validati sulla ES per verificare la qualità dei dati. Meeting di sign-off alle 4 pm per autorizzare la replica dei dati Bulk reconstruction sulle physics stream Bulk reconstruction sulle physics stream vari problemi di merging e ricostruzione, vari problemi di merging e ricostruzione,  Esecuzione del Computing Model in maniera completa distribuzione dei dati e analisi distribuita distribuzione dei dati e analisi distribuita  Simulazione MC completa in parallelo running ai Tier-2, trasferimento dati e ricostruzione ai Tier-1 running ai Tier-2, trasferimento dati e ricostruzione ai Tier-1 Lo scopo è testare l’intero computing system come se si trattasse di dati reali per trovare in tempo i problemi che si potrebbero verificare durante il data taking

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 24 Final Dress Rehearsal Distribuzione dei dati: Dati correttamente ricostruiti pronti solo il 15-6 e trasferiti ai Tier1 e Tier2 Richiesti 100% AOD e DPD a NA e RM, 25% a MI e LNF Efficienza 100%

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Final Dress Rehearsal Analisi nei Tier2:  Utilizzo esclusivo dei Tier2 italiani  Test di accesso ai dati e running dei job di analisi con Ganga contributo fondamentale degli utenti italiani per debuggare Ganga e renderlo utilizzabile su dpm (primo srm ad essere funzionante con le nuove release) contributo fondamentale degli utenti italiani per debuggare Ganga e renderlo utilizzabile su dpm (primo srm ad essere funzionante con le nuove release) possibilità di definire i siti o la cloud sui cui runnare possibilità di definire i siti o la cloud sui cui runnare soddisfazione degli utenti per la facilità e la velocità di utilizzo dopo il primo periodo di training e configurazione. soddisfazione degli utenti per la facilità e la velocità di utilizzo dopo il primo periodo di training e configurazione. max 2h tra l’invio dei job, il recupero dell’output e l’analisi locale, nonostante la forte competizione con la produzione MC max 2h tra l’invio dei job, il recupero dell’output e l’analisi locale, nonostante la forte competizione con la produzione MC efficienza dei job > 95% efficienza dei job > 95%  Strategie di analisi: produzione in grid di DPD di gruppo o utente con i DPDMaker dagli AOD e DPD primari prodotti centralmente produzione in grid di DPD di gruppo o utente con i DPDMaker dagli AOD e DPD primari prodotti centralmente analisi dei DPD localmente nei Tier2 di riferimento (ARANA) analisi dei DPD localmente nei Tier2 di riferimento (ARANA)  Gruppi di analisi coinvolti Susy, Top, Higgs, MS, Minimum Bias, Trigger Susy, Top, Higgs, MS, Minimum Bias, Trigger Analisi preliminari Analisi preliminari

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio 10)(4)(6) jets minbias 10 20 40 6 + Bphy 25i + 10 totalE + EtMiss Trigger EF Analisi del trigger nella muon stream: offline muon (Muid) MU6 MU10 MU11 MU20 MU40 LVL1 selection barrel + endcaps muon p T (MeV) L1 L2 EF Final Dress Rehearsal

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Tutte le analisi studiano preliminarmente la ricostruzione di Z Di-electron invariant mass Di-  invariant mass Final Dress Rehearsal eventi calibrati eventi scalibrati

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Y J/  M  (MeV) J/  Y Z M  (MeV) Z Final Dress Rehearsal Opposite Sign e Same Sign dileptons Opposite Sign (OS) e Same Sign (SS) dileptons

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Analisi Susy nella stream e/gamma muon p T (MeV) E T MISS GeV GeV/c P T 1 ST jet Lepton-neutrino transverse mass Final Dress Rehearsal

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Etmiss Etsum nella stream e/gamma: Molteplicità di particelle cariche nella stream Minimum Bias Final Dress Rehearsal

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Calibration center CERN 40 M  /day 100 M  /day Stream di calibrazione dei   Stream dal LVL2 (10 kHz). Distribuzione in Italia a Roma, sito ufficiale per la calibrazione degli MDT, e a Napoli per l’analisi, off-line, degli RPC Canali FTS dedicati con il Tier0 per diminuire la latenza (non appesantisce la banda passante) Canali FTS dedicati con il Tier0 per diminuire la latenza (non appesantisce la banda passante) 100 M ev/giorno, Event Size = 1 kB, Max bandwidth = 10 MBps 100 M ev/giorno, Event Size = 1 kB, Max bandwidth = 10 MBps  Calibrazione entro 24h dalla presa dati  Accesso e scrittura su DB Oracle. Replica del DB al Cern  Risorse necessarie: Spazio disco: 3 TB nel 2008 e 10 TB nel 2009 Spazio disco: 3 TB nel 2008 e 10 TB nel 2009 CPU: ~150 kSI2k CPU: ~150 kSI2k

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Stream di calibrazione dei  Distribuzione dei dati:  Trasferimento rapidissimo Pochi minuti dalla registrazione in DDM Pochi minuti dalla registrazione in DDM  Lunghi tempi di attesa per le registrazioni dei file nei cataloghi Problemi con i cataloghi centrali ora risolti Problemi con i cataloghi centrali ora risolti Ritardo nelle registrazioni fino a 5h Ritardo nelle registrazioni fino a 5h Soluzioni in fase di implementazione Soluzioni in fase di implementazione Processamento dei dati:  Splitting dei dati e produzione di ntuple max 2h dopo il completamento dei dataset  Calibrazione dalle ntuple max 3h  Filling del DB locale e replica al Cern Replica dei dati:  Replica in linea dei dati al Tier0 I dati arrivati sono stati processati e i risultati trasmessi al Cern entro il termine di 24h a partire dalla presa dati. FDR:  43 M eventi analizzati al giorno (equivalenti a 6h di presa dati al giorno)  Durata del test: 3 giorni

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Sistema di benchmark La suite di benchmark di ATLAS  Definizione di un sistema di benchmark per ATLAS basato sull’esecuzione delle applicazioni del software di esperimento Misura realistica della CPU utilizzata attraverso l’utilizzo di task reali Misura realistica della CPU utilizzata attraverso l’utilizzo di task reali  Possibilità di utilizzare questo benchmark per la determinazione dei processori più adatti da acquistare  Basato su una infrastruttura già esistente, potenziata per raccogliere le informazioni di benchmark e presentarle in modo interattivo agli utenti Kit Validation Kit Validation  sviluppato per validare le installazioni del software (installazioni Grid e utente) Global Kit Validation portal Global Kit Validation portal  Invia i risultati dei test (informazioni sulle macchine: CPU type, CPU speed, Memory size …) a un Web service  I risultati dei test sono ottenuti effettuando un parsing dinamico dei logfile I tempi di processamento sono ottenuti dai servizi del framework di ATLAS I tempi di processamento sono ottenuti dai servizi del framework di ATLAS  I test vengono effettuati tramite uno script che installa le release del software di ATLAS ed è in grado di inviare più test concorrenti (utile per test su macchine multi-CPU e multi-core)

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Sistema di benchmark  Applicazioni eseguite: Generazione, Simulazione, Digitizzazione e Ricostruzione.  Si determina il power factor di vari processori confrontando i tempi di esecuzione rispetto ad una macchina di riferimento

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio i Tier2 partecipazione ai test CCRC e FDR-2 utilizzo delle risorse

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Reliability e Availability dei Tier2

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CSN1, Roma 2 Luglio core (fino al 21-3) 72 core (fino 3-6) 160 core Tier-2 Napoli Utilizzo Risorse 2008

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CSN1, Roma 2 Luglio Tier-2 Roma I

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 39 I Tier2 Italiani Considerazioni sui Tier2 italiani  Affidabilità e robustezza  Efficienza del 100% e velocità nel trasferimento dei dati dal CNAF  garanzia di reperibilità dei dati per l’analisi  I momenti di bassa attività sono legati soprattutto al rallentamento delle attività dell’esperimento o a problemi nei servizi della cloud l’utilizzo da parte degli utenti italiani per l’analisi distribuita è in significativa crescita l’utilizzo da parte degli utenti italiani per l’analisi distribuita è in significativa crescita  Qualche difficoltà si è avuta nel passato negli upgrade del middleware. Per il CCRC: SRM: passaggio alla v2.2 senza difficoltà SRM: passaggio alla v2.2 senza difficoltà SLC4: nessun problema nell’upgrade dei WN e dei server DPM SLC4: nessun problema nell’upgrade dei WN e dei server DPMSRM:  DPM estremamente affidabile e facile da gestire  STORM, dubbi sul futuro del supporto e la capacità di scalare di DPM (verificata in atlas almeno fino a 100 TB) consigliano di testarlo anche nei Tier2 Test di STORM al Tier2 di Milano Test di STORM al Tier2 di Milano Tutorial al CNAF il 2 e 3 luglio con gli sviluppatori di STORM e gli esperti di GPFS Tutorial al CNAF il 2 e 3 luglio con gli sviluppatori di STORM e gli esperti di GPFS

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 40 Risorse nei Tier2 e Richieste 2008

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Risorse necessarie - dati  LHC data taking Hz  10 7 eventi/giorno con 14h di data taking Hz  10 7 eventi/giorno con 14h di data taking 3·10 6 sec (6·10 8 eventi), corrispondenti a 2 mesi di data taking 3·10 6 sec (6·10 8 eventi), corrispondenti a 2 mesi di data taking Stima rivedibile in seguito alla reale durata della presa dati Stima rivedibile in seguito alla reale durata della presa dati LHC - Tier2 1.2 versioni complete di AOD 2.5 versioni di DPD primari 3.Frazione di RAW (metà della quota CNAF del 5%) 4.Frazione di ESD (metà della quota CNAF del 10%) Totale = ~350 TBn 3. e 4. per studi di performance dei rivelatori  Cosmics data taking presa dati complementare a LHC (~ 10 settimane) presa dati complementare a LHC (~ 10 settimane) fino ad ora dati trasferiti al Tier1 su disco e on demand ai Tier2 ma analisi su Castor soprattutto. fino ad ora dati trasferiti al Tier1 su disco e on demand ai Tier2 ma analisi su Castor soprattutto. Messa a punto recente di Ganga per runnare sui RAW data su pressione italiana  Analisi solo sui Tier2 (No Tier1!!) Messa a punto recente di Ganga per runnare sui RAW data su pressione italiana  Analisi solo sui Tier2 (No Tier1!!) 1.RAW e ESD (replica per l’analisi dei dati inviati al CNAF) 2.No AOD e DPD Totale = ~80 TBn Stima effettutata in base ai dati raccolti nelle week M6 e M7 supponendo circa il 10% in italia RAW = 1.6 MB - AOD = 0.2 MB ESD = 1 MB - DPD = 0.02 MB Cosmics - Tier2

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Risorse necessarie - Analisi Bisogna trovare un modo per garantire l’uso delle risorse dei Tier-2 italiani alla comunità italiana impedendo che le attività centrali di ATLAS o gli utenti non italiani le usino in maniera predominante 1. Creazione di un gruppo atlas/it a livello di VO 2. Job Priority Mechanism: definizione di quote dedicate per le varie attività (p.es. produzione 50% e analisi 50%) e i vari gruppi (atlas e atlas/it) definizione di quote dedicate per le varie attività (p.es. produzione 50% e analisi 50%) e i vari gruppi (atlas e atlas/it) 3. Fair-Share Mechanism per ottimizzare l’uso delle risorse bilanciamento temporale dell’uso delle risorse per impedire che rimangano inutilizzate quando non viene utilizzata completamente la quota dedicata ad una precisa attività o a un gruppo bilanciamento temporale dell’uso delle risorse per impedire che rimangano inutilizzate quando non viene utilizzata completamente la quota dedicata ad una precisa attività o a un gruppo Gennaio 08 Stato attule: CPU: Il gruppo atlas/it è stato creato e sarà operativo nei prossimi giorni perché si è attesa un unpgrade del WMS per la pubblicazione del sistema di priorità dei job nell’information system. È ora possibile inserire il gruppo italiano nel sistema fornendogli i privilegi nell’uso delle risorse dei Tier2 Disco: Spazio disco dedicato agli utenti italiani (Local Group Disk) Uso delle risorse per gli utenti italiani

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Risorse necessarie - Analisi  Analisi nei Tier2 analisi caotica da parte degli utenti analisi caotica da parte degli utenti produzione di DDPn produzione di DDPn analisi di gruppo: prevista al Tier1. Utilizzo delle risorse dei Tier2 anche per analisi di gruppo analisi di gruppo: prevista al Tier1. Utilizzo delle risorse dei Tier2 anche per analisi di gruppo presenza importante di italiani nei gruppi di fisica presenza importante di italiani nei gruppi di fisica replica completa di AOD e DPD nei Tier2 replica completa di AOD e DPD nei Tier2 Stato attuale:  fino al 2007 uso marginale dei Tier2 per l’analisi distribuita (ampia attività locale)  grande collaborazione della comunità italiana con gli sviluppatori per aumentare la semplicità di utilizzo, l’efficienza, l’individuazione dei siti sui cui runnare con GANGA  risoluzione di problemi tecnici: accesso allo storage con srm Storm e DPM accesso allo storage con srm Storm e DPM accesso ai RAW data e alla stream di calibrazione accesso ai RAW data e alla stream di calibrazione  FDR: partecipazione di molti gruppi italiani 13 gruppi (Higgs, SUSY, MS, Top, Tau, Etmiss, Trigger) 13 gruppi (Higgs, SUSY, MS, Top, Tau, Etmiss, Trigger) analisi nei Tier2 e uso di GANGA analisi nei Tier2 e uso di GANGA Alta efficienza (>95%), velocità di esecuzione e recupero degli output Alta efficienza (>95%), velocità di esecuzione e recupero degli output  gruppi di analisi: 13 2.Disco per gruppo: ~7 TBn 3.CPU per gruppo: ~80 kSI2k Totale = 100 TBn e 1000 kSI2k La stima delle risorse necessarie per gli utenti espresse in termini di numero di gruppi di analisi piuttosto che di numero di utenti appare piu’ realistica Tier2

G. Carlino: Il Computing di ATLAS CSN1, Roma 2 Luglio Risorse necessarie - MC June-Sept TeV Sept-Dec TeV Dec-Mar TeV 14 TeVtotal Geant420M25M 70M ATLFAST70M 210M total90M95M 280M Simulation timekSI2k·s Minimum Bias300 QCD700 W/Z, WH, Top600 SuSy1100 Higgs700 B-physics600 Il piano di produzione MC si basa sulla disponibilità delle risorse. Non tutte le nazioni hanno soddisfatto i pledges ai Tier1 e Tier2. Spostare la produzione quasi totalmente ai Tier2 per dedicare le risorse del CNAF soprattutto al reprocessing 1. 2 versioni di AOD 2. 5 versioni di DPD 3. Tier2 buffer per il MC per 2 settimane Storage = ~ 150 TBn CPU = ~ 500 kSI2k Tier2 HITS = 4 MB RDO = 2 MB ESD = 1 MB AOD = 0.2 MB

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 45 Risorse necessarie - riepilogo Attività CPU(kSI2k)Disco(TBn) LHC data taking 350 Cosmics data taking 80 Simulazione Utenti Totale

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 46 Risorse disponibili nei Tier2 CPU (kSI2k) Disco (TBr) Sep 07Gen 08Giu 08Sep 07Gen 08Giu 08 LNF Milano Napoli Roma Tot (TBn) (TBn) (TBn)  Sep 07 indica le risorse disponibili nella prima parte del 2007, Gen 08 indica le risorse acquisite nella seconda parte del 2007 con lo sblocco del sub judice 2007, Giu 08 indica le risorse acquisite o in fase di acquisizione con lo sblocco del primo sub judice 2008  1 CInt06_Rate = 0,2 kSI2k - 1 kSI2k = 5 CInt06_Rate

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 47 Richieste 2008 CPUDiscoTotale (kSI2k)K€TBnK€ Nuove necessità Risorse a Giugno (occupato) 210 (disponibile) hp1Richieste hp2Richieste Costi  CPU: 0.16 K€/kSI2k  Disco: 1.1 K€/TBn  Gli ultimi acquisti di storage sono in fase di installazione, vanno quindi considerati totalmente disponibili per le nuove attività e sottratti alle richieste  hp1 : richiesta della totalità dello storage necessario = 470 TBn Si eccede il budget potenzialmente disponibile per Atlas (metà della tasca indivisa) Si eccede il budget potenzialmente disponibile per Atlas (metà della tasca indivisa) L’esperimento richiede che una parte delle risorse disponibili per il computing venga destinata per l’acquisto di spare PS degli MDT L’esperimento richiede che una parte delle risorse disponibili per il computing venga destinata per l’acquisto di spare PS degli MDT hp2: richiesta di una frazione dello storage necessario = 300 TBn hp2: richiesta di una frazione dello storage necessario = 300 TBn Liberazione di gran parte dello spazio disco attualmente disponibile cancellando gradualmente i dati attuali e conservando solo cosmici e dati FDR utili per l’analisi Liberazione di gran parte dello spazio disco attualmente disponibile cancellando gradualmente i dati attuali e conservando solo cosmici e dati FDR utili per l’analisi La quota di 300 TBn corrisponde precisamente all’acquisto nei Tier2 di Mi, Na e RM1 di un sistema di storage di 110 TBr e 4 disk server, simile a quello appena acquistato La quota di 300 TBn corrisponde precisamente all’acquisto nei Tier2 di Mi, Na e RM1 di un sistema di storage di 110 TBr e 4 disk server, simile a quello appena acquistato Margine per la richiesta di 100 k€ per gli spare PS degli MDT Margine per la richiesta di 100 k€ per gli spare PS degli MDT

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 48 Backup slides

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 49 Attività Computing ATLAS Event Builder Event Filter Tier3 10 GB/s 320 MB/s ~PB/s Tier2 Tier0 Tier1 L’attività “sul campo” ha permesse di definire meglio molti aspetti del Computing Model  Attività nei Tier  Tier0: Prompt Reconstruction  Tier1: Reprocessing e Group Analysis parte significativa della Group Analysis puà essere spostata nei Tier2 in caso di necessità parte significativa della Group Analysis puà essere spostata nei Tier2 in caso di necessità  Tier2: Simulazione, Group e User Analysis  Definizione dei sistemi di storage  Pool di Storage per le specifiche attività lo spazio da assegnare ad ogni pool dovrà essere definito con precisione durante il periodo di data taking lo spazio da assegnare ad ogni pool dovrà essere definito con precisione durante il periodo di data taking  Flussi di dati

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 50 HITS ESD AOD HITS ESD AOD MC TAPE MC TAPE HITHIT MC Buffer MC Buffer PROD DISK PROD DISK CPUs Pile-updigitizationreconstruction G4 / ATLFAST Simulation HITS RDO ESD AOD DPD1 HITS RDO ESD AOD DPD1 MC DISK MC DISK AOD HITS AOD AOD from ATLFAST HITS from G4 AOD from ATLFAST TAPE AOD from ATLFAST HITS from G4 EVNT AOD MC DISK MC DISK All other T1’s AOD EVNT DPD GROUP DISK GROUP DISK DPD GROUP DISK GROUP DISK CPUs DPD User files (Atlas) DPD User files (Atlas) USERDISK Useranalysis User analysis Group analysis HITS from G4 AOD DPD1 making making DPD1 DPD2 DPD1 DPD2 DPD User files (IT) DPD User files (IT) LOCAL GROUPDISK

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 51 CPUs RAW AOD RAW AOD DATATA PE TAPE RAW t0atlas RAW STAGED ISK RAW ESD AOD RAW ESD AOD DATADISK AOD re-processing RAW AOD DATADI SK RAW ESD On request AOD DPD making AOD DPD All other T1’s DPD CPUs Group analysis User analysis DPD GROUP DISK GROUP DISK DPD GROUP DISK GROUP DISK AOD ESD DPD User files (IT) DPD User files (IT) LOCAL GROUPDISK DPD User files (Atlas) DPD User files (Atlas) USERDISK

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 52 T0 T1 T2 15% ESD, 15% AOD 10% ESD, 10% AOD 15% RAW, 15% ESD, 100% AOD AOD share 10% ESD, 10% AOD 15% ESD, 15% AOD Fake data generati al Tier0 con il Load Generator e trasmessi ai Tier1 e Tier2 in base al tipo di esercizio da svolgere lo share della cloud il MoU CCRC08 – Fase 2 File da 300 MB e 3 GB in accordo con le dimensioni dei file reali Dati cancellati solo alla fine dell CCRC

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 53 LOCALE NON DISPONIBILE LOCALE UPS E QUADRO PARALLELO CENTRALE TERMICA LOCALE IN FASE DI ALL. ZONA DI PERTINENZA TIER 2 ZONA DI PERTINENZA TIER 2 ZONA DI PERTINENZA TIER 2 Il Tier-2 di Milano La Sala Macchine e gli spazi per il Tier-2  8 Rack per ATLAS, 5 parzialmente occupati  4 rack (2 per ogni sala) connessi con fibra a 10 Gbps  Spazio e risorse per altri rack eventualmente necessari

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 54 Tier-2 Milano Utilizzo Risorse 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 55 Tier-2 Milano

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 56 Il Tier-2 di Napoli 4 Rack installati attualmente: Connessione tra i rack a 10 Gbps con switch in cascata Connessione tra i rack a 10 Gbps con switch in cascata Espansione fino a 10 Rack Impianti dimensionati per tale capacità Impianti dimensionati per tale capacità Sala ATLAS INFN Superficie 44 m 2 Superficie 44 m 2 La strategia è di suddividere il Tier2 nelle due sale con connessioni dirette a 10 Gbps

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 57 Il Tier-2 di Napoli Sala PON SCoPE Superficie 120 m 2 Superficie 120 m 2 Capacità 120 Rack. 10 Tier-2 a disposizione del Tier-2 Capacità 120 Rack. 10 Tier-2 a disposizione del Tier-2 Il Tier-2 di ATLAS verrà ospitato in questa struttura usufruendo di tutte le facilities di monitoraggio e intervento previste dal progetto Il Tier-2 di ATLAS verrà ospitato in questa struttura usufruendo di tutte le facilities di monitoraggio e intervento previste dal progetto In fase di installazione una connessione di rete costituita da 6 coppie di fibre monomodali a 10 Gbps tra la sala SCoPE e il Tier2 In fase di installazione una connessione di rete costituita da 6 coppie di fibre monomodali a 10 Gbps tra la sala SCoPE e il Tier2 Stato di avanzamento dei lavori (Giugno 2008) Stato di avanzamento dei lavori (Giugno 2008) Disponibilità autunno 2008 Disponibilità autunno 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 58 Tier-2 Napoli Utilizzo Risorse 2008 Miglioramento del rapporto CPU/Wall Time

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 59 Tier-2 Napoli

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 60 Tier-2 Roma I Utilizzo Risorse 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 61 CALCOLO Kloe Garr Nastri utenti Altri experim Sistema Informativ o Tier 2 Il proto Tier-2 di Frascati  La sala che ospita attualmente il proto-Tier2 è situata al pian terreno di un edificio a due piani che ospita il servizio di calcolo dei LNF, una libreria a nastro dell’esperimento Kloe, il sistema informativo dell’INFN ed il POP GARR dell’area di Frascati  Superficie 97 m 2.  Il Tier-2 occupa attualmente due rack e può essere espanso con altri tre rack  Può ospitare tranquillamente tutte le risorse previste per il 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 62 Proto Tier-2 Frascati Usage (%) CPU Time Wall time Utilizzo Risorse 2008

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 63 Proto Tier-2 Frascati

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 64 Attività di Computing in Italia Nuovo sistema di produzione Benchmarking CPU

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 65 Modifica del sistema di produzione nella cloud Italiana Sottomissione con i Pilot Job Utilizzo di PANDA, il tool usato per la produzione in OSG Utilizzo di PANDA, il tool usato per la produzione in OSG  ultima cloud a “resistere” alla migrazione  Pilot job:  sottomessione alla Grid di piccoli job (pilot job), praticamente equivalenti a quelli da runnare  invio attraverso un server centrale (Panda server) dei job reali ai pilot  Sistema utilizzato solo per la produzione e non per l’analisi  Vantaggi:  controllo maggiore sull’ordine di esecuzione dei job  job con priorità maggiore vengono processati prima anche se arrivati dopo  maggiore efficienza: non vengono inviati job verso nodi mal configurati. Solo il pilot job muore 1. Installazione di un Panda Server al Cern 2. Attivazione di una pilot factory al CNAF che rimpiazza lo scheduler dei pilot con un sistema più modulare interfacciato ai tool di LCG come WMS per la sottomissione dei job (sviluppata soprattutto in Italia) e la Dashboard Sistema operativo da aprile per la produzione MC e il reprocessing al CNAF Produzione in Italia

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 66 Produzione in Italia Produzione in LCG Produzione in Italia gridSuccessfailureefficiency LCG % OSG % None % Nordugrid % total % Dettaglio Produzione nelle tre griglie Quota produzione LCG ~ 65% 48,91% 4,64% 5,44% 10,76% 12,22% 17,97% BARI CNAF FRASCATI LEGNARO MILANO NAPOLI ROMA

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 67 number of jobs walltime gridsuccessfailureefficiency LCG % OSG % None % Nordugrid % total % Produzione in Italia

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 68 Sistema di benchmark Test della memoria

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 69 Tutti i task, eccetto per la simulazione, peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Tutti i task, eccetto per la simulazione, peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Peggior valore a full load Peggior valore a full load -10.9% in ricostruzione -10.9% in ricostruzione Scaling tests (Intel 2 x dual-core) Sistema di benchmark

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 70 Tutti i task, eccetto per la simulazione, peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Tutti i task, eccetto per la simulazione, peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Peggior valore a full load Peggior valore a full load -3.5% in ricostruzione -3.5% in ricostruzione Sistema di benchmark Scaling tests (AMD 2 x dual-core)

CSN1, Roma 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 71 Acquisti - Mercato Elettronico Esperienze con il MEPA Atlas ha effettuato nel 2008 acquisti in comune tra 3 Tier2 con il Mercato Elettronico Storage: gara con fatturazione separata Storage: gara con fatturazione separata Switch: gara con fatturazione unica a Na e consegna nelle varie sedi Switch: gara con fatturazione unica a Na e consegna nelle varie sedi  Problemi con il grey market. Sarebbe utile chiarire le procedure nell’INFN Esperienza: Difficoltà iniziale a comprendere le nuove regole del MEPA anche a causa di conoscenze ancora non diffuse nell’ente Difficoltà iniziale a comprendere le nuove regole del MEPA anche a causa di conoscenze ancora non diffuse nell’ente Difficoltà a definire contemporaneamente la precisa quantità di materiale da acquistare e il relativo prezzo massimo Difficoltà a definire contemporaneamente la precisa quantità di materiale da acquistare e il relativo prezzo massimo  Richiede un’indagine di mercato molto accurata  Rischio che le gare vadano deserte Ritardi dovuti all’arbitrarietà con cui la Consip annulla gare in corso Ritardi dovuti all’arbitrarietà con cui la Consip annulla gare in corso  Gara switch annullata per inserire nuovo categoria di metaprodotto Facilità a definire metaprodotti anche complicati Facilità a definire metaprodotti anche complicati Velocizzazione delle procedure Velocizzazione delle procedure Aumento dei fornitori iscritti Aumento dei fornitori iscritti Grande aiuto e disponibiltà da parte dell’amministrazione di Napoli Grande aiuto e disponibiltà da parte dell’amministrazione di Napoli