L’ANALYSIS FACILITY VIRTUALE DI TORINODario Berzano (CERN, INFN & Università di Torino),

Stefano Bagnasco, Riccardo Brunetti, Stefano Lusso (INFN)

Workshop dei Tier-2 Italiani di ALICE - Catania, 20 dic 2012

L’esperienza PROOF di ALICE

LE ANALYSIS FACILITIES PROOF DI ALICE

3

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

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

http://aaf.cern.ch

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

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

5

TORRENT E CVMFS

• I torrent non sono supportati→ non è previsto di supportarli

• Possibile migrazione (feb-mar 2013) verso cvmfs→ probabile testbed su AAF

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)

6

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!

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_000123456_ESDs_p2

• Dataset usati per gestire le richieste self-service di staging→ ogni utente può richiedere senza permessi lo staging asincrono di dati

7

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 v5-34-04 (taggato a fine settimana)

1.7022.745

Official datasetsUser datasets

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

http://bit.ly/aliceproof

PROOF come appliance virtualesulla cloud di Torino

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

10

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

NUMERI

• 31 ipervisori KVM→ 27 worker + 4 servizi

• Un OpenNebula master• 2 storage server ridondanti

con 10 GbE

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

11

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

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

http://www.gluster.org

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

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 80-90

accessi simultanei• Plateau oltre i 95 worker

worker PROOF

MB/

s

Test I/O bound fatto con PROOF

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

14

Agnostic VM image

Grid WN

PROOF

Whatevercontextualization

FACILITÀ DI GESTIONE

15

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

2

1

3 4

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

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

17

TEMPO DI DEPLOYMENT

• Dalla richiesta al boot: meno di 15 secondi per una macchina!• 40 macchine virtuali bootate in meno di 2 minuti!

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

18

TPC + ITS refit# TPC Cluster > 70Chi2 / NDF < 4eta cut|zPrimaryVertex| < 5 cm

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