Tier 2 di CMS_IT risposte alle domande aggiuntive

1
TIER 2 DI CMS
RISPOSTE ALLE
DOMANDE AGGIUNTIVE
Tommaso Boccali - INFN Pisa
Roma, 27 Gennaio 2014
2
outline
• Bari
• E spiegazioni metodologiche per le domande comuni
• LNL
• Pisa
• Roma1-CMS
• Nota: alcune risposte le avrete gia’ sentite (ALICE) e altrre le sentirete domani
(ATLAS). Per quanto possibile abbiamo controllato siano compatibili…
3
Bari
• 1. Fornire HS06 il valore numerico degli pledged e
medi utilizzati (non cores).
• (domanda presente per tutti)
• Nel documento abbiamo scelto di
• Prendere I valori di HS06 di pledge dei siti
• Stimato il core medio: 10 HS06/core
• Confrontato con monitoring
• HLRMON
• Locale quando disponibile
• Perche’ abbiamo fatto cosi’?
4
10 HS06/core e’ un numero sensato
1.
1.
2.
Vedi CNAF (che dice addirittura 12)
Vedi LNL che ha fatto il calcolo preciso: viene effettivamente 10
HS06
HLRMON non da’ stime in HS06
2.
1.
2.
Normalized
a si2k
O ore vere, o ore.kSi2k
Poi da Si2k si puo’ volendo passare a HS06, utilizzando il fattore
Michelotto = 250 (ma era una stima su singolo core di anni fa,
chissa’ ora dove siamo)
HLRMON dipende dai numeri pubblicati nel BDII di sito
3.
1.
Non sempre aggiornati
Per la review non vogliamo testare la catena di conversione
fra si2k/HS06/cores, meglio usare un valore affidabile
5. I monitoring locali (sui quali ci si appoggia per un x-check,
visto anche I problemi noti di DGAS) “parlano” solo in jobs
4.
5
• In pratica, I valori reali in HS06 del sito sono quelli del
documento, utilizzando di nuovo #HS06 = #cores * 10
• Per cui dai documenti
BA = 10.1 kHS06
LNL = 11.4 kHS06
PI = 15.5 kHS06
RM1 = 700 kHS06
6
Periodo 04/2012 - oggi
• Pledges da rebus (non divise per sito) =
• 45 kHS06 invariata, per cui faccio periodo unico (sono 660 giorni)
= 4500 cores
In cores:
BA = 1050 cores
LNL = 1220 cores
PI = 1430 cores
RM1 = 550 cores
TOT = 4250
(RM1 non include i 200
per calibrazione, vedi
dopo)
(PISA non include i ~
100 jobs in piu’ che
vediamo dal monitoring
locale)
7
Quindi …
Site
Cores
used
HS06 used HS06
pledge
Fraction
Bari
1050
10500
12800
82%
LNL
1220
12200
11300
113%
Pisa
1430+100
15300
12600
121%
Rm1
550 + 200
7500
10000
75%
TOT
4550
45500
45000
100%
Nota
(10% nodi
off, diventa
85%)
8
3. Fornire il ranking del Tier2
usando la metrica di qualita’
usata da ciascun esperimento.
LNL
RM1
• Risposta per tutti: preso il 2011-
ora
•
•
•
•
•
LNL = 99%
RM1 = 96%
Pisa = 89%
Bari = 91%
MEDIA = 94%
• NB: CMS identifica T2 soddisfacenti
quelli che hanno > 80%
• E T1 soddisfacenti quelli che hanno
> 90%
• Per cui i ns T2 sono “ok” anche
per la metrica T1
Bari
Pisa
• Problemi specifici di Bari che
hanno recentemente abbassato
l’availability
• 2 major problems alla cabina
elettrica del Campus di Bari2
Soglia
80%
Soglia
90%
9
• 4. Fornire la misura o la stima dei consumi del Tier-2, l’efficienza energetica
•
•
•
•
in termini di rapporto fra consumi e potenza di CPU media utilizzata e se
misurabile il PUE.
Nel paragrafo 2.3.2 Limitazioni e costi del documento è riportata la lettura della
potenza fornita dall’UPS: 99.4 kW. Nelle stesse condizioni il consumo
complessivo della farm è risultato pari a 152 kVA.
L’UPS alimenta sia la farm vera e propria che i Servizi della Sezione (server WEB,
Mail server, DNS, etc.). La potenza complessiva viene spesa oltre che per
raffreddare la sala calcolo vera e propria, anche per raffreddare altri due ambienti:
quello con i servizi di Sezione e quello con gli UPS). Un calcolo preciso del PUE è
complicato da fare senza misurazioni aggiuntive oltre quelle fornite dai display
presenti sull’alimentazione elettrica, ma una buona indicazione può essere
ottenuta valutando il coefficiente di prestazione ottenuto divedendo la potenza
complessivamente assorbita (in kVA) per la potenza erogata dagli UPS (in kW)
assumendo che quest’ultima coincida con la potenza informatica: PUE =
152/99,4= 1,53.
Questo rapporto non è esattamente il PUE: per ottenere il PUE il numeratore va
diminuito a causa del cosphi e per le perdite nell’UPS, il denominatore va
diminuito per tener conto del assorbimento delle residue unità di ventilazione
alimentate attraverso UPS.
Si osservi infine che il coefficiente di prestazione così calcolato può avere una
dipendenza dal periodo nell’anno in cui viene calcolato. Il valore di 1,53 è stato
misurato a novembre 2013.
• kVA/kHS06= 152/40kHS06 => 3.85 W/HS06
• (e’ di sito, non di cms!!!!)
10
5. Riassumere i contributi forniti da CSN, CCR e GE negli ultimi 5
anni per lo sviluppo dell’infrastruttura e il funzionamento del sito.
11
6. Definire l’impegno da parte della struttura ospitante per la
manutenzione ordinaria e straordinaria dei componenti
dell’infrastruttura.
• L’Università di Bari contribuisce attraverso:
• La fornitura e la manutenzione dei locali
• La manutenzione dell’alimentazione elettrica. Si sono da poco
conclusi i lavori di riqualificazione della cabina MT/BT del
Dipartimento
• la fornitura dell’energia elettrica
In generale:
• La Sezione INFN si occupa
della Manutenzione Ordinaria
• Per la M. Straordinaria, la Sezione
prova a coprire, richiedendo
contributo CCR altrimenti
12
7. Completare la descrizione del personale aggiungendo le
persone coinvolte in ruoli manageriali e di esperimento con i
relativi FTE.
• Oltre alla tabella nel documento, ecco altro personale
CMS che svolge attività per il TIER2:
13
8. Indicare se le risorse del Tier-2 sono disponibili per
uso opportunistico per altri gruppi di ricerca.
• La farm di Bari è da sempre organizzata come farm
multidisciplinare.
• Le risorse aggiuntive rese disponibili mantenendo attive,
compatibilmente con i consumi elettrici, alcune delle risorse
della farm dopo il periodo di ammortamento, sono state messe
a disposizione degli utenti che in modo opportunistico, usando
il middleware di grid o con account locale sul cluster, hanno
potuto usare la farm di calcolo.
• La farm di Bari oltre che agli utenti locali è aperta ad alcune VO
internazionali, come biomed e compchem, a cui viene garantito
un uso opportunistico delle risorse computazionali.
• Informazioni interattive si possono trovare a questo link:
• http://cloud-mysql.ba.infn.it/
14
2013
15
9. Il modello di calcolo di LHC potrebbe evolvere verso un numero minore di
centri di maggiori dimensioni. Per questioni di economia di scala questi centri
potrebbero essere multidisciplinari. Dire quali sono in termini di infrastruttura e/o
personale i possibili margini di espansione del vostro sito.
• Le risorse computazionali presenti nella farm di Bari comprendono, sia
le risorse dei TIER2 di ALICE e CMS, ma anche risorse acquistate da
altri esperimenti INFN come per esempio PAMELA, FERMI-GLAST, T2K,
Totem, Magic5, gruppo teorico, e perfino risorse acquistate da gruppi non
INFN. La gestione della Farm è stata sempre improntata ad assicurare ai
contributori delle risorse un uso corrispondente al loro contributo.
• E’ opportuno precisare che in molti casi l’uso da parte di altri gruppi di
utenti (diversi da CMS e Alice) non è stato puramente opportunistico ma
è stato fornito un vero e proprio supporto agli utenti.
• Questo approccio ha permesso acquisire utenti anche da altri gruppi di
ricerca della Sezione e del Dipartimento di Fisica e più in generale
dell’Università di Bari, ma soprattutto ha dato la possibilità di contribuire a
progetti multidisciplinari come per esempio quelli svolti in collaborazione
con la comunità di bioinformatica (quali LIBI, Bioinfogrid, BioVeL).
• Questa tipo di attività, ha dimostrato già una sua autosostenibilità
evidente dalla continuità temporale dei progetti citati (dal 2005 al 2014).
16
Considerazioni sui margini di espansione
• Infrastruttura: Il progetto ReCaS rappresenta per Bari un
momento di forte espansione sia per quanto riguarda la parte
infrastrutturale (fino a 1 MW di potenza informatica, 80 racks)
sia per quanto riguarda le risorse computazionali: più di un
fattore due rispetto alle risorse attualmente disponibili. E’
però necessario aggiungere che sfruttando il progetto ReCaS,
si sta procedendo ad una valutazione sistematica di diversi tool
di gestione della farm:
• ci aspettiamo che, pur con un raddoppio delle dimensioni
della farm, non sia necessario un incremento di personale.
• Per raggiungere la scala finale di ReCaS ovviamente la
quantità di personale necessario **non** sarà lineare.
17
ReCaS
• Il centro parte con circa 600kW di potenza IT e 60 Rack
utilizzabili.
• Nella configurazione finale (1MW e 80 Rack) è possibile
ospitare fino a 35-40 mila cores (~ 400 kHS06) e 50
PetaByte di storage.
• Considerando le CPU e i dischi attualmente in produzione.
• Questo con la tecnologia di oggi, poi -> legge di Moore
18
• Personale: E’ stato di recente approvato dal Direttivo un bando
di tecnologo T.I. per il Servizio Calcolo della Sezione di Bari.
• Inoltre, come descritto nel documento, negli anni scorsi la gestione
del TIER2 è stata realizzata attraverso una serie di contratti su fondi
esterni, in generale dell’INFN ma anche in qualche caso
dell’Università di Bari, sfruttando al massimo tutte le sinergie tra gli
obiettivi dei progetti e le attività di gestione della farm.
• L’esperienza fin qui maturata sui progetti su fondi esterni ci fa ben
sperare che anche per il futuro questa strada sia ancora percorribile.
• Infine, all’interno del progetto ReCaS stiamo mettendo particolare
attenzione, soprattutto in riferimento alle risorse acquisite nel progetto
dell’Università, affinchè il centro di calcolo diventi
autosostenibile. Questo ci fa sperare che ulteriori unità di personale
possano essere pagate in futuro anche dall’Università.
19
Nota generale sull’espandibilita’
• Il manpower necessario NON scala con HS06 e/o TB, ma
con il numero di oggetti singoli e distinti da gestire.
• Per esempio, 100 macchine dual core danno lo stesso carico di
lavoro di 100 macchine a 32 cores
• Un sistema SAN da 100 dischi da 1 TB da’ lo stesso lavoro di un
sistema da 4 TB
• Un sistema SAN da 100 dischi da ~ lo stesso lavoro di un sistema SAN
da 500 dischi (“contano le teste dello storage, non I dischi”)
• Lo stesso per elettricita’/raffreddamento/m^3
• In prima approx, scalano con il numero di CPU, non di core
• In prima approx, scalano con il numero di WN
20
• Quindi l’espandibilita’ realizzata con aggiornamento
tecnologico e’ praticamente gratis dal punto di vista
infrastrutturale/ di manpower; dove possibile abbiamo fatto
questo esercizio
• Altra cosa e’ l’espansione del centro come # di macchine
installate
• Richiede investimenti e aumento delle spese di gestione (elettricita’)
• Richiede nuovi spazi
• Richiede aumento di manpower, che certamente pero’ NON e’ lineare
con le risorse installate
• Amministrare 100 WN e’ marginalmente piu’ complesso che amministrarne
200, soprattutto se in presenza di sistemi automatizzati di gestione
installazione che oggi tutti abbiamo
• Nel 2006 i nostri siti avevano ~ 20 WN, e c’era tipicamente
PIU’ personale di adesso
21
LEGNARO
• 1. Fornire il valore numerico degli HS06 pledged e medi
utilizzati (non cores).
• Vedere parte di Bari …
• 2. Fornire il ranking del Tier2 usando la metrica di qualita’
usata da ciascun esperimento.
• Vedere parte di Bari …
22
3. Fornire la misura o la stima dei consumi del Tier-2, l’efficienza
energetica in termini di rapporto fra consumi e potenza di CPU
media utilizzata e se misurabile il PUE.
• LEGNARO:
• PUE = (75+50)/75 = 1.7 (LNL)
• “Il consumo medio attuale è di circa 75 kW per le macchine in sala e
circa 50 kW per il raffreddamento, quindi ampiamente entro i limiti
dell’infrastruttura “
• PADOVA:
• PUE = 121 / 86 = 1.4
• consumo macchine: 43% di 200kW = 86kW
• raffreddamento: 35 kW
• (x LNL e’ di sito, non di cms!)
• W/HS06 sui due siti ~6
23
4. Riassumere i contributi forniti da CSN, CCR e GE negli ultimi 5
anni per lo sviluppo dell’infrastruttura e il funzionamento del sito.
• Ci sono i seguenti finanziamenti CCR, tutti relativi a networking
(centro stella T2 e link LNL-PD)
• 2008 - modulo 4 porte 10Gb per HP5400 piu’ transceiver per
collegamento con PD
• 11k di finanziamento parziale
• 2010
• switch centro stella T2: 16k
• manutenzione fibra LNL-PD: 9.5k
• 2011
• reintegro centro stella T2: 18k
• manutenzione fibra LNL-PD: 9.5k
• 2012
• ottiche 10Gb ER per link LNL-PD: 12k
• manutenzione fibra LNL-PD: 9.5k
• Vedi anche commenti alla domanda 8.
24
5. Definire l’impegno da parte della struttura ospitante per la
manutenzione ordinaria e straordinaria dei componenti
dell’infrastruttura.
• Legnaro:
• Energia eletterica: a carico dei Laboratori.
• Raffreddamento: manutenzione dei chiller a carico dei Laboratori.
• UPS: manutenzione e sostituzione batterie a carico dei Laboratori.
• Rete:
• l’infrastruttura di rete interna (esclusi quindi i collegamenti verso
l’esterno) per la parte Tier-2 è a carico di ALICE e CMS tramite il
finanziamento al T2 di CSN1 e CSN3. La parte rimanente a carico dei
Laboratori (principalmente Servizio Calcolo, con eventuali contributi
degli esperimenti locali che usufruiscono di macchine in sala);
• gli apparati e le ottiche per l'accesso verso l'esterno, sia a GARR-X che
al link Legnaro-Padova, sono stati finanziati dalla CCR. I contratti di
manutenzione delle fibre sono a carico del GARR e quindi rientrano nei
contributi INFN→GARR.
• STRAORDINARIA:
• La Sezione copre se possibile, altrimenti viene chiesto contributo
25
• Padova:
• Energia elettrica: a carico dell’Universita di Padova, senza limiti di
kW (convenzione in scadenza il 15.12.2013 ed in fase di rinnovo)
• nella bozza in via di approvazione si confermano le condizioni attuali
• Raffreddamento: manutenzione dell’impianto a carico della
Sezione.
• UPS: manutenzione e sostituzione batterie a carico della Sezione.
• Rete:
• la rete interna alla sala è tipicamente a carico della Sezione. Acquisti
specifici dedicati al Tier-2 (ad es. schede e ottiche 10Gb/s) sono a
carico di CMS e ALICE tramite il finanziamento al Tier-2 di CSN1 e
CSN3;
• gli apparati e le ottiche per l'accesso verso l'esterno, sia a GARR-X che
al link Legnaro-Padova, sono stati finanziati dalla CCR. I contratti di
manutenzione delle fibre sono a carico del GARR e quindi rientrano nei
contributi INFN→GARR.
• STRAORDINARIA:
• La Sezione copre se possibile, altrimenti viene chiesto contributo
26
6. Indicare la data di scadenza della convenzione per la fornitura
di energia elettrica della Sezione con l’Universita’ e se questa
prevede limitazioni di utilizzo del Tier-2.
• Solo applicabile a Padova:
• la convenzione precedente e’ scaduta il 15-12-2013 ed attualmente
e’ in fase di rinnovo
• Nella bozza attuale non sono previsti contributi espliciti per la
corrente elettrica da parte dell’INFN.
• (nessuna variazione rispetto alla situazione attuale)
27
7. Indicare una stima della percentuale dei consumi del
Tier-2 rispetto a quello globale del laboratorio.
• Il consumo totale annuo dei Laboratori nel 2013 e’ stato di
18.479.570 kWh.
• Il consumo annuo del T2 assumendo il valore medio
indicato nel documento di 125kW risulta di
125*24*365=1095000 kWh
• Frazione stimata = 6%
28
8. Commentare su eventuali costi aggiuntivi dovuti alla
divisione del Tier-2 su due siti.
• I costi aggiuntivi diretti sono quelli riguardanti il link in fibra ottica tra
le due sedi:
• fino al 2012 il contratto di manutenzione della fibra era a carico dei Laboratori
(9.5k annui finanziati da CCR),
• dal 2013 e’ a carico del GARR, quindi il link LNL-PD rientra nel servizio che
GARR fornisce all’INFN.
• A questo bisogna aggiungere il costo delle ottiche 10Gb di tipo ER
(Extended Range) negli apparati su cui si attestano le fibre (dipende
dall’apparato, ma circa ~5k ciascuna).
• Da notare che comunque la fibra non e’ ad uso esclusivo del
Tier-2 ma e’ una risorsa disponibile per altri servizi e attivita’ in
sinergia tra LNL e PD (vedi ad es. il progetto di cloud di calcolo
scientifico in comune LNL-PD citato nel par. 7 del documento).
• Non ci sono stati altri costi tipo aumento infrastruttura ecc. in quanto
entrambe le sedi erano gia’ dotate di computing room attrezzata.
29
9. Completare la descrizione del personale aggiungendo le
persone coinvolte in ruoli manageriali e di esperimento con i
relativi FTE.
• Per quanto riguarda il personale di esperimento, sia per CMS
che per ALICE c’e’ una persona che fa da “interfaccia” tra il
Tier-2 e l’esperimento: Stefano Lacaprara per CMS e Andrea
Dainese per ALICE
• (Come ruoli manageriali c’era Gaetano Maron fino ad ottobre
2013 ma ora non piu’ e la sua attivita’ verra’ coperta dal
restante personale.)
• Aggiungiamo inoltre i due responsabili del Calcolo delle due
sedi (contributi per procedure di acquisto, infrastruttura sale,
ecc.): Michele Gulmini per Legnaro e Michele Michelotto per
Padova
• Tutto il personale citato partecipa per complessivi
stimabili FTE ~ 20%
30
10.Indicare se le risorse del Tier-2 sono disponibili per
uso opportunistico per altri gruppi di ricerca.
• Da sempre il Tier-2 ospita anche
altre VO con delle code dedicate
ma senza priorita’, quindi
accesso alle risorse solo se
sono lasciate libere da CMS e
ALICE. La VO che piu’ di tutte
ha sfruttato questo uso
opportunistico e’ sempre stata
LHCB, ma oltre a questa ci sono
anche “enmr”, “superb”,
“euindia” e “cdf”.
31
11.Il modello di calcolo di LHC potrebbe evolvere verso un numero minore di
centri di maggiori dimensioni. Per questioni di economia di scala questi centri
potrebbero essere multidisciplinari. Dire quali sono in termini di infrastruttura e/o
personale i possibili margini di espansione del vostro sito.
• Per quanto riguarda l’aspetto del
supporto di VO diverse (centro
multidisciplinare), va notato che
gia’ adesso Legnaro-Padova e’
Tier-2 ufficiale per 2 VO
pienamente supportate.
• La VO lhcb e’ da sempre
abilitata all’uso opportunistico:
se pur non vi siano contatti
diretti con l’ esperimento, viene
naturalmente dato supporto
tramite gli eventuali ticket
GGUS dell’ infrastruttura EGI.
• Oltre a queste, anche per altre VO minori in
passato si e’ offerto un supporto ben maggiore
di quello per un uso puramente
“opportunistico”. Tra gli esempi ricordiamo:
• SuperB: setup di un SE dedicato e supporto
produzioni MC, in collegamento col gruppo
SuperB di Padova;
• Agata: VO di un esperimento di gr.3 ospitato
presso LNL nel periodo 2007-2010, ha usato
il T2 per lo storage locale, il data
management ed il data transfer verso altri siti
(setup di SE dedicato e door gridftp);
• Enmr: supporto all’integrazione in Grid e poi
alle produzioni mediante persona nel
progetto europeo EU-NMR nel team del T2
fino al 2010 (S. Badoer);
• EuIndia: EuIndia: supporto all’integrazione in
grid e poi alle produzioni mediante persona
nel progetto europeo EU-IndiaGrid nel team
del T2 fino a fine progetto (S. Fantinel)
32
Espandibilita’ del sito - LNL
• :Calcoliamo la quantita’ massima di
HS06 e TB che possono essere installati
nella sala attuale ad infrastruttura
esistente, senza quindi ipotizzare
espansioni di spazio, potenza
elettrica o raffreddamento.
• I rack in sala sono 22, di cui
assumiamo 18 disponibili per il T2 e
gli altri 4 per utilizzi diversi e servizi.
• Partiamo calcolando la densita’ per
unita’ di rack di HS06 e TB con server e
storage attuali (analoghi agli ultimi
acquisti effettuati):
• server: dual twin con 4 server 32 core
su 2U => 64 core per U => 640 HS06
/U
• storage: enclosure da 60HD da 4TB
in 4U => 15 HD per U => 60 TB / U
• I rack nella sala LNL non possono essere riempiti
completamente (42 U) per vincoli di peso (max 700Kg
di carico utile per rack) e di corrente elettrica (max
3*32A per rack). Con questi vincoli l’occupazione
massima risulta:
• rack di server: 12 enclosure 2U dual-twin pesano
~500Kg e assorbono ~3*28A, quindi con questi
raggiungiamo il limite di potenza (~17 KW/rack).
• max 24 U per rack di server
• rack di storage: qui c’e’ solo il limite di peso, 5
enclosure 4U da 60HD pesano ~600Kg
• max 20 U per rack di storage
• Ipotizzando di dedicare 9 rack ai server e 9 allo storage
otteniamo:
• Max server: 9 rack * 24 U = 216 U => 138240 HS06
• Max storage: 9 rack * 20 U = 180 U => 10800 TB
•
Con un rapporto HS06/TB di ~13, non distante da quello reale in uso
attualmente (~10 per CMS). Naturalmente si puo’ variare il rapporto
HS06/TB a seconda delle esigenze.
33
LNL
• Naturalmente Legnaro non avrebbe problemi ad
espandersi in maniera anche piu significativa potendo
contare su un campus con numerose aree libere e sulla
disponibilità di una infrastruttura elettrica progettata per
fornire potenze ragguardevoli e tipiche del mondo degli
acceleratori.
• Servirebbero in questo caso investimenti mirati allo scopo
e che in questo momento non sono però nella road map
del laboratorio.
34
Espandibilita’ del sito - PD
• Facendo un calcolo analogo per Padova, dove i rack che possono
essere dedicati al T2 sono 20, teniamo gli stessi valori delle densita’:
• 640 HS06 / U
• 60 TB / U
• In questo caso non ci sono vincoli di peso ma quelli di corrente elettrica
per rack sono come per LNL (3 linee da 32A per rack), quindi i limiti sono:
• rack di server: come per LNL
• max 24 U per rack di server
• rack di storage: arriviamo fino a 9 enclosure 4U da 60HD
• max 36 U per rack di storage
• Ipotizzando 12 rack di server e 8 rack di storage otteniamo:
• Max server: 12 rack * 24 U = 288 U => 184320 HS06
• Max storage: 8 rack * 36 U = 288 U => 17280 TB
• Sommando le capacita’ max delle due sale si ottiene
• Max server: 322560 HS06
• Max storage: 28080 TB
35
PISA
• 1. Fornire il valore numerico degli HS06 pledged e medi
utilizzati (non cores).
• Vedere parte di Bari …
• 3. Fornire il ranking del Tier2 usando la metrica di qualita’
usata da ciascun esperimento.
• Vedere parte di Bari …
36
(inoltre…)
• Pisa dispone di un monitoring locale, che si basa sui logs
LSF, e che e’ considerato piu’ affidabile perche’ non
dipende da demoni / comunicazioni, etc
• Tramite tale monitoring, stimiamo ~ 100 core aggiuntivi
attivi in media (vedere documento)
37
2. Fornire l’availability del sito (OPS)
• Usiamo i report WLCG mensili
• http://sam-reports.web.cern.ch/sam-
reports/2013/201312/wlcg/WLCG_Tier2_OPS_Dec2013.pdf
• Purtroppo, dopo 12 mesi sono cancellati, per cui abbiamo solo
l’ultimo anno
93.1%
38
Motivi di calo di availability
• Apr-13
A=84 R=85
• Problemi hardware DDN e upgrade a EMI2 dei CE
• Jul-13
A=93 R= 93
• Problemi elettrici in sala che hanno fermato lo storage
• Sep-13
A=95 R=95
• Problemi elettrici in sala che hanno fermato lo storage
• In entrambi i casi, il DDN ha avuto dei problemi che NON doveva avere. L’assistenza ha
proceduto in seguito a un upgrade di firmware
• Oct-13
A=82
R=95
• Messo in produzione il 12k quindi fermo dello storage
• Nov-13
A=81
R=90
• Distacco corrente alla marzotto e upgrade EMI3 di StoRM con il problema al FE
• Bug storm che ha necessitato di 3 gg di debug da parte degli sviluppatori
39
4. Fornire la misura o la stima dei consumi del Tier-2, l’efficienza
energetica in termini di rapporto fra consumi e potenza di CPU
media utilizzata e se misurabile il PUE.
• Da documento:
• Potenza “informatica” = 200 kW
• Potenza per servizi: 150kW
• PUE = 1.75
• Stime piu’ recenti e accurate
• Potenza “informatica” = 225kW
• Potenza per servizi: 135kW
• PUE = 1.6
• W/HS06: da ultimi numeri: 360 kW/66 kHS06 = 5.5
W/HS06
40
5. Riassumere i contributi forniti da CSN, CCR e GE negli ultimi 5
anni per lo sviluppo dell’infrastruttura e il funzionamento del sito.
• CSN1 = nulla; GE = nulla
• CSN4 = contributi specifici per il cluster dei teorici
• CCR = manutenzioni di apparati di rete, contributi
all’infrastruttura Storage di Sezione
• Collaborazioni esterne = ingegneria etc …
41
42
6. Definire l’impegno da parte della struttura ospitante
per la manutenzione ordinaria e straordinaria dei
componenti dell’infrastruttura.
STRAORDINARIA:
La Sezione copre se possibile, altrimenti viene
chiesto contributo CCR
43
7. Esplicitare il numero di FTE coinvolti
per personale tecnico e di esperimento.
100% calcolo scientifico
50% calcolo scientifico
100% calcolo scientifico
50% calcolo scientifico
100% calcolo scientifico
50% calcolo scientifico
50% calcolo scientifico
Nome
Funzione
FTE
T.Boccali
Resp.
Nazionale,
esperto SW di
CMS
10%
G.Bagliesi
Data Manager
<10
%
Pers CMS
44
8. Commentare sulla criticita’ delle 4
persone a tempo determinato
• Delle 4 persono a t.d.
• Una e’ interamente su SUMA e calcolo teorico
• Una segue anche altri progetti INFN (AAI)
• Una segue anche progetti di DP
• Una non segue calcolo GRID, ma applicativi locali (che CMS non
usa)
• Lo statement del documento, qui riaffermato, e’
• “Per la parte del personale, i membri staff riescono a garantire
la gestione ordinaria del sito “
• Detto questo, il numero di Progetti e Collaborazioni rende
plausibile la presenza di personale a t.d.
45
9. Indicare se le risorse del Tier-2 sono disponibili per
uso opportunistico per altri gruppi di ricerca
• Il sito come politica e’ sempre stato aperto a TUTTE le VO supportate da
INFNGRID, nell’ottica di mantenere le macchine piene
• In quanto tale, il sito ha sempre risposto (in seconda priorita’) ai ticket di
TUTTE le VO
• (Uso opportunistico o no?)
46
VO/gruppi che hanno
girato a Pisa
( http://farmsmon.pi.infn.it/lsfmon )
47
10.Il modello di calcolo di LHC potrebbe evolvere verso un numero minore di
centri di maggiori dimensioni. Per questioni di economia di scala questi centri
potrebbero essere multidisciplinari. Dire quali sono in termini di infrastruttura e/o
personale i possibili margini di espansione del vostro sito.
• VO / Gruppi supportati ufficialmente a Pisa (extra CMS,
naturalmente)
• SuperB: sito ufficiale di “produzione”
• Belle II: sito ufficiale di “produzione”
• Glast: abbiamo supportato (e istruito!) il VO manager, tutte le
attivita’ Grid/Glast iniziate su Pisa e poi passate altrove
• Teorici: centro nazionale di CSN4
• Nato dal fatto che i primi teorici italiani a usare Grid sono stati i pisani,
avvicinati alla Grid mediante i corsi organizzati in Sede (il primo
09/2007).
• CVI: “…the Committee praises the upgrade of the CSN4 cluster
“zefiro” which serves the computing needs of some 16 research
groups”
• (LHCB??)
48
VO theophys 2008-2010
(prima della creazione
del centro nazionale)
VO theophys 2013
Tripiccione, 10/2013, CSN4
49
Tramontana, Theocluster, Zefiro
LHCB …
50
LHCB ….
V.Vagnoni, 05/2012
51
Altre collaborazioni
• Ingegneria (fluidodinamica): come tramite per
collaborazioni industriali
52
53
Espandibilita’ del sito
• NON abbiamo possibilità di espansione fisica (rack) la sala è
piena (34 racks)
• attualmente abbiamo circa 7000/700 macchine core e
sostituendo tutto il vecchio con processori di ultima
generazione (AMD 16 core o Intel 12) potremmo arrivare a
circa 25000 core
• ~250 kHS06
• storage: mantenendo gli attuali sistemi (2xddn9900 +
1xddn12000) per un totale di 1800 dischi
• Con dischi da 3 TB, ~6PB; con dischi da 4, ~7PB
• Tutto questo senza modifiche infrastrutturali (elettricità,
rack, condizionamento e rete)
• Se “permettiamo” ai WN di aumentare in numero, c’e’ circa un
altro fattore ~2 dovuto all’occupanza media dei rack
• (il tutto _OGGI_, poi legge di Moore)
54
ROMA
• 1. Fornire il valore numerico degli HS06 pledged e medi
utilizzati (non cores).
• Vedere parte di Bari … (e notare aggiunta a mano di 200
cores … vedi prossimo punto)
• 4. Fornire il ranking del Tier2 usando la metrica di qualita’
usata da ciascun esperimento.
• Vedere parte di Bari …
55
2. Giustificare l’uso delle risorse pledged per le calibrazioni. Dire
se questo e’ accounted dall’esperimento sia a livello nazionale
che internazionale.
• L’uso delle risorse per le calibrazioni ECAL non e’ al
momento pledged ne’ accounted. La ragione e’ che per
motivi tecnici i job sono eseguiti in locale, cioe’ su code
locali del T2, e quindi non passano per CRAB: infatti i job
accedono i raw data, creano un formato intermedio su cui
ricalcolano iterativamente per diversi passaggi.
• Tuttavia e’ possibile modificare HLRMON locale per accreditare
questi job a CMS e quindi farne poi un pledge ufficiale. Tale
modifica verrà quindi implementata ASAP.
56
3. Commentare sul fatto che nel 2012 e 2013 si sono
resi indisponibili circa il 10% dei cores all’anno, cosa
che non si riscontra negli altri siti.
• Come spiegato nel rapporto, nel 2012 non ci sono state nuove
acquisizioni di CPU e non erano state chieste dismissioni (questo
a posteriori è stato un errore di valutazione da parte del responsabile
del T2).
• A inizio 2012 erano disponibili circa 1000 core distribuiti su circa 80
server di vario tipo (dual 2-core, dual 4-core,dual 6-core, twin e non);
con il termine indisponibili si intende sia i server che nel 2012 e nel
2013 sono stati dismessi perchè guasti (in generale server vecchi con
cpu dual-core o quad-core per un totale di -92 core), sia worker node
in servizio ma problematici: in particolare, tra 2012 e prima metà del
2013, 5 lame di server twin acquistate da E4 (su gara nazionale)
hanno dato problemi ripetuti, prolungati e non risolti da E4. Ogni
lama ha 12 core (2 CPU da 6 core). Ogni intervento su una lama del
genere comporta lo spegnimento dell’intera twin, quindi anche della
lama gemella funzionante.
• L’effetto medio (-92 core dismessi -60 core ripetutamente guasti 60 core gemelli forzosamente fermi durante interventi su quelli
guasti) e’ quantificabile in circa -10% in questione.
57
5. Indicare come si e’ misurato il PUE.
• Abbiamo (== CMS+ATLAS!) una misura continua della potenza
assorbita da tutti i dispositivi sotto UPS che sono esclusivamente
quelli relativi al calcolo e reti (la parte di rack e’ gia’ sottratta)
• Tutta la potenza impiegata per il raffreddamento NON è sotto UPS,
perciò calcoliamo il PUE come potenza erogata dal quadro elettrico
principale diviso potenza erogata dall'UPS. La potenza erogata dal
quadro elettrico principale non è sotto monitor continuo, ma è stata
misurata a campione e risulta abbastanza stabile (come del resto la
potenza erogata dall'UPS).
• I numeri sono: P_tot =~ 120 kW e P_UPS(info) =~ 80 kW
• PUE = P_tot/P_UPS(info) = 1.5
• (W/HS06 = 5.8)
58
6. Riassumere i contributi forniti da CSN, CCR e GE negli ultimi 5
anni per lo sviluppo dell’infrastruttura e il funzionamento del sito.
• Negli ultimi 5 anni CSN e GE non hanno contribuito nè
allo sviluppo dell’infrastruttura nè al funzionamento del
sito.
• La CCR ha contribuito
 2010: 42 k€ + 25 k€ per Router 10 Gbps, switch servizi,
ottiche
 2013: 9.5 k€ batterie UPS, finanz straordinario consumo
 2013: 20 k€ Router di frontiera T2
• I contributi citati sono condivisi tra ATLAS e CMS
59
7. Definire l’impegno da parte della struttura ospitante per la manutenzione
ordinaria e straordinaria dei componenti dell’infrastruttura.
• Il Dipartimento di Fisica si limita a fornire i locali
nell’ambito della convenzione con l’INFN (e la corrente!)
• La Sezione di Roma dell’INFN ha a suo carico la
manutenzione ordinaria dell’infrastruttura di cooling, la
manutenzione elettrica a valle dei quadri di distribuzione
(finora è costata quasi zero, sono stati sostituiti due
sezionatori del costo di circa 300 euro l’uno in 6 anni) e la
manutenzione della rete dati.
• Le spese di manutenzione straordinaria, escluse quelle
citate al punto 6 a carico della CCR, sono state finora
trascurabili e a carico della Sezione.
60
8. Indicare la data di scadenza della convenzione per la fornitura
di energia elettrica con l’Universita’ e se questa prevede
limitazioni di utilizzo del Tier-2.
• Come già spiegato nel rapporto non c’è una convenzione
specifica per la fornitura di energia elettrica: c’è una
convenzione generale tra Università e INFN firmata nel
2013 e di durata quinquennale, quindi con scadenza nel
2018.
61
9. Indicare se le risorse del Tier-2 sono disponibili per
uso opportunistico per altri gruppi di ricerca.
• Le risorse del Tier-2 in linea di principio sono disponibili
per uso opportunistico, purchè questo non implichi un
carico di lavoro addizionale per le persone responsabili
del sito, in particolare per il responsabile tecnico Dr.Ivano
Talamo che è già impegnato al 100% per la gestione
CMS.
• quindi = si possono aprire all’uso opportunistico, ma tale
deve essere
• No support!
62
10.Indicare se ci sono gruppi di ricerca oltre a CMS
supportati direttamente dal Tier-2.
• NO
63
11.Valutare i pro e contro di una eventuale
unione col Tier-2 di ATLAS.
• I Tier-2 di ATLAS-Roma e CMS-Roma sono gia’ uniti
nell’infrastruttura non solo di base (cooling, rete etc.) ma
anche dei servizi software (LFS, monitor, installazione
etc).
• Quello che NON e’ unito e’ attualmente
1. Lo storage
2. I WN/le code (ognuno gira sulle sue macchine)
3. I Computing Element (cioe’ sono due “siti” WLCG distinti)
• Analizziamo uno per uno questi punti, con costi/benefici
dell’unione
64
1 – lo storage
• RM1-CMS usa dCache, RM1-ATLAS DPM
• D’altra parte
• DPM e’ da sempre la tecnologia + problematica per CMS. Ha sempre
richiesto patch per la messa in produzione (incompatibilita’ a livello di
librerie SSL con CMSSW), e il suo utilizzo a livello mondiale e’ in calo
verticale. Attualmente, per siti nuovi, CMS consiglia di NON adottarlo.
La sua sostenibilita’ in CMS e’ dubbia, e lo e’ anche a livello WLCG
(ATLAS ha dovuto accollarsene in parte lo sviluppo / manutenzione)
• dCache e’ invece la tecnologia d’eccellenza x CMS, e la sua
sostenibilita’ non e’ in dubbio fino a che FNAL lo utilizza (e NON
esistono piani attualmente per un cambiamento a FNAL)
• RM1-CMS ha un’ampia esperienza in dCache, e’ il sito italiano che lo
prova per primo, e Ivano Talamo e’ ben inserito nella comunita’ degli
sviluppatori dCache
• Indipendentemente da tutto, un cambio di tecnologia con 1 PB
installato e pieno non e’ facile (a meno di non avere un altro PB
vuoto….)
65
2 – WN/le code
• I WN sono configurati in modo molto simile e CMS/ATLAS
stanno gia’ lavorando per ottenere una configurazione
comune gestita via “Puppet”.
• Al momento i WN targati ATLAS e quelli targati CMS si
trovano in code batch diverse, accessibili rispettivamente
dai job Grid delle rispettive VO.
• Nulla osta a abilitare l’accesso incrociato ai WN,
sebbene in periodo di presa dati questa scelta
potrebbe essere riconsiderata
66
3 – I CE (e in generale i siti WLCG)
• CE: al momento 4 per ATLAS e 3 per CMS
• Siti WLCG: INFN-ROMA1 (Atlas), INFN-ROMA1-CMS (CMS):
• Richiede riconfigurazione dei CE (poco male…)
• Richiede interventi manuali a tutti i sistemi di monitoring / accounting
esistenti (WLCG, CMS, MONALISA, HLRMON, REBUS, SiteDB di CMS,
database Phedex ….)
• nella pratica NON esiste un modo certificato per farlo se non … farlo e poi mettere
una pezza ai problemi, che possono necessi
• Molto probabimente si perderebbe tutto lo storico antecedente
• Prova della sua complessita’: alcuni siti si sono trovati con nomi non ottimali,
e non hanno mai pensato di cambiarli
• LNL si chiama tuttora INFN-LNL-2
• Karlsruhe ha cambiato nome in KIT prima dell’inizio della presa dati. Un bagno di
sangue durato 2 mesi
• Il guadagno e’ minimo: probabilmente per 2 T2 servirebbero comunque 7
CE, che sono comunque configurati uguali a meno di quella stringa …
• La (high) availability data da 3 CE non e’ troppo diversa da quella con
4,5,6 …
67
12.Il modello di calcolo di LHC potrebbe evolvere verso un numero minore di centri di
maggiori dimensioni. Per questioni di economia di scala questi centri potrebbero essere
multidisciplinari. Dire quali sono in termini di infrastruttura e/o personale i possibili margini di
espansione del vostro sito.
• l’attuale Tier-2 (ATLAS+CMS) occupa 10 rack e si puo’ espandere
fino a 14 rack senza modifiche dell’infrastruttura elettrica e di cooling,
senza costi aggiuntivi (a parte ovviamente l’acquisto dei rack) e negli
spazi di nostra competenza
• I 10 rack attuali sono completamente pieni, ma non contengono tutti
hardware di ultima generazione. Utilizzando
• CPU da 16 core
• Dischi da 4
• Si potrebbe raddoppiare il centro a parita’ di tutto il resto OGGI
(+legge di Moore per il futuro).
• Un aumento del numero di rack oltre 14 richiede un notevole
aggiornamento dell’infrastruttura di base, sia elettrica che di
cooling, oltre che una trattativa sugli spazi, che, pur essendo
disponibili, non sono di nostra competenza.