Post on 05-Apr-2020
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