Verso la presa dati Il Computing di ATLAS

Presentazione sul tema: "Verso la presa dati Il Computing di ATLAS"— Transcript della presentazione:

1 Verso la presa dati Il Computing di ATLAS
I primi dati Commissioning del Computing Attività nella cloud italiana Richieste 2009 Gianpaolo Carlino CSN1 Pisa, 16 Settembre 2008

2 I primi eventi – 10/09/08

3 I primi eventi – 10/09/08

4 I primi eventi – 10/09/08 I dati vengono distribuiti!
Il DAQ ha chiuso il primo run verso le ed è subito iniziato il trasferimento dei RAW data su tape e di ESD su disco a tutti i Tier1 …… Primo Evento al CNAF di ATLAS: Run Event: 40050

5 Tutti i dataset, sia RAW che ESD, sono stati completamente replicati
I primi eventi – 10/09/08 … e ai Tier2 Tutti i dataset, sia RAW che ESD, sono stati completamente replicati

6 L’accesso agli ESD con Ganga nei Tier2 e la ricostruzione funzionano!
I primi eventi – 10/09/08 L’accesso agli ESD con Ganga nei Tier2 e la ricostruzione funzionano!

7 Attività di Commissioning del Computing in ATLAS
(breve riassunto, dettagli nella CSN1 del 2 Luglio)

8 Commissioning del Computing
ATLAS ha svolto un’intensa attività di test per arrivare pronti al primo evento Febbraio 2008: FDR-1: simulazione dell’intera catena di software & computing CCRC08–1: test della distribuzione dei dati T0 T1  T2 sosprattutto un test delle operazioni al Tier0, di funzionalità del sistema e di installazione e configurazione di SRM 2.2 e canali FTS Maggio 2008 CCRC08-2: test intensivo del DDM, T0 T1  T2 e T1  T1 test di funzionalità e throughput con metriche molto esigenti 4 settimane di test con incremento graduale delle complessità dei test Giugno 2008 FDR-2: simulazione dell’intera catena di software & computing test delle procedure di validazione, ricostruzione e analisi distribuita dei dati test di analisi nei Tier2: accesso ai dati e tool di analisi distribuite (Ganga) Estate 2008 Functional Test trasferimenti continui tra tutti i siti (70 circa in tot) di dati generati al Cern al 10% del rate nominale per tenere sempre sotto osservazione il sistema

9 CCRC08 – Fase 2 Throughput Test PEAK NOMINAL
Simulazione dell’export dal Tier0 Hz (150% del rate nominale)

10 12h di backlog recuperati in 90 minuti
CCRC08 – Fase 2 Throughput Test 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! ~ 200 MBps per 2h

11 CCRC08 – Fase 2 Tier1 – Tier1 Test
Studio dell’efficienza nei trasferimenti incrociati e contemporanei tra Tier1 18 TB corrispondenti a 90 MBps di inport rate per ogni Tier1 (superiore al rate nominale)

12 CCRC08 – Fase 2. I Tier2 Tier0  Tier1  Tier2
Oversubscription a Na e Rm: 100% AOD Tier1  Tier2 Replica molto veloce, max 1.5 h dalla richiesta di sottoscrizione studio dell’efficienza dei trasferimenti studio del timing dei trasferimenti  Dataset  Files Eff Thr. MB/s LNF 86 169 100% 2.64 MI 88 180 2.88 NA 395 794 12,02 RM Alta efficienza dei Tier2: Replica dei dati con eff. 100% e alto throughput Affidabilità dei Tier2: Recupero immediato del backlog con un throughput fino a 100 MBps in caso di necessita’

13 Final Dress Rehearsal Analisi nei Tier2:
Test dell’intero computing system, dall’on-line/trigger all’analisi distribuita, come se si trattasse di dati reali, per evidenziare i problemi che si potrebbero verificare durante il data taking Analisi nei Tier2: Utilizzo esclusivo dei Tier2 italiani per l’analisi Test di accesso ai dati e running dei job di analisi con Ganga 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 con i DPDMaker dagli AOD e DPD primari prodotti centralmente analisi dei DPD nei Tier2 di riferimento (ARANA) Gruppi di analisi coinvolti Susy, Top, Higgs, MS, Minimum Bias, Trigger Risultati non particolarmente rilevanti dal punto fisico. Lo scopo era di familiarizzare con i tool e testare tutti gli aspetti della catena

14 Analisi del trigger nella muon stream:
Final Dress Rehearsal 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)

15 Attività nei Tier2 Attività principale degli utenti nella prima settimana dell’FDR2: Attività principale degli utenti nella prima settimana dell’FDR2: calibrazione dei mu Attività principale degli utenti nella seconda settimana dell’FDR2: analisi

16 Commissioning del Computing
Considerazioni finali sul CCRC e FDR Il sistema di distribuzione dei dati era un item critico di Atlas. Preoccupazione negli utenti (scarsa fiducia sulla possibilità di reperire i dati con velocità ed efficienza). Il commissioning di questo sistema ha focalizzato l’attenzione durante il CCRC. Giudizio finale positivo: efficienze e throughput molto alti. Sw stabile e affidabile. È stato effettuto un debugging approfondito delle configurazioni di tutte le parti del sistema testando, ben oltre gli use cases previsti per il data taking 2008, tutti i tipi di trasferimenti previsti dal CM L’FDR ha testato l’intera catena del computing, dal DAQ all’analisi distribuita. Dopo le prime fasi di “registrazione” il Tier0 è stato in grado di ricostruire i dati e inviarli ai Tier1 L’analisi distribuita è stata testata sia con Ganga che con PAthena. Alta efficienza e velocità Esercizio troppo breve per poter essere considerato un vero commissioning dell’analisi distribuita, manca un test di continuità, di robustezza e stress L’attività “sul campo” ha permesso di definire meglio molti aspetti del Computing Model. A inizi 2009 ATLAS apporterà le necessarie modifiche in base alle indicazioni ottenute con la presa dati 2008

17 Attività nella cloud Italiana e Richieste 2009

18 Attività al CNAF Il CCRC08
Al CNAF numerosi problemi con lo storage che hanno comportato throughput e efficienze bassi per lunghi periodi. Il test è stato superato solo negli ultimi giorno quando i problemi tecnici sono stati compresi e risolti Il periodo Giugno-Luglio Attività molto rallentata nella cloud italiana a causa di numerosi problemi al CNAF sia di carattere strutturale che di instabilità del middleware e dei servizi (in particolare il catalogo locale, LFC) Stato di “quasi crisi”. La stretta collaborazione tra CNAF e ATLAS-IT ha portato all’individuazione dei problemi e alla loro risoluzione: miglioramento della struttura di supporto e controllo delle attività al Tier1 individuazione dei servizi critici (LFC) e studio delle soluzioni per renderli più stabili e soprattutto ridondarli studio e test delle configurazioni dello storage

19 Attività al CNAF L’estate
Attività al CNAF soddisfacente senza interruzioni né dei servizi né della struttura Produzione al Tier1 e ai Tier2 con alta efficienza ritornata agli share che ci competono Functional Test continuo al 10% del nominal rate con efficienza sempre 100% Test del Reprocessing dei dati in tutti i Tier1 e al CNAF Ridondanza dei servizi vitali della cloud: Studio di fattibilità della replica del catalogo locale con Oracle Data Guard Piani futuri test di carico al CNAF con le nuove configurazioni dello storage (Tier2) in corso test sullo storage a Milano per la migrazione a Storm anche nei Tier2 effettuati test positivi di installazione e configurazione, in corso test di funzionalità su un cluster di WN e storage dedicati

20 Uso delle CPU della farm del CNAF
Attività al CNAF CPU garantite per ATLAS: 440 kSI2k (quota 2007, dalla prossima settimana saranno disponibili le risorse 2008: 1034 kSI2k) Nei periodi di attività si evidenziano picchi superiori allo risorse garantite E’ evidente l’aumento dell’uso delle risorse nel periodo Agosto-Settembre Uso delle CPU della farm del CNAF

21 Job di produzione in Atlas
Attività in Italia La produzione in Italia ha runnato sempre quando c’è stata attività in ATLAS Job di produzione in Atlas La interruzioni sono dovute alla validazione delle nuove release del software

22 Attività in Italia Produzione in LCG 2007 Produzione in LCG Gen-Lug 08
Produzione in Ago-Set 08 Produzione IT in LCG = 16.6% Prod. IT nel mondo = 7.5% Produzione in Italia Produzione in Italia Produzione in Italia BARI CNAF FRASCATI LEGNARO MILANO NAPOLI ROMA 48,91% 4,64% 5,44% 10,76% 12,22% 17,97%

23 Attività in Italia VO Atlas

24 Attività nei Tier2 Tier2 di Napoli Utilizzo Risorse 2008
60 core (fino al 21-3) 72 core (fino 3-6) 160 core

25 Il Reprocessing Attività primaria in un Tier1
Processo composto di quattro fasi i cui tool sono stati recentemente definiti e testati: stage dei file da tape e copia su WN utilizzo del tool DDM di pre-stage dei dataset da castor tape su disk buffer file di input (Conditions Data) replicati in Oracle stream su disco (Storm) e copiati su WN ~ 35 input file per job sottomissione dei job con il sistema dei pilot copia separate dei file di output su Storm (T0D1) e tape (T1D0).

26 Il Reprocessing Test a agosto con i dati dell’ FDR2
30 task da circa 100 job (10000 ev. per file) Durata singolo job ~ 150 min test separato dei tool di prestaging e reprocessing efficienza 100% in tutte cloud alcuni retries nella copia dei file su WN dovuti a un problema di timeout nei trasferimenti ora compreso Funzionamento positivo del sw di Athena, failure nella reco < 1% e nessun errore nell’accesso al DB . Next: reprocessing dei dati di FDR2 e cosmici Test più significativo: realistici file size e composizione delle eventi nell’FDR ma aumento della statistica grazie ai file di cosmici Tier1 Efficienza CA 100% DE 99% ES FR IT NL TW UK down US NDGF No fdr2 data CERN

27 Ridondanza dei servizi della cloud
Replica del catalogo locale LFC Le interruzioni al CNAF hanno evidenziato la necessità di replicare l’ LFC, vero single point of failure nel modello di calcolo di ATLAS, per evitare che l’intera cloud sia completamente inattiva in caso di down del Tier1 Ipotesi iniziale replica in un altro Tier1 al momento gli altri Tier1 non sono disponibili ad impegnare risorse e manpower sebbene ne riconoscano la necessità Ipotesi praticabile: replica in uno dei Tier2 italiani: Roma1 LFC è un db ORACLE. Il sistema Data Guard può essere usato per replicare remotamente l’LFC del CNAF sul db di Roma1 Switch automatico a Roma1 del db dal ruolo Standby a quello di Produzione in R/W mode Intervento manuale al CNAF per restituire al CNAF db il ruolo di Produzione Trasparente alle applicazioni di Atlas attraverso alias nel DNS Il CNAF e ATLAS IT si sono impegnati a testare il sistema entro Novembre Da comprendere le eventuali licenze necessarie CNAF Roma1

28 Analisi nei Tier2 dopo l’FDR2 attività quantitativamente limitata (l’analisi fisica è proseguita localmente soprattutto per finalizzare i risultati del CSC) ma qualitativamente importante FDR2c a fine agosto esercizio soprattutto per il test delle funzionalità del Tier0, nei Tier2 test della stabilità di Ganga con le nuove release del sw di Atlas: OK aumento dell’uso dei Tier2 per il commissioning dei rivelatori es: LVL1. produzione delle nuove matrici di coincidenze e confronto decoding on-line/off-line con i cosmici interazione gruppi di fisica e computing. Creazione di un gruppo misto per individuare tutte le necessità dell’analisi e trovare le soluzioni per l’uso dei Tier2 anche per l’analisi “semi-interattiva” in grid (attività fino ad ora eseguita localmente ma che con l’aumento dei dati previsto per il 2009 necessiterà di tutte le risorse dei Tier2) e per le attività di sviluppo per definire soluzioni per l’uso non standard di Ganga e eventuali strategie alternative aumento del contributo italiano al gruppo ATLAS di GANGA per risolvere i problemi di accesso ai dati (RAW e HITS) e per produrre un controllo automatico del funzionamento dei tool

29 Risorse dedicate per gli utenti italiani nei Tier2
Attività nei Tier2 Risorse dedicate per gli utenti italiani nei Tier2 ridefinizione delle aree di storage per seperare le quote per la collaborazione (per gruppi o singli utenti Atlas) e quelle per gli utenti italiani Meccanismo di job priorities per riservare le CPU all’analsi (italiana) definizione di quote dedicate per le varie VO o attività (p.es. produzione e analisi) 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 Test del meccanismo di job priorities Si è testato che i job di utenti con ruoli diversi di distribuiscono nel tempo non in base all’ordine di arrivo nella coda, ma in modo da soddisfare in un dato intervallo una percentuale di utilizzo delle risorse impostata nel batch system: atlas = 70% atlasprd = 30%

30 Disco nei Tier1 ATLAS (Luglio 2008)
Risorse CNAF 2009 Pledges 2008 Disco nei Tier1 ATLAS (Luglio 2008) Contributo del CNAF ad Atlas Disco: 4%. CPU: 5% Tape: 6% Tier1 più piccolo in assoluto! … e le risorse 2008 saranno disponibili solo a fine settembre

31 Risorse CNAF 2009 Piano sviluppo Referee Settembre 2007
Piano sviluppo ATLAS (somma dei Tier1) Il superamento dei problemi verificatisi al CNAF e la fine dei lavori di ristrutturazione della sala, oltre alla convinzione che il 2009 possa essere un anno di piena attivita’ di LHC, consigliano di non andare sotto le percentuali indicate nel piano di sviluppo per non ridurre la competitività della cloud italiana (vedi problema LFC) e la sua centralità nell’esperimento. L’ideale sarebbe un piano di sviluppo in cui si torni in pochi anni ad una percentuale coerente con il numero di autori: il 10% Rapporto CNAF/ATLAS 2009 Disco = 1148/21456 (TBn) = 5.3% CPU = /31367 (kSI2k) = 8% Tape = /12584 (TBn) = 10.3%

32 Risorse Tier2 2009 - LHC 75ns operation 25ns operation 2009
Train to 7TeV Machine checkout Beam Setup 75ns operation 25ns operation Shutdown B C No beam Beam 2009 LHC data taking 100 giorni di Fisica 14h di data taking (50k sec/day) 5· Hz  109 eventi 320 MB/s 1.6 PB/year di RAW, 1.0 PB/year di ESD, > 0.1 PB/year di AOD LHC - Tier2 2 versioni complete di AOD 5 versioni di DPD primari Frazione di RAW (2%, circa metà della quota CNAF) No ESD Totale = ~ 500 TBn 3. per studi di performance dei rivelatori 4. Sostituiti dagli “heavy” DPD RAW = 1.6 MB - AOD = 0.2 MB ESD = 1 MB DPD = 0.02 MB 32

33 Risorse Tier2 2009 - Analisi Utenti @ Tier2 Totale = 350 TBn
analisi di gruppo. Prevista soprattutto al Tier1. In caso di limitate risorse al Tier1 o per riservare completamente le CPU al reprocessing si aumenta la quota svolta al Tier2 analisi caotica da parte degli utenti per studi di fisica e/o performance: produzione di DPD secondari da AOD o heavy DPD analisi dei DPD in Grid calibrazioni dei mu (MDT, LVL1, RPC) sviluppo codice (uso à la lxplus ma in Grid) Tier2  gruppi di analisi: 20 Disco per gruppo: ~ 14,5 TBn CPU per gruppo: ~80 kSI2k Totale = 350 TBn e 1600 kSI2k Spazio disco per gli utenti generici di Atlas e per gli utenti italiani (non incluso nei pledges) 2. Si assume che lo spazio disco necessario scali con la luminosità integrata. Fattore di scala 2009 vs 2008 = 5/2 ( vs sec). Per il 2008 si sono considerati 7 TBn a gruppo Assumiamo di poter recuperare per le attività 2009 metà dello spazio disco utenti assegnato per il 2008 fino al 2007 uso marginale dei Tier2 per l’analisi distribuita (ampia attività locale) attività di analisi connesse al commissioning soprattutto al Cern FDR nel 2008: partecipazione di molti gruppi italiani 15 gruppi (Higgs, SUSY, MS, Top, Tau, Etmiss, Trigger) Previsione per il 2009 circa 20 gruppi italiani di analisi Fisica: W/Z (2), SUSY (2), Top, Higgs (3), Jets, Hidden Valley, Z’, Bphys Performance, Calibrazione: EM Calo / Photon ID, Pixel, Tau/Etmiss, btag trigger, Jet calib e reco, LVL1 muon, RPC, MDT, combined muons

34 Risorse Tier MC Atlas prevede di simulare nel 2009 una frazione dei dati raccolti così definita: Full simulation: 20%  2 · 108 eventi Fast simulation: 45%  4.5 · 108 eventi Nel corso dell’anno si verificheranno le risorse effettivamente disponibili e si deciderà lo sviluppo temporale delle simulazioni in maniera realistica. La simulazione viene svolta anche nei Tier1 se le risorse sono disponibili. La strategia è di dedicare le risorse del CNAF al reprocessing e massimizzare l’uso dei Tier2. La ricostruzione dei dati MC prodotti nei Tier2 puà essere eseguita nei Tier2 stessi con un leggere carico supplementare del DDM nella cloud. Tuning delle attività presentazione di G. Polesello per i dettagli Simulation time kSI2k·s Minimum Bias 300 QCD 700 W/Z, WH, Top 600 SuSy 1100 Higgs B-physics 2 versioni di AOD 5 versioni di DPD Tier2 buffer per il MC per 2 settimane Storage = ~ 350 TBn CPU = ~ 850 kSI2k Tier2 HITS = 4 MB RDO = 2 MB ESD = 1 MB AOD = 0.2 MB

35 Risorse Tier2 2009 - riepilogo
Attività CPU (kSI2k) Disco (TBn) LHC data taking 500 Cosmici 50 Simulazione 850 340 Utenti 1600 350 Totale 2450 1240

36 Risorse Tier2 2009- riepilogo
CPU (kSI2k) Disco (TBn) Richieste ATLAS 2450 1240 Piano ATLAS 2351 1208 Piano Referee 2228 1304 Settembre 2007

37 Risorse disponibili nei Tier2
CPU (kSI2k) Disco (TBr) Gen 08 Giu 08 Dic 08 LNF 101 169 48 63 Milano 214 343 424 84 140 251 Napoli 210 330 430 40 152 264 Roma 383 457 66 133 245 Tot 908 1225 1480 238 198 (TBn) 488 391 (TBn) 823 680 (TBn) Gen 08 indica le risorse acquisite nella seconda parte del 2007 con lo sblocco del sub judice 2007, Giu 08 le risorse acquisite con lo sblocco del primo s.j e Dic 2008 la stima delle risorse disponibili a fine anno con lo sblocco del secondo s.j. 2008 Le risorse del secondo sblocco s.j sono in fase di acquisizione Il valore dei TB netti riportato per Giugno 2008 è quello effettivo e non il semplice TBr/1.2 come calcolato precedentemente. Sono stati escluse le risorse obsolete al Dic 08

38 Determinazione delle necessità di storage
Richieste 2009 – Tier2 CPU Disco kSI2k K€ TBn Necessità attività 2009 2450 1240 Necessità attività 2008 200 Risorse a Dicembre 2008 1480 680 Richieste 2009 970 114 760 Costi CPU: 0.12 K€/kSI2k Disco: 1.0 K€/TBn Determinazione delle necessità di storage Allo storage necessario per le nuove attività 2009 va sommato quello per conservare i dati del Deve rimanere su disco: l’ultima versione degli AOD e dei DPD del 2008 per l’analisi = ~150 TB la metà dello spazio disco destinato agli utenti per il 2008 = ~ 50 TB Suddivisione per sedi 30% per i Tier2 approvati 10% per il proto Tier2

39 Richieste 2009 – Tier2 Ulteriori richieste: Switch di rack Consumo
Si prevede l’acquisto di switch 3Com dello stesso tipo già acquistato in tutti i Tier2 per garantire la connessione a 10 Gbps tra i WN e lo Storage Nell’ipotesi di finanziamento da parte della CCR di un router centrale per i Tier2 prevediamo connessioni in fibra per ogni switch Nel caso il router non venisse finanziato nel 2009 sarà comunque possibile connettere tra di loro gli switch con gli stessi moduli in fibra garantendo il throughput 4 switch acquistati nel 2008 a Mi, Na e Rm. 2 da acquistare a Na e Rm e 3 a Mi nel 2009 in base ai rack che si prevede di occupare Moduli in fibra per 4 switch a Rm e 5 a Mi (moduli per 2 switch già disponibili) e per 6 switch a Na 2 switch per Frascati, connessione in rame a 10 Gbps tra il rack di WN e quello dei disk server, il terzo rack contiene i dischi con i controller connessi in fibre channel ai disk server Consumo Richiesta di 5 k€ per ogni Tier2

40 Conclusioni Considerazioni sui Tier2 italiani
Il computing di Atlas ha mostrato un notevole grado di maturazione in molti sue parti durante il commissioning. Alcune, come l’analisi distribuita, vanno però testate in maniera più approfondita e utilizzate per tutte le applicazioni. Il 10 Settembre l’esperimento è stato in grado di acquisire immediatamente i dati e, per quanto riguarda il computing off-line, di ricostruirli, replicarli con efficienza nei Tier1 e nei Tier2 e analizzarli. 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 la comprensione e l’utilizzo da parte degli utenti italiani dei tool di analisi distribuita sono in crescita grazie al maggior confronto tra gli utenti stessi e la comunità del computing Considerazioni sul CNAF Il CCRC ha permesso di testare e debuggare in maniera significativa l’hardware e il middleware del CNAF. I problemi evidenziati nei mesi scorsi sembrano efficacemente superati e l’attività procede con continuità

41 Backup slides

42 Final Dress Rehearsal Simulazione di 1 fill di presa dati
Test dell’intero computing system, dall’on-line/trigger all’analisi distribuita, come se si trattasse di dati reali per evidenziare i problemi che si potrebbero verificare durante il data taking Simulazione di 1 fill di presa dati 4 Run di 1 hr a 1032 e 250 Hz, 1.5 pb-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 Run della trigger simulation 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 ricostruzione e validazione sulla ES per verificare la qualità dei dati. Test del “calibration loop” Bulk reconstruction sulle physics stream (anche DPD da ESD inizialmente) vari problemi di merging e ricostruzione evidenziati e risolti Esecuzione del Computing Model in maniera completa distribuzione dei dati e analisi distribuita Simulazione MC completa in parallelo

43 Final Dress Rehearsal Tutte le analisi studiano preliminarmente la ricostruzione di Z Di- invariant mass Di-electron invariant mass eventi calibrati eventi scalibrati Di-electron invariant mass

44 La Produzione MC Uso dei pilot job da circa 6 mesi (tranne NDGF)

45 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

46 La Produzione MC Av. Job eff = 77% e Av. Walltime eff: 86%
Attività a pieno carico durante il CCRC-2 e FDR (picchi di 16 kslots/day) Av. Job eff = 77% e Av. Walltime eff: 86% Quota produzione LCG ~ 65%

47 Analysis Model (update)
ESD (Event Summary Data) contengono output dettagliato della ricostruzione permettono la particle ID, track-refitting, jet finding, calibrazioni (long term) target size = 500 kB/ev attualmente = 800 kB/ev kB/ev (MC truth) AOD (Analysis Object Data) summary dell’evento ricostruito sufficiente per le analisi comuni permette ricostruzioni limitate (tracce, cluster) (long term) target size = 100 kB/ev attualmente = 200 kB/ev + 30 kB/ev per il MC DPD (Derived Physics Data) versioni ridotte (skimming, slimmed, thinning) degli AOD Group Level o primary DPD (D1PD) versioni filtrate di AOD/ESD con container selezionati solo per numerosi gruppi di analisi (prodotti ai Tier1) User level DPD: secondary DPD (D2PD) versioni filtrate di D1PD con UserData per analisi individualie e tertiary DPD (D3PD) root file rinali contenenti histo/ntuple per la pubblicazione (prodotti ai Tier2) target size di D1PD = 10 kB/ev (variazioni in base al canale fisico) ESD/AOD/D1,2PD hanno lo stesso formato ROOT/POOL per cui leggebili sia da Athena che da ROOT (usando la libreria AthenaRootAccess)

48 LAN Tier2 – situazione attuale
La rete dei Tier2 LAN Tier2 – situazione attuale La connessione a 10 Gbps tra i rack è garantita da Switch 3Com stackable. Connessione in rame per distanze inferiori ai 3 m Connessione in fibra per distanze superiori (p.es. sale diverse) La connessione con il Garr è a 1 Gbps, sufficiente per le esigenze attuali 1 Gbps RACK n n+1 10 Gbps Rame m m+1 Fibra Cluster di Rack 1 Cluster di Rack 2

49 LAN Tier2 – situazione futura
La rete dei Tier2 LAN Tier2 – situazione futura Ogni rack sarà connesso a 10 Gbps verso un router centro stella del Tier2 connesso direttamente a 10 Gbps verso il Garr. Gli switch di rack usati attualmente possono sempre impiegati anche nella nuova configurazione comprando i moduli per le fibre dove mancano Tempi? Il gruppo NetArc della CCR sta studiando la fattibilità dell’upgrade Nel frattempo, anche se non si definisce l’acquisto del router centrale, proponiamo l’acquisto degli switch necessari per i nuovi rack con i moduli in fibra 10 Gbps verso il GARR 10 Gbps Fibra 10 Gbps Fibra 10 Gbps Fibra 10 Gbps Fibra RACK m RACK m+1 RACK n RACK n+1 Cluster di Rack 1 Cluster di Rack 2

50 Computing Shifts Definita la tipologia di shift necessari per seguire le operazioni di computing: On line trigger, DAQ Tier-0: Tier0 operations, first and second pass reconstruction della ES e bulk reconstruction delle physics streams, registrazione dei dataset nei cataloghi centrali Data Export dal Tier0, Monitoring dei servizi centrali dell’ADC Produzione: Data Export dal Tier0 ai Tier1, Produzione MC, Reprocessing, Critical Data Replications e servizi centrali. Shift Remoti Gli Shift di produzione sono già attivi dallo scorso anno, i Tier0 e sono svolti per ora dagli esperiti per finalizzare le procedure e i tool e da settembre verranno svolti da tutti i membri di Atlas (all’inizio anche quando non c’è data taking)

51 Controllo dello attività in Italia
Monitoraggio del funzionamento della cloud italiana Controllo del funzionamento dei Tier2 e del Tier1 Controllo del funzionamento della attivita’ di computing in Italia Definita una check list comprendente la lista dei servizi dei siti e le pagine delle dashboards che monitorano l’andamento di tutte le attivita: produzione, trasferimenti etc… Contributo di tutti i gruppi italiani. Organizzazione suddivisa in tre fasi Controlli compiuti dalle persone del computing dei Tier2 e del Tier1 per ottimizzare e debuggare l’attività, determinare le procedure da seguire in caso di problemi e scrivere la documentazione (in fase di attuazione da settembre) Estensione dei controlli anche agli utenti più esperti degli altri gruppi (a partire dai run di fisica di ottobre) Estensione a tutti gli utenti interessati a fare analisi dopo un opportuno training (dal 2009)

52 Reliability e Availability dei Tier2
Jun-08

53 Risorse Tier2 2009 - MC Strategia di simulazione: Ricostruzione:
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 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 Non consideriamo la ricostruzione per il calcolo delle risorse nei Tier2. Il processing time è più breve di un ordine di grandezza

54 Cosmics - Storage @ Tier2
Risorse Tier cosmici Cosmics data taking la raccolta di cosmici avverrà sicuramente nel 2009 quando LHC sarà inattivo. Al momento non è possibile stimare nè la quantità di dati che verrà raccolta nè l’effettivo interesse per gli stessi da parte degli italiani RAW e ESD (replica per l’analisi dei dati inviati al CNAF) No AOD e DPD Totale = ~ 50 TBn Stima indicativa, da rivedere nel corso del 2009 Cosmics - Tier2 M8, luglio 08 (circa 10 giorni) RAW = 94 TB ESD = 7 TB NTUP = 12 TB

55 Piano temporale dei finanziamenti
Richieste 2009 – Tier2 Suddivisione per sedi 30% per i Tier2 approvati 10% per il proto Tier2 Riteniamo necessario il finanziamento di Frascati per il 2009 per permettere al sito di partecipare alle attività di computing in maniera significativa e di evidenziare la sua importanza nella cloud italiana Referaggio calcolo Luglio 2008 CPU Disco Switch Consumo kSI2k K€ TBn LNF 100 12 80 8 5 Milano 290 35 230 sj Napoli Roma sj Tot 970 117 770 sj 20 Piano temporale dei finanziamenti 2/3 assegnati subito per permettere l’acquisizione delle risorse per Aprile 1/3 s.j. da ridiscutere nel 2009 in base all’andamento del run del 2008 e la definizione più realistica delle attività di LHC nel 2009