ATLAS: il calcolo Alessandro De Salvo 25-5-2015 A. De Salvo – 25 maggio 2015.

Presentazione sul tema: "ATLAS: il calcolo Alessandro De Salvo 25-5-2015 A. De Salvo – 25 maggio 2015."— Transcript della presentazione:

1 ATLAS: il calcolo Alessandro De Salvo 25-5-2015 A. De Salvo – 25 maggio 2015

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

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

4 ATLAS: Utilizzo risorse Tier 2 in Italia [2] FrascatiMilano NapoliRoma 05/201405/201505/201405/2015 05/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

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

6 Availability = time_site_is_available/total_time Reliability = time_site_is_available/ (total_time-time_site_is_sched_down) Availability / Reliability 2011-2015 6

7 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

8 Partecipazione italiana alle attività di ATLAS  ATLAS Italia partecipa alle attività di ADC in diversi aspetti  Database (Coordinamento, Frontier, Conditions)  Installazione del software (CVMFS e distribuzione)  Monitoring  Network infrastructure (LHCONE)  Storage  Federazioni di xrootd e HTTPD  DPM  VO management  Altre attività (PRIN)  Cloud Computing  Hadoop (EventIndex)  Network Infrastructure (LHCONE)  Proof on Demand  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 8

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

10 Risorse Disponibili 2015 - CPU CPUFrascatiMilanoNapoliRomaTotalePledge HS061667220890293632003286957 46800 To be pledge d 1071810924147901092447356 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 2015 10

11 Risorse Disponibili 2015 – Disco DiscoFrascatiMilanoNapoliRomaTotalePledge Totale disponibile 8681242154612384894 3712 to be pledged 6881062136610584174 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 2015 11

12 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 2011. 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) Frascati3048120 Milano3048405 Napoli2088204 Roma3048444 Tot112321173 Risorse obsolete 2016 12

13 Richiesta Risorse 2016 - 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%46.840.5 * 6.3 Disco T1 (PB) 479%4.233.33 * 0.9 Tape T1 (PB) 1169%10.55.9 * 4.6 CPU T2 (kHS06) 5669%50.947.43.5 Disco T2 (PB) 727%5.044.170.9 * Pledge 2015 13

14 Richiesta Risorse 2016 - 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) 3.511.214.7176.4 Disco T2 (TB) 87011732043449.5 Totale 625.9 Prezzi stimati: CPU = 12 k€/kHS Disco = 220 k€/PB Totale 14

15 Richiesta Risorse 2016 - 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 15

16 Richiesta Risorse 2016 – Riepilogo (A) 16 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 10.76883.051201.174934.226139.813208.5 Milano 10.910623.054051.172084.226139.813208.5 Napoli 14.813662.09204002.092043.74.878.5 Roma 10.910583.054441.171694.226139.813208.5 Tot 47.3417411.2411733.5087014.75204333.143.8704.0 Richieste totali e per sito: totale delle richieste

17 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 10.77180.961201.174532.135733.95.3161.0 Milano 10.910920.964051.171682.135733.95.3161.0 Napoli 14.813960204000 1.11.548.0 Roma 10.910880.964441.171292.135733.95.3161.0 Tot 47.342942.8811733.507506.39204312.817.4531.0 17 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 2015 3.Riduzione dello spazio locale dei siti (-120 TBn)  Massimo risparmio, ma in condizioni molto complicate per i siti: 173 kEUR

18 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  Si sta indagando anche la possibilità di estendere di 1 o 2 anni il periodo di manutenzione dello storage in dismissione nel 2016 18

19 Backup slides 19

20 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) 20

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

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

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

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

25 Risorse opportunistiche: Volunteer Computing D. Cameron – Pre-GDB on Volunteer Computing – Nov 2014 25 ATLAS @ HOME CERN ARC Control Tower Panda Server ARC CE Boinc server (vLHC@Home) Volunteer PC Boinc Client VM Shared Directory Grid Catalogs and Storage DB on demand BOINC PQ Continuous 2000-3000 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

26 Storage Federation 26 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

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

28 Derivation Framework S. Campana – ATLAS Jamboree – Dec 2014 28

29 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 2014 29

30 Event facilities 30  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

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

32 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