Il Computing di ATLAS Gianpaolo Carlino CSN1 Roma, 2 Giugno 2008 Il Computing Challenge I Tier2 I Tier2 Richieste finanziarie 2008 Richieste finanziarie 2008

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 2 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 CCRC08-1,5  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 sosprattutto un test delle operazioni al Tier0, di funzionalità del sistema e di installazione e configurazione di SRM 2.2  Marzo-Aprile 2008:  CCRC08-1.5: 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 T0  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

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 3 Il Computing Challenge in ATLAS CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2(mag 08) CCRC08 – Fase 2 (mag 08)

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 4 FDR-1 e CCRC08-1 Febbraio 2008: FDR-1 (Week 1) e CCRC08-1 (Weeks 2-4)  FDR-1: simulazione dell’intera catena di computing dall’online all’analisi distribuita  dati similati con physics mix a luminosità  Run Hz dagli SFO  Full Tier0 Operations: calibrazione, data quality, first pass reconstruction, sottoscrizione e trasferimento ai Tier1. Dell’intera catena ci si è concentrati soprattutto sulle operazioni al Tier0 che hanno richiesto più tempo del previsto. Inoltre limitata disponibilità dei dati mixati  Setup dei site services di Atlas  Test degli endpoint SRM 2.2  definizione degli Space tokes, ACLs  Configurazione canali FTS

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 5 CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con le operazioni degli altri esperimenti LHC. FDR data exports (Week 2) FDR data exports (Week 2) 2 set di dati: day 1&2 (molti errori a causa di problemi di certificazione interni al Tier0) e day 3 (100% eff.) “real” CCRC exercise (Week 3) “real” CCRC exercise (Week 3)  dati prodotti con il load generator al Tier0 di grandezze nominali da 300 MB a 3 GB (FDR data non sufficienti)  Rump Up al rate nominale. Share come da CM e MoU  Target 900 MBps sostenuto 24h  Risultati relativamente buoni: Throughput 700 MBps per 2 giorni Throughput 700 MBps per 2 giorni picchi di 1.1 GBps per alcune ore picchi di 1.1 GBps per alcune ore Debugging (utilissimo) delle configurazioni dei Tier1 Debugging (utilissimo) delle configurazioni dei Tier1 Replica dei dati nelle cloud (Week 4) FDR-1 e CCRC08-1

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 6 CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con le operazioni degli altri esperimenti LHC. WeeklyThroughtput 2.1 GBps in uscita dal CERN FDR-1 e CCRC08-1

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 7 FDR-1 e CCRC08-1

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 8 FDR-1 e CCRC08-1

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 9 FDR-1 e CCRC08-1

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 10 Attività di Commissioning del Computing in ATLAS CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2(mag 08) CCRC08 – Fase 2 (mag 08)

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 11  Il CCRC08-1 è stato un utilissimo esercizio per debuggare le operazioni al Tier0, il sistema di distribuzione dei dati e le configurazioni dei siti (per la prima volta si è usato in molti siti SRM2.2).  Sono state rimandate alla fase 1.5 e 2: debugging approfondito delle configurazioni dei sistemi ai Tier1 e Tier2 debugging approfondito delle configurazioni dei sistemi ai Tier1 e Tier2 ripetizione dei test con i sistemi più stabili e richiedendo metriche quantitative stringenti ripetizione dei test con i sistemi più stabili e richiedendo metriche quantitative stringenti  3 attività per il periodo pre CCRC-2:  Tier0 processing e data distribution (ripetizione dei Functional Test e dei Throughput Test) per tunare significativamente il sistema  Trasferimenti incrociati tra i Tier1 per configurare i canali FTS  Tier1 M5 data reprocessing job di test (250 files) per ogni cloud per testare le varie procedure. OK in 9/10 clouds. job di test (250 files) per ogni cloud per testare le varie procedure. OK in 9/10 clouds.  Produzione ai Tier2 Utilizzo in tutti i siti di SRM2.2. Test alla scala reale (necessità di spazio disco, carente in tutti i siti). Test delle operazioni reali: shifts, comunicazioni etc. CCRC08-1.5

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 12 Functional Test di Aprile 1 settimana di trasferminenti al rate nominale, rispettando lo share tra i siti del MoU (CNAF 5%) e il CM (AOD replicati in tutte le cloud su disco, RAW data su tape, una copia nell’insieme dei Tier1, ESD su disco 2 copie nell’insieme dei Tier1) 1 settimana di trasferminenti al rate nominale, rispettando lo share tra i siti del MoU (CNAF 5%) e il CM (AOD replicati in tutte le cloud su disco, RAW data su tape, una copia nell’insieme dei Tier1, ESD su disco 2 copie nell’insieme dei Tier1) Per molti siti si è superata una efficienza del 95% richiesta come metrica di successo per il test. Problemi: catalogazione doppia degli eventi in LFC (suspicious datasets). Baco in DDM per cui non vengono catalogati dataset effettivamente trasferiti e viene quindi ripetuto il trasferimento catalogazione doppia degli eventi in LFC (suspicious datasets). Baco in DDM per cui non vengono catalogati dataset effettivamente trasferiti e viene quindi ripetuto il trasferimento problema ai disk server del CERN perché il load generator generava troppi file molto piccoli per cui alcuni dati si sono persi e non sono stati trasferiti problema ai disk server del CERN perché il load generator generava troppi file molto piccoli per cui alcuni dati si sono persi e non sono stati trasferiti CCRC08-1.5

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 13  Reprocessing dei dati M5 al CNAF  Attività primaria per un Tier1 effettuato su un subset dei dati M5 Un dataset di 250 job per Tier1 (5 TB) Un dataset di 250 job per Tier1 (5 TB) Conditions data su disco, 250 files, 35 input files per job Conditions data su disco, 250 files, 35 input files per job Output su disco (Storm) e archiviato su nastro Output su disco (Storm) e archiviato su nastro  Esercizio di: 1. stage dei file da tape (mai provato prima in Atlas) e copia su WN 2. lettura file di input (conditions data) residenti su disco (Storm) 3. sottomissione dei job con il sistema dei pilot (prima applicazione in Italia)  Efficienza 93% (con 60 retries). Durata 27 h. Durata singolo job ~60 min.  Efficienza 93% (con 60 retries). Durata 27 h. Durata singolo job ~ 60 min.  Attività da ripetere dopo il CCRC08-2. CCRC08-1.5

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 14 Attività di Commissioning del Computing in ATLAS CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2 (mag 08) CCRC08 – Fase 2 (mag 08)

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC DDM Functional Test (FT) Studio dell’efficienza del sistema di trasferimento dei dati Trasferimenti Tier0  Tier1s Nessuna attività nei Tier2 Dati prodotti con il load generator al Tier0 corrispondenti al 40% del nominal rate per 3 giorni Dataset sottoscritti agli endpoint Tape e Disk secondo gli share MoU RAW data su Tape – CNAF 5% RAW data su Tape – CNAF 5% ESD su Disk nei siti che ospitano i corrispondenti RAW – CNAF 5% ESD su Disk nei siti che ospitano i corrispondenti RAW – CNAF 5%  in preparazione al T1-T1 della Week 2 AOD sottoscritti completamente a tutti i Tier1 AOD sottoscritti completamente a tutti i Tier1 Metrica Replica completa al 90% dei dataset sottoscritti Replica dei dataset completata in 48h dalla sottoscrizione

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 (97% complete) CCRC Test superato da tutti i Tier1 Atlas e dal CNAF

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 (T1T1) Trasferimenti incrociati Tier1s  Tier1s Studio dell’efficienza del sistema di distribuzione dei dati simulando il trasferimento dei dati prodotti nel reprocessing (Tier1-Tier1 transfer matrix) Nessuna attività nei Tier2  Replica degli ESD della Week 1 da ogni Tier1 a tutti gli altri ESD su disco (T0D1), non precisamente la configurazione finale del reprocessing (T1D1) ESD su disco (T0D1), non precisamente la configurazione finale del reprocessing (T1D1)  Ripetizione in scala maggiore del test effettuato da tutti i Tier1 in Marzo-Aprile: 10 siti attivi contemporaneamente in ingresso e uscita  Test delle configurazioni dei canali FTS  Sito sorgente sempre definito (nessun trasferimento caotico) CCRC08 - 2

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 Timing: definizione molto attenta dell’inizio e della fine del test: inizio alle 10AM del 13 Maggio e fine alle 2 PM del 15 Maggio definizione molto attenta dell’inizio e della fine del test: inizio alle 10AM del 13 Maggio e fine alle 2 PM del 15 Maggio Le sottoscrizioni partono contemporaneamente per tutti i Tier1  verifica della capacità del sistema di reggere un boost improvviso di richieste Le sottoscrizioni partono contemporaneamente per tutti i Tier1  verifica della capacità del sistema di reggere un boost improvviso di richieste Volume di dati: Volume di dati: 629 datasets corrispondenti a 18TB di dati da replicare in ogni Tier1 Throughtput: 90 MB/s import rate per ogni Tier1. Superiore al rate nominale 90 MB/s import rate per ogni Tier1. Superiore al rate nominale CCRC Metrica Per ogni canale (Tier1-Tier1 pair) il 90% dei dataset deve essere completamente replicato nel tempo definito Test molto challanging!!

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno DAY1 All days All days (errors) CCRC 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 MB/s

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 - 2

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC Attività concorrente con CMS sebbene non visualizzata in GridView!!! I trasferimenti nei canali Tier1-Tier1 non sono ancora monitorati

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC 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 nell’import da molti siti ! Efficienza media 45% e throughput medio 40 MBps  I test effettuati in aprile erano riusciti: efficienza ~ 100% e alto throughput. Il fatto che coinvolgevano solo 3 Tier1 a6lla volta e non era previsto flusso di uscita ha mascherato alcuni problemi nella configurzione. Problemi individuati:  Alto carico sui server GridFTP: traffico in uscita dai server doppio di quello in ingresso dovuto alla riscrittura dello stesso dato. Ciò limita il traffico in ingresso  Problema legato all’interazione tra GridFTP e GPFS (differenza nella block-size, 64 kB vs 1 MB). Si manifesta quando il numero delle stream/file sui canali FTS è maggiore del numero di server GPFS.

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC 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 Risoluzione dei problemi: 1.Riduzione del numero di stream/file sul sever FTS del CNAF al numero di server GPFS (4). Ciò però limita il throughput (necessario aumentare di molto il numero di file concorrenti) 2.Aumentati a 6 i server GridFTP per distribuire meglio il carico Risoluzione parziale: nessuna riscrittura ma sempre basso throughput  È stato prolungata di due giorni la durata del test recuperando parte del backlog  È stato effettuato un nuovo test T1T1 autonomamente nel fine settimana con buoni risultati. Problema di efficienza superato. Da verificare la capacità di effettuare trasferimenti ad alto throughput (Week 3) Problema di efficienza superato. Da verificare la capacità di effettuare trasferimenti ad alto throughput (Week 3)

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC 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 Throughput comunque limitato nei due giorni successivi alla fine del test anche in assenza di attività contemporanea negli altri siti.

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 DDM Throughput Test (TT) Trasferimenti ad alto rate Tier0  Tier1  Tier2 Simulazione dell’export dei dati dal Tier0 per 24h/day di data taking a 200 Hz ~ 150% del nominal rate di 14h/day No Oversubscription per aumentare il throughput. Se non si ha alta efficienza (>90%) non si raggiunge il rate nominale CCRC Metrica Ogni sito deve essere in grado di sostenere il peak rate per almeno 24 ore e il nominal rate per 3 giorni

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Rate Attesi Rates(MB/s)TAPEDISK Total BNL IN2P SARA RAL FZK CNAF ASGC PIC NDGF TRIUMF Sum CCRC 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC Data transfer complessivo

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 - 2

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC Analisi dei Risultati: Il test è stato superato: Il test è stato superato: si è sostenuto il rate di picco per 24h e il rate nominale per 72h Al CNAF: Il test è stato parzialmente superato  Trasferimenti sempre lenti  Non si è riusciti a superare il rate nominale, in caso di backlog determinato da periodi di inefficienze alla sorgente o alla destinazione non si riusciva ad “accelerare” i trasferimenti (come succede agli altri siti) per recuperarlo Problemi individuati:  interazione tra GridFTP e GPFS a limitare il throughput  Errata configurazione dello storage aggiuntivo (20 TB) da parte degli installatori (un solo canale collegato) causa della lentezza di trasferimenti.  Individuato solo alla fine della settimana 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC DDM Full Exercise Simulazione dell’intero set di trasferimenti Tier0  Tier1, Tier 1  Tier1, Tier1  Tier2  Si considera il rate 14h/day di data taking  Si considera il reprocessing a full rate (200 Hz)  Primi due giorni: test di funzionalità  Ultimi due giorni: test di throughput I siti vengono “appesantiti” da un’alta sottomissione di job di produzione MC nei Tier1 e Tier2. si aggiungono i trasferimenti MC tra Tier2 e Tier1 si aggiungono i trasferimenti MC tra Tier2 e Tier1 Metrica Tier0  Tier1: 90% dei dataset completi in 6 ore dalla fine del test Tier1  Tier1 (functional): 90% dei dataset completi in 6 ore Tier1  Tier1 (throughput): mantenimento del rate di tasferimenti del reprocessing Tier1 gemello previsto dal MoU per tutta la durata del test (CNAF: 10 MBps di ESD e 20 MBps di AOD)

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 Load Generator at 100%, NO RAW Load Generator at 100% CCRC 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC Risolti problemi di throughput per trasferimenti dal Tier0: ~ 200 MBps per 2h Appena inizia il T1T1 il Cnaf rallenta ~5 MBps da ogni sito

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Suspect Datasets completi Datasets completi (OK) ma con doppia registrazione Suspect Datasets completi Datasets completi (OK) ma con doppia registrazione Incomplete Datasets Effetto del power-cut al CERN Venerdi mattina Incomplete Datasets Effetto del power-cut al CERN Venerdi mattina 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 CCRC T0  T1s data distribution

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Tier0  Tier1 transfers Problemi al load generator 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 - 2

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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 CCRC Tier1 - Tier1 transfer matrix

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno # running jobs # jobs/day 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 CCRC Produzione MC, in sovrapposizione alle altre attività

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC Analisi dei Risultati: Ogni sito ha superato il test: Ogni sito ha superato il test: nonostante problemi di power cut al Cern e al load generator il primo giorno nonostante il problema delle doppie sottoscrizioni Al CNAF: Il test (sia T0T1 che T1T1) è stato superato in extremis risolvendo il problema della lentezza dei trasferimenti che causava il basso throughput e la bassa efficienza (time-out dei job) Risoluzione del problema:  Upgrade dei server GridFTP a SLC4 aumento a 256 kB della block size e quindi miglioramento del problema delle riscritture aumento a 256 kB della block size e quindi miglioramento del problema delle riscritture aumento del numero di stream/file a 5 aumento del numero di stream/file a 5 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC  Aumento del throughput (fattore ~2) dopo le 13 del 29-5 per l’upgrade a SLC4 dei server GridFTP  Throughput medio 125 MBps e recupero molto veloce del backlog  Test superato in extremis 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno ssd Attività nell’intero mese, incluendo sia CCRC che commissioning stress tested CCRC L M M G V S D W E K IV M M G V S D W E K III L W E K II L M M G V S D L M M G V S D WEEKIWEEKI

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno CCRC Considerazioni finali sul CCRC  Il sistema di distribuzione dei dati era uno degli item critici di Atlas e destava 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 le due fasi del CCRC  Grande collaboriazione tra il gruppo ADC e le clouds  Il giudizio finale è positivo. È 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 Computing Model  Efficienze e throughput molto alti ! Attività principali dei prossimi mesi:  Test del reprocessing ai Tier1 e uso del tape  Definizione precisa e test accurati della classe di storage T1D1 in tutti i sti L M M G V S D W E K IV M M G V S D W E K III L W E K II L M M G V S D L M M G V S D WEEKIWEEKI

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 41 CCRC Il CCRC al CNAF 1.Configurazione: Il commissioning ha messo in evidenza che alcuni aspetti del sistema di storage non erano perfettamente compresi e i testi effettuati in precedenza non erano stati sufficientemente accurati da evidenziarli 2.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. 3.Il sistema è ancora poco robusto e richiede un’attenzione continua Problemi ancora aperti:  Interazione tra GridFTP e GPFS, bisogna approfondire le conoscenze su GridFTP.  T1D1. Test effettuati in LHCb permettono di essere confidenti sull’uso di Storm per questa classe di storage. È necessario effettuare test dedicati in collaborazione tra Atlas e il CNAF per verificare che il sistema sia in grado di soddisfare le richieste dell’esperimento  Vero problema per i prossimi mesi: IL DISCO!!! Il ritardo dell’acquisizione dei pledge 2008 mette l’esperimento in seria difficoltà. Necessità di aumentare le attività ai Tier2 L M M G V S D W E K IV M M G V S D W E K III L W E K II L M M G V S D L M M G V S D WEEKIWEEKI

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno i Tier2 partecipazione ai test CCRC e FDR-2 le infrastrutture utilizzo delle risorse

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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  CCRC-1&2 - test di distribuzione dei dati –  i Tier2 hanno partecipato al test replicando i dati trasmessi al CNAF dal Tier0  studio dell’efficienza dei trasferimenti  studio del timing dei trasferimenti  FDR-2 – 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 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 44 Attività Computing ATLAS Efficienza dei Tier2 italiani: 100%. Il test mostra che si possono ottenere ottimi livelli di funzionalità per esercizi specifici di breve durata. E’ necessario una grande attenzione sullo stato dei siti. Il target è raggiungere per lunghi tempi gli stessi risultati e senza interventi umani. CCRC-1,5 – Aprile 2008 Functional Tests: Distribuzione dei dati secondo MoU: 25% per ogni Tier2

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 45 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 CCRC Tier0 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 46 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 CCRC 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 47 CCRC 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 CNAF, 20 Giugno FDR - 2 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 49 FDR - 2 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 CNAF, 20 Giugno FDR - 2 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 dagli AOD e DPD primari prodotti centralmente con i DPDMaker del gruppo di analisi produzione in grid di DPD di gruppo o utente dagli AOD e DPD primari prodotti centralmente con i DPDMaker del gruppo di analisi 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 CNAF, 20 Giugno 10)(4)(6) jets minbias 10 20 40 6 + Bphy 25i + 10 totalE + EtMiss Trigger EF FDR - 2 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno FDR - 2 Tutte le analisi studiano preliminarmente la ricostruzione di Z e W Di-electron invariant mass Di-  invariant mass

G. Carlino: Il Computing di ATLAS Milano, 30 Aprile FDR - 2 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

G. Carlino: Il Computing di ATLAS Milano, 30 Aprile FDR - 2 Etmiss Etsum nella stream e/gamma: Molteplicità di particelle cariche nella stream Minimum Bias

G. Carlino: Il Computing di ATLAS Milano, 30 Aprile 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 Milano, 30 Aprile 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, dovuti ad errori di accesso ai cataloghi di NorduGrid Problemi con i cataloghi centrali, ora risolti, dovuti ad errori di accesso ai cataloghi di NorduGrid 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  I dati arrivati nei siti sono stati comunque processati entro il termine di 24h a partire dalla presa dati nonostante il problema di registrazione 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 Milano, 30 Aprile Stream di calibrazione dei  Database di calibrazione:  Database locale Oracle nei siti di calibrazione Accesso delle applicazioni di calibrazione: OK Accesso delle applicazioni di calibrazione: OK  T0, RT, validazione Replica in linea dei dati al CERN: OK Replica in linea dei dati al CERN: OK  Monitoring del database (Roma) con Spotlight Ottimizzazione delle query parallele Ottimizzazione delle query parallele Numero di connessioni Numero di connessioni  Dati inseriti durante FDR calibrazioni con tag FDR2 148 calibrazioni con tag FDR2

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno i Tier2 partecipazione ai test CCRC e FDR-2 muon calibration le infrastrutture utilizzo delle risorse

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Impianto elettrico: Gruppo di continutà da 200 KVA corrispondenti a 160 KW, autonomia 15’. Gruppo di continutà da 200 KVA corrispondenti a 160 KW, autonomia 15’. Ordinato un gruppo elettrogeno da 400 KVA in esclusivo uso della sala macchine, in grado di sopperire alle esigenze della parte elettrica e del sistema di raffreddamento. Autonomia 11 ore. Ordinato un gruppo elettrogeno da 400 KVA in esclusivo uso della sala macchine, in grado di sopperire alle esigenze della parte elettrica e del sistema di raffreddamento. Autonomia 11 ore. Impianto termico: Il sistema di condizionamento realizzato per l’intera sala è costituito da due chiller da 90 kW termici ognuno Il sistema di condizionamento realizzato per l’intera sala è costituito da due chiller da 90 kW termici ognuno Modifiche al sistema di distribuzione dell’aria sono già previste per ottimizzarlo Modifiche al sistema di distribuzione dell’aria sono già previste per ottimizzarlo Impianto Antincendio: Il sistema attualmente installato non copre tutte le zone previste, nel prossimo anno è prevista la sua revisione e la sostituzione dell’estinguente attualmente non più a norma Il sistema attualmente installato non copre tutte le zone previste, nel prossimo anno è prevista la sua revisione e la sostituzione dell’estinguente attualmente non più a norma Il Tier-2 di Milano

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Il Tier-2 di Napoli Impianto Elettrico: Max potenza disponbile: 250 kW Max potenza disponbile: 250 kW 2 Gruppi di continuità da 60 kVA in parallelo. Autonomia a pieno carico 7’. In corso installazione sistema di videosorveglianza 2 Gruppi di continuità da 60 kVA in parallelo. Autonomia a pieno carico 7’. In corso installazione sistema di videosorveglianza Monitoraggio remoto dei parametri elettrici dell’armadio di zona Monitoraggio remoto dei parametri elettrici dell’armadio di zona Ad ogni rack arriva una linea elettrica trifase da 22KW Ad ogni rack arriva una linea elettrica trifase da 22KW Gruppo elettrogeno in comune con la sala SCoPE, verrà installato Gruppo elettrogeno in comune con la sala SCoPE, verrà installato entro la metà del 2008 entro la metà del 2008 Impianto termico: Chiller con capacità di raffreddamento di 90 kW, due compressori indipendenti Chiller con capacità di raffreddamento di 90 kW, due compressori indipendenti Rack autoraffreddanti RIMatrix della Rittal con potenza dichiarata di 12kW espandibile a 20 KW modificando la temperatura e i flussi dell’acqua Rack autoraffreddanti RIMatrix della Rittal con potenza dichiarata di 12kW espandibile a 20 KW modificando la temperatura e i flussi dell’acqua Raffreddamento ambientale della sala garantito da due unità da 6 KW Raffreddamento ambientale della sala garantito da due unità da 6 KW Impianto Antincendio: Protezione dei rack Protezione dei rack Centralina che attraverso una coppia di rivelatori per rack (in AND) attiva la scarica all’interno dei rack stessiCentralina che attraverso una coppia di rivelatori per rack (in AND) attiva la scarica all’interno dei rack stessi Protezione della sala Protezione della sala Analogo funzionamento ma i sensori sono distribuiti nella sala dove avviene la scaricaAnalogo funzionamento ma i sensori sono distribuiti nella sala dove avviene la scarica

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Il Tier-2 di Roma1 Nuova sala disponibile da fine Novembre 2007 Dimensione sala 60 m 2 espandibile fino a oltre 120 m 2 Dimensione sala 60 m 2 espandibile fino a oltre 120 m 2 4 rack disponibili per Atlas, connessi a 10 Gbps 4 rack disponibili per Atlas, connessi a 10 Gbps Capacità della sala: 14 rack con gli attuali impianti, fino a 21 modificando la rete idraulica (progettata per questa eventualità) Capacità della sala: 14 rack con gli attuali impianti, fino a 21 modificando la rete idraulica (progettata per questa eventualità) Impianto termico: Rack autocondizionati ad acqua della Knuerr Rack autocondizionati ad acqua della Knuerr Max potenza per rack: 17kW Max potenza per rack: 17kW 2 chiller da 80 KW ognuno con doppia pompa indipendente 2 chiller da 80 KW ognuno con doppia pompa indipendente Impianto Elettrico: Max potenza disponibile: 360 KVA Max potenza disponibile: 360 KVA UPS da 120 KVA, un secondo simile in consegna a marzo 2008 con autonomia di 10’ a pieno carico UPS da 120 KVA, un secondo simile in consegna a marzo 2008 con autonomia di 10’ a pieno carico Impianto Antincendio: Impianto a gas inerte che agisce sull'intera sala macchine e all’interno dei rack. Impianto a gas inerte che agisce sull'intera sala macchine e all’interno dei rack. Sensori posti sia nella sala che all’interno dei rack Sensori posti sia nella sala che all’interno dei rack La centralina di controllo è situata all'interno della sala macchine e verrà collegata con un sistema di allarmistica alla vigilanza dello stabile La centralina di controllo è situata all'interno della sala macchine e verrà collegata con un sistema di allarmistica alla vigilanza dello stabile

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno 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

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Il proto Tier-2 di Frascati Impianto elettrico: Potenza attualmente necessaria: 15 kW (Atlas) + 40 kW (altre risorse) Potenza attualmente necessaria: 15 kW (Atlas) + 40 kW (altre risorse) UPS da 160 KVA, autonomia 15’ UPS da 160 KVA, autonomia 15’ Gruppo elettrogeno da 120 kW in azione dopo un minuto Gruppo elettrogeno da 120 kW in azione dopo un minuto Impianto termico: L’impianto di raffredamento esistente e’ a circolazione d’acqua ricavato deviando una parte del condizionamento di Dafne L’impianto di raffredamento esistente e’ a circolazione d’acqua ricavato deviando una parte del condizionamento di Dafne Impianto Antincendio: Impianto a gas inerte (FM200) dimensionato tenendo conto della destinazione d’uso e dimensione dei vari ambienti Impianto a gas inerte (FM200) dimensionato tenendo conto della destinazione d’uso e dimensione dei vari ambienti

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno i Tier2 partecipazione ai test CCRC e FDR-2 le infrastrutture utilizzo delle risorse

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Reliability e Availability dei Tier2

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Tier-2 Milano Utilizzo Risorse 2008

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Tier-2 Milano

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno 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 CNAF, 20 Giugno Tier-2 Napoli Utilizzo Risorse 2008 Miglioramento del rapporto CPU/Wall Time

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Tier-2 Napoli

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Tier-2 Roma I Utilizzo Risorse 2008

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Tier-2 Roma I

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Proto Tier-2 Frascati Usage (%) CPU Time Wall time Utilizzo Risorse 2008

G. Carlino: Il Computing di ATLAS IV – Test e Commissioning CNAF, 20 Giugno Proto Tier-2 Frascati

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 78 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 (vedi talk di F. Prelz) Test di STORM al Tier2 di Milano (vedi talk di F. Prelz) 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 79 Attività di Computing in Italia Nuovo sistema di produzione Benchmarking CPU

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 80 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 81 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 La produzione in Italia nel semestre è stata rallentata dal passaggio

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

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 83 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)

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 84 Sistema di benchmark Risultati dei test e summary table

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 85 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

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

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 87 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 88 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 89 Risorse nei Tier2 e Richieste 2008

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Risorse necessarie - dati  LHC data taking Hz  10 6 eventi/giorno con 14h di data taking Hz  10 6 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 LHC - Tier2 1.2 versioni complete di AOD 2.5 versioni di DPD (primari e secondari) 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 CNAF, 20 Giugno 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 ma non è ancora operativo 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: Lo spazio a disposizione per gli utenti nei Tier2 è del 27% secondo il CM. Frazione di questo sarà dedicato agli utenti italiani e il resto come zona scratch per gli altri utenti di atlas (discussione in corso in Atlas) Uso delle risorse per gli utenti italiani

G. Carlino: Il Computing di ATLAS CNAF, 20 Giugno Risorse necessarie - Analisi  Analisi nei Tier2 analisi caotica da parte degli utenti analisi caotica da parte degli utenti produzione di DnDP produzione di DnDP 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 in 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-2: 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  utenti: Disco: 1 TBn 3.CPU: 10 kSI2k Totale = 100 TBn e 1000 kSI2k 1. L’attività durante l’FDR ci autorizza a considerare realistica questa stima 2. Stima di Atlas: 1.5 TBn 3. ~4 core Tier2

G. Carlino: Il Computing di ATLAS CNAF, Giugno 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  La nostra strategia è di spostare la produzione il più possibile ai Tier2 per dedicare le risorse del CNAF soprattutto al reprocessing

G. Carlino: Il Computing di ATLAS CNAF, Giugno Risorse necessarie - MC Strategia di simulazione: 1.G4 Hits prodotti nei Tier2 e uploaded nei Tier1 2.Hits su T1D1 3.Digi, Pile-up e Reco al Tier % di RDO su disco 5. AOD esportati agli altri Tier1 e ai Tier2 della cloud 6.AOD prodotti nelle altre cloud importati al Tier1 e esportati ai Tier2 della cloud 7. DPD primari prodotti dagli AOD al Tier1 e esportati ai Tier2 della cloud 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 - ESD = 1 MB RDO = 2 MB - AOD = 0.2 MB Ricostruzione:  Merging dei file di input (circa 10 RDO per job) al Tier1  avviene soprattutto ai Tier1 perché richiede molti file di input da replicare ai Tier2  I task vengono assegnati alla cloud, i job al Tier1 o ai Tier2 in base ad un criterio di ranking che tiene conto del numero di slot disponibili, delle code e di un fattore di peso, definito dalla cloud, che penalizza i Tier2 (maggiore è il peso peggiore è il rank dei Tier2)  Il tuning del peso permette di variare il rapporto reco/simu al Tier1 e ai Tier2  In caso di necessità e di risorse disponibili possiamo aumentare il rapporto ai Tier2

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 95 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 96 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, Mag 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 97 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 98 Richieste 2008 Ulteriori richieste:  Switch di rete per il quarto rack a Napoli Si prevede l’acquisto di un quarto switch 3Com dello stesso tipo acquistato in tutti i Tier2 per garantire la connessione a 10 Gbps tra i WN e lo Storage: 3.5 k€ Si prevede l’acquisto di un quarto switch 3Com dello stesso tipo acquistato in tutti i Tier2 per garantire la connessione a 10 Gbps tra i WN e lo Storage: 3.5 k€  Consumo Richiesta di 3 k€ per ogni Tier2 Richiesta di 3 k€ per ogni Tier2CPUDiscoSwitchConsumoTotale kSI2kK€TBnK€ LNF Milano Napoli Roma Tot

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 99 Richieste 2008 Proposta dei Referee:  Nessuna assegnazione a Frascati  Stime necessita’ per LHC ridotte a 250 TBn invece di 350TBn, corrispondente a 2·10 6 s  Altre necessita’ come da richieste  Variazione stima dei costi: CPU 0.15 k€/kSI2k, Disco 1 k€/TBn  Consumi: utilizzo del sj assegnato a settembre (5 k€). Rm e LNF devono ancora chiedere lo sblocco CPUDiscoSwitchConsumoTot AtlasRefereeAtlasRefereeARARR kSI2kK€kSI2kK€TBnK€TBnK€ LNF Milano Napoli , Roma Tot ,

CSN1, Roma, 2 Luglio 2008 G. Carlino: Il Computing di ATLAS 100 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