CMS COMPUTING REPORT Tommaso Boccali Catania, 1 Ottobre

Stato del calcolo CMS Cosa si e’ fatto 2013-(2014)? Analisi Chiusura RunI Reprocessing dei dati di tutto il Run con una versione “Legacy” E parziale rilascio come dati “open” (~40 1/pb) Simulazioni prima per post LS1 (13 TeV), e successivamente per Phase 2 (post LS3) 2

3

Preparazione analisi high prio

2014 Resource Utilization at Tier-1 L’utilizzo dei Tier-1 ha raggiunto il 140% del pledge 2013 era stata < 100%, per periodi di fermo fra I reprocessing Il Tape e’ sotto pressione da almeno un anno CNAF: praticamente al 100% fino a giugno, ora < 500 TB liberi Attenzione: sindrome LHCb 2014 tape recommandation: 55 PB 2014 pledges: 48 PB 5

2013 Utilization at Tier-2s Tier-2s: utilizzo maggiore del pledge ~ 10% Efficienza di CPU % Utenti unici per settimana stabilizzato intorno a 300 Discesa dovuta a maggiore organizzazione: in un analysis group una/poche persona mandano jobs per tutti 6

2014 Computing Milestones & CSA14 Data Management milestone: 30 April 2014 demonstrate the functionality and scale of the improved Data Management system Disk/tape separation & data federations (needed for CSA14) Analysis milestone: 30 June 2014 demonstrate the full production scale of the new CRAB3 distributed analysis tools (needed for CSA14) Organized Production milestone: 31 October 2014 exercise the full system for organized production Utilize the Agile Infrastructure (IT-CC and Wigner) at 12k cores scale Run with multi-core at T0 and T1 for data reconstruction Demonstrate distributed prompt reconstruction at Tier-1s 7

8

Alcuni highlights (sviluppo & CSA14) CRAB3 (sistema di analisi distribuita): Refactored per utilizzare glideWMS invece di Panda Basato su Rest interface AsyncStageOut per trasferimento files slegato dalla fine del job Cloud 1. Uso di HLT, T0, CERN-AI via Openstack Link CERN-P5 upgradato a 60 Gbit/s per aumentare utilizzabilita’ della farm HLT 2. (Opportunistic) Tools tipo BOSCO per qualunque tipo di utilizzo non standard Xrootd scale testing Prove di analisi via WAN su larga scala Tests fino al 20% dell’attivita’ di analisi totale 9

STATO RISORSE ITALIANE 10

Stato a fine 2014 (in teoria da 1 Apr 2014) Sulla carta non e’ vero: le risorse ReCaS (che danno un +6 kHS06 a Bari) non sono ancora installate. Pero’ sono comprate, per il 2015 le consideriamo. In pratica 46 kHS06 disponibili. 11 “sbilanciamento” dovuto a ReCaS: tutti aumenti 2014 su Bari

Cosa si processa (T1 vs T2s) in Italia? T1: prod/analisys T2s: prod/analisys In entrambi I casi, piu’ analisi rispetto al modello originale (che era 100%-0% e 50%-50%) 12 Analisi Produzione

Accounting (fatto un po’ a mano) dell’ultimo anno solare Usiamo la dashboard di CMS Accounting EGI siamo tutti in transizione DGAS->APEL, e ci sono stati non pochi problemi di recente … non la consideriamo affidabile Pledge italiano = 46 kHS06 (quello reale, senza ReCaS) ore CPU accountate da jobs ufficiali (NON comprende jobs locali non mandati via CRAB, per esempio) / 365 = 41 kHS06 = 90% del pledge 13

Per sito CMS (kHS06) Pledge (kHS06) senza ReCaS % pledge erogato con jobs CRAB % corrette con jobs locali BA81266%80% LNL % PI %130% RM %82% TOT %105% CORREZIONI: BA: utilizzo “batch like” +1.5 kHS06  80% Risorse -20% in estate per limitare stress termico (in attesa di spostare nella nuova sala ReCaS non ancora pronta) RM1: Lavoro di upgrade fase2 ECAL: 15% di utilizzo Utilizzo per PRIN STOA: 4% PI: Local monitoring dice in media 1700 cpu (incluso accesso locale): 17kHS06 14

Distribuzione annuale del lavoro 15

Accounting Tier ore accountate in 12 mesi Tradotto in HS06 (dal CNAF): Pledge = kHS06 Erogato = 32.5 kHS06 Frazione = 140% Stabile mese per mese … 16

Ranking Tier2 per utilizzo – IT tutti nella prima meta’ 17

I Tier1… Grazie CNAF! ~40% di overpledge 18

Su tutti i jobs di CMS (2014) Perche’ non 13%? Perche’ al denominatore c’e’ forte overpledge (dei T2 americani in gran parte …) 19

Novita’ CNAF Secondo T1 CMS a fornire accesso remoto allo storage via Xrootd (~maggio 2013) Con attivita’ di sviluppo -> plugin GPFS/TSM per Xrootd Primo T1 CMS a completare la Disk/Tape separation (altri entro Marzo 2014) Protegge parte custodial da accessi caotici Permette attivita’ di analisi T2-like al T1 (Agosto 2013) Primo/Secondo T1 CMS a aprirsi ad attivita’ di analisi per tutti gli utenti Aiuta a compensare momenti di assenza di produzione, e massimizza l’utilizzazione delle risorse (Febbraio 2014) Coda multicore up and running (risorse non dedicate) Analisi 2013 vs : 0.3% 2014: 22% 20

Tier2 Federazione Italiana funzionante (da prima meta’ 2013) Italia ospita anche il redirettore europeo di Xrootd/CMS Inizialmente una copia a Bari Seconda copia a Pisa Ridondanza assicurata da infrastruttura HA del CNAF xrootd-cms.infn.it Terza copia in Francia (per non avere il GARR come single point of failure) Mi fermo qui, appena finita la Review e non credo vogliate sentire di piu’ 21

Responsabilita’ Italia E in piu’ 14.3*4+33 = 90 mesi di servizio assegnati a CMS Italia per la gestione dei Tier1/2 22

23

2015 Target del trigger: mantenere stessa physics capability sui canali dell’Higgs Questo da solo richiede un rate di trigger fra 800Hz e 1.2 kHz – 1 kHz nei conti seguenti (3 x wrt standard 300 Hz) Inoltre ci sono 2 fattori che complicano ulteriormente la situazione, a partita’ di numero di eventi raccolti Lumi istantanea + alta = reco time x2.5 Out of Time PU (non lo considero nel seguito, siamo ragionevolmente convinti di poterci proteggere) 24

Per cui … In un mondo ideale, fattore 6x di risorse necessario ; chiaramente impossibile Soluzioni messe in campo 1. Miglioramento dell’efficienza di uso delle risorse: CPU Mitigare effetto di trigger rate + alto: usare i T1 anche per una frazione della prompt reconstruction Meno reprocessing completi possibili (solo 1 alla fine dell’anno) Usare farm HLT per Prompt Reco Gia’ attivo, via HLT Cloud Uso opportunistico di risorse non CMS (e non HEP) Una parte della produzione MC 2012 girata su UCSD SuperComputing Centre Ridurre il numero di eventi simulati 2. Miglioramento dell’efficienza di uso delle risorse: Disco Remote data access per evitare di dover distribuire piu’ copie dei dati/MC Data placement intelligente e dinamico Abbandono totale del formato RECO per AOD 3. Miglioramento dell’efficienza del nostro SW Computing/Offline 25

In una slide … Ridurre differenze T0/T1/T2: girare dove ci sono risorse Disaccoppiare Disco e CPU nel brokering Nuove architetture (ARM, Phi) Nuova infrastruttura di analisi MW GRID sostanzialmente congelato da usare nei nostri siti, ma: 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 Xrootd: BA, PI, BO + T2 CRAB3: MiB, PG BO, PD, BA PI, CNAF 26

Nuovo formato dati? MiniAOD CMS sta testando in CSA14 un nuovo formato compatto dei dati, ~5x piu’ compatto degli AOD Particle flow based Per ogni physics object, solo il migliore algoritmo salvato Soglie aggiustate agli analysis needs piu’ comuni (dovrebbe coprire ~l’80% delle analisi, e permettere un reprocessing completo da parte dell’analizzatore in ~48 ore) Ottimizzato per selezioni veloci (analisi a Hz) In prospettiva, una soluzione per Richieste sempre crescenti di storage La difficolta’ di operare reprocessings completi in tempi stretti Troppo presto per capire se/come funzionera’, ma stay tuned PI 27

28

Richieste – raccomandazioni - delta T1: CPU + 70% Disk + 0% Tape + 34% T2: CPU + 28% DISK + 7% 29

Pledges Basate sul 13% CMS_IT/CMS Pledges 2015 GIA’ sottomesse (Aug 31 st ), per nuove regole RRB Situazione 2014 vs 2015: 30

Aumenti effettivi T2 T1 Aumenti effettivi richiesti sono minori, grazie a acquisti effettuati tramite risparmi e piccoli avanzi di gara Ai T2 oggi 220 TBN di Disco in piu’, e 1.2 kHS06 (che riducono di circa 50kEur le richieste 2015) 31

Dismissioni e totali (solo T2) Starting point (come detto, ancora non reale) Pledge 2015 Dismissioni Notare il forte sbilanciamento dovuto a ReCaS! 32

Acquisizioni totali T2 (new + dismissioni) Totale PRE-RECAS = 535kEur (nel DB dei preventivi era 560kEur perche’ si utilizzavano 250 Eur/TBN) (costi unitari comunicatici dai referees) 33

ReCaS Per CMS, solo Bari puo’ contribuire Le CPU erano gia’ state utilizzate tutte per il 2014 Anche se non ancora attive, le assumiamo attive entro fine 2014 Nel 2015, ReCaS contribuisce per CMS con tutte e sole le richieste storage del sito di Bari In pratica, risparmio su CMS e’ 70kEur + effetto su overhead 34

Post ReCaS = 73kEur di risparmio per CSN1 QUESTO E’ IL NUMERO FINALE! 35

Situazione attesa fine 2015 Sbilanciamento dovuto a ReCaS ben visibile (Al netto di belle sorprese da gare non ancora concluse / effettuate) 36

Nota Richieste T vs : –TOT = 561kEur –TOT-RECAS = 335kEur 2015: –TOT = 535kEur –TOT-RECAS = 462kEur Richieste totali diminuite, ma ReCaS aiuta meno 2015 doveva essere peggio del 2014, in pratica richiesta totale inferiore per la fase delle dismissioni 37

Inoltre (film gia’ visto per LHCb) Brutta sorpresa 2015: Le pledges confermate il 31 agosto per I Tier1 valgono: CMS parte da un deficit sui T1 pari al 16-17% Motivazioni principali: abbiamo perso il T1 di Taiwan I Russi hanno messo 0% di pledge (last minute update: e’ un errore!!) DEFICIT REALE ai T1 e’ ~10% 38

Conclusioni Il computing di CMS in Italia funziona bene Una “non notizia”, e’ cosi’ da anni Non solo site management, ma stiamo cercando di mantenerci a galla sulle attivita’ sullo sviluppo (con il poco mapower che riusciamo ad attirare) CMS ha recepito i richiami (urla di dolore?) per il 2015, abbassando le richieste A prezzo di metterci un una condizione assolutamente scomoda, soprattutto se LHC andra’ bene ReCaS e’ stata un’ottima opportunita’ per risparmiare nel 2014, aiuta meno nel 2015, non aiutera’ nel 2016 Ne usciamo con un bel risparmio (~300kEur su CMS) Ne usciamo un po’ sbilanciati, ma in realta’ meno di quanto si temesse all’inizio 39

BACKUP 40

Tests di Xrootd Stress tests: fino a 2200 jobs running in Wisconsin, che leggono dai siti ~500 MB/s e’ un limite del link intercontinentale, non output max possibile. (e’ un test nella peggior condizione possibile: il 100% dei jobs e’ via Xrootd, e intercontinentale; CMS non pensa di avere nel futuro RUN piu’ del 20% dei jobs con accesso remoto) 41

42

43

Analisi ancora dominante ai T2 Analysis users maintain around 30k processor cores running continuously at Tier-2 Transitioning users to the next submission tool in 2014 Even if in principle T2s should do 50% analysis, 50% MC Prod, in the end it is 60/40 50% 42% (also analysis) 8% 44

CMS ha scarsita’ di tape (soprattutto nei T1 che funzionano meglio -> fanno piu’ attivita’) Disco non e’ messo male, ma solo perche’ per la Disk/Tape separation si e’ ripartiti da tutto vuoto. Si sta velomente riempiendo e in realta’ al CNAF abbiano gia’ avuto una pulizia d’emergenza 45

46

Opportunistic e heterogeneous computing BOSCO GRID CRAB + GlideinWMS 47

Rete P5-IT upgrade da 20 a 60 Gbit/s inizio 2014 Permette miglior utilizzo della farm HLT per Offline 48

Chi processa (2014-) in Italia? T1 e’ meno della meta dell’attivita’ totale italiana 49

Rimane un fattore 2 di risorse da acquisire (su T0 e T1 *) Dal 2013 al 2015 … Statement di CMS: ottenibile con flat budget , o tutto su 2015 (INFN ha deciso di spostare tutti I delta su 2015) *: I T2 sono molto meno critici, visto che li’ Una parte dell’attivita’ scala con I dati (AOD dell’anno in corso) Una parte scala meno (produzione MC, basta farne meno  ) Una parte scala con il numero di utenti 50

Altro …. Il mondo dell’IT ci sta cambiando intorno (lo fa da tempo in realta’, ma noi potevamo in un certo modo “fregarcene”) Le reti geografiche sono cresciute molto + delle aspettative fine 199x (MONARC) Modello gerarchico di MONARC non piu’ una necessita’ La rete puo’ essere usata per ottimizzare accesso a storage (e comprarne quindi meno) Le architetture di CPU stanno cambiando Mono -> multi core (da qualche anno) Cores x86 -> GPU (da qualche anno, ma non per noi) Cores x86 -> ARM (+ recente) In GRID, passaggio ormai a sottomissione via pilot Meno supporto centrale, piu’ CLOUD friendly Utilizzo + efficiente Maggiore potenza di calcolo Minore costo di gestione 51

52

Test (voluti e non) per il nuovo modello di calcolo Test di reprocessing remoto fra T1 e T1 Eseguito a CNAF reprocessing su dati remoti FNAL Eseguito a RAL reprocessing su dati remoti a CNAF Test di T1-diskless Non voluto, effettuato in un periodo di down hardware dello storage, per limitare l’inefficienza 5k jobs di analisi running (leggendo sostanzialmente da CERN,FNAL, T2 italiani) Purtroppo rete CNAF saturata Test di resilienza a problemi FNAL-CNAF accidental test: storage FNAL mal configurato, processing avvenuto per 48 ore via Xrootd (~4 Gbit/s da CNAF!) (unico caveat vero e’ che spesso I fallback Xrootd funzionano ad un punto tale che mascherano I problemi veri; ci stiamo attrezzando di tet specifici per non farci ingannare) Up to 5000 analysis jobs running CPU efficiency 75 to 95% WAN saturated in some moments at 20 Gbit/s Failure rate “normal” for analysis ( <10%) Running Waiting FNALCNAF 53

Occhio … siamo al limite Su indicazione di … chiunque, CMS ha ridotto al minimo le richieste. Nella maggior parte dei casi Sono tunate per il minimo utilizzo, non quello medio (e con ipotesi pessimistiche su LHC, come 3 Msec nel 2015) Si fa affidamento su T0 e HLT nei mesi di down per effettuare reprocessing 2015 requests 2015 requests & recomm: da richieste dovevamo entrare nei casino a 08/2015, da raccomandazioni a 06/

2016 Stima dismissioni = uguale a 2015 (13 kHS06, 750 TBN) Potrebbe essere addirittura un po’ meno … Richieste nuove 55