ppt

Stato del Tier-1
secondo gli esperimenti LHC
U. Marconi
INFN, Sezione di Bologna
CSN1, 1/2/05
1
Sommario
• Ruolo del Tier-1 secondo gli esperimenti LHC.
• Esperienza del 2004.
• Considerazioni sullo stato degli elementi
fondamentali del centro.
– Infrastruttura, Rete, Farm, Disco, Tape.
• Considerazioni sull’organizzazione.
• Conclusioni.
2
Ruolo del Tier-1
• Il Tier-1 riceve dal Tier-0 una frazione dei dati raw, o di dati già
sottoposti ad una prima fase di ricostruzione, e deve archiviarli.
• I dati debbono essere elaborati in loco per produrre dati in formato
utile all’analisi.
• I dati da analizzare debbono essere inviati ai Tier-2 e agli altri Tier1.
• La produzione MC è effettuata nei Tier-2 ma archiviata nel Tier-1,
che provvede anche a smistarli verso gli altri Tier.
• Il Tier-1 deve anche essere dotato di risorse con cui effettuare
l’analisi.
– Ciò è essenziale per LHCb in quanto prevede di fare tutta l’analisi al Tier-1.
– Gli altri esperimenti LHC prevedono che grossa parte dell’analisi sia fatta
nei Tier-2.
• Il Centro deve avere esercitare un ruolo di indirizzo nelle scelte
tecniche e fornire assistenza ai Tier-2.
3
Schema (semplificato) del Tier-1
Local Area Network
Data in
Data out
GRID front-end
(data)
Scheduled
Farm
(re-reconstruction)
Application software
Jobs in
GRID front-end
(jobs)
Disk storage
Chaotic
Farm
(analysis)
Application software
Batch scheduler
Tape
Various Services
(GRID infrastructure,
Databases, Monitoring,
Web Services, etc.)
Infrastructure
(Cooling, Power, UPS,
Fire Estinguisher,
Cabling, etc.)
OpenLab
(HW and SW R&D) 4
Sviluppo del Tier-1
ATLAS
• All’avvio di LHC
–
–
–
–
Disco: ~1PB
Tape: ~ 1PB
CPU: ~ 10MSi2k
Rete:
2007
2008
2009
2010
2011
2012
Disk
(TB)
550
1500
2300
4200
5700
7200
Tape
(TB)
300
1000
1800
3100
4500
6100
CPU
(MSi2k)
0.8
2.6
4.8
8.1
12.
17
2011
2012
• Tier-0: 10Gb/s
• Tier-1, Tier-2: 1Gb/s
• In seguito crescono di
un ordine di grandezza:
disco, tape e CPU
LHCb
2006
2007
2008
2009
2010
Disk
(TB)
120
240
400
500
560
Tape
(TB)
100
200
350
700
1200
CPU
(MSi2k)
0.22
0.44
0.74
0.92
1.4
5
Esperienza nel 2004
• Per la prima volta:
– E’ stata utilizzata un’unica farm di considerevoli
dimensioni (circa 750 CPU) condivisa da tutti gli
esperimenti.
– Si è pesantemente fatto ricorso allo storage su disco.
– E’ stata utilizzata l’archiviazione su tape per decine di
TB di dati.
– Si è utilizzata massicciamente la GRID in produzione.
• Fra molte difficoltà è stato possibile guadagnare
importanti informazioni.
6
Esperienza: Farm (I)
• Il batch server/scheduler di pubblico dominio
Torque/MAUI, adottato per la sottomissione dei job, si è
rivelato inaffidabile.
– Nelle attese il sistema open source doveva essere potentissimo.
– Ha mostrato seri limiti di scalabilità senza ragioni facilmente
comprensibili.
– Scarso il supporto da parte degli sviluppatori.
• Di recente è stata presa la decisione di passare a LSF.
– Sistema proprietario, utilizzato con successo al CERN.
• Errata o disomogenea configurazione dei nodi.
– Ad esempio, i dischi di rete talvolta non sono stati montati.
– E’ sufficiente usare maggiore rigore e affidarsi a servizi di
monitoraggio adeguati.
7
Esperienza: Farm (II)
• Stato di riempimento completo di un disco interno
dei nodi di calcolo della farm.
– Effetto “buco nero”: il nodo risucchia tutti i job in coda
nello scheduler, che non trovando spazio disco muoiono
all’istante. Un incubo per i manager di produzione!
– Bisogna adottare servizi di monitoraggio che
retroagiscano sullo scheduler o sul WMS di GRID.
– Una trovata è stata il “pilot job”, che prima di
sottomettere il job vero e proprio sonda lo stato del
nodo e verifica che esso soddisfi i requisiti necessari
all’esecuzione.
8
Esperienza: Storage disco (I)
• Vari problemi a basso livello sull’hardware.
– La prima soluzione immaginata per procurarsi spazio disco, di
cavarsela cioè con soluzioni storage a basso costo o magari
assemblate, pur se con buone componenti, si è rivelata
impraticabile.
– I dispositivi disco sono oltremodo delicati ed un
malfunzionamento può far perdere migliaia di ore di
computazione.
– E’ necessario ricorrere a prodotti di marca, di aziende che
possano garantire affidabilità e supporto tecnico.
– I problemi di affidabilità hanno limitato la disponibilità di risorse
con cui soddisfare le esigenze di spazio disco degli esperimenti.
– Con la messa in produzione di sistemi SAN di grosse dimensioni,
come l’IBM FASsT900, e l’aggregazione dei volumi, mediante
file system paralleli, dovremmo superare anche questa difficoltà.
9
Esperienza: Storage disco (II)
• Problemi seri con il protocollo NFS per l’export dei dischi in rete
verso i nodi di calcolo.
– NFS è utilizzato principalmente per la condivisione del software applicativo da
parte dei nodi di calcolo, ma in parte anche per lo storage dei dati.
– I nodi della farm a turno, casualmente, si trovano nell’impossibilità di accedere
al disco. La conseguenza è il blocco di tutti i job che fanno uso del disco di
rete coinvolto.
– Il motivo a tutt’oggi è ignoto. Forse si deve all’accoppiamento di punti di
debolezza del protocollo, o dell’implementazione Linux di NFS, con le latenze
dovute alla complessità della rete del centro.
– Sono state pazientemente individuate cure che limitano il problema, pur senza
risolverlo.
• Come repository del software la soluzione verso la quale ci si sta
orientando è quella di abbandonare NFS e passare ad AFS, che offre,
almeno come protocollo, maggiori garanzie di robustezza.
10
Esperienza: Tape
• Problemi a basso livello sull’hardware.
– Il funzionamento dei drive LTO2 con CASTOR ha mostrato seri limiti.
– Uno stress notevole per il responsabile del servizio costretto al baby-sitting dei
drive.
– Si dovrebbe curare con il passaggio ai 9940B: a breve lo sapremo.
• A più alto livello:
– Al momento l’accesso caotico ad una grossa quantità di dati è una pretesa
eccessiva. Se i dati su nastro non sono letti in maniera accorta, il sistema
diventa difficilmente impiegabile.
– Il problema si cura aumentando il numero di lettori, ma soprattutto disponendo
di un’area disco di dimensioni comparabili con l’area tape.
– Aiuta certamente in questa fase pianificare con l’amministratore del sistema il
trasferimento su disco di insiemi di dati di grossa dimensione.
• Ad esempio se c’è da fare reprocessing l’esperimento chiede una quota temporanea
di disco e passa all’amministratore di CASTOR la lista dei file. L’amministratore li
copia su disco in modo intelligente. Dopo il reprocessing il disco può essere
liberato.
– Le prestazioni di CASTOR sono una questione aperta anche e soprattutto per il
CERN.
11
Valutazione
• Infrastruttura:
– E’ adeguata.
• Rete:
– L’esperienza in questo ambito è molta, ma poiché la scala è grande, è
necessario potenziare gli strumenti di monitoraggio e definire strumenti
per la certificazione di tutte le sue parti, senza dare nulla per scontanto.
• Farm:
– La competenza è avanzata: si è imparato come costruirle.
– E’ essenziale disporre di strumenti di monitoraggio e un’allarmistica
maggiormente efficaci. Ciò che esiste non è stato utilizzato in maniera
appropriata.
• Storage disco e Tape:
– Sono elementi critici.
– E’ necessario investire su questo.
• Organizzazione del lavoro e disponibilità di man power:
– E’ cruciale, come dirò nel seguito.
12
Sull’organizzazione (I)
• È necessario lavorare per attuare la transizione da una
condizione di lavoro artigianale (in cui si procede anche
grazie a trovate estemporanee, possibili su piccola scala)
ad una impostazione industriale e sistematica.
• Manca un organigramma dettagliato.
• Il personale è insufficiente ed è impiegato in troppi servizi
con naturali perdite di efficienza.
• La mancanza di personale sta limitando fortemente la
possibilità di collaudo, certificazione e sperimentazione
delle risorse hardware e del software.
– Non si possono usare in produzione elementi non collaudati.
– È necessario definire protocolli di certificazione di ogni elemento
critico.
• Gli esperimenti dovranno collaborare alla definizione dei
protocolli di certificazione.
13
Sull’organizzazione (III)
• Ricerca e sviluppo
– È naturale immaginare che l’impiego su questa scala di
tecnologie costose e potenti possa fornire importanti ricadute a
tutto vantaggio dell’Ente.
– Come si fa R&D nello sviluppo del software di GRID, così si
dovrebbe fare sui sistemi di calcolo e infrastrutturali.
• Non si pretende di inventare un nuovo dispositivo hardware, si possono
però sperimentare soluzioni hardware e software nuove (es.: filesystem
paralleli di nuova generazione), ricavando uno spazio di OpenLab
all’interno del centro.
• Lo si potrebbe fare sottraendo una frazione del tempo e delle risorse spese
nei servizi di routine.
• Questo aspetto è importante per la maturazione professionale del personale
impegnato nella gestione del Centro e servirebbe anche per dare loro
maggiore motivazione e soddisfazione.
14
Sull’organizzazione (IV)
• Man power
– Per coprire le esigenze di servizio del Centro, già ora e a maggior
ragione a regime, occorre iniettare nuovo personale.
– Stime ragionevoli si attestano su ordine di 10 unità mancanti.
• Si dovrebbe inoltre tenere conto del fatto che una frazione del tempo
dovrebbe essere resa disponibile per attività di ricerca e innovazione anche
per il personale di servizio.
– Inoltre, gli esperimenti ritengono importante avere personale al
Tier-1 specificamente dedicato alle loro esigenze.
– Non è una buona idea rimandare ancora nuove assunzioni: si deve
infatti tenere conto del tempo necessario alla formazione e
all’assestamento di nuove forze.
• Per formare un operatore esperto valutiamo occorrano due anni.
15
Uso della GRID
• Durante il 2004, gli esperimenti LHC hanno fatto
parzialmente o integralmente uso al Tier-1 degli
strumenti di GRID.
• Per il 2005 tutte le componenti italiane del calcolo LHC
sono d’accordo nell’impiegare, in produzione, al Tier-1,
esclusivamente gli strumenti di GRID nella versione
fornita dall’INFN.
– Nel caso in cui per far ciò sarà necessario fare adattamenti al
software d’esperimento si confida nella disponibilità e
collaborazione degli sviluppatori/amministratori della GRID
italiana.
16
Conclusioni
• Il Centro a partire dall’avvio del progetto è cresciuto
molto.
• C’è ancora tanto lavoro da fare, soprattutto nel
reclutamento, nella formazione e nell’organizzazione.
• È importante che gli esperimenti abbiano un ruolo attivo
e collaborino alla soluzione dei problemi.
• Benché i servizi di GRID permettano di pensare ad un
modello di calcolo decentrato, più opportunistico, in linea
di principio, di quello gerarchico, è essenziale vi sia un
forte cuore al suo centro.
• Il Tier-1 deve funzionare!
17