Il Computing di ATLAS Il Computing Challenge Gianpaolo Carlino I Tier2

Presentazione sul tema: "Il Computing di ATLAS Il Computing Challenge Gianpaolo Carlino I Tier2"— Transcript della presentazione:

1 Il Computing di ATLAS Il Computing Challenge Gianpaolo Carlino I Tier2
Richieste finanziarie 2008 Gianpaolo Carlino Referee Meeting CNAF, 20 Giugno 2008

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 Marzo-Aprile 2008: CCRC08-1.5: test di computing preparatori per il CCRC08-2 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 metriche molto esigenti 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. Giugno 2008 FDR-2 test delle procedure di validazione, ricostruzione e analisi distribuita dei dati

3 Il Computing Challenge in ATLAS
CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2 (mag 08)

4 Febbraio 2008: FDR-1 (Week 1) e CCRC08-1 (Weeks 2-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à 1031 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

5 FDR-1 e CCRC08-1 CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con le operazioni degli altri esperimenti LHC. 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) 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 picchi di 1.1 GBps per alcune ore Debugging (utilissimo) delle configurazioni dei Tier1 Replica dei dati nelle cloud (Week 4)

6 FDR-1 e CCRC08-1 CCRC-1. Attività di trasferimenti dal Tier0 ai Tier1/2 in contemporanea con le operazioni degli altri esperimenti LHC. Weekly Throughtput 2.1 GBps in uscita dal CERN

7 FDR-1 e CCRC08-1

8 FDR-1 e CCRC08-1

9 FDR-1 e CCRC08-1

10 Attività di Commissioning del Computing in ATLAS
CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2 (mag 08)

11 CCRC08-1.5 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 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. 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.

12 Functional Test di Aprile
CCRC08-1.5 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) 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 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

13 CCRC08-1.5 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) Conditions data su disco, 250 files, 35 input files per job Output su disco (Storm) e archiviato su nastro Esercizio di: stage dei file da tape (mai provato prima in Atlas) e copia su WN lettura file di input (conditions data) residenti su disco (Storm) 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. Attività da ripetere dopo il CCRC08-2.

14 Attività di Commissioning del Computing in ATLAS
CCRC08 – Fase 1 (feb 08) CCRC08 – Fase 1,5 (mar-apr 08) CCRC08 – Fase 2 (mag 08)

15 DDM Functional Test (FT)
CCRC08 - 2 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% 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 W E K I L M M G V S D W E K II L M G V S D W E K III L M G V S D W E K IV L M G V S D Metrica Replica completa al 90% dei dataset sottoscritti Replica dei dataset completata in 48h dalla sottoscrizione

16 CCRC08 - 2 Test superato da tutti i Tier1 Atlas e dal CNAF CNAF
W E K I L M G V S D CNAF (97% complete) W E K II Temporary failure (disk server) treated as permanent by DDM. Transfer not retried W E K III Test superato da tutti i Tier1 Atlas e dal CNAF W E K IV

17 CCRC08 - 2 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) 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) W E K II I L M G V S D III IV

18 CCRC08 - 2 Metrica Test molto challanging!! 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 Le sottoscrizioni partono contemporaneamente per tutti i Tier1  verifica della capacità del sistema di reggere un boost improvviso di richieste 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 W E K II I L M G V S D III IV Metrica Per ogni canale (Tier1-Tier1 pair) il 90% dei dataset deve essere completamente replicato nel tempo definito Test molto challanging!!

19 CCRC08 - 2 DAY1 All days (errors) All days MB/s I W E K II III IV L M
G V S D III IV MB/s All days (errors) All days

20 Frazione di dataset completati
CCRC08 - 2 W E K II I L M G V S D III IV Frazione di dataset completati FROM = Not Relevant 0% 20% 40% 60% 80% 100% TO

21 CCRC08 - 2 Attività concorrente con CMS sebbene non visualizzata in GridView!!! I trasferimenti nei canali Tier1-Tier1 non sono ancora monitorati W E K I L M M G V S D W E K II L M M G V S D W E K III L M G V S D W E K IV L M G V S D

22 Analisi dei Risultati:
CCRC08 - 2 Analisi dei Risultati: 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. W E K II I L M G V S D III IV

23 CCRC08 - 2 Risoluzione dei problemi:
W E K II I L M G V S D III IV Risoluzione dei problemi: 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) 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)

24 CCRC08 - 2 Throughput comunque limitato nei due giorni successivi
W E K II I L M G V S D III IV Throughput comunque limitato nei due giorni successivi alla fine del test anche in assenza di attività contemporanea negli altri siti.

25 DDM Throughput Test (TT)
CCRC08 - 2 W E K I L M G V S D 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 W E K II L M M G V S D L W E K III M M G V S D Metrica Ogni sito deve essere in grado di sostenere il peak rate per almeno 24 ore e il nominal rate per 3 giorni L M G V S D W E K IV

26 CCRC08 - 2 Rate Attesi Rates(MB/s) TAPE DISK Total
BNL IN2P SARA RAL FZK CNAF ASGC PIC NDGF TRIUMF Sum W E K I L M G V S D II III IV CNAF share del 5% corrispondente a 56 MBps

27 CCRC08 - 2 Data transfer complessivo W E K I L M G V S D II III IV

28 CCRC08 - 2 W E K I L M G V S D II III IV PEAK NOMINAL ERRORS

29 Analisi dei Risultati:
CCRC08 - 2 Analisi dei Risultati: 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 W E K I L M G V S D II III IV

30 Simulazione dell’intero set di trasferimenti Tier0  Tier1,
CCRC08 - 2 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 W E K II I L M G V S D III IV 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)

31 T0 T2 CCRC08 - 2 T1 Load Generator at 100%, NO RAW
K II I L M G V S D III IV T0 T1 T2 15% ESD, 15% AOD 10% ESD, 10% AOD 15% RAW, 15% ESD, 100% AOD AOD share

32 12h di backlog recuperati in 90 minuti
CCRC08 - 2 Tier0  Tier1 W E K II I L M G V S D III IV 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! Risolti problemi di throughput per trasferimenti dal Tier0: ~ 200 MBps per 2h Appena inizia il T1T1 il Cnaf rallenta ~5 MBps da ogni sito

33 CCRC08 - 2 T0 T1s data distribution Suspect Datasets
W E K II I L M G V S D III IV Suspect Datasets Datasets completi (OK) ma con doppia registrazione Incomplete Datasets Effetto del power-cut al CERN Venerdi mattina

34 CCRC08 - 2 Tier0 Tier1 transfers Expected Rate
W E K II I L M G V S D III IV Expected Rate Tier0 Tier1 transfers Problemi al load generator il 27 Power-cut il 30

35 Grande miglioramento rispetto a Week2
CCRC08 - 2 Tier1 - Tier1 transfer matrix W E K II I L M G V S D III IV DARK GREEN boxes Double Registration problem YELLOW boxes Effetto del power-cut Grande miglioramento rispetto a Week2

36 CCRC08 - 2 Produzione MC, in sovrapposizione alle altre attività
W E K II I L M G V S D III IV # running jobs # jobs/day

37 Analisi dei Risultati:
CCRC08 - 2 W E K II I L M G V S D III IV Analisi dei Risultati: 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 del numero di stream/file a 5

38 CCRC08 - 2 W E K II I L M G V S D III IV 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

39 Attività nell’intero mese, incluendo sia CCRC che commissioning
W E K IV III II I Attività nell’intero mese, incluendo sia CCRC che commissioning ssd stress tested

40 Considerazioni finali sul CCRC
M G V S D W E K IV III II I 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

41 CCRC08 - 2 Il CCRC al CNAF Problemi ancora aperti:
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 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 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 G V S D W E K IV III II I

42 i Tier2 partecipazione ai test CCRC e FDR-2 le infrastrutture
utilizzo delle risorse

43 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 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

44 Attività Computing ATLAS
CCRC-1,5 – Aprile 2008 Functional Tests: Distribuzione dei dati secondo MoU: 25% per ogni Tier2 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.

45 CCRC08 - 2 Tier0  Tier1  Tier2 Oversubscription a Na e Rm: 100% AOD
W E K II I L M G V S D III IV  Dataset  Files Eff Thr. MB/s LNF 86 169 100% 2.64 MI 88 180 2.88 NA 395 794 12,02 RM

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

47 CCRC08 - 2 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 W E K I L M G V S D II III IV Errori

48 FDR - 2 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 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 1032 e 250 Hz, 350 nb-1, con configurazioni diverse, ripetuti più volte 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 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 vari problemi di merging e ricostruzione, Esecuzione del Computing Model in maniera completa distribuzione dei dati e analisi distribuita Simulazione MC completa in parallelo running ai Tier-2, trasferimento dati e ricostruzione ai Tier-1

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%

50 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) 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. 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% 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 analisi dei DPD localmente nei Tier2 di riferimento (ARANA) Gruppi di analisi coinvolti Susy, Top, Higgs, MS, Minimum Bias, Trigger Analisi preliminari

51 Analisi del trigger nella muon stream:
FDR - 2 Analisi del trigger nella muon stream: 2m(10)(4)(6) jets minbias m10 m20 m40 m6 + Bphy t25i + totalE EtMiss Trigger decision @ EF L1 L2 EF offline muon (Muid) MU6 MU10 MU11 MU20 MU40 LVL1 selection barrel + endcaps muon pT (MeV)

52 FDR - 2 Tutte le analisi studiano preliminarmente la ricostruzione di Z e W Di- invariant mass Di-electron invariant mass Di-electron invariant mass

53 Analisi Susy nella stream e/gamma
FDR - 2 Analisi Susy nella stream e/gamma ETMISS PT 1ST jet muon pT (MeV) GeV/c Lepton-neutrino transverse mass GeV

54 FDR - 2 Molteplicità di particelle cariche nella stream Minimum Bias
Etmiss Etsum nella stream e/gamma:

55 Stream di calibrazione dei 
40 M/day 100 M/day Calibration center CERN 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) 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 CPU: ~150 kSI2k

56 Stream di calibrazione dei 
FDR: 43 M eventi analizzati al giorno (equivalenti a 6h di presa dati al giorno) Durata del test: 3 giorni Distribuzione dei dati: Trasferimento rapidissimo 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 Ritardo nelle registrazioni fino a 5h 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

57 Stream di calibrazione dei 
Database di calibrazione: Database locale Oracle nei siti di calibrazione Accesso delle applicazioni di calibrazione: OK T0, RT, validazione Replica in linea dei dati al CERN: OK Monitoring del database (Roma) con Spotlight Ottimizzazione delle query parallele Numero di connessioni Dati inseriti durante FDR-2 148 calibrazioni con tag FDR2

58 i Tier2 partecipazione ai test CCRC e FDR-2 muon calibration
le infrastrutture utilizzo delle risorse

59 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 LOCALE NON DISPONIBILE UPS E QUADRO PARALLELO CENTRALE TERMICA IN FASE DI ALL. ZONA DI PERTINENZA TIER 2

60 Il Tier-2 di Milano Impianto termico: Impianto elettrico:
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. Impianto termico: 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 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

61 Il Tier-2 di Napoli La strategia è di suddividere il Tier2 nelle
due sale con connessioni dirette a 10 Gbps Sala ATLAS INFN Superficie 44 m2 4 Rack installati attualmente: Connessione tra i rack a 10 Gbps con switch in cascata Espansione fino a 10 Rack Impianti dimensionati per tale capacità

62 Il Tier-2 di Napoli Sala PON SCoPE Superficie 120 m2
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 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) Disponibilità autunno 2008

63 Il Tier-2 di Napoli Impianto Elettrico: 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 Monitoraggio remoto dei parametri elettrici dell’armadio di zona Ad ogni rack arriva una linea elettrica trifase da 22KW Gruppo elettrogeno in comune con la sala SCoPE, verrà installato entro la metà del 2008 Impianto termico: 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 Raffreddamento ambientale della sala garantito da due unità da 6 KW Impianto Antincendio: Protezione dei rack Centralina che attraverso una coppia di rivelatori per rack (in AND) attiva la scarica all’interno dei rack stessi Protezione della sala Analogo funzionamento ma i sensori sono distribuiti nella sala dove avviene la scarica

64 Il Tier-2 di Roma1 Nuova sala disponibile da fine Novembre 2007
Dimensione sala 60 m2 espandibile fino a oltre 120 m2 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à) Impianto termico: Rack autocondizionati ad acqua della Knuerr Max potenza per rack: 17kW 2 chiller da 80 KW ognuno con doppia pompa indipendente Impianto Elettrico: Max potenza disponibile: 360 KVA 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. 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

65 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 m2. 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 CALCOLO Kloe Garr Nastri utenti Altri experim Sistema Informativo Tier 2 65

66 Il proto Tier-2 di Frascati
Impianto elettrico: Potenza attualmente necessaria: 15 kW (Atlas) + 40 kW (altre risorse) UPS da 160 KVA, autonomia 15’ 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 Impianto Antincendio: Impianto a gas inerte (FM200) dimensionato tenendo conto della destinazione d’uso e dimensione dei vari ambienti 66

67 i Tier2 partecipazione ai test CCRC e FDR-2 le infrastrutture
utilizzo delle risorse

68 Reliability e Availability dei Tier2

69 Tier-2 Milano Utilizzo Risorse 2008

70 Tier-2 Milano

71 Tier-2 Napoli Utilizzo Risorse 2008 60 core (fino al 21-3)

72 Tier-2 Napoli Utilizzo Risorse 2008 Miglioramento del
rapporto CPU/Wall Time

73 Tier-2 Napoli

74 Tier-2 Roma I Utilizzo Risorse 2008

75 Tier-2 Roma I

76 Proto Tier-2 Frascati Utilizzo Risorse 2008 Wall time Usage (%)
CPU Time Usage (%)

77 Proto Tier-2 Frascati

78 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 Qualche difficoltà si è avuta nel passato negli upgrade del middleware. Per il CCRC: SRM: passaggio alla v2.2 senza difficoltà SLC4: nessun problema nell’upgrade dei WN e dei server DPM SRM: 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) Tutorial al CNAF il 2 e 3 luglio con gli sviluppatori di STORM e gli esperti di GPFS

79 Attività di Computing in Italia
Nuovo sistema di produzione Benchmarking CPU

80 Produzione in Italia Modifica del sistema di produzione nella cloud Italiana Sottomissione con i Pilot Job 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 Installazione di un Panda Server al Cern 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

81 Produzione in Italia Produzione in LCG
Dettaglio Produzione nelle tre griglie grid Success failure efficiency LCG 72.1% OSG 358364 81.3% None 164476 254263 39.3% Nordugrid 427524 45134 90.5% total 73.9% Produzione in Italia BARI CNAF FRASCATI LEGNARO MILANO NAPOLI ROMA 48,91% 4,64% 5,44% 10,76% 12,22% 17,97% Quota produzione LCG ~ 65% La produzione in Italia nel semestre è stata rallentata dal passaggio

82 Produzione in Italia number of jobs walltime grid success failure
                                                                                               walltime                                                                                               grid success failure efficiency LCG 72.1% OSG 358364 81.3% None 164476 254263 39.3% Nordugrid 427524 45134 90.5% total 73.9%

83 La suite di benchmark di ATLAS
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 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 sviluppato per validare le installazioni del software (installazioni Grid e utente) 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 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)

84 Risultati dei test e summary table
Sistema di benchmark Risultati dei test e summary table

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

86 Sistema di benchmark Test della memoria

87 Sistema di benchmark Scaling tests (Intel 2 x dual-core)
Tutti i task, eccetto per la simulazione , peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Peggior valore a full load -10.9% in ricostruzione

88 Sistema di benchmark Scaling tests (AMD 2 x dual-core)
Tutti i task, eccetto per la simulazione , peggiorano quando si incrementa il numero di task concorrenti nella stessa macchina Peggior valore a full load -3.5% in ricostruzione

89 Risorse nei Tier2 e Richieste 2008

90 Risorse necessarie - dati Cosmics - Storage @ Tier2
LHC data taking Hz  106 eventi/giorno con 14h di data taking 3·106 sec (6·108 eventi), corrispondenti a 2 mesi di data taking Cosmics data taking 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. Messa a punto recente di Ganga per runnare sui RAW data su pressione italiana  Analisi solo sui Tier2 (No Tier1!!) LHC - Tier2 2 versioni complete di AOD 5 versioni di DPD (primari e secondari) Frazione di RAW (metà della quota CNAF del 5%) Frazione di ESD (metà della quota CNAF del 10%) Totale = ~350 TBn 3. e 4. per studi di performance dei rivelatori Cosmics - Tier2 RAW e ESD (replica per l’analisi dei dati inviati al CNAF) 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 90

91 Risorse necessarie - Analisi
Uso delle risorse per gli utenti italiani 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) 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 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) 91

92 Risorse necessarie - Analisi
Analisi nei Tier2 analisi caotica da parte degli utenti produzione di DnDP analisi di gruppo: prevista al Tier1. Utilizzo delle risorse dei Tier2 anche per analisi di gruppo presenza importante di italiani nei gruppi di fisica 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 ai RAW data e alla stream di calibrazione FDR-2: partecipazione di molti gruppi italiani 13 gruppi (Higgs, SUSY, MS, Top, Tau, Etmiss, Trigger) analisi nei Tier2 e uso di GANGA Alta efficienza (>95%), velocità di esecuzione e recupero degli output  utenti: 100 Disco: 1 TBn 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 92 92

93 Risorse necessarie - MC
June-Sept 08 10 TeV Sept-Dec 08 Dec-Mar 09 14 TeV total Geant4 20M 25M 70M ATLFAST 210M 90M 95M 280M Simulation time kSI2k·s Minimum Bias 300 QCD 700 W/Z, WH, Top 600 SuSy 1100 Higgs B-physics 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

94 Risorse necessarie - MC
HITS = 4 MB - ESD = 1 MB RDO = 2 MB - AOD = 0.2 MB Strategia di simulazione: G4 Hits prodotti nei Tier2 e uploaded nei Tier1 Hits su T1D1 Digi, Pile-up e Reco al Tier1 20% di RDO su disco AOD esportati agli altri Tier1 e ai Tier2 della cloud AOD prodotti nelle altre cloud importati al Tier1 e esportati ai Tier2 della cloud DPD primari prodotti dagli AOD al Tier1 e esportati ai Tier2 della cloud 2 versioni di AOD 5 versioni di DPD Tier2 buffer per il MC per 2 settimane Storage = ~ 150 TBn CPU = ~ 500 kSI2k Tier2 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

95 Risorse necessarie - riepilogo
Attività CPU (kSI2k) Disco (TBn) LHC data taking 350 Cosmics data taking 80 Simulazione 500 150 Utenti 1000 100 Totale 1500 680

96 Risorse disponibili nei Tier2
CPU (kSI2k) Disco (TBr) Sep 07 Gen 08 Giu 08 LNF 41 101 169 16 48 63 Milano 128 214 343 34 84 140 Napoli 112 210 330 40 152 Roma 156 383 30 66 133 Tot 437 908 1225 120 100 (TBn) 238 198 (TBn) 488 407 (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

97 Richieste 2008 CPU Disco Totale Nuove necessità 2008
Costi CPU: 0.16 K€/kSI2k Disco: 1.1 K€/TBn CPU Disco Totale (kSI2k) K€ TBn Nuove necessità 2008 1500 680 Risorse a Giugno 2008 1225 200 (occupato) 210 (disponibile) hp1 Richieste 300 50 470 520 570 hp2 330 380 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) 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 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 Margine per la richiesta di 100 k€ per gli spare PS degli MDT

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€ Consumo Richiesta di 3 k€ per ogni Tier2 CPU Disco Switch Consumo Totale kSI2k K€ TBn LNF 30 5 3 38 Milano 90 15 100 118 Napoli 3.5 121.5 Roma Tot 300 50 330 12 395.5

99 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 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à 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 Gara switch annullata per inserire nuovo categoria di metaprodotto Facilità a definire metaprodotti anche complicati Velocizzazione delle procedure Aumento dei fornitori iscritti Grande aiuto e disponibiltà da parte dell’amministrazione di Napoli