Slides - Agenda

Referaggio calcolo CMS 2014
CSN1 - 18 Settembre 2013
Tommaso Boccali
(INFN Pisa)
1
Outline
• Stato generale calcolo CMS
• Stato italiano calcolo CMS
• Evoluzione modello di calcolo
• E soprattutto … Richieste 2014
2
Stato Computing
• Presa dati (pp) meglio del previsto:
– Secondi in collisione piu’ delle previsioni, e inoltre
1 mese e mezzo aggiuntivo in pp
+25% rispetto al
planning di inizio 2012
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 2012-13
AODSIM (il data
tier per la fisica):)
: 13B+4B di
eventi prodotti
5
Utilizzo in Analisi
• CMS-World:
• Ormai da > 1
anno
preponderan
te (>90%)
attivita’ su
formato dati
ridoto (AOD)
Stabilizzati su 300-400 utenti singoli la settimana
6
Utilizzo risorse T1&T2
T1: buco dovuto alla
preparazione dei
reprocessing; in risalita
T2: calo ultimi mesi in attesa
del nuovo reprocessing 2011
+ dei nuovi samples per
post-LS1
7
Reprocessing con release 5_3_X
(legacy per il run 2010-2013)
Reprocessing in
pratica finito.
2013
E poi …
8
2011 final rereco
9
Italia!
Interventi elettrici Campus di Bari
Riorganizzazione disco per dare pledge 2012
Rotture
multiple
controller
disco
10
Italia
• T1:
– Pledge 2012 e’ 18.85 kHS06 CPU, 2.8 PB DISCO,
6.6 PB TAPE
• Raggiunto fine 2012
– PLEDGE 2013 e’ 22.75 kHS06 CPU, 3.38 PB DISCO,
6.5 PB TAPE
• Raggiunto ~ Agosto
– Anzi CNAF ci ha permesso a Agosto/13 un overpledge di ~500
TB per effettuare la separazione TAPE/Disk (vedere dopo)
11
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
– CMS ha avuto periodi di overpledge e di underpledge, bilanciamento
possibile solo grazie alla natura shared del sito
# jobs 09-2012/09-2013 ai T1: CNAF migliore dopo FNAL (consolidato dato 2012)
12
Utilizzo CNAF per CMS
CPU:
sostanzialmente in
pledge (4 mesi
under, 8 mesi over)
TAPE:
saturazione del
pledge raggiunta.
Attivita’ NON
bloccata grazie alla
separazione
tape/disk (dopo…)
13
News dal Tier1
• Attivita’ di analisi per utenti Italiani attiva fin
da meta’ 2012
• Separazione dello storage Tier1 in Tape e Disk
• In grado di aprire all’analisi di tutti gli Utenti di
CMS (grazie a tape/disk separation)
14
Separazione DISK/TAPE
• Spazio TAPE con frontend di disco “piccolo” (~350
TB, 10% del pledge) sostanzialmente dedicato
solo ai dati da tenere in custodial
• Tutto il resto del disco (~ 3 PB) come area
svincolata dal disco
– Permette un utilizzo caotico (in analisi, per esempio)
senza dover temere sovraccarichi della parte TAPE
– Svincola il T1 in modo netto fra parte di data
custodiality e parte di processing (produzione +
analisi)
15
Un minimo di dettaglio
• La separazione e’ stata decisa in CMS qualche mese fa
• A tutt’oggi CNAF risulta il PRIMO Tier1 ad aver
completato la transizione (RAL ha cominciato molto
prima ma ancora non ha finito)
• Operazione effettuata interamente ad Agosto (dal 5 al
19)
– … per chi dice che e’ impossibile lavorare ad Agosto in
Italia …
– Un grosso grazie al personale T1 e al supporto CMS!
– 1.1 PB di dati richiamati da TAPE e spostati su parte DISK in
~ 10 giorni
– Transizione di tutta la farm effettuata il 20 agosto
16
T2 italiani
• BA, LNL, PI, RM1
– Totale risorse pledge 2012:
• Disco = 3.5PB
• CPU = 45.5kHS06
– 2013: identico
• Accordate solo dismissioni
17
# jobs, 01/2012 – 09/2013
Come # di jobs successful Italia 1o posto (di un epsilon…)
Picture simile a quella dell’anno scorso: US inarrivabili, (cf slides G1, Sett 2012)
Italia nel gruppo che segue FNAL
18
E all’interno dell’Italia (T2 only)
# jobs, 01/2012 – 09/2013
Nota usuale sui rossi:
• I “rosa” sono certamente problemi di workflow (utenti o team di produzione)
• I rossi intensi sono problemi dal lato GRID (possono essere sia di sito sia di infrastruttura)
• I rossi scuri sono probabilmente problemi di sito, ma anche di workflow
• Per esempio se viene mandato un job che richiede una versione del sw che non c’e’
• Una *mia* stima dei problemi veri di sito da’ numeri inferiori al 5%; il resto sono errori
operazionali
19
Disco
• I T2 italiani ~ 900 TB l’uno (come il 2012)
• 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
Numeri 2012,
2013 +5%
Esempio di Pisa: fino a 10 gg fa pieno al 98%;
refill di emergenza attuato
20
Gruppi di fisica
• Sono ufficialmente supportati 8 gruppi di
fisica:
– Bari: Higgs, SUSY
– LNL: ElectroWeak, Muons
– Pisa: Tracking, Tau & Particle Flow
– Rome: Higgs, Egamma & ECAL
– Nulla di nuovo da anni….
21
Italia in totale (01/2012 - 09/2013)
(occhio, # di jobs, non secondi CPU – e gli workflows che girano a T1 e T2 sono diversi)
22
(nota: T3_IT_Padova a meta’ 2012 e’ stato completamente integrato in T2_IT_LNL; ora sono una cosa sola)
Highlights 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
23
Traffico Xrootd di CMS a livello mondiale …
24
… ed Europeo
Italia assolutamente centrale a livello Europeo
25
Anche CNAF in Xrootd!
• Al CNAF sono state accese 4 porte 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”
– Soluzione sviluppata in Italia
• Patches ora accettate da Xrootd e in release ufficiale
CNAF + FNAL unici T1
completamente abilitati con
accesso Xrootd per lungo
tempo
26
Milestones 2013
• “termine installazione/configurazione di Xrootd sui T2 per l'accesso
remoto degli utenti italiani ai dati”
– 1 giugno 2013
– 100% DONE
• Tutta l’italia e’ nel redirettore di Europeo CMS (anche T1 e qualche T3)
• “messa in opera del redirettore della cloud di calcolo italiana”
– 15 dicembre 2013
– 100% DONE
• Redirettore della cloud italiana xrootd-it.ba.infn.it operativo
• (“definizione delle procedure di utilizzo del T1 per analisi e
disponibilita' dello spazio disco necessario”
– Done Luglio:
– )
27
https://twiki.cern.ch/twiki/bin/viewauth/CMS/T1ItalyForUsers
28
Esempio di funzionamento di Xrootd
15/04: Storage di
Legnaro down per
upgrade di dCache.
Attivita’ di sito NON
ferma perche’ I jobs
potevano accedere ai
dati 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
• (sempre piu’ vicini ad un modello full mesh …)
29
Analisi al T1
• L’analisi al T1 per tutti gli utenti italiani e’
stata attivata (mediante un gruppo VOMS
specifico)
Prossimo step attuabile grazie
a tape/disk separation:
attivarla per tutti gli utenti
CMS
Una settimana al CNAF (estate, credo)
30
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 (2012)
• 20-e Gbit/s per PI (inizio 2013)
– Questo rende + efficace l’utilizzo italiano di Xrootd
in modo trasparente
31
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 Stage Out
…
– Alpha e Beta Testing, test di scala
• Pisa, Torino, Bologna, Padova
• Computing Evolution
– C. Grandi coordinatore L2, si sta formando un gruppo anche
interessato agli studi Cloud partiti in CCR
• M.Sgaravatto (PD): HLT Cloud, General CMS-Cloud Interface, Gestione delle
immagini virtuali
• BA: could storage, Testbed per Cloud IaaS basata su OpenStack per il progetto
PON-PRISMA
• PG
• …
32
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
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
33
HLT cloud 2013 – in produzione!
• _AI: Agile Infrastructure CERN
• (non risporse CMS)
• 170j jobs
• _HLT: la farm HLT a P5
• 480k Jobs processati
• Success rate comparabile
con T1/T2
• Picchi fino a 6k jobs running
34
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) – approvato
settembre 2013
– “Long-Term Data Preservation and Scientific and Cultural
Heritage”
• PON ReCaS (BA in CMS)
• PON Pegasus (BA in CMS)
35
Sinergie locali
•
–
Storicamente, i centri “proto
T2”(2004+) 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
•
•
•
•
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
– 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
•
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
36
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
37
Nuovo environment di LHC x il 2015
Parametri ….
(25 ns – 50 ns)
38
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.5 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)
39
Per cui …
• In un mondo ideale, fattore 6x di risorse necessario 2015-2013;
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
•
•
•
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
40
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)
• *: 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
41
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
42
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
Utilizzo + efficiente
• 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
Maggiore potenza
di calcolo
Minore costo
di gestione
– Meno supporto centrale, piu’ CLOUD friendly
43
In una slide …
• Ridurre differenze
T0/T1/T2: girare
dove ci
Xrootd: BA, PI,
sono risorse
BO + T2
• Disaccoppiare Disco e CPU
nel brokering
PI, CNAF
• Nuove architetture
(ARM,
Phi)
• Transizione verso tools di
analisi/produzione comuni
CRAB3: PG, PD,
almeno con ATLAS
PI, TO
• 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
daBA
fare: intra e
BO, PD,
inter cloud scheduling;
ottimizzazione dell'accesso allo
storage
• .. E additittura volunteer
computing per produzione
MC (completamente da fare)
44
Responsabilita’
L1
L2
L3
45
46
47
48
57
Richieste 2014
• Processo a 4 steps
1.
2.
3.
4.
Siamo qui!
1 Aprile: richieste CMS
Fine Aprile: report C-RSG
1 Settembre: aggiornamento richieste CMS
28 Ottobre: report finale C-RSG
Senza dire troppo sulla storia:
#2: accettate in sostanza le richieste 2014
#3: forte diminuzione richieste 2015 sul T1
(dovute principalmente a riduzione stima secondi
di presa dati 2015 + compromessi sulla frazione di
eventi da simulare)
Le risorse richieste a
maggio (meeting ref a
Pisa), a giugno (CSN1) e
adesso sono identiche!
58
Richieste 2014-2015
“paga il CERN”
“paga la
Giunta”
“paga la
CSN1”
Inoltre: delta 2014-2013 e’ MINORE, visto che il refereraggio calcolo aveva assegnato
piccolo overpledge l’anno scorso (come risulta da REBUS)
CMS-IT e’ al 13% di CMS
59
REBUS
T1
T2
60
Tier1 2014
Al netto delle dismissioni (vedi Donatella)
• Unico aumento sono 650 TB di TAPE
• CPU e Disco gia’ a posto
• a 40 Eur/TB (stima) sono circa 25kEur
61
TIER2
“mancano” 5.2 kHS06
(Nota preliminare …. Aspettare discussione su ReCaS prima di trarre troppe conclusioni)
62
Dismissioni T2
• (T1 segue altra strada)
• TOTALE e’
– 23.6 kHS06
– 440 TBN
Dismissioni pure =
437kEur
(se 12 Eur/HS06 + 350 Eur/TBN)
63
Richieste 2014 – Summary pre-RECAS
• 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 12 Eur/HS06 + 350 Eur/TBN + 40 Eur/TB)
64
Per sito
A meno di 1000 Euro qua e la’, lo stesso che nei preventivi
65
66
2015
APRILE 2013
• Sostanziale diminuzione Tier1
• Tier2 invariati
SETTEMBRE 2013
A spanne, 300kEuro IN MENO su
T1_CNAF per il 2015 rispetto ai
numeri della CSN1 di Giugno
67
Le richieste T1 2015 sono adesso
davvero ridotte all’osso!
La richiesta di 300kH06 non e’ la MEDIA di utilizzo previsto nel 2015, ma IL MINIMO
Il modello “regge” solo perche’ nei mesi di shutdown (quando ci sono I reprocessing
completi) la farm HLT viene usata come pezzo del T1
68
Arriva ReCaS!
• Volutamente non ho nominato ReCaS per ora
• ReCaS puo’ aiutare con:
1.
2.
3.
4.
Tutto il Delta 2014-2013 nazionale
Tutte le dismissioni Bari 2014
Parte delle dismissioni Bari 2015
(Piccola)Parte del Delta 2015-2014
Appurato con ReCaS
Dipende da come
va la gara
Tabella finale richieste:
71
Penultimo: 2 punti
1. Nessuna richiesta Tier3 inserita nei preventivi
– Alla CSN1 di 09/12 si era parlato di distribuire (una piccola
parte delle) risorse dismesse dal T1 ai T3. Siamo
fortemente interessati, non e’ ancora successo perche’ le
nuove risorse al T1 sono arrivate da poco. Vorremmo
procedere con il sostegno della CSN1
2. Le richieste 2014-2015 di CMS sono volutamente flat
per il 2014, con il delta nel 2015.
– CMS ha detto chiaramente che e’ facolta’ delle FA
ridistribuire il carico sui 2 anni.
– L’INFN ha deciso di non farlo, e di lasciare tutto il carico sul
2015, e in tale modo sono state modulate le richieste.
72
Ultimo: Milestones 2014
• Attivare l'analisi utente al CNAF per tutti gli
utenti di CMS
– 01/06/2014
• Deployment di una infrastruttura per il test di
sottomissione jobs via cloud tramite tools
standard CMS
– 31/12/2014
• (negoziabili con I referees…)
73
Conclusioni
• Il computing di CMS in Italia funziona bene
– Una “non notizia”, e’ cosi’ da anni
– Non solo T1/T2/T3, ma stiamo allargando le attivita’ sullo
sviluppo “critico per noi” (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’ un’ottima opportunita’ per risparmiare nel 2014
(appurato) e 2015 (in misura non ancora accertata)
– Ma ReCaS dura due anni, e’ importante che i siti non ReCaS
siano mantenuti in attivita’
– 2 anni sulla vita aspettata dei T2 e’ poca roba
74