La nuova Sala Calcolo-V12

Transcript

La nuova Sala Calcolo e la farm
di Bari
INFN – Sezione di Bari
2 novembre 2009
Le seguenti persone hanno contribuito alle attività descritte in questo documento:
Per il complesso delle infrastrutture (impianto elettrico, condizionamento, sistema UPS, sistema di
controllo, infrastruttura di rete e di storage, sistemi gestione e monitoring della farm,…):
Giacinto Donvito
Vincenzo Spinoso
Riccardo Gervasoni
Domenico Diacono
Giorgio Pietro Maggi
Eugenio Nappi
Per le componenti specifiche di ALICE
Antonio Franco
Domenico Di Bari
All’attività di analisi e produzione di CMS
Alexis Pompili
Marcello Maggi
Nicola De Filippis
Lucia Barbone
Marcello Abbrescia
Vincenzo Spinoso
All’attività di analisi e produzione di ALICE
Giuseppe Bruno
Domenico Di Bari
Carmelo Di Giglio
Domenico Elia
Vito Manzari
Giacomo Volpe
Davide Perrino
Le opere edili, gli impianti elettrici, idraulici, di condizionamento e di controllo sono stati realizzati
dalla ditta IECI di Cavone Nicola & C. snc con sede in Corso Vittorio Emanuele , 24 70128 Palese
(Bari) sotto la supervisione del Direttore dei lavori Ing. Alfredo Magnanimo.
Page 2
1 Indice
La nuova Sala Calcolo e la farm di Bari ...................................................................................................... 1
1 Indice ....................................................................................................................................................... 3
2 Indice delle figure ................................................................................................................................... 5
3 Indice delle tabelle.................................................................................................................................. 6
4 L’Infrastruttura........................................................................................................................................ 7
4.1 La logistica ...................................................................................................................................... 7
Il sistema di rack ....................................................................................................................................... 8
4.2 I Chiller.......................................................................................................................................... 10
4.3 Il sistema di UPS........................................................................................................................... 12
4.4 I sistemi di sicurezza..................................................................................................................... 14
4.4.1 Allarme generico segnalazione guasti impianto antiincendio ............................................ 14
4.4.2 L’allarme chiller .................................................................................................................... 14
4.4.3 L’allarme alta temperatura sala S1+S3 ................................................................................ 14
4.4.4 Pulsante sgancio alimentazione sala S1+S3 ....................................................................... 14
4.4.5 L’impianto di rilevazione incendi ........................................................................................ 14
4.4.6 L’impianto spegnimento incendi.......................................................................................... 15
4.4.7 L’impianto di rilevazione allagamenti ................................................................................. 15
4.4.8 Pulsante sgancio alimentazione sala S9.............................................................................. 16
4.4.9 Il monitoring della temperatura effettuato da mon2 ........................................................... 17
4.4.10 Procedura di spegnimento di emergenza da remoto ......................................................... 18
4.4.11 Sistema di video sorveglianza ............................................................................................ 18
4.4.12 APC InfraStruXure Manager (host proprietario fornito da APC).................................... 18
4.4.13 Ulteriori sistemi di monitoring da implementare .............................................................. 19
4.5 La potenza realmente disponibile in cabina. ............................................................................... 20
4.5.1 Upgrade della Cabina di trasformazione ............................................................................. 21
4.6 Completamento e manutenzione................................................................................................. 23
4.6.1 Stima dei costi per il completamento dell’infrastruttura. ................................................... 23
4.6.2 Stima dei costi di manutenzione........................................................................................... 23
5 La Farm ................................................................................................................................................. 24
5.1 Le risorse computazionali............................................................................................................. 24
5.2 La farm di Bari nel panorama nazionale ..................................................................................... 26
5.3 Lo storage ...................................................................................................................................... 26
5.3.1 Le esigenze ............................................................................................................................ 26
5.3.2 La soluzione precedente........................................................................................................ 27
5.3.3 Risultati dei test di storage.................................................................................................... 28
5.3.4 La configurazione dello storage nella farm di Bari............................................................. 32
5.3.5 La migrazione al nuovo sistema e il confronto con il vecchio ........................................... 33
5.4 L’infrastruttura di rete................................................................................................................... 36
5.4.1 Indirizzi IP utilizzati e riservati ........................................................................................... 38
5.5 Il software ...................................................................................................................................... 39
5.5.1 I sistemi operativi e i relativi kernel..................................................................................... 39
5.5.2 Le procedure di installazione................................................................................................ 39
5.6 Il sistema di code locali ................................................................................................................ 39
5.7 Il sistema di monitoring................................................................................................................ 42
5.8 Il sistema di Accounting ............................................................................................................... 45
5.8.1 Il sistema di accounting locale ............................................................................................. 45
5.8.2 Il sistema di accounting centrale (HLRmon)....................................................................... 45
5.9 I Servizi della farm: scalabilità e affidabilità .............................................................................. 47
5.9.1 Il batch manager .................................................................................................................... 47
5.9.2 Il BDII .................................................................................................................................... 47
5.9.3 Il Computing Element........................................................................................................... 48
5.9.4 L’MDS di Lustre ................................................................................................................... 48
5.9.5 User interface e front end per utilizzo interattivo ............................................................... 48
5.9.6 Accesso allo spazio disco: StoRM e Xrootd ....................................................................... 48
5.9.7 I servizi di Grid...................................................................................................................... 49
5.9.8 I servizi per le VO ................................................................................................................. 49
Page 3
5.10 Le prestazioni della farm ............................................................................................................ 50
Attività di analisi dati e produzione Monte Carlo gruppo CMS....................................................... 51
6.1 Attività sulla farm di Bari............................................................................................................. 51
6.1.1 SUSY (ed EWK) ................................................................................................................... 51
6.1.2 Determinazione prestazioni RPC mediante stream dedicato.............................................. 51
6.1.3 RPC Muon Trigger Performance ......................................................................................... 52
6.1.4 Stima della muon fake rate e test di accesso allo storage................................................... 53
6.1.5 EWK con µ + τ-jet (e PF/τ-POG)........................................................................................ 53
6.2 Attività del gruppo di Bari nella ricerca dell’Higgs ................................................................... 54
6.3 Attività di produzione Monte Carlo ............................................................................................. 54
7 Attività di analisi dati e produzione Monte Carlo gruppo ALICE ................................................... 56
7.1 Attività sulla farm di Bari e GRID............................................................................................... 56
7.1.1 Produzioni Monte Carlo........................................................................................................ 56
7.2 Attività di analisi del gruppo di Bari ........................................................................................... 56
7.2.1 Misura di dN/dη con il rivelatore a pixel in ambito first physics ...................................... 56
7.2.2 Misura di J/psi da decadimento di adroni con beauty......................................................... 57
7.2.3 Analisi di jet con identificazione di adroni carichi ............................................................. 57
7.2.4 Analisi dei primi dati di ALICE con cosmici ...................................................................... 58
7.2.5 Il Very High Momentum Particle Identification Detector: VHMPID ............................... 58
7.2.6 Attività di analisi future per il gruppo ALICE-Bari............................................................ 59
6
Page 4
2 Indice delle figure
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
Fig.
1 - Pianta dei locali del nuovo centro di calcolo................................................................................. 7
2 - Isola APC con i rack in cui è installata la farm............................................................................ 9
3 - Il sistema dei chiller per il raffreddamento dell'acqua............................................................... 11
4 - I due UPS attualmente installati................................................................................................... 12
5 - Le bombole contenenti il gas inerte del sistema spegnimento incendio. Le prime due servono i
locali S1+S3, le altre tre rispettivamente i locali S5, S7 ed S9 ....................................................... 16
6 - Andamento della temperatura misurata sulla CPU di alcuni server, elencati nella figura,
installati nei rack della sala calcolo................................................................................................... 17
7 - Andamento della temperatura misurata sulla CPU di due server, elencati nella figura,
fisicamente installati nel Corridoio Caldo. ....................................................................................... 18
8 - Schermata prodotta dal sistema di monitor dei rack APC (lavora solo sotto Windows). ........ 19
9 - Andamento degli assorbimenti misurati in cabina nel periodo 15 - 26 luglio 2009................. 20
10 – Le risorse computazionali in funzione dei fondi utilizzati per l'acquisto. ............................. 25
11 - Le risorse di storage in funzione dei fondi utilizzati per l'acquisto. ....................................... 25
12 – La pagina di monitoring di GridMap ........................................................................................ 26
13 - Schema del precedente sistema di storage ................................................................................ 28
14 - Numero di bytes scritti al secondo in funzione del numero di client concorrenti e della
configurazione hardware/software adottata...................................................................................... 29
15 - Numero di bytes al secondo letti in maniera random in funzione del numero di client
concorrenti e della configurazione hardware/software adottata...................................................... 30
16 - Tempo speso per I/O wait da un job di analisi in funzione del numero dei job concorrenti per
Lustre e dCache. ................................................................................................................................. 31
17 - Durata del processo di un-tar di un kernel in funzione dei processi concorrenti per Lustre e
dCache. ............................................................................................................................................... 31
18 - La configurazione attuale del sistema di storage della farm di Bari........................................ 32
19 - Efficienza di CPU per job di analisi di un utente Susy, rappresentati per siti diversi che
ospitavano lo stesso dataset. (a Bari era utilizzato dCache). ........................................................... 33
20 - Efficienza di CPU nell’esecuzione dei job di analisi di test, denominati JobRobot, quando i
dati erano ospitati su dCache............................................................................................................. 33
21 - Efficienza dell’uso della CPU per job di analisi di un utente Susy, dopo la migrazione dei
dati su Lustre (il grafico mostra le efficienze per tutti i Tier2 di CMS che contenevano il dataset
in oggetto)........................................................................................................................................... 34
22 - Efficienza dell’uso della CPU per job del JobRobot, dopo la migrazione dei dati su Lustre (il
grafico mostra le efficienze per tutti i Tier2 di CMS). .................................................................... 34
23 - Efficienza di uso della CPU per job di analisi su dati di QCD per job molto I/O intensive (il
grafico mostra le efficienze per tutti i Tier2 di CMS). .................................................................... 35
24 - Schema dell'infrastruttura di rete .............................................................................................. 36
25 – Il backbone della rete (HP ProCurve Switch 5412zl Intelligent Edge) con le connessioni
attualmente attive. .............................................................................................................................. 37
26 - Test di performance dell'infrastruttura di rete........................................................................... 38
27 - Utilizzo della farm nella settimana dal 12/10/2009 al 19/10/2009......................................... 42
28 - L'utilizzo della farm nella settima dal 12/10/2009 al 19/10/2009 da parte dei alcuni
utilizzatori della farm: theophys, cms, glast. La linea nera indica le risorse acquistate con i fondi
della VO, la linea blu indica il numero massimo di job running per quella VO........................... 43
29 - Andamento delle temperature misurate all'interno dei server indicati nella caption della
figura. .................................................................................................................................................. 44
30 - Uso della risorse ripartito tra le VO negli ultimi 30 giorni (18/10/09).................................... 45
31 - Uso delle risorse della farm di Bari in funzione delle VO negli ultimi 30 giorni (18/10/09).46
32 - Uso della farm di bari nell'ultimo anno. .................................................................................... 46
33 - la configurazione dei principali servizi della farm ................................................................... 47
Page 5
Fig. 34 - A sinistra: la “site availability” ( >80%) del sito di Bari nell’ultimo anno; a destra la “site
availability” nelle ultime due settimane. .......................................................................................... 50
Fig. 35 - Site availability di Bari a confronto con gli altri T2 di CMS a partire dall'inizio del 2009. Si
noti il buco a metà maggio causato dallo shut down per lo spostamento della farm..................... 50
Fig. 36 - L'efficienza RPC Muon Trigger nel piano phi-z....................................................................... 52
3 Indice delle tabelle
Tabella 1 - - Elenco dei locali e loro destinazione. ..................................................................................... 7
Tabella 2 - Caratteristiche tecniche dei chiller. ......................................................................................... 10
Tabella 3 - Quadro economico per aumento potenza in cabina e gruppo elettrogeno........................... 22
Tabella 4 - Costi apparecchiature da acquistare a completamento. ....................................................... 23
Tabella 5 - Costi annui di manutenzione. .................................................................................................. 23
Tabella 6 - Il dettaglio delle risorse della farm e dei fondi utilizzati per l'acquisto................................ 24
Tabella 7 – Caratteristiche HP ProCurve Switch 5412zl Intelligent Edge (J8698A). ............................ 36
Tabella 8 - Le code batch implementate sulla farm di Bari..................................................................... 40
Tabella 9 - I servizi di Grid. ....................................................................................................................... 49
Tabella 10 - I servizi per le VO. ................................................................................................................. 49
Page 6
4 L’Infrastruttura
4.1 La logistica
Il nuovo centro di calcolo della Sezione INFN di Bari é stato localizzato nei locali S1, S3, S5, S7 ed
S9 del Dipartimento Interateneo di Fisica. I locali denominati S1 ed S3 sono stati uniti per realizzare
un unico ambiente di dimensioni 5,70x8,50 m2 pari a circa 50 m2, in cui è stata localizzata la computer farm. Le stanze S5, S7 ed S9 hanno invece una dimensione di 4,30x3,30 m2, pari a 14 m2 ciascuna.
In totale l’area complessiva destinata al nuovo centro di calcolo è di 50+14x3= 92 m2.
S9
S7
S5
S3
S1
Fig. 1 - Pianta dei locali del nuovo centro di calcolo
In particolare:
Tabella 1 - - Elenco dei locali e loro destinazione.
Area (m2)
Locale
Dimensioni
locale (mxm)
Funzione
S1+S3
5,70x8,50
50
Computer farm
S5
4,30x3,30
14
APE + espansione
S7
4,30x3,30
14
Servizi centrali della Sezione (mail server, WEB server,
DNS,.. etc)
S9
4,30x3,30
14
Quadro Elettrico e UPS
Tutti i locali sono dotati di pavimento flottante realizzato con pannelli in resine ad alta densità
(legno truciolato) ricoperte in laminato antistatico, di dimensioni 600 x 600 mm2 con spessore
40 mm in grado di sopportare carichi >1500 kg/m2 e con resistenza al fuoco classe 1 REI45. Il
pavimento è poggiato su una struttura composta da colonnine, regolabili in altezza, e traverse
in acciaio zincato.
Page 7
Il sistema di rack
La Computer Farm utilizza il sistema InfrastruXure High Density della APC ed è costituita da
14 Armadi Rack Server disposti in una configurazione isola fredda / isola calda. Il complesso
dei rack viene refrigerato da n° 8 unità di condizionamento In-Row RC da 25 kW l’una che
corrispondono ad una capacità di raffreddamento media di 14 kW per rack (12,5kW in ridondanza N+1).
Le 8 unità In-Row RC sono in grado di neutralizzare fino a 200kW di calore e 175kW in una
configurazione con ridondanza N+1.
Il sistema è già predisposto per essere espanso con altri 4 Armadi Rack Server e n° 2 unità di
condizionamento In-Row RC. Il sistema completo sarà quindi composto da 18 rack disposti in
due file da 9 rack ciascuna e da n° 10 unità di condizionamento In-Row RC 10 con una capacità complessiva di raffreddamento di 250 kW e 225 kW in ridondanza N+1 corrispondenti a
14 kW in media per Rack (12,5kW in ridondanza N+1).
L’alimentazione dei 14 Armadi Rack Server è fornita attraverso una presiera di servizio per
ogni rack ancorata al soffitto della stanza. La presiera è munita di tre prese ciascuna in grado
di erogare fino a 7 kW per un totale di 20 kW. La presiera è connessa direttamente al quadro
elettrico con un singolo cavo. Sul quadro elettrico ciascun cavo viene alimentato attraverso un
proprio interruttore tarato per erogare 20 kW con una sensibilità sul differenziale di 0.003
mA.
Per fornire la doppia alimentazione a dispositivi critici come per esempio dispositivi di storage o servizi centrali della farm, ogni presiera è fornita di una ulteriore presa detta di “riserva”
che viene alimentata attraverso una linea indipendente: di fatto tutte le prese di “riserva” delle
presiere relative ad una delle due file di rack vengono alimentate da uno stesso cavo controllato sul quadro elettrico da un proprio interruttore tarato per erogare una potenza di 20 kW1.
Ogni rack è dotato di due strisce di alimentazione da 24 prese tipo Metered con amperometro
e scheda IP per monitorare l’assorbimento in tempo reale.
Nella figura Fig. 2 è mostrato il complesso dei rack attualmente installati nella sala S1+S3.
Come si vede dalla figura i rack sono disposti su due file: con B si indica la fila più vicina
alle finestre e con A l’altra fila.
1
Nella configurazione attuale l’alimentazione delle prese di “riserva” è prelevata a valle degli UPS e
quindi in parallelo con il resto dell’alimentazione. Quindi di fatto non è una alimentazione indipendente. Ai fini di questa nota è importante sottolineare che l’impianto è predisposto per utilizzare una alimentazione di riserva se disponibile. Si sta valutando se prelevare l’alimentazione della linea di riserva direttamente dalla rete a monte degli UPS.
Page 8
Fig. 2 - Isola APC con i rack in cui è installata la farm
Page 9
4.2 I Chiller
La produzione di acqua fredda a 7 °C viene realizzata con due chiller WSAT–EE502 della
CLIVET.
Nella Tabella 2 sono riportate le caratteristiche tecniche dei due chiller.
Tabella 2 - Caratteristiche tecniche dei chiller.
La potenzialità frigorifera complessiva è di 250 kW senza ridondanza e 189 kW con ridondanza N+1. Ciascuno dei due chiller, infatti, è composto da due unità indipendenti che possono lavorare ciascuna per proprio conto. La potenza massima assorbita è di 62 kW per ciascun
chiller quando entrambe le unità dello stesso chiller entrano in funzione. La presenza di due
unità consente al WSAT–EE502 di adeguare la potenza assorbita alle reali necessità e di ope-
Page 10
rare con un meccanismo a gradini. Come si vede dalle specifiche il WSAT–EE502 dispone
di due gradini corrispondenti alle due unità indipendenti presenti nel sistema.
La Fig. 3 mostra i due chiller sulla piattaforma appositamente realizzata con i due serbatoi di
acqua fredda.
Fig. 3 - Il sistema dei chiller per il raffreddamento dell'acqua
Page 11
4.3 Il sistema di UPS
Come UPS è stato utilizzato il sistema MASTERYS MC - UPS trifase 80 kVA della Socomec Sicon.
Nella configurazione attuale il sistema si compone di due unità da 80 kVA, che funzionano in parallelo, in grado di fornire una potenza di 80 kVA (64 kW) pienamente ridondata e 160 kVA (128 kW)
senza ridondanza.
Sfruttando la possibilità di mettere in parallelo fino a sei unità, il progetto a regime prevede l’aggiunta
di un terzo elemento per spingere la potenza complessiva erogabile a regime fino a 240 kVA (192
kW) senza ridondanza e 160 k VA (128 kW) con ridondanza N+1.
Il sistema ha una autonomia massima di 10 minuti a pieno carico, leggermente maggiore con un carico
ridotto. In ogni caso l’uso di unità UPS con questa limitata autonomia ha il solo scopo di superare
l’intervallo di tempo tra l’interruzione dell’erogazione dell’energia e la partenza del gruppo elettrogeno (al momento non ancora disponibile).
Fig. 4 - I due UPS attualmente installati
Page 12
Nella figura
Fig. 4 è mostrata la sala con i due UPS.
Page 13
4.4 I sistemi di sicurezza
La sicurezza della farm viene realizzata attraverso diversi sistemi di allarmistica e di intervento sia attivo che passivo tra loro complementari.
4.4.1 Allarme generico segnalazione guasti impianto antiincendio
In caso di guasto nell’impianto di rilevazione e spegnimento incendi (per esempio mancanza
di alimentazione elettrica, perdita di pressione nelle bombole, etc.) verrà segnalato un guasto
generico alla squadra di pronto intervento utilizzando un combinatore telefonico installato
sulla linea 080 5442403.
La squadra di pronto intervento si compone di:
Maggi
Diacono
Donvito
Spinoso
Gervasoni
Telefonino 348 0454699
4.4.2 L’allarme chiller
I due chiller vengono costantemente monitorati al fine di individuare eventuali blocchi del
loro normale funzionamento inclusa l’assenza di alimentazione.
In caso di malfunzionamento di uno dei due chiller viene attivato un allarme, che attraverso
un combinatore telefonico installato sulla linea 080 5442451, segnala alla squadra di pronto
intervento (già citata) quali dei due chiller ha manifestato segni di malfunzionamento.
4.4.3 L’allarme alta temperatura sala S1+S3
La temperatura della sala S1+S3 viene monitorata da un termostato: se la temperatura ambiente supera la temperatura di 48° C, viene interrotta l’alimentazione elettrica alla sala. In
pratica vengono disattivati gli interruttori generali sulle linee di alimentazione A e B a valle
dell’UPS.
N.B.: Questo intervento non dis-alimenta le altre sale, gli UPS e i Chiller.
4.4.4 Pulsante sgancio alimentazione sala S1+S3
Accanto alla porta di ingresso della sala S1+S3 è stato installato un pulsante di sgancio che
interrompe l’alimentazione elettrica alla sala. L’intervento sulla alimentazione agisce come
nel caso precedente, ossia viene interrotta l’alimentazione elettrica alla sala. In pratica vengono disattivati gli interruttori generali sulle linee di alimentazione A e B a valle dell’UPS.
N.B.: Questo intervento non dis-alimenta le altre sale, gli UPS e i Chiller.
4.4.5 L’impianto di rilevazione incendi
L’impianto di rilevazione incendio è composto da quattro sezioni indipendenti, una per ciascun locale (S1+S3, S5, S7, S9)
In ciascun locale la rivelazione incendio si basa su due linee separate con sensori a soffitto e
sotto il pavimento. I rivelatori sono sensibili tanto alla presenza di fumo che alla temperatura
ambiente (soglia 57° C circa). L’attivazione in coincidenza di due sensori uno su una linea e
l’altro sull’altra, fa partire una serie di azioni:
Page 14
1)
Invio di segnalazione alla squadra per la gestione dell’emergenza incendio/allagamento attraverso il combinatore telefonico installato sulla linea 080
5442403.
2)
Attivazione della scarica del gas nella sala in cui è stato rilevato l’incendio.
3)
Interruzione dell’alimentazione elettrica nella sala in cui è stato rilevato l’incendio.
Eccetto che nel caso della sala S9 (quadro elettrico + UPS), l’interruzione
dell’energia elettrica è solo quella specifica della sala interessata. Nel caso della
sala S9 tutte le alimentazioni vengono interrotte: vengono aperti gli interruttori generali di arrivo dell’alimentazione al quadro, e quelli di uscita verso le varie sale (a
valle degli UPS). Di conseguenza anche l’alimentazione ai chiller viene interrotta.
Squadra per la gestione dell’emergenza incendio/allagamento
Maggi
Abitazione 080 5482384
Maggi
Diacono
Donvito
Gervasoni
Spinoso
Custode Dipartimento 080 5443175
Ingresso Campus
080 5442720
4.4.6 L’impianto spegnimento incendi
Per lo spegnimento incendio si utilizza una miscela di Argon-Azoto sotto pressione. Anche l’impianto
di spegnimento incendio è composto da quattro sezioni indipendenti, una per ciascun locale (S1+S3,
S5, S7, S9)
In figura Fig. 5 è mostrato il gruppo di bombole impiegate dal sistema di spegnimento incendio. Si tratta di un sistema di 5 bombole, due per l’ambiente S1+S3, e una per ciascuno degli
ambienti S5, S7 ed S9.
Come per il sistema di rilevazione incendi, lo spegnimento agisce in maniera separata in ciascuno degli ambienti interessati. Negli ambienti più piccoli sono presenti due ugelli per
l’uscita del gas di spegnimento: uno a soffitto e un secondo sotto il pavimento flottante. Per la
stanza S1+S3 ci sono due ugelli al soffitto ed uno sotto il pavimento flottante.
4.4.7 L’impianto di rilevazione allagamenti
Anche l’impianto di rilevazione allagamenti è composto da quattro sezioni indipendenti, una
per ciascun locale (S1+S3, S5, S7, S9) e si compone di due sensori per locale posti sotto il
pavimento flottante.
In caso di rilevazione di un allagamento in atto viene fatta partire una serie di azioni:
1)
Invio di segnalazione alla squadra per la gestione dell’emergenza incendio/allagamento attraverso il combinatore telefonico installato sulla linea 080
5442403
2)
Interruzione dell’alimentazione elettrica nella sala in cui è stato rilevato
l’allagamento. Eccetto che nel caso della sala S9 (quadro elettrico + UPS), interruzione dell’energia elettrica è solo quella specifica della sala interessata. Nel caso
della sala S9 tutte le alimentazioni vengono interrotte: vengono aperti gli interruttori generali di arrivo dell’alimentazione al quadro, e quelli di uscita verso le varie
sale (a valle degli UPS). Di conseguenza anche l’alimentazione ai chiller viene interrotta.
Page 15
Fig. 5 - Le bombole contenenti il gas inerte del sistema spegnimento incendio. Le prime due servono i locali
S1+S3, le altre tre rispettivamente i locali S5, S7 ed S9
4.4.8 Pulsante sgancio alimentazione sala S9
Accanto alla porta di ingresso della sala S9 è stato installato un pulsante di sgancio che interrompe tutte le alimentazioni elettriche: vengono aperti sia gli interruttori generali in arrivo al
quadro dalla cabina elettrica, che quelli di uscita verso le varie sale a valle degli UPS. Di conseguenza anche l’alimentazione ai chiller viene interrotta.
Page 16
4.4.9 Il monitoring della temperatura effettuato da mon2
mon2 è un sistema generale di monitoring sviluppato da Vincenzo Spinoso per la farm di Bari. Il sistema verrà descritto con maggiori dettagli nel paragrafo 5.7. Per le questioni riguardanti la sicurezza della farm è importante sottolineare che mon2 si occupa di monitorare, tra
le altre cose, la temperatura misurata direttamente sulle CPU all’interno di alcuni server selezionati. Inoltre se dovesse verificare che le temperature rilevate superano le rispettive soglie, invia una mail di notifica alle seguenti persone:
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
Ciascuno dei destinatari, utilizzando il proprio client di posta elettronica, può generare un
allarme in ricezione di un messaggio con un particolare “Oggetto: “, oppure utilizzando il
server di posta, può farsi inviare un SMS.
La Fig. 6, labellatata “Nuova”, mostra gli andamenti delle temperature delle CPU di alcuni
server nella nuova sala calcolo. Naturalmente la temperatura delle CPU può variare in funzione delle condizioni di carico della macchina, in ogni caso è significativo l’andamento di
insieme delle temperature.
Si può osservare che la temperatura misurata sulle CPU è di 10-15°C più elevata di quella
della sala che è di circa 20 °C.
Fig. 6 - Andamento della temperatura misurata sulla CPU di alcuni server, elencati nella figura, installati nei
rack della sala calcolo.
Page 17
Nella Fig. 7, labellata “CC”, sono invece mostrati gli andamenti delle temperature delle CPU
di due server localizzati nel Corridoio Caldo (CC).
Fig. 7 - Andamento della temperatura misurata sulla CPU di due server, elencati nella figura, fisicamente installati nel Corridoio Caldo.
Il monitor della temperatura di mon2, in attesa che possa essere sostituito o integrato con altri dispositivi quali per esempio quelli di video sorveglianza, consente all’operatore di capire cosa sta succedendo all’interno della farm soprattutto dopo una segnalazione di guasto dei chiller o di allarme generato
dallo stesso mon2, e fornire un valido aiuto per assumere le necessarie decisioni anche in connessione
con la possibilità di utilizzare la procedura di spegnimento di emergenza da remoto.
4.4.10 Procedura di spegnimento di emergenza da remoto
La procedura di spegnimento di emergenza da remoto è attivabile attraverso una pagina web il cui
URL è noto solo ai componenti la squadra di emergenza. Il comando non esegue, al momento, uno
shutdown ordinato della farm, ma lo spegnimento avviene in modo sincrono entro 60 secondi dal comando, su tutte le macchine della nostra classe di rete 212.189.205.X.
4.4.11 Sistema di video sorveglianza
Quale ulteriore strumento di controllo remoto della farm è stato installato un sistema di webcam che oltre a fornire una visione degli ambienti e di quanto succede al loro interno, permette di visualizzare i parametri più importanti (assorbimenti elettrici, temperature dell’ambiente
e dei fluidi, segnalazioni di allarme).
4.4.12 APC InfraStruXure Manager (host proprietario fornito da APC).
E’ un sistema di monitoring proprietario che APC ha fornito insieme alla infrastruttura; tale sistema
permette sostanzialmente di monitorare le unità di condizionamento, In-Row RC, e le strisce di alimentazione da 24 prese tipo Metered installate in ciascun rack. Il sistema è in grado di notificare eventuali anomalie via e-mail, ma questa possibilità non è stata ancora abilitata.
Page 18
Una delle difficoltà nell’uso di questo sistema di monitoring deriva dal fatto che gira solo sotto
windows. Inoltre al momento non sembra sia possibile integrare le informazioni raccolte in un sistema
di monitoring più generale. Si sta investigando la possibilità di interrogare direttamente con comandi
SNMP gli oggetti fisici monitorati.
Fig. 8 - Schermata prodotta dal sistema di monitor dei rack APC (lavora solo sotto Windows).
4.4.13 Ulteriori sistemi di monitoring da implementare
-
Il sistema UPS può essere interrogato via SNMP per ottenere informazioni sul suo
stato. Questa parte del monitoring è attualmente in fase di test.
-
Il PLC che gestisce gli allarmi può essere monitorato e può fornire informazioni più
dettagliate rispetto a quelle notificate dalla chiamata telefonica. E’ in fase di valutazione l’offerta per l’acquisto del software di monitoring.
Page 19
4.5 La potenza realmente disponibile in cabina.
Fig. 9 - Andamento degli assorbimenti misurati in cabina nel periodo 15 - 26 luglio 2009
Come mostrato nelle pagine precedenti la computer farm è stata progettata e realizzata per operare
fino ad una dissipazione di potenza di circa 200 kW di carico utile a cui vanno aggiunti ulteriori 150
kW per rendere operativi i due chiller, gli UPS, l’impianto di illuminazione, etc. per un totale quindi di
350 kW.
Naturalmente la possibilità di usare questa potenza dipende dalla sua disponibilità in cabina.
Peraltro al momento esiste un limite formale fissato durante le procedure autorizzative pari a
100 kW.
La cabina di trasformazione monta tre trasformatori da 250 kW in parallelo ed è quindi in
grado di erogare fino ad un massimo di 750 kW, comunque non meno di 500 kW se si vuole
lasciare un margine di sicurezza.
Naturalmente per determinare la potenza utilizzabile nella sala calcolo occorre sapere qual è
l’assorbimento del resto del dipartimento. Per questo motivo sono state effettuate una serie di
misure in un periodo di 10gg dal 15 al 26 luglio 2009. Si tratta di un periodo in cui c’è ancora
piena attività nel dipartimento, dal momento che le ferie non sono ancora iniziate; inoltre, essendo un periodo di gran caldo, è un periodo in cui si fa più intenso l’uso dei condizionatori
negli uffici.
Come si vede dal grafico della Fig. 9, la potenza usata dal dipartimento si compone di una
componente fissa, giorno/notte/weekend, di poco inferiore ai 100 kW, praticamente quasi tutta attribuibile al consumo della sala calcolo, a cui si aggiunge una componente legata alla presenza del personale, di fatto concentrata durante il giorno, pari a circa ulteriori 130 kW di picco per un totale di 230 kW. In effetti il picco di assorbimento si è registrato nella giornata di
giovedì 16 luglio ed ammonta a 223kW.
Possiamo quindi assumere che la potenza di picco richiesta dal dipartimento ammonta a 150
kW. Se si somma la potenza complessiva richiesta della farm di calcolo a pieno regime, valutata pari a 350 kW, si ottiene una richiesta di potenza massima di 500 kW compatibile con il
limite della potenza erogabile dalla cabina elettrica.
4.5.1 Upgrade della Cabina di trasformazione
Anche se dalle misure fatte appare che la cabina attuale è in grado di erogare tutta la potenza
richiesta dalla farm, potrebbe essere necessario procedere ad un upgrade della attuale cabina
di trasformazione in quanto uno dei tre trasformatori perde olio. Inoltre esiste anche il sospetto che i materiali impiegati, essendo nel frattempo cambiata la normativa, siano diventati non
conformi a quella attualmente vigente2.
Si potrebbe sfruttare l’occasione per aumentare anche la potenza erogabile per fare fronte a ulteriori
future espansioni sia della farm sia delle altre attività del dipartimento.
Una stima del costo dell’upgrade della cabina è stata fatta prevedendo due diverse tipologie di interventi: una prima, meno invasiva, consiste nella sostituzione dei tre trasformatori MT/bt e nella realizzazione di un nuovo quadro di cabina per la commutazione automatica da gruppo elettrogeno, dedicato
all’alimentazione delle nuove utenze.
La seconda proposta d’intervento, più radicale, prevede la totale sostituzione delle apparecchiature di
cabina. La soluzione, ovviamente più invasiva ed economicamente onerosa, potrebbe comunque essere presa in considerazione tenendo presente che le apparecchiature elettriche presenti in cabina, seppur
tenute in buone condizioni ed attualmente funzionanti, hanno comunque superato i 25 anni di vita,
oltrepassando abbondantemente il limite di obsolescenza tecnica degli impianti elettrici.
Entrambe le proposte prevedono l’installazione di un gruppo elettrogeno da 400 kVA in grado di assicurare la potenza necessaria in caso di interruzione dell’erogazione dell’energia elettrica.
Si riportano in questo documento i costi relativi alla soluzione meno onerosa rimandando l’analisi delle due soluzioni al documento predisposto dall’Ing. Magnanimo. Come si vede dalla Tabella 3 i costi
2
In realtà questa circostanza è stata recentemente esclusa dalla ditta manutentrice della cabina.
dei lavori assommerebbero a 167 keuro (IVA esclusa) di cui circa 50 keuro sono determinati
dall’acquisto del gruppo elettrogeno, mentre l’acquisto dei nuovi trasformatori incide per circa 40 keuro. Un significativo risparmio potrebbe essere realizzato utilizzando il trasformatore da 1250 kW disponibile presso il CNAF.
Tabella 3 - Quadro economico per aumento potenza in cabina e gruppo elettrogeno.
QUADRO ECONOMICO (PROPOSTA N.°1)
A
)
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
A.10
A.11
A.12
A.13
B
)
B.1
B.2
B.3
B.4
B.5
B.6
B.7
LAVORI
Rimozione e smaltimento apparecchiature esistenti
Opere Civili
f/o N°3 Fusibili Media Tensione
f/o N° 1 Trasformatori 630 kVA
f/o N° 2 Trasformatori 400 kVA
f/o coll TR1-2 / QGBT esistente [2x4x150mmq]
f/o coll. TR3 / QGBT Nuovo [CSP 1250A]
f/o N° 1 Gruppo Elettrogeno 400 kVA
f/o N° 1 Quadro Generale di Bassa Tensione
f/o N° 1 Quadri di Rifasamento Automatico 220 kVAR
Collegamento cab-dipartimento (cavidotti+cavi)
Accessori di Cabina
Oneri sicurezza
TOTALE LAVORI
Somme a disposizione dell'Amministrazione
IVA su lavori 10%
Contributo incentivazione per progetto ex art. 18
(1,50%)
Spese generali: Progettazione, direzione lavori, misure
e contabilità, coordinamento per la sicurezza
Collaudi
Contributo CNPAIA 2% INPS 4%
IVA sui compensi 20%
Imprevisti ed arrotondamenti
Totale somme a disposizione
Importo totale progetto
€ 6.000,00
€ 10.000,00
€
600,00
€ 15.400,00
€ 26.600,00
€ 2.400,00
€ 2.500,00
€ 48.700,00
€ 14.000,00
€ 4.200,00
€ 25.800,00
€ 4.000,00
€ 6.408,00
€ 166.608,00
€ 16.660,80
€
2.499,12
€ 43.208,00
€ 3.000,00
€ 2.772,48
€ 9.796,10
€ 5.455,50
€ 83.392,00
€ 250.000,00
Page 22
4.6 Completamento e manutenzione
4.6.1 Stima dei costi per il completamento dell’infrastruttura.
In Tabella 4 sono mostrati i costi indicativi delle apparecchiature da acquistare e delle opere
da realizzare per completare l’infrastruttura: i 4 ulteriori rack e i 2 InRow RC, il terzo UPS, il
raddoppio dei cavi di alimentazione dalla cabina al quadro elettrico ed il gruppo elettrogeno
da 400 kVA.
Tabella 4 - Costi apparecchiature da acquistare a completamento.
Priorità
Apparecchiature
S1
S9
Costo
4 rack + 2 InRow RC
4
15.000
Terzo UPS
4
17.000
Raddoppio cavi elettrici di alimentazione
Cabina elettrica - quadro elettrico
Gruppo elettrogeno da 400 k VA
4
12.000
4
60.000
Totale Apparecchiatura
104.000
4.6.2 Stima dei costi di manutenzione
In Tabella 5 sono mostrati i costi indicativi di manutenzioni delle apparecchiature impiegate
nell’infrastruttura di calcolo.
Tabella 5 - Costi annui di manutenzione.
Apparecchiatura
Chiller Clivet
Impianto antincendio escluso
bombole
Rack APC
UPS
Totale
Costo Annuo
1200.00
2400.00
12000.00
Dall’offerta fatta all’INFN
A chiamata
15600.00
Page 23
5 La Farm
5.1 Le risorse computazionali.
La Farm di Bari, inizialmente partita all’interno del progetto INFN-GRID, si è sviluppata dapprima
come protoT2 di CMS ed ALICE e più recentemente ha inglobato le risorse computazionali di altri
esperimenti e gruppi attivi nella sezione di Bari, in particolare del gruppo teorico che contribuisce con
272 CPU core e degli esperimenti GLAST (80 core) e Pamela (32 Core).
La
Tabella 6 mostra i dettagli delle risorse disponibili sulla farm e i fondi attraverso cui sono state acquisite. La tabella e i grafici da essa derivati includono già le risorse in via di acquisizione con i fondi
assegnati a CMS con lo sblocco sj 2009.
Tabella 6 - Il dettaglio delle risorse della farm e dei fondi utilizzati per l'acquisto.
La versione aggiornata di questa tabella è disponibile al seguente indirizzo:
http://spreadsheets.google.com/ccc?key=0AlXaBZtzEnxkcDF1UFdTY01lcU5CeU5FLUt6RVJqYWc&hl=en
I dati della tabella sono sintetizzati nei due grafici mostrati rispettivamente in Fig. 10 e Fig. 11, il
primo del quale si riferisce alle CPU (in HEPSpec), mentre il secondo allo storage (ALTRI= DOT1,
GLAST, Pamela).
Fig. 10 – Le risorse computazionali in funzione dei fondi utilizzati per l'acquisto.
Fig. 11 - Le risorse di storage in funzione dei fondi utilizzati per l'acquisto.
Page 25
5.2 La farm di Bari nel panorama nazionale
Fig. 12 – La pagina di monitoring di GridMap
La Fig. 12 mostra lo stato della parte italiana dell’infrastruttura EGEE come prodotta da Gridmap
(http://gridmap.cern.ch/gm/#topo=regions&layout=tc&vo=OPS&serv=Site&drilldown=Italy&sitenam
es). Nella figura l’area del rettangolo corrispondente al sito è proporzionale al numero di CPU istallate. La farm di Bari con 642 CPU è la quinta per numero di CPU dell’infrastruttura di grid italiana dopo
INFN-T1, INFN-PI, INFN-LNL-2 e INFN-TO (le risorse di INFN-CNAF-LCB sono le stesse di quelle di INFN-T1).
5.3 Lo storage
5.3.1 Le esigenze
L’attività svolta negli ultimi mesi ha messo in evidenza la necessità di intervenire su diversi aspetti al
fine di migliorare le prestazioni della farm e la sua usabilità da parte degli utenti. Di seguito verranno
elencati questi punti:
-
-
Accessibilità e stabilità delle home degli utenti.
Gli utenti locali hanno necessità di avere un file-system condiviso fra tutti i nodi di calcolo, in
modo da poter lavorare in modo trasparente su qualsiasi WN della farm sia in batch che in interattivo. Questo file-system è di cruciale importanza e criticità: deve essere sempre on-line e responsivo altrimenti l’usabilità della farm ne viene intaccata. Il file system deve anche essere in grado di
gestire un gran numero di job concorrenti senza che ci siano importanti perdite di efficienza e senza che si verifichino blocchi del sistema.
Efficienza di lettura dei dati di esperimento da parte dei job di analisi:
L’accesso casuale ai dati di esperimento da parte di job di analisi sottomessi da utenti delle diverse
VO ospitate sulla farm è una operazione particolarmente critica che può trasformarsi in un vero
collo di bottiglia. Sono state misurate infatti efficienze nell’uso delle CPU da parte dei job di analisi dell’ordine del 20%, valore estremamente basso che comporta un enorme spreco di risorse.
-
Riduzione del peso del management dell’infrastruttura e del man power richiesto.
La semplificazione dell’infrastruttura di storage consente anche di ridurre il peso della gestione
dell’infrastruttura e il man power dedicato. Infatti, poiché la farm è usata da molti gruppi con esigenze diverse può diventare un problema gestire diversi servizi di storage per i diversi gruppi.
Questo è vero anche per quanto riguarda gli acquisti di hw: spesso si riesce a coordinare gli investimenti dei vari gruppi ottenendo una ottimizzazione della spesa. Inoltre alcuni dei gruppi che usano la farm hanno la precisa necessità di accedere allo storage con chiamate posix standard non
potendo usare librerie di accesso diverse (come invece accade per alcuni esperimenti LHC).
5.3.2 La soluzione precedente
-
-
-
La home degli utenti
La soluzione inizialmente adottata, dettagliata in Fig. 13, era basata su GPFS che offriva garanzie
di scalabilità e la funzionalità di mirroring fra dischi localizzati su macchine diverse. Questa caratteristica era ritenuta essenziale per garantire la continuità del servizio anche nel caso in cui
qualcuno dei server diventasse indisponibile, per esempio a causa di un guasto.
In realtà si è visto che se uno dei server diventa indisponibile, tutto il file system GPFS si blocca
rendendo il sistema molto instabile con crash frequenti.
L’area Dati degli esperimenti
L'area dei dati di esperimento veniva fornita attraverso il sistema di storage dCache. L'uso di questo sistema permetteva, infatti, di accedere ai dati distribuiti sui vari server come se fossero su un
unico file-system. Erano possibili anche configurazioni che garantivano la quota fra diverse VO, il
che ovviamente era necessario dato che l’infrastruttura di storage è condivisa fra diversi esperimenti.
dCache è risultato molto stabile, inoltre offriva la possibilità di poter usare sistemi operativi diversi, come per esempio SolarisOS con ZFS, sui server di storage. Questo spesso ha dato la possibilità di utilizzare hardware di minore costo per realizzare il sistema di storage.
Per contro dCache riusciva a fornire accesso ai dati attraverso librerie appositamente sviluppate in
grado di soddisfare le esigenze di accesso allo storage da parte degli esperimenti di LHC ma che
risultavano poco adatte all’uso posix-like tipico degli altri gruppi.
Inoltre dCache si è dimostrato poco efficiente nel soddisfare le esigenze di job di analisi concorrenti. Anche con pochi job concorrenti i tempi di lettura dei dati risultavano così elevati da determinare un uso poco efficiente della CPU, anche dell’ordine del 20-30%, da parte dei job di analisi,
in quanto questi perdevano molto del loro tempo in “I/O wait”.
Il software di esperimento
Il software di esperimento era installato su un’area condivisa via NFS. Lo storage risiedeva in un
server centrale che esportava le librerie a tutti i nodi della farm. In questo modo era possibile installare il software una sola volta e tutti i WN potevano usarlo immediatamente dopo
l’installazione. Non sono stati riscontrati problemi di performance dovuti a questa configurazione.
Per il software di esperimento è stata scelta una soluzione diversa da quella usata per le home degli utenti perchè il pattern di utilizzo è completamente diverso: infatti mentre in questo caso gli
accessi sono in prevalenza letture da tutti i nodi e le scritture avvengono da un solo nodo (durante
l’installazione del software), nel caso delle home il sistema deve poter sopportare scritture multiple e letture contemporanee da tutti i nodi del cluster.
Page 27
NFS WN
Experimental
Software
GPFS
WN
WN
WN
WN
WN
WN
WN
WN
WN
WN
WN
Cluster
Frontend
dCap
gridftp
dCap
gridftp
dCache
Fig. 13 - Schema del precedente sistema di storage
5.3.3 Risultati dei test di storage
Al fine di ricercare la migliore soluzione per l’infrastruttura di storage della farm in grado di
dare una risposta alle esigenze elencate nel paragrafo precedente, è stata eseguita una serie di
test nel periodo tra dicembre 2008 e maggio 2009. Sulla base dei risultati ricavati dai test, che
qui di seguito saranno illustrati brevemente, si è deciso di cambiare completamente
l’infrastruttura di storage. Si è deciso infatti di abbandonare la soluzione utilizzata fino
all’estate 2009 e basata su NFS, GPFS e d_Cache, come illustrata nel paragrafo 5.3.2, per
passare ad utilizzare al loro posto Lustre. Con il passaggio a Lustre si è notato un netto miglioramento delle performance nell’accesso ai dati da parte dei job di analisi di CMS ed è stata anche messa in evidenza una maggiore scalabilità del file system in relazione al numero di
client contemporanei.
Page 28
Fig. 14 - Numero di bytes scritti al secondo in funzione del numero di client concorrenti e della configurazione
hardware/software adottata.
Come possiamo vedere nel plot di Fig. 14 le performance di scrittura a parità di configurazione hw
(per esempio 8Raid5HW) risentono molto meno del numero di processi di scrittura paralleli nel caso
dell’uso del file system Lustre. Mentre nel plot di Fig. 15 possiamo vedere le performance per operazioni di lettura random a parità di configurazione hw (per esempio 8Raid5HW) nel caso dell’uso del
file system Lustre continuano a crescere all’aumentare del numero di processi concorrenti.
Page 29
Fig. 15 - Numero di bytes al secondo letti in maniera random in funzione del numero di client concorrenti e
della configurazione hardware/software adottata.
Nel grafico di Fig. 16 è rappresentato il tempo di I/O speso da un job di analisi all’aumentare del numero di job che insistono sullo stesso server. Come si nota chiaramente nel caso di Lustre questo tempo aumenta molto poco all’aumentare del numero di job che insistono sullo stesso server. Nel caso di
dCache invece questo tempo cresce in modo molto più ripido all’aumentare del numero di jobs.
Nel grafico di Fig. 17 è mostrato il tempo necessario per effettuare l’untar di un file compresso contenente il kernel in funzione del numero di processi paralleli che effettuano la stessa operazione.
E’ facilmente visibile come per un piccolo numero di processi (1-2 processi) un file-system di tipo
NFS è molto più performante; mentre non appena il numero di processi diventa nell’ordine della decina le cose si invertono e diventa molto più vantaggioso usare un file system di tipo Lustre capace di
distribuire gli accessi contemporanei su più hw in modo da mantenere il tempo di esecuzione entro
limiti accettabili.
Page 30
Fig. 16 - Tempo speso per I/O wait da un job di analisi in funzione del numero dei job concorrenti per Lustre e
dCache.
Fig. 17 - Durata del processo di un-tar di un kernel in funzione dei processi concorrenti per Lustre e dCache.
Page 31
5.3.4 La configurazione dello storage nella farm di Bari.
Sulla base dei risultati dei test e tenendo conto delle esigenze di uso della farm che sono state evidenziate nei paragrafi precedenti, si è visto che molti problemi potevano essere risolti utilizzando Lustre
come unico file system distribuito.
Fig. 18 - La configurazione attuale del sistema di storage della farm di Bari.
L’idea principale che si è seguita nell’organizzazione del file-system è stata quella di unificare il servizio di accesso ai dati di esperimento con quello delle home degli utenti usata per la sottomissione di
job locali. In particolare:
- E’ stato verificato con i test effettuati, che questo non rappresenta un problema dal punto di vista
delle performance.
- Si è ritenuto invece opportuno separare le partizioni che servono i dati della home da quelle “general pourpose” che contengono i dati di esperimento.
- Il file-system, per il momento, è stato configurato usando un unico device di metadati. In futuro
con la migrazione a Lustre 2.0 sarà possibile aggiungere un secondo device per fornire in maniera
indipendente tale servizio.
- Ogni disk server è configurato con 2 o 4 interfacce di rete in bonding (a seconda della dimensione
dello storage fornito dallo stesso server), in modo che la rete non rappresenti il collo di bottiglia
per l’accesso ai dati.
- Per tener conto delle esigenze di ALICE che prevede che l’accesso alle risorse di storage debba
avvenire attraverso un server xrootd, si è provveduto all’installazione di due macchine per esportare tale servizio utilizzando una quota dello storage distribuito messo a disposizione da tutti i server
disk al momento disponibili.
Si è riusciti quindi a soddisfare le molteplici esigenze attraverso l’utilizzo di un singolo prodotto. Questo ha ovviamente l’indubbio vantaggio di ridurre il man power richiesto per gestire l’intera infrastruttura, in quanto il servizio di storage sottostante è comune a tutti gli esperimenti e il lavoro necessario
per fornire il servizio di storage per ALICE si riduce al mantenimento di un semplice servizio xrootd
(e non anche alla gestione dell’HW sottostante).
Il cluster di storage xrootd per ALICE è stato implementato installando su una workstation il software
server di xrootd e su una storage-station il client xrootd che realizza il data access; quest'ultimo a sua
volta, con i suoi elementi di storage, è elemento del file system lustre.
Page 32
5.3.5 La migrazione al nuovo sistema e il confronto con il vecchio
I dati di esperimento sono stati trasferiti da dCache a Lustre senza spegnere la farm. Ci sono voluti
diversi giorni in quanto è stata una operazione molto complessa che ha richiesto una serie di configurazioni “ad-hoc” nei vari servizi della farm.
Non appena la migrazione è stata portata a termine è stato evidente da subito un miglioramento generale sia nella stabilità della farm sia nella efficienza dell’uso della CPU da parte dei job in esecuzione.
A titolo di esempio di seguito sono riportati alcuni grafici che mostrano l’efficienza di uso della CPU
per job di analisi di CMS (provenienti da grid) che leggevano gli stessi dataset sia con l’installazione
precedente basata su dCache sia con l’utilizzo del successivo setup basato su Lustre.
Fig. 19 - Efficienza di CPU per job di analisi di un utente Susy, rappresentati per siti diversi che ospitavano lo
stesso dataset. (a Bari era utilizzato dCache).
Fig. 20 - Efficienza di CPU nell’esecuzione dei job di analisi di test, denominati JobRobot, quando i dati erano
ospitati su dCache.
Page 33
Fig. 21 - Efficienza dell’uso della CPU per job di analisi di un utente Susy, dopo la migrazione dei dati su Lustre (il grafico mostra le efficienze per tutti i Tier2 di CMS che contenevano il dataset in oggetto).
Fig. 22 - Efficienza dell’uso della CPU per job del JobRobot, dopo la migrazione dei dati su Lustre (il grafico
mostra le efficienze per tutti i Tier2 di CMS).
Nei grafici mostrati nelle Fig. 19, Fig. 20, Fig. 21, Fig. 22 e Fig. 23 è evidente come l’efficienza di
uso della CPU sia passata da valori compresi fra il 25% e 65% con dCache a valori vicini o superiori
al 90% con Lustre. E’ anche possibile notare che non solo la percentuale di efficienza della CPU è
migliorata di molto rispetto all’uso di dCache, ma anche che il sito di Bari è ora uno dei più efficienti
fra tutti gli altri Tier2 di CMS.
Page 34
Fig. 23 - Efficienza di uso della CPU per job di analisi su dati di QCD per job molto I/O intensive (il grafico
mostra le efficienze per tutti i Tier2 di CMS).
Page 35
5.4 L’infrastruttura di rete
La Fig. 24 mostra lo schema della rete realizzata.
Fig. 24 - Schema dell'infrastruttura di rete
Come appare dalla figura la rete sfrutta il backbone della HP ProCurve Switch 5412zl Intelligent Edge, le cui caratteristiche principali sono riportate nella Tabella 7.
Tabella 7 – Caratteristiche HP ProCurve Switch 5412zl Intelligent Edge (J8698A).
Ports
–
–
–
12 open module slots
1 RS-232C DB-9 console port
Supports a maximum of 288 auto-sensing
10/100/1000 ports or 48 10-GbE ports or 288
mini-GBICs, or a combination
Performance
1000 Mb Latency
< 3.7 µs (FIFO 64-byte packets)
10 Gbps Latency
< 2.1 µs (FIFO 64-byte packets)
Throughput
up to 480.3 million pps
Routing/Switching capacity
645.6 Gbps
Switch fabric speed
691.2 Gbps
Routing table size
10,000 entries
Page 36
Fig. 25 – Il backbone della rete (HP ProCurve Switch 5412zl Intelligent Edge) con le connessioni attualmente
attive.
E’ importante osservare subito che i moduli di ingresso con 4 porte a 10 Gbit/s non comunicano con il
back-plane alla piena velocità: le porte sono accoppiate a due a due e ciascun gruppo di due porte comunica con il back-plane a 14 Gbit/s anziché 20 Gbit/s.
Tenendo conto di questa limitazione, per sfruttare pienamente gli uplink in entrambi i versi, si sta
assemblando la rete secondo lo schema di seguito illustrato:
– Ogni rack sarà dotato di uno o due switch HP Switch 2900-24G. Questo switch ha 24 porte a 1
Gbit/s di ingresso e due uplink a 10 Gbit/s. All’interno dello stesso rack vengono montati sia
disk server che nodi di calcolo. I disk server sono collegati allo switch di rack con 4 cavi da 1
Gbit/s (si è verificato che questa larghezza di banda non crea colli di bottiglia sui disk server
attuali) e producono un traffico di rete verso lo switch centrale, mentre i WN occupano le restanti 16 porte e tipicamente producono un traffico dallo switch centrale verso i WN stessi. In
questo modo si crea un traffico di 16 Gbit/s verso i WN e di 8 Gbit/s dallo storage verso il resto della farm. Tenendo conto che la connessione tra gli switch di rack sarà fatta utilizzando
entrambi gli uplink a 10 Gbps, risulta che il traffico verso i WN è solo di poco superiore al limite esistente tra le due porte a 10Gbit/s ed il back-plane che come abbiamo detto è di soli 14
Gbit/s. In conclusione in questo modo ciascun WN vede quasi l’intera banda di 1 Gbit/s in
uscita dal centro stella.
Se invece tutte le 24 porte dello switch periferico saranno connesse a dei WN, i due uplink a
10 Gbits saranno collegati a due porte non accoppiate a 10 Gbit/s in maniera da garantire la
Page 37
piena comunicazione con il back-plane e quindi assicurare una banda di 1 Gbit/S in input/output a ciascun WN. In questo modo solo due delle 4 porte a 10Gbit/s di ciascun modulo
saranno utilizzate.
In futuro eventuali unità disco con interfaccia 10 Gbit/s potranno essere direttamente connesse allo
switch centrale con una connessione diretta a 10 Gbit/s, sempre avendo cura di utilizzare solo 2 della 4
porte disponibili sui moduli di Input/output del centro stella.
Nella fase iniziale di avvio della nuova infrastruttura e fintanto che non si riusciranno ad installare gli
switch HP 2900-24G già citati, si continueranno ad usare gli switch a 48/24 porte a 1 Gbit/s presenti
nella vecchia infrastruttura: in questo caso l’uplink sarà fatto sfruttando le restanti 8/4 porte da un
Gbit/s in maniera da ridurre al minimo le limitazioni introdotte dal ridotta banda disponibile
sull’uplink.
Dai primi e preliminari test effettuati il sistema dimostra di comportarsi come atteso dalle specifiche
tecniche: infatti come mostra il grafico in Fig. 26 è possibile raggiungere 1GByte/s usando un singolo
uplink a 10 Gbit/s.
Fig. 26 - Test di performance dell'infrastruttura di rete.
Con questa configurazione è possibile quindi servire fino a:
 384 WNs quasi a full Gbit/s (>3000 cores)
 48 Disk Servers up to 4Gbits/s per un totale teorico di 24Gbyte/s di aggregato dai disk server
5.4.1 Indirizzi IP utilizzati e riservati
La rete della farm di grid è in DMZ rispetto al resto della sezione. Il traffico non impatta sul router
interno della sezione per evitare eventuali problemi di performance.
L’attuale connessione con il GARR può arrivare fino a 1Gbit/s. I parametri ufficiali sono comunque:
 Max Speed:
200.0 Mbits/s (IP)
 BGA:
50.0 Mbits/s (IP)
La rete della farm è tutta su una rete di classe C con IP: 212.189.205.*.
Page 38
5.5 Il software
5.5.1 I sistemi operativi e i relativi kernel
Dal 3 novembre il sistema operativo utilizzato sulla farm è SLC5. Il sistema operativo viene montato
su un kernel in grado di gestire tutto l’hardware esistente sui nodi e tutti i file-system necessari all’uso
in produzione (Lustre, NFS, AFS). In questo momento stiamo usando il kernel vanilla 2.6.22.19 opportunamente patchato per soddisfare i requisiti menzionati. Questa infatti è al momento attuale la versione più aggiornata che supporti tutti i file system. La linea guida che contiamo di seguire è quella di
usare kernel il più aggiornati possibile, perché abbiamo notato un generale incremento della stabilità
operativa sia dal lato server che sulle macchine client (WN e UI).
5.5.2 Le procedure di installazione
L’installazione di SLC è la procedura più frequente di installazione di un sistema operativo, poiché è
legata spesso all’introduzione di nuovi WN nella farm; tali WN sono spesso forniti in gruppi di più
macchine uguali. Al fine di velocizzare le operazioni di installazione con riferimento a tale caso, utilizziamo un’apposita macchina per l’installazione via PXE: essa permette di effettuare il boot e
l’installazione automatica via rete attraverso la combinazione di vari server (DHCP, TFTPd, Apache)
e la compilazione di un file di Kickstart.
Le installazioni di Debian e di Solaris/Opensolaris vengono effettuate manualmente perché di solito
sono effettuate su macchine molto diverse tra loro, e con configurazioni più complesse (bonding sulle
schede di rete ethernet, configurazioni dei driver o delle utility di controller disco, configurazione del
RAID).
5.6 Il sistema di code locali
Il sistema di code locali è basato su software Open Source, in particolare si compone di due distinti
sistemi: Torque che gestisce l’interazione fra job e WN e fornisce la gestione delle code vere e proprie, mentre Maui gestisce le priorità di esecuzione dei job. Formalmente Torque svolge le funzioni di
batch manager mentre Maui dello scheduler.
Al momento la farm conta circa 650 core di calcolo utilizzabili.
I test di scalabilità fatti finora e l’uso in produzione non hanno mai mostrato problemi per quanto riguarda il comportamento del sistema di code all’aumentare delle risorse gestite. Unico problema riscontrato è quello relativo alla non corretta gestione dei job in coda quando questi superano il numero
di 4000. Infatti, in questo caso Maui considera come job eleggibili per essere eseguiti solo i primi
4000 trascurando completamente gli altri.
Grazie all’uso di questi due software è possibile implementare politiche di gestione dei job anche molto complesse. In particolare sulla farm è in produzione una configurazione che fornisce le seguenti
funzionalità:
1. Priorità in base alla percentuale di risorse acquistate (quello che comunemente si chiama
fair-share).
2. Priorità su particolari utenti all’interno di un gruppo.
3. Priorità diverse in base alla durata prevista dei job (job più brevi hanno maggiore priorità).
4. Priorità sulla base del tempo passato in coda da ogni job.
5. Limiti sul numero massimo di job in esecuzione per un dato gruppo.
6. Limiti sul numero massimo di job in esecuzione per singolo utente.
7. Risorse riservate, in modo permanente, per particolari usi.
8. Risorse riservate in modo occasionale per determinati utenti o use-case concordati in precedenza.
9. Possibilità di eseguire “job interattivi”.
10. Esecuzione praticamente immediata dei job interattivi degli utenti locali
Page 39
Questi ultimi sono di particolare utilità quando è necessario compilare e debuggare del codice con una
elevata frequenza.
In questo modo è possibile usare le risorse della farm di batch per effettuare attività che normalmente
richiederebbero delle macchine dedicate da usare in interattivo. Questo ovviamente con lo scopo di
minimizzare gli sprechi di risorse: infatti, in questo modo le risorse vengono sempre usate o da job in
batch o da job interattivi.
È inoltre possibile con lo stesso sistema di batch di eseguire job di tipo parallelo (che utilizzano cioè
più processori in contemporanea) che fanno uso di librerie MPICH (1 e 2).
Al momento, tutte le funzionalità di sottomissione sono implementate su un’unica macchina che fa da
batch server e da CE di grid, a cui si aggiungono le macchine di front-end del cluster che vengono usate solo per la sottomissione in locale di jobs.
In un prossimo futuro si prevede di suddividere i servizi di gestione dei job su più di un server in maniera da permettere una ulteriore scalabilità nella gestione di un gran numero di WN e di job contemporanei.
In questo sistema di batch sono implementate diverse code per la sottomissione dei job. In particolare
si è deciso il tipo di code da creare in base agli use-case richiesti dagli utenti ed alle necessità di gestione del cluster.
In particolare ci sono le tre code generiche: “short, long, infinite” che vengono esportate via grid e
sono abilitate a tutte le VO. Esse sono caratterizzate da un diverso tempo di esecuzione concesso ai
job che è crescente passando da short a infinite (il job sottomesso ad una coda viene ucciso quando il
tempo totale di esecuzione supera quello imposto dall’amministratore su quella stessa coda).
In seguito ad specifiche richieste sono state create le code “alice” e “cms” usate solo dalle rispettive
VO per le sottomissioni via grid.
Esiste anche una coda chiamata “cert” che viene usata soltanto a fini di test dalle VO che si occupano
di controllare e certificare che il sito stia funzionando correttamente.
Sono poi state create delle code che servono per accettare le sottomissioni locali da parte degli utenti:
“local” è la coda generica che viene usata per tutte le sottomissioni di job che non hanno particolari
requirements;
“verylong” è una coda creata ad-hoc per job molto lunghi (fino a 1000 ore di running consecutivo);
la coda “teorici” è stata creata per distinguere i job di fisica teorica nei casi in cui questi abbiano bisogno di particolari politiche di scheduling.
Ogni coda ha anche una sua priorità di esecuzione: job sottomessi a code che hanno una durata minore
acquistano una priorità maggiore.
In generale i job locali hanno una priorità maggiore rispetto a quelli provenienti da grid.
Tabella 8 - Le code batch implementate sulla farm di Bari.
Nome Coda Batch
short
long
infinite
cms
Durata massima dei job
48 ore
60 ore
90 ore
48 ore
alice
local
verylong
teorici
cert
48 ore
100 ore
1000 ore
100 ore
45 minuti
CPU assegnate
Tipo di risorse
Tutte
Tutte
Tutte
Tutte
Tutte
Tutte
Tutte
Tutte
Tutte
diverse
diverse
diverse
diverse
diverse
diverse
diverse
diverse
diverse
La selezione di risorse particolari per il proprio job può essere fatta attraverso il comando di sottomissione batch, utilizzabile anche da grid. Al momento sono state definite le seguenti due classi di macchine:
 Macchine a 64 bit (che include tutte le macchine successive ai Pentium IV)
Page 40

Macchine a 64 bit con processore Opteron.
Chiaramente la prima classe include la seconda. Il comando da utilizzare per sottomettere il proprio
job su macchine a 64 bit qualsiasi è:
“qsub -l nodes=N:sqbit -q queue_name”
mentre quello per sottomettere i propri job su macchine a 64 bit Opteron è
“qsub -l nodes=N:teorici -q queue_name”
dove N è il numero di CPU su cui si vuol fare girare il job, queue_name è il nome della coda che si
intende usare, per es “teorici”.
Page 41
5.7 Il sistema di monitoring
Per il monitoring delle risorse della farm, utilizziamo principalmente
 Ganglia (su macchina reale SLC4)
L’installazione di Ganglia e dei relativi sensori è estremamente semplice; ogni nuova macchina installata via Kickstart è automaticamente inserita nel monitoring di Ganglia, e quindi è
possibile monitorarne da subito in particolare la raggiungibilità via rete, il carico di CPU, la
velocità di trasmissione dati sulla rete in uscita e in entrata, l’utilizzo della memoria centrale.
È possibile osservare l’interfaccia di Ganglia al seguente indirizzo:
http://pccms29.ba.infn.it/web

Mon2 (su macchina virtuale Debian, ospitata su macchina reale VMWARE/SLC4).
L’esigenza di poter monitorare molti altri aspetti della farm (stato dei volumi RAID, temperatura, job monitoring) ci ha spinti nella creazione di un sistema di monitoring complementare,
che abbiamo chiamato Mon2, accessibile attraverso il seguente URL:
http://cmsprod.ba.infn.it/mon2
Fig. 27 - Utilizzo della farm nella settimana dal 12/10/2009 al 19/10/2009
Tale sistema di monitoring si basa su sensori scritti in Bash/Perl, che inviano via SSH attraverso semplici file di testo la descrizione dello stato delle risorse monitorate; queste informazioni vengono aggregate e inserite in un database al fine sia di produrre grafici di sintesi (andamento della temperatura), sia di garantire la disponibilità di uno storico per determinati tipi
di servizi (job monitoring).
Page 42
Fig. 28 - L'utilizzo della farm nella settima dal 12/10/2009 al 19/10/2009 da parte dei alcuni utilizzatori della
farm: theophys, cms, glast. La linea nera indica le risorse acquistate con i fondi della VO, la linea blu indica il
numero massimo di job running per quella VO.
Page 43
Nella Fig. 29 è mostrata la temperatura monitorata da Mon2 all’interno di alcuni processori.
Opportunamente istruito, Mon2 può notificare via mail i cambiamenti di stato dei servizi o
delle risorse; tale notifica ci ha permesso più volte di intervenire tempestivamente in corrispondenza di rotture dei dischi o di malfunzionamento dell’impianto di condizionamento.
Fig. 29 - Andamento delle temperature misurate all'interno dei server indicati nella caption della figura.
-
Nagios (su macchina reale SLC4).
Nagios è un complesso sistema di monitoring, sviluppato con l’intento di fornire uno strumento di monitoring di tipo “fabric”; tuttavia grazie all’espandibilità attraverso plug-in, è ufficialmente supportato da EGEE, che lo ha completato e reso adatto anche per il monitoring dei
servizi di GRID. Nagios è stato di recente installato sulla farm ed è stata avviata la procedura
di customizzazione.
Page 44
5.8 Il sistema di Accounting
5.8.1 Il sistema di accounting locale
Il sistema di accounting locale è basato sui dati forniti dal sistema di batch PBS. Uno script,
che viene fatto girare regolarmente, provvede ad estrarre le informazioni relative ad ogni job
eseguito sulla farm e ad introdurle in un database.
Interrogando il database (http://vgridba2.ba.infn.it/~yogi/cgi-bin/usf.py) è possibile ottenere informazioni come quelle mostrate nella Fig. 30 in cui è mostrata la ripartizione tra le VO dell’uso
delle risorse della farm di Bari (WALL TIME).
Fig. 30 - Uso della risorse ripartito tra le VO negli ultimi 30 giorni (18/10/09).
5.8.2 Il sistema di accounting centrale (HLRmon)
L’uso delle risorse della farm di Bari è misurato anche dal sistema D-GAS, il sistema di accounting di grid sviluppato dall’INFN. Recentemente è stato realizzato un portale raggiungibile al link: https://dgas.cnaf.infn.it/hlrmon/welcome/welcome-lhc.html attraverso cui è possibile controllare l’uso delle risorse dei T2 dell’INFN.
Page 45
Fig. 31 - Uso delle risorse della farm di Bari in funzione delle VO negli ultimi 30 giorni (18/10/09).
Nella Fig. 31 è mostrato l’uso delle risorse della farm di Bari da parte delle VO LHC e dalle
altre VO (no-lhc: nel caso della farm di Bari “no-lhc” corrisponde per la gran parte all’uso
della farm da parte della VO theophys). La linea rossa rappresenta le risorse assegnate alla
sezione di Bari alle VO lhc (alice e cms). Dalla figura appare che le VO lhc consumano abbastanza di più delle risorse di loro proprietà: questo è possibile in quanto si possono utilizzare
anche le risorse di INFN-GRID e DOT1.
Nella figura seguente, Fig. 32, è mostrato l’andamento dell’uso della farm di Bari nell’ultimo
anno. Anche qui l’uso locale corrisponde a quello della VO theophys. È evidente l’aumento
dell’attività delle VO ALICE e CMS con il tempo: negli ultimi mesi le due VO hanno sistematicamente usato più delle risorse loro assegnate.
Fig. 32 - Uso della farm di bari nell'ultimo anno.
Page 46
5.9 I Servizi della farm: scalabilità e affidabilità
Di seguito viene riportato uno schema funzionale della farm di Bari, con l’indicazione dei vari servizi,
evidenziando per quali di questi è prevista la possibilità di essere ridondati o in generale presenti in
diverse istanze.
Verranno anche mostrate le scelte tecniche individuate per garantire l’affidabilità e la scalabilità dei
vari servizi.
Fig. 33 - la configurazione dei principali servizi della farm
5.9.1 Il batch manager
Uno dei servizi più critici per la sottomissione dei jobs è il batch server. Questo nodo si fa carico di
schedulare l’esecuzione dei jobs e di interagire con i WN per controllarne lo stato.
Questo nodo non è particolarmente demanding in termini di performance, ma richiede macchine che
siano intrinsecamente affidabili e possibilmente in una configurazione ad Alta Affidabilità.
Grazie all’uso di Torque 2.3.x e di un file-system condiviso contiamo di usare, a regime, due nodi che
possano fornire questo servizio con il paradigma: attivo-passivo. Cioè i client usano sempre la macchina definita come “primario” e in caso in cui questa non sia responsiva provano a interagire con il
server di back-up.
5.9.2 Il BDII
Sulle stesse macchine si conta di installare e configurare il servizio di BDII, fondamentale per pubblicare le risorse del sito alla grid, in modo che anche in questo caso il down di una macchina non possa
impedire la continuità del servizio.
Page 47
5.9.3 Il Computing Element
Altro servizio critico è il Computing Element: una failure su questo componente rende inutilizzabile il
cluster per gli utenti che vogliono accedervi da grid. Per evitare tale situazione si pensa di dotare la
farm di più di un computing element. In particolare in un primo momento si conta di configurare la
farm con 2 lcg-CE in bilanciamento di carico più un CE di tipo CREAM. Quando quest’ultimo sarà il
sistema di accesso standard, si provvederà alla sostituzione dei due CE LCG in favore di un altro CE
CREAM.
5.9.4 L’MDS di Lustre
Altro servizio fondamentale per l’utilizzabilità della farm è lo storage. Nell’infrastruttura di Lustre
l’elemento critico è il server dell’MDS. Se questo viene meno tutto il sistema si blocca: per evitare
questo tipo di problema è necessario fornire l’alta disponibilità del servizio.
Un modo per fornire tale servizio è stato già sperimentato con successo, utilizzando una caratteristica
tipica di Lustre più l’uso del sistema DRBD per replicare la partizione in cui sono contenuti i metadati.
Nei test effettuati è stato osservato che in caso di failure della macchina principale alcune operazioni
vengono messe in pausa al massimo per 10 secondi, mentre tutte le operazioni di lettura e scrittura già
cominciate prima della failure continuano senza interruzioni.
Un sistema di questo genere verrà messo in produzione al prossimo down generale della farm.
5.9.5 User interface e front end per utilizzo interattivo
Un altro servizio particolarmente critico per garantire una elevata qualità del servizio agli utenti è la
macchina di frontend (o User Interface) su cui l’utente si alloca e da cui lancia la sua attività sia in interattivo, che in batch o attraverso grid. Per rendere questo servizio più resistente alle failure si è passati da sistema costituito da una singola macchina ad un cluster di 3 machine accessibile attraverso lo
stesso indirizzo: frontend.ba.infn.it. Quando si collega, l’utente non sa su quale machina del cluster è
allocato e in caso di down di una delle macchine, l’attività potrà proseguire su una delle altre macchine del cluster.
5.9.6 Accesso allo spazio disco: StoRM e Xrootd
Allo spazio disco gestito da Lustre si può anche accedere dall’esterno della farm attraverso il servizio
SRM che usa gridftp o xrootd come protocollo di trasporto. Tale servizio è fornito usando il software
chiamato StoRM. In questo caso il servizio può essere diviso in diversi sottoservizi: un database
mysql, un front-end che accetta le connessioni da parte dell’utente, e un back-end che effettua le operazioni sul file-system.
Al momento tutti questi servizi sono sulla stessa macchina ma per disegno ognuno di questi può essere
installato su una macchina separata, e nel caso di front-end si possono avere più front-end che lavorano in cluster.
Nell’uso quotidiano non stiamo notando problemi di carico, quindi stiamo organizzando solo la possibilità di avere una macchina di back-up in modo da avere una configurazione active-passive, in modo
che in caso di failure della prima la seconda possa entrare in funzione.
Se in futuro si presenteranno esigenze di realizzare cluster in bilanciamento di carico, questo è per disegno possibile.
Per quanto riguarda le door di accesso per i protocollo Xrootd, al momento una singola macchina risulta sufficiente dal punto di vista del carico; tuttavia poiché la rete è già un collo di bottiglia, si procederà aggregando le schede di rete delle macchine usate e aumentando il numero di macchine che
esportano il protocollo stesso per massimizzare la banda di rete disponibile ai WN.
Per quanto riguarda invece il protocollo gsiftp, al momento sono in produzione 3 macchine che vengono usate in round-robin. Per fare questo è stato sviluppato uno script che si assicura che la macchina
sia funzionante prima di indirizzare il traffico verso questo end-point: in tal modo si garantisce sia il
bilanciamento del carico che la protezione contro la failure di una macchina di front-end.
Page 48
5.9.7 I servizi di Grid
Tabella 9 - I servizi di Grid.
Nome del
servizio
Situazione attuale
A regime
Specifiche della macchina
(usata attualmente)
User Interface
Cluster di macchine
accessibile attraverso il
puntatore logico:
Cluster di macchine accessibile
attraverso il puntatore logico:
Macchine Ex CNAF (2x Xeon –
4GB di ram)
Macchina di
front end
Computing
Element
frontend.ba.infn.it
gridba2.ba.infn.it
frontend.ba.infn.it
2 CE lgc in alta affidabilità +
(2x Xeon – 2GB di ram)
1 CREAM -CE
Batch System
(Torque-Maui)
Sul CE
gridba2.ba.infn.it
2 macchine in alta affidabilità
diverse dal CE
BDII
Sul CE
gridba2.ba.infn.it
Sulle macchine server del batch
system in alta affidabilità
Storage Element
storm-se-01.ba.infn.it
StoRM interfacciato a
Lustre
storm-se-01.ba.infn.it (+ stormbe-01.ba.infn.it) StoRM
interfacciato a Lustre
2x4Core – 8GB di RAM (SUN
X4140)
Porta GridFTP
gftp.ba.infn.it,
Un pool dinamico di porte
alicegrid09.ba.infn.i usate in base al carico e alla
t,
availability delle stesse
gridtutorial8.ba.infn
.it
2x4Core – 8GB di RAM (SUN
X4140)
Ganglia
pccms29.ba.infn.it
pccms29.ba.infn.it
Mon2
cmsprod.ba.infn.it
cmsprod.ba.infn.it
Virtuale
Nagios.ba.infn.it
Macchine Ex CNAF (2x Xeon –
4GB di ram)
Un pool di due macchine (con i
server finanziati 2009)
2x4core – 4GB RAM
NAGIOS
CRAB
crab1.ba.infn.it
5.9.8 I servizi per le VO
Tabella 10 - I servizi per le VO.
Nome del servizio
VO
Macchina virtuale/reale
Commento
WMS
CMS - all
wms1.ba.infn.it
LB
CMS - all
lb1.ba.infn.it
Crabserver
CMS
crab1.ba.infn.it
divisa su due macchina
SQUID
CMS
pccms26.ba.infn.it
Macchina molto vecchia che va sostituita
al più presto
PHEDEX
CMS
virtuale
L’hardware che ospita la macchina va
rinnovato al più presto perché molto
vecchio
ALICE VO-BOX
ALICE
Reale (alicegrid6.ba.infn.it)
DB-Server
Libi
Reali (dbserv1/dbserv2)
2 macchine con il back-up
Page 49
5.10 Le prestazioni della farm
Per quanto riguarda la qualità e la disponibilità del sito, nelle figure seguenti, Fig. 34 e Fig. 35, è mostrato il plot della qualità del sito di Bari e la sua availability confrontata con quella degli altri T2 di
CMS
(http://lxarda16.cern.ch/dashboard/request.py/historicalsiteavailabilityranking?siteSelect3=T2&sites=T2_IT_Bari&sites=T2_IT_Legnaro&sites=T2_IT_Pisa&sites=T2_IT_Rome&timeRange=last2W
eeks).
La cattiva performance durante il mese di ottobre 2009 è dovuta al passaggio dal file system d-Cache a
Lustre+ StoRM che ha portato alcune instabilità iniziali.
Fig. 34 - A sinistra: la “site availability” ( >80%) del sito di Bari nell’ultimo anno; a destra la “site availability”
nelle ultime due settimane.
Fig. 35 - Site availability di Bari a confronto con gli altri T2 di CMS a partire dall'inizio del 2009. Si noti il buco
a metà maggio causato dallo shut down per lo spostamento della farm.
Page 50
6 Attività di analisi dati e produzione Monte Carlo gruppo
CMS
6.1 Attività sulla farm di Bari
Nell’esperimento CMS la farm di Bari opera come un T2. La farm di Bari, insieme ai Tier2 di
Aachen, della Florida, del London Imperial College e di Vienna, è ufficialmente associata già dal 2008 - al gruppo di fisica sulle supersimmetrie di CMS (SuperSimmetry Physics Analysis Group, SUSY-PAG). Dettagli su tali attività sono forniti al paragrafo 6.1.1
La possibile associazione con un secondo gruppo di Fisica è in via di definizione. Inoltre il
Tier2 di Bari è candidato ad ospitare le attività di analisi relative alla stream primaria dedicata
al monitoring delle prestazioni degli RPC. I dettagli relativi sono riportati nel paragrafo 6.1.2.
D’altra parte il Tier2 di Bari già ospita altre attività di analisi condotte sia da fisici del gruppo
di Bari che da fisici di altre sezioni italiane nonché da fisici stranieri in collaborazione con il
gruppo locale. Le attività dei fisici coinvolti riguardano analisi inserite nell’ambito:
- del Muon Physics Object Group (µ-POG); alcuni dettagli sono riportati al par. 6.1.3;
- dell’ElectroWeak Physics Analysis Group (EWK-PAG) e del Particle-Flow/Tau Physics Object Group (PF/τ-POG); alcuni dettagli sono al par. 6.1.4.
Infine alcuni fisici del gruppo di Bari sono fortemente coinvolti nelle attività di analisi del sottogruppo HZZ dell’Higgs Physics Analysis Group (Ηiggs-PAG) come brevemente richiamato
nel par. 6.2.
Il gruppo di Bari è anche impegnato nell’attività di servizio della produzione Monte Carlo di
CMS, come riportato nel par. 6.3.
6.1.1 SUSY (ed EWK)
In questo periodo si stanno terminando le repliche degli skim di analisi (PAT Level 1) su eventi Monte
Carlo denominati Summer08 e che consistono nei campioni di segnale e di fondo specifici per le analisi SUSY. Questa attività rappresenta un test di capacità di copia tra due Tier2 e rappresenta allo stesso tempo un esempio di analisi condivisa. Lo spazio usato per questo skim in particolare è di 10 TB. Il
resto dello spazio disco, allocato istituzionalmente per il SUSY-PAG sarà utilizzato a breve per produzioni MC particolari e skim per analisi di effetti sistematici. Non è ancora possibile stimare con ragionevole precisione la CPU necessaria per l’analisi degli skim. La persona di collegamento tra il Tier2 ed
il gruppo SUSY-PAG ed i suoi convener è M. Maggi.
A Bari l’analisi dei dati per la fisica di ricerca della supersimmetria punta allo studio di eventi finali
con leptoni µ, jet ed energia mancante. Gli studi effettuati finora sono stati dedicati alla comprensione
del rivelatore e alla sua risposta agli eventi attesi nel modello standard (in particolare processi di produzione elettrodebole di Z e W con stati finali simili a quelli tipici di supersimmetria). Su questi studi
elettrodeboli sono state recentemente concluse nel gruppo di Bari due tesi di dottorato (S. Tupputi e G.
Roselli); inoltre sono in via di ultimazione due tesi di dottorato presso l’Università Les Andes di Bogotà, di cui M. Maggi è stato fino alla fine del 2008 tutor all’interno del progetto della comunità europea HELEN; la collaborazione fra il gruppo colombiano ed il gruppo di Bari è tuttora molto attiva.
6.1.2 Determinazione prestazioni RPC mediante stream dedicato
Al Trigger Review di CMS del 2008 è stata finalizzata da M. Maggi e M. Abbrescia la proposta per
una stream primaria dedicata per il monitoring delle prestazioni degli RPC, che è stata accolta e testata durante il CRAFT09. La stream denominata RPCMonitor è basata su due Trigger Path. Il primo
detto “di normalizzazione” è basato su qualunque µ che passi il Livello 1 di trigger ed è prescalato
affinché rimanga sotto i 30 Hz, il secondo detto “patologico” è basato sugli stessi trigger in cui però
gli RPC sono candidati a non aver risposto correttamente.
Durante il CRAFT09 la rate usata era di 300 Hz e il throughput della stream è rimasto contenuto sotto
1 MB/s in quanto solo le informazioni del sistema di camere per i µ venivano immagazzinate. Passando dai raggi cosmici alle collisioni protone-protone la stream è previsto che contenga eventi con
un µ nello stato finale arricchito per eventi di basso momento trasverso (che quindi non passerebbero
l’HLT) e per situazioni in cui il sistema RPC non abbia risposto in qualche sua componente.
È stato richiesto di definire il data flow di questa stream primaria al di fuori del Tier0 proponendo di
considerare come Tier1 - ai fini del custodial - il CNAF e di allocare le risorse per il suo utilizzo in
tempo reale presso il Tier2 di Bari che è la sede dove si raccoglie una comunità numerosa del progetto
RPC di CMS.
Le risorse necessarie sono calcolabili a partire da 1 MB/s allocato a tale stream. Per lo storage lo spazio richiesto ammonta, per i primi 2-3 anni, a 15 TB/anno di nastro al CNAF e 20 TB/anno su disco
per permettere la creazione di vari skim. Le risorse necessarie non crescerebbero dal terzo anno in
quanto si potranno cancellare i dati vecchi (conservando eventualmente qualche particolare skim).
L’applicazione di monitoring si stima richieda 20 core di CPU, mentre le successive analisi su skim
dedicati richiederebbero 10 core aggiuntivi.
6.1.3 RPC Muon Trigger Performance
Negli ultimi mesi R. Trentadue ha continuato ad occuparsi dello sviluppo delle procedure e degli algoritmi per lo studio dell'efficienza di trigger degli RPC utilizzando come riferimento il sistema di
trigger delle Drift Tube (DT).
Il metodo implementato consiste nell'individuazione di una traccia ricostruita dal sistema di muoni,
senza il contributo degli hit degli RPC. Questa traccia chiamata Stand Alone poiché non usa le informazioni del tracker, viene propagata attraverso le stazioni di muoni fino alla stazione 2 di riferimento per l'attribuzione delle coordinate eta e phi del trigger.
Fig. 36 - L'efficienza RPC Muon Trigger nel piano phi-z
Considerando un intervallo fiduciale di 20° intorno alla coordinata phi stimata dalla traccia ricostruita,
Page 52
l'algoritmo cerca nelle DT un candidato trigger dell'evento (basta chiedere che il suo bunch crossing
sia zero). Se il candidato trigger viene trovato, nella stessa regione fiduciale l'algoritmo cerca il corrispondente candidato trigger RPC. Se esso viene individuato allora il sistema di trigger degli RPC viene considerato efficiente. I risultati trovati sono soddisfacenti in quanto l'efficienza in funzione del pt
del muone ricostruito è circa al 98%. L'efficienza nel piano phi-z è abbastanza uniforme a parte nella
regione dei crack (separazione) tra wheel e settori.
6.1.4 Stima della muon fake rate e test di accesso allo storage
All’interno dell’attività del µ-POG L. Barbone ed A. Pompili si sono interessati di alcuni aspetti della ricostruzione dei muoni nonché dell’identificazione degli stessi. Nell’ultimo anno
l’attività è stata focalizzata su una prima stima della fake rate muonica poiché la contaminazione prevalentemente adronica ( " ,K, p ) dei muoni ricostruiti costituisce una generale rilevante sorgente di incertezza sistematica. Preliminarmente hanno collaborato allo sviluppo e al
debugging di uno strumento affidabile che fornisca la cosidetta “verità Monte Carlo”; questo
strumento denominato MuonAssociatorByHits fornisce l’associazione delle tracce ricostruite
! di matching fra gli hit ricostruiti e quelli simulati.
con quelle simulate al livello
Eseguire una stima realistica della fake rate muonica richiede l’uso di un campione Monte
Carlo di eventi di QCD particolarmente inclusivi, e quindi realistici, in cui sono anche simulati muoni secondari prodotti negli sciami calorimetrici e per decadimento in volo di pioni e kaoni. Dover stimare effetti dell’ordine di 10"4 ÷10"5 richiede di dover processare alcuni milioni
di eventi ed il campione ospitato al Tier2 ha occupato circa 10TB (2TB in formato RECO e
ben 8TB in formato RAW).
Il Tier2 ha svolto fino al 2008
! una considerevole attività di produzione dei dati simulati per
LCG3 (vedi 6.3) mentre poca esperienza era stata maturata fino al 2008 in relazione a molteplici e complesse attività di analisi, per loro natura caratterizzate da un accesso caotico ai dati
immagazzinati. L’applicazione usata per l’analisi di fake rate è particolarmente esigente dal
punto di vista dell’accesso allo storage; infatti tale applicazione, che deve poter accedere a
molti file, trattandosi di campioni di fondo ad alta statistica, richiede, processando ciascuno di
questi file dal formato "ristretto" (RECO), anche l'accesso, evento per evento, ad ulteriori file
dal formato più "ampio" (RAW) aventi informazioni di più basso livello ma necessarie per il
tipo di analisi in questione. In tal modo è stato possibile impostare un sistema di test e valutazione di opzioni combinate di hardware e software in relazione all'accesso allo storage da parte delle applicazioni di analisi, cioè ad uno degli elementi cruciali per garantire l'efficienza e
la proficuità del modello di calcolo dell’esperimento CMS. Come risultato di questi test si è
ottenuta sia la definizione di migliori configurazioni hardware per un più efficiente accesso
allo storage che la comparazione in termini di efficienza e scalabilità di sistemi software di
gestione dello storage (sistemi di caching dinamico dei file - come dCache - confrontati con
file-system distribuiti ad accesso parallelo - come Lustre).
6.1.5 EWK con µ + τ-jet (e PF/τ -POG)
Di analisi effettuate nell’ambito elettrodebole si è accennato anche fra gli studi preliminari per
il SUSY-PAG. A questi va aggiunta l’attività di ricerca condotta - a partire dal 2007 - da
L.Lusito (in cui si e’ inserito recentemente C.Calabria) che è incentrata sulla produzione del
bosone Z che decade in leptoni τ. Precisamente si vuole ricostruire il canale
Z " ## " µ + #Jet + X nel quale un τ decade leptonicamente e l’altro semileptonicamente o
adronicamente. Scopo iniziale è la stima del rapporto di sezioni d’urto
!
Page 53
!
" (Z # $$ ) " (Z # µµ) e il tuning di algoritmi di τ−tagging. Attualmente è in corso
l’ottimizzazione dei metodi di estrazione del segnale mediante reiezione del fondo basata su
proprietà di ricostruzione ed identificazione dei µ e dei τ−jet, il che ha richiesto di partecipare
contestualmente anche al tuning degli algoritmi di ricostruzione ed identificazione dei leptoni
τ nell’ambito degli studi del PF/τ-POG. Ulteriore contributo è stato fornito per lo studio di
efficienza di diversi trigger path.
!
Attualmente la ricerca è focalizzata sull'applicazione di metodi per la stima del contributo del fondo
dai dati, in particolare sul "template method" e sulla determinazione degli errori sistematici.
Il Tier2 ha ospitato gli skim dei campioni simulati sia di segnale che di fondi della “produzione Summer08”, accessibili sia via GRID da altri collaboratori dell’EWK-PAG che in locale. Su questi studi
sono in fase di completamento sia la tesi di dottorato di L.Lusito che la tesi di laurea di C.Calabria
sotto la supervisione di A.Colaleo e S.Nuzzo.
6.2 Attività del gruppo di Bari nella ricerca dell’Higgs
!
!
Gli eventi a 4 leptoni H " ZZ (*) " 4l - dove per 4 leptoni si intendono le combinazioni con
4 µ, 2e2µ, 4e - rappresentano una terna di canali particolarmente indicati per la ricerca dell’Higgs
(H) previsto dal Modello Standard, poiché costituiscono una “segnatura” particolarmente pulita e dal
tasso di produzione relativamente significativo in un ampio intervallo di valori della massa dell’H.
All’estrazione!del segnale H " ZZ (*) " 4l stanno lavorando dalla meta’ del 2007 N. de Filippis ed
A. Pompili, mentre L. Barbone sta iniziando ad inserirsi. Specificatamente N. de Filippis, appena rientrato a Bari, mantiene la responsabilità del coordinamento del software e dell’analisi del sottogruppo
HZZ maturata nel periodo da contrattista presso l’Ecole Politecnique di Parigi e che ha consentito – a
!relativo all’intera catena di analisi - una trattazione unificata dei tre canali. A. Pomlivello del codice
pili ha curato la parte che riguarda l’utilizzo del parametro d’impatto dei leptoni e di variabili di vertexing quali osservabili usate nei criteri di selezione dei suddetti canali per la reiezione dei fondi. Il
gruppo intende proseguire nello sviluppo ed ottimizzazione dell’intera catena di analisi dei canali
H " ZZ (*) " 4l . Nel primo anno di raccolta dei dati l’analisi sarà incentrata sullo sviluppo delle
strategie “di scoperta” per estrarre dal copioso fondo un picco nella distribuzione della massa invariante di 4 leptoni quale indicazione della presenza dell’Higgs, poiché una stima della sezione d’urto di
produzione H " ZZ ed una misura di alcuni parametri principali del bosone di Higgs (massa e larghezza per iniziare) richiedono oltre ad una conoscenza dettagliata della calibrazione e
dell’allineamento del rivelatore una luminosità non integrabile in breve tempo. Analogamente a più
lungo termine si intende partecipare alla misura dello spin-parità e degli accoppiamenti del bosone di
! ai fermioni ed ai bosoni di gauge.
Higgs
6.3 Attività di produzione Monte Carlo
Il gruppo di Bari si è occupato della produzione Monte Carlo sin dal luglio 2006 quando è stata avviata per la prima volta in CMS una intensa attività di produzione in preparazione al CSA06 (Computing,
Software, and Analysis challenge 2006) . Il gruppo di produzione basato a Bari e composto da N. de
Filippis, M. Abbrescia, S. My, A. Pompili, A. Pierro e G. Maggi, più persone della altre sezioni INFN
ed in particolare della Sezione di Pisa (S. Sarkar), era identificato come gruppo LCG3 che è stato uno
dei 4-5 gruppi di produzione di CMS operanti fra l’Europa e gli USA curatori dell’intera produzione
di dati simulati di CMS dal 2006 fino alla primavera del 2008 quando la Collaborazione ha deciso di
centralizzarla al CERN. Complessivamente l’esercizio si è rivelato molto utile perché ha permesso di
debuggare il funzionamento sia del Tier1 che dei Tier2 italiani di CMS, scoprire i problemi, trovare le
soluzioni e rendere il sistema distribuito di calcolo pronto per la presa dei dati ad LHC.
Solo di recente, con la nuova riorganizzazione del gruppo della produzione al CERN, la Collaborazione CMS ha deciso di utilizzare gruppi di sottomissione esterni al CERN. A luglio scorso sono state
Page 54
avviate trattative con il gruppo della produzione di CMS che hanno portato ad individuare due persone
di Bari (V. Spinoso e M. Abbrescia) disponibili a seguire l’attività di produzione. L’attività di produzione a Bari è dunque ripresa a partire dalla seconda metà di settembre 2009 non appena si è concluso
un ciclo di training seguito al CERN presso il gruppo centrale di produzione. Al gruppo di sottomissione barese è stata assegnata la zona CNAF che comprende tutti i Tier2 italiani più Vienna e Budapest.
Page 55
7 Attività di analisi dati e produzione Monte Carlo gruppo
ALICE
7.1 Attività sulla farm di Bari e GRID
L’attività del gruppo ALICE Bari, relativamente all’impiego di risorse di calcolo, si sviluppa sulle seguenti aree di attività:
- sviluppo e manutenzione codice di simulazione e ricostruzione per i rivelatori SPD e
HMPID
- attività di analisi nell’ambito Soft Physics (ALICE-PWG2) e First Phyisics per la misura
di molteplicità e densità di pseudo rapidità con il rivelatore a pixel
- attività di analisi nell’ambito Heavy-Flavour Physics (ALICE-PWG3) per la misura delle
J/psi secondarie da decadimento di adroni con beauty
- attività di analisi nell’ambito Photon and Jet Physics (ALICE-PWG4) per la ricostruzione
di jet attraverso algoritmo di “deterministic annealing”.
Soprattutto nel corso dell’ultimo anno, a causa della naturale evoluzione delle attività di analisi (quindi
soprattutto in riferimento ai tre ultimi punti sopra citati), vi è stato un crescente impiego delle risorse
di calcolo, sia impegnando le risorse locali, che utilizzando le risorse di GRID.
7.1.1 Produzioni Monte Carlo
Già dal 2006, Bari ha partecipato alle sessioni di produzione del Physics Data Challenge della collaborazione ALICE (PDC). Nel corso di queste sessioni e delle altre che sono venute in seguito, il gruppo
di Bari si è concentrato su due fronti: il primo più mirato specificatamente alle produzioni Monte Carlo relative alle attività di analisi del gruppo Alice-Bari (rivelatori SPD e HMPID); il secondo riguardante le sperimentazioni sull'affidabilità dei servizi specifici della VO di ALICE nell’ambito delle
attività di GRID di ALICE.
I ricercatori che si stanno occupando ormai da anni di produzione e analisi dei dati sono Giuseppe
Bruno, Domenico Di Bari, Domenico Elia, Vito Manzari e un numero cospicuo di dottorandi e laureandi (attualmente Davide Perrino, Giacomo Volpe, Carmelo Di Giglio, Mariella Nicassio). I responsabili delle produzioni sono Domenico Elia per l’SPD e Domenico Di Bari per l’HMPID.
Nell’ambito del Physics Working Group 2 (PWG2) di Alice sono state realizzate delle produzioni p-p
minimum bias (50 K eventi), Pb-Pb (5 K eventi minimum bias e altrettanti 5% “most central”) con
numerose multiple ricostruzioni finalizzate allo studio delle prestazioni dell’algoritmo di ricostruzione
dei “tracklets” con SPD. Per lo sviluppo ed il test della catena di analisi per la ricostruzione della densità di pseudo rapidità si è invece fatto uso del calcolo su GRID e di campioni generati centralmente
nell’ambito First Physics. In ambito PWG3 è in corso un intenso lavoro per ottimizzare lo studio della
ricostruzione di J/psi da decadimento di B: sono state impostate e recentemente completate produzioni
ufficiali su GRID per p-p minimum bias (100 M eventi) e p-p con J/psi primarie (16 M eventi). E’ in
corso una ulteriore produzione p-p con J/psi da B. Infine nell’ambito PWG4 si stanno testando opzioni
diverse per l’algoritmo di ricostruzione dei jet (sviluppato a Bari e basato su “deterministic annealing”) utilizzando campioni prodotti su GRID con jet di diverse energie, cercando in particolare di ottimizzare la ricostruzione per eventi Pb-Pb a bassa molteplicità.
7.2 Attività di analisi del gruppo di Bari
7.2.1 Misura di dN/dη con il rivelatore a pixel in ambito first physics
Si tratta di un’attività di analisi perseguita nell’ambito dei gruppi soft physics (PWG2) e first physics
di ALICE. La misura di densità di pseudo rapidità verrà realizzata con i punti ricostruiti nei due strati
del SPD, con il quale è possibile coprire la regione centrale di pseudorapidità (|η|< 1.5) per tracce fino
a valori molto bassi di impulso trasverso (circa 30 MeV/c). L’algoritmo di ricostruzione associa un
Page 56
cluster sullo strato interno ad uno corrispondente sullo strato esterno del rivelatore (per individuare il
cosiddetto “tracklet”) quando i due punti sono allineati con il vertice primario di interazione entro definite tolleranze. L’interesse immediato per questa misura risiede nel fatto che essa sarà la prima misura realizzata in ALICE e quindi l’oggetto del primo Physics Paper della Collaborazine. Essa infatti
richiede l’allineamento dei soli due strati di pixel e quindi procedure di calibrazione e allineamento
estremamente più semplici rispetto a quelle necessarie per la camera a proiezione temporale (TPC):
quest’ultima verrà utilizzata in fasi successive all’acquisizione dei primi dati e consentirà la ricostruzione completa delle tracce cariche in campo magnetico.
Le principali correzioni sono state studiate in dettaglio in funzione della pseudo-rapidità η, della posizione del vertice primario z e della molteplicità di tracce cariche ricostruita. I contributi di correzione
da applicare a livello di traccia sono i seguenti:
- background da particelle secondarie;
- inefficienza di ricostruzione dell’algoritmo;
- accettanza ed inefficienza del rivelatore a pixel;
- contributo di particelle che non raggiungono lo strato sensibile del rivelatore;
- inefficienza di ricostruzione del vertice primario e dell’algoritmo di selezione di trigger.
Sono state realizzate, sia sul cluster di calcolo locale che sulla GRID (in ambito ufficiale Gruppo First
Physics al CERN), numerose produzioni Monte Carlo atte a sviluppare e testare l’intera catena di analisi: la validazione del metodo è avvenuta utilizzando simulazioni a diversa energia nel centro di massa
(900 GeV, 7 TeV, 10 TeV e 14 TeV), con diversa distribuzione della posizione trasversa del vertice
principale di interazione e con diversi generatori di fisica (PYTHIA e PHOJET).
La prospettiva è quella di analizzare i primi dati di fisica, perfezionare la catena di analisi adattandola
al caso delle collisioni Pb-Pb in attesa dei primi dati con gli ioni alla fine del 2010.
7.2.2 Misura di J/psi da decadimento di adroni con beauty
Si tratta di un’attività perseguita nell’ambito del gruppo di analisi heavy-flavour (PWG3) di ALICE.
E’ in fase avanzata di definizione la catena di analisi per la ricostruzione del decadimento B -> J/psi +
X che rappresenta uno dei più interessanti obiettivi di fisica con il campione di dati p-p da raccogliere
nel corso del primo anno. In particolare sono stati generati nel corso dell’ultimo anno dei campioni
Monte Carlo finalizzati alla ottimizzazione del rapporto segnale su fondo (eventi p-p minimum bias,
con J/psi da B e con J/psi primarie rispettivamente). In prospettiva occorrerà fare uno studio dettagliato delle diverse sorgenti di errore sistematico nonché, al solito, adattare gli strumenti preparati per p-p
al caso delle collisioni Pb-Pb. In tempi recentissimi è stato perseguito anche uno studio di fattibilità
della ricostruzione dello spettro di impulso trasverso del B a partire dal corrispondente spettro ricostruito della J/psi da B. Lo studio sembra fattibile, ancora nell'ambito del primo anno di presa dati ma
vanno stimati anche qui i diversi sistematici. In particolare si rende necessario l'uso di un generatore
molto più adatto di Pythia alla fisica del (decadimento del) B. Un candidato alternativo è stato individuato in EVTGEN (usato da BaBar e LHCb): il nuovo generatore andrà integrato in AliRoot per poi
proseguire con una campagna di produzioni Monte Carlo dedicate.
7.2.3 Analisi di jet con identificazione di adroni carichi
Lo studio della produzione di particelle ad alto pT si articola all’interno del Physics Working Group 4
(PWG4) di Alice. Le proprietà della QCD in condizioni estreme di densità di energia e temperature in
gioco possono essere per esempio studiate attraverso l’analisi dei jet (gruppi di particelle correlate ad
alto pT). Questi vengono comunemente ricostruiti tramite algoritmi, inclusi nel codice. Uno di essi, il
Deterministic Annealing (DA), è stato sviluppato e introdotto dal dott. D. Perrino.
Dal punto di vista della programmazione ha contribuito ad adattare il codice comunemente usato dal
PWG4 alle esigenze dell’analisi secondo le ultime direttive della Collaborazione, e ha modificato le
classi relative al DA affinché fosse possibile effettuare l’analisi sfruttando il Cern Analysis Facility
(CAF). Ha inoltre testato sui vari algoritmi un metodo sviluppato all’interno del PWG4 per l’unfolding
dello spettro di pT ottenuto nell’analisi di jet. Ora tale metodo è incluso nel codice, funzionante e utilizzabile da tutti.
Un importante contributo allo studio di eventi con alto pT sarà sicuramente dato dal rivelatore HMPID,
che è in grado di identificare particelle cariche (π, K, p) nella regione di medio-alto pT. Si è valutato,
Page 57
grazie a dati generati con un Monte Carlo, l’accettanza rispetto alla leading particle (particella a più
alta energia in un jet), e valutato la molteplicità di particelle del jet identificabili dal rivelatore stesso.
Sono inoltre in corso d’opera una serie di sostanziali modifiche al DA, che ne dovrebbero aumentare
l’affidabilità e la velocità di calcolo. Si sfrutteranno, poi, le risorse locali per fare un’estensiva analisi
di eventi simulati al fine di effettuare una comparazione tra diversi algoritmi per la ricostruzione dei
jet (DA, UA1, FastJet). Inoltre si è già avuta l’approvazione da parte della Collaborazione per una
produzione specifica di circa 4 milioni di eventi protone-protone a 7+7 TeV di trigger dove è richiesto
che almeno un jet occupi l’accettanza dell’HMPID. In questo modo sarà possibile verificare le prestazioni nell’identificare jet in termini di efficienza e contaminazione. Tale produzione avverrà su GRID
con la specifica richiesta che i dati siano memorizzati sullo storage presente a Bari per ottimizzare gli
accessi ai dati, poiché l’analisi verrà svolta interamente a Bari.
7.2.4 Analisi dei primi dati di ALICE con cosmici
I dati con cosmici già presi nel corso dello scorso anno, in particolare quelli ottenuti con trigger basato
sul FastOr SPD (coincidenza “top-bottom layer”) sono stati utlizzati per definire l’allineamento interno del rivelatore a pixel. I dati 2009, ancora in corso di acquisizione, puntano a verificare e migliorare
l’allineamento già determinato: il risultato complessivo costituirà la base per l’analisi dei primi dati pp e per ottenere, in una fase appena successiva, l’allineamento finale verificato con le collisioni. Il
gruppo di Bari ha contribuito in questo sforzo, in particolare verificando la corrispondenza tra dati e
simulazione, con particolare riferimento alla riproduzione della distribuzione di cluster size (in funzione dell’angolo di incidenza dei muoni) da parte del modello di risposta del SPD in AliRoot. E’ stata
inoltre di recente messa a punto una procedura per la valutazione della efficienza di rivelazione e di
risposta del FastOr (per singolo chip del SPD) specificamente utilizzabile con tracce di cosmici.
L’HMPID ha partecipato alla presa dati di ALICE fino ad ottobre 2008. I dati raccolti si riferiscono sia
a muoni cosmici, sia ad eventi di fascio durante i test di iniezione ad LHC. L’analisi effettuata sui dati
raccolti ha avuto l’obiettivo di verificare il funzionamento corretto del rivelatore. I risultati ottenuti
hanno mostrato il buon allineamento con la Time Projection Chamber (TPC) di ALICE e la correttezza della mappatura dei più dei 160000 canali. Il guadagno delle camere proporzionali è stato anche
valutato ricavando le distribuzioni in carica corrispondenti alle MIP ed ai singoli elettroni.
Si stanno studiano le prestazioni di un nuovo algoritmo (l’Hidden Track Algorithm: HTA) pensato per
poter ricavare l’angolo Cherenkov medio di anelli rivelati dall’HMPID in eventi a bassa molteplicità
senza alcuna informazione fornita dai rivelatori traccianti. Tale algoritmo è stato ideato e sviluppato
interamente a Bari. Le persone coinvolte sono Domenico Di Bari e Francesco Barile (dottorando primo anno). Un’applicazione di questo algoritmo con l’HMPID si basa sulla possibilità, in maniera indipendente, di verificare l’allineamento del rivelatore nel sistema di riferimento di ALICE.
Le prestazioni di questo algoritmo sono state verificate in eventi simulati p-p in ALICE. I dati generati
sono stati di due tipi: eventi p-p con campo magnetico pari a 0.5 T ed eventi senza campo magnetico.
Con i primi eventi siamo stati in grado di verificare e migliorare l’efficienza dell’HTA. Tale algoritmo
è stato inserito nella classe AliHMPIDReconHTA.cxx nel programma AliRoot. Esso è utilizzabile nelle simulazioni ed è pronto per essere applicato all’analisi dei primi dati di interazione ad LHC.
7.2.5 Il Very High Momentum Particle Identification Detector: VHMPID
Lo studio di fattibilità di un nuovo rivelatore, che ha come obiettivo quello di estendere
l’identificazione su singola traccia di adroni carichi ad impulsi maggiori di quelli attualmente raggiungibili in ALICE, è una delle attività in cui il gruppo di Bari è impegnato per un’eventuale upgrade di
ALICE. Il ricercatore che sta conducendo tali studi è il dott. Giacomo Volpe.
Data l’energia disponibile ad LHC, jet con “leading particle” con impulso superiore ai 10 GeV/c saranno molto probabili. La capacità di identificare adroni carichi su singola traccia in tale intervallo
d’impulsi risulterebbe di grande importanza allo studio della fisica dei jet (modificazioni dovute al
mezzo, funzioni di frammentazione), nelle collisioni ad LHC. Attualmente in ALICE, il rivelatore
HMPID identifica su singola traccia per impulsi ben al di sotto dei 10 GeV/c e la TPC identifica fino a
30 GeV/c, ma su base statistica. Nell’ambito di tale problematica, il dott. G. Volpe si sta occupando
dello studio di fattibilità di un rivelatore in grado di identificare adroni carichi ad impulsi superiori ai
Page 58
10 GeV/c. Per tale apparato, denominato VHMPID (Very High Momentum Particle Identification
Detector), dato l’intervallo d’impulsi che deve coprire, si è pensato ad un rivelatore di luce Cherenkov
ad immagini anulari, che utilizza come radiatore un gas a basso indice di rifrazione. Si è ottimizzata la
geometria e la scelta dei materiali, attraverso simulazioni in AliRoot. Dopo diverse configurazioni studiate, la più efficace è risultata essere quella in cui i fotoni Cherenkov prodotti nel radiatore sono riflessi da uno specchio sferico sul fotorivelatore, che si trova sul suo piano focale. Il radiatore scelto è
il C4F10.
Il fotorivelatore consiste in una MWPC con fotocatodo a CsI, segmentato in pad di 0.8x0.84 cm2. Il
gas contenuto nella MWPC è CH4. Una finestra di SiO2 di 4 mm di spessore, separa il radiatore dalla
camera proporzionale. La lunghezza del radiatore scelta è 80 cm, che si adatta bene allo spazio disponibile in ALICE.
La simulazione effettuata per studiare tale disposizione è consistita in 1000 eventi di collisione Pb-Pb
alle energia di LHC, ottenuti con HIJING, e di una singola particella alla saturazione, ortogonale al
rivelatore. Tale produzione è stata condotta interamente sulle risorse locali del gruppo ALICE.
La geometria completa prevista per il VHMPID, implementata già in AliRoot, consiste in 12 moduli
posizionati nello spazio libero adiacente il PHOS. I moduli si distribuiscono con simmetria cilindrica
intorno al punto d’interazione, per far si che le particelle ad alto impulso prodotte nelle collisioni, colpiscano il rivelatore quasi ortogonalmente. La distanza dal punto d’interazione è di circa 5.5 m.
7.2.6 Attività di analisi future per il gruppo ALICE-Bari
Di seguito sono elencate le principali attività previste per l’immediato futuro, nell’ipotesi di presa dati
di interazione ad LHC:
1. Calibrazione sui dati reali del modello di risposta del rivelatore a pixel
2. Validazione degli algoritmi di ricostruzione su eventi da collisioni p-p
3. Analisi fisica completa dei primi campioni raccolti (“first physics”) di collisioni p-p
alle energie di LHC:
- densità media di particelle cariche a rapidità centrale
- distribuzione di molteplicità di particelle cariche a rapidità centrale
4. Analisi fisica dei primi dati di collisioni Pb-Pb (se disponibili)
5. Messa a punto su dati reali delle procedure di analisi fisica da effettuarsi sul campione
completo del run 2009-2010, in particolare:
- heavy flavour nel rivelatore centrale (J/Ψ da adroni con beauty)
- ricostruzione e analisi di jet
6. Raccolta dati sufficienti per l’allineamento dei sette moduli di HMPID rispetto al sistema di riferimento di ALICE;
7. Messa a punto dei programmi online di monitoring e raccolta e validazione degli istogrammi di riferimento;
8. Calibrazione dei sette moduli, mediante calcolo del guadagno delle camere, e
dell’indice di rifrazione con la temperatura del liquido radiatore; verifica del guadagno
per singolo fotoelettrone da studio della carica dei fotoni raccolti;
9. Studio di trigger con i due layer dei rivelatori a pixel (mediante FASTOR) per jet
nell’HMPID;
10. Analisi e studio degli eventi simulati di jet nell’HMPID.
Page 59

La nuova Sala Calcolo-V12

Transcript

Documenti analoghi

direttamente dai palchi di vasco rossi, san remo e music farm.

Guida all`accesso al sito per i Collegi Provinciali IPASVI

Sistemi in rete, Il software Sistemi offerto anche come servizio

Armonie perturbanti: un caso di rimediazione di

sotto foma di pellicola, ma gli elementi pseudo

Gt Farm

Provincia di Bari - Città Metropolitana di Bari