L ANALYSIS FACILITY VIRTUALE DI TORINO. Dario Berzano (CERN, INFN & Università di Torino), Stefano Bagnasco, Riccardo Brunetti, Stefano Lusso (INFN)

Transcript

1 L ANALYSIS FACILITY VIRTUALE DI TORINO Dario Berzano (CERN, INFN & Università di Torino), Stefano Bagnasco, Riccardo Brunetti, Stefano Lusso (INFN) Workshop dei Tier-2 Italiani di ALICE - Catania, 20 dic 2012

2 L esperienza PROOF di ALICE

3 LE ANALYSIS FACILITIES PROOF DI ALICE ALICE Analysis Facilities (AAF): al fine di garantire agli utenti una esperienza comune in ogni sito, dal 2010 esistono delle linee guida che tutte le AF di ALICE seguono ASPETTI COMUNI Autenticazione: tutti gli utenti di ALICE hanno accesso a tutte le AAF Software: AliEn PackMan (no torrent), stesse versioni presenti su Grid Accesso ai dati locali via xrootd Gestione dei dataset Monitoraggio web con MonALISA 3

4 AUTENTICAZIONE E SICUREZZA L utente ha accesso al solo PROOF master unica porta aperta: 1093/TCP (IANA) Autenticazione GSI proxy dal proprio certificato personale X.509 Token AliEn non necessario (a meno che non si legga da AliEn) proxy distribuito da PROOF su tutti i nodi e token creati al volo Il master gestisce più utenti, ognuno con uno username Unix configurazione nsswitch per usare LDAP ALICE localmente Comunicazioni client-proof master non cifrate handshake cifrato, ma comunicazioni successive più leggere 4

5 GESTIONE DEL SOFTWARE AliEn packman per la gestione dei pacchetti installazione di AliEn indipendente da quella della VO box Ogni nodo ha una copia locale del software TORRENT E CVMFS I torrent non sono supportati non è previsto di supportarli Possibile migrazione (feb-mar 2013) verso cvmfs probabile testbed su AAF 5

6 MODELLO DI STORAGE Modello dati: xrootd caching pool distribuito sugli stessi nodi di calcolo Virtual Mass Storage System un file è ottenuto da AliEn al volo se non è presente localmente Cache Mode xrootd cancella i file vecchi quando lo spazio sta per esaurirsi Scaricare i dati al volo può essere molto lento preferito staging asincrono attraverso il dataset stager (afdsmgrd) PROBLEMI CON XROOTD IN CACHE MODE Dati di ALICE molto ingombranti Su AF grande (CAF) non c è abbastanza spazio locale per tutti! xrootd cancella e scarica continuamente gli stessi dati! Su una AF piccola meglio disattivare gli automatismi! 6

7 I DATASET E LA GESTIONE DEI DATI Sono liste di file di ROOT contenenti tree Concepiti per esprimere un elenco di file in modo sintetico: esempio: /group/user/lhc10h_ _esds_p2 Dataset usati per gestire le richieste self-service di staging ogni utente può richiedere senza permessi lo staging asincrono di dati Official datasets User datasets PROBLEMI CON I DATASET Troppi dataset disponibili su CAF >4000 dataset, oltre metà creati da utenti! Attuale implementazione in ROOT non scalabile problemi di velocità nella scansione Informazioni dei dataset non sempre affidabili se i file sono cancellati i dataset non lo sanno Nuovo modello di dataset disponibile da febbraio da ROOT v (taggato a fine settimana) 7

8 MONITORING Monitoraggio centralizzato di tutte le AAF con MonALISA sia da web che da client Uno speciale agente leggero MonALISA (in Perl) installato su ogni nodo Alcune delle informazioni monitorate: numero di utenti connessi popolarità dei dataset spazio disponibile ed utilizzato sul pool locale 8

9 PROOF come appliance virtuale sulla cloud di Torino

10 UN ANNO DI CLOUD COMPUTING A TORINO La cloud del Tier-2 di Torino compie un anno in questi giorni Cloud locale basata su OpenNebula (attualmente v3.6) In un anno: migrazione dei worker nodes hypervisors per il number crunching migrazione graduale dei servizi hypervisors per la high availability NUMERI 31 ipervisori KVM 27 worker + 4 servizi Un OpenNebula master 2 storage server ridondanti con 10 GbE DALLA VIRTUAL ANALYSIS FACILITY ALLA CLOUD Dove prendere le risorse per PROOF in un Tier-2 Grid? 2008: prima che si parlasse di cloud si pensò alle macchine virtuali! Avere risorse elastiche per ALICE+PROOF ha motivato l adozione delle VM ora PROOF non è che un caso d uso particolare ( appliance ) della cloud 10

11 PECULIARITÀ RISPETTO ALLE AAF Setup AAF basato su script di installazione non adatto a noi altro insieme di script più semplici e più generici Obiettivo: esporre la stessa interfaccia AAF i.e.: in una macro d analisi, se scrivi TAF invece di CAF deve funzionare COSA C È DI DIVERSO? Manteniamo macchine virtuali leggere con dischi virtuali piccoli non possiamo avere tutto il software (anche centinaia di GB) su ciascuna VM Macchine virtuali aggiunte e tolte dinamicamente vogliamo che PROOF si accorga quando accendiamo o spegniamo una VM Le macchine sono usa e getta impossibile distribuire lo storage su di esse Configurazioni uniformi per Grid e PROOF vorremmo avere un solo tipo di macchina virtuale per entrambi i casi 11

12 GLUSTERFS Filesystem distribuito che scala orizzontalmente non un singolo master, ma comunicazione peer-to-peer tra i nodi Ha client nativi, ma espone un interfaccia POSIX con un driver FUSE il filesystem si monta senza modifiche né al kernel né alle applicazioni Modalità di funzionamento simili ad un RAID di alto livello distributed, striped, replicated (e combinazioni di esse) Ogni singolo server può servire tutti i dischi ottimo in caso di failover Eccellente facilità di gestione e manutenzione online aggiunta e rimozione dei brick, ribilanciamento 12

13 LA NOSTRA CONFIGURAZIONE DI GLUSTERFS GlusterFS già usato a Torino per tutta l infrastruttura cloud strumenti uniformi facilitano la gestione complessiva La parte cloud usa caratteristiche di replicazione e ridondanza La parte storage AAF utilizza solamente l aggregazione di dischi GlusterFS ottimo in manutenzione e accesso concorrente Esponiamo (solo all esterno) interfaccia xrootd per compatibilità AAF MB/s Test I/O bound fatto con PROOF worker PROOF 13 IL NOSTRO STORAGE 3 LUN da 17 TB 51 TB totali Un server frontend con interfaccia 10 GbE Picco di 600 MB/s tra accessi simultanei Plateau oltre i 95 worker

14 ELASTICITÀ E CONTESTUALIZZAZIONE PROOF da solo non gestisce l aggiunta e rimozione di nodi Con OpenNebula usiamo la contestualizzazione per decidere le sorti al boot un nodo diventa Grid oppure PROOF Uno script di configurazione aggiunge il nodo al PROOF master al boot lo stesso script toglie il nodo dalla lista allo spegnimento Stabilità e gestione automatica (il più possibile!) dei crash nodo depennato se non più accessibile, PROOF riavviato se crasha Grid WN Agnostic VM image PROOF contextualization Whatever 14

15 FACILITÀ DI GESTIONE COME FA L AMMINISTRATORE AD AGGIUNGERE UN NODO PROOF? Fa partire una macchina virtuale PROOF dall interfaccia di OpenNebula Nessuna altra operazione richiesta! il nuovo nodo sarà visibile da solo appena disponibile 15

16 CONFIGURAZIONE E MONITORING LOCALE Usiamo e riusiamo le nostre macchine virtuali il più possibile non spegniamo/riaccendiamo di continuo le VM Cambiamenti di configurazione locali possibili senza riavviare i nodi Puppet: sempre attivo e invocato al volo one-time in contestualizzazione Puppet ha bisogno di autenticare il nodo: procedura interattiva... abbiamo attivato l autosign (aggiunta non interattiva) per le VM! VM integrate nella nostra infrastruttura di monitoring locale preesistente Zabbix configurato con le regole di autodiscovery 16

17 DEPLOYMENT VELOCE DELLE IMMAGINI Macchine virtuali base grandi ~4 GB non sono pesantissime, ma se ne faccio partire 40 per volta? Le immagini base sono cachate su ogni singolo hypervisor lo script di distribuzione usa un modello torrent-like per copiarle! Stessa immagine usata per WN e PROOF contestualizzazione a tempo di boot L immagine non viene clonata snapshot qcow2 dalla copia cache locale TEMPO DI DEPLOYMENT Dalla richiesta al boot: meno di 15 secondi per una macchina! 40 macchine virtuali bootate in meno di 2 minuti! 17

18 ANALISI DI TEST: IPERNUCLEI Λ Codice analisi di Stefania Bufalino Obiettivo: ricerca di ipernuclei Λ (ipertritone e anti-ipertritone) in collisioni di ioni pesanti attraverso analisi di massa invariante Molto buono per testare le prestazioni dello storage Utilizza tantissima statistica (~20 TB da LHC10h: Pb-Pb, AOD073) Grande uso di CPU: PID selection Accesso all OADB per ottenere informazione di PID per ogni run Applicazione di numerosi tagli sulle tracce Cut topologico per migliorare il segnale Dati di output leggeri 80 istogrammi mono e bidimensionali TPC + ITS refit # TPC Cluster > 70 Chi2 / NDF < 4 eta cut zprimaryvertex < 5 cm 18

19 CONCLUSIONI E SVILUPPI FUTURI Esperienza d uso decisamente positiva Un servizio nuovo nel nostro centro di calcolo con appena pochi sforzi di manutenzione extra grazie alle macchine virtuali Risorse mai sprecate PROOF spento e convertite in Grid (sempre attive!) quando nessuno le usa Utenti molto felici di usare calcolo interattivo Si pensa di far diventare PROOF un appliance di CernVM per ALICE Torino sarà sito pilota del progetto 19