EVOLUZIONE MODELLI DI CALCOLO A LHC T Boccali

EVOLUZIONE MODELLI DI CALCOLO A LHC T. Boccali, A. De Salvo, C. Grandi, D. Elia, V. Vagnoni

2 Outline (a grana grossa) • Computing a LHC: condizioni al contorno • Run 1 (2010 -2013): • Modello di calcolo degli esperimenti • Lezioni imparate • Nuove condizioni al contorno per il Run 2015 -2018 • Evoluzione dei modelli di calcolo • (Oltre il 2018)

3 LHC, condizioni al contorno I piani storici Anno Bunch spacin g (pp) Energy (pp) per nucleo ne Energy (HI) per nucleo ne Lumi Inst (pp) Lumi Inst (HI) <pile up> interact ions, pp Integra ted lumi (pp) Live time (HI) 2005 25 ns 14 Te. V 5. 5 Te. V 2 x 1033 5 x 1026 5 10 1/fb 107 O(106) 2006 25 ns 14 Te. V 5. 5 Te. V 2 x 1033 5 x 1026 5 10 1/fb 107 O(106) 2007 25 ns 14 Te. V 5. 5 Te. V 2 x 1033 5 x 1026 5 10 1/fb 107 O(106)

4 Aspettative degli esperimenti (~ 2005) • Data rates • 40 MHz interaction rate (1/25 ns) – pp • 4 k. Hz - HI • O(100 -300) Hz salvati alla fine della selezione su tape • ~1 MB/ev RAW data size (pp), ~ 10 MB/ev (HI) • Eventi raccolti in un anno • pp: 100 Hz * 107 sec = 1 Miliardo l’anno -> 1 PB/anno • HI: 100 Hz * 106 sec = 100 Milioni l’anno -> 1 PB/anno • Utenti attivi : una percentuale (ottimisticamente) fissata intorno al 30 -50% della collaborazione • ~1000 per ATLAS/CMS • ~200 per LHCB/ALICE

6 (NB: sarebbe numeri originali in k. SI 2 k, rinormalizzati a HS 06 usando il fattore 250) Altri parametri in gioco Esperimento Size RAW (MB) Size RECO (MB) Size ridotto (analisi) Tempo di riconstru zione (sec. HS 0 6/ev) Tempo di simulazio ne (sec. HS 0 6/ev) Tempo di analisi(se c. HS 06/e v) ALICE 1 0. 04 0. 004 25 150 2 -64 ALICE 12 2. 5 0. 25 3000 70000 30 -1000 HI ATLAS 1. 6 . 5 . 1 60 400 2 CMS 1. 5 0. 05 100 180 1 LHCB 0. 025 0. 075 0. 025 10 1 pp

8 Sommando tutto, sempre dai TDR degli esperimenti (visione del 2005) Esperi mento Anno presa dati (1, 2, 3) Tape (PB) Disco (PB) CPU per recons tructio n (k. HS 06 ) CPU per calibra tion (k. HS 06 ) CPU per simula tion (k. HS 06 ) CPU per reproc essing (k. HS 06 ) CPU per analisi (k. HS 06 ) ALICE 1 11 14 50 12 48 40 ALICE 3 18 24 90 20 80 70 ATLAS 1 12 20 16 12 40 100 40 CMS 1 20 15 20 20 40 60 40 CMS 3 50 30 50 50 100 150 100 LHCB 1 3. 4 3. 2 16 30 5 LHCB 3 11. 6 4. 7 24 30 15

10 ~400 k. HS 06 Slide del 2005 (per il primo anno di presa dati) ….

11 Come gestirle? Volonta’ anche politica si andare su calcolo geograficamente distribuito 1. 2. 3. Le funding agencies si comprano risorse invece di mandare soldi al CERN Si crea un knowledge distribuito sul calcolo scientifico La CERN/IT puo’ concentrarsi sugli aspetti piu’ vicini alla presa dati • Usando GRID come MW, MONARC come template del modello di calcolo

12 MONARC e le reti • Gli esperimenti “producono” dati a ~450 MB/s (se a 300 Hz) di flusso RAW, piu’ un flusso Ricostruito simile • La parte di produzione MC mette circa un altro fattore 2, e poi c’e’ la parte ricostruita • L’analisi deve accedere a questi dati in modo caotico, da parte di ~ 1000 utenti (jobs di analisi sono dimensionati a circa 1 Mbit/s/HS 06, e ci sono ~100 k. HS 06 per l’analisi) • Sommando il tutto, si arriva ad una stima di 20 Gbit/s+100 Gbit/s; quindi O(150 Gbit/s) caotici fra ~50 siti (gli istituti + importanti) • Le reti previste per il 2010 NON potevano garantire queste bande fra un numero grande e variabile di istituti

13 Per cui MONARC … • E’ sostanzialmente Data Driven: i dati devono seguire rotte prevedibili con rate prevedibili, in modo che solo queste vadano “garantite” • Si ottiene naturalmente una distinzione fra i siti, che non sono tutti uguali. • Solo fra alcuni di questi e’ necessario dare garanzie di banda.

14 CERN Tier 0 Storage della copia master dei dati RAW calibrazioni “veloci” e monitoring una prima ricostruzione Si dividono una copia di “backup” dei RAW 1 1 Tier 1 1 Tier 1 Tier ricostruzioni e calibrazioni piu’ accurate 2 2 Tier 2 Tier 2 Tier gran parte dell’attivita’ di analisi/simulazione avverra’ qui coprono I bisogni di una comunita’ ~ 50 utenti ogni altra risorsa da piccolo cluster 2 Tier 2 Tier 2 Tier 3, 4 30/3/2005 universitario, a macchina desktop, a Tommaso Boccali 14 portatile …

15 La rete e MONARC • LHCOPN fra T 0 <-> T 1 s per la parte “garantita” • Dall’inizio almeno 10 Gbit/s daverso CERN • Fra T 1 e T 2 e fra T 2: nulla di davvero garantito • In pratica lasciato alle NREN senza particolari richieste aggiuntive

16

Enabling this scale of data-intensive system requires a sophisticated 17 network infrastructure detector A Network Centric View of the LHC CERN →T 1 miles kms France 350 565 Italy 570 920 UK 625 1000 Netherlands 625 1000 Germany 700 1185 Spain 850 1400 Nordic Level 1 and 2 triggers O(10 -100) meters Level 3 trigger O(1) km CERN Computer Center Universities/ physics groups USA – New York 3900 6300 4400 7100 Canada – BC 5200 8400 Taiwan 6100 9850 The LHC Open Network Environment (LHCONE) This is intended to indicate that the physics groups now get their data wherever it is most readily available 50 Gb/s (25 Gb/s ATLAS, 25 Gb/s CMS) 500 -10, 000 km 1300 2100 USA - Chicago 1 PB/s O(1 -10) meter Universities/ physics groups Universities/ physics groups Universities/ physics groups The LHC Optical Private Network (LHCOPN) LHC Tier 1 Data Centers Universities/ physics groups Universities/ physics groups LHC Tier 2 Analysis Centers

18 Effetti di essere Data- Driven • Difficolta’ di spostamento di dati fra NREN diverse, se non utilizzabile LHCOPN • Traffico T 2 – T 2 per esempio • Necessita’ di non generare traffico caotico fuori controllo • L’attivita’ di analisi e’ essenzialmente locale, utilizza solo lo storage locale • Necessita’ di preallocazione “smart“ dei dati nei T 2 per non avere bassa efficienza di analisi • Necessita’ di copie multiple di dati interessanti (almeno una per continente)

19 Occhio: peculiarieta’ • Il modello qui descritto vale bene per ATLAS e CMS • ALICE fin dall’inizio e’ stata meno rigida nel suo modello: ai T 1 e’ riservato solo il ruolo di reprocessing dei dati, tutto il resto dove c’e’ disponibilita’ di calcolo • considerando la rete come di fatto infinita, il che ha spesso funzionato bene, a volte creato problemi nei centri • LHCb ha dei Tier 2 ridotti, senza disco. In pratica tutte le attivita’ che necessitino di accesso allo storage sono al Tier 1 o “nelle vicinanze”.

20 WLCG as the orchestrator • “Grid” is a computing paradigm • WLCG governs the interoperation since 2002 between the number of “concrete GRID implementations” (a number of, the main ones being OSG, LCG, Nurdu. Grid, …) • WLCG was crucial in planning, deploying, and testing the infrastructure before 2010, and is crucial for operations now As of today, from REBUS • CPU 1. 8 MHS 06 (~180 k computing cores) • DISK 175 PB (~80 k HDDs) • TAPE 170 PB (20 -80 k tapes) • # Sites exceeding 200 ATLAS > 100 k jobs/day Still increasing … CMS > 100 TB moved /day Da Krakow’ 12

21 Risorse reali in gioco 2013 (1 HS 06 ~ 250 Si 2 k) Esperimento CPU (k. HS 06) Disk (PB) Tape (PB) ALICE 391 37 44 ATLAS 780 93 63 CMS 636 59 76 LHCB 190 13 17 Divise in ~200 siti

22 Come ha funzionato? • Gestire il computing a LHC e’ sicuramente stato • Faticoso (come manpower necessaria a gestire servizi, spostamento di dati, sottomissione di jobs) • Complicato (un sistema a moltissimi gradi di liberta’, difficile da ottimizzare) • Costoso (200 siti, di cui una decina molto grandi) • … pero’ certamente dal punto di vista della fisica ha avuto successo • Luglio 2010: primi eventi di TOP presentati a Parigi, raccolti 72 ore prima • Luglio 2012: “scoperta” dell’Higgs, dati raccolti la settimana prima, spesso gia’ riprocessati nel frattempo

23 … e gli esperimenti lo hanno largamente riconosciuto. . ATLAS RRB 2013

24 Altri plots interessanti Atlas ~150 kjobs di analisi in parallelo Atlas ~30 PB trasferiti al mese

25 Spazio “visto” dal data management di ATLAS

26 CMS… CMS: jobs runnanti ai T 2 CMS: Trasferimenti T 0 ->T 1 s

27 LHCb … Jobs sulla GRID… E in particolare campagne di produzione

28 ALICE … Jobs running …

29 In realta’ …. • Modello realmente utilizzato 2010 -2013 e’ stato leggermente diverso da quello qui descritto T 0 • Alcuni hint veloci • Rete non davvero cosi’ problematica, modello a mesh per I trasferimenti • LHCONE • Diminuzione delle restrizioni di MONARC • Analisi ai T 1 • Data placing ai siti diventato almeno parzialmente automatico, e cosi’ anche la cancellazione (ATLAS: Victor) T 1 T 2 T 2 T 2

30 LHCONE gia’ attiva • Nata dal fatto che le reti fra siti non LHCOPN e’ meglio del previsto • Un T 2 tipico in US e’ connesso a 40 Gbit/s da almeno un anno, 100 a breve • Un T 2 italiano e’ a 10 Gbit/s da almeno un anno • Gli esperimenti hanno quindi cominciato ad alleggerire le maglie, per esempio permettendo traffico diretto T 2 <->T 2, e formando quindi una full mesh (tutti parlano con tutti, O(200^2) links permessi) • Puo’ essere vista piu’ come una protezione per il resto del mondo, che per il lavoro di LHC (che rischia di saturare altrimenti qualunque cosa)!

Enabling this scale of data-intensive system requires a sophisticated 31 network infrastructure detector A Network Centric View of the LHC CERN →T 1 miles kms France 350 565 Italy 570 920 UK 625 1000 Netherlands 625 1000 Germany 700 1185 Spain 850 1400 Nordic Level 1 and 2 triggers O(10 -100) meters Level 3 trigger O(1) km CERN Computer Center Universities/ physics groups USA – New York 3900 6300 4400 7100 Canada – BC 5200 8400 Taiwan 6100 9850 The LHC Open Network Environment (LHCONE) This is intended to indicate that the physics groups now get their data wherever it is most readily available 50 Gb/s (25 Gb/s ATLAS, 25 Gb/s CMS) 500 -10, 000 km 1300 2100 USA - Chicago 1 PB/s O(1 -10) meter Universities/ physics groups Universities/ physics groups Universities/ physics groups The LHC Optical Private Network (LHCOPN) LHC Tier 1 Data Centers Universities/ physics groups Universities/ physics groups LHC Tier 2 Analysis Centers

33 Modelli di calcolo: tutto bene… e allora perche’ cambiare? • Diverse condizioni al contorno da LHC • Diverse priorita’ (abbiamo l’Higgs!) • Redesign di limitazioni del Run 1 (per esempio, della max lumi istantanea sopportata da LHCb) • Ma anche (purtroppo) diverse condizioni finanziarie rispetto ai primi anni 200 x

34 shutdown LHC 2013+ Siamo qui! run • 2015 -2018: 13 Te. V, ~2. 5 x in luminosita’, fino a 3 x in Pileup • 2020 -2022: 13 Te. V, altro fattore 2. 5 x in luminosita’

35 Complessita’ del computing – a spanne (2015) • Maggiore energia: ~20% di tracce in piu’; ~30% di sezione d’urto totale in piu’: 1. 5 x • Maggiore luminosita’: piu’ eventi uno sopra l’altro. Purtroppo la nostra ricostruzione e’ + che lineare con la complessita’, per cui la differenza fa almeno un 2 x (si puo’ arrivare a 80 eventi sovrapposti, +altri 80 a +50 ns e altri 80 a -50 ns) • Diverso interesse di fisica: focalizzazione sull’Higgs, per lo studio delle sue proprieta’ implica NON alzare le soglie di trigger per I canali con potenziale di Higgs -> aumento del rate di eventi scritti su disco a almeno 1 KHz (da 100 -300 Hz) – fattore ~3 -5 x • E anche maggiore copertura fisica del B da LHCb, per esempio • QUINDI: a parita’ di tutto il resto, servirebbe un aumento di almeno 10 delle risorse da qui a inizio 2015.

36 Come “riguadagnare” questo fattore 10 • Ci sono delle deficienze (== mancanze di efficienza) note nel nostro modo di processare • Se usassimo MONARC “ideale”, avremmo spostamenti molto inefficienti fra i siti • Il fatto che I jobs vadano dove sono i dati implica che I dati debbano essere preallocati bene • Abbiamo molta difficolta’ a cancellare files (viscosita’ umana) • Ecc … ecc… Accorgersene e’ gia’ qualcosa e infatti e’ stato lanciato uno sforzo a livello di WLCG sui Technical Evolution Groups (TEG)

37 TEG • Reports finali: qui • Gruppi di lavoro • Storage • Databases • Operations • Workload Management • Security

38 Storage e Data management 1. Semplificare le interfacce 1. SRM serve solo ai siti con MSS 2. usare protocolli piu' standard (http, ma anche xrootd, gridftp) dove non c'e' nastro 2. Storage federations 1. Oggi Xrootd ma in futuro anche http. . . NFS 4. 1 ancora immaturo 2. Data caches (per esempio ai T 2) 3. non solo pre-allocazione di dati ma anche spostamenti e cancellazioni automatici 3. Sicurezza 1. lightweight security per dati read-only?

39 Workload Management 1. Basato su pilot jobs 1. Dipendenza dagli information systems molto ridotta (solo per service discovery – quindi solo info statiche) 2. Utilizzo di un gateway per l'accesso al sito ancora necessario (CE) 1. 2. Modifiche all'interfaccia per ridurre la scala delle autorizzazioni Modifiche all'interfaccia per il supporto dei job multicore 3. Clouds affrontate marginalmente 1. virtualizzazione per supportare la configurazione ai siti 2. Dopo la fine del TEG in realta' le attivita' per l'uso di Cloud sono state dominanti mentre l'evoluzione dell'interfaccia del CE si e' praticamente fermata

40 Databases & Security • Utilizzo di tecnologia No. SQL per usi specifici • Caches (via squid) per non event data (conditions data, software, . . . ) • Frontier e’ in pratica upgradato a prodotto WLCG • Rendere obbligatorio glexec per I pilot jobs • Interazione fra security per WM e per data access non ancora definita • Eseguibili firmati -> data access senza proxy

41 NB: dal punto di vista finanziario • I grossi progetti europei EGI-EMI (FPVII) stanno finendo • Le funding agencies stanno avendo problemi finanziari, e garantire il personale di sito non e’ uno sforzo banale • Per l’italia solo per il T 1, per i T 2 INFN ha detto fin dall’inizio che non avrebbero contribuito • Non siamo piu’ (o non saremo a breve) in assoluto i piu’ grossi fruitori di calcolo scientifico; con l’approccio MONARC/GRID e’ difficile utilizzare risorse non costruite apposta per noi

42 E quindi, i nuovi modelli di calcolo • Linea generale: utilizzare MEGLIO cio’ che abbiamo (perche’ tanto di piu’ non ci daranno) • Cercare di riassorbire con efficienze operazionali il gap di risorse che non riusciremmo comunque ad avere • Cercare di promuovere miglioramenti dello stack software (sia con ottimizzazioni di sw, sia con cambiamenti architetturali) • • Abbracciare nuove tecnologie (Cloud, di nuovo nuove architetture) • Manpower limitata: cercare di avere progetti o WLCG o almeno a >1 esperimento (sia per devel, sia per supporto)

43 Concetti generali a tutti gli esperimenti • Accesso remoto diretto ai dati: • Data. Driven: i jobs vanno dove sono i dati, per non generare traffico caotico sulla WAN. • Se un sito ha CPU libere, ma dati non interessanti, non sara’ usato • Se un sito ha dati interessanti, ma tutte le CPU usate, non sara’ possibile l’accesso a questi dati • Come organizzare l’accesso remoto? Storage Federations!

44 Storage federations • Ricetta: • dati distribuiti su N siti • Un protocollo di accesso remoto (http, Xrootd, NFS 4. 1 …) • Un ”catalogo” dei files / un servizio di redirezione • (tanta rete …) • Catalogo: • Serve un DB centrale che sappia dove sono tutti i files (uhm…) • Redirezione • I vari siti “annunciano” I loro files al redirettore • Protocollo: • alla fine Xrootd e http sono poco diversi ad alto livello; NFS 4. 1 pare tramontato

45 Idea: federazione gerarchica • (Esempi: FAX, AAA, ALICE x costruzione …) • Ad una richiesta di fopen, il sistema reagisce • Cercando il file localmente; altrimenti • Scala al redirettore regionale, che lo “chiede” ai nodi registrati; se non c’e’ • Puo’ scalare un certo numero di livelli di redirezione, fino eventualmente al redirettore mondiale. • Appena il file viene trovato, si apre una connessione diretta fra server e WN

46 Bello, ma …. e i rischi? • Xrootd e’ molto efficiente come protocollo (http si vedra’), qualche migliaio di connessioni remote possono intasare qualunque cosa • E’ essenziale uno shaping del traffico, per limitarlo; • E’ essenziale che la maggior parte dei fopen si fermi al primo livello • E che quindi un efficiente preplacement dei dati continui ad avvenire • (a meno che, chiaramente, la rete non diventi “infinita”)

47 Multicore • Fino ad ora, l’utilizzo delle macchine di calcolo e’ sempre stato “batch seriale”: 1 core, 1 job. • Ma in questo modo, visto che molti dei jobs che troverrano a essere eseguiti nello stesso momento sono “simili”, c’e’ un chiaro spreco di RAM perche’ la geometria (per esempio) e’ presente piu’ volte in memoria • Soluzione: approccio multicore. Un singolo job crea processi/threads veri e propri su tutta la macchina O Almeno su una frazione non piccola del WN

49 Ma come farlo? ? • Framework multithreaded e’ vitale • Non e’ possibile esporre il fisico medio (almeno a mio parere) al parallelismo • Pertanto in prima approssimazione, e’ il Framework che deve esserlo, schermando tutto il resto dall’utente • “parallelismo a livello di moduli”: ogni modulo e’ pensato/scritto/eseguito come seriale; + moduli girano in parallelo • Funziona? • Certamente si • E’ sufficiente? • Non e’ detto: funziona nel caso in cui • Le interdipendenza fra I moduli siano semplici / semplificabili • Non ci sia un singolo modulo che prende il 90% del tempo (e purtroppo non ne siamo lontani… il tracking)

50 50 Are we entangled? • You can improve parallelism by unrolling sequences • But on the other hand global event reconstruction techniques a-la Energy Flow make everything more interdependent Lines are input/output to modules

51 Ci sono veri motivi per averne + di uno? • Cioe’, un solo FW basterebbe per I 4 esperimenti LHC? • Secondo me si’. • I nostri modelli di calcolo non sono troppo diversi • Tutti basiamo l’event data model su ROOT • I Workflos di ricostruzione, calibrazione, analisi sono simili • Come al solito e’ un problema di volonta’ • Il CERN ci sta almeno provando: Concurrency Forum! • Valutazione delle varie tecnologie (libdispatch, TBB, …) • Proposta di soluzioni (? )

52 Nuove architetture • Non mi soffermo su questo, vista la sessione di ieri, ma alcune parti specifiche dei nostri software sono altamente parallelizzabili (seeding, tracking, island search per I jets, …)) • Nota bene: parlo di parallelizzazione ALL’INTERNO DEL SINGOLO MODULO! • Xeon Phi, GPU sono tecnologie che sono sotto studio da parte degli esperimenti • ARM d’altra parte e’ interessante per la riduzione dei consumi • Ma senza i 64 bit stiamo solo giocando … • Tipicamente solo per piccole porzioni del codice, da iper-ottimizzare • In condizioni time-critical, come a livello di farm di trigger

54 Alcune guidelines per il prossimo modello di calcolo Ridurre differenze T 0/T 1/T 2: girare dove ci sono risorse qualunque workflow, appoggiandosi a Xrootd quando serva 2. Disaccoppiare Disco e CPU nel brokering 1. Transizione verso tools di analisi/produzione comuni almeno fra 2 esperimenti 3. 1. Diminuzione del manpower per lo sviluppo e il supporto MW GRID sostanzialmente congelato da usare nei nostri siti, ma: 4. 1. 2. 5. Non per la maggioranza dei jobs, ma per riottenere frazioni di efficienza Essere pronti a sfruttare opportunita’ impreviste (slot in centri supercalcolo, risorse opportunistiche) via CLOUD Tanto lavoro da fare: intra e inter cloud scheduling; ottimizzazione dell'accesso allo storage . . E additittura volunteer computing per produzione MC (completamente da fare)

55 Le cloud …. • Abbiamo delle sessioni specifiche a questo WS, per cui non ne parlo troppo estesamente qui • Per cosa possono servire a noi le cloud? 1. Per avere accesso a risorse altrimenti non utilizzabili 1. Per diminuire gli FTE necessari per manutenere i siti 2. Stack Cloud commerciali esistono indipendentemente da noi (non dobbiamo svilupparceli) Per essere chiari: comunque per il run 2015 -2018 l’utilizzo preponderante delle NOSTRE CPU sara’ via GRID; qui stiamo parlando del “resto” (< 10% a occhio)

56 Cloud per avere maggiori risorse • Consideriamo 3 use cases di risorse che OGGI gli esperimenti avrebbero difficolta’ ad utilizzare Grossi centri di supercalcolo e/o cloud non HEP, magari con architetture strane (rete di interconnessione dei nodi) offerti per brevi periodi ad un Esperimento 2. Grosse farm di calcolo dei nostri esperimenti, destinate ad altro (tipo le farm HLT) libere per frazioni del tempo 3. Grosse farm commerciali, da usare per un certo periodo (a pagamento/gratis) 1. Questo perche’ “una farm” per diventare “un sito” ha bisogno di servizi non immediati da installare; per esempio

57 Girare su GRID rispetto a su Cloud A computer connected to network, with conditioning and power Local site staff An operating system “compatible” with the application Local site staff, after negotiation with experiments Comes as a virtual image from the experiment central infrastructure A local installation of the experiment software (and a local area where to store it) Local site staff provides area, Experiment support installs software (ok, we have CVMFS now …) Downloaded on demand from the experiment central infrastructure Machines for local experiment facilities (voboxes etc) Local site staff provide them. Also deployable as virtual images A local storage containing the input data Local site staff needs to have bought storage for the experiment Data can be accessed remotely OR via cloud storage (efficiency price? ) A configuration to be executed User! Ex p s ne u pp ed o ed r t GRID Si te s ne u pp ed o ed r t You need

58 Cloud • Quanto detto e’ vero riguardo all’utilizzo opportunistico/temporaneo di risorse “altrui” • Ma gli stessi aspetti riguardano l’ottimizzazione (== riduzione) del manpower necessario nei nostri siti • Diminuisce la necessita’ di avere personale specializzato per una data VO • L’unico suppoto locale davvero necessario e’ quello sistemistico, per installare / tenere vive le macchine e per gestire lo stack Cloud locale

59 Standardizzazione! • Ci sono tanti stack Cloud disponibili • Ma appare sempre + chiaro che il mondo HEP si stia orientando (CERN in testa) verso Openstack • Compliance EC 2 (sia macchine, sia storage) gratis • . . E un po’ meno chiaramente, verso CERN/VM come base per l’immagine virtuale di esperimento • Al momento CER/VM soddisfa completamente solo ALICE … per costruzione ! OK fare R&D, ma teniamo presente che “il CERN ha gia’ scelto…”

60 Esempi noti 1. Centro di calcolo di UCSD offerto a CMS per un paio di settimane ha pemesso di effettuare mesi di lavoro standard 2. Le farm di HLT nei modelli 2015+ sono utilizzate come T 0 nei periodi di down di LHC, ma anche durante il paio di ore che intercorre fra un fill e l’altro di LHC • in pratica nei piani di tutti gli esperimenti, con diversa granularita’ temporale 3. Utilizzo di Amazon, Rack. Space, etc …. per tamponare periodi di urgenza • Tutti gli esperimenti stanno facendo I loro conti; adesso troppo caro in utilizzo standard ma chissa’….

61 Cloud commerciali • Al momento economicamente non sostenibile: • CMS: spostare un mese di produzione MC (solo la parte GEANT 4) su Amazon e’ ~1. 3 M$ • ALICE: x spostare tutta l’attivita’ ALICE 2012 su Amazon • 40 M$ • Pero’ si possono avere forti sconti (anche /10) sul mercato “spot”: • Comprare 1 MOre di CPU “nel prossimo anno” (ma quando siano disponibili lo decide Amazon) • Dare il permesso a Amazon di uccidere i jobs quando le macchine servano per usi meglio pagati • Interessante , vediamo come evolve….

62 E dopo ? (LS 2, 2020+) • Esperimenti stanno cominciando solo adesso a pensare come vorranno operare; saremo in rpesenza di detectors in gran parte “nuovi” • Idee che circolano: • Processare direttamente a HLT (quindi via SW) tutto il rate dall’esperimento (40 MHz) – eliminando hardware dedicato di L 1 • Poter salvare piu’ rate su disco: non salvare RAW, ma direttamente formato ridotto per l’analisi (permetterebbe 20 x di rate su disco) • Ma serve grossa fiducia nelle calibrazioni online • Rottura completa dello schema MONARC: delocalizzazione completa delle risorse (sia via GRID sia via Cloud: in situazione “a rete infinita” MONARC non ha molto senso). • Calcolo eterogeneo (x 86 + ARM + Phi + GPU + chissa’ cosa): come ai vecchi tempi di LEP, tornare ad avere piu’ architetture supportate allo stesso tempo

Calcolo ALICE 63 Prospettive Calcolo ALICE Previsioni post-LS 2: nuovo CM q Aumento consistente del flusso di dati (~102 -> 50 k. Hz) Ø contenimento delle risorse (calcolo e storage) necessarie: § necessità di ridisegnare interamente il framework di calcolo q Concetti ispiratori: Ø Cloud computing Ø Online + Offline (O 2)

67 Conclusioni (in ottica CCR) • Acquisire esperienza Cloud, preferenzialmente Open. Stack: e’ un buon investimento • E per cloud storage? ? ? • Le reti saranno ancora piu’ centrali per gli esperimenti in futuro • E la capacita’ di tunare i cammini, se la rete non sara’ “infinita” • Esperienza in nuove architetture di calcolo sono utili; difficilmente “moriremo x 86” • Queste stesse (ARM per esempio), sono di interesse anche per I servizi • Il software sara’ necessariamente multicore aware • Come rendere i nostri fisici capaci di capirlo/scriverlo? • Possiamo contribuire a scrivere “IL” FW multicore (se esistera’? )