A Prototype of a dynamically expandable Virtual Analysis ...personalpages.to.infn.it/~berzano/pub/VafThesis/... · Mean 1.559 RMS 0.3229 invmass [GeV/c2] 0.8 1 1.2 1.4 1.6 1.8 2 2.2

A Prototype ofa dynamically expandableVirtual Analysis Facility

for the ALICE Experiment

CandidatoDario Berzano

RelatoreProf. Massimo Masera

CorrelatoreDott. Stefano Bagnasco

Università degli Studi di Torino – INFN Sezione di Torino

Torino, 21 aprile 2009

Tesi Magistrale

Dario Berzano

IntroduzioneLa fisica di ALICE

Modelli di calcoloin LHC e ALICE

Risorse etecnologie richieste

Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

1/30

1 IntroduzioneLa fisica di ALICEModelli di calcolo in LHC e ALICERisorse e tecnologie richiesteVirtualizzazione

2 Prestazioni di XenColli di bottigliaPrestazioni di Xen su task paralleli di applicazioni reali

3 Il PrototipoCaratteristiche tecnicheModelli di accesso ai datiPrestazioni in casi d’uso realiRate di eventi e uso della CPU in diverse configurazioni

4 Caso d’uso realeStudio di un decadimento di open charmConfronto velocità PROOF vs. locale

5 Conclusioni

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

2/30

L’esperimento ALICE: un nuovo stato della materia

Quark Gluon PlasmaQCD ⇒ a 150÷180 MeV la materiaadronica transisce ad uno stato dove

quark e gluoni sono deconfinati

Interesse della QGP:Fisica delle particelle⇒ Test QCD non perturbativaCosmologia⇒ Big Bang, stelle di neutroni

Evoluzione spazio-temporale di unacollisione ione-ione

Densità elevate di energiain laboratorio ⇒ collisioniultrarelativistiche di ioni

ALICE (A Large Ion Collider Experiment) ⇒ unico esperimento di LHCspecificatamente dedicato alle collisioni di ioni

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

3/30

Il calcolo in ALICE

1.25 GiB/s incollisioni PbPb

≈ 5 PiB all’annosu nastro

≈ 1.5 PiB di datipermanentementedisponibili su disco

Potenza di calcolodi ≈ 25000 PC†

Necessità di distribuire dati e CPU ⇒ Grid

Ogni fisico ha a disposizione uguale accesso ai dati ed alle CPUSistema complesso e delocalizzato ma trasparente per il fisico

†ALICE Collaboration, J. Phys. G 30 (2004) 1517.

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

4/30

Grid e PROOF

Se si vuole eseguire un “job” sulla Grid, esso viene messo in una coda edeseguito non appena si trovano risorse libere ⇒ analisi non interattiva

Ci sono però calcoli che non sono adatti ad essere eseguiti sulla Grid:

Alcuni risultati devono essere ottenuti in tempi brevi⇒ Cambiare al volo parametri per ottimizzare tagli e calibrazioni

La durata dei calcoli è breve rispetto al tempo di attesa in coda⇒ Non vale la pena attendere che si liberino risorse sulla Grid

C’è bisogno di un’infrastruttura di analisi dati parallela e interattiva:

Parallela ⇒ per eseguire in tempi brevi il lavoro occorrono tante CPUche lavorino contemporaneamente

Interattiva ⇒ non ci sono code e si può “restare davanti allo schermo”mentre l’analisi è eseguita, intervenendo rapidamente sui parametri

Lo strumento per l’analisi parallela ed interattiva usato in ALICE è basatosul programma ROOT ed è denominato PROOF (Parallel ROOT Facility)

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

5/30

Il modello a “tier” della Grid di LHC

Nella Grid di LHC esistono due classi di centri di calcolo, o tier; è possibileritagliare risorse da essi per l’analisi interattiva solo quando servono?

Bisogna notare che:

La potenza di calcolo ha un costo elevatoNon ha senso dedicare calcolatori solo per l’analisi interattiva se poirestano inattivi per la maggior parte del tempo (ad es. di notte)

Tier-1Ricostruzione degli eventiElevato numero di CPU (≈ 1k):ne dedico staticamente qualcunaa PROOF (es. CERN)Man mano che i job Gridfiniscono assegno le CPU liberatea PROOF (approccio dinamico)

Tier-2Simulazioni Monte Carlo eanalisi finaleTroppe poche CPU (≈ 100) perdedicarle a PROOFRiavviare i nodi Grid comePROOF è lento (attendere lafine dei job: tmax ≈ 48 h)

Torino è un Tier-2 con queste necessità: l’approccio dinamico è la strada dapercorrere, ma occorre trovare una soluzione migliore

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

6/30

Risorse e tecnologie richieste

Quali sono le tecnologie e le risorse necessarie all’implementazione di unasiffatta infrastruttura?

1 Risorse di calcolo già esistenti⇒ i calcolatori di un Tier-2, come il centro di calcolo di Torino

2 Virtualizzazione⇒ più calcolatori virtuali indipendenti su ogni calcolatore ordinario

3 Strumento per l’analisi parallela ed interattiva⇒ PROOF

4 Capacità di fornire risorse all’analisi interattiva su richiesta⇒ alcuni strumenti di virtualizzazione sono in grado di farlo

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

7/30

Virtualizzazione completa e paravirtualizzazione

La virtualizzazione è un modo per far vedere ai sistemi operativi e aiprogrammi risorse hardware virtuali, ovvero non esistenti fisicamente

In concreto, attraverso la virtualizzazione è possibile:

Eseguire sulla stessa macchina fisica più macchine virtuali (VM)completamente indipendenti e isolateControllare e limitare l’accesso alle risorse fisicheEmulare architetture differenti da quella della macchina fisica

Il sistema che coordina l’accesso alle risorse fisiche da parte delle VM,stabilendone le priorità d’accesso, è detto ipervisore (hypervisor)

Virtualizzazione completa

Emulazione di ogni architetturaSistema operativo della VM nonmodificatoPerdita di prestazioni (speciesenza accelerazione hardware)

Paravirtualizzazione

Architettura vista “direttamente”Kernel ospite modificato ⇒ è“conscio” di essere virtualeLimitata perdita di prestazioni ⇒occorrerà valutare dove

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

8/30

Un centro di calcolo virtuale con Xen

Xen è il nome di un ipervisore open source e gratuito in grado di assegnaredinamicamente risorse alle macchine virtuali

Xen gestisce tutti i processi ⇒global accounting

Uso di CPU variabile a runtime{cap ⇒ num. max di CPUweight ⇒ priorità relativa

Xen può variare anche lamemoria con le VM accese

Togliendo risorse ai nodi Grid ijob rallentano (swap ⇒ discousato come memoria) senza fallire

Indipendenza delle VM ⇒problemi e perdite di prestazionidi una VM non influenzano l’altra

Facility staticaLe macchine fisiche sono

soltanto worker node (WN)della Grid

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

8/30








Facility virtuale dinamicaOgni macchina fisica contiene sia

un nodo Grid che un nodo PROOF,con risorse variabili su richiesta

Tesi Magistrale

Dario Berzano




Virtualizzazione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

8/30








Facility virtuale dinamicaOgni macchina fisica contiene sia

un nodo Grid che un nodo PROOF,con risorse variabili su richiesta

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi XenColli di bottiglia

Prestazioni di Xensu task paralleli diapplicazioni reali

Il Prototipo

Caso d’usoreale

Conclusioni

9/30





5 Conclusioni

Tesi Magistrale

Dario Berzano

Introduzione



Il Prototipo

Caso d’usoreale

Conclusioni

10/30

Generalità dei test di fattibilità

Occorre fare dei test che:

analizzino ogni potenziale collo di bottiglia di Xen singolarmentesiano scalabili, ovvero in grado di trarre vantaggio dalla divisione in piùthread paralleli ⇒ la differenza di prestazioni tra VM e nodo fisico èsensibile al variare del numero di processi paralleli?

Programma che risponde ai requisiti: sysbench ⇒ semplice e scalabile

CPUTest di primalità sui numeri da 1 a 20000 (task parallelizzabile)

Memoria RAMNumero variabile di processi concorrenti che scrivono in tutto 5 GiB

Lettura e scrittura di file10 processi leggono e scrivono 5 GiB (divisi in 128 file da 40 MiB l’uno)Diverse misurazioni ⇒ media (prima lettura scartata per la cache)

Tesi Magistrale

Dario Berzano

Introduzione



Il Prototipo

Caso d’usoreale

Conclusioni

11/30

Risultati dei test di fattibilità

# of parallel threads0 2 4 6 8 10

real

tim

e [s

]

10

20

30

40

50

60paravirtualizedphysical

CPU benchmark

# of parallel threads0 2 4 6 8 10

real

tim

e [s

]

6

810

1214

1618

20 paravirtualizedphysical

Memory benchmark

time

[s]

020406080

100120140160

File I/O benchmark

readwrite

physical virtual remote

La paravirtualizzazione non è emulazione⇒ non vi è davvero, come atteso, laminima perdita di prestazioni di CPULa memoria è fino al ∼ 40% più lenta⇒ ma il collo di bottiglia delle nostreanalisi è la CPU, non la memoriaLettura e scrittura su disco sono lente⇒ ma vogliamo leggere i nostri dati dallarete e non dai dischi localiLo swap può essere un problema⇒ si isola la perdita di prestazioniseparando fisicamente il disco del nodoGrid dal disco del nodo PROOF

Tesi Magistrale

Dario Berzano

Introduzione



Il Prototipo

Caso d’usoreale

Conclusioni

12/30

Confronto virtuale/reale con Geant4

Simulazione† realizzata con Geant4 di perdita di energia di ioni 12C intessuti umani: 200k eventi (25k eventi paralleli su 8 core)

Macchina reale

# [hr.min.s]1 29.00.492 28.26.543 28.03.404 29.09.335 28.50.466 28.19.007 28.40.188 29.20.41

avg 28.43.58std 00.26.25

Macchina virtuale

# [hr.min.s]1 28.35.392 28.41.023 28.03.574 28.27.225 28.39.336 28.06.077 28.40.538 28.31.05

avg 28.28.12std 00.15.06

∆ < 1% ⇒ nessuna perdita di prestazioni per la macchina virtuale

†Simulazione di Andrea Attili e Faiza Bourhaleb.

Tesi Magistrale

Dario Berzano

Introduzione



Il Prototipo

Caso d’usoreale

Conclusioni

13/30

VM in configurazione dinamica con AliRoot/1

Generazione di eventi pp con AliRoot lanciate ripetutamente in parallelo su4 core variando l’assegnazione delle risorse ogni 2 ore

3.5 GiB ? 4 core256 MiB ? 1/2 core

}2x Ù

1.75 GiB ? 3 core512 MiB ? 2 core

}2x

running time [hours]0 2 4 6 8 10 12 14 16

even

t tim

e [s

]

200

400

600

800

1000

1200

1400

1600

1800

2000

Event time

2 hours

Durata media degli eventi terminati in un certo intervallo di tempo (bin): lagenerazione rallenta con il diminuire delle risorse, ma non fallisce

Tesi Magistrale

Dario Berzano

Introduzione



Il Prototipo

Caso d’usoreale

Conclusioni

14/30

VM in configurazione dinamica con AliRoot/2

Quanto tempo impiega Xen a trasferire le risorse da una macchina virtualead un’altra? È possibile poter richiedere risorse in tempo “quasi” reale?

running time [s]7050 7100 7150 7200 7250 7300 7350 7400 7450

mem

ory

[GiB

]

0.5

1

1.5

2

2.5

3

3.5

total RAM

used RAMused swap

Memory

1min 34s

Il tempo di trasferimento delle risorse a pieno carico è ≈ 1.5 min ⇒ più cheaccettabile per un trasferimento su richiesta dell’utente

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il PrototipoCaratteristichetecniche

Modelli di accessoai dati

Prestazioni in casid’uso reali

Rate di eventi euso della CPU indiverse configuraz.

Caso d’usoreale

Conclusioni

15/30





5 Conclusioni

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

16/30

Caratteristiche tecniche del Prototipo: l’hardware

Le macchineQuattro macchine con 8 core ciascuna (2 Quad-Core)Un nodo multiuso con diversi servizi (PROOF master, interfaccia dimonitoring e controllo, area condivisa con il software di ALICE)8 GiB RAM su tre macchine, 16 GiB su una macchinaSei slot per dischi “piccoli” di cui due utilizzati indipendentemente peril problema dello swap

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

17/30

Caratteristiche tecniche del Prototipo: il software

Configurazione attuale della facility

Su ogni macchina:

{nodo PROOF virtualenodo Grid virtuale (attivi da dicembre)

Programma per cambiare le risorse su tutti i nodi contemporaneamenteUn programma (Cobbler) per facilitare le installazioni “di massa”Autenticazione con certificato (x509) per PROOF ⇒ stesso grado disicurezza della GridApplicazione web per il monitoraggio della facility

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

18/30

Confronto tra diversi modelli di accesso ai dati per PROOF

Definizioni:

SE (Storage Element): in ogni sito Grid è l’area dove vengonoconservati i dati a cui accedono tutti i WN e gli utentiPROOF pool: i dati sono distribuiti sugli stessi host che eseguonol’analisi, visto come un’unica unità di dischi aggregati (“pool”)

Dischi in “pool”

Ora in uso nel Prototipo e alCERN (CAF)Trasferimenti di rete ridotti ⇒job vicino ai dati, non viceversaIn un Tier-2: nodi con pochi slotper dischi piccoli ⇒ spazio nonsufficiente

Accesso diretto allo SE locale

Come i WN della GridNecessita di autenticazione concertificato Grid ⇒ già presente,ma finora mai testato su PROOFUnico SE condiviso per Grid ePROOF ⇒ manutenzione piùfacile per un Tier-2

Lo SE condiviso è la strada da percorrere: tuttavia, con l’attuale topologiadi rete lo SE di Torino non è ancora visibile in modo efficiente ai nodi

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

19/30

Generalità dei test eseguiti sul Prototipo

Test eseguiti sui nodi Grid

Due tipi di test:

{job speciali che usano solo la CPUveri job (principalmente di ALICE) su Grid

Il numero di job che falliscono sui nodi virtuali è più alto della media?

Test eseguiti sui nodi PROOFUna analisi è lanciata utilizzando tutti i 32 worker a disposizione200 file di ROOT da analizzare, uniformemente distribuiti sullemacchine (esattamente 50 file su ognuna)Il numero di eventi analizzati al secondo è misurato tre volte e mediato

I test con i job reali sono stati eseguiti su due macchine perché al tempo deltest soltanto due nodi virtuali erano in produzione nella Grid

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

19/30

Generalità dei test eseguiti sul Prototipo

Test eseguiti sui nodi Grid

Due tipi di test:

{job speciali che usano solo la CPUveri job (principalmente di ALICE) su Grid

Il numero di job che falliscono sui nodi virtuali è più alto della media?

Test eseguiti sui nodi PROOFUna analisi è lanciata utilizzando tutti i 16 worker a disposizione100 file di ROOT da analizzare, uniformemente distribuiti sullemacchine (esattamente 50 file su ognuna)Il numero di eventi analizzati al secondo è misurato tre volte e mediato

I test con i job reali sono stati eseguiti su due macchine perché al tempo deltest soltanto due nodi virtuali erano in produzione nella Grid

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

20/30

Scalabilità di PROOF

# workers/node1 2 3 4 5 6 7 8

even

t ra

te [

even

ts/s

]

5000

10000

15000

20000

25000

30000

35000

40000

45000

PROOF scaling

PROOF si adatta ad un numero crescente di nodi: la velocità di esecuzioneaumenta linearmente fino al massimo di un worker per ogni core

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

21/30

Test con carico di lavoro simulato sui nodi Grid

rela

tive

even

t rat

e

0

0.2

0.4

0.6

0.8

1

PROOF

WN

PROOF/WN event rate comparison

same resourcesallocation

PROOF mode:WN is shrunk

reference rate:PROOF/WN alone

Con carico di lavoro sul WN Grid ⇒ velocità di poco inferiore al massimo possibileXen è preciso nell’assegnare le risorse come richiesto

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

21/30

Test con carico di lavoro simulato sui nodi Grid

rela

tive

even

t rat

e

0

0.2

0.4

0.6

0.8

1

PROOF

WN

PROOF/WN event rate comparison




Con carico di lavoro sul WN Grid ⇒ velocità di poco inferiore al massimo possibileXen è preciso nell’assegnare le risorse come richiesto

Ù

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

22/30

Test con job reali sui nodi Grid in produzione

rela

tive

even

t rat

e

0

0.2

0.4

0.6

0.8

1

PROOF event rate




Stesse velocità, anche se rispetto a prima il nodo Grid usa intensivamente lo swapXen e dischi separati garantiscono notevole isolamento delle prestazioni delle VM

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

22/30

Test con job reali sui nodi Grid in produzione

rela

tive

even

t rat

e

0

0.2

0.4

0.6

0.8

1

PROOF event rate




Stesse velocità, anche se rispetto a prima il nodo Grid usa intensivamente lo swapXen e dischi separati garantiscono notevole isolamento delle prestazioni delle VM

Ù

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen





Caso d’usoreale

Conclusioni

23/30

Utilizzo della CPU da parte dei soli job di ALICE sulla Grid

time [hours]0 10 20 30 40 50 60

CP

U e

ffic

ien

cy

0

0.2

0.4

0.6

0.8

1

1.2

WN CPU efficiency

mem=~7 GiBcap=800%

mem=~3.7 GiBcap=800%

mem=~512 MiBcap=100%

Man mano che aumenta l’uso dello swap il collo di bottiglia diventa l’accesso al discoNon ci sono più fallimenti della media ⇒ solo rallentamenti, ma è OK

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo

Caso d’usorealeStudio di undecadimento diopen charm

Confronto velocitàPROOF vs. locale

Conclusioni

24/30





5 Conclusioni

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo



Conclusioni

25/30

Ricostruzione di un decadimento di open charm

D+ → K−π+π+

La ricostruzione richiede calcolo parallelo edinterattività: si usano le informazioni didetector del barile centrale (TOF, TPC, ITS):

Costruzione di tutte le possibili triplettedi tracce con un grande parametrod’impatto e corretta combinazione dicariche

Identificazione delle particelle eseguitasui prodotti di decadimento

Ricostruzione del vertice secondario⇒ distanza di minimo approccio (DCA)

Controllo del corretto puntamento del−→p della D+ verso il vertice primario

Analisi della massa invariante dei candidati

Event display: TPC

Event display: ITS

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo



Conclusioni

26/30

Analisi della massa invariante dei candidati

L’analisi – finora provata solo su Grid e localmente – è stata adattata perl’esecuzione sulla facility virtuale con PROOF ⇒ 105 eventi analizzati

invmass1Entries 5505Mean 1.559RMS 0.3229

]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

20

40

60

80

100

120


invariant mass (cut 1)ππ k→+D

Tagli meno stringentiPicco della D+ appena visibile


]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

5

10

15

20

25



Tagli più selettiviPicco della D+ più evidente

MD+ = 1869.62 MeV /c2

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo



Conclusioni

27/30

Confronto dei candidati con il picco di riferimento


]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

20

40

60

80

100

120




]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

5

10

15

20

25



Massa invariante di D+ → K−π+π+ dopola sottrazione del fondo ottenuta da uncampione di 6 milioni di eventi simulati

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo



Conclusioni

28/30

Tempo richiesto per l’analisi con PROOF vs. locale


]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

20

40

60

80

100

120




]2invmass [GeV/c0.8 1 1.2 1.4 1.6 1.8 2 2.2

0

5

10

15

20

25



Durata della ricostruzione

PROOF 20min 21sLocal 10hr 27minRun time [s] Error [s] Error [%] Rate [evt/s]

PROOF

Local

1221,0 79,2

37620,0 2,6

# events

# files

96700

967

How much is PROOF faster? 30,8

0

16,0

32,0

48,0

64,0

80,0

Rate [evt/s]

PROOFLocal

Sulla facility virtuale l’analisi è 31 volte piùrapida ⇒ più facile testare ripetutamente i

tagli per la selezione dei candidati

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

29/30





5 Conclusioni

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

30/30

Conclusioni

Risultati disponibili ad oggi

La fattibilità è stata provataTest specifici e test su casi d’uso realievidenziano la fattibilità dell’approccio Xen

Nodi Grid già attiviI nodi Grid della facility virtuale sono giàoperativi e lavorano con i “vecchi” nodi Grid

Infrastruttura facilmente espandibileLa facility (dall’installazione del software agliscript di controllo) è stata pensata in mododa rendere facile l’aggiunta di macchine

Estesa documentazioneÈ mantenuto un wiki con i risultati del lavorosvolto, lo stato della facility e le istruzioni perusarla

Sicurezza equivalente a GridGli utenti si possono connettere con lo stessocertificato usato per Grid e sarà anchepossibile accedere ai dati via nome AliEn

Parallelizzazione di un’analisiUn’analisi intensiva, finora eseguibile sololocalmente e su Grid, è stata adattata perPROOF con prestazioni migliori

Da realizzare in futuro per la facility

Migliore allocazione delle risorseL’assegnazione dinamica quando l’utente siconnette a PROOF è stata dimostrata esserefattibile ⇒ trasparente per il fisico e variabilea seconda degli utenti connessi

Accesso ai dati da SE locale via AliEnÈ richiesto un canale diretto con lo storageelement e sono necessarie modifiche al codicedi PROOF per permettere l’accesso ai datiattraverso il loro nome AliEn

Tesi Magistrale

Dario Berzano

Introduzione

Prestazionidi Xen

Il Prototipo

Caso d’usoreale

Conclusioni

30/30

Conclusioni

Risultati disponibili ad oggi

La fattibilità è stata provataTest specifici e test su casi d’uso realievidenziano la fattibilità dell’approccio Xen

Nodi Grid già attiviI nodi Grid della facility virtuale sono giàoperativi e lavorano con i “vecchi” nodi Grid

Infrastruttura facilmente espandibileLa facility (dall’installazione del software agliscript di controllo) è stata pensata in mododa rendere facile l’aggiunta di macchine

Estesa documentazioneÈ mantenuto un wiki con i risultati del lavorosvolto, lo stato della facility e le istruzioni perusarla

Sicurezza equivalente a GridGli utenti si possono connettere con lo stessocertificato usato per Grid e sarà anchepossibile accedere ai dati via nome AliEn

Parallelizzazione di un’analisiUn’analisi intensiva, finora eseguibile sololocalmente e su Grid, è stata adattata perPROOF con prestazioni migliori

Da realizzare in futuro per la facility

Migliore allocazione delle risorseL’assegnazione dinamica quando l’utente siconnette a PROOF è stata dimostrata esserefattibile ⇒ trasparente per il fisico e variabilea seconda degli utenti connessi

Accesso ai dati da SE locale via AliEnÈ richiesto un canale diretto con lo storageelement e sono necessarie modifiche al codicedi PROOF per permettere l’accesso ai datiattraverso il loro nome AliEn

Documents

A Prototype of a dynamically expandable Virtual Analysis ...personalpages.to.infn.it/~berzano/pub/VafThesis/... · Mean 1.559 RMS 0.3229 invmass [GeV/c2] 0.8 1 1.2 1.4 1.6 1.8 2 2.2