Slides nadia calcolo

Referaggio calcolo CMS 2014
3 Maggio 2013 - Pisa
1
outline
• Stato generale calcolo CMS
• Stato italiano calcolo CMS
• Evoluzione modello di calcolo
• E soprattutto … Richieste 2014
2
Stato Computing
• Presa dati meglio del previsto:
– Secondi in collisione piu’ delle previsioni, e inoltre
1 mese e mezzo aggiuntivo in pp
3
Trigger rate salito da ~400 Hz a 1200 Hz
Ben oltre le specifiche a 300 Hz (che erano 100
Hz nel Computing TDR)
Totale eventi raccolti 2012: 7.8B (di cui 3.2B
parked)
PU alto ma gestibile; sostanzialmente costante
tutto l’anno (a differenza del 2011)
Reco time vs
lumi
4
MonteCarlo
AODSIM (il data tier per la fisica) -> 13B di eventi
5
Utilizzo in Analisi
• CMS-World:
• Ormai da > 1
anno
preponderan
te (>90%)
attivita’ su
formato dati
ridoto (AOD)
Ormai stabilizzati su 300-400 utenti singoli la settimana
6
Utilizzo risorse T1&T2
T1: at e over pledge a parte
nelle fasi di validazione
prima di reprocessing
T2: over pledge
(effetto principale: forte over
pledge di alcuni siti, US in testa)
7
Reprocessing con release 5_3_X
(legacy per il run 2010-2013)
Reprocessing in
pratica finito.
Fuori dal piano
iniziale: legacy
reprocessing dei
dati 2011 con
release 5_3_X:
partira’ appena
pronte le
calibrazioni
Poi (dopo estate) si
comincia con
simulazioni post
LS1
8
Italia
• T1:
– Pledge 2012 e’ 18.850 kHS06 CPU, 2.8 PB DISCO, 6.6
PB TAPE
• CPU ok, disco ancora non completamente disponibile, tape
ok (da poco)
– PLEDGE 2013 e’ 22.75 kHS06 CPU, 3.38 PB DISCO, 6.5
PB TAPE
• Pledges sono al 1 Aprile, ancora non raggiunte
– Piu’ precisamente: CPU non troppo distanti per overpledge CNAF,
TAPE e’ una diminuzione quindi ~ ok
– Disco siamo ancora lontani, ancora non siamo tecnicamente al
pledge 2012.
9
Utilizzo T1_IT_CNAF
• L’approccio italiano (1 solo T1 per tutti gli esperimenti) permette periodici
overpledge anche grossi
– Vero soprattutto per esperimenti grossi, che sono molto efficienti a occupare
tutte le risorse libere
– In alcuni periodi (estate soprattutto) CMS ha avuto al CNAF periodi a risorse
> 1.5 pledge, in modo costante. Questo si e’ ridimensionato successivamente.
– CMS ha “ripagato” negli scorsi 2 mesi, in cui c’e’ stata poca attivita’ di
reprocessing e ha ridato indietro tempo CPU
# jobs 01-2012/03-2013 ai T1: CNAF migliore dopo FNAL
10
T1_CNAF
Unici buchi di attivita’ Nov-Jan e Jun:
validazione dei reprocessing.
Aprile: fine del reprocessing dei dati 2012
In attesa di partire con il 2011
(legacy reprocessing)
Pledge e’ ~ 2000 (dipende
da come si valutano le CPU,
lascio a Luca definirlo bene); momenti
extra pledge la normalita’ soprattutto
in estate
Running
Pending
Total
11
Tape CNAF:
pledge
12
T2 italiani
• BA, LNL, PI, RM1
– Totale risorse pledge 2012:
• Disco = 3.5PB
• CPU = 45.5kHS06
– 2013: identico
• Accordate solo dismissioni
13
# jobs, 01/2012 – 02/2013
Picture simile a quella dell’anno scorso: US inarrivabili, (cf slides G1, Sett 2012)
Tutti I siti italiani nella meta’ superiore
14
Disco
• I T2 italiani ~ 850 TB l’uno (come il 2012)
– In realta’ disco arrivato dopo 01/04/2012 … Per Pisa in effetti
appena arrivato
• Lo spazio e’ TOTALMENTE ALLOCATO secondo I dettami di
CMS
– Spazio reale occupato
70-95%, ma grossa
variabilita’ annuale
– Non vi e’ spazio aggiuntivo
usabile liberamente
Pisa oggi: 93% occupato
01/04/2012
15
Gruppi di fisica
• Sono ufficielmente supportati 8 gruppi di
fisica:
– Bari: Higgs, SUSY
– LNL: ElectroWeak, Muons
– Pisa: Tracking, Tau & Particle Flow
– Rome: Higgs, Egamma & ECAL
16
I Tier3
• 2012: richiesta ai referees del calcolo di cominciare un programma
di sperimentazione sui T3 (definiti “per funzionalita’”, non per
locazione geografica)
• Idee generali
– Essere ottimizzati per le attivita’ di ricerca di un gruppo INFN – non per
I task MoU
– Attenzione all’attivita’ interattiva
– Accesso a tutti I dati mediante la cloud italiana di Xrootd
– Responsabilizzare gruppo locale di CMS; preparare persone “esperte di
calcolo” a livello italiano
• Per questo li vogliamo distribuiti nelle sezioni
• Prodotto un documento aggiornato sul modello di analisi,
consegnato ai referees 09/2012
• Richiesta = 30kEuro per il 2013
17
… ma
• Documento ben valutato – nessuna vera obiezione
tecnica
• … ma no soldi!
• Proposta referees (statement in G1 di Sept 2012):
destinare ai T3 una frazione delle macchine
dismesse al T1 (piccola frazione delle migliaia di
cores/anno)
– Ci siamo detti d’accordo, ma ancora non si e’ mosso nulla
– Chiediamo adesso che in occasione dell’arrivo delle
macchine nuove al T1 (~1 mese), cominci l’assegnazione
delle macchine dismesse ai siti
• Peraltro esistono gia’ macchine dismesse l’anno prima…
18
Italia in totale (01/2012 - 02/2013)
(occhio, # di jobs, non secondi CPU – e gli workflows che girano a T1 e T2 sono diversi)
19
(nota: T3_IT_Padova a meta’ 2012 e’ stato completamente integrato in T2_IT_LNL; ora sono una cosa sola)
Availability
Terremoto BO
Problema elettrico
Campus di Bari
Riorganizzazione
Disco CNAF
Rottura
controller
disco
Upgrade dCache
Upgrade dCache
Riconfigurazione farm per
passaggio a LHCONE
Transizione dCache -> Storm
20
Highlights 2012-2013
• L’Italia con gli US e’ l’unico
stato ad aver fatto
deployment completo di
Xrootd a T1+T2 (e anche
qualche T3)
• Abbiamo un redirettore
nazionale + ospitiamo quello
Europeo (Bari)
– Erano 2 milestones 2013 ->
100% DONE
21
Anche CNAF in Xrootd!
• Al CNAF e’ stata accesa un porta Xrootd
• Necessaria l’implementazione di patches a Xrootd per proteggere
sistema TAPE del CNAF
– Xrootd non pubblica nel redirettore files solo su TAPE
– In caso di accesso diretto a files su tape, il recall avviene via GEMSS in modo
“pulito”
• Patches ora accettate da Xrootd e in release ufficiale (da testare da
parte nostra)
CNAF + FNAL
unici T1
completamente
abilitati con
Xrootd
22
Milestones 2013
• “termine installazione/configurazione di
Xrootd sui T2 per l'accesso remoto degli utenti
italiani ai dati”
– 1 giugno 2013
– 100% DONE
• “messa in opera del redirettore della cloud di
calcolo italiana”
– 15 dicembre 2013
– 100% DONE
23
Struttura server Xrootd Italia
• BA
– firblibi03.ba.infn.it, gridtutorial8.ba.infn.it
• LNL
– cmsxrd.lnl.infn.it
• PI
– stormgf1.pi.infn.it, stormgf2.pi.infn.it
• RM1
– cmsrm-xrootd01.roma1.infn.it
• Redirettore Europeo
– xrootd.ba.infn.it
• Redirettore italiano
– xrootd-it.ba.infn.it
• CNAF
– ds-202-08-37.cr.cnaf.infn.it
Al redirettore italiano sono
connessi anche PG e TS come T3
24
Esempio di funzionamento
Files letti da jobs a
LNL via Xrootd: 15/04
dcache giu’ per upgrade;
attivita’ di sito non
ferma visto che i jobs
potevano leggere dati in
fallback via Xrootd
Altri tests fatti
• Reprocessing @ CNAF leggendo dati RAW in Xrootd-Fallback da FNAL
• Reprocessing @ T2_IT leggendo MC RAW in Xrootd-Fallback da CNAF
25
Analisi al T1
• L’analisi al T1 per tutti gli utenti italiani e’
stata attivata (mediante un gruppo VOMS
specifico)
Non nel modello di calcolo di
CMS .. Per ora!
Tecnicamente funziona e
funziona bene, pero’ spesso il
T1 e’ cosi’ pieno per le sue
attivita’ MOU che alla fine i
jobs girano prima nei T2 …
Una settimana al CNAF (estate, credo)
26
Networking
• Durante gli ultimi 12 mesi
– T2+T1(extra LHCOPN) sono passati a LHCONE, che
permette ottimizzazione dei flussi di analisi e di
trasferimento dati a matrice completa
– I T2 sono passati a GARR-X
• 10 Gbit/s per BA, RM1, LNL (da tempo)
• 20-e Gbit/s per PI (recentemente)
– Questo rende + sensato l’utilizzo italiano di Xrootd
in modo trasparente
28
Attivita’ di sviluppo SW/CMP
• CRAB (tool di analisi) – Common Solutions con
ATLAS/CERN-IT
– Responsabilita’ di componenti fondamentali
•
•
•
•
H.Riahi, D.Cingottini (PG)
TaskManager
Async Stageout
…
• Computing Evolution
– C. Grandi coordinatore L2, si sta formando un gruppo
anche interessato agli studi Cloud partiti in CCR
• M.Sgaravatto (PD)
29
HLT Cloud
•
Idea: sfruttare farm HLT (~13kCores/~200kHS06) quando la DAQ e’ spenta / ad uso ridotto
–
–
–
–
•
Usato approccio CLOUD (Openstack/KVM con Openvswitch)
–
–
–
–
–
•
Shutdown lunghi (LS1) - ~ 2 anni
Shutdown invernali- ~ 3 mesi
Periodi di machine development ~ 2-5 giorni
Interfill – 1-2 ore
CERNVM come immagine di partenza
CVMFS per il software
Accesso allo storage via Xrootd
Possibilita’ di allocare / deallocare macchine in pochi minuti (non serve reboot dell’host)
Possibilita’ di allocare solo una frazione della farm (per esempio periodi a bassa luminosita’)
Esperienza specifica, ma molte soluzioni riutilizzabili per generico uso di risorse
opportunistiche, visto che
–
–
–
Nessuna dipendenza da sistema operativo
Nessuna dipendenza da topologia di rete (c’e’ un overlay virtualizzato)
Unico servizio che serve davvero un CLOUD service che istanzi le macchine, e una immagine
preconfigurata per parlare con glideinWMS
30
Partecipazione a progetti MIUR
• PRIN08 (BA, MIB, PI, TS)
– “Progetto e sviluppo di un ambiente hardware e software
ottimizzato per l'analisi dei dati dell'esperimento CMS”
– Concluso 09/2012
• PRIN10/11 (… tutti …)
– “Sviluppo di tecnologie per l’ottimizzazione dell’accesso ai dati di
LHC, trasferibili ad altri domini scientifici, mediante l'approccio
del grid e del cloud computing“
– 02/2013 – 01/2016
• Premiale PIDES (di CMS: CNAF, BA, PI) – sottomesso
2013
– “Long-Term Data Preservation and Scientific and Cultural
Heritage”
• PON ReCaS (BA in CMS)
• PON Pegasus (BA in CMS)
31
Sinergie locali
•
–
Storicamente, i centri “proto T2”
sono stati iniziatori di attivita’ GRID
su larga scala nelle Sezioni a partire
dal 2002. La situazione attuale (per
difetto, solo I progetti maggiori)
PI
•
•
•
•
– BA:
• Grosso centro per la fisica teorica
• PON RECAS
• Progetto PIDES per la data
preservation
– LNL
• Sinergie con esperimenti di GIII
• integrazione totale con PD via fibre
dedicate
–
RM1
•
•
•
Partnership industriali (Ferrari, Ducati,
Consorzio +39)
Centro di Calcolo Nazionale di GIV
Progetto PIDES per la data preservation
Progettazione centro di calcolo teorico
SISSA + proposte di collaborazione per
condivisione risorse
Progetto regionale della Sapienza su cloud
Nessuno di questi progetti sarebbe nato
senza CMS come catalizzatore
Nessuno di questi progetti
sopravviverebbe a lungo senza il T2, che
nella quasi totalita’ dei casi
–
–
Ha predisposto le infrastrutture
Fornisce expertise
32
Evolution of Computing Model per
post LS1
1. Perche’ e’ necessario “cambiare” qualcosa
– Nuovo environment da LHC
– Nuove situazioni al contorno (funding etc)
2. Soluzioni:
– Cambiamenti al computing model puro
– Cambiamenti al nostro software
33
Nuovo environment di LHC
25 ns
50 ns
Parametri ….
34
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 (2-4 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
– Se 25 ns: effetto dovuto al OOTPU al momento da’ un
fattore 2x (tracker soprattutto)
35
Per cui …
• In un mondo ideale, fattore 12x 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 standard 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)
2.
Miglioramento dell’efficienza di uso delle risorse: Disco
•
•
•
3.
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
Miglioramento dell’efficienza del nostro SW Computing/Offline
36
Rimane un fattore (~)2 di risorse da
acquisire (su T0 e T1 *)
• Dal 2013 al 2015 …
• Statement di CMS: ottenibile con flat budget 2014+2015, o
tutto su 2015 (dipende da scelte dell’ente finanziatore)
– (ringraziando almeno in parte la legge di Moore …)
• *: 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
37
Altre condizioni al contorno in
cambiamento veloce
• Il paradigma CLOUD sta diventando standard industriale
(molto piu’ di quanto GRID sia mai riuscito a fare)
– Come implementazione, non un unico standard ma una certa
interoperabilita’ per costruzione (per es. EC2 + OpenStack)
• Il supporto economico FPVI-FPVII (EMI, EGI) sta per finire
– Se vogliamo un middleware solo nostro (HEP), dobbiamo
pagarcelo
– Seguire standard industriali dove si puo’, usare soluzioni
comuni a N esperimenti quando non si puo’ (Common
Solutions, CERN/IT)
• In generale, i fondi per il supporto dei siti (da INFN, per
esempio), non sono certo in aumento
38
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 pero noi)
• Cores x86 -> ARM (+ recente)
• In GRID, passaggio ormai concluso fra WMS e pilot
– Meno supporto centrale, piu’ CLOUD friendly
39
In una slide …
• Ridurre differenze
T0/T1/T2:Xrootd:
girareBA,dove
PI, ci
sono risorse
BO + T2
• Disaccoppiare Disco e
CPU nel brokering
• Transizione verso tools di
analisi/produzione
CRAB3: PG
comuni almeno con
ATLAS
• MW GRID
sostanzialmente
congelato da usare nei
nostri siti, ma:
• Essere pronti a sfruttare
opportunita’ impreviste
(slot in centri supercalcolo,
risorse opportunistiche) via
CLOUD BO, PD, BA
– Tanto lavoro da fare: intra e
inter cloud scheduling;
ottimizzazione dell'accesso
allo storage
• .. E additittura volunteer
computing per produzione
MC (completamente da
fare)
40
Attivita’ di miglioramento SW di CMS
1) Solo ottimizzazione
2) Sviluppi in direzioni prevedibili
3) Don’t ask …
41
Fase 1: subito dopo LS1
• Niente che non sia gia’ in buono stato ha
speranza di essere usabile
• Per CMS sostanzialmente: Multicore
Scheduling (vero)
– Vero: Multicore “dei poveri” gia’ usabile oggi
(forking)
– Piani dicono multithreading vero in test finale late
2013, e subito dopo in produzione
42
Vantaggi Multicore #1
Avere controllo completo su una macchina intera invece che su uno “slot” porta
numerosi vantaggi, alcuni attuali altri “possibili”
• Miglior utilizzo delle caches dei processori
• Scheduling di jobs a alta CPU e a alto I/O sulle stessa macchine (ora le
controlliamo “globalmente”)
• Meno memoria utilizzata (perche’ calibrazioni etc sono presenti una volta sola)
-> disegnare algoritmi piu’ efficienti, ma che utilizzino piu’ memoria
• Trend opposto a quello seguito gli scorsi due anni, dove si e’ fatto di tutto
per diminuire la memoria, a volte a scapito delle performance
43
Vantaggi Multicore #2
• Utilizzo di risorse opportunistiche con meno RAM,
ad oggi a noi negate
• Il fatto che lo scheduling non e’ piu’ per core, ma
per “macchina” diminuisce di un fattore ~ 10 il
carico dell’infrastruttura di computing
• # di jobs da gestire
• # di slots da gestire
• # di files temporanei da gestire
• In fase finale di test Autunno 2013 (perche’ ESISTE gia’)
44
Fase 2 (~2018)
• Qui si puo’ fare R&D vera sull’architettura
• Tre aspetti in gioco
1. Massively multicore, ma sempre x86: XEON Phi
2. Massively multicore, architettura nuova:
GPU+CUDA/OpenCL
3. Riduzione dei consumi sia diretti sia di
condizionamento: ARMv8_64
45
1. XEON Phi
Interessante per usi “tipo coprocessore”: un
core Intel standard esegue ricostruzione, e
passa la parte meglio parallelizzabile
(tracking) al Phi
Non necessita di nuovo codice: architettura di
host e guest e’ la stessa
E’ una buona palestra per massively multicore
Chi lo fa ? Al momento ITALIA in pole position, con
• Francesco Giacomini + Matteo Manzali hanno cominciato una collaborazione con CMS per
studiare il boost di particolari algoritmi (inizio probabile e’ il seedinf nei Pixel), usando il Phi
del CNAF
• Pisa ha altri 2 Phi, collaborazione in partenza con informatici per capire se e’ possibile
collaborazione
• Recentemente il gruppo HLT/CERN ha manifestato interesse ... Non credo siano ancora 46
partite attivita’ vere e proprie
2. GPU
• Questa e’ una soluzione molto performante in un
piccolo subset di algoritmi (quelli sostanzialmente
vettoriali)
• E’ anche la piu’ complicata dal punto di vista degli
skill necessari; non permette un facile riuso di
codice (deve essere riprogettato) – CUDA,
OpenCL, etc
• In CMS si e’ pensato a utilizzi solo a livello di
trigger, ma non mi pare si stia davvero
muovendo nulla
47
3. ARM (v8, 64 bit)
• Interessante per 2 motivi:
1. Consumo!
1. Un core i7 consuma 10-20 W (e in media altri ~4 per
raffreddarlo)
2. Un core ARM e’ 1-1.5 W
2. E’ un mercato con molta concorrenza (prezzi bassi,
aumento di performance maggiore anno su anno)
– La ricompilazione di CMSSW su ARM e’ pressoche’
conclusa
– Per ora e’ solo un test preliminare (ARMv8 non esiste
ancora) ma non e’ detto che in 6-7 anni il mercato
e/o I costi infrastrutturali non ci spingano in questa
direzione
Per il momento
attivita’
CERN/OpenLAB.
Sistema di sviluppo
equivalente arrivato a
Pisa la settimana
scorsa; interesse da
parte degli
informatici per
benchmarking / 48
misura di
49
Ma prima: stato acquisti 2013
• CPU: AQ copre le necessita’ dei siti
– Tutto ok, opzione non ancora esercitata dai siti
• Disco: come al solito in ordine +/- sparso
– Pisa continua con DDN (gia’ arrivato!)
– Possibile sinergia ALICE+CMS per BA+LNL
– Roma da sola (piccole cifre…)
50
Richieste 2014
C-RSG
04/2013
NB: in realta’ in alcuni casi in Italia abbiamo + del pledge 2013; sostanzialmente
perche’ assegnazioni CSN1 erano avvenute prima dello scrutiny
REBUS fa fede:
51
REBUS
T1
T2
52
Tier1
Al netto delle dismissioni (vedi Luca) unico
aumento sono 650 TB di TAPE
53
TIER2
“mancano” 5.2 kHS06
54
Dismissioni T2
• (T1 segue altra strada)
• TOTALE e’
– 23.6 kHS06 (caso limite e’ Pisa, TUTTE le CPU
vanno fuori manutenzione)
– 440 TBN
Dismissioni pure =
390kEur
(se 10 Eur/HS06 + 350 Eur/TBN)
55
Richieste 2014 - summary
• T1
– Dismissioni come decise dal centro
– 650 TB di Tape
• T2
– Aumento di 5.2 kHS06
– Dismissioni pari a 23.6 kHS06 e 440
TBN
– (+ server / networking come share
solito)
(se 10 Eur/HS06 + 350 Eur/TBN)
56
Una nota: manutenzioni/emergenze
• Sett ‘12:
• “…il supporto per il
mantenimento ordinario delle
infrastutture e' a carico delle
sezioni/laboratori che ospitano i
Tier-2 mentre quello della
infrastuttura straordinaria (tipo
UPS) va a carico della CCR. Se i
direttori non hanno soldi …
presentino il problema al
direttivo e li saranno discusse le
possibili soluzioni.”
CCR: ok! Problemi UPS a BA
e RM1, CCR ha finanziato
tutto/in parte la cifra per
tornare operativi!
Man.Ordinaria: non ok!
Richiesta da direttore PI per
contributo manutenzioni
non presa in considerazione
In pratica, NON abbiamo una soluzione per le manutenzioni
57
ordinarie dei centri; che si fa??????
Dismissioni 2015 - T2
• Prima stima al momento
• Cosa ci aspettiamo?
– Nel corso di 3 anni dismissione di tutte le CPU
– Nel corso di 3 anni dismissione di 60-75% del disco
• Per il disco dipende totalmente dalla fase
Per
esempio,
per Pisa
aspettatevi
botta l’anno
dopo
58
Summary delle richieste
(+ usual share di networking e server)
59
ReCaS
• Da slides di GP, il max che si puo’ ottenere e’
1.
2.
3.
4.
Delta 2014-2013 nazionale (pochissima roba)
Dismissioni Bari 2013
Parte delle dismissioni Bari 2015
Molto poco del delta 2015-2014
• Per cui:
1. 2015-2015 forte (!) richiesta di mantenere I T2 not
ReCas operativi (-> dismissioni accordate)
2. 2015: aumento di risorse ai T2 not ReCaS (naturale
visto il punto 4 sopra)
61
62