La nuova Sala Calcolo-V12
Transcript
La nuova Sala Calcolo-V12
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 Telefonino 338 7004665 Telefonino 393 5403592 Telefonino 328 8870476 Telefonino 333 3956376 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 Telefonino 348 0454699 Diacono Telefonino 338 7004665 Donvito Telefonino 393 5403592 Gervasoni Telefonino 333 3956376 Spinoso Telefonino 328 8870476 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 (2x Xeon – 2GB di ram) BDII Sul CE gridba2.ba.infn.it Sulle macchine server del batch system in alta affidabilità (2x Xeon – 2GB di ram) 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 (2x Xeon – 2GB di ram) 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 (2x Xeon – 2GB di ram) (2x Xeon – 4GB di ram) 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