ATLAS: il calcolo A. De Salvo A. De Salvo – 1 settembre 2015

ATLAS: Utilizzo risorse Tier 1 in Italia 2 May 2014Sep 2015 INFN T1 (7.86%) INFN T1 Napoli T1 Roma Milano Frascati 70e3 Job Efficiency WCT Sep PB NTUP Expired AOD Secondary May 2014

ATLAS: Utilizzo risorse Tier 2 in Italia 4 siti T2 (D/S)  Frascati  Milano  Napoli  Roma 1 3 May 2014 Sep e3 Roma Milano Napoli Frascati Job Efficiency Roma Milano Napoli Frascati May 2014 Aug PB NTUP Expired AOD Secondary

ATLAS: Utilizzo risorse Tier 2 in Italia [2] FrascatiMilano NapoliRoma 05/201405/201505/201405/ /201405/201505/201405/2015  Plot di accounting (Faust): la linea verde è il pledge per sito  Buone performance dei siti  Qualche problema a livello ATLAS centrale per riempire i siti fino ad aprile 2015  Multicore job correttamente accountati solo da gennaio 2015 (problema nei sensori di APEL) 4

Network 5 DDM IngoingDDM Outgoing FRASCATI NAPOLI MILANO ROMA Traffico di Rete

Availability = time_site_is_available/total_time Reliability = time_site_is_available/ (total_time-time_site_is_sched_down) Availability / Reliability

Novità 2014/2015 nei siti  Tutti i siti T1 e T2  Tutti i siti sono abilitati per il processing multicore  Buona parte della produzione è ormai multicore, l’analisi ancora no  Gestione dinamica abilitata per ora solo al CNAF (ma seguiranno MI e RM)  Situazione nell’ultimo anno  Tutti i siti molto stabili e con ottime reliability/availability  Problema ad un rack a Roma (2 ventole su 3 rotte) che ha portato ad una riduzione di potenza temporanea della CPU, pur non impattando da un punto di vista ATLAS  Migrazione ad APEL senza grossi problemi, pur avendo dovuto adattare le procedure alle situazioni dei singoli siti  Milano: Condor  RM e NA: multi-sito con singolo publisher  “Prove di matrimonio” tra ATLAS e CMS a RM  Testata con successo una configurazione comune di WN  A breve verranno create le code di overflow, una per ogni esperimento, che permetteranno un overlap incrementale, ove sia possibile 7

Risorse Disponibili CPU CPUFrascatiMilanoNapoliRomaTotalePledge HS To be pledge d Le CPU totali a disposizione dei Tier2 comprendono anche risorse non pledged: le CPU obsolete (fino al 2015 e già rifinanziate) ancora in produzione ma in corso di spegnimento CPU per uso locale (cluster proof) o in griglia ma dedicate principalmente alle attività italiane (Tier3) finanziate con fondi vari –Proof on Demand, share per analisi e simulazione MC per il ruolo atlas/it CPU non a completa disposizione dei siti –(es. scope + Recas a NA, ex SuperB, Belle2, a LNF) Nel conto delle CPU pledged NON sono comprese le CPU gara dei rimpiazzi 2015, tranne che per Frascati, ancora da espletare CPU disponibili fine

Risorse Disponibili 2015 – Disco DiscoFrascatiMilanoNapoliRomaTotalePledge Totale disponibile to be pledged Lo storage totale disponibile nei Tier2 comprende anche l’area locale in cui sono conservati i dati di tutti gli utenti italiani (LOCALGROUP), non solo gli utenti locali La dimensione di queste aree è di circa 180 TB per Tier2 In gran parte già occupata, gli utenti dovranno cancellare i dati vecchi non più necessari per fare spazio ai dati del 2015 l’utilizzo di queste aree è irrinunciabile per cui il loro volume va sottratto allo storage da dichiarare pledged Storage disponibile fine

Risorse Obsolete nel 2016 Le CPU obsolete sono le macchine comprate nel 2012 e installate fine 2012 inizi 2013 (non sono comprese le macchine installate successivamente). Le CPU hanno garanzia triennale, tranne quelle acquistate a partire dal 2014 Lo storage obsoleto comprende le SAN comprate nel 2010 e installate >= giugno Garanzia quinquennale La sostituzione del materiale obsoleto, specie per i dischi, è fondamentale per il buon funzionamento dei centri e quindi dell’intero sistema di computing italiano di ATLAS CPU (HS06) Disco (TBn) Frascati Milano Napoli Roma Tot Risorse obsolete

Risorse attività ATLAS 2016 Lo Scrutiny Group ha approvato ad aprile 2015 le seguenti risorse per ATLAS 11

Richieste LHC 2016 [1] D. Lucchesi – CSN1 5/6/

Richieste T [risorse a tabella] D. Lucchesi – CSN1 5/6/

Richieste T [Scenario 1] D. Lucchesi – CSN1 5/6/

Richieste T [Scenario 2] D. Lucchesi – CSN1 5/6/

Scenari T2 ATLAS 16  Scenario 1  Tutte le risorse, calcolate con il 9% (CPU) e 7% (Storage) del totale ATLAS  Scenario 2  Risorse strettamente necessarie  Tagli possibili, in ordine di rilevanza: 1.Riduzione dell’overhead fino al 50% 2.Rimpiazzo delle solo CPU obsolete già nel Riduzione dello spazio locale dei siti (-120 TBn)  Massimo risparmio, ma in condizioni molto complicate per i siti: 173 kEUR

Richieste T [ATLAS] 17 CPU Pledged 2015 [kHS06] Disco Pledged 2015 [TBn] CPU Obs 2016 [kHS06] Disco Obs 2016 [TBn] CPU New 2016 [kHS06] Disco New 2016 [TBn] CPU Tot 2016 [kHS06] Disco Tot 2016[TBn] OH Rete [K€] OH Server [K€]Tot[K€] Frascati Milano Napoli Roma Tot Richieste totali e per sito: totale delle richieste (scenario 1) CPU Pledged 2015 [kHS06] Disco Pledged 2015 [TBn] CPU Obs 2016 [kHS06] Disco Obs 2016 [TBn] CPU New 2016 [kHS06] Disco New 2016 [TBn] CPU Tot 2016 [kHS06] Disco Tot 2016[TBn] OH Rete [K€] OH Server [K€]Tot[K€] Frascati Milano Napoli Roma Tot Richieste totali e per sito: risorse strettamente necessarie (scenario 2)

Richieste T [LHC] D. Lucchesi – CSN1 5/6/

Partecipazione italiana alle attività di ATLAS  ATLAS Italia partecipa alle attività di computing di ATLAS in diverse aree di lavoro  Cloud support [all]  Database [D. Barberis, A. De Salvo, L. Rinaldi, M. Verducci]  Installazione del software (CVMFS e distribuzione) [A. De Salvo, A. Sanchez]  Monitoring [S. Tupputi]  Network infrastructure (LHCONE) [A. De Salvo]  Storage [A. De Salvo, A. Doria, E. Vilucchi]  Federazioni di xrootd e HTTPD  DPM  VO management [A. De Salvo, E. Vilucchi]  Altre attività (PRIN)  Cloud Computing  Hadoop (EventIndex)  Network Infrastructure (LHCONE) + Distributed T2 (DT2)  Proof on Demand (PoD)  La partecipazione alle rimanenti attività è largamente limitata dalla disponibilità di persone  Attività sulle GPU, inserite in un FIRB  Interesse della comunità per GPU e multiprocessing/ottimizzazione del codice, ma NON c’è manpower 19

Responsabilità italiane nel calcolo di ATLAS  ATLAS database  Dario Barberis [coord]   ATLAS Frontier  Alessandro De Salvo [coord]   Coordinamento calcolo ATLAS IT  Alessandro De Salvo [coord]    Grid software release / CVMFS  Alessandro De Salvo [coord], A. Sanchez   SAM monitoring  Salvatore Tupputi [deputy coord]   VO management  Alessandro De Salvo [coord]  Elisabetta Vilucchi [deputy] 

M&O-A  Le attività riconosciute da ATLAS come In-Kind M&O-A sono  VO Management  Grid/CVMFS software installation  Frontier operations  Per il 2014 il totale riconosciuto per il Computing di ATLAS è 1.3 FTE (~125 kCHF -> ~120 kEUR con cambio a 1.04 CHF)  Confermate tutte le attività già riconosciute gli anni passati  Leggero decremento sulla VO in quanto il 2015 era un anno di transizione ad un nuovo sistema (VOMS-Admin) mentre ora si andrà a regime  Ottimo risultato, cosiderando le poche risorse di manpower a disposizione 21

Conclusioni  Il Computing di ATLAS ha dimostrato di essere robusto ed affidabile per il processamento dei dati, sia MC che analisi finale  Computing Model di ATLAS è stato quasi completamente ridisegnato, sia a livello del codice di ricostruzione/analisi sia dei servizi infrastrutturali, incrementandone l’efficienza  I siti italiani sono stati sempre attivi ed efficienti  Le richieste totali del 2016 sono ~700 kEUR, con possibilità di scendere fino a ~530 kEUR considerando solo le risorse strettamente necessarie 22

Backup slides 23

Richiesta Risorse I Le risorse necessarie per il 2016 sono determinate dalla volontà di conservare il ruolo significativo nel computing di ATLAS acquisito negli ultimi anni conservando gli share di risorse pledged per le attività centrali: Tier1: 9% Tier2: 9% CPU e 7% Disco e di garantire la competitività agli utenti italiani mediante l’uso di risorse dedicate nei Tier2 e Tier3 ATLAS Share IT ATLAS IT 2016 ATLAS IT disponibile Totale 2016 CPU T1 (kHS06) 520 9% * 6.3 Disco T1 (PB) 479% * 0.9 Tape T1 (PB) 1169% * 4.6 CPU T2 (kHS06) 5669% Disco T2 (PB) 727% * Pledge

Richiesta Risorse II Le risorse per le attività italiane sono già disponibili e non inclusi nel disponibile “pledged” 2016 e non sono necessarie ulteriori richieste New 2016 Obs 2016 Richieste 2016 K€ CPU T2 (kHS06) Disco T2 (TB) Totale Prezzi stimati: CPU = 12 k€/kHS Disco = 220 k€/PB Totale 25

Richiesta Risorse III Overhead per rete e server aggiuntivi Algoritmo Bozzi (cfr. presentazione CSN1 Bari Settembre 2011): Rete: 6% (cpu) + 5% (disco) = 33.2 k€ Server: 7% (cpu + disco) = 43.9 k€ A cosa servono: Rete: switch di rack Server: servizi di grid A cosa corrispondo questi finanziamenti: Rete: 1÷2 switch con modulo 10 Gbps Per collegare le nuove risorse e/o sostituire i primi switch ormai fuori manutenzione Server: 1÷3 server per sezione 26

Richiesta Risorse 2016 – Riepilogo (A) 27 Prezzi stimati: CPU = 12 k€/kHS Disco = 220 k€/PB CPU Pledged 2015 [kHS06] Disco Pledged 2015 [TBn] CPU Obs 2016 [kHS06] Disco Obs 2016 [TBn] CPU New 2016 [kHS06] Disco New 2016 [TBn] CPU Tot 2016 [kHS06] Disco Tot 2016[TBn] OH Rete [K€] OH Server [K€]Tot[K€] Frascati Milano Napoli Roma Tot Richieste totali e per sito: totale delle richieste

Richiesta Risorse 2016 – Riepilogo (B) CPU Pledged 2015 [kHS06] Disco Pledged 2015 [TBn] CPU Obs 2016 [kHS06] Disco Obs 2016 [TBn] CPU New 2016 [kHS06] Disco New 2016 [TBn] CPU Tot 2016 [kHS06] Disco Tot 2016[TBn] OH Rete [K€] OH Server [K€]Tot[K€] Frascati Milano Napoli Roma Tot Prezzi stimati: CPU = 12 k€/kHS Disco = 220 k€/PB  Richieste totali e per sito: risorse strettamente necessarie  Tagli possibili, in ordine di rilevanza: 1.Riduzione dell’overhead fino al 50% 2.Rimpiazzo delle solo CPU obsolete già nel Riduzione dello spazio locale dei siti (-120 TBn)  Massimo risparmio, ma in condizioni molto complicate per i siti: 173 kEUR

Nuovo Computing Model di ATLAS nel Run2  Nuovo sistema di computing  Rucio (Data Management)  Prodsys-2 (Workload Management)  FAX ed Event Service per ottimizzare l’utilizzo delle risorse  Ottimizzazione della Produzione ed Analisi  Run-1: 75% / 25% (slots occupancy ~ cputime usage)  Run-2: 90% / 10% (stima grossolana)  La maggior parte dell’analisi (Derivation) sarà spostata sulla (group) production  L’analisi rimanente sarà più veloce e I/O intensive  Riduzione del merging e produzione di file più grandi  Code dinamiche in Panda, basate sui requirement dei job  Direct I/O (xrootd e WebDAV/HTTPS) 29

Lifetime dei dati  Modello di lifetime dei dati  Ogni dataset avrà un lifetime settato in fase di creazione  La lifetime può essere infinita (ad esempio per i dati RAW) e può essere estesa, ad esempio se il dataset è stato utilizzato di recente oppure se esiste una eccezione conosciuta  Ogni dataset avrà una retention policy, ad esempio i RAW saranno memorizzati in doppia copia su tape e gli AOD almeno una copia su tape  Durante la loro lifetime I dataset verranno contrassegnati come dati primari, e quindi non cancellabili  I dataset con lifetime spirata verranno contrassegnati come secondari e potranno scomparire in ogni momento dai dischi e dai tape, ad eccezione dei Group disk e LocalGroup disks  Utilizzo maggiore del tape, ma non dal punto di vista degli utenti finali, tranne casi particolari 30

Novità del Computing di ATLAS nel Run2  Utilizzo più efficiente delle risorse  Maggiore flessibilità nel Computing Model (Clouds/Tiers)  Eliminazione dei ruoli stretti T1/T2/T3  Global Panda queue  Global Storage Pool (STABLE, UNSTABLE, VOLATILE)  Diminuzione delle risorse utilizzate (multicore)  Ottimizzazione del workflow delle analisi (Derivation Framework/Analysis Model)  La maggior parte delle analisi:  Processeranno una grande mole di dati  Utilizzeranno meno tempo di CPU  Un singolo job di analisi sui dataset derivati può utilizzare fino a 40MB/s (vs. 4 MB/s nel Run-1 con gli AOD)  Utilizzo di risorse opportunistiche  Grid, Cloud, HPC, Volunteer Computing 31

Risorse opportunistiche: HPC S. Campana – ATLAS Jamboree – Dec

Risorse opportunistiche: Cloud S. Campana – ATLAS Jamboree – Dec

Risorse opportunistiche: Volunteer Computing D. Cameron – Pre-GDB on Volunteer Computing – Nov HOME CERN ARC Control Tower Panda Server ARC CE Boinc server Volunteer PC Boinc Client VM Shared Directory Grid Catalogs and Storage DB on demand BOINC PQ Continuous running jobs almost 300k completed jobs 500k CPU hours 14M events 50% CPU efficiency Currently >10000 volunteers 300 new volunteers/week Volunteers growth Boinc-based Low priority jobs with high CPU-I/O ratio Non-urgent Monte Carlo simulation Need virtualisation for ATLAS sw environment CERNVM image and CVMFS No grid credentials or access on volunteer hosts ARC middleware for data staging The resources should look like a regular Panda queue ARC Control Tower

Storage Federation 35 Goal reached ! >96% data covered We deployed a Federate Storage Infrastructure (*): all data accessible from any location Analysis (and production) will be able to access remote (offsite) files Jobs can run at sites w/o data but with free CPUs. We call this “overflow”. S. Campana – ATLAS Jamboree – Dec 2014

Nuovi tipi di Reprocessing nel Run2  Derivation Framework  Modello in super-streaming, con scopo finale la produzione per (gruppi di) analisi  Potenzialmente può risolvere problemi nell’input di AOD  Esegue operazioni intensive di CPU su eventi selezionati  I lumi-block completi appaiono solo dopo il passaggio del Derivation Framework  AODtoAOD Reprocessing  Risolve problemi che necessitano solo di input di AOD  Intrinsecamente correlato con il Derivation Framework  RAWtoAOD - Fast Reprocessing  Riprocessamento veloce dove vengono aggionate solo le Condition Data  RAWtoAOD - Full Reprocessing  Riprocessamento veloce dove vengono applicate le nuove calibrazioni e viene aggiornato il software 36

Derivation Framework S. Campana – ATLAS Jamboree – Dec

Analysis Model per il Run2 Common analysis data format : xAOD replacement of AOD & group ntuple of any kind Readable both by Athena & ROOT Data reduction framework Athena to produce group derived data sample (DxAOD) Centrally via Prodsys Based on train model one input, N outputs from PB to TB S. Campana – ATLAS Jamboree – Dec

Event facilities 39  Event Service  Event level processing, implementato a livello di ProdSys (e pilot)  L’event service verrà inzialmente utilizzato su risorse tradizionali (grid/cloud) e successivamente anche su HPC e oltre  Inizialmente sarà usato per la simulazione, per poi essere ampliato a tutto il resto, fino all’utilizzo di un Event Streaming Service  Integrazione con G4Hive e Multi-Threading  Event Index  Semplificazione del TagDB di ATLAS, trasformandolo in un indice degli eventi (EventIndex), con puntatori allo storage che contiene gli eventi in vari formati (da RAW a NTUP)  Basato su Hadoop  Imminente sostituzione del TagDB con l’EventIndex

Performance del software  Ricostruzione  Raggiunto il fattore 3 di miglioramento rispetto al Run-1, previsto dal nuovo Computing Model!  Dimensione degli AOD  Raggiunta la dimensione prevista dal Computing Model 40

Infrastruttura italiana ATLAS in Italia continuerà ad usare per il Run2 il Tier1 e i Tier2 allo stesso modo del Run1 Tier1 + 4 Tier2 (Tier2 di tipo ‘S’ – Stable) con risorse sempre più equalizzate Interfaccia primaria di tipo Grid Full mesh con accesso ai dati locali e tramite Federazioni di Storage Cambiamenti in fase di studio o di sviluppo Interfacce di tipo Cloud Prototipo di Tier-2 distribuito Progetto PRIN LHC-StoA, tra NA e RM Possibile estensione a più siti T2 Attualmente il target è quello della condivisione di servizi in HA multiregione, ma può anche essere esteso Attività promettente, limitata solo dall’esigua quantità di manpower che può essere dedicato a tale scopo