Graduate School in Physics and Astrophysics ------------------------------------------- ANNUAL REPORT ------------------------------------------- Fill with a text editor (without TAB or formatting) Repeat fields for each course as necessary. ------------------------------------------- name: Dario BERZANO email: dario.berzano@to.infn.it ciclo: 26 year completed (1,2 or 3): 1 supervisor: Prof. Massimo MASERA ------------------------------------------- GRADUATE SCHOOL COURSES (only completed courses, with examination passed in the year) code: title: teacher: hours: ------------------------------------------- COURSES FROM OTHER GRADUATE SCHOOLS (only completed courses, with examination passed in the year) school: Politecnico di Torino title: Parallel and Distributed Computing teacher: Prof. Bartolomeo MONTRUCCHIO hours: 20 ------------------------------------------- UNDERGRADUATE COURSES (Laurea Magistrale) (only completed courses, with examination passed in the year) title: teacher: hours: ------------------------------------------- SUMMER SCHOOLS, INTERNATIONAL SCHOOLS (only those attended in the current year) title: II INFN International School on Architectures, tools and methodologies for developing efficient large scale scientific computing applications place: Bertinoro (FC) - Italy webpage: http://www.ceub.it/corsi/corso-scheda_en.cfm?wid=1506 days: 5 talk or poster (Y/N): N title: VIII Seminario sul Software per la Fisica Nucleare, Subnucleare ed Applicata place: Alghero (SS) - Italy webpage: http://agenda.infn.it/conferenceDisplay.py?confId=3442 days: 5 talk or poster (Y/N): N title: CERN School of Computing - Copenhagen, Danimarca place: Copenhagen - Denmark webpage: http://csc.web.cern.ch days: 15 talk or poster (Y/N): Y ------------------------------------------- CONFERENCES, WORKSHOP (only those attended in the current year) title: 14th Advanced Computing and Analysis Techniques (ACAT) place: Uxbridge - United Kingdom webpage: http://acat2011.cern.ch/ days: 5 talk or poster (Y/N): Y ------------------------------------------- VISITS AND STAGES (only those done in the current year) institution: place: starting date: days: --------------------------------------------------- Research activity/Publications in the current year (max characters 2500) Il mio lavoro si svolge principalmente presso il Centro di Calcolo della sezione di Torino dell'Istituto Nazionale di Fisica Nucleare. Come borsista INFN e dottorando presso l'Universita` di Torino il mio lavoro e` di supporto alle attivita` e servizi di calcolo offerti dal Centro di Calcolo di Torino all'esperimento ALICE di LHC presso il CERN di Ginevra. Dal punto di vista della rete di calcolo mondiale denominata Grid, usata principalmente nell'ambito della Fisica delle Alte Energie, il Centro di Calcolo di Torino e` un Tier-2, ovvero un centro di calcolo di medie dimensioni: molte delle attivita` da me svolte riguardano la ricerca di soluzioni innovative per l'utilizzo ottimale delle risorse di calcolo in condizioni di limitatezza. 1. PROOF e ALICE Analysis Facilities PROOF [1] e` uno strumento di calcolo parallelo ed interattivo, parte del framework di analisi ROOT [2] (il piu` usato nell'ambito della Fisica delle Alte Energie). A partire dal 2010, l'utilizzo di PROOF nel modello di calcolo dell'esperimento ALICE e` ufficialmente riconosciuto e considerato complementare al modello Grid: le reti di calcolatori basate su PROOF per l'esperimento ALICE sono identificate con il nome AAF (ALICE Analysis Facilities) [3]. Il mio lavoro per il CERN e l'esperimento ALICE e` stata ed e` la definizione del data model per le AAF, oltre che lo sviluppo ed il supporto degli strumenti e della documentazione ad esso funzionali. Nonostante le AAF siano in grado di analizzare i dati accedendovi direttamente dai siti Grid di tutto il mondo, questo approccio puo` portare a dei rallentamenti inaccettabili per un modello di calcolo interattivo. Per questa ragione il data model delle AAF prevede che i dati da analizzare siano indicati dall'utente prima dell'analisi. Uno strumento si preoccupa di trasferire i dati localmente in modo asincrono, e l'utente ha a disposizione degli strumenti per seguire lo stato del trasferimento. In PROOF esiste il concetto di dataset, ovvero elenchi di file corrispondenti ad un insieme di dati da analizzare. Il lavoro collegato al data model delle AAF e` lo sviluppo del software di gestione dei dataset, denominato afdsmgrd [4]. Tale software legge periodicamente l'elenco di dataset registrati dall'utente e gestisce il trasferimento, in parallelo, di una grande quantita` di files. Essendo le condizioni delle reti e dei siti da cui si trasferiscono i dati piuttosto eterogenee e variabili, il demone di gestione e` robusto e e` in grado di ripetere il trasferimento un certo numero (configurabile) di volte prima di considerare il fallimento permanente. Il backend per il trasferimento e` basato su script, dunque il demone e` in grado di trasferire file da una sorgente qualunque verso una destinazione qualunque, anche se in ALICE e` utilizzato il solo protocollo xrootd [5]. Un controllo di integrita` e` effettuato su ogni file trasferito: questo serve a ripetere il trasferimento se il danneggiamento e` dovuto ad esso, o a segnare permanentemente il file come danneggiato, per evitare blocchi imprevisti nell'analisi dell'utente che saltera` automaticamente i file identificati in questo modo. Il demone e` scritto interamente in C++ e puo` gestire una coda potenzialmente di milioni di elementi senza pesare sulla memoria, grazie all'utilizzo di SQLite [6]. Esso si e` verificato inoltre essere estremamente stabile. Tutte le AAF del mondo hanno in produzione una copia di questo demone. Essendo esso di un uso piu` generale di ALICE, e di supporto a PROOF, afdsmgrd viene attualmente distribuito come parte di ROOT ed e` utilizzato anche dall'esperimento ATLAS di LHC. Dal punto di vista dell'utente e` anche stato preparato un pacchetto (sotto forma di macro compilabile per ROOT) per la gestione dei dataset che ne consente la rimozione, la pulizia, il recupero in caso di corruzione e la creazione diretta a partire da una ricerca sul catalogo dei file di tutto l'esperimento mantenuto su AliEn (il middleware Grid di ALICE) [7], oltre che la sincronizzazione dei dataset tra tutte le AAF. 2. Infrastruttura per cloud computing basata su OpenNebula Presso il Centro di Calcolo di Torino e` nato un progetto per fornire supporto ad attivita` di tipo cloud computing, sia nell'ambito del calcolo che nell'ambito dei servizi. 2.1 Casi d'utilizzo del cloud computing a Torino Il cloud computing consiste nell'utilizzo di risorse hardware virtualizzate, come processori virtuali, dischi virtuali e reti virtuali. L'utilizzo della virtualizzazione nell'ambito del calcolo e` molto utile anche nei centri di piccole dimensioni perche' contribuisce alla distribuzione ottimale delle risorse, sia di calcolo che umane, per mezzo di macchine virtuali. Il Centro di Calcolo di Torino ospita un certo numero di macchine di calcolo utilizzate da diversi gruppi. Il cliente con il piu` grande numero di macchine e` la Grid (ed in particolare l'esperimento ALICE). Formalmente, quando un gruppo di lavoro richiede delle risorse di calcolo, esse vengono installate all'interno del Centro di Calcolo, collegate ad una rete, configurate e date in utilizzo al gruppo che ne ha fatto richiesta. Purtroppo queste operazioni sono piuttosto onerose in termini di ore di lavoro, molto ripetitive e suscettibili di errori. Inoltre molte di queste macchine rimangono accese ed installate anche quando sono inutilizzate o dopo la fine del loro periodo di utilizzo, pesando sul consumo di elettricita` e costituendo di fatto uno spreco di risorse. L'utilizzo di un'infrastruttura di tipo cloud, della quale ho configurato un prototipo attualmente in uso presso il Centro di Calcolo, dovrebbe costituire una risposta a tutti questi problemi. I computer fisici installati non sono nient'altro che hypervisor, ovvero macchine deputate all'esecuzione di macchine virtuali: quando un gruppo fa richiesta per un certo numero di risorse, si tratta semplicemente di istanziare una macchina virtuale che verra` configurata secondo le richieste del cliente e, a configurazione avvenuta, replicarla un certo numero di volte sull'infrastruttura cloud. Dal punto di vista dei servizi l'utilizzo di una cloud permette di copiare completamente lo stato di una macchina funzionante, replicabile integralmente nel caso di un malfunzionamento o di una compromissione, e permette la migrazione di una macchina virtuale attualmente in esecuzione su una macchina fisica malfunzionante verso una macchina fisica in salute senza interruzioni sostanziali del servizio. Per la gestione della cloud utilizziamo lo strumento open-source OpenNebula [8]. Abbiamo scelto OpenNebula perche' e` largamente diffuso, la sua comunita` e` molto attiva e ogni sua singola parte e` configurabile sotto forma di script basati sul linguaggio BASH o Ruby, consentendo un gran numero di gradi di liberta`. 2.2 Attivita` di configurazione e sviluppo svolta su OpenNebula Questo primo anno di attivita` su OpenNebula si e` concentrato essenzialmente su: la messa in sicurezza delle reti virtuali, la velocita` di trasferimento (deployment) delle immagini delle macchine virtuali sugli hypervisor, il monitoring ed il controllo scalabile dell'infrastruttura e l'eliminazione dei colli di bottiglia. Le macchine virtuali di farm diverse sono configurate su reti virtuali diverse, e anche se fisicamente tutte le comunicazioni transitano attraverso gli stessi switch, le reti virtuali sono isolate tra di loro a livello Ethernet grazie all'utilizzo di bridge virtuali creati con lo strumento ebtables [9]. Il deployment delle macchine virtuali non avviene con lo strumento predefinito di OpenNebula, che avviene attraverso SSH. Il disco contenente le immagini delle macchine virtuali e` condiviso su tutte le macchine fisiche della rete attraverso il filesystem distribuito GlusterFS [10], che consente una velocita` di trasferimento piu` che raddoppiata. La sostanziale riscrittura della parte di OpenNebula che si occupa del trasferimento delle immagini ha permesso di raddoppiare ulteriormente la velocita` rispetto all'utilizzo del solo GlusterFS. Inoltre, le immagini delle macchine virtuali vengono trasferite soltanto alla prima esecuzione sulla macchina di destinazione: la macchina virtuale non scrive poi le eventuali modifiche sull'immagine trasferita, bensi` su un cosiddetto snapshot di LVM, cosi` quando la macchina viene spenta e` possibile eliminare le sole modifiche rispetto all'immagine originale ed evitare un successivo trasferimento di quest'ultima. Naturalmente il tempo di deployment di un'immagine gia` pre-copiata sulla macchina di destinazione e` dell'ordine dei secondi, non avvenendo nessun trasferimento fisico. Il monitoring ed il controllo dell'infrastruttura vengono effettuati con Zabbix [11] e Puppet [12], mentre la maggior parte delle configurazioni interattive avvengono mediante una shell parallela chiamata pdsh che fa uso di SSH. L'eliminazione dei colli di bottiglia e` stata rivolta essenzialmente al punto critico delle macchine virtuali, ovvero l'accesso ai dischi: per migliorare la velocita` le macchine virtuali non vengono eseguite da file ma da partizioni LVM, mentre le aree di disco "usa e getta" per le macchine virtuali sono create all'avvio della macchina con il filesystem XFS, il cui tempo di creazione non dipende praticamente dalla dimensione del filesystem (a differenza del piu` diffuso ext3). e` attualmente in fase di test la configurazione di un servizio di object storage rivolto alle macchine virtuali basato sul protocollo HTTP denominato Swift [13], sviluppato nell'ambito del framework di gestione delle cloud OpenStack [14]. Dopo la configurazione di un servizio di storage di questo tipo, l'infrastruttura cloud potra` diventare ufficialmente operativa ed uscire dallo stato di prototipo. 3. Calcolo interattivo (PROOF) su macchine virtuali I due ambiti di lavoro sopracitati (PROOF da un lato, e cloud computing dall'altro) sono i capisaldi dell'evoluzione del lavoro costituente il tema dell'attivita` che sto svolgendo in qualita` di borsista INFN e dottorando. 3.1 PROOF su OpenNebula Alla conferenza ACAT 2011 ho presentato un lavoro denominato "PROOF on the cloud using PoD and OpenNebula", che illustra la strategia che sto seguendo a Torino per fornire uno strumento di calcolo interattivo e parallelo basato su PROOF al di sopra di un'infrastruttura virtuale, laddove la virtualizzazione sembra essere la strada piu` efficiente per ottenere l'elasticita` e la dinamicita` dell'infrastruttura: lavorando infatti in condizioni di limitatezza di risorse, vogliamo che le risorse non disponibili vengano rilasciate e rese disponibili per PROOF nel piu` breve tempo possibile, attraverso il deployment di macchine virtuali e l'eventuale sottrazione a tempo di esecuzione di macchine virtuali concorrenti sulla base di una politica di priorita` al calcolo interattivo. Il lavoro originale, denominato "A prototype of a dynamically-expandable Virtual Analysis Facility" [15][16][17] era basato su macchine virtuali installate staticamente sui nodi di calcolo. Negli ultimi tre anni l'evoluzione rapida degli strumenti di gestione delle infrastrutture cloud si sono evoluti al punto da permettermi di concentrarmi sullo sviluppo del caso d'uso in se' piuttosto che dell'infrastruttura di deployment e di gestione della virtualizzazione. Attraverso l'utilizzo del software PROOF on Demand, che necessita di un sistema di code per l'istanziazione dinamica di nodi di calcolo PROOF, piu` un sistema di code dedicato i cui nodi di calcolo sono macchine virtuali, e` stato possibile realizzare un demone di controllo che, senza cambiare l'esperienza d'uso dell'utente PoD e PROOF, controlla lo stato della coda PoD e sottomette automaticamente nuove macchine virtuali pronte a soddisfare le richieste di calcolo interattive. Queste macchine virtuali sono istanziate attraverso OpenNebula in modo trasparente per l'utente, che non ha nessuno strumento per poter accedere direttamente all'interfaccia di controllo dell'infrastruttura cloud. Grazie ai meccanismi di miglioramento della velocita` del trasferimento e al caching delle immagini delle macchine virtuali sui nodi di destinazione, in un tempo inferiore al minuto e mezzo l'utente puo` ottenere i nodi di calcolo richiesti. Il vantaggio di questa soluzione e` che fa un uso massiccio di tool gia` esistenti e mainstream, senza modifiche dei loro codici ma solo delle loro configurazioni. Il risultato e` uno strumento la cui stabilita` e` garantita dal supporto degli sviluppatori e della comunita`, considerato dunque sicuro ed affidabile. 3.2 PROOF su WNoDeS Recentemente e` stato aperto con il CNAF di Bologna un ramo di sviluppo di WNoDeS [18] che concerne il caso d'uso di PROOF. Si tratta sempre di effettuare il deployment dinamico di PROOF su macchine virtuali, ma questa volta su un sistema maggiormente orientato a siti di grandi dimensioni (proprio come il CNAF, che e` un Tier-1 per la Grid) che fanno essenzialmente calcolo utilizzando sistemi di code. L'idea e` quella di sfruttare l'infrastruttura di WNoDeS per effettuare il deployment trasparente di macchine virtuali che agiscono come server PROOF. La grossa differenza rispetto al lavoro svolto per il Centro di Calcolo di Torino e` che, in quest'ultimo caso, il sistema di gestione delle code e` gia` parte integrante dello stesso strumento di deployment, mentre l'utilizzo, anche in questo caso, di PROOF on Demand rende l'integrazione del lavoro piuttosto semplice. L'integrazione di PROOF con WNoDeS culminera` a settimane in un abstract che verra` sottomesso a CHEP 2012, e costituira` gran parte del mio lavoro per il prossimo anno di dottorato e di borsa INFN. 3.3 Utilizzo delle credenziali Grid con SSH per PoD Uno dei problemi affrontati e` l'integrazione di PoD con il sistema di autenticazione a certificato e chiave pubblica/privata attualmente in uso nella Grid. PoD, per sua natura, necessita di una connessione SSH su un nodo remoto per poter lanciare PROOF dinamicamente: siccome gli utenti Grid, ed in particolare gli utenti ALICE, dispongono gia` di credenziali per accedere ai servizi, occorreva trovare un sistema che utilizzasse le medesime per poter ottenere un accesso SSH su alcune macchine, al fine della fruizione del servizio PoD. Il lavoro consiste sostanzialmente in due parti: un'autenticazione ed un'autorizzazione. L'autenticazione avviene presentando il proprio certificato personale ad un server web HTTPS; se l'autenticazione ha successo, e se l'utente viene riconosciuto come un valido utente di ALICE, ottiene un'autorizzazione limitata nel tempo a collegarsi via SSH ad una specifica macchina. Questo lavoro, stabile ed in produzione, e` di interesse assolutamente generale e non limitato al caso di PROOF on Demand. Esso verra` a breve pubblicato sotto forma di nota interna della Commissione Calcolo e Reti dell'INFN ed integrato nei prossimi servizi di PROOF dinamico dell'esperimento ALICE. 4. Riferimenti [1] http://root.cern.ch/drupal/content/proof [2] http://root.cern.ch [3] http://aaf.cern.ch [4] http://code.google.com/p/afdsmgrd [5] http://xrootd.slac.stanford.edu [6] http://www.sqlite.org [7] http://alien2.cern.ch [8] http://opennebula.org [9] http://ebtables.sourceforge.net [10] http://www.gluster.org [11] http://www.zabbix.com [12] http://projects.puppetlabs.com/projects/puppet [13] http://swift.openstack.org [14] http://www.openstack.org [15] Berzano D, Bagnasco S, Lusso S and Masera M 2008 PoS(ACAT08)050 [16] Bagnasco S, Berzano D, Lusso S, Masera M 2009 J. Phys.: Conf. Ser. 219 062033 [17] http://personalpages.to.infn.it/~berzano/pub/VafThesis/Berzano-VafThesis-Eng-nobinding.pdf [18] http://web.infn.it/wnodes/index.php/wnodes BE AWARE: research activity and Pubs are not evaluated as didactic credits, but are requested to trace the PhD students' career