Università degli Studi di Perugia
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
Tesi di Laurea
Sviluppo di procedure per
l’automatizzazione del flusso di
lavoro per l’analisi dati distribuita
in Grid nell’esperimento CMS
Candidato
Mattia Cinquilli
Relatore
Prof. Leonello Servoli
Correlatore
Dott. Daniele Spiga
ii
Indice
Introduzione
1
1 Grid
5
1.1
Introduzione a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2
Grid computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.1
Definizione di Grid . . . . . . . . . . . . . . . . . . . . . . . . .
8
Architettura Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.3.1
Livelli architetturali . . . . . . . . . . . . . . . . . . . . . . . .
10
Grid di produzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.3
1.4
1.4.1
zioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Da Grid a cloud computing . . . . . . . . . . . . . . . . . . . .
14
Architettura WLCG/EGEE . . . . . . . . . . . . . . . . . . . . . . . .
15
1.5.1
Utenti e VO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.5.2
Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.5.3
Elementi principali del middleware . . . . . . . . . . . . . . . .
17
1.5.4
Job flow: sottomissione . . . . . . . . . . . . . . . . . . . . . .
19
1.5.5
MAGIC-5: un caso d’uso della Grid . . . . . . . . . . . . . . .
20
1.4.2
1.5
1.6
Sostenibilità dell’infrastruttura Grid: dallo sviluppo alle opera-
Flussi di lavoro complessi in ambienti distribuiti
. . . . . . . . . . . .
2 Client-server computing
2.1
2.2
21
23
Definizione di client-server computing . . . . . . . . . . . . . . . . . .
23
2.1.1
Un server per ogni client . . . . . . . . . . . . . . . . . . . . . .
24
2.1.2
Caratterizzazione . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.1.3
Funzioni del client . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.1.4
Funzioni del server . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.1.5
Modelli strutturali . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.1.6
Integrazione con il calcolo distribuito . . . . . . . . . . . . . . .
30
Classificazione dei sistemi client-server in base alla topologia . . . . . .
31
iv
2.3
2.4
2.5
2.6
2.2.1
Modello a due livelli (two-tiers) . . . . . . . . . . . . . . . . . .
31
2.2.2
Modello a tre livelli (three-tiers) . . . . . . . . . . . . . . . . .
32
2.2.3
Modello a N livelli (N-tiers) . . . . . . . . . . . . . . . . . . . .
36
Client-server: vantaggi e svantaggi . . . . . . . . . . . . . . . . . . . .
37
2.3.1
Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
2.3.2
Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Sviluppo di un sistema client-server . . . . . . . . . . . . . . . . . . . .
40
2.4.1
Strumenti di sviluppo . . . . . . . . . . . . . . . . . . . . . . .
40
Software Development Life Cycle . . . . . . . . . . . . . . . . . . . . .
41
2.5.1
Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.5.2
Definizione dei requisiti . . . . . . . . . . . . . . . . . . . . . .
42
2.5.3
Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.5.4
Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.5.5
Integrazione e test . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.5.6
Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Client-server: sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.6.1
Le minacce di sicurezza emergenti . . . . . . . . . . . . . . . .
45
2.6.2
Server: possibili minacce . . . . . . . . . . . . . . . . . . . . . .
45
3 LHC e CMS
47
3.1
LHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.2
CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.2.1
L’ambiente computazionale di CMS . . . . . . . . . . . . . . .
50
3.2.2
Framework dell’analisi distribuita in CMS . . . . . . . . . . . .
51
4 CRAB: evoluzione verso un’architettura client-server
4.1
Motivazioni dell’evoluzione
4.2
Client-server: fattorizzazione del flusso di lavoro
4.3
Strategia implementativa
4.4
4.5
. . . . . . . . . . . . . . . . . . . . . . . .
63
. . . . . . . . . . . . . . . . . . . . . . . . .
65
Architettura del server . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.4.1
Classificazione logica delle componenti . . . . . . . . . . . . . .
70
4.4.2
Descrizione agenti di input/output . . . . . . . . . . . . . . . .
74
4.4.3
Descrizione agenti di logica e di gestione . . . . . . . . . . . . .
75
4.4.4
Descrizione agenti per l’interazione con la Grid . . . . . . . . .
77
Interfaccia al middleware ed ai sistemi di batch: BossLite . . . . . . .
80
Richieste degli utenti: task
83
. . . . . . . . . . . . . . . . . . . . . . . .
83
Task e job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Componente per l’aggregazione delle informazioni sui task . . . . . . .
85
5.1.1
5.2
59
. . . . . . . . . . . .
5 Implementazione dei componenti di gestione dei task
5.1
59
v
5.2.1
5.3
5.4
TaskTracking: architettura . . . . . . . . . . . . . . . . . . . .
89
Componente per la gestione del ciclo di vita dei task . . . . . . . . . .
95
5.3.1
TaskLifeManager: architettura . . . . . . . . . . . . . . . . . .
97
Supporto per l’interazione trasparente con Storage Element . . . . . .
99
5.4.1
SEAPI: architettura . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.2
SEAPI: funzionamento . . . . . . . . . . . . . . . . . . . . . . . 101
6 Risultati
105
6.1
Dalla fase di test alle operazioni in produzione . . . . . . . . . . . . . 105
6.2
Test di scala del server . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3
6.2.1
Fase con un solo utente . . . . . . . . . . . . . . . . . . . . . . 107
6.2.2
Fase multiutente . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Utilizzo del server di CRAB in produzione . . . . . . . . . . . . . . . . 109
6.3.1
Valutazione dell’efficienza dei job . . . . . . . . . . . . . . . . . 110
Conclusioni
115
Ringraziamenti
117
Bibliografia
119
vi
Elenco delle figure
1.1
I tre macro livelli architetturali di una griglia computazionale. . . . . .
10
1.2
Autentificazione nella Grid. . . . . . . . . . . . . . . . . . . . . . . . .
17
1.3
Elementi della Grid WLCG/EGEE. . . . . . . . . . . . . . . . . . . .
18
1.4
Job Flow nella Grid WLCG/EGEE. . . . . . . . . . . . . . . . . . . .
19
2.1
Topologia client-server con un server per un unico client. . . . . . . . .
29
2.2
Topologia client-server con un solo server per client multipli. . . . . . .
29
2.3
Topologia client-server con più server e più client. . . . . . . . . . . . .
30
2.4
Modello client-server su due livelli. . . . . . . . . . . . . . . . . . . . .
31
2.5
Modello client-server su tre livelli.
. . . . . . . . . . . . . . . . . . . .
33
2.6
Modello client-server su N livelli. . . . . . . . . . . . . . . . . . . . . .
37
2.7
SDLC: fasi base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.1
Il progetto LHC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.2
Struttura del rivelatore CMS. . . . . . . . . . . . . . . . . . . . . . . .
49
3.3
Il modello computazionale di CMS: l’architettura su livelli. . . . . . .
51
3.4
Velocità dei trasferimenti di PhEDEx dal 2004 al 2008. . . . . . . . . .
55
3.5
CRAB workflow. WMS può essere inteso sia come gLite WMS che come
glidein WMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.1
CRAB: flusso di lavoro e interazioni. . . . . . . . . . . . . . . . . . . .
61
4.2
L’aggiunta di un nuovo livello fra la Grid e l’utente. . . . . . . . . . .
62
4.3
CRAB: flusso di lavoro e interazioni con l’introduzione del server. . . .
64
4.4
Schema SQL del supporto per la gestione del Message Service. . . . .
67
4.5
Vista schematica dell’architettura del server di CRAB. . . . . . . . . .
72
4.6
Job per sito sottomessi dal 20 Novembre 2009 al 28 Dicembre 2009.
Grafico prelevato dall’HTTPFrontend del server di analisi di Legnaro.
76
4.7
Implementazione con un pool di thread della componente JobTracking.
79
4.8
Schema UML della componente GetOutput. . . . . . . . . . . . . . . .
80
4.9
Vista schematica dell’architettura di BossLite. . . . . . . . . . . . . . .
82
viii
5.1
Architettura e componenti del server di CRAB; in rosso sono evidenziati
gli agenti dedicati alla gestione dei task e le frecce relative all’interazione
con lo Storage Element attraverso le SEAPI.
5.2
. . . . . . . . . . . . . .
85
Schema delle interazioni della TaskTracking con le altre componenti del
server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.3
Diagramma delle classi degli oggetti della TaskTracking costruito con
la specifica UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.4
Schema del funzionamento dei thread e della coda dei task. . . . . . .
93
5.5
Diagramma delle classi degli oggetti della TaskLifeManager costruito
con la specifica UML. . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.6
Principali componenti logiche delle SEAPI. . . . . . . . . . . . . . . . 102
5.7
Diagramma delle classi degli oggetti delle SEAPI costruito con la specifica UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.8
Schema di un caso d’uso delle SEAPI nel caso di un tasferimento da
uno Storage Element ad un altro. . . . . . . . . . . . . . . . . . . . . . 103
6.1
Distribuzione per stato dei job sottomessi attraverso il server di CRAB
sul middleware gLite durante la fase di test di sottomissioni controllate
con singolo utente. Informazioni prelavate dai dati contenuti nella base
di dati del server, attraverso l’HTTPFrontend (cap. 4). . . . . . . . . . 108
6.2
Utilizzo percentuale della CPU (scala verticale) distribuito nel tempo
(scala orizzontale) da parte del server MySQL (sorgente: HTTPFrontend ). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3
Distribuzione per stato dei job sottomessi al server durante la fase di
test multiutente (sorgente: HTTPFrontend ). . . . . . . . . . . . . . . 110
6.4
Distribuzione giornaliera del numeri di utenti diversi che hanno utilizzato i server di CRAB a partire da Gennaio 2009 fino a metà Gennatio
2010. Grafico generato tramite le informazioni messe a disposizione
dalla Dashboard (cap. 3). . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.5
Distribuzione dei job sottomessi tramite i server di CRAB fra i siti della
collaborazione CMS (sorgente: Dashboard ). . . . . . . . . . . . . . . . 112
6.6
Distribuzione della frazione giornaliera di jobs terminati con successo
durante tutto l’anno 2009 (sorgente: Dashboard ). . . . . . . . . . . . . 113
6.7
Distribuzione giornaliera della percentuale di jobs terminati con stato
Abort durante tutto l’anno 2009 (sorgente: Dashboard ). . . . . . . . . 113
Introduzione
Una Griglia Computazionale è un ambiente sviluppato per il calcolo distribuito che
consente la condivisione, selezione e aggregazione di risorse autonome geograficamente
distribuite utilizzate a tempo di esecuzione, a seconda della loro disponibilità, capacità e prestazioni. La crescente domanda di risorse di calcolo nel mondo moderno ha
portato dagli anni ’50 ad oggi all’incremento esponenziale della potenza di calcolo.
Dalla costruzione dei primi Supercomputer che concentravano tutta la potenza in unico sistema, si è arrivati all’unione delle risorse di piú computer collegati su di una rete
locale, cioé il Cluster Computing. Successivamente, l’idea che il potenziale generato
da un sistema di computer in cluster connessi fra loro fosse sufficiente per soddisfare
le richieste delle applicazioni più onerose, portò l’esigenza di andare oltre quella che
era stata la comune struttura di un sistema di calcolo. Quindi vennero create le prime
griglie computazionali. Attualmente esistono molteplici implementazioni di questo paradigma con casi d’uso che vanno dalla ricerca di nuove terapie di cura delle malattie
(come l’Alzheimer e l’AIDS) , fino ai servizi finanziari . Fra gli utilizzatori della griglia
computazionale vi sono anche gli esperimenti di fisica delle alte energie in funzione al
Large Hadron Collider (LHC) del CERN a Ginevra, che hanno individuato in questa
tecnologia le potenzialità in grado di soddisfare le proprie esigenze computazionali.
Il Compact Muon Solenoid (CMS) è uno dei 4 esperimenti di LHC che ha progettato
il modello di calcolo sul paradigma di Grid. A regime il rilevatore CMS sarà in grado
di acquisire una quantità di dati annua pari a 1 PB. Il processamento e quindi l’analisi
di questa mole di dati richiede una quantità di risorse di calcolo e di memorizzazione
senza precedenti. La griglia computazionale fornisce la risposta a queste esigenze,
garantendo inoltre ad ogni utente della vasta collaborazione la possibilità di accesso
ai dati distribuiti in Grid. CMS nel corso degli anni ha quindi sviluppato delle applicazioni basate su sitemi Grid che possono essere classificate in due categorie: quelle
necessarie alla gestione dei dati e quelle necessarie alla gestione dei flussi di lavoro per
il relativo processamento.
Lo scopo di questo lavoro di tesi è la progettazione e lo sviluppo di componenti fondamentali di un sistema basato su architettura client/server, specializzato nella gestione
2
del flusso di lavoro dell’analisi dati distribuita, tale che rappresenti una piattaforma
per il supporto di flussi complessi quali quelli concatenati, tipici di alcuni casi d’uso di
un esperimento di fisica delle alte energie (calibrazione ed allineamento del rivelatore
di particelle elementari).
Il modello di calcolo di CMS prevede tre livelli computazionali (detti Tier) organizzati
gerarchicamente. Dopo una prima fase di processamento cha avviene al Tier-0 del
CERN, i dati sono spediti ai Tier-1. Questi ultimi devono garantirne la custodia e la
potenza di calcolo per i successivi riprocessamenti. I dati vengono infine resi disponibili ai Tier-2, centri di calcolo di dimensioni inferiori ai Tier-1, responsabili per il
supporto di tutte le attività di analisi dell’utente. Secondo questo schema computazionale i fisici della collaborazione CMS sono obbligati ad interagire con il complesso
ambiente distribuito di Grid. Tale aspetto può essere piuttosto complicato soprattutto
per utenti di fisica, storicamente più interessati ai risultati dell’analisi piuttosto che
agli aspetti tecnici del sistema di calcolo. Il miglior modo di soddisfare tali esigenze è
quello di incapsulare l’utente finale in un ambiente protetto, da cui la scelta di disegnare un’applicazione basata all’architettura client/server.
La presentazione del lavoro di tesi si articola in 6 capitoli.
Nel primo viene data una descrizione della griglia computazionale come infrastruttura
di calcolo distribuito, della sua architettura, delle implementazioni più importanti e
delle varie fasi del flusso di lavoro.
Nel secondo viene descritta la teoria del client/server computing illustrandone l’architettura e le varie topologie d’implementazione, descrivendo in particolar modo i
vantaggi e gli svantaggi del suo utilizzo.
Nel terzo viene fatto un quadro dell’esperimento CMS da un punto di vista prettamente computazionale, descrivendo quindi: i servizi e le applicazioni specifiche per la
gestione dei dati, del software per l’analisi dei dati e le applicazioni d’interfaccia alla
griglia computazionale.
Negli ultimi tre capitoli si illustra la parte originale del lavoro di tesi.
In particolare nel capito quattro vengono descritte in dettaglio le motivazioni per la
scelta di un’applicazione client/server, la strategia e l’architettura utilizzata.
Il quinto capitolo presenta i dettagli dello sviluppo di due componenti del server (TaskTracking e TaskLifeManager) e delle librerie necessarie ad interagire con i servizi di
memorizzazione della griglia.
Infine nel sesto capitolo vengono presentati i risultati ottenuti durate un intero anno
di attività.
“C’è tanta gente infelice che tuttavia non prende l’iniziativa di cambiare la propria
situazione perché è condizionata dalla sicurezza, dal conformismo, dal
tradizionalismo, tutte cose che sembrano assicurare la pace dello spirito, ma in realtà
per l’animo avventuroso di un uomo non esiste nulla di più devastante di un futuro
certo. Il vero nucleo dello spirito vitale di una persona è la passione per l’avventura.
La gioia di vivere deriva dall’incontro con nuove esperienze, e quindi non esiste gioia
più grande dell’avere un orizzonte in continuo cambiamento, del trovarsi ogni giorno
sotto un sole nuovo e diverso. Se vuoi avere di più dalla vita, devi liberarti dalla tua
inclinazione alla sicurezza monotona e adottare uno stile più movimentato che al
principio ti sembrarà folle, ma non appena ti ci sarai abituato, ne assaporerai il
pieno significato e l’incredibile bellezza.”
Chris McCandless
4
Capitolo 1
Grid
“The secret of a Grid’s success is
not so much its structure as the
imagination with which it is used.”
Allen Hurlburt
1.1
Introduzione a Grid
Dalla creazione del primo microprocessore su di un solo chip agli inizi degli anni ’70 è
stata fatta molta strada nell’incremento delle prestazioni computazionali. Proprio in
quegli anni il cofondatore della Intel Corporation, Gordon Moore, diceva:
“Le prestazioni dei processori, e il numero di transistor ad esso relativo,
raddoppiano ogni 18 mesi.”[1]
Questa previsione si rivelò corretta e per tutti gli anni ’70 e ’80 le prestazioni delle
CPU andavano migliorando ad un ritmo equivalente a quello che Moore aveva previsto.
Inoltre, dagli inizi degli anni ’80 si assistette ad una crescente commercializzazione di
personal computer ed all’avvio dell’informatizzazione di massa.
L’ascensione vertiginosa delle prestazioni di un singolo microprocessore non era destinata a durare ancora per molto. Nonostante l’introduzione di supercomputer1 e
mainframe2 , gli onerosi calcoli scientifici, ma non solo quelli, richiedevano prestazioni
di calcolo sempre più bisognose di risorse. La velocità con cui aumentava la complessità dei software, e quindi la loro necessità di risorse era maggiore delle prestazioni
1I
supercomputer sono dei sistemi di elaborazione progettati per ottenere potenze di calcolo molto
elevate.
2 Mainframe: un computer grande e dotato di elevata capacità di elaborazione in grado di
supportare l’utilizzo contemporaneo da parte di numerosi utenti, anche migliaia.
6
1 Grid
hardware che potevano essere fornite. Questo ha portato all’unione delle risorse di
piú computer collegati su di una rete telematica locale sviluppando tecnologie quali
il Cluster Computing, che permette di e↵ettuare calcoli in parallelo. I calcolatori facenti parte di questo sistema possono essere eterogenei, funzionando comunque in un
modo tale da poter essere considerati come un singolo computer. Questo permette
di scomporre un problema che richiede molte elaborazioni in sottoproblemi separabili
che possono essere distribuiti fra i vari nodi del cluster, e dove applicabile per risolverli
in parallelo.
Sono state sviluppate varie tecnologie per la creazione di programmi in grado di essere
eseguiti in parallelo e per l’interfacciamento del cluster stesso; tra cui MPI e PVM.
Quest’ultimo è acronimo di Parallel Virtual Machine[2], ed è un software progettato per permettere a macchine eterogenee, connesse via rete, di essere usate come un
singolo processore parallelo e distribuito. L’MPI (Message Passing Interface)[3] è un
protocollo di comunicazione fra computer, o nodi, che eseguono un programma parallelo su di un sistema distribuito.
Una naturale evoluzione di questi concetti è il Grid computing o Grid cluster che è
una tecnologia strettamente collegata al cluster computing.
Nel 1996 venne pubblicato su “The International Journal of Supercomputer Applications and High Performance Computing”[4] un articolo destinato a far tramontare la
legge di Moore. La pubblicazione fu intitolata “Overview of the I-WAY: Wide Area
Visual Supercomputing” e tra gli autori vanta Ian Foster3 .
Il progetto I-WAY (Information Wide Area Year) è stato il primo riguardante:
• la costruzione di applicazioni in una realtà virtuale distribuita;
• la gestione di risorse distribuite in una WAN4 ;
• il relativo scheduling della richiesta di risorse.
Lo scopo dell’esperimento era quello di usare risorse per consentire ai ricercatori di
e↵ettuare calcoli computazionali su larga scala. Connettendo 17 centri tramite una
comunicazione via rete di tipo ATM5 usando i collegamenti di rete già esistenti, 5 siti
di ricerca virtuale ed oltre 60 gruppi di applicazioni, il progetto I-WAY venne creato
in una WAN6 eterogenea. L’obiettivo principale era quello di avere applicazioni che
3 Ian
Foster è ricercatore presso il Mathematics and Computer Science Division all’Argonne Natio-
nal Laboratory e professore di Informatica all’University of Chicago; meglio conosciuto come ’father
of the Grid’ (il padre della griglia)
4 WAN (Wide Area Network) è una rete di computer usata per connettere LAN (Loacal Area
Network)
5 Asynchronous Transfer Mode
6 WAN: Wide Area Network (rete geografica), che collega nodi a distanza qualsiasi, anche
planetaria.
1.1 Introduzione a Grid
7
usassero più di un supercomputer, di uno o più dispositivi virtuali e di avere una
‘tecnologia collaborativa’ usando spazi virtuali comuni nei quali condurre una scienza
computazionale. L’obiettivo secondario da un punto di vista teorico, ma non da un
punto di vista tecnico, era quello di scoprire problemi legati ad un uso esteso della
tecnologia basata su sistemi distribuiti. Questo portò all’analisi ed alla relativa risoluzione di problematiche molto importanti nello sviluppo di applicazioni distribuite,
quali:
• sicurezza;
• ambienti computazionali uniformi;
• scheduling globale delle risorse distribuite;
• riserva (lock) di risorse;
• definizione e gestione di gruppi di ricerca virtuali distribuiti, ma collaborativi.
I-WAY permise di sperimentare un nuovo metodo per rendere possibili calcoli che
necessitavano di risorse sempre maggiori, andando a sfruttare la potenza di calcolo
di tutti quei computer dedicati ad altre attività, ma momentaneamente inutilizzati.
Una metodologia di calcolo computazionale distribuito, che avrebbe permesso di condividere dati e potenza di calcolo tramite una rete a pubblico accesso, creando una
vastissima risorsa computazionale, venne quindi considerata la soluzione ideale per
risolvere problemi.
Questo nuovo sviluppo avvenne parallelamente alla progressiva involuzione della legge
di Moore, causata soprattutto da limiti tecnologici, quali: l’impossibilità di ridurre la
scala del gate del singolo transistor a causa dell’incremento della densità di corrente
e la difficoltà legata alla schermatura dei chip all’aumentare delle frequenze di calcolo
(circa 3 GHz odierni).
Oramai le performance dei chip non raddoppiavano più e il loro prezzo non stava
diminuendo come era accaduto in passato. Inoltre dall’avvento del progetto I-WAY
l’obiettivo principale non era più quello di creare risorse per il calcolo computazionale
sempre più potenti in una densità sempre minore: era di rendere l’utilizzo di risorse
geograficamente distribuite sempre più facile ed efficiente. Ma sotto un altro punto di
vista, l’avvento del progetto di Ian Foster aveva portato nuova linfa allo sviluppo del
calcolo computazionale, costruendo una nuova struttura che si potesse interporre fra
l’hardware e l’utente, migliorando ulteriormente le prestazioni di calcolo, senza il bisogno di aumentare ancora una volta vertiginosamente la complessità della circuiteria
di un computer.
Il progetto di Ian Foster era l’inizio di quell’infrastruttura di calcolo computazionale
8
1 Grid
che evolvendosi ha portato a focalizzare lo sviluppo su quelle che oggi sono le griglie
computazionali.
1.2
Grid computing
In seguito al progetto I-WAY vi fu un moltiplicarsi di progetti che prevedevano lo sviluppo di un’infrastruttura di calcolo simile ad esso. Tutti i progetti avevano in comune
la stessa architettura globale e tecnologie simili venivano usate per la realizzazione.
La Grid vera e propria nacque ad un gruppo di lavoro presso l’Argonne National Laboratory nel Settembre del 1997. Questo fu seguito da una pubblicazione del 1998
intitolata “The Grid: Blueprint for a New Computing Infrastructure”[5] di Ian Foster
e Carl Kesselman, ma meglio conosciuta come “La bibbia di Grid”.
1.2.1
Definizione di Grid
La griglia computazionale è un tipo di sistema parallelo e distribuito che consente la
condivisione, selezione e aggregazione di risorse autonome geograficamente distribuite
utilizzate a tempo di esecuzione, a seconda della loro disponibilità, capacità, prestazione, costo e qualità del servizio richiesto dall’utente. Dunque il Grid Computing è
l’applicazione infrastrutturale di quella logica di condivisione delle risorse che consente
di utilizzare la potenza di elaborazione di una serie di computer collegati in rete via
Internet, dividendo i processi di calcolo e di memoria secondo regole di distribuzione
definite dai gestori della Grid.
Ciò che rende possibile quest’infrastruttura intermediando fra diverse entità è il middleware. Questo è un software di connessione formato da un insieme di servizi e
di ambienti di sviluppo che consentono a più entità, che possono risiedere su uno o
più elaboratori, di interagire attraverso una rete di connessione a dispetto di di↵erenze nei protocolli di comunicazione, architetture dei sistemi locali, sistemi operativi,
ecc. . . Dunque, lo scopo del middleware è quello di o↵rire servizi di comunicazione,
astrazione, collaborazione ed un’ambiente di sviluppo delle applicazioni per permettere l’interoperabilità e la connettività fra applicazioni distribuite su risorse eterogenee.
[5]
Passiamo ad analizzare in dettaglio le proprietà della Grid.
• Condivisione di risorse
La possibilità di condividere risorse eterogenee, intese come potenza di calcolo
e spazio disco, in scala globale è una caratteristica essenziale della Grid. Le
risorse possono essere costituite da piattaforme di↵erenti, con diverse architetture hardware e software, con diversi linguaggi computazionali, situate in luoghi
1.2 Grid computing
9
di↵erenti, appartenenti a di↵erenti domini amministrativi.
La condivisione deve essere ad un livello di astrazione tale da rendere una generica operazione completamente trasparente all’utente. Questo ha il vantaggio di
proiettare l’utente stesso in un ambiente virtualizzato, nel quale accedere a dati
e risorse locali o distribuiti nella Grid non faccia alcuna di↵erenza. Da questo
punto di vista Grid è un’evoluzione di Internet in quanto permette di migliorare
i collegamenti, definendo opportuni protocolli di comunicazione, ma in un contesto generico. Nella definizione di questi protocolli entra in gioco il concetto di
sicurezza che è un aspetto importante e critico della Grid e che deve essere ad
un livello molto alto.
• Sicurezza
Poiché non è possibile una condivisione incondizionata di risorse a livello di Internet, è fondamentale che l’aspetto della sicurezza sia trattato in una Computing
Grid. Per questo, vengono definiti tre livelli di sicurezza:
– politica di accesso: i fornitori di risorse e gli utenti devono definire con
chiarezza e precisione a chi è permesso di condividere risorse e per quali
condizioni le risorse possono essere accedute;
– autenticazione: è fondamentale un meccanismo per la verifica dell’identità
di una risorsa e di un utente;
– autorizzazione: è necessario un meccanismo per determinare se un operazione è permessa, a seconda del tipo di politica di accesso delle risorse.
Quindi è importante sapere chi è autorizzato ad usare Grid e quali risorse in
particolare; chi certifica che l’utente autentificato sia proprio quell’utente; quali
sono le politiche d’uso delle risorse.
• Uso delle risorse
Con un quantitativo di risorse molto grande, è fondamentale un efficiente uso
delle stesse. Questo perché non ha importanza avere un numero di risorse molto
elevato se ogni volta che un utente voglia accedervi esso trovi lunghe code di
utenti per la stessa risorsa. È primario l’obiettivo di distribuire i lavori fra le
code, allocando i lavori efficientemente in modo da distribuire gli accessi fra
più risorse. Quindi, in linea di principio, un utente ha informazioni relative a
diversi lavori (jobs) sottomessi su Grid ed è possibile calcolare una distribuzione
ottimale per l’allocazione delle risorse. Un software che esegua questa analisi di
carico e distribuzione di jobs è da considerare parte integrante del middleware
della Grid.
10
1 Grid
1.3
Architettura Grid
Non è possibile definire un’architettura Grid che possa essere considerata come definitiva perché le caratteristiche e l’architettura dipendono fortemente dal caso concreto.
Ad esempio è ben diverso avere risorse omogenee gestite amministrativamente in maniera centralizzata dall’organizzare risorse eterogenee e controllabili solo localmente.
In questo ultimo caso, che è quello che ci interessa, una delle richieste a cui dovrà
soddisfare la Grid è quella di assemblare risorse eterogenee, di mettere a disposizione
un’infrastruttura scalabile che assicuri dinamicità nell’uso e nell’organizzazione delle
risorse. È tuttavia possibile definire come è organizzata in generale una Grid da un
punto di vista concettuale.
1.3.1
Livelli architetturali
Come è possibile vedere in figura 1.1 sono distinguibili tre macro-livelli.
Applicazioni Scientifiche, Business e Ingegneristiche
APPLICAZIONI
Applicazioni d'ambiente per lo sviluppo
High Level
Knowledge
Services
Security
Workload
Management
System
MIDDLEWARE
Low Level
Communica
tion
Scheduling
Monitoring
Risorse
Computers
Dati
FABRIC
Storage
Elements
Figura 1.1: I tre macro livelli architetturali di una griglia computazionale.
1.3 Architettura Grid
11
• Livello delle Applicazioni
Ne fanno parte tutte le applicazioni dell’utente che interagiscono, direttamente
o non, con la Grid. Talvolta contiene l’interfaccia che consente all’utente di interagire con la Grid e quindi anche l’ambiente di programmazione (API). Questo è
caratterizzato da un’assoluta portabilità attraverso vari tipi di sistemi hardwaresoftware e loro combinazioni in un contesto di eterogeneità e dinamicità. Inoltre
tutto il meccanismo della gestione dei gruppi di lavoro è parte integrante di
questo livello.
• Livello Middleware
Questo livello è a sua volta scomponibile in due parti: un livello più vicino
all’utente (High Level) ed uno più vicino alle risorse (Low Level).
L’High Level è costituito da:
– Knowledge Discovery: servizi di Grid che forniscono un accesso consistente,
pervasivo ed efficace a risorse computazionali, con un interesse rivolto allo
sfruttamento della Grid come un sofisticato strumento di “Web computing”;
– Sicurezza: la possibilità di un efficace ed efficiente controllo di accesso alla
griglia per avere ambienti di Grid sicuri, ma anche per una cooperazione
tra ambienti Grid appartenenti a di↵erenti organizzazioni;
– Resource Broker: servizio che fornisce un collegamento tra la richiesta di
risorse e le risorse disponibili.
Il Low Level è composto da:
– Scheduling: interagendo con i servizi del suo livello e di quello superiore si
occupa di mappare costantemente le risorse della Grid, decidendo su quali siti devono essere assegnati i vari lavori, bilanciando il carico di lavoro
a seconda delle informazioni disponibili; quindi garantisce un accesso altamente efficiente ad informazioni statiche e dinamiche traducendo le richieste
di alto livello in richieste di basso livello;
– Monitoring: questo servizio si incarica di controllare l’utilizzo delle risorse del sistema e di dare un supporto diagnostico in caso di guasti e
sovraccarichi;
– Comunication: definisce i protocolli di comunicazione e autenticazione per
le transazioni di rete abilitando lo scambio dei dati con il livello fabric. I
protocolli di comunicazione permettono lo scambio di dati tra le risorse del
livello inferiore, cioè implementano i servizi di trasporto, routing e naming;
mentre i protocolli di autenticazione forniscono un meccanismo di autoriz-
12
1 Grid
zazione e protezione delle comunicazioni in uno scenario multi-istituzionale
permettendo l’interoperabilità tra le varie soluzioni locali.
• Livello Fabric
Le risorse sono oggetti che hanno proprietari, che possono essere usate per un
certo periodo di tempo e che possono essere rinnovabili oppure no. Sono gestite
tramite lo Scheduling, il Knowledge Discovery e il Resource Broker. Questi
permettono di allocare le risorse di cui ha bisogno un utente, sottraendole a
quelle disponibili. I dati possono essere replicati per l’ottimizzazione delle risorse
di memorizzazione, garantendo prestazioni migliori nell’accesso ai dati. Alcuni
esempi di risorse possono essere lo spazio disco, la banda di rete, il tempo di
CPU o semplicemente i dati.
1.4
Grid di produzione
Dopo il progetto I-WAY sono nati nuovi e sempre più avanzati progetti che prevedono
l’applicazione della Grid, per scopi principalmente scientifici e finanziari. Ecco un
elenco dei principali:
• Condor[6]. È un progetto sviluppato a partire dal 1988 dall’ University of Wi-
sconsin (Madison, USA) con l’idea di sfruttare la potenza di calcolo dei desktop
universitari accesi ma momentaneamente inutilizzati. L’obiettivo del progetto è
quello di sviluppare, implementare, di↵ondere e valutare i meccanismi e le linee
di condotta per il supporto dell’High Throughput Computing (HTC) in grandi
insiemi di risorse computazionali proprietarie e distribuite. Gli utenti sottomettono i loro job, seriali o paralleli che siano, a Condor; quest’ultimo mette i job
in una coda, sceglie quando e dove eseguire i job, ne segue l’andamento, ed alla
fine informa l’utente al termine dell’esecuzione.
• UNICORE[7]. É una tecnologia di Grid Computing che fornisce l’accesso traspa-
rente, sicuro e intuitivo a risorse distribuite Grid come supercomputer o sistemi
cluster e le informazioni memorizzate nelle basi di dati. UNICORE (Uniform
Interface to Computing Resources) è stato sviluppato in due progetti finanziati
dal ministero tedesco per l’istruzione e la ricerca. L’architettura è costituita da
tre livelli: l’utente (client), il server e il sito di destinazione.
• NorduGrid[8]. Nasce come infrastruttura di calcolo distribuito a disposizione
delle università e dei centri di ricerca del Nord Europa. NorduGrid utilizza
il middleware ARC[9] che include molteplici applicativi e librerie mediante le
quali è possibile realizzare i servizi base (monitoraggio delle risorse distribuite,
gestione dei dati, comunicazione, autenticazione e sicurezza, portabilità) su cui
1.4 Grid di produzione
13
definire il middleware di livello superiore. Le sue diverse componenti possono
essere adoperate indipendentemente l’una dall’altra oppure in maniera congiunta
al fine di sviluppare applicativi per il Grid Computing.
• LCG[10]. L’LHC Computing Grid Project è stato creato dal CERN (Ginevra,
Svizzera) nel 2001 con lo scopo di costruire e mantenere l’infrastruttura com-
putazionale necessaria per la memorizzazione e l’analisi dei dati provenienti dai
quattro esperimenti dell’LHC (ALICE, ATLAS, CMS e LHCb). LCG costituisce
un test di vitale importanza per le nuove tecnologie informatiche Grid e potrebbe rivoluzionare il modo in cui utilizziamo le risorse dei computer in aree che
vanno dalla ricerca fondamentale alla diagnostica medica.
• EGEE[11]. “Enabling Grid for E-sciencE” è il progetto finanziato dalla Co-
munità Europea che ha come scopo la realizzazione di un’infrastruttura Grid
sicura, affidabile e robusta, che consenta di accedere a risorse geograficamente
distribuite 24 ore al giorno. La base di partenza è stata quella del preesistente LHC Computing Grid (LCG), e uno degli scopi è di fornire a LCG nuove
versioni del middleware. Questo progetto garantisce anche l’interoperabilità di
implementazioni diverse (gLite[12], ARC, UNICORE).
• OSG[13]. L’Open Science Grid è un’infrastruttura Grid per la scienza su larga
scala, sviluppata ed adoperata da un consorzio di università e laboratori degli
Stati Uniti. È stata formata nel 2004 per permettere a di↵erenti comunità di
scienziati di accedere ad una infrastruttura Grid che permettesse di sfruttare
le risorse comuni. Questa include due progetti: Integration e Production Grid.
L’Integration Grid permette di verificare nuove tecnologie e applicazioni, mentre
la Production Grid fornisce un ambiente stabile e supportato per applicazioni
destinate ad un uso a lungo termine. Le capacità e la linea di sviluppo di questo
progetto, sono guidate dai partecipanti degli Stati Uniti negli esperimenti presso l’LHC. Inoltre, molti dei gruppi di lavoro dell’OSG collaborano e lavorano
sull’interoperabilità con l’infrastruttura EGEE. La correlazione fra LCG e le risorse degli Stati Uniti avviene attraverso gli esperimenti a LHC a cui partecipano
anche i ricercatori statunitensi.
• WLCG[10]. La Worldwide LHC Computing Grid è stata creata per preparare
le infrastrutture necessarie alla simulazione e all’analisi dei dati prodotti dagli
esperimenti dell’acceleratore LHC. Essa dipende da una stretta collaborazione
con i maggiori progetti ed organizzazioni che fruiscono di fondi pubblici, per la
fornitura di servizi di rete, software di Grid specializzato e per il controllo dell’infrastruttura Grid. Proprio per questo, i progetti WLCG ed EGEE condividono
14
1 Grid
una gran parte dei loro servizi operando in congiunzione e creando un sistema
WLCG/EGEE.
1.4.1
Sostenibilità dell’infrastruttura Grid: dallo sviluppo alle
operazioni
Attualmente gli stati membri e la Commissione Europea hanno progettato e stanno
mettendo in atto un piano per garantire la sostenibilità a lungo termine del middleware
della infrastruttura della Grid di base con l’European Grid Initiative (EGI)[14]. Questa è un’associazione fra un ente di coordinazione e le National Grid Initiative (NGI).
Queste ultime sono delle entità nazionali legali il cui compito è quello di prendersi
carico sia delle operazioni inerenti all’infrastruttura Grid nei rispettivi stati, che delle
richieste delle comunità scientifiche che vengono supportate. L’obiettivo principale
dell’evoluzione di EGEE è quello di collegare fra di loro le Grid nazionali esistenti e
di supportare attivamente l’avvio di nuove iniziative in quegli stati dove ancora non
esistono.
Le attività dei progetti correnti (EGEE) vengono progressivamente trasformate in
servizi di EGI: questa fase deve ancora essere completata e per poter garantire una
continuità dei servizi per gli utenti della Grid europea. Alla fine della transizione
l’infrastruttura dovrà essere sostenibile nel lungo periodo in termini di costi e risorse
e dovrà coordinare le singole iniziative dei 42 paesi europei ed extra-europei che partecipano all’iniziativa. Particolare attenzione verrà prestata allo sviluppo dei sistemi
middleware necessari per i servizi o↵erti, nonché alla validazione e standardizzazione dei software che saranno messi a disposizione da sistemi di Grid Computing (già
sviluppati a livello nazionale). Il progetto prevede anche la realizzazione di specifici
standard per le interfacce Grid e la promozione di questa tecnologia presso l’industria,
per un corretto trasferimento tecnologico. Oltre al trasferimento delle nuove tecnologie, è necessario che l’attuale middleware della Grid europea venga continuamente
sviluppato. Tale sviluppo continuerà anche nell’ambito del progetto UMD: Unified
Middleware Distribution. Questo altri non è che l’unione dei tre consorzi di EGEE
(ARC, gLite e UNICORE) che permetterà di coordinare a livello europeo gli sviluppi
che attualmente sono paralleli, evitando una duplicazione degli sforzi.
1.4.2
Da Grid a cloud computing
Il passaggio ad una struttura con maggiore sostenibilità, consente anche un passaggio
da Grid a Cloud Computing[15]. Questo implica che l’infrastruttura Grid potrà essere
vista come un insieme di servizi da mettere a disposizione agli utenti tramite un’o↵erta
1.5 Architettura WLCG/EGEE
15
(commerciale) attraverso un servizio web di risorse di calcolo e storage con un ambiente
virtuale creato secondo le esigenze degli utenti in un dominio amministrativo unico,
cosı̀ come stanno già facendo Amazon, Google o IBM. Quest’approccio rende semplice
e flessibile l’accesso ad hardware, software e storage grazie a una nuova interfaccia web
e l’o↵erta di ambienti virtuali (Worker Node on Demand7 ). La funzionalità nei servizi
Cloud può essere descritta in molti modi e dipende dai tipi di astrazione e servizi che
si intende mettere a disposizione. Le astrazioni tipiche sono:
• Hardware as a Service (HaaS): mettere l’hardware a disposizione dei clienti.
• Software as a Service (SaaS): fornire dei servizi software pronti per essere usati.
• Data as a Service (DaaS): consentire accesso ai dati disponibili da varie fonti.
Queste astrazioni possono essere viste collettivamente come l’o↵erta di una Platform
as a Service (Paas), o, piú in generale, di una Infrastructure as a Service (IaaS).
L’infrastruttura (come IGI8 ) potrà potenzialmente diventare un servizio che si compra
e si vende facilmente via web, cosı́ che la Grid integrata con Cloud e virtualizzazione
possa estendere l’uso dell’infrastruttura dalla ricerca a potenzialemente ogni utente
(Pubblica Amministrazione e aziende).
1.5
Architettura WLCG/EGEE
I requisiti computazionali degli esperimenti di LHC sono enormi: circa 12-14 PetaBytes di dati saranno prodotti ogni anno. Analizzare questa mole di dati richiederà
l’equivalente di 70 mila computer del tipo più veloce tra quelli oggi prodotti, che per
vari motivi non possono essere tutti concentrati in un solo posto.
La Worldwide LHC Computing Grid viene incontro a queste necessità attraverso il
dispiegamento di un servizio di calcolo Grid a livello mondiale, integrando le risorse dei
centri di calcolo scientifici disseminati in Europa, America e Asia, in un’organizzazione
globale di calcolo virtuale.
1.5.1
Utenti e VO
Le organizzazioni virtuali (VO, Virtual Organization)[16] sono un insieme dinamico,
multi-istituzionale e virtuale di entità che condividono risorse. Ognuna ha una dimensione di↵erente e persegue un diverso scopo con una diversa durata temporale.
Nell’architettura WLCG/EGEE le VO sono utilizzate per fornire agli utenti di un
gruppo, senza una particolare caratterizzazione geografica, la potenzialità di accedere
7 WNOD:
8 Italian
selezione dinamica di risorse virtuali tramite Grid
Grid Initiative: é la NGI italiana che fa parte del progetto EGI
16
1 Grid
alla risorse di un sistema distribuito, garantendone un accesso coordinato e controllato, o↵rendo all’utente la visibilità di un unico sistema di calcolo logico, facilmente
scalabile.
Ogni entità mette a disposizione della griglia computazionale un insieme di risorse
locali. Ognuna di queste entità può utilizzare le risorse della griglia computazionale
combinandole nel modo più opportuno per risolvere i propri problemi. Inoltre, ogni
entità agisce sia da client che da server (cosı̀ come avviene nella tecnologia peer to
peer).
1.5.2
Sicurezza
La Grid Security Infrastructure (GSI)[17] è una specifica d’autenticazione per una
comunicazione segreta e protetta fra software nell’ambiente Grid. Questa si basa sul
concetto di chiave pubblica criptata (certificati X.5099 ) e sul protocollo di comunicazione Secure Socket Layer (SSL)
10
. Dunque una generica entità della Grid (qualsiasi
essa sia: utente o risorsa) necessita di un certificato digitale rilasciato da una Certification Authority (CA) 11 riconosciuta da WLCG/EGEE.
Il certificato, la cui chiave privata è protetta da una password, è usato per generare e
certificare un proxy certificate, che corrisponde ad un certificato temporaneo (generalmente con una durata di 24 ore) usato per l’attuale autentifica all’interno della Grid
e che non necessita di password. Spesso i lavori che gli utenti hanno la necessità di
eseguire sulla Grid hanno durate molto più lunghe -anche di molti giorni- e potrebbe
accadere che le credenziali scadano prima della fine dei lavori, cosı̀ che questi vengano
invalidati per mancanza di autorizzazione ed eventualmente i risultati prodotti non
siano accessibili. Anche per questo motivo è stato introdotto un sistema di deposito
delle credenziali dell’utente, permettendo la creazione e la relativa memorizzazione
di un certificato proxy a lunga durata in un server dedicato. Il nome del server è
MyProxy, ed il certificato contenuto in questo server viene utilizzato per rinnovare
periodicamente il proxy di un utente che sta per scadere. Lo schema di autenticazione
è mostrato in figura 1.2. Questo servizio oltre che a mantenere a lungo termine le
credenziali degli utenti permette di avere un’autenticazione unica dal punto di vista
dell’utente, cosı̀ che ogni servizio Grid si limiti ad interrogare il MyProxy, senza che
l’utente debba inserire la password della chiave privata per ogni singolo servizio.
Il Virtual Organization Membership Service (VOMS) è un sistema che permette di
complementare un certificato con delle estensioni contenenti informazioni relative alla
VO, il gruppo VO a cui appartiene l’utente, e il ruolo che l’utente ha all’interno della
VO. Nella terminologia VO, un gruppo è un sottoinsieme dell’organizzazione virtuale,
9 In
crittografia, X.509 è uno standard per le infrastrutture a chiave pubblica
è un protocollo realizzato per comunicazioni cifrate su Internet
11 Certification authority è un’entità che rilascia certificati digitali verso terze parti
10 SSL
17
1.5 Architettura WLCG/EGEE
M yP roxy
CA
FIRMA DIGITALE
U te nte
FIRMA DIGITALE
P roxy..1
FIRMA DIGITALE
P roxy..n
FIRMA DIGITALE
Figura 1.2: Autentificazione nella Grid: dalla Certification Autority al servizio
MyProxy.
contenente i membri che condividono responsabilità e privilegi nel progetto. I gruppi
sono organizzati in modo gerarchico.
1.5.3
Elementi principali del middleware
In figura 1.3 sono mostrate le interazioni fra gli elementi principali, a cui corrispondono una o più macchine dedicate, che compongono la Grid di WLCG/EGEE.
Interfaccia Utente
L’Interfaccia Utente (UI, User Interface) è il punto d’accesso alla Grid di WLCG/EGEE.
Questa può essere un qualsiasi computer nel quale l’utente abbia un account e il proprio certificato installato. Dall’interfaccia l’utente può essere autorizzato ad utilizzare
le risorse della Grid, accedendo alle funzionalità o↵erte dall’Information, Workload e
Data Management Systems.
Computing Element
Per la terminologia Grid, un Computing Element (CE) corrisponde ad un insieme di
risorse computazionali localizzate in un sito (esempio: cluster, farm computazionale).
La funzionalità principale del CE è quella della gestione dei job (sottomissione, controllo, etc.). Una delle risorse facenti parte del CE sono i Worker Nodes (WN). Questo
è l’insieme dei nodi che formano il cluster; i WN eseguono i job e contengono gli stessi
comandi e librerie installate nelle UI.
Storage Element
18
1 Grid
Lo Storage Element (SE) è un’entità logica che garantisce un accesso uniforme alle
risorse di memoria. Queste ultime possono essere disk server, disk array o tape disk.
Gli Storage Element possono supportare di↵erenti tipi di protocolli ed interfacce per
l’accesso ai dati memorizzati.
Molti dei siti WLCG/EGEE forniscono almeno uno SE.
COMPONENTE
FISICA
USER
INTERFACE
INFORMATION
INDEX
STORAGE
ELEMENT
WORKER
NODE
RESOURCE
BROKER
COMPUTING
ELEMENT
WORKER
NODE
Figura 1.3: Elementi della Grid WLCG/EGEE.
Resource Broker
Il Resource Broker (RB), è il modulo della Grid che riceve le richieste degli utenti e
interroga l’Information Service per trovare le risorse adatte. Il Workload Management
System (WMS) è un software che risiede nel Resource Broker. Il suo obiettivo è quello
di accettare i job degli utenti, assegnarli ai più appropriati CE, registrare il loro stato
e ritirarne il relativo output al termine dell’esecuzione. Dunque, questa entità regola
l’accesso alle risorse distribuite e↵ettuando il processo detto di match-making.
Information System
L’Information System (IS) fornisce informazioni circa le risorse WLCG/EGEE ed il
loro stato. I sistemi di informazione attualmente utilizzati dalla Grid WLCG/EGEE
sono due: il “Monitoring and Discovering Service” (MDS)[18] che è usato per la scoperta di risorse e per pubblicarne lo stato; il “Relational Grid Monitoring Architecture”
(R-GMA)[19] che invece è usato per il controllo delle risorse e la loro relativa pubbli-
1.5 Architettura WLCG/EGEE
19
cazione ad un livello utente.
Questi servizi si appoggiano a BDII (Berkeley Database Information Index), un database che serve per memorizzare lo stato delle risorse e che contiene tutte le informazioni
disponibili relative a Grid.
1.5.4
Job flow: sottomissione
La figura 1.4 mostra il flusso di lavoro nella sottomissione di un Job nella griglia computazionale WLCG/EGEE.
Figura 1.4: Job Flow nella Grid WLCG/EGEE.
I passi principali sono i seguenti:
• a: l’utente ottiene un certificato digitale dalla Certification Authority; si registra
ad una VO ed ottiene un account ad una Interfaccia Utente; da qui crea un
certificato proxy che permette all’utente di e↵ettuare operazioni;
• b: viene sottomesso un job dall’UI al Resource Broker, specificando i files da
copiare nei Worker Nodes (Input Sandbox); lo stato del job è SUBMITTED;
20
1 Grid
• c: il Workload Management System cerca il miglior Computing Element dispo-
nibile secondo le richieste specificate dall’utente, interrogando il BDII; lo stato
del job è WAITING;
• d: il RB prepara il job per la sottomissione ed invia le informazioni necessarie
al CE selezionato; lo stato del job è READY;
• e: il CE riceve la richiesta; lo stato del job è SCHEDULED;
• f: il manager di risorse locale della farm invia l’esecuzione del job ai WN locali
e i file dell’utente vengono copiati dal RB al WN dove viene eseguito il job; lo
stato del job è RUNNING;
• g: mentre il job è in esecuzione i file possono essere letti da uno Storage Element;
• h: il job può produrre dei file di output nuovi; questi possono essere memorizzati
negli SE ed essere acceduti da altri utenti;
• i: nel caso in cui l’esecuzione del job termina senza errori e l’output prodotto
(Output Sandbox) è di dimensioni non molto grandi quest’ultimo viene copiato
nel Resource Broker; lo stato del job è DONE;
• j: ora l’utente può ritirare l’output del suo job nella sua User Interface; lo stato
del job è CLEARED;
• k: le richieste per il controllo dello stato del job e delle risorse possono essere
e↵ettuate dalla UI;
• l: se un sito a cui è stato inviato il job, non è in grado di accettarlo e di
eseguirlo, allora il job può essere passato ad un altro CE; dopo un certo numero
di risottomissioni il job viene marcato ABORTED.
1.5.5
MAGIC-5: un caso d’uso della Grid
MAGIC-5[20] (Medical Application on a Grid Infrastructure Connection) è una collaborazione italiana fra vari istituti INFN e ospedali il cui fine è quello di sviluppare un
sistema software per applicazioni mediche, che fornisca un’individuazione assistita dal
computer (CAD, Computer Aided Detection) su basi di dati distribuite d’immagini
mediche (mammografia, TAC, . . . ) e la loro scansione automatizzata tramite l’ausilio della tecnologia Grid. Data l’enorme mole di dati da controllare e le dimensioni
delle singole immagini che sconsigliano il trasferimento (vietato d’altra parte da motivi di riservatezza dei dati), l’uso di un sistema automatico distribuito per l’analisi
di immagini mediche è di grandissima importanza per i programmi di monitoraggio;
1.6 Flussi di lavoro complessi in ambienti distribuiti
21
alcuni esempi di applicazione sono: immagini mammografiche ai raggi-x per la diagnosi di cancro al seno, immagini per l’individuazione del cancro al polmone fornite
dalla Computed Tomography (CT) e immagini fornite dalla tomografia ad emissione
di positroni (PET, Positron Emission Tomography), per una diagnosi precoce dell’Alzheimer. Questo permette un’organizzazione dei dati ed una loro analisi remota,
consentendo anche una diagnosi remota interattiva. In questo caso la Grid consente
anche di operare su dati remoti rispettando i limiti previsti dalla legge; infatti, secondo
la tutela della privacy del paziente, non è possibile trasferire dei dati relativi ad esso,
da una struttura ospedaliera ad un’altra senza una burocrazia molto pesante.
MAGIC-5, prevede di trasferire ed eseguire il software sul sito contenente i dati di
interesse e di ricevere il risultato dell’esecuzione del software su quei dati anonimizzati
o meno a seconda dell’applicazione. Questo, oltre a provocare una certa riduzione
dei ritardi associati al processo di monitoraggio, permette un’analisi più efficiente e
sicura, segnalando i casi da sottoporre ad ulteriore analisi da parte di un medico.
1.6
Flussi di lavoro complessi in ambienti distribuiti
I modelli computazionali definiti dalle organizzazioni o istituzioni che hanno bisogno
di una grande quantità di risorse spesso necessitano dell’implementazione di flussi di
lavoro complessi che devono però coesistere con la richiesta di scalabilità. La Grid
dá la possibilità di risolvere i problemi relativi alla scalabilità introducendo servizi e
infrastrutture che permettono a ogni collaborazione di costruire applicazioni specifiche. Quest’ultime implementano di↵erenti flussi di lavoro permettendo di dare una
soluzione alla quasi totalità dei casi d’uso. Soddisfare tutti i requisiti appena descritti
è difficile -o forse impossibile- se s’interagisce direttamente con la Grid, e la tendenza
attuale è quella di andare verso il Client/Server Computing in sostituzione alle applicazioni autonome e indipendenti. L’introduzione di un tale nuovo livello di servizi per
le applicazioni, che si interpone fra quest’ultime e il middleware della Grid, permette
di soddisfare i requisiti in termini di scalabilità dell’infrastruttura e funzionalità messe
a disposizione degli utenti. Inoltre l’utente viene isolato dalle complessità del sistema
distribuito permettendo di costruire un ambiente di lavoro dinamico e modulare. Infatti le applicazioni basate sul client/server computing permettono di mettere in atto,
migliorare e ottimizzare l’utilizzo del middleware della Grid. In particolare la presenza
di un server (o meglio: un insieme di servizi distribuiti su molteplici server) permette
di:
• implementare dei flussi di lavoro specifici e allo stesso tempo complessi;
• gestire facilmente le politiche dell’applicazione decise dalle relative Virtual Organization, centralizzando eventuali cambiamenti;
22
1 Grid
• sganciarsi dall’infrastruttura Grid, con la possibilità per gli amministratori di
gestire le esigenze della VO senza passare dalla Grid;
• nascondere le complessità della Grid agli utenti.
Capitolo 2
Client-server computing
“Real men don’t use backups, they
post their stu↵ on a public ftp server
and let the rest of the world make
copies.”
Linus Torvalds
Negli ultimi anni la crescita esponenziale del Web ha portato allo sviluppo di servizi
fortemente centralizzati in netto contrasto con la natura fortemente distribuita della
rete stessa cosı̀ come era stata concepita. Il sistema client-server, che rappresenta il
core system di molti sistemi presenti ad oggi su Internet, ha portato infatti notevoli
vantaggi in termini di fruizione del servizio. Oltre che nei sistemi Internet, il sistema
client-server ha trovato applicazione in tutti quei contesti in cui è necessaria una
condivisione di risorse e/o una suddivisione dei lavori.
Il termine client-server venne usato per la prima volta nel 1980 in riferimento ad un
personal computer (PC) su una rete, evolvendo nell’attuale modello solamente verso la
fine degli anni ’80. Tale evoluzione ha portato a considerare questo termine un concetto
logico, che non dipende né dalla diversità né dalla locazione dell’hardware; infatti
una singola macchina può essere sia client che server a seconda della configurazione
del software. La tecnologia client-server è dunque un modello per l’interazione tra i
processi di un software che vengono eseguiti contemporaneamente.
2.1
Definizione di client-server computing
Il client-server computing viene usato per descrivere un modello architetturale per
lo sviluppo di sistemi computazionali. Questo modello è basato sulla distribuzione
delle funzioni fra due tipi di processi autonomi e indipendenti: il server e il client.
24
2 Client-server computing
Un client è un qualsiasi processo che richiede uno specifico servizio al processo del
server. Un server è un processo che fornisce i servizi che sono stati richiesti dal client.
I due processi possono risiedere nello stesso computer o su computer diversi, a patto
che questi siano connessi da una rete. Un client può richiedere servizi a più server
all’interno di una rete, senza preoccuparsi della posizione o delle caratteristiche fisiche
del computer su cui si trova il processo del server. La rete che collega il client e il
server diventa cosı̀ il mezzo attraverso il quale i vari processi possono comunicare.
La caratteristica principale del client-server computing è la distribuzione dei compiti
e delle funzioni, potendo cosı̀ concentrare la potenza di calcolo dove vengono svolte le
funzioni computazionalmente più complesse (generalmente è il server). [21]
2.1.1
Un server per ogni client
Alcune tipologie di server sono:
File Server È una macchina progettata per condividere file all’interno di una
rete. Questa mette a disposizione degli utilizzatori di una rete di computer (i client)
dello spazio su un disco (disco singolo o composto da più dischi) nel quale sia possibile
salvare, leggere, modificare, creare file e cartelle condivise da tutti, secondo regole
o autorizzazioni che generalmente il gestore di rete organizza e gestisce. Il processo
server è in un certo senso primitivo, perché per poter trovare i dati richiesti tende a
esigere lo scambio di un alto numero di messaggi. Alcuni esempi di File Server sono:
• UNIX: Network File Services (NFS) creato da Sun Microsystems [22].
• Microsoft Windows “Map Drive” e.g., Rivier College’s “P-drive”.
• Samba: Samba è un progetto libero che fornisce servizi di condivisione di file e
stampanti a client SMB/CIFS [23].
Print Server Questo tipo di server gestisce l’accesso ai dispositivi di uscita condivisi, come le stampanti. Questi sono stati il primo tipo di server. Un servizio di
stampa può trovarsi in un solo Print Server o su più macchine separate, che funzionano
come un unico Print Server.
Application Server Questa macchina gestisce l’accesso ad applicazioni software
centralizzate, come nel caso di un database condiviso. Quando l’utente richiede delle
informazioni l’Application Server processa la richiesta e ritorna il risultato del processo all’utente.
Mail Server Questo servizio gestisce il flusso della posta elettronica, della messaggistica e della comunicazione nei sistemi a larga scala, come con sistemi di tipo
2.1 Definizione di client-server computing
25
Mainframe.
Fax Server Fornisce la struttura per inviare e ricevere i fax attraverso una singola
connessione di rete telematica. Il Fax Server può essere costituito da una stazione di
lavoro con una scheda che permette d’interfacciarsi al Fax e da un software gestionale
specifico, oppure può essere semplicemente costituito da un dispositivo specializzato
dedicato e progettato per servizi Fax. Questa macchina gestisce il flusso delle informazioni del Fax da e per la rete (simile al Mail Server).
Directory Services Server Sistema tipico negli ambienti a larga scala in cui i
dati sono distribuiti attraverso più server. I servizi di directory forniscono uno strato
di astrazione tra le risorse e gli utenti, organizzando e memorizzando le informazioni
su reti di computer e su risorse condivise disponibili tramite la rete. Il servizio di
directory fornisce anche un controllo degli accessi sull’utilizzo delle risorse condivise
in modo da favorire il lavoro dell’amministratore di sistema.
Web Server Sistema che memorizza e recupera dati da Internet o dall’intranet.
Tipicamente ci sono dei client leggeri, come i browser web, che consentono di richiedere una pagina web (spesso scritta in HTML), messa a disposizione dal server. Le
informazioni inviate dal server web viaggiano in rete trasportate dal protocollo HTTP
(Hyper Text Transfer Protocol). L’insieme di server web dà vita al World Wide Web,
uno dei servizi più utilizzati di Internet. Normalmente un server web risiede su sistemi
dedicati ma può essere eseguito su computer ove risiedano altri server o che vengano
utilizzati anche per altri scopi.
Web Application Server È un software che fornisce l’infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un
contesto distribuito orientato per il web. Si tratta di un complesso di servizi per la
realizzazione di applicazioni multilivello ed enterprise, con alto grado di complessità.
Alcuni esempi di Web Application Server sono: Internet Information Server (IIS) di
Microsoft, iPlanet della Netscape, WebSphere della IBM, WebLogic di BEA and Oracle Application Server.
Database Server Un server di basi di dati è un servizio che fornisce l’accesso
ai dati organizzati all’interno del database localizzato sul server. Questo si occupa di
fornire i servizi di utilizzo del database ad altri programmi e ad altri computer secondo
la modalità client-server. Il server memorizza i dati, riceve le richieste dei client ed
elabora le risposte appropriate. I Database Server sono complessi sistemi software
26
2 Client-server computing
concepiti, oltre che per memorizzare i dati, anche per fornire un accesso rapido ed
efficace ad una pluralità di utenti contemporaneamente e garantire protezione sia dai
guasti che dagli accessi indebiti. Un esempio di Database Server è: Oracle9i[24].
2.1.2
Caratterizzazione
Le caratteristiche in base alle quali possiamo classificare i sistemi client-server sono
principalmente due:
• il tipo di distribuzione dei servizi fra le due entità che permette di definire i
concetti di Fat Client e Fat Server.
• la capacità del server di avere transazioni indipendenti da ogni precedente interazione o meno, cioè di avere un server con o senza stati.
Client-server: massiccio o snello (fat or thin).
Un’entità è chiamata client o server a seconda di quale sia il livello di condivisione delle
operazioni fra di essi. Un client snello (thin) è un client che esegue direttamente solo
un minimo dell’elaborazione, mentre uno massiccio (fat) si fa carico di una proporzione
dell’elaborazione decisamente più amplia. Il criterio di definizione del concetto di Fat
Client o Fat Server è dato dal criterio di quanto un’applicazione sia sul client o sul
server.
• Fat Client: vengono utilizzati nei tradizionali modelli di client-server compu-
ting; spesso la loro introduzione comporta problemi non indi↵erenti dal punto di
vista della manutenzione o dell’assistenza. Un esempio ne sono le applicazioni
Web 2.0 come Google Mail che presenta un’interfaccia ricca (scritta in Ajax) ad
un sistema di posta elettronica.
• Fat Server: il server contiene la logica del sistema, mettendo a disposizione
un livello di servizi astratto. Il vantaggio più grande nell’usare un server massiccio è dovuto al fatto che la gestione è più semplice, perché, in caso di
una qualsiasi modifica al software del server è sufficiente intervenire solamente
sul server, invece che andare a modificare tutti i client che sono potenzialmente
disponibili. Le tendenze attuali privilegiano questo tipo di sistema, dove sempre
più spesso il client leggero corrisponde a un browser web.
Client-server: con o senza stati stateless or stateful Un server senza stati
(Stateless Server ) è un server che tratta ogni richiesta come una transazione indipendente scorrelata da ogni precedente richiesta [25]. Il vantaggio più grande di questa
proprietà è che semplifica di molto la progettazione del server, perché esso non ha
bisogno nè di tenere in relazione transazioni diverse, nè di allocare dinamicamente
2.1 Definizione di client-server computing
27
un’area di memoria dedicata o di preoccuparsi di liberare lo spazio allocato se il client
s’interrompe nel mezzo della transazione. Ovviamente ci sono anche degli svantaggi,
quali:
• dover includere un quantitativo di informazioni maggiore per ogni richiesta;
• il server deve ogni volta interpretare tutte le informazioni.
Un esempio di un server senza stati è un server del World Wide Web (fatta eccezione
dei cookies1 ): questi prendono come input la richiesta (URL) che specifica completamente il documento richiesto e non hanno bisogno di nessun contesto particolare o
memoria allocata durante una precedente richiesta. Questo tipo di server contrasta
con un tradizionale server FTP[26], che gestisce una sessione interattiva con l’utente.
Nel caso di una richiesta per un file che si trova sul server FTP, si assume che l’utente si sia precedentemente autenticato e che la directory corrente e la modalità di
trasferimento del file siano già state definite. Un server con stati (Stateful Server ) ha
una tabella che permette di registrare in modo incrementale le informazioni e lo stato
delle interazioni in corso con i client, incluse le risposte ad ogni richiesta, in modo
che il server possa tener traccia di tutte le richieste e↵ettuate dal client. Il vantaggio di un server con stati è che i messaggi scambiati sono di dimensioni minori e che
sono trattati in modo più efficiente. Alcuni svantaggi sono invece dovuti ai possibili
problemi che il client incontra: nel caso in cui questo incorra in interruzioni ripetute
e frequenti, la grande quantità di informazioni che devono essere gestite dal server
possono peggiorare le prestazioni di quest’ultimo. L’esempio migliore di un server con
stati è un File Server remoto.
Stateless vs Stateful Server.
Confrontando da un punto di vista analitico i server con e senza stati possiamo notare
che:
• Un server con stati tiene traccia dei dati del client (dati) fra una richiesta e la
successiva.
• Un server senza stati non mantiene nessuna informazione sullo stato; ad esempio,
usando un File Server che non mantenga gli stati, per ogni richiesta il client
devrebbe indicare il nome completo del file, specificando dove leggere e scrivere,
riautenticandosi ad ogni richiesta.
1I
cookie HTTP (più comunemente denominati Web cookies, tracking cookies o semplicemente
cookie) sono frammenti di testo inviati da un server ad un Web client (di solito un browser) e poi
rimandati indietro dal client al server - senza subire modifiche - ogni volta che il client accede allo stesso
server. I cookie HTTP sono usati per eseguire autenticazioni e tracking di sessioni e memorizzare
informazioni specifiche riguardanti gli utenti che accedono al server.
28
2 Client-server computing
• Usando un File Server con stati il client può inviare meno informazioni per ogni
richiesta, diventando cosı̀ il modello più semplice.
D’altro canto, un server senza stati è più robusto e ad esempio:
• le connessioni perse non lasciano un file in uno stato invalido;
• riavviando il server non viene persa nessuna informazione;
• un riavvio del client non causa nessuna confusione in un server senza stati.
2.1.3
Funzioni del client
Le operazioni principali dei sistemi client sono:
• Gestione dell’interfaccia utente.
• Controllo della sintassi degli input degli utenti.
• Gestione della logica dell’applicazione.
• Generazione delle richieste per le operazioni da eseguire e loro trasmissione al
server.
• Gestione della comunicazione con il server.
2.1.4
Funzioni del server
Le operazioni principali che sono svolte dal server sono:
• Accettazione e trattamento delle richieste ricevute dal client.
• Controllo dell’autorizzazione.
• Garanzia di preservare l’integrità.
• Esecuzione delle operazioni necessarie e trasmissione delle risposte al client.
• Manutenzione di un catalogo/tabella del sistema.
• Capacità di uso concorrente tra più client (multiclient).
• Ripristino del sistema in caso di fallimento.
29
2.1 Definizione di client-server computing
2.1.5
Modelli strutturali
Quando si parla di topologia nei sistemi client-server ci si riferisce alla disposizione
e alla struttura fisica della rete client-server, in cui tutti i client e tutti i server sono
connessi gli uni con gli altri, includendo tutte le stazioni di lavoro. I diversi schemi di
topologie e strategie usate sono i seguenti [27]:
• Unico client, unico server: in questa topologia un unico client è connesso al
server come mostrato in figura 2.1.
• Più client, unico server: i client sono multipli e sono connessi ad un unico server,
figura 2.2.
• Più client, più server: i client sono multipli e sono connessi a molteplici server,
figura 2.3.
Server
Client
Figura 2.1: Topologia client-server con un server per un unico client.
Server
Client
Client
Client
Client
Client
Figura 2.2: Topologia client-server con un solo server per client multipli.
La struttura dei due casi in figura 2.2 e 2.2 è tale da introdurre il problema legato
alla presenza di un unico server, infatti nel caso di non disponibilità di quest’ultimo
i servizi non sono più accessibili. Questo problema è conosciuto come Single Point
of Failure. L’indisponibilità di tale servizio può essere legata a un attacco maligno,
un problema di rete o la semplice manutenzione del server. La soluzione ridondante
mostrata in figura 2.3 permette di avere un servizio più stabile dal punto di vista della
disponibilità, in quanto è basata su server multipli. Questi introducono la capacità di
30
2 Client-server computing
Server
Server
Server
Server
Server
Client
Client
Client
Client
Client
Figura 2.3: Topologia client-server con più server e più client.
cambiare server quando quello precedentemente contattato è terminato inaspettatamente o non è stato proprio possibile contrattarlo (failover ). Tale tecnica avviene in
modo trasparente senza l’intervento umano e senza nessun avvertimento. [28]
2.1.6
Integrazione con il calcolo distribuito
Una caratteristica tipica del calcolo distribuito è quella di avere delle tecnologie implementate attraverso ambienti eterogenei 1.2.1. Nel caso dei sistemi eterogenei, questo
implica la capacità di comunicare con altri sistemi e protocolli. Il calcolo distribuito ha
un’architettura complessa, che implica la progettazione delle applicazioni e lo sviluppo
dei sistemi in una nuova ottica, andando ad aumentare l’efficienza di manutenzione
della rete nel suo insieme. Molte entità distribuite lavorano per conto di un client
che e↵ettua una richiesta e proprio la presenza di più server fa si che il sistema sia in
grado di tollerare gli errori (fault tolerant), il che è un vantaggio enorme rispetto ai
sistemi centralizzati. Per far sı̀ che il calcolo distribuito diventi efficace e di fatto rivoluzionario, gli sviluppatori delle applicazioni distribuite devono fare tutto il possibile
per minimizzare la complessità delle architetture e della manutenzione, integrando i
vari software con le varie piattaforme. La progettazione di applicazioni basate su di
un’architettura di tipo client-server necessita della modularizzazione delle applicazioni
e delle relative funzioni in componenti discrete. Queste componenti devono essere legate solamente da dati incapsulati e funzioni che possono essere spostate da un sistema
ad un altro. Questo modello di progettazione dà ai software basati sull’architettura
client-server una maggiore adattabilità e flessibilità.
2.2 Classificazione dei sistemi client-server in base alla topologia
2.2
31
Classificazione dei sistemi client-server in base
alla topologia
Esistono tre tipi di sistemi client-server [25]:
• Due livelli (Two-tiers).
• Tre livelli (Three-tiers).
• N-livelli (N-tiers).
2.2.1
Modello a due livelli (two-tiers)
I due livelli di un’applicazione basata su questo tipo di sistema sono generalmente
collegati dalla rete, ma in alcuni casi entrambi i livelli possono essere presenti sulla
stessa macchina. La tendenza è quella di centralizzare la logica dell’applicazione sul
server, rendendo la manutenzione del codice più semplice. L’architettura client-server
è per definizione composta da almeno due livelli, dove il client è il primo livello mentre
il secondo livello è costituito dal server. Il client richiede i servizi al server, comunicando direttamente con esso senza nessun altra entità intermedia. Un’illustrazione del
modello a due livelli è mostrata in figura 2.4.
CLIENT
APPLICAZIONE
LIBRERIE
INTERFACCIA
DI RETE
INTERFACCIA
DI RETE
LIBRERIE
APPLICAZIONE
SERVER
Figura 2.4: Modello client-server su due livelli.
Un esempio tipico di applicazione che implementa questo modello è il Database
32
2 Client-server computing
Server, in cui le richieste (query SQL) vengono fatte dall’applicazione e poi processate
dal database per l’esecuzione. I risultati vengono quindi mandati indietro attraverso
lo stesso meccanismo, ma nella direzione opposta.
I sistemi a due livelli presentano vari vantaggi:
• Permettono di avere un’applicazione con un’interfaccia grafica più accattivante,
rispetto a quanto fosse possibile con le precedenti tecnologie.
• L’implementazione è più veloce e meno complicata rispetto ai sistemi con un
numero maggiore di livelli.
• O↵rono la possibilità di una gestione semplice e flessibile.
• La disponibilità di strumenti ben integrati come quelli messi a disposizione dai
produttori di DBMS.
Contrariamente vi sono alcuni svantaggi con le architetture su due livelli:
• Lo sviluppo dell’applicazione dev’essere portato avanti anche lato client, la ma-
nutenzione del client è di conseguenza costosa; infatti in un’architettura a due
livelli il client è generalmente fat client;
• Maggiore carico della rete: poiché l’elaborazione dei dati avviene sul client, i
dati devono essere trasportati nella rete, portando uno stress maggiore alla rete.
• La procedura di distribuzione del software per il modello in questione è complicata. Siccome la logica dell’applicazione si trova anche lato client, tutte le
macchine che ne ospitano uno devono essere aggiornate in caso di una nuova
release. Questa procedura oltre che essere complicata, costosa e soggetta ad
errori, porta via molto tempo.
• Le macchine client sono considerate deboli in termini di sicurezza e sono relativamente facili da corrompere.
• Le librerie necessarie all’esecuzione dell’applicazione devono essere caricate sul
client.
• L’architettura su due livelli causa problemi quando è implementata su Internet.
2.2.2
Modello a tre livelli (three-tiers)
Più la logica dell’applicazione è distribuita fra i vari livelli dell’architettura più diventa
difficile raggiungere un buon livello di riusabilità. Per evitare di includere la logica
dell’applicazione sia a livello del server che lato client, un terzo livello software può
2.2 Classificazione dei sistemi client-server in base alla topologia
33
essere inserito nel mezzo. In questo caso si parla di un’architettura a tre livelli (threetiers), dove la maggior parte della logica si trova nel livello intermedio e dove ogni
livello corrisponde ad un servizio che viene messo a disposizione dal sistema. Con
questo tipo di struttura quando è necessario cambiare la logica dell’applicazione è
sufficiente modificare solo il livello intermedio. Ogni livello architetturale può essere
associato ad un specifica categoria logica:
• Rappresentazione (GUI) dei servizi per l’utente: include la manutenzione dell’interfaccia grafica per l’utente e la presentazione di ció che gli utenti vedono
sul monitor.
• Servizi dell’applicazione e della logica: includono l’esecuzione di applicazioni e il
flusso del programma di controllo, cioè la logica che si occupa della convalida dei
dati e delle richieste/risposte nella comunicazione fra i processi dei vari livelli.
• Core server: si riferisce al server che esegue e↵ettivamente le richieste e che
eventualmente gestisce la base di dati sottostante. In questo caso la logica del
server interagisce con la gestione, l’accesso e la sicurezza dei dati.
Sulla base di queste tre categorie logiche, i tre livelli dell’architettura del sistema
client-server sono mostrati in figura 2.5.
PROXY SERVER
LIBRERIE
APPLICAZIONE
INTERFACCIA
DI RETE
INTERFACCIA
DI RETE
INTERFACCIA
DI RETE
LIBRERIE
LIBRERIE
APPLICAZIONE
APPLICAZIONE
CLIENT
SERVER
Figura 2.5: Modello client-server su tre livelli.
Il server del livello intermedio funziona come un proxy per tutte le richieste che
vengono dai client, inoltrandole al Core server e restituendo il risultato al client dopo
che la richiesta è stata processata. Oltre a funzionare come un livello intermedio, il
34
2 Client-server computing
proxy server coordina l’esecuzione dei lavori sul Core server.
Quest’architettura permette di creare un ambiente di lavoro più sicuro per il server
che svolge le richieste. Ma anche per questo modello ci sono un paio di inconvenienti:
• la necessità di avere un piccolo processo (listener) all’interno del server intermedio;
• tutte le richieste del client devono essere trasmesse in una rete tramite un
protocollo ben definito.
I confini fra i vari livelli sono di tipo logico.
Primo livello (client). La responsabilità principale di questo livello è quella di
ricevere gli eventi degli utenti, controllare l’interfaccia utente e rappresentare i dati
sull’interfaccia. Poiché con questa architettura la maggior parte del software è rimosso
dal client, questo è sottile (thin).
Secondo livello (application/proxy server). La parte complessa della logica dell’applicazione è all’interno di questo livello ed è disponibile per il livello client,
quando questo la richiede. Tale livello costituisce l’entità centrale per la soluzione dei
problemi presenti nel modello a due livelli, anche proteggendo l’accesso diretto di dati.
Terzo livello (core server). Questo livello è responsabile della memorizzazione
dei dati, spesso tramite un File Server e un gestore di basi di dati.
I livelli sopra elencati possono essere eseguiti tutti in un’unica e medesima macchina, in quanto è importante che il sistema sia ben strutturato e che la progettazione
dei confini fra i vari software esistenti nei diversi livelli sia ben definita. Alcuni dei
vantaggi derivanti dall’utilizzo del modello a tre livelli includono:
• La manutenzione delle applicazioni è centralizzata perché la logica necessaria
agli utenti finali è nel server intermedio. Ciò permette di eliminare una delle
problematiche più importanti che è presente nel modello tradizionale a due livelli:
la distribuzione del software.
• Attraverso la separazione netta fra l’interfaccia utente, il controllo e la presentazione dei dati dalla parte logica dell’applicazione più client possono accedere
ad una vasta gamma di applicazioni messe a disposizione dal server. I vantaggi
principali per le applicazioni client sono due: uno sviluppo più rapido grazie al
riutilizzo delle componenti logiche già esistenti ed una fase di test più breve, in
quanto le componenti del server sono già state testate a parte.
2.2 Classificazione dei sistemi client-server in base alla topologia
35
• Molti utenti sono in grado di accedere ad una vasta gamma di applicazioni server,
proprio perché tutte le applicazioni logiche sono messe a disposizione sul server
del terzo livello.
• Di regola i server sono sistemi fidati (trusted ) e l’autorizzazione è più semplice
rispetto a quella di numerosi client non attendibili, cosı̀ che la protezione e la
sicurezza dei dati sono più semplici da ottenere. Pertanto, questo sistema ha
senso anche per l’esecuzione di tutti quei processi critici in cui la sicurezza dei
dati sensibili sul server è uno dei punti chiave.
• La ridefinizione delle strategie di memorizzazione non influenza i client. Nei
sistemi ben progettati, il client accede ai dati attraverso un’interfaccia stabile
che incapsula tutti i dettagli della memorizzazione.
• Il bilanciamento del carico è più facile grazie alla separazione della logica dell’applicazione dal Core server.
• Il bilanciamento dinamico del carico: nel caso in cui vi siano dei colli di bottiglia
in termini di prestazioni il processo del server può essere trasferito ad altri server
in fase di esecuzione.
• La necessità di avere un hardware meno costoso per quanto riguarda il client
(thin).
• La gestione di un qualsiasi cambiamento nella logica è più facile e più veloce da
eseguire, perché la componente logica è implementata sul server, quindi in un
unico posto piuttosto che su numerosi client.
• La modularità dei vari livelli rende più facile modificare o sostituire un livello
senza che vengano interessati gli altri livelli.
• I client non hanno bisogno di avere le librerie native caricate a livello locale, ma
queste possono essere gestite centralmente.
• Il server principale può non essere direttamente visibile a Internet.
Un ulteriore vantaggio dell’architettura a tre livelli è che mappa in modo del tutto
naturale il Web, con un browser Web che agisce come thin client e un server Web che
agisce come application server.
Alcuni svantaggi di questo modello invece sono:
• Il client non mantiene una connessione persistente e diretta al server principale
(come nel caso di un Database Server).
• Può essere necessario un proxy server separato.
36
2 Client-server computing
• Nel caso in cui venga utilizzato un proxy server separato puó venire generato un
traffico di rete maggiore.
• Il protocolli di rete utilizzati possono essere protocolli proprietari.
L’architettura a tre livelli può essere facilmente estesa a N livelli, con dei livelli
aggiuntivi necessari a fornire una maggiore flessibilità e scalabilità. Ad esempio, il
livello intermedio del modello a tre livelli potrebbe essere diviso in due, con un livello
per il server Web e un altro per il server delle applicazioni.
Architettura a tre livelli e Internet.
Con il rapido sviluppo di Internet e delle tecnologie Web, le applicazioni clientserver in esecuzione su Internet e intranet stanno diventando un nuovo tipo di calcolo
distribuito. Una tipica applicazione web utilizza la seguente architettura su tre livelli.
• L’interfaccia utente viene eseguita sul desktop come client.
• Il client è collegato (attraverso uno o più collegamenti immediati al server) ad
un Web server, che può essere un magazzino per delle applicazioni scaricabili (le
componenti software).
• Il server web è, a sua volta, sostenuto da un Database Server che tiene traccia
delle informazioni specifiche per l’interesse del client e la relativa storia.
• Queste applicazioni web si basano su standard di Internet (HTTP, HTML, XML,
ecc).
2.2.3
Modello a N livelli (N-tiers)
Nel modello computazionale a N livelli gli sviluppatori sono obbligati a progettare
le componenti secondo un ben preciso schema che rappresenti le entità, i rapporti, le
attività e le regole, per una distribuzione ottimale delle funzioni tra livelli logici e fisici,
consentendo un migliore utilizzo delle piattaforma hardware e delle risorse condivise.
Un altro aspetto della suddivisione su N livelli è che sia gli sviluppatori di applicazioni
che gli amministratori sono in grado di identificare i colli di bottiglia e quindi:
• aggiungere più hardware dove necessario, permettendo un bilanciamento migliore del carico;
• duplicare i servizi per avere una disponibiltà continua in caso di fallimento (failover ).
La suddivisione può essere e↵ettuata fra la logica delle componenti dell’applicazione,
la sicurezza logica e la logica di presentazione, il calcolo ad alta intensità e le componenti con un alto I/O e cosı̀ via. Nella progettazione di un sistema con questa
37
2.3 Client-server: vantaggi e svantaggi
topologia l’approccio che viene più comunemente utilizzato è quello con un’architettura su tre livelli. I modelli su tre o N livelli sono simili, se non per il fatto che quello su
quest’ultimo permette di definire un maggior scomposizione e quindi modularitá dei
servizi. Perció, per la distribuzione dei servizi di alcuni sistemi spesso si opta per una
struttura con ben più di tre livelli, infatti un’infrastruttura che supporta tre livelli è
spesso composta da svariate macchine e servizi, le cui funzionalità non fanno parte
della progettazione. In figura 2.6 è illustrata l’architettura N-tier.
Server 1
Server 2
CLIENT
Server 3
SERVER N
Server X
Server N-2
Figura 2.6: Modello client-server su N livelli.
Un sistema client-server su N livelli o↵re numerosi vantaggi rispetto ai modelli
tradizionali su uno o due livelli, fra cui:
• migliori prestazioni complessive;
• logica dell’applicazione centralizzata;
• raggiunto un livello di protezione nettamente più avanzato.
2.3
Client-server: vantaggi e svantaggi
2.3.1
Vantaggi
Ci sono diversi vantaggi associabili al modello di client-server computing:
• Prestazioni e carico di lavoro ridotto: l’elaborazione è ripartita tra il client
e il server, quindi le prestazioni dell’applicazione non sono legate principalmen-
te alle caratteristiche della postazione di lavoro (desktop); questa deve essere
solamente in grado di eseguire il software del client (aumentando la durata dei
vecchi PC, da un punto di vista dell’utilità nel tempo). Di conseguenza c’è anche l’e↵etto di riduzione del carico sulla rete che collega la stazione di lavoro al
server, che invece di inviare tutte le richieste del client avanti e indietro, si limita
a inviare solo le domande e le risposte dal server dell’applicazione.
38
2 Client-server computing
• Indipendenza dalla stazione di lavoro: gli utenti non sono limitati a un solo
tipo di sistema o piattaforma, in quanto è possibile avere sistemi compatibili
con tutte o quasi le stazioni di lavoro (in base al tipo e alla versione del sistema
operativo), in modo del tutto trasparente.
• Interoperabilità dei sistemi: il modello client-server, non permette solo
di cambiare in modo del tutto trasparente una componente, ma dà anche la
possibilità alle diverse componenti o sistemi (client, rete o server) di lavorare
assieme.
• Scalabilità: la natura modulare del sistema client-server permette sostituzioni
senza danneggiare il resto del sistema. Per esempio, è possibile aggiornare il
server ad una macchina più potente, senza cambiamenti visibili all’utente. Questa capacità di cambiare le componenti del sistema rende il modello client-server
particolarmente aperto all’introduzione di nuove tecnologie, sia hardware che
software.
• Integrità dei dati: è preservata, in quanto il server può usufruire e fornire un
numero di servizi che proteggano i dati come, l’archiviazione crittografata dei file,
il backup in tempo reale (mentre i dati stanno venendo elaborati), il mirroring
del disco (dove i dati sono automaticamente duplicati su un’altra partizione
dello stesso disco fisso), la duplicazione dei dati (i dati vengono automaticamente
scritti su un disco rigido diverso), l’elaborazione delle transazioni che consente di
tenere traccia delle modifiche apportate ai dati e di correggere eventuali problemi
che possono sorgere (ad esempio in caso di crash del server).
• Accessibilità dei dati: poiché il server detiene la maggior parte dei dati in una
posizione centralizzata, più utenti possono accedere e lavorare simultaneamente
sui dati garantendone una maggiore condivisione.
• Amministrazione del sistema: l’ambiente client-server é particolarmente maneggevole, favorendo una gestione centralizzata del sistema. Inoltre, poiché i dati
sono centralizzati, la gestione di questi può anch’essa essere centralizzata. Alcune delle funzioni di amministrazione del sistema sono relative alla gestione della
sicurezza, dell’integrità dei dati e il recupero del sistema in caso di fallimenti.
• Servizi integrati: tutte le informazioni che il client ha il diritto di utilizzare
sono disponibili sulla propria stazione di lavoro, tramite l’interfaccia, cosı̀ che non
vi sia la necessità di modificare le modalità di accesso diretto alle informazioni.
• Mascheramento dell’accesso fisico ai dati: l’accesso ai dati memorizzati in
un punto qualsiasi della rete, dal PC locale, al server locale o anche al server su
2.3 Client-server: vantaggi e svantaggi
39
WAN, avviene utilizzando lo stesso tipo di richiesta dei dati. L’unica di↵erenza
può essere dovuta ad una riduzione delle prestazioni, ad esempio se la larghezza
di banda della rete è insufficiente.
• Indipendenza dal luogo di trattamento dei dati: gli utenti accedono tramite una stazione di lavoro senza nessuna preoccupazione riguardante l’ubicazione
o la tecnologia dei processori coinvolti. Con un sistema utente centrico il desktop fornisce il punto di accesso al sistema (ed eventualmente al gruppo di lavoro,
servizi aziendali inclusi), senza nessun legame con la piattaforma di esecuzione
dell’applicazione.
• Costi operativi ridotti: il costo dell’hardware e del software è in continua
discesa, il che significa che il valore di calcolo è in continuo aumento. Il modello
client-server o↵re un modo per sfruttare questo andamento, sostituendo i sistemi
di grandi dimensioni spesso molto costosi, con quelli meno costosi e più piccoli
ma collegati in rete.
• Costo dell’hardware ridotto: il costo dell’hardware può essere ridotto, in
quanto è solo il server che richiede lo spazio e la potenza di elaborazione sufficiente per memorizzare e gestire l’applicazione.
• Costi di comunicazione sono ridotti: l’applicazione svolge parte delle ope-
razioni lato client, inviando solo una richiesta per l’accesso ai servizi del server
attraverso la rete, quindi una minore quantità di dati passa attraverso la rete.
2.3.2
Svantaggi
Pure gli svantaggi connessi all’uso del modello computazionale client-server sono diversi:
• Costi di manutenzione: il principale svantaggio di questo modello è dato
dall’aumento del costo del personale amministrativo e di sostegno per mantenere
il server. In genere l’amministratore di rete può prendersi carico anche della
gestione e manutenzione del server, di controllare l’accesso degli utenti ad esso
e di supportare le relative applicazioni. Tuttavia, quando il numero degli utenti
del server aumenta, o non appena aumenta la quantità di informazioni gestite
dal server stesso, diviene necessario assumere un amministratore del server.
• Costo della formazione: la formazione può comportare dei costi aggiuntivi,
in quanto il personale d’amministrazione deve acquisire familiarità con il sistema
operativo e l’applicazione, specialmente lato server.
40
2 Client-server computing
• Costo dell’hardware: quando si vuole avere un server con delle buone presta-
zioni e un’integrità dei dati ottima si verifica un aumento dei costi dell’hardware,
dovuto all’acquisto di hardware ad alta potenza (grande quantità di RAM, spazio
su disco rigido, ...).
• Costo del software: il costo complessivo del software è generalmente superiore
a quello dei PC tradizionali.
• Complessità: le componenti che costituiscono l’intero sistema client-server possono essere molte, e, più sono le componenti, più sono le cose che possono anda-
re storte, rendendo più difficile individuare la sorgente del problema quando si
verificano degli errori o, ancora peggio, quando il sistema si blocca.
2.4
Sviluppo di un sistema client-server
Lo sviluppo nel caso di sistemi client-server è un processo molto diverso dai tradizionali
metodi di sviluppo dei sistemi informativi. Ad esempio, l’approccio nel caso dello
sviluppo di sistemi orientati verso un ambiente centralizzato come quello mainframe e
basato sui tradizionali linguaggi di programmazione che difficilmente può essere usato
per poter ottenere uno sviluppo ottimale di un sistema client-server che si basa sulla
diversità di hardware e software fra le entità coinvolte. Inoltre, gli utenti moderni sono
più esigenti e hanno una conoscenza migliore della tecnologia informatica rispetto agli
utenti che usavano il PC quando questo è comparso. [29]
2.4.1
Strumenti di sviluppo
In un contesto in rapida e continua evoluzione come quello attuale, una delle decisioni
più critiche per lo sviluppo di un’applicazione client-server è la scelta degli strumenti
più adeguati al problema. Come regola generale, i manager tendono a scegliere uno
strumento che abbia un potenziale di sopravvivenza a lungo termine. Tuttavia, la
scelta di uno strumento per la progettazione o lo sviluppo di applicazioni deve essere
guidato dalle esigenze di sviluppo del sistema. Una volta che tali requisiti siano stati
definiti, è opportuno determinare le caratteristiche dello strumento che si vorrebbe
avere. Gli strumenti per lo sviluppo client-server includono:
• Interfaccia grafica (GUI ) per lo sviluppo.
• Costruttore d’interfacce grafiche per le applicazioni.
• Sviluppo orientato agli oggetti, utilizzando un repository centrale per i dati e le
applicazioni.
2.5 Software Development Life Cycle
41
• Supporto per database multipli (gerarchici, in rete, relazionali).
• Accesso ai dati indipendentemente dal modello di dati.
• Definizione di un SDLC (System Development Life Cycle) completo che serva
come supporto dalla progettazione, all’implementazione e alla manutenzione del
progetto.
• Gruppo di sviluppo e di supporto.
• Supporto per gli strumenti di sviluppo appartenenti a terze parti (es: librerie)
• Supporto per piattaforme multiple (sistema operativo, hardware e GUI).
• Supporto del protocollo di rete (TCP / IP, IXP / SPX, NetBIOS, e cosı̀ via).
Non è possibile definire quale sia la scelta migliore per ogni singolo strumento necessario allo sviluppo delle applicazioni, ad esempio non tutti gli strumenti supporteranno
tutte le GUI, i sistemi operativi, i middleware o i database. I manager del progetto devono scegliere uno strumento che si adatti sia alle esigenze di sviluppo delle
applicazioni sia che corrisponda alle risorse umane disponibili, nonché all’infrastruttura hardware. È probabile che il sistema richiederà più strumenti di quanti ne siano
e↵ettivamente utili, assicurarandosi che tutti o la maggior parte dei requisiti siano
soddisfatti. Individuare gli strumenti di sviluppo è solo il primo passo, mentre fare in
modo che il sistema soddisfi i suoi obiettivi a livello di client, server, e di rete è un
altro problema.
2.5
Software Development Life Cycle
Nell’ingegneria del software il System Development Life Cycle (SDLC) è il processo
di creare o alterare i sistemi, e consiste nell’insieme di modelli e metodologie usati
specialmente nell’ingegneria del software per il loro sviluppo. Queste metodologie
costituiscono il framework per pianificare e controllare la creazione di un sistema
informativo: il processo di sviluppo software.
Il SDLC aderisce alle fasi importanti che sono essenziali per gli sviluppatori, come
la pianificazione, l’analisi, la progettazione e l’implementazione e ne esistono svariati
modelli. Storicamente il piú antico è quello a cascata: una sequenza di fasi nelle
quali l’output di ogni fase è l’input della successiva. Generalmente queste fasi seguono
sempre quelle di base, ma molte metodologie a cascata danno diversi nomi alle fasi
e il numero di queste puó variare da 4 a 7. Comunque, non si puó parlare di un
modello SDLC definitivamente corretto, in quanto ogni fase puó essere caratterizzata
e suddivisa in varie fasi.
42
2 Client-server computing
Nel modello a cascata (waterfall model) ogni fase è costruita sovrapponendone una
sull’altra, prendendo l’output della fase precedente, aggiungendo ulteriore lavoro e
producendo dei risultati che sono influenzati da quelle precedenti. Questo tipo di
approccio top-down serve per soddisfare le intenzioni originarie mantenendo la qualitá
del prodotto.
Nei prossimi paragrafi sono descritte le fasi principali, quelle che possiamo considerare
essere la base di uno sviluppo, cosı́ come sono mostrate in figura 2.7.
PLANNING
REQUISITI
(definizione)
DESIGN
SVILUPPO
TEST
(integrazione)
INSTALLAZIONE
Figura 2.7: SDLC: fasi base.
2.5.1
Pianificazione
La fase di pianificazione stabilisce una vista ad ampio spettro di quello che sará il
software finale, usandola per definire la struttura base del progetto, valutare la fattibilitá e i rischi associati ad esso, descrivendo una gestione appropriata e gli approcci
piú tecnici.
La parte piú critica di questa fase è la definizione ad alto livello dei requisiti del prodotto, soprattutto riferito ai suoi obiettivi, mentre tutti i requisiti del software devono
essere definiti nella fase relativa.
L’output di questa fase consiste dei piani di configurazione della gestione, un piano di
assicurazione della qualitá e il piano del progetto con il relativo programma di lavoro
che include le attivitá per la fase successiva.
2.5.2
Definizione dei requisiti
Questo processo prende in input gli obiettivi identificati nella sezione dei requisiti ad
alto livello della fase di pianificazione. Ogni obiettivo viene quindi raffinato in un
insieme di uno o piú requisiti. Questi requisiti definiscono:
2.5 Software Development Life Cycle
43
• le funzioni principali dell’applicazione desiderata,
• le aree dati operative,
• entitá dati iniziali.
Questa fase consiste nel ripartire il sistema in parti di↵erenti e disegnare un diagramma
per un’analisi dettagliata. Analizzare gli obiettivi del progetto, ripartire le funzionalitá
che devono essere create e coinvolgere gli utenti cosı́ che possano essere definiti dei
requisiti definitivi.
L’output di questa fase è costituito da un documento contenente la lista dei requisiti
e da un piano di lavoro aggiornato.
2.5.3
Progettazione
Questa fase ha in input i requisiti definiti nella precedente. Per ogni requisito identificato, viene prodotto un insieme di uno o piú elementi. Gli elementi di progettazione
descrivono le funzionalitá desiderate nel software e generalmente includono diagrammi, tabelle con regole e anche pseudocodice. Questi elementi di progettazione hanno
il fine di descrivere il software abbastanza in dettaglio da consentire ad un programmatore esperto di poterlo sviluppare con poche altre informazioni in piú.
L’output della fase sono i documenti di progettazione e l’aggiornamento dei requisiti
e del piano di lavoro.
2.5.4
Sviluppo
La fase di sviluppo prende in input gli elementi prodotti dalla fase di progettazione.
Per ogni elemento, un insieme di uno o piú implementazioni software vengono prodotte.
Dunque, in questa fase viene e↵ettivamente scritto il codice di programmazione dei
vari sottosistemi. Inoltre gli sviluppatori e↵ettuano i controlli necessari sui singoli
elementi (unit testing) e sui moduli interi.
L’output di questa fase include un insieme completo di software che soddisfa i requisiti
e gli elementi di progettazione precedentemente documentati, un sistema di supporto
che descrive le operazioni del software (online help), un piano di test che descrive i
vari casi in cui validare la correttezza e la completezza del software. Inoltre vengono
aggiornati i requisiti e il piano di lavoro.
2.5.5
Integrazione e test
Durante questa fase, le implementazioni software, l’online help e i dati per il test vengono migrati dall’ambiente di sviluppo ad un altro ambiente analogo, necessario per la
fase di test. Quindi, tutti i casi di test vengono eseguiti per verificare la correttezza e
44
2 Client-server computing
la completezza del software. Successivamente l’esecuzione della suite di test conferma
la robustezza e la completezza delle potenzialitá di migrazione. Inoltre, i dati vengono
preparati per un uso in produzione, vengono identificati gli utenti e collegati ai ruoli
a loro appropriati.
L’output della fase di integrazione e di test include l’insieme dei software opportunamente integrato, un sistema di aiuto online, un mappa d’implementazione, un piano
di messa in produzione che descrive i dati e gli utenti.
2.5.6
Installazione
Nella fase d’installazione, le implementazioni software, l’online help e i dati iniziali
sono caricati nel server di produzione (deployment). A questo punto tutti i casi
di test per verificare la correttezza e la completezza del software sono stati eseguiti.
Successivamente i test vengono nuovamente eseguiti per validare il sistema e come
prerequisito per l’accettazione del software da parte del destinatario.
L’output di questa fase include un’applicazione in produzione e una test di suite
completa.
2.6
Client-server: sicurezza
Una minaccia per la sicurezza è definita come la circostanza, la condizione, o un evento
che abbia la possibilità di causare qualche tipo di difficoltà distruttiva a dati o risorse
di rete. La divulgazione di dati riservati (disclosure), la modifica non autorizzata o
sbagliata dei dati (data integrity), la negazione del servizio (Denial of Service) e la
frode sono alcune delle possibili minacce ad un qualsiasi sistema informativo. Nel caso
di un sistema distribuito la sicurezza è una questione delicata, specialmente nel caso
in cui ci si trovi in una rete aperta come Internet. Tuttavia, per ogni sistema di questo
tipo si presentano delle questioni da trattare con metodi diversi a seconda del contesto
e delle politiche di sicurezza e protezione che sono state definite nell’organizzazione,
azienda o sistema specifico. I temi principali nel caso di un sistema di tipo clientserver sono l’autorizzazione e l’autenticazione. Per queste operazioni esistono vari
meccanismi che permettono di gestirle, fra cui la protezione con password, con smart
card crittografate o attraverso la biometria.
I problemi di sicurezza nel client-server computing possono essere dovuti alle seguenti
falle:
• sicurezza credenziali: si presentano quando un individuo qualsiasi riesce ad otte-
nere l’accesso non autorizzato a un computer attraverso le credenziali di accesso
di qualche utente.
45
2.6 Client-server: sicurezza
• sicurezza del software: alcuni difetti (bug) nel software possono causare la presenza di errori nel sistema compromettendo i risultati.
• uso incoerente: possono accadere quando due usi diversi di un sistema contrastano su un unico punto di sicurezza;
• sicurezza fisica: si presentano quando un qualsiasi vi è un qualsiasi accesso fisico
alla macchina che ospita il server o una delle sue componenti (ad esempio: se
un malintenzionato riesce ad accedere alla sala in cui è contenuta la macchina
fisica e porta via l’hard disk o manomette il sistema).
Gli ultimi due tipi di falle possono essere eliminate grazie ad un’attenta progettazione
e implementazione del sistema, mentre per risolvere le falle dovute ai problemi di
sicurezza fisica possono essere utilizzati dei metodi di protezione migliori. Questi
metodi di protezione e sicurezza possono essere classificati nelle seguenti categorie:
• sicurezza basata sulla fiducia (trust based ),
• sicurezza attraverso segretezza,
• schema della password,
• sistema biometrico.
2.6.1
Le minacce di sicurezza emergenti
Possiamo identificare le minacce di sicurezza emergenti dei sistemi client-server come:
• minacce all’ambiente di elaborazione locale da mobile code
2
• minacce ai server che possono includere l’impersonificazione, le intercettazioni,
i denial of service o la modifica dei pacchetti di rete.
Il metodo di protezione consiste nella ricerca di dati dannosi e frammenti di programma
che sono trasferiti dal server al client filtrando i dati e programmi noti per essere
pericolosi.
2.6.2
Server: possibili minacce
Le possibili minacce di sicurezza al server possono essere dei seguenti tipi:
• L’intercettazione è l’attività di ascoltare in modo passivo i dati inviati attraverso
la rete. Questo sistema consente ad un malintenzionato di ottenere la trascrizione
2 è
un software trasferibile fra sistemi diversi, ad esempio, trasferibili attraverso la rete o tramite
una penna USB, ed eseguito su un sistema locale, senza l’esplicita esecuzione da parte del destinatario.
46
2 Client-server computing
completa delle attività di rete e in tal modo di ottenere informazioni sensibili,
come password, dati e procedure per svolgere delle funzioni. La crittografia può
impedire gli intercettatori dall’ottenere dati che viaggiano su reti non protette.
• Denial of service è la situazione in cui un utente rende il sistema inutilizzabile per
gli utenti legittimi monopolizzando o danneggiando una risorsa in modo che non
possa essere utilizzata. Le forme più comuni di questo attacco sono le seguenti:
– Sovraccarico di servizio (Service Overloading): un server può essere reso
inutilizzabile tramite l’invio di una grande quantità di richieste di servizio illegittime, atte a consumare le sue risorse (in particolare il ciclo di
CPU). In una tale situazione il server può negare (per limiti fisici o anche
implementativi) le richieste di servizi che invece sono legittime.
– Inondazione di Messaggi (Message flooding): si tratta di un processo che
punta a saturare il disco del server inviando ripetutamente e concorrentemente richieste o file di grandi dimensioni. Questo può causare il blocco
del disco.
– Attacco di risposta (Replay Attack ): è una forma di attacco di rete che
consiste nell’impossessarsi di una credenziale di autenticazione comunicata
da una macchina ad un altra e riproporla successivamente simulando l’identità dell’emittente. In genere l’azione viene compiuta da un attaccante
che s’interpone tra i due lati comunicanti (man in the middle). Questo tipo di minaccia può essere risolto utilizzando dei token di sessione generati
pseudocasualmente, oppure utilizzando una marca temporale e all’interno
nel corpo del messaggio crittografato.
Capitolo 3
LHC e CMS
“Physics is the universe’s operating
system.”
Steven R. Garman
3.1
LHC
Il Large Hadron Collider (LHC)[30], è il piú grande e potente acceleratore di particelle
mai costruito. L’acceleratore è collocato in un tunnel circolare di 27 km di circonferenza, inizialmente scavato per ospitare il Large Electron Positron Collider (LEP)[31],
situato a circa 100m sotto la campagna che circonda Ginevra a cavallo della frontiera
franco-svizzera. LHC accelera due fasci di protoni circolanti in senso opposto, ognuno
contenuto in un tubo a vuoto, ed è stato disegnato per far collidere i due fasci ad
un’energia nel centro di massa di 14 TeV (1 TeV = 1 miliardo di elettronvolt = 101 2
eV1 ). Le collisioni avvengono in quattro punti. In corrispondenza di queste zone di
collisione sono stati installati quattro grandi apparati sperimentali: ATLAS (A Toroidal LHC Apparatus), CMS (Compact Muon Solenoid), LHCb ed ALICE (A Large Ion
Collider Experiment). Questi si occupano di rivelare le collisioni prodotte da LHC e,
a valori nominali, produrranno una quantità di dati pari a quella che oggi producono
l’insieme delle reti di telecomunicazione europee! Due di questi, ATLAS e CMS, sono
rivelatori dedicati ad uno studio generale della fisica di LHC. I restanti due (ALICE
e LHCb) sono più piccoli e più specializzati.
I primi fasci di protoni sono stati fatti circolare, a bassa energia e senza farli collidere
tra loro, il 10 settembre 2008. Dopodiché LHC è tornato operativo solo il 19 novembre
1 Un
elettronvolt (simbolo eV) è l’energia acquistata da un elettrone libero quando passa attraverso
una di↵erenza di potenziale elettrico di 1 volt.
48
3 LHC e CMS
2009. Il 23 novembre 2009 i 4 esperimenti hanno registrato i primi eventi da collisioni
protone-protone di LHC.
Figura 3.1: Il progetto LHC.
Le ricerche e↵ettuate con LHC serviranno per lo studio della fisica ad alte energie,
per la conferma delle attuali teorie della fisica ed in particolare della verifica del Modello Standard. Il Modello Standard è una teoria della fisica che spiega esattamente
una vasta gamma di fenomeni subnucleari, lasciando tuttavia ancora senza risposta
molte domande fondamentali. Di conseguenza i fisici ritengono che quello di cui siamo
a conoscenza non sia tutto e questo è il motivo per cui si sta cercando la nuova fisica
che sta oltre il Modello Standard, che permetterà loro di arrivare ad una teoria più
completa.
3.2
CMS
CMS (Compact Muon Solenoid)[32] è uno dei due grandi esperimenti general-purpose
di fisica delle particelle installati all’acceleratore protone-protone LHC del laboratorio
CERN di Ginevra. Circa 3600 persone da 183 istituti scientifici di 38 stati formano la
collaborazione CMS che ha costruito il rivelatore. Il rivelatore CMS è capace di studiare tutti gli aspetti fisici delle collisioni protone-protone ad un’energia nel centro di
49
3.2 CMS
massa di 14 TeV. L’apparato sperimentale contiene sotto-rivelatori capaci di misurare
l’energia e l’impulso di fotoni, elettroni, muoni e altre particelle create nelle collisioni.
È suddiviso geometricamente in una parte cilindrica centrale (barrel ) chiuso alle due
estremità da due tappi (endcaps). Il rivelatore piú vicino al punto di collisione è il
tracciatore al silicio. Attorno ad esso vi è il calorimetro elettromagnetico, che è poi
seguito dal calorimetrico adronico. Il tracciatore ed i calorimetri sono collocati all’interno del magnete solenoidale superconduttore che genera un campo magnetico di 4
Tesla. All’esterno del magnete vi è il sistema di rivelazione dei muoni, che è collocato
nel giogo in ferro che chiude le linee di forza del campo magnetico. L’intero apparato
sperimentale di CMS ha un diametro di 15 m, è lungo 21m ed ha un peso totale di
oltre 12000 tonnellate.
Figura 3.2: Struttura del rivelatore CMS.
Ognuno dei 5 sotto-rivelatori ha dei canali di lettura propri (per un totale di 15 milioni di canali di lettura) attraverso i quali CMS puó raccogliere dati per vari TB/s, di
cui peró solo alcuni saranno selezionati per essere scritti su disco (100 MB/s). Il sistema di selezione on-line (trigger ) è basato su due livelli: uno hardware ed uno software.
Questi permetteranno di ridurre la frequenza dai 40 MHz (frequenza di collisione a
LHC) a 100 Hz (frequenza di scrittura dati), cioè 100 MB/s, che corrispondono alla
scrittura di circa 1 PB di dati (raw data) per ogni anno. La mole di dati scritta de-
50
3 LHC e CMS
ve poi essere resa accessibile ad ogni membro della collaborazione indipendentemente
dalla sua locazione geografica. Inoltre le risorse di calcolo sono messe a disposizione sia
dal centro di calcolo del CERN sia per la maggior parte dei membri della collaborazione, per questo diventa fondamentale mettere a punto un sistema computazionale che
permetta di sfruttare questa potenza di calcolo distribuita. Nell’ottica di soddisfare
le suddette problematiche, CMS ha deciso di fare uso della Grid. L’ammontare dei
dati crescerá nel tempo e il paradigma Grid sembra essere l’unico sistema per rendere
trattabile questa mole di dati (che dovrebbe corrispondere al 10% della massa di dati
prodotti annualmente sulla Terra).
3.2.1
L’ambiente computazionale di CMS
L’utilizzo degli strumenti Grid messi a disposizione dai progetti LCG ed OSG consente
di risolvere il problema piú complicato ed importante, ossia rendere accessibili dati e
risorse distribuiti.
Il modello computazionale distribuito di CMS[33] è stato progettato proprio per servire, elaborare e archiviare il gran numero di eventi che verranno registrati durante
la presa dei dati. Le risorse computazionali sono geograficamente distribuite, interconesse tramite reti ad alta capacità e accedute attraverso la Grid. La scelta di un
sistema distribuito permette la delega delle responsabilità della gestione alle comunità
locali di CMS, accedendo ad ulteriori canali di finanziamento e assicurando un maggiore equilibrio del carico delle risorse disponibile, replicando i dati d’interesse su siti
di↵erenti.
Architettura gerarchica Il modello di calcolo di CMS ha definito una struttura
gerarchica dei vari centri della collaborazione che sono detti Tier. Come mostrato in
figura 3.3 sono presenti quattro livelli:
Tier-0 : del Tier-0 fa parte un solo centro computazionale, localizzato al CERN che
riceve dati dal CMS Data Acquisition System, li archivia e fornisce una prima ricostruzione degli stessi. I dati ricostruiti, assieme ai dati grezzi (raw data), sono distribuiti
sui Tier-1 attraverso una rete privata in fibra ottica che è lo scheletro della rete appositamente costruita per LHC, in modo da interconnettere il CERN e i Tier-1. In
aggiunta al Tier-0, il CERN ospita la CMS Analysis Facilities (CAF)[33] disegnata
per supportare attività che necessitano di un periodo di latenza più breve possibile.
Tier-1 : è il livello sottostante al Tier-0; i centri che ne fanno parte sono distribuiti
in vari paesi; questi siti o↵rono servizi in grado di archiviare, ricostruire e calibrare
dati. Piú in generale questo livello fornisce dei servizi su larga scala, fondamentali per
la gestione dei dati ed e↵ettuati con un lavoro centralizzato. Questo livello assicura
la custodia di una parte dei row data prodotti dal rilevatore CMS e dei dati simulati
51
3.2 CMS
prodotti ai centri Tier-2 connessi.
Tier-2 : sono centri piú piccoli ma piú numerosi di quelli al livello precedente (attualmente più di 50); questi siti forniscono principalmente notevoli risorse computazionali
(CPU) e capacitá di analisi; i Tier-2 sono associati gerarchicamente ad uno specifico
Tier-1 e fanno riferimento a questi ultimi per accedere a degli insiemi di dati (dataset)
molto grandi.
Tier-3 : il livello piú vicino all’utente è il livello Tier-3 (risorsa dipartimentale); i siti
appartenenti a questo livello forniscono le risorse locali per i gruppi e non hanno obblighi formali verso la collaborazione, ma solo responsabilità verso gli utenti.
Tier-0, Tier-1 e Tier-2 sono risorse globali dell’esperimento, mentre i Tier-3 sono risorse a disposizione essenzialmente degli utenti locali.
Figura 3.3: Il modello computazionale di CMS: l’architettura su livelli.
3.2.2
Framework dell’analisi distribuita in CMS
Il modello d’analisi di CMS prevede che le attività siano guidate dalla locazione dei
dati (data driven). Questi ultimi vengono distribuiti attraverso i vari centri computazionali (Tier-2). Al momento della richiesta di processamento di una specifica porzione
di dati, saranno i siti che ospitano i dati richiesti ad o↵rire la potenza di calcolo neces-
52
3 LHC e CMS
saria all’analisi e quindi non saranno i dati ad essere spostati a tempo di esecuzione.
Ovviamente, per permettere tali operazioni in un ambiente distribuito ed eterogeneo,
sono necessarie delle applicazioni adeguate atte ad interfacciarsi con il complesso sistema di calcolo ed a nascondere agli utenti gli aspetti tecnici, garantendo cosı́ un
accesso trasparente alle risorse. Per tali motivazioni è stato sviluppato un’insieme di
strumenti, andando cosı̀ a costituire dei servizi specifici di CMS sopra i servizi Grid già
esistenti. Questi strumenti costituiscono il Data e Workload Management (DMWM)
della collaborazione.
Data Management
Il CMS Data Management ha il ruolo di mettere a disposizione l’infrastruttura e gli
strumenti necessari per gestire la gran quantità di dati prodotti, processati e analizzati in un ambiente computazionale distribuito. Per poter semplificare la gestione dei
dati, i singoli file vengono raggruppati in blocchi (file-block ) aventi una dimensione
conveniente per il loro trasferimento. I file-block sono le unità del dato che vengono
utilizzati per il posizionamento e la replica e sono a loro volta raccolti in dataset, la
cui dimensione e definizione dipendono dal significato fisico dei dati.
Dunque il Data Management mette a disposizione gli strumenti (basi di dati e relative interfacce) che tengono traccia dei dati distribuiti e delle loro locazioni. Oltre
a quest’ultima, vengono tracciate anche le informazioni logiche che sono poi risolte
attraverso dei cataloghi locali ai centri di elaborazione. Le dimensioni dei file sono
adeguatamente grandi (almeno 1GB), in modo da evitare problemi di scalabilitá con i
sistemi di memorizzazione (Storage Element o nastro magnetico che siano) nonché per
ottimizzare il trasferimento dei dati. Questo è reso possibile dalla possibilità di unire
piccoli file di output, prodotti da singoli job, in pochi file grandi (grazie all’operazione
di merge). Il CMS Data Management System è costituito da un insieme di componenti
interoperanti descritte nelle seguenti sezioni.
DBS.
Il Dataset Bookkeeping System (DBS)[34] è il mezzo per descrivere, sco-
prire e usare i dati-eventi di CMS. Questo cataloga le definizioni specifiche dei dati
di CMS quali il numero di run, gli algoritmi e le configurazioni usate per elaborare i
dati assieme alle informazioni relative alla parentela del processamento dei dati. DBS
memorizza le informazioni inerenti ai dati in un formato che ne rende possibile la
consultazione tramite interrogazioni: queste permettono di scoprire quali dati siano
disponibili e come questi siano organizzati logicamente, in termini di file, file-block e
dataset.
DBS viene usato per l’operazione di scoperta dei dati (data discovery) e la configurazione dei job da parte dei sistemi di produzione ed analisi attraverso un’apposita
53
3.2 CMS
interfaccia costituita dalle DBS API. Gli utenti possono scoprire quali dati sono disponibili attraverso il Web o interfaccia a linea di comando (CLI ). DBS o↵re varie
opportunità di utilizzo:
• un DBS globale come singola istanza che cataloga tutti i dati di CMS;
• molti DBS locali utilizzati per descrivere i dati prodotti dalle produzioni Mon-
teCarlo di gruppi di fisica e singoli individui; se necessario i dati catalogati nei
DBS locali possono essere migrati nel DBS globale, secondo opportune procedure
dipendenti dalle caratterstiche dei dati.
DBS è un’applicazione Web costituita da più livelli e con una struttura modulare.
Questo rende possibile e facile adattare il sistema a svariati tipi di database, consentendo una distribuzione (o meglio deployment) che va dalle generiche esigenze di
CMS fino alle installazione individuali. Attualmente i tipi di database supportati sono
ORACLE, MySQL e SQLite.
Il DBS globale è installato al CERN, ed ospita anche alcuni cataloghi di tipo locale,
appartenenti a specifici gruppi di fisica interni a CMS. Ovviamente esistono istanze
locali installate presso altri siti e per usi prettamente privati.
Local Data Catalog.
Come detto in precedenza, un’applicazione di CMS conosce
informazioni realtive solamente ai file logici e per aver accesso ai file fisici si basa su
un servizio locale al sito che funge da catalogo dei file. Ogni sito della collaborazione
mantiene un Trivial File Catalog costituito da un semplice insieme di regole necessarie
a costruire il percorso specifico dei file nel sito, a partire dal nome logico dei file e dal
protocollo d’accesso.
PhEDEx.
Il posizionamento e il sistema di trasferimento dei dati in CMS è im-
plementato da PhEDEx[35]. Questo sistema fornisce un’interfaccia web per definire,
eseguire e controllare le decisioni amministrative sul movimento dei dati: dove i dati
sperimentali devono trovarsi, quali copie devono essere custodite dal sito e quali dati
devono essere replicati su altri siti a seconda delle politiche definite all’interno della
collaborazione, anche per facilitare l’accesso a dati. Inoltre i dati vengono distribuiti
su svariati siti a seconda delle risorse disponibili, degli interessi dei vari gruppi di fisica
e in ultimo anche dalle scelte dei membri delle comunità locali di CMS a cui un sito
fornisce servizi.
Ogni sito ha la libertà di scelta dei sistemi di memorizzazione (Storage Element) da
utilizzare. Per PhEDEx ogni area di memorizzazione distinta è rappresentata da un
nodo. I collegamenti logici fra i nodi definisco la topologia di trasferimento. Il flusso di
lavoro dei trasferimenti inizia quando un utente e↵ettua una richiesta di trasferimento
54
3 LHC e CMS
di dati verso un qualche nodo attraverso un servizio Web dedicato; di conseguenza
la richiesta deve essere approvata dal Data Manager del nodo in questione. Nella
richiesta l’utente specifica quali dati vuole trasferire e dove li vuole trasferire: il nodo
sorgente viene selezionato in modo ottimale e automatico (attraverso una specifica implementazione dell’algoritmo di Dijkstra[36]) fra tutti i nodi che ospitano una replica
dei dati in questione. Questo consente a PhEDEx di bilanciare il trasferimento dei
dati fra sorgenti multiple quando gli stessi dati sono presenti in più nodi. Il sistema
in questione è in grado di tollerare trasferimenti non stabili: quando un trasferimento
fallisce in uno specifico collegamento è possibile utilizzare un’altra replica disponibile.
Da un punto di vista tecnico PhEDEx è basato su agenti software distinti a seconda
delle operazioni che svolgono. Ognuno di essi memorizza il proprio stato e comunica
attraverso un database centrale installato al CERN, basato su ORACLE, utilizzato
dunque come una black board. Alcuni agenti sono centrali al CERN, mentre ogni
sito ha degli agenti che interagiscono con lo Storage Element locale. Gli agenti dedicati al trasferimento dei dati utilizzano varie metodologie di trasferimento (anche a
seconda dei protocolli di trasferimento disponibili nel sito a cui fa riferimento il nodo), rendendo PhEDEx indipendente dalle tecnologie supportate. Un sito Web mette
a disposizione gli strumenti di gestione necessari ad eseguire le operazioni richieste,
quali la possibilità di creare richieste (ad esempio: di trasferimento o cancellazione dei
dati) ed approvarle o meno, permettendo inoltre agli utenti e agli amministratori di
controllare lo stato attuale e storico dei trasferimenti. Oltre a tutto questo PhEDEx
tiene traccia del posizionamento dei dati all’interno del sistema computazionale distribuito, fornendo un supporto indispensabile agli strumenti di analisi che necessitano di
conoscere dove sono localizzati i dati al momento della sottomissione dei job.
CMS ha trasferito oltre 87 PB di dati da quando il progetto PhEDEx è iniziato nel
2004 (figura 3.4).
Workload Management
Il ruolo del sistema di CMS Workload Management[37] è la gestione del flusso di
lavoro necessario al processamento dei dati inteso come: creazione e sottomissione,
monitoraggio dei job e recupero dei risultati. Il Production Agent (ProdAgent)[38]
è ottimizzato per eseguire queste operazioni in un ambiente controllato, come il Tier-0
e i centri computazionali appartenenti al livello Tier-1. Il CMS Remote Analysis
Builder (CRAB) è ottimizzato per sostenere l’analisi dei dati eseguita dagli utenti.
Software di CMS.
Il software per la simulazione, la ricostruzione e l’analisi dei dati
provenienti dal rivelatore è scritto usando la programmazione orientata agli oggetti.
Le applicazioni sviluppate possono essere divise in due categorie a seconda degli scopi.
55
3.2 CMS
Figura 3.4: Velocità dei trasferimenti di PhEDEx dal 2004 al 2008.
La prima categoria consiste del software che si occupa della simulazione delle particelle elementari e della risposta del rivelatore (ossia dell’output atteso). La seconda
categoria si occupa di collezionare e ricostruire i dati, per poi fornire gli strumenti
per l’analisi degli stessi. L’insieme degli strumenti sviluppati in questo ambiente per
la simulazione del rilevatore e la ricostruzione dei dati è chiamato CMSSW (CMS
SoftWare framework). Il software è strutturato nei seguenti elementi principali:
• un framework configurabile per ogni ambiente computazionale, in grado di consentire l’analisi e la ricostruzione degli eventi;
• moduli software per calcoli fisici che possono integrarsi con il framework al mo-
mento dell’esecuzione, operando attraverso i costrutti che sono già disponibili
per l’accesso ai dati;
• strumenti di servizio ed utilità che consistono di due categorie principali di ser-
vizi: fisici (es: routine di calcolo e stampa di istogrammi) e computazionali
(accesso ai dati, comunicazione fra i moduli, etc).
Tipicamente l’utente utilizza questo software sia in maniera interattiva che in modalità batch. Dato il modello computazionale di CMS l’utente, per procedere nell’analisi
dei dati, dovrà interagire con la Grid.
56
3 LHC e CMS
CRAB. L’analisi dei dati in un ambiente distribuito è molto complessa dal punto
di vista computazionale; infatti, nonostante la presenza degli strumenti messi a disposizione dal framework CMSSW, è necessario e↵ettuare molti passi per preparare e
gestire i propri job. I principali sono:
• configurazione dell’ambiente remoto riproducendo le stesse identiche condizioni
dell’ambiente locale
• sottomissione dei job su Grid
• controllo dell’esecuzione dei job
• ritiro dell’output contenente i risultati.
Tutto questo rappresenta un lavoro complesso per un fisico, che tipicamente è interessato principalmente al solo risultato dei suoi job. Per l’utente è quindi necessaria
un interfaccia che esegua degli automatismi che permettano di semplificare il flusso
di lavoro per l’analisi dei dati di CMS. Il CMS Remote Analysis Builder (CRAB)[39]
è stato sviluppato come un’interfaccia orientata all’utente in grado di permettere all’utente finale l’analisi dei dati in un ambiente locale o distribuito, nascondendo le
complessità dellle interazioni con la Grid e i servizi di CMS. Questo software permette
all’utente di lavorare su grandi insiemi di dati distribuiti usando lo stesso algoritmo
di analisi che egli ha sviluppato in locale lavorando su piccoli sottoinsiemi di dati. Le
funzionalità messe a disposizione da CRAB mostrate in figura 3.5 sono:
• Data-discovery e locazione: facilita l’interrogazione con i cataloghi dei dati di
CMS (DBS e PhEDEx) per trovare quali dati sono disponibili e dove possono
essere acceduti.
• Creazione job: raccoglie e comprime localmente il codice dell’utente, con le
relative librerie, e tutto l’ambiente di lavoro che deve essere inviato ai siti remoti
dove i dati sono localizzati.
• Job splitting: decide come configurare ogni singolo job, per quanto riguarda
l’accesso ad un sottoinsieme di file del dataset in modo da distribuire l’uso delle
risorse del Tier-2.
• Sottomissione job: sottomissione ai siti Grid dove sono localizzati i dati richiesti
dall’utente.
• Monitoraggio job: controlla lo stato dei job interagendo con i servizi Grid.
• Ritiro output: i risultati prodotti dai job o vengono copiati nello Storage Element
di un Tier-2 associato all’utente in questione o nel caso di file di dimensioni
57
3.2 CMS
ragionevolmente piccole (pochi MB) possono tornare direttamente all’utente.
è poi possibile pubblicare i dati prodotti, con la loro descrizione e provenienza
all’interno di un DBS locale, in modo che i dati prodotti possano essere utilizzati
per ulteriori analisi o semplicemente condivisi con altri utenti all’interno della
collaborazione.
Figura 3.5: CRAB workflow. WMS può essere inteso sia come gLite WMS che come
glidein WMS.
Strumenti di monitoraggio.
In uno scenario altamente distribuito gli strumenti di
monitoraggio sono dei servizi critici per il successo dell’analisi, come per CMS. Questi
permettono di controllare l’evoluzione degli altri strumenti sviluppati da CMS (CRAB,
ProdAgent, ...), dando una visione completa della struttura operativa. Gli obiettivi
principali che hanno guidato lo sviluppo degli strumenti di monitoraggio sono:
• nessuna fiducia sugli strumenti di monitoraggio locali ai siti;
• avere un visione unica dell’utilizzo degli strumenti di CMS, che sia di alto livello
e da cui sia possibile selezionare e visualizzare i dettagli delle operazioni fino al
livello di un singolo processo;
• mantenere il sistema snello e flessibile: anche a costo di avere qualche informazione non segnalata in modo del tutto adeguato;
• registrare sufficienti informazioni sugli errori in modo che i piani e le azioni
successive possano essere basate sui dati quantitativi e che sia possibile misurare
l’efficacia delle soluzioni;
58
3 LHC e CMS
• individuare le informazioni necessarie alle scelte dei responsabili, cosı̀ che sia
possibile capire come indirizzare le attività degli utenti e su come pianificare i
lavori futuri;
• cercare di non definire a priori tutti i parametri rilevanti.
Il lavoro di monitoraggio è costruito attorno all’idea di un’applicazione che aggrega
informazioni: i vari processi e strumenti inviano messaggi ad un collettore centrale.
Ovviamente ciò implica che in questo modo possono essere raccolte solo le informazioni inviate secondo precise specifiche. In CMS gli strumenti di monitoraggio sono
costituita dalla Dashboard. Quest’applicazione si basa su una base di dati gestita
tramite un server Oracle, una serie di strumenti che collezionano le informazioni provenienti da varie fonti di alimentazione, e da un paio di interfacce Web che attraverso
diverse viste danno l’accesso a livelli di dettaglio di↵erenti, aggregando questi in modo
flessibile e personalizzato.
Le viste principali che sono messe a disposizione sono quella contenente le informazioni
da un punto di vista storico, quella che contiene le informazioni a tempo di esecuzione
relative ai processi di analisi degli utenti e un’interfaccia interattiva che permette di
navigare da una vista ad un’altra fornendo sia estrema flessibilità che dettaglio nello
informazioni.
Capitolo 4
CRAB: evoluzione verso
un’architettura client-server
“Version 1 of any software is full of
bugs. Version 2 fixes all the bugs
and is great. Version 3 adds all the
things users ask for, but hides all the
great stu↵ in Version 2.”
Fred Blechman
La necessitá di ottimizzare l’utilizzo delle risorse di calcolo distribuito in ambiente
Grid ha portato la collaborazione CMS allo sviluppo di applicazioni basate sull’architettura client-server. In questo capitolo vengono illustrate le motivazioni, le problematiche e i dettagli implementativi della strategia adottata nel caso dell’analisi
distribuita.
4.1
Motivazioni dell’evoluzione
CRAB nasce nel 2004 con l’obiettivo di soddisfare le esigenze del modello di analisi di
CMS. In particolare CRAB si propone di consentire agli utenti un accesso efficiente
ai dati distribuiti nascondendo le complessità della Grid. Come è stato precedentemente illustrato (vedi sezione 3.2.2), la prima implementazione di CRAB è basata su
di un’architettura autoconsistente in un’unica entitá, totalmente in mano all’utente
(standalone model ) e capace di soddisfare le esigenze basilari del caso d’uso in questione.
In figura 4.1 è mostrato lo schema con le interazioni e il flusso di lavoro di CRAB.
Dunque i principali livelli d’interazione sono:
60
4 CRAB: evoluzione verso un’architettura client-server
• il middleware della Grid;
• i servizi di Data Management di CMS (ad esempio quelli necessari per la ricerca
dei dati);
• l’ambiente di sviluppo locale (come il software di CMS);
• l’area di lavoro dell’utente sulla User Interface.
Le fasi principali del flusso di lavoro sono:
• preparare l’ambiente di lavoro, che consiste nelle seguenti fasi:
– l’area di lavoro del software CMSSW, opportunamente installata e configurata;
– l’eseguibile e le relative librerie che si vogliono sottomettere alla Grid;
– le variabili d’ambiente necessarie all’interazione con CRAB e la Grid;
• utilizzare CRAB per eseguire i job sulla Grid in modo facile e trasparente:
– creare e sottomettere alla Grid il proprio lavoro;
– controllarne l’avanzamento;
– ritirare l’output del proprio lavoro una volta che questo è terminato;
– e↵ettuare altre operazioni a seconda dell’esito e dei risultati ottenuti.
CRAB standalone è stato usato con successo dagli utenti di CMS a partire dal 2004
fino ad oggi per eseguire l’analisi dei dati simulati (Monte Carlo). Il primo utilizzo
intenso di questo strumento c’è stato a partire dalla primavera del 2006 per la preparazione del Physics Technical Design Report (Physics TDR)[40]. Successivamente
CRAB è stato utilizzato durante le fasi dei test di scala di CMS (data challenges).
L’ultima è stata CSA07[41] durante la quale sono stati sottomessi jobs con CRAB ad
una frequenza di 20000 jobs al giorno distribuiti su circa 40 siti diversi. I primi test
con dati non simulati sono stati e↵ettuati durante il Cosmic Challenge del 2006[42].
Se da un lato le prestazioni e la semplicitá dell’interfaccia di CRAB standalone erano
soddisfacenti per le esigenze della collaborazione in quella fase, dall’altro è stato possibile mettere in evidenza i limiti di scala e soprattutto è stato possibile individuare i
margini di miglioramento, soprattutto dal punto di vista dell’automazione.
Per quanto riguarda i limiti osservati, i principali sono:
• utilizzo del sistema computazionale: l’integrazione con la Grid non è completamente adeguata per le funzionalità e potenzialità che questa mette a disposizione
non permettendo al sistema di scalare. Le maggiori conseguenze sono la lentezza
nell’interazione diretta con la Grid specialmente quando si gestiscono un gran
numero di job;
61
4.1 Motivazioni dell’evoluzione
CRAB
UI
DBS
C
R
A
B
DatasetPath
LFNs, #events, fileblocks
Dataset Discovery
Fileblocks
jdl, job,
SEs
PhEDEx
DLS
RB/WMS
(DLI interface)
Output
Dataset Location
jdl, job
trivial file catalog
CE
LFN !> PFN
File Location
WN ........
Data
SE
Output (also to remote SE)
Figura 4.1: CRAB: flusso di lavoro e interazioni.
• implementazione del modello computazionale: per definizione è possibile suppor-
tare un unico semplice flusso di lavoro. L’assenza di persistenza non consente il
supporto di flussi complessi e concatenati;
• gestione dello strumento software stesso: la distribuzione agli utenti di nuove versioni o di aggiornamenti che spesso includono dei cambiamenti cruciali è
complessa, macchinosa e lenta, in quanto non centralizzata;
• interazione con gli utenti e implementazione delle politiche della collaborazione:
il supporto degli utenti è difficile in quanto tutte le informazioni risiedono su
macchine remote dei servizi o dei vari siti della Grid; inoltre la gestione dei vincoli
della collaborazione è complessa perché non esiste una gestione centralizzata.
Queste costituiscono le principali motivazioni dell’evoluzione da uno strumento ad
un’architettura basata sul modello client-server.
L’introduzione di un server di analisi nell’architettura costituisce l’inserimento di un
livello aggiuntivo fra l’utente e il middleware della Grid, cosı̀ come mostrato in figura
4.2.
62
4 CRAB: evoluzione verso un’architettura client-server
Oltre a far fronte alle limitazioni sopra elencate i vantaggi che si vogliono ottenere
UTENTI
CRAB SERVER
CRAB
SERVER
MYSQL SERVER
STORAGE SERVER
GRID MIDDLEWARE
SITO GRID
SITO GRID
SITO GRID
RISORSE
Figura 4.2: L’aggiunta di un nuovo livello fra la Grid e l’utente.
con l’introduzione del modello client-server sono:
• rendere il più possibile automatico il flusso di lavoro dell’analisi in CMS;
• ridurre il lavoro umano non necessario spostando tutte le azioni automatizzabili
sul server, rendendo il client un’interfaccia semplice e leggera (thin client, vedi
2.1) che funziona come punto d’accesso a tutto il sistema;
• automatizzare il più possibile l’interazione con la Grid, e cioè la sottomissione, la
“risottomissione” intelligente, la gestione dei possibili errori, il ritiro dei risultati
e tutte le operazioni post-mortem dei job;
• raccogliere in un unico sistema centrale l’insieme delle informazioni dei job degli
utenti per poter rivelare eventuali errori e poterli risolvere. Tale aspetto risulta
cruciale nell’ottica di poter controllare i siti e la Grid in tempo reale, soprattutto
in previsione del massiccio incremento legato alla partenza di LHC;
• gestire centralmente gli aggiornamenti dell’applicazione ed eventuali problemi,
cioè avere la possiblità di un’ amministrazione centralizzata.
4.2 Client-server: fattorizzazione del flusso di lavoro
63
Il server dell’analisi distribuita si propone di migliorare la scalabilità dell’intero sistema di calcolo mettendo a disposizione dell’esperimento CMS le funzionalità specifiche
che non possono essere incluse nel middleware della Grid, per definizione generico e
multiuso. Questo nuovo strumento consente di introdurre un insieme di funzionalità
e automazioni mantenendo l’accesso trasparente alle risorse sottostanti, senza nessun impatto reale sugli utenti finali. L’interfaccia proposta, la sua installazione e la
procedura di configurazione rimangono le stesse dello standalone.
4.2
Client-server: fattorizzazione del flusso di lavoro
L’introduzione del paradigma client-server comporta di conseguenza una fattorizzazione delle funzionalitá fra le due entitá in gioco con la conseguente aggiunta di un
nuovo livello nel flusso d’interazione come mostrato in figura 4.3. Il client semplifica
lo strumento standalone senza modificarne l’architettura[43]. É scritto in Python ed
utilizza una base di dati SQLite per memorizzare in modo persistente le informazioni
della singola analisi. Il client viene eseguito dall’utente attraverso la linea di comando
occupandosi di:
• creare i job
• interazione con i servizi di Data Management per la ricerca dei dati e della loro
locazione;
• interazione con l’area di lavoro dell’utente, preparando l’input sandbox che
contiene l’eseguibile dell’utente più le librerie necessarie;
• preparazione dei job: suddivisione del task di analisi in piú job (job splitting),
creazione degli script necessari alla gestione dell’esecuzione del job;
• inviare la richiesta di sottomissione al server passandogli la richiesta XML, la
serializzazione su file XML dei job e l’input sandbox associata;
• una volta che la richiesta è stata presa in carico dal server è possibile:
– controllare lo stato di avanzamento dei job tramite il server;
– ritirari i risultati una volta che questi sono stati processati dal server;
– ri-sottomettere al server i job che sono falliti;
– eseguire altre operazioni sui job, quali: cancellarli o richiedere informazioni
post-mortem.
64
4 CRAB: evoluzione verso un’architettura client-server
UserBox CRAB Client
Proxy
datasetpath
CRAB server
LF
N
DBS
,#
ev
en
Jdl, Job
BOSS DB
ts
,
fil
e
bl
oc
ks
gsiftp server
direct submission available
jdl,
Dataset Discovery
SEs
fileblocks
PhEDEx
DLS (DLI enabled, LFC based)
fileblocks
RB
Job
SEs
Dataset Location
jdl
trivial file catalog
CE
Output
File Location
WN ........
Data
SE
Output
Figura 4.3: CRAB: flusso di lavoro e interazioni con l’introduzione del server.
Il server si occupa del resto del flusso di lavoro, e cioé di tutte quelle operazioni che
non richiedono strettamente l’intervento umano. Dunque esegue in modo automatico
le seguenti operazioni:
• ricevere le richieste dal client in formato XML, verificare i dati in input per poi
deserializzare la descrizione dei job memorizzandola in modo persistente sulla
base di dati;
• soddisfare le richieste di sottomissione del client, inviando i job verso la Grid a
nome dell’utente richiedente;
• controllare lo stato dei job e memorizzarlo nella base di dati locale;
• ritirare i risultati quando i job sono terminati e aggiornare la base di dati con i
relativi codici di uscita;
• ri-sottomettere i job che sono falliti secondo particolari condizioni predefinite;
4.3 Strategia implementativa
65
• eseguire altre operazioni su richiesta del client: fornire informazioni sull’avanzamento dei job, cancellare i job, etc.
4.3
Strategia implementativa
I vantaggi o↵erti da un’architettura client-server non sono certamente senza conseguenze; ad esempio l’introduzione di un nuovo servizio puó rappresentare un singolo
punto di fallimento e l’impossibilità di bilanciare il carico di lavoro. Per far fronte a
tali problematiche è stato deciso di mettere in produzione più istanze del server di
analisi distribuiti fra i vari siti della collaborazione, in modo che in caso di mancata
disponibilitá di un server sia sempre possibile per l’utente accedere trasparentemente
ad un altro.
Un altro aspetto è quello relativo alla progettazione e implementazione, che ovviamente nel caso di un’architettura complessa richiedono uno sforzo maggiore rispetto
ad una semplice applicazione non distribuita.
Per riuscire ad ottimizzare la forza lavoro disponibile e avere un ambiente di lavoro
comune la collaborazione CMS ha deciso di mettere a disposizione dei vari strumenti
del Workload Management una struttura comune detta WMCore[44]. Quest’ultima
è un framework software costituito da una serie di librerie di codice utilizzabili attraverso un insieme ben definito di API1 , spesso corredate da strumenti di supporto allo
sviluppo delle estensioni o altri strumenti ideati per aumentare la velocità di sviluppo
del prodotto finito.[45]
A seconda delle esigenze dettate dagli obiettivi di sviluppo, ogni singolo progetto del
Workolad Management estende il framework per poter aggiungere le funzionalità specifiche sfruttando il concetto di modularitá, che consente una facile separazione delle
attivitá rispetto ad una vasta gamma di funzionalitá.
La possibilità di avere un framework comune fra i vari progetti consente la sinergia
degli sviluppatori aumentando la produttività e riducendo i costi. Inoltre la struttura
per componenti modulari o↵re il vantaggio della sostituibilità e della riusabilitá del
codice, caratteristiche importanti di un software ad alta qualitá. La sostituibilitá del
codice è una proprietá importante che permette ad una componente di essere sostituita
da un’altra (sia durante la fase di progettazione che a tempo di esecuzione), se i requisiti delle componenti sono gli stessi. Di conseguenza, le componenti possono essere
1 Le
Application Programming Interface sono ogni insieme di procedure disponibili al programma-
tore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito.È un
metodo per ottenere un’astrazione, di solito tra l’hardware e il programmatore, o tra software a basso
ed alto livello. Le API permettono di evitare ai programmatori di scrivere tutte le funzioni dal nulla.
Le API stesse sono un’astrazione: il software che fornisce una certa API è detto implementazione
dell’API.
66
4 CRAB: evoluzione verso un’architettura client-server
sostituite anche con una loro versione aggiornata o ad esempio con una componente
alternativa, senza interrompere il sistema nel quale la componente lavora, garantendo
una gestione centralizzata che semplifica le operazioni sopra descritte.
4.4
Architettura del server
Il server ha un’architettura modulare costituita da componenti indipendenti implementate come demoni, dette agenti. Le componenti sfruttano le funzionalità del framework
software messo a disposizione dal Workload Management di CMS. Oltre a queste sono
state sviluppate delle componenti esterne tra cui le principali sono:
• Storage Element API: librerie che forniscono un’interfaccia generica a diversi tipi
di Storage Element attraverso di↵erenti protocolli;
• BossLite: framework per l’interazione con la Grid che fornisce un’interfaccia generica a diversi tipi di middleware consentendo di mantenere in modo persistente
le informazioni sui job sottomessi;
• Message Service: servizio necessario a far comunicare in modo asincrono e persi-
stente le varie componenti secondo il modello publish/subscribe. Questo prevede
una comunicazione asincrona fra vari processi detti agenti in cui sia i mittenti che
destinatari di messaggi dialogano attraverso un tramite, detto dispatcher basato
su una base di dati. Il mittente di un messaggio (publisher ) non è consapevole
dell’identitá dei destinatari (detti subscriber ), ma esso si limita a pubblicare (publish) il proprio messaggio al dispatcher. I destinatari si rivolgono a loro volta al
dispatcher sottoscrivendosi (subscribe) alla ricezione di messaggi. Il dispatcher
quindi inoltra ogni messaggio inviato da un publisher a tutti i subscriber interessati a quel messaggio. Questo implica che ai publisher non sia noto quanti e
quali sono i subscriber e viceversa. In figura 4.4 è mostrato lo schema SQL su
cui il dispatcher gestisce il sistema di messaggistica.
• Credential API: librerie necessarie a gestire le credenziali delegate dagli utenti.
Quasi tutto il software all’interno del server è sviluppato utilizzando il linguaggio di
programmazione Python. Rispetto ad altri linguaggi orientati agli oggetti esso permette di ridurre le linee di codifica, grazie alla sua duttilità e all’esteso insieme di
librerie disponibili che facilitano la programmazione ad alto livello. Il fatto che non
necessita di essere compilato permette una manutenzione facile e veloce.
L’esigenza di memorizzare le informazioni in modo persistente implica l’utilizzo di una
base di dati relazionale (RDMS: Relational database management system). Attualmente quello in uso è MySql 5.0 [46], i cui vantaggi sono che:
67
4.4 Architettura del server
MS_MESSAGE
MSG_ID
TYPE
MS_TYPE
TYPE_ID
SOURCE
DEST
MSG
TIME
MS_SUBSCRIPTION
SUB_ID
NAME
DELAY
MS_PROCESS
PROC_ID
TYPE_ID PROC_ID
NAME
HOST
PID
MS_HISTORY
MSG_ID
TYPE
SOURCE
DEST
MSG
TIME
DELAY
Figura 4.4: Schema SQL del supporto per la gestione del Message Service.
• supporta la maggior parte delle sintassi SQL e rispetta quasi del tutto lo standard
ANSI,
• possiede delle interfacce per diversi linguaggi, fra cui Python,
• viene distribuito con lincenza GNU GPL2 ,
• ha un stabilità elevata data dall’esperienza accumulata e dall’ampio utilizzo in
tutti i settori.
La struttura modulare del server è tale da consentire il supporto a di↵erenti tipi di
basi di dati relazionali con la semplice implementazione di poche classi specifiche per
la definizione dei dettagli dei comandi di interazione con il nuovo sistema (il framework
comune mette già a disposizione le librerie necessarie per l’utilizzo di Oracle).
I parametri sopra specificati, le opzioni specifiche di ogni singola componente e tutte
le informazioni di cui il server necessita sono specificate in un file in formato XML
generato automaticamente durante la fase d’installazione. I parametri possono essere
specificati e modificati dall’amministratore del server a seconda della configurazione
specifica:
2 La
GNU General Public License è una licenza per software libero. È comunemente indicata con
l’acronimo GNU GPL o semplicemente GPL.
68
4 CRAB: evoluzione verso un’architettura client-server
• nome, porta, percorso e tipo di protocollo dell’host di Storage;
• variabili di accesso al server MySql fra cui le credenziali per l’accesso, il tipo di
accesso (locale via socket
3
o remoto) e altri parametri specifici;
• file di configurazione dei servizi del middleware, locazione delle credenziali dele-
gate dagli utenti al server e URL da cui ritirare eventuali file di configurazione
controllati centralmente.
Qua sotto è riportato come esempio il contenuto del file di configurazione di uno dei
server di CRAB attualmente in produzione:
<?xml version="1.0" ?>
<CrabServerConfig>
<CrabServerConfiguration>
<Component Name="TaskTracking"/>
<Component Name="JobTracking"/>
<Component Name="GetOutput"/>
<Component Name="ErrorHandler"/>
<Component Name="JobKiller"/>
<Component Name="HTTPFrontend"/>
<Component Name="CrabServerWorker"/>
<Component Name="AdminControl"/>
<Component Name="Notification"/>
<Component Name="TaskRegister"/>
<Component Name="TaskLifeManager"/>
<Component Name="CommandManager"/>
<ConfigBlock Name="HTTPFrontend">
<Parameter Name="InstallerModule" Value="Plugins.HTTPFrontend.CrabServerTools"/>
<Parameter Name="HWmonitorLogFile" Value="$WORKAREA/HTTPFrontend/HW.log"/>
<Parameter Name="FirstRun" Value="None"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/HTTPFrontend"/>
</ConfigBlock>
<ConfigBlock Name="JobTracking">
<Parameter Name="PoolThreadsSize" Value="4"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/JobTracking"/>
<Parameter Name="jobsToPoll" Value="3000"/>
<Parameter Name="RssFeed" Value="no"/>
<Parameter Name="QueryInterval" Value="3"/>
<Parameter Name="PollInterval" Value="10"/>
</ConfigBlock>
<ConfigBlock Name="CrabServerConfigurations">
<Parameter Name="Protocol" Value="uberftp"/>
<Parameter Name="storagePath" Value="/data/CSstoragePath"/>
<Parameter Name="credentialType" Value="Proxy"/>
<Parameter Name="storagePort" Value="XYZ"/>
<Parameter Name="CacheDir" Value="/data1/CSstoragePath/logs"/>
<Parameter Name="ProxiesDir" Value="/tmp/del_proxies/"/>
<Parameter Name="storageName" Value="crabas.lnl.infn.it"/>
<Parameter Name="WMSserviceList" Value=""/>
<Parameter Name="baseConfUrl" Value="http://cmsdoc.cern.ch/cms/LCG/crab/config/"/>
<Parameter Name="configFileName" Value="glite_wms_CERN.conf"/>
<Parameter Name="crabServerschemaLocation" Value="$CRAB_SERVER_ROOT/share/CrabServerDB.sql"/>
3 Gli
Unix domain socket (detti anche socket locali o socket in dominio Unix), usati nei sistemi
operativi POSIX per le comunicazioni tra processi residenti sullo stesso computer.
4.4 Architettura del server
69
<Parameter Name="resourceBroker" Value="CNAFStress"/>
</ConfigBlock>
<ConfigBlock Name="CrabServerWorker">
<Parameter Name="maxThreads" Value="5"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/CrabServerWorker"/>
</ConfigBlock>
<ConfigBlock Name="JobKiller">
<Parameter Name="KillerName" Value="BossLiteKiller"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/JobKiller"/>
<Parameter Name="RssFeed" Value="no"/>
</ConfigBlock>
<ConfigBlock Name="Notification">
<Parameter Name="Notification_SMTPServer" Value="smtp.lnl.infn.it"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/Notification"/>
<Parameter Name="Notification_SMTPServerDBGLVL" Value="3"/>
<Parameter Name="Notification_per_task" Value="true"/>
<Parameter Name="NotificationDelay" Value="10"/>
<Parameter Name="Notification_SenderName" Value="[email protected]"/>
<Parameter Name="Notification_SenderPwd" Value="XXXXX"/>
<Parameter Name="debugLevel" Value="9"/>
<Parameter Name="Notification_per_job" Value="false"/>
</ConfigBlock>
<ConfigBlock Name="TaskLifeManager">
<Parameter Name="levelAvailable" Value="15"/>
<Parameter Name="checkProxy" Value="on"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/TaskLifeManager"/>
<Parameter Name="taskLife" Value="168:00:00"/>
<Parameter Name="eMailAdmin" Value="None"/>
<Parameter Name="pollingTimeCheck" Value="600"/>
</ConfigBlock>
<ConfigBlock Name="ErrorHandler">
<Parameter Name="ReportAction" Value="noMove"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/ErrorHandler"/>
<Parameter Name="DelayFactor" Value="100"/>
<Parameter Name="RssFeed" Value="no"/>
<Parameter Name="QueueFailures" Value="False"/>
<Parameter Name="MaxCacheDirSizeMB" Value="80"/>
<Parameter Name="ErrorMatrixFile" Value=""/>
<Parameter Name="RunHandlerName" Value="crabRunFailureHandler"/>
<Parameter Name="SubmitHandlerName" Value="submitFailureHandler"/>
</ConfigBlock>
<ConfigBlock Name="BOSS">
<Parameter Name="BossLiteschemaLocation" Value="$PRODCOMMON_ROOT/share/setupDatabase.sql"/>
<Parameter Name="configDir" Value="$WORKAREA/BOSS/config"/>
<Parameter Name="tmpDir" Value="$WORKAREA/BOSS/tmp"/>
</ConfigBlock>
<ConfigBlock Name="MessageService">
<Parameter Name="pollInterval" Value="5"/>
</ConfigBlock>
<ConfigBlock Name="GetOutput">
<Parameter Name="OutputLocation" Value="SE"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/GetOutput"/>
<Parameter Name="GetOutputPoolThreadsSize" Value="7"/>
<Parameter Name="RssFeed" Value="no"/>
<Parameter Name="skipWMSAuth" Value="1"/>
<Parameter Name="maxGetOutputAttempts" Value="3"/>
<Parameter Name="jobsToPoll" Value="3000"/>
70
4 CRAB: evoluzione verso un’architettura client-server
<Parameter Name="PollInterval" Value="10"/>
</ConfigBlock>
<ConfigBlock Name="CrabServer">
<Parameter Name="CrabServerName" Value="[email protected]"/>
<Parameter Name="CrabServerRunOffset" Value="10"/>
<Parameter Name="CrabServerWorkDir" Value="/home/crab/work"/>
</ConfigBlock>
<ConfigBlock Name="AdminControl">
<Parameter Name="Bots" Value="RestartBot,MessageBot"/>
<Parameter Name="BotPeriod" Value="01:00:00"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/AdminControl"/>
</ConfigBlock>
<ConfigBlock Name="CrabServerDB">
<Parameter Name="maxConnectionAttempts" Value="5"/>
<Parameter Name="dbType" Value="mysql"/>
<Parameter Name="refreshPeriod" Value="14400"/>
<Parameter Name="dbWaitingTime" Value="10"/>
<Parameter Name="passwd" Value="XXXXX"/>
<Parameter Name="host" Value="localhost"/>
<Parameter Name="user" Value="DatabaseUserName"/>
<Parameter Name="socketFileLocation" Value="$WORKAREA/mysqldata/mysql.sock"/>
<Parameter Name="portNr" Value=""/>
<Parameter Name="dbName" Value="CrabServerDB"/>
<Parameter Name="schemaLocation" Value="$PRODAGENT_ROOT/share/ProdAgentDB.sql"/>
</ConfigBlock>
<ConfigBlock Name="TaskTracking">
<Parameter Name="PollInterval" Value="13"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/TaskTracking"/>
<Parameter Name="Thread" Value="5"/>
<Parameter Name="debugLevel" Value="9"/>
</ConfigBlock>
<ConfigBlock Name="TaskRegister">
<Parameter Name="maxThreads" Value="6"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/TaskRegister"/>
</ConfigBlock>
<ConfigBlock Name="CommandManager">
<Parameter Name="acceptableClient" Value="2.7.0,2.7.1"/>
<Parameter Name="ComponentDir" Value="$WORKAREA/CommandManager"/>
<Parameter Name="acceptableThroughput" Value="-1"/>
<Parameter Name="uiConfigWMS" Value=""/>
<Parameter Name="uiConfigRB" Value=""/>
<Parameter Name="uiConfigRBVO" Value=""/>
<Parameter Name="Port" Value="20081"/>
</ConfigBlock>
<ConfigBlock Name="JobStates">
<Parameter Name="maxRetries" Value="3"/>
<Parameter Name="mergeMaxRetries" Value="10"/>
</ConfigBlock>
</CrabServerConfiguration>
</CrabServerConfig>
4.4.1
Classificazione logica delle componenti
L’architettura del server prevede l’utilizzo di uno Storage Element locale o remoto per
lo scambio dei files dei job degli utenti. In figura 4.5 è mostrata la struttura del server
4.4 Architettura del server
71
in termini di agenti e le componenti esterne necessarie al funzionamento del server e
con cui il server interagisce. Tutte le componenti (in viola) estendono il framework
(detto anche common core) e utilizzano quest’ultimo per interagire con la base di
dati, per comunicare, per accedere alle credenziali e per interagire con lo Storage
esterno. Ogni componente svolge una determinata funzione all’interno del server vero
e proprio; nelle componenti è implementata la logica dell’applicazione che permette di
ricevere le richieste degli utenti, processarle e ritornare ai risultati secondo diversi casi
d’uso supportati che possono essere facilmente aggiunti. Le componenti, a seconda
delle entità con cui interagiscono e delle funzioni svolte possono essere classificate nei
seguenti gruppi:
• Input/Output (in arancione nella figura 4.5): CommandManager, HTTPFrontend, Notification;
• Implementazione logica e gestione (viola): TaskTracking, AdminControl, ErrorHandler, TaskRegister;
• Interazione con la Grid (azzurre): CrabServerWorker, JobTracking, GetOutput,
JobKiller.
Molte di esse, specialmente quelle che interagiscono con la Grid, che ricevono gli
input dagli utenti e in generale tutte quelle che devono e↵ettuare operazioni su molti
job o task in un breve intervallo di tempo hanno la necessitá di avere delle prestazioni
ottime in modo da evitare colli di bottiglia, accorciando e spesso rimuovendo il ritardo
per quelle singole operazioni che devono essere svolte in molti task contemporaneamente.
Tale ragione spiega perché sia stata introdotta la tecnica del multithreading[47] che
consente di ottenere un sistema multi utente scalabile, soprattutto per le operazioni
piú frequenti e lente come la sottomissione, il tracciamento dello stato e il ritiro dei
risultati dei job. Quando si interagisce con il middleware della Grid infatti è molto
importante eseguire piú istanze in parallelo in quanto alcune operazioni richiedono
una quantitá di tempo considerevole. I thread permettono di suddividere un programma in piú filoni che vengono eseguiti concorrentemente. Nel caso specifico sono
stati adottati due tipi d’implementazioni:
• la prima in cui i thread sono parte di uno stesso processo e condividono risorse
come la memoria in modo d’accedere alle stesse variabili e comunicare facilmente;
• la seconda in cui i thread appartengono a processi diversi che non condividono risorse, cosı̀ che vengano eseguiti in un ambiente isolato e quasi totalmente
indipendente.
72
4 CRAB: evoluzione verso un’architettura client-server
RICHIESTE
CRAB CLIENT
Command
Manager
Task
Tracking
RICHIESTE
WEB
MAILBOXES
HTTP
Frontend
Notification
CrabJob
Creator
MESSAGE
SERVICE
COMMON
CORE
Admin
Control
MYPROXY
BOSSLITE
TASK/JOB
TaskLife
Manager
TASK
INSTANCE
MYSQL
Error
Handler
CACHE
CREDENZIALI
Job
Killer
Job
Tracking
Task
Register
CrabServer
Worker
STORAGE
Get
Output
MIDDLEWARE
Figura 4.5: Vista schematica dell’architettura del server di CRAB.
Nel caso di una macchina con un’architettura a processore singolo la CPU esegue
istruzioni di thread di↵erenti e si parla di multithreading a divisione di tempo, in
cui la commutazione fra i thread avviene di solito tanto frequentemente da dare l’impressione che tutte le operazioni siano eseguiti contemporaneamente. Ma il vantaggio
maggiore si presenta nel caso delle architetture multi-processore (o multi-core) che
negli ultimi mesi stanno prendendo sempre più piede tanto da diventare quelle più
comuni, in cui i thread vengono realmente eseguiti contemporaneamente, ciascuno su
un distinto processore.
Nel caso di un servizio come quello in questione avere delle componenti multithread
aumenta la velocitá di esecuzione sui sistemi con piú CPU o CPU con piú core. Ovviamente ci sono anche degli svantaggi in quanto tutte le componenti che utilizzano
piú thread concorrenti per una stessa porzione di codice devono essere implementate mantenendo la sicurezza dei thread (thread safety) nel caso di esecuzioni multiple
4.4 Architettura del server
73
contemporanee. In particolare è importante che i vari threads possano avere accesso
alle stesse informazioni condivise, ma che queste siano modificabili solo da un thread
alla volta.
Nel caso di un processo multithreaded con piú thread che accedono virtualmente agli
stessi dati, la struttura di controllo e l’ordine di accesso ai dati stessi non rispettano
completamente la sequenzialitá del testo del programma, rendendo possibili comportamenti inattesi dovuti alla manipolazione non corretta delle informazioni. Infatti,
l’utilizzo di tale tecnica ha portato all’introduzione di alcune e↵etti collaterali. In
primo luogo questi ultimi sono legati alla gestione della concorrenza fra i vari thread,
sia perché Python per quanto riguarda l’interazione con MySql non è thread safe sia
perché alcuni strumenti messi a disposizione dalla Grid necessitano di un ambiente dedicato per l’esecuzione delle chiamate al middleware (ad esempio creando dei thread
come fossero dei nuovi sottoprocessi che non condividono l’area di memoria fra loro).
Questo caso ha dilatato notevolmente il tempo necessario allo sviluppo. In secondo
luogo avere molte componenti che a loro volta eseguono molti thread concorrentemente incrementa notevolmente il carico di lavoro per la macchina su cui è installato il
server. Il raggiungimento di un carico di lavoro elevato influisce in modo negativo sulle
prestazioni del server, rallentando l’esecuzione delle operazioni eseguite dalle singole
componenti. Per questo motivo non è possibile aumentare senza criterio il numero di
thread necessari (generalmente un numero maggiore di thread permette un’esecuzione
più veloce delle richieste e delle operazioni), in quanto questo dipende strettamente
dalle prestazioni della macchina fisica, specialmente in termini di processori (o core)
disponibili. Infatti i sistemi multiprocessore sono dotati di più unità di calcolo indipendenti ognuna in grado di prendersi carico di un singolo thread.
Infatti un fattore di cui tenere conto consiste proprio nel fatto che un alto numero di
esecuzioni concorrenti, aumenta il carico di lavoro di tutto il server e dei servizi da
esso usati: lo Storage e la base di dati. Per quest’ultima è stata creata una libreria ad
hoc, la Safe Session. Tale libreria è in grado di gestire le connessioni al database in
modo efficiente, incapsulandole nel concetto più generico di sessione e ha le seguenti
proprietá:
• supporta piú tipi di DBMS,
• contiene un insieme di connessioni (pool ),
• preserva la sicurezza nella concorrenza dei thread,
• gestisce piú insiemi di connessioni contemporaneamente anche da parte dello
stesso programma (o componente);
• può essere modificata dall’utilizzatore tramite la tecnica dell’ereditarietà per
aggiungere o modificare il comportamento di base.
74
4 CRAB: evoluzione verso un’architettura client-server
Un pool mantiene un insieme di connessioni aperte al database, evitando di aprire e
chiudere una connessione troppe volte. Dunque un qualsiasi utilizzatore della base di
dati del server si connette utilizzando una sessione, senza occuparsi dei dettagli della
transazione o della connessione.
Vedremo il caso specifico dello Storage nel capitolo successivo tramite l’implementazione da me svolta delle Storage Element API.
4.4.2
Descrizione agenti di input/output
Le componenti di questo insieme consentono agli utenti di inviare richieste di ogni
tipo al server, agli amministratori di poter controllare il funzionamento del server e a
quest’ultimo di inviare eventuali segnalazioni agli utenti e agli amministratori.
CommandManager. La CommandManager è la componente che si prende carico delle richieste del client, le inoltra alle componenti interne del server attraverso il
sistema di messaggistica asincrono e preleva le informazioni necessarie per rispondere
alla richiesta. La comunicazione fra il client e il server avviene attraverso SOAP 4 .
Questo è stato scelto sia perché è uno standard de facto nello sviluppo di servizi nella
comunità Grid, sia perché è ideale nei servizi web che utilizzano la programmazione
orientata agli oggetti. Inoltre permette di lavorare con il protocollo HTTP (HyperText Transfer Protocol), fornendo l’interoperabilitá necessaria attraverso istituzioni e
linguaggi di programmazione diversi.
L’implementazione della parte di comunicazione è stata e↵ettuata grazie a gSOAP [48],
uno strumento open source per creare servizi web o↵rendo la possibilitá di sviluppare
facilmente in linguaggio C e C/C++ i Web services SOAP/XML (eXtensible Markup
Language). Quindi l’agente interagisce con il modulo della comunicazione attraverso
delle API che permettono d’integrare codice scritto in C/C++ con Python, grazie a
SWIG(Simplified Wrapper and Interface Generator)[49]. Il client non assume nulla sui
dettagli dell’implementazione del server e vice versa e il corpo dei messaggi è definito
con XML, che incapsula i comandi e i dettagli delle richieste degli utenti. Di seguito
c’è un esempio di comando inviato dal client al server che richiede la cancellazione del
job numero 1 del task cinquilli crab 0 091228 101315 41uyv0 :
<?xml version="1.0" ?>
<TaskCommand
ClientVersion="2.7.0"
4 Simple
Object Access Protocol è un protocollo leggero per lo scambio di messaggi tra componenti
software, tipicamente nella forma di componentistica software. La parola object manifesta che l’uso
del protocollo dovrebbe e↵ettuarsi secondo il paradigma della programmazione orientata agli oggetti.
4.4 Architettura del server
75
Command="kill"
Flavour="analysis"
Range="[1]"
Scheduler="glite"
Subject="/C=IT/O=INFN/OU=Personal Certificate/L=Perugia/CN=Mattia Cinquilli"
Task="cinquilli\_crab\_0\_091228\_101315\_41uyv0"
TotJob="-1"
Type="fullySpecified"
/>
HTTPFrontend. L’HTTPFrontend fornisce gli strumenti necessari per mostrare
sia agli utenti che agli amministratori informazioni sul server tramite HTTP:
• stato dell’hardware del server,
• stato del software del server relativo a MySql, server Python, Storage, etc.,
• vista dei job sul server, raggruppandoli per utente, dati analizzati, tempo, etc.
. Questa componente include CherryPy[50], un framework per lo sviluppo web con
Python che fornisce le fondamenta sopra le quali costruire applicazioni web in modo
molto simile a come si scriverebbe un altro programma Python a oggetti, risultando
in meno linee di codice sviluppate in meno tempo. Quindi ogni pagina Web che viene
visualizzata da questa componente corrisponde ad un modulo. L’insieme dei moduli
costituisce un plug-in di questo agente.
In figura 4.6 è mostrata una vista della distribuzione per sito Grid dei job sottomessi
tramite il server di Legnaro dal 20 Novembre 2009 al 28 Dicembre 2009.
Notification. La Notification invia messaggi di posta elettronica sia tramite un
server di posta locale alla macchina del server, sia autenticandosi ad un server di posta
remoto. Generalmente i messaggi di posta inviati notificano gli utenti dell’esito dei
loro job una volta che sono tutti terminati e gli amministratori per particolari situazioni di allarme che possono verificarsi.
4.4.3
Descrizione agenti di logica e di gestione
Queste componenti gestiscono il flusso di lavoro all’interno del server, implementando
la logica necessaria a fornire le funzionalitá specifiche e per gestire il server stesso.
TaskTracking. La TaskTracking è la componente informativa del server. Gli
obiettivi di questa componente sono:
76
4 CRAB: evoluzione verso un’architettura client-server
Figura 4.6: Job per sito sottomessi dal 20 Novembre 2009 al 28 Dicembre 2009. Grafico
prelevato dall’HTTPFrontend del server di analisi di Legnaro.
• mantenere informazioni generali dei task attivi e non sul server,
• notificare le altre componenti quando un task passa di stato,
• generare e mantenere i file xml sullo stato e i log di ogni task.
Questa componente è implementata con la tecnica del multithreading e sarà descritta
nel dettaglio nel cap. 5.
AdminControl. L’AdminControl è un semplice framework a plug-in per eseguire
periodicamente delle operazioni che possono essere di manutenzione per poter rendere
il server il piú possibile auto gestito, riducendo al minimo il carico di lavoro sull’amministratore. Ogni plug-in corrisponde ad un’operazione o serie di operazioni e due
esempi ne sono:
• RestartBot: puó capitare che per qualche motivo una componente non sia piú
in esecuzione e questo si occupa di controllare che tutte le componenti del server
siano in esecuzione facendo ripartire quelle che non lo sono.
4.4 Architettura del server
77
• MessageBot: pulisce la tabella del database che contiene lo storico dei messaggi
inviati dalle componenti attraverso il MessageService.
ErrorHandler. L’ErrorHandler si occupa della gestione degli errori sottoscrivendosi agli eventi (sotto forma di messaggi) generati dalle altre componenti. A seconda
del tipo di errore e del tipo di job questa componente esegue l’operazione associata, aggiornando le informazioni del job. Ha una struttura a plug-in 5 in modo che
possano essere definiti una vasta gamma di errori e che per ogni caso d’uso generico
venga definito un plug-in appropriato. I plug-in da utilizzare vengono specificati nella
configurazione del server. Quando la componente riceve l’evento a cui è registrata
essa attiva il plug-in associato all’evento passandogli le informazioni necessarie. Il
plug-in principalmente utilizzato è quello che si occupa di gestire i fallimenti dei job,
prendendo delle decisioni a seconda del codice di uscita del job e innescando le azioni necessarie (generando un nuovo evento per un’altra componente). Attualmente le
azioni disponibili sono:
• NoResubmission: non viene eseguita nessuna azione per il job, che viene archiviato; è l’azione eseguita di default;
• DelayedResubmission: viene richiesta la risottomissione del job, con un ritardo
configurabile;
• ResubmitElsewhere: viene richiesta la risottomissione, ma il sito in cui il job è
fallito viene rimosso da quelli disponibili.
TaskRegister. La TaskRegister prende in carico le richieste di nuovi task dalla
CommandManager, verifica la consistenza e la correttezza dei dati in ingresso (proxy,
input sandbox, definizione task, etc.) e, se questa va a buon fine, prepara le strutture
dati necessarie al server, deserializzando nel database del server le informazioni inviate
dal client in formato XML; infine invia un messaggio di corretta registrazione di un
nuovo task. Questa componente è multithreaded e permette di gestire ogni singolo
task per thread.
4.4.4
Descrizione agenti per l’interazione con la Grid
Le componenti di questo gruppo sono basate soprattutto su BossLite per interagire
con i vari middleware in modo trasparente. Come detto in precedenza sono implemen5 plug-in:
programma non autonomo che serve ad aumentare le funzioni di una applicazione. Ad
esempio, i plug-in dei browser web permettono di visualizzare oltre alle pagine html altri tipi di
file, come le animazioni in formato flash, etc. La capacitá di un software di supportare i plugin è
generalmente un’ottima caratteristica, perché rende possibile l’ampliamento e la personalizzazione
delle sue funzioni in maniera semplice e veloce.
78
4 CRAB: evoluzione verso un’architettura client-server
tate secondo il modello di multithread per velocizzare l’interazione con il middleware
che spesso è fra le operazioni meno veloci di tutto il flusso di lavoro, evitando di creare
dei rallentamenti e congestionamenti del servizio nel caso di richieste simultanee.
CrabServerWorker. É strutturata da un modulo principale che si occupa di ricevere le richieste di sottomissione di insiemi di job verso la Grid ritornandone l’esito e
da un insieme di thread che vengono attivati dal modulo principale solo quando vi sono
delle richieste da soddisfare. Un compito della componente è anche quello di e↵ettuare
un vero e proprio scheduling delle sottomissioni su delle code appropriate distribuendo
il carico di lavoro fra i vari thread. Per ogni singola richiesta di sottomissione, che
spesso comprende piú job, questo agente implementa i controlli sulle dimensioni delle
collezioni di job e se necessario le ridefinisce al fine di ottimizzare l’interazione con
la Grid. L’esito dell’operazione di sottomissione non è sempre positivo e per questo
sono state implementate delle soluzioni di fall back. Questo agente si occupa anche di
e↵ettuare eventuali ri-sottomissioni.
JobTracking. La JobTracking controlla regolarmente lo stato dei job sottomessi
sulla Grid e richiede il ritiro dell’output per quei job che sono finiti. La componente è
strutturata in due moduli: il primo modulo principale (main module) esegue l’inizializzazione e gestisce i messaggi ricevuti; il secondo (status monitor ) aggiorna lo stato
dei job nella base di dati interna interrogando la Grid e segnala i job terminati alla
GetOutput.
Quest’ultimo è stato implementato utilizzando un pool scheduler, un pool di thread
e due code per la comunicazione. Il pool scheduler assegna il carico di lavoro per le
interrogazioni, che in parallelo eseguono il controllo dello stato. Un modello basato
sulla comunicazione di token che identificano i sottoinsiemi di job garantisce la sincronizzazione tra i thread e il pool scheduler, consentendo l’assegnazione dinamica dei
job.
Il modello di funzionamento è mostrato in figura 4.7. Il pool scheduler partiziona
l’insieme dei job in una serie di sottoinsiemi, assegnando un identificatore (token) a
ciascuno di essi. Dopo di che, il pool scheduler inserisce gli identificatori nella coda
di input, che è persistente (sulla base di dati del server). La prima azione che viene
e↵ettuata dal thread è quella di mettersi in attesa di un token da leggere dalla coda di
input. Dopo avere ottenuto il token, il thread esegue l’operazione per il controllo dello
stato di tutti i job connessi a tale token, inserendo quest’ultimo nella coda di output e
andando nuovamente a leggere dalla coda di input per ottenere un nuovo incarico. Il
token inserito nella coda di output viene prelevato dal pool scheduler, che dunque può
e↵ettuare nuovamente l’assegnazione dei job connessi a tale token, insieme ai nuovi
4.4 Architettura del server
79
job che nel frattempo possono essere stati sottomessi su Grid.
Figura 4.7: Implementazione con un pool di thread della componente JobTracking.
GetOutput. La GetOutput esegue l’operazione di ritiro dei risultati dei job degli
utenti quando viene richiesto dalla JobTracking. La componente interroga regolarmente la base di dati interna per verificare se ci sono o meno job per cui è stato
richiesto il ritiro degli output, mettendo in coda tali richieste. Un gruppo di thread
(pool thread ) prende le richieste dalla coda, e↵ettua l’operazione e mette in coda l’output. Regolarmente la componente interroga la coda per verificare se ci sono job per
cui sono stati ritirati i risultati, generando il corrispondente messaggio di job terminato con successo oppure fallito. La struttura per classi è mostrata in figura 4.8. La
classe GetOutputComponent è la classe principale e il metodo checkJobs() esegue l’interrogazione per job di cui è stato richiesto l’output, mettendo la richiesta nella coda
dei thread. Successivamente esegue un’interrogazione dei job di cui è stato ritirato
l’output, per ognuno di essi chiama il metodo processOutput() processando l’output
ritirato dai thread. La classe JobHandling implementa i metodi necessari a dialogare
con il MessageService, la gestione delle operazioni con il file system e con le operazioni
necessarie ad archiviare i job processati. La classe JobOutput implementa tutte le operazioni specifiche per il ritiro dell’output, includendo i metodi come requestOutput()
usato anche dalla componente JobTracking per richiedere l’operazione, doWork() che
implementa il corpo del thread che esegue realmente l’operazione interagendo con BossLite e la Grid, e setDoneStatus() usato per indicare la fine di un’operazione.
JobKiller. La JobKiller mette a disposizione i servizi necessari a cancellare i job
sottomessi verso la Grid. Anche questa componente funziona a plug-in, è costituita da
un’unica classe che gestisce sequenzialmente tutte le richieste smistandole al plug-in
desiderato. I diversi plug-in eseguono l’operazione di cancellazione in modo diverso a
80
4 CRAB: evoluzione verso un’architettura client-server
Figura 4.8: Schema UML della componente GetOutput.
seconda del tipo di richiesta ricevuta.
4.5
Interfaccia al middleware ed ai sistemi di batch:
BossLite
BossLite è la libreria sviluppata con Python per interfacciarsi con i vari middleware della Grid e con i sistemi batch locali. Questo strumento mette a disposizione
un’interfaccia generica e astratta, rendendo possibili operazioni standard come la sottomissione, il tracciamento, la cancellazione e il ritiro dei risultati dei job. Le interfacce
ai sistemi specifici vengono istanziate al momento dell’esecuzione grazie ad una struttura a plug-in, dove ogni plug-in contiene le definizioni per interagire con il sistema
specifico. Attualmente è supportata l’interazione con i seguenti middleware:
• gLite di EGEE
4.5 Interfaccia al middleware ed ai sistemi di batch: BossLite
81
• CondorG di OSG
• ARC di NorduGrid
e con i seguenti sistemi locali:
• LSF
• Condor
• SGE
• PBS
BossLite usa una base di dati per tracciare e registrare in uno schema entitá-relazioni
le informazioni dei task e job da esso gestiti. Le informazioni presenti nella base
di dati vengono rimappate logicamente e velocemente attraverso oggetti di Python
che permettono agli strumenti di livelli logici più alti di utilizzare tali informazioni
in modo trasparente. Un sessione per la connessione alla base di dati permette di
eseguire operazioni (aprire e chiudere connessioni, e↵ettuare interrogazioni, inserimenti
o aggiornamenti di tuple, etc.) attraverso un’interfaccia astratta e supportando diversi
tipi di DBMS. Attualmente quelli supportati sono MySql e SQLite[51]. L’architettura
di BossLite è mostrata in figura 4.9.
82
4 CRAB: evoluzione verso un’architettura client-server
Figura 4.9: Vista schematica dell’architettura di BossLite.
Capitolo 5
Implementazione dei
componenti di gestione dei
task
“I mean, if 10 years from now, when
you are doing something quick and
dirty, you suddenly visualize that I
am looking over your shoulders and
say to yourself “Dijkstra would not
have liked this”, well, that would be
enough immortality for me.”
Edsger Dijkstra
5.1
Richieste degli utenti: task
Gli obiettivi principali di un’applicazione per la gestione dei flussi di lavoro tipici
dell’analisi dati in ambiente distribuito Grid sono:
• semplificare l’interazione dell’utente con l’analisi su ambiente distribuito;
• ottimizzare i processi sequenziali che tipicamente richiedono molto tempo;
• soddisfare le ingenti richieste di potenza computazionale sfruttando tutte le
risorse distribuite;
• accedere contemporaneamente ai dati distribuiti su di↵erenti posizioni geografiche.
84
5 Implementazione dei componenti di gestione dei task
Per raggiungere tali obiettivi la singola richiesta dell’utente viene identificata univocamente con un flusso di lavoro detto task, costituito dall’insieme delle specifiche
necessarie ad eseguire la richiesta stessa. Il task è quindi l’entità logica avente corrispondenza 1 a 1 con la richiesta dell’utente. A sua volta l’applicazione fattorizza
la richiesta e quindi il task, in un insieme di sotto unità logiche dette job. Ognuno
di questi è eseguito sequenzialmente venendo distribuito su più siti computazionali.
La fattorizzazione in job della richiesta iniziale viene detta job splitting, e crea una
relazione uno a molti fra il task e i job. Da un punto di vista Grid ognuno di questi
job è a sé stante e indipendente dagli altri, il middleware non tiene traccia del fatto
che appartengano ad uno stesso task.
Il task definisce dunque una entità monolitica di cui l’applicazione deve servirisi per
poter rappresentare in maniera univoca la richiesta dell’utente e gestire efficacemente
la mole di flussi di lavoro attivi nel servizio.
5.1.1
Task e job
L’introduzione del concetto di task nelle applicazioni distribuite è un’aspetto tanto
importante quanto critico in quanto permette raccogliere un insieme di job in un’unica
entità, specialmente in uno strumento come il server di CRAB, disegnato per essere
interposto tra il consumatore ed i servizi della Grid. Tutte le operazioni eseguite dagli
agenti del server si possono distinguere in base alla granularità degli ogetti con cui
operano. Essi possono essere task e job:
• job: viene utilizzato come elemento indivisibile per quanto riguarda le opera-
zioni da un punto di vista Grid (tracciamento, sottomissione e risottomissione,
cancellazione, ritiro dei risultati);
• task: è l’insieme dei job che viene usato per rappresentare e raccogliere in un’un-
cia entità un singolo flusso di lavoro dell’utente; tramite questo oggetto è possibile accedere all’insieme dei job per poter e↵ettuare singole operazioni su di
essi.
Fin dalle fasi iniziali della progettazione del server di CRAB sono stati disegnati i
demoni necessari ad operare e gestire l’entità task. Sono stati quindi definiti gli agenti
per:
• tracciare lo stato di avanzamento dei task e per aggregare gli eventi (operazioni
o decisioni) ad esso inerenti;
• gestire il ciclo di vita del task all’interno del server, dall’arrivo fino al termine.
Il secondo agente include la gestione dei file di input e di output dei job del task,
nonché l’interazione con l’area di Storage associata al server. Come visto nel cap. 4
85
5.2 Componente per l’aggregazione delle informazioni sui task
RICHIESTE
CRAB CLIENT
Command
Manager
Task
Tracking
RICHIESTE
WEB
MAILBOXES
HTTP
Frontend
Notification
CrabJob
Creator
MESSAGE
SERVICE
COMMON
CORE
Admin
Control
MYPROXY
BOSSLITE
TASK/JOB
TaskLife
Manager
TASK
INSTANCE
MYSQL
Error
Handler
CACHE
CREDENZIALI
Job
Killer
Job
Tracking
Task
Register
CrabServer
Worker
STORAGE
Get
Output
MIDDLEWARE
Figura 5.1: Architettura e componenti del server di CRAB; in rosso sono evidenziati
gli agenti dedicati alla gestione dei task e le frecce relative all’interazione con lo Storage
Element attraverso le SEAPI.
il tipo di area e le modalità d’interazione (i protocolli utilizzati) possono cambiare a
seconda della specifica installazione e configurazione. Per far fronte a questa esigenza
è stato sviluppato un insieme di API che permette di lavorare su quest’area in modo
trasparente e semplice.
In figura 5.1 è mostrata l’architettura del server, dove in rosso sono evidenziate le
parti sopra descritte.
5.2
Componente per l’aggregazione delle informazioni sui task
Come è già stato detto un aspetto fondamentale all’interno del server è la capacità di
poter tracciare l’avanzamento dei task in quanto unità logica. Questo implica saper
controllare lo stato di tutti i job di un task, raccogliendo le informazioni sull’avan-
86
5 Implementazione dei componenti di gestione dei task
zamento dei singoli job (controllato dall’agente JobTracking, cap. 4) e aggiornando i
file contenenti le informazioni utili per l’utente. A tal fine è stato scelto di sviluppare
un’agente dedicato che prende il nome di TaskTracking.
Come mostrato in figura 5.2 questo agente aggrega le informazioni che riceve tramite
messaggi dagli altri agenti del server. Tali informazioni sono costituite dagli eventi
che occorrono ai task e ai relativi job. Gli eventi includono tutte le operazioni richieste (come un nuovo flusso di lavoro da eseguire, o la cancellazione di un job, . . . ),
l’esito di tali operazioni ed eventuali cambiamenti di stato dei task. Queste vengono
dunque elaborate dalla componente in questione che registra lo stato d’avanzamento
complessivo dei task stessi attraverso una coda persistente. Quest’ultima è definita
nello schema SQL della base di dati associata al server e contiene informazioni di alto
livello relative al task e all’utente associato ad esso. La presenza di una coda persistente permette di accedere in un qualsiasi momento alle informazioni memorizzate,
di registare gli avanzamenti dei vari flussi di lavoro in modo d’avere un’istantanea
sullo stato del flusso di lavoro e soprattuto gestendo al meglio la concorrenza dei vari
thread.
Un altro strumento cruciale è BossLite (cap. 4), che mette a disposizione le strutture
dati e le API necessarie a garantire l’accesso alle informazioni statiche e dinamiche
dei task e dei job. Un esempio d’interazione della TaskTracking con gli altri agenti è
quello in cui il client invia al server un nuovo task da processare:
• la CommandManager riceve un nuovo task dal client, allora propaga le informazioni necessarie alla TaskTracking e alla TaskRegister;
• la TaskTracking riceve il suddetto messaggio, registra il nuovo task nella coda
persistente e il task inizia cosı̀ ad essere tracciato;
• contemporaneamente la TaskRegister riceve lo stesso messaggio: deserializza il
task, verifica gli input, prepara il task alla sottomissione e invia un messaggio di
corretta registrazione alla TaskTracking e alla CrabServerWorker;
• la TaskTracking riceve il messaggio di corretta registrazione: aggiorna le informazioni del task e quindi lo stato d’avanzamento;
• contemporaneamente la CrabServerWorker riceve il messaggio dalla TaskRegi-
ster: carica il task in questione, lo mette nella coda dei task da sottomettere,
lo sottomette e invia alla TaskTracking un messaggio che contiene l’esito della
sottomissione;
• la TaskTracking riceve il messaggio dalla CrabServerWorker: registra il nuovo
evento e aggiorna lo stato d’avanzamento del task; nel caso in cui la sottomis-
sione sia fallita dopo tutti i possibili tentativi il task viene archiviato e non più
87
5.2 Componente per l’aggregazione delle informazioni sui task
CRABSERVER
WORKER
TASK
REGISTER
JOB
KILLER
COMMAND
MANAGER
NOTIFICATION
TASK
TRACKING
BOSSLITE
BOSSLITE
TABLES
REPORT/LOG
AREA
TASK
QUEUE
DATABASE
Figura 5.2: Schema delle interazioni della TaskTracking con le altre componenti del
server.
tracciato fino a che un nuovo evento non ne causi la de-archiviazione; nel caso in
cui la sottomissione sia andata a buon fine la Task Tracking continua a tracciare
l’avanzamento dei job del task;
• quando tutti i job sono in uno stato terminale di conseguenza la TaskTracking
archivia il task, che viene dunque considerato completo cosı̀ che questo non venga
più preso in considerazione, alleggerendo il processamento dell’agente dai task
non più necessari.
Un task archiviato può essere comunque recuperato nel caso in cui debbano essere
e↵ettuate altre operazioni su di esso. Alcune di queste operazioni sono la risottomissione di job che erano falliti, l’estensione del task che comporta l’aggiunta di ulteriori
job da eseguire oppure il semplice fatto che il tipo di flusso di lavoro in esecuzione
prevede l’esecuzione del task in più iterazioni.
Le informazioni sullo stato dei task e dei relativi job vengono propagate verso il client
nel momento in cui questo contatta il server, dunque la propagazione di informazio-
88
5 Implementazione dei componenti di gestione dei task
ni avviene su richiesta diretta. Onde rendere questo tipo di operazione più veloce,
alleggerendo il carico di lavoro sul server, la TaskTracking e↵ettua un’operazione di
caching delle informazioni necessarie all’utente. Tali informazioni vengono registrate
in un file che l’agente stesso provvede ad aggiornare periodicamente e usate dal client
su richiesta. Ovviamente tanto frequentemente questo viene aggiornato, tanto più
attuali saranno le informazioni che l’utente ha del proprio task. L’agente descritto si
occupa di:
• creare e aggiornare un file in formato XML per ogni task dove mantenere le
informazioni sugli eventi che accadono ad un task; le informazioni vengono registrate quando l’agente lo ritiene necessario o quando gli altri agenti notificano un
evento tramite il MessageService (cap. 4) messo a disposizione dal framework
comune;
• creare e aggiornare il più frequentemente possibile un file in formato XML
per ogni task che contenga lo stato di avanzamento del task e lo stato e le
informazioni di tutti i job che esso contiene.
Ecco un esempio del file che contiene le informazioni sullo stato di un particolare task:
<?xml version=’1.0’ encoding=’UTF-8’?>
<TaskTracking>
<TaskReport thresholdRequested=’0’ ended=’50’ owner=’Mattia Cinquilli’
taskName=’LM0’ TaskStatus=’Processed’ totJob=’4’
email=’mattia.c***@cern.ch’/>
<Job status=’Cleared’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’ce3.itep.ru’ ended=’Y’ resubmit=’0’ job_exit=’0’
sched_status=’E’ exe_exit=’0’ action=’Cleared’ cleared=’1’ id=’1’/>
<Job status=’Cleared’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’ce3.itep.ru’ ended=’Y’ resubmit=’0’ job_exit=’0’
sched_status=’E’ exe_exit=’0’ action=’Cleared’ cleared=’1’ id=’2’/>
<Job status=’Submitted’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’’ ended=’N’ resubmit=’0’ job_exit=’None’ sched_status=’SU’
exe_exit=’None’ action=’SubSuccess’ cleared=’0’ id=’3’/>
<Job status=’Submitted’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’’ ended=’N’ resubmit=’0’ job_exit=’None’ sched_status=’SU’
exe_exit=’None’ action=’SubSuccess’ cleared=’0’ id=’4’/>
</TaskTracking>
Ecco invece un esempio del file che contiene le informazioni sugli eventi registrati per
un task:
5.2 Componente per l’aggregazione delle informazioni sui task
89
<?xml version=’1.0’ encoding=’UTF-8’?>
<TaskTracking>
<TaskReport thresholdRequested=’0’ ended=’50’ owner=’Mattia Cinquilli’
taskName=’LM0’ TaskStatus=’Processed’ totJob=’4’
email=’mattia.c***@cern.ch’/>
<Job status=’Cleared’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’ce3.itep.ru’ ended=’Y’ resubmit=’0’ job_exit=’0’
sched_status=’E’ exe_exit=’0’ action=’Cleared’ cleared=’1’ id=’1’/>
<Job status=’Cleared’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’ce3.itep.ru’ ended=’Y’ resubmit=’0’ job_exit=’0’
sched_status=’E’ exe_exit=’0’ action=’Cleared’ cleared=’1’ id=’2’/>
<Job status=’Submitted’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’’ ended=’N’ resubmit=’0’ job_exit=’None’ sched_status=’SU’
exe_exit=’None’ action=’SubSuccess’ cleared=’0’ id=’3’/>
<Job status=’Submitted’ sched_id=’https://lb008.cnaf.infn.it:9000/****’
site=’’ ended=’N’ resubmit=’0’ job_exit=’None’ sched_status=’SU’
exe_exit=’None’ action=’SubSuccess’ cleared=’0’ id=’4’/>
</TaskTracking>
5.2.1
TaskTracking: architettura
La TaskTracking è sviluppata secondo la programmazione orientata agli oggetti, implementa il multithreading per poter eseguire contemporaneamente più task e utilizza
in modo esclusivo una tabella memorizzata sulla base di dati, necessaria per tenere
traccia dei task e delle informazioni ad essi associate. L’utilizzo del multithreading
è dovuto al fatto che i file creati dalla componente devono essere aggiornati il più
frequentemente possibile e che eventuali task costituiti da molti job (più di 1000) richiedono un tempo di processamento non indi↵erente. Parallelizzando tale processo
si riduce di molto la probabilità che un task di grandi dimensioni vada a rallentare
l’elaborazione degli altri, garantendo l’efficienza dal punto di vista dello user.
In particolare questo agente è costituito dalle classi mostrate nel diagramma di classi
in figura 5.3 costruito secondo lo standard UML1 . Tali classi sono:
• TaskTrackingComponent: è la classe più importante che contiene tutta la
logica dell’agente necessaria a gestire le operazioni principali, utilizzando le altre
1
L’Unified Modelling Language è il linguaggio per la modellazione di programmi e dati. È lo
standard utilizzato nell’ingegneria del software per descrivere un sistema informatico (e non solo),
consente ai vari ruoli (sviluppatore, tester, analista, etc.) di comunicare tramite lo stesso linguaggio.
Si avvale di diversi tipi di diagrammi, statici e dinamici, per fornire diverse viste di uno stesso sistema.
90
5 Implementazione dei componenti di gestione dei task
TaskTracking
CreateXml
JobReport
Thread
JobXml
TaskTracking
Component
TaskState
API
TaskTracking
Util
1
2..N
PollThread
Internal
LoggingInfo
TaskTracking
Util
Figura 5.3: Diagramma delle classi degli oggetti della TaskTracking costruito con la
specifica UML.
classi come utilità per avere un’accesso trasparente alle varie funzionalità; infatti
questo modulo implementa i metodi necessari a:
– inizializzare la componente,
– interagire con il MessageService per inviare/ricevere messaggi,
– gestire i thread,
– implementare la funzione che include la logica per tracciare l’avanzamento
dei task (poll method )
– interagire con BossLite,
– creare dei rapporti sia sui file che sulla base di dati;
• PollThread: eredita dalla classe Thread della libreria di Python le primitive
necessarie per definire ed implementare il comportamento dei thread;
• TaskTrackingUtil: contiene un insieme di funzionalità che servono semplicemente ad automatizzare alcune operazioni sui dati;
• UtilSubject: formata dall’insieme dei metodi necessari a trattare correttamente
5.2 Componente per l’aggregazione delle informazioni sui task
91
il contenuto del certificato dell’utente, in particolare del Subject che contiene la
maggior parte dei dettagli personali dell’utente;
• TaskStateAPI: contiene un insieme di API che la classe TaskTrackingComponent usa per interagire con la propria tabella che si trova sulla base di dati;
• InternalLoggingInfo: mette a disposizione un’insieme di semplici ma efficaci
metodi per gestire le informazioni di log che vengono scritte su file in formato
XML;
• JobXml: classe che rappresenta un singolo job e che contiene le informazioni
che è necessario scrivere per ogni job su un file in formato XML;
• CreateXmlJobReport: classe che mantiene tutti gli oggetti di tipo JobXml,
occupadosi di fornire un insieme di API semplici e trasparenti per scrivere il
rapporto del task su un file in formato XML.
Tracciamento e gestione dei thread
La classe TaskTrackingComponent contiene tutta la logica e le funzioni principali dell’agente. Infatti l’avvio dell’agente corrisponde alla chiamata della funzione
di inizializzazione (init) e di inizio del lavoro (startComponent) di questa classe. La
funzione di inizializzazione si occupa di leggere i parametri di esecuzione che sono
specificati nella configurazione del server (fra cui i principali sono: numero di thread,
numero di file di log dell’agente stesso, area di lavoro della componente, area di memorizzazione dei log dei task) e di inizializzare gli oggetti necessari a mantenere un
insieme di connessioni alla base di dati (cap. 4). La funzione startComponent registra
l’agente nel sistema di messaggistica del server, avvia e gestisce tanti thread quanti
ne sono stati specificati nel file di configurazione. La definizione e l’avvio dei thread
consistono nel creare oggetti di tipo PoolThread, passando alla relativa funzione di inizializzazione
init
2
) sia il nome del thread sia il riferimento al metodo della classe
TaskTrackingComponent che si occupa di tracciare l’avanzamento di un task, cioè il
poll method. Ecco la porzione di codice che chiama i thread:
for i in xrange(1, nMaxThreads):
pollingThread = PollThread(self.pollTasks, "pollingThread_" + str(i))
pollingThread.start()
2 In
Python non esistono costruttori di classe: il metodo
init
è chiamato immediatamente dopo
la creazione dell’istanza di una classe. Questo può sembrare proprio il costruttore della classe (in
Python per convenzione questo è il primo metodo definito nella classe), agisce come un costruttore (è
il primo pezzo di codice eseguito in una nuova istanza di una classe). Erroneamente, perché l’oggetto
viene costruito prima che
init
venga chiamato.
92
5 Implementazione dei componenti di gestione dei task
Il metodo passato in fase di inizializzazione è quello che il PoolThread chiama quando il thread parte. La chiamata avviene nel modo più sicuro possibile, andando ad
intercettare ogni tipo di errore che può sorgere (spesso possono esservi errori legati
alla base di dati, al sistema operativo e comunque non inerenti alla componente in sé)
e permettendo al massimo tre fallimenti prima di uscire. A seguire (vedi inserto) il
codice che implementa la classe PollThread:
class PollThread(Thread):
def __init__(self, poll, name):
Thread.__init__(self)
self.poll = poll
self.name = name
def run(self):
failedAttempts = 0
while True:
try:
self.poll(self.name)
except Exception, ex:
logging.error("ERROR in thread " + self.name + "\n" + str(ex))
if failedAttempts == 3:
logging.error("Cannot restart polling. Aborting")
logging.error("\nWarning: Polling thread is not running!")
sys.exit(1)
failedAttempts += 1
logging.error("Trying to restart polling... " + \
"(attempt %s)" % failedAttempts)
else:
failedAttempts = 0
I thread vengono dunque eseguiti all’interno dello stesso processo condividendo le
risorse come quelle di memoria. Questo comporta che la concorrenza dei thread è
stata gestita in modo accurato, andando ad implementare tutti i metodi in modo che
ogni conflitto potesse essere evitato.
Il flusso di lavoro del poll method è il seguente:
• istanzia la sessione di lavoro con il framework BossLite;
• preleva in modo esclusivo un task dalla coda dei task che sta sulla base di dati;
• carica le informazioni del task prelevato dalla coda e quelle dei job cosı̀ come
sono messe a disposizione da BossLite;
5.2 Componente per l’aggregazione delle informazioni sui task
93
• controlla lo stato di avanzamento di tutti i job del task preparando un sommario
fra quelli in avanzamento, quelli che non sono ancora iniziati, quelli finiti bene
o male;
• prepara un file XML che contiene le informazioni di avanzamento del task
(ad esempio la percentuale di job finiti) e di ogni singolo job serializzando le
informazioni prelevate da BossLite;
• aggiorna il task sulla base di dati e lo rilascia nella coda;
• va in pausa rilasciando le risorse occupate, per poi ripartire dal secondo punto.
TASK
TASK
TASK
THREAD 1
THREAD 2
THREAD N
TASK
TASK
TASK
Figura 5.4: Schema del funzionamento dei thread e della coda dei task.
Da un punto di vista della concorrenza accade quanto viene mostrato in figura 5.4.
Ogni thread seleziona un task della coda, esegue le operazioni sopra riportate per il
task scelto e quando ha finito lo rilascia. Successivamente ogni thread riposa per un
tempo predefinito all’interno del file di configurazione e sceglie nuovamente un task
e↵ettuando cosı̀ un lavoro ciclico sulla coda.
La concorrenza fra i thread sulla coda dei task è garantita in modo persistente all’interno della base di dati attraverso una tabella dedicata:
CREATE TABLE tt_taskInstance (
id int NOT NULL AUTO_INCREMENT,
task_name varchar(255) NOT NULL DEFAULT ’’,
e_mail varchar(255) NOT NULL DEFAULT ’’,
treshold_level int(3) UNSIGNED NOT NULL DEFAULT ’100’,
notification_sent int(1) UNSIGNED NOT NULL DEFAULT ’0’
ended_level int(3) UNSIGNED NOT NULL DEFAULT ’0’,
94
5 Implementazione dei componenti di gestione dei task
proxy varchar(255) NOT NULL DEFAULT ’’,
uuid varchar(255) NOT NULL DEFAULT ’’,
status varchar(255) NOT NULL DEFAULT ’not submitted’,
work_status TINYINT UNSIGNED NOT NULL DEFAULT 0
user_name varchar(255) NOT NULL DEFAULT ’’,
lastupdate_time TIMESTAMP DEFAULT 0
ended_time TIMESTAMP DEFAULT 0
land_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
cleaned_time TIMESTAMP DEFAULT 0
primary key(id),
unique(task_name),
key(task_name)
) TYPE = InnoDB DEFAULT CHARSET=latin1;
Questa tabelle mantiene le informazioni principali fra cui il nome e lo stato d’avanzamento del task, le informazioni dell’utente e i vari timestamp necessari alla gestione
del ciclo di vita del task. Di particolare interesse è il campo work status che viene
utilizzato per descrivere lo stato del task da un punto di vista della concorrenza fra i
thread. I valori che questo campo della tabella può assumere sono:
• 0 - il task è libero, non è stato ancora processato nel ciclo corrente e può venire
scelto per essere processato;
• 1 - il task è occupato e sta venendo processato da un thread;
• 2 - il task è già stato processato e bisogna aspettare il ciclo successivo per
sceglierlo di nuovo.
Il flusso di lavoro prevede che alla partenza dell’agente venga impostato a 0 il valore di quel campo per tutti i task ancora attivi (non archiviati) nella tabella, cosı̀
da garantire il consumo dei task in ordine cronologico d’arrivo. Successivamente ogni
thread seleziona il primo task (andando secondo l’ordine dell’indice id della tabella)
non ancora processato (cioè con il campo work status uguale a 0 ), occupandosi anche
di e↵ettuare un lock sulla tupla della tabella. Il lock non viene e↵ettuato usando la
corrispondente funzione LOCK messa a disposizione da SQL, ma aggiornando il campo work status della tabella a 1. Tale scelta è giustificata dal fatto che utilizzando le
primitive di SQL per il lock si potrebbero avere problemi di deadlock 3 e che se l’agente
venisse riavviato per qualche motivo le informazioni sulla base di dati continuerebbero
ad essere bloccate richiedendo un intervento manuale per la risoluzione. Quando un
3 Il
deadlock è una situazione in cui due (o più) processi (o azioni) si bloccano a vicenda aspettando
che uno esegua una certa azione (es. rilasciare il controllo su una risorsa come un file, una porta
input/output, etc.) che serve all’altro e viceversa.
5.3 Componente per la gestione del ciclo di vita dei task
95
thread finisce di elaborare un task rimuove il lock aggiornando il campo di lavoro a
2. Una volta che tutti i task non archiviati della tabella sono stati processati, cioè
quando tutti hanno work status a 2, allora il primo thread che viene eseguito che trova
questa condizione aggiorna il campo a 0 per tutti i task da elaborare. Cosı̀ facendo
i thread possono cosı̀ continuare la propria attività di tracciamento in modo ciclico
rispetto alla tabella dei task che funziona dunque come una coda.
Per garantire la concorrenza sulla selezione del task dalla tabella è stato necessario
introdurre un semaforo binario4 sfruttando il modulo BoundedSemaphore messo a
disposizione da Python per la gestione dei thread.
La TaskTracking, cosı̀ come altre componenti del server fra cui la GetOutput e la
JobTracking, fanno un uso sostenuto della base di dati. Per questo motivo è stato
necessario porre particolare attenzione all’ottimizzazione del numero di connessioni
aperte e attive. A tal fine sono state usate le Safe Session (cap. 4), lo standard messo
a disposizione del framework. Questo modulo ha permesso di gestire in modo trasparente ed efficace le connessioni necessarie incapsulandole nel concetto più generico di
sessione. Questa gestisce in modo automatico ogni connessione, aprendola solo quando
e↵etticamente necessario e chiudendola non appena è terminata l’interrogazione alla
base di dati.
5.3
Componente per la gestione del ciclo di vita dei
task
Ogni richiesta dell’utente ha per definizione una durata temporale variabile ma finita.
Un task, in quanto insieme di tuple sulla base di dati (ognuna contenente informazioni relative ai job), files di log, nonché files di input e output specifici dell’utente,
richedono un’attenta gestione in modo tale da non appesantire il carico di lavoro dei
vari agenti. Per un servizio in produzione tale attività non può essere affidato né ad
un amministratore né all’utente. Tale funzionalità deve essere necessariamente automatizzata, tramite l’implementazione di un insieme di sistemi di controllo e pulizia di
cache più avanzati possibili.
Nel caso specifico del server di CRAB gli aspetti che vanno tenuti sotto controllo e
quindi sui quali devono basarsi i sistemi di controllo e gestione del task sono:
• le credenziali degli utenti;
• il tempo di vita del tas/job sul server;
4 Un
semaforo è una struttura dati gestita da un sistema operativo multitasking per sincronizzare
l’accesso a risorse condivise tra task (cioè processi o thread). È composta da una variabile intera e
da una coda di processi. Nel caso di un semaforo binario la variabile intera può assumere 0 o 1.
96
5 Implementazione dei componenti di gestione dei task
• la completezza del task in funzione dei singoli job.
L’obiettivo principale è quello di archiviare i task vecchi dalla base di dati e rimuovere
files dallo Storage. Quest’ultimo è di particolare importanza in quanto vi possono
risiedere sia i file di input che di output di ogni singolo task. Proprio per il fatto che
quest’area contiene informazioni che dipendono dagli utenti non è di facile gestione
per via dell’uso non predicibile che ne viene fatto. La sua occupazione dipende dalle
dimensioni delle sandbox dei job (che possono variare da pochi MegaByte a qualche
GigaByte), dalla quantità di task attivi e quindi dalla quantità di utenti che utilizzano
il server. È importante notare che al momento della sottomissione di un job è impossibile per il server prevedere quale sarà la dimensione delle sandbox di output dei job,
e quindi non è possibile adottare nessuna azione preventiva se non quella di attuare
dei limiti a priori (ad esempio bloccando tutti i job degli utenti direttamente sui nodi
dei siti dove vengono prodotti file di output superiori ad una certa dimensione).
In virtù di questo è stato sviluppato un agente dedicato, che ha il ruolo di archiviare
i task una volta che il loro ciclo di vita è terminato (anche forzandone l’archiviazione
se ne è il caso) e cancellare i relativi file su Storage.
La TaskLifeManager è l’agente che svolge i compiti sopra citati. In generale le
operazioni che svolge sono le seguenti:
• ciclicamente controlla tutti i task verificando da quanto tempo si trovano sul
server: nel caso in cui un task è attivo sul server per più di una certa soglia
(specificata nel file di configurazione del server e che di default è di un mese)
allora questo viene archiviato e tutti i relativi file rimossi (tranne quelli di log)
indipendentemente dal fatto che sia attivo o meno; nel caso in cui il task è
archiviato ma i file siano ancora presenti dopo una certa soglia limite (anche
questa specificata nel file di configurazione e di default di una settimana) questi
vengono rimossi;
• ciclicamente controlla le credenziali degli utenti: se individua delle credenziali
che sono scadute archivia il task e prepara un file con la lista dei file da rimuovere
(i file sullo Storage non possono essere rimossi in assenza di credenziali valide);
nel caso in cui le credenziali non sono ancora scadute ma la loro durata residua
è al di sotto di una certa soglia allora, onde evitare che queste scadano prima
del completamento del task, viene inviata un’e-mail all’utente dove gli viene
chiesto di rinnovarle (il client mette a disposizione un semplice comando per
poterle rinnovare); nel caso in cui è possibile il server rinnova automaticamente le
credenziali contattando il servizio MyProxy, evitando cosı̀ di contattare l’utente;
• raccogliere tutti i file che non sono stati rimossi durante i due cicli sopra elencati:
prepara uno script per la loro rimozione che deve essere eseguito da un utente
5.3 Componente per la gestione del ciclo di vita dei task
97
amministratore, invia un’e-mail proprio a quest’ultimo indicandogli il motivo
dell’e-mail e il comando da eseguire;
• rimuovere i singoli file dei risultati dei job (output sandbox) mano a mano che
questi vengono ritirati dagli utenti.
5.3.1
TaskLifeManager: architettura
Anche questa componente è sviluppata secondo la teoria della programmazione ad
oggetti. I cicli da essa e↵ettuati non sono eseguiti attraverso un costrutto iterativo
della programmazione, ma sono costruiti sul sistema di messaggistica del framework:
l’agente si inizializza ed esegue una prima volta tutte le operazioni necessarie; al
termine di queste invia un messaggio a cui l’agente stesso è registrato. Il messaggio
inviato attraverso il MessageService specifica un tempo di ritardo con il quale il
messaggio deve essere recapitato. Una volta trascorso questo intervallo temporale
(specificato nel file di configurazione del server), durante il quale la componente è
rimasta in attesa passiva, il servizio di messaggistica mette a disposizione il messaggio
agli agenti che si sono registrati ad esso. La TaskLifeManager riceve il messaggio che
essa stessa si era inviato andando ad eseguire le operazioni associate.
In figura 5.5 è mostrato il diagramma per classi di questo agente, che sono:
TaskLifeManager
ProxyLife
TaskLife
Manager
TaskLifeAPI
Figura 5.5: Diagramma delle classi degli oggetti della TaskLifeManager costruito con
la specifica UML.
• TaskLifeManager: questa classe è quella principale che si occupa di inizializzare la componente prelevando le informazioni dalla configurazione e di preparare
le strutture dati necessarie, d’interfacciarsi con il MessageService, di e↵ettuare
il controllo sul ciclo di vita dei task dal punto di vista del tempo massimo di
98
5 Implementazione dei componenti di gestione dei task
permanenza attiva sul server, di cancellare i file non più necessari utilizzando
le funzionalità messe a disposizione dalle Storage Element API (descritte nel
paragrafo successivo);
• ProxyLife: questa classe mette a disposizione le funzionalità per controllare il
tempo di residuo della durata delle credenziali degli utenti, prendendo le decisioni
adeguate a seconda dei parametri specificati; per gestire con le credenziali utilizza
le Credential API messe a disposizione dal framework del server che permette
un’interazione trasparente indipendentemente dal tipo di credenziali usate;
• TaskLifeAPI: insieme di metodi che corrispondo alle operazioni necessarie per
interagire con la base di dati, sia in modo diretto con interrogazioni specifiche, sia
attraverso le TaskStateAPI descritte nel paragrafo precedente, sia attraverso
BossLite.
Di particolare interesse sono i flussi di lavoro che si occupano della gestione della
vita del task dal punto di vista del tempo di permanenza e della validità delle credenziali. In questo ultimo caso il flusso di lavoro è implementato nel metodo pollProxies
della classe ProxyLife e prevede i seguenti passi:
• seleziona dalla base di dati attraverso la TaskLifeAPI tutti le credenziali distinte;
• per ogni credenziale verifica la durata rimasta attraverso le CredentialAPI;
• nel caso in cui la durata del proxy delegato al server di CRAB tramite servizio
MyProxy (cap. 1) sia terminata, dunque che le credenziali dell’utente siano già
scadute:
– archivia sia i task che i job di quel task che non sono stati ancora archiviati utilizzando i metodi archiveBliteTask e archiveServerTask della classe
TaskLifeAPI ;
– memorizza in un campo di classe i file associati ai job del task archiviato
che devono ancora essere rimossi;
– crea uno script in grado di rimuovere i file ancora presenti e notificare via
e-mail l’amministratore che deve occuparsi di eseguire tale script;
• se le credenziali non sono ancora scadute, ma hanno una durata corta sotto una
soglia specificata:
– se è possibile queste vengono rinnovate attraverso la delega abilitata dal
server MyProxy;
5.4 Supporto per l’interazione trasparente con Storage Element
99
– nel caso in cui non sia possibile, il metodo invia un’e-mail all’utente che
cosı̀ può rinnovare e ri-delegare il proxy attraverso il client di CRAB;
• se il proxy ha un tempo di vita ancora accettabile si prosegue senza e↵ettuare
alcuna operazione.
Il flusso di lavoro e↵ettuato direttamente dalla classe principale TaskLifeManager
prevede di:
• selezionare tutti i task ancora non archiviati che sono sul server da oltre una
certa soglia temporale; la selezione viene e↵ettuata dalla classe TaskStateA-
PI sfruttando i campi TIMESTAMP della tabella dei task associata all’agente
TaskTracking;
• per ogni task archiviare tutti i task e i job ad esso associati cosı̀ come viene fatto
nel caso delle credenziali scadute;
• per ogni task verificare quali sono i file all’interno dell’area di Storage, cancellare
tutti i file presenti che sono ad esso associati;
• nel caso in cui alcuni file non possono essere cancellati per qualche motivo, viene
preparato uno script e viene notificato l’amministratore del server, cosı̀ come al
punto precedente.
5.4
Supporto per l’interazione trasparente con Storage Element
Uno Storage Element (cap. 1) è un servizio autonomo che implementa le funzioni
principali per la gestione dei dati senza l’intervento degli utenti, nascondendo a questi
ultimi le complessità strutturali del sistema di memorizzazione. Esso mette a disposizione le interfacce per accedere tramite Grid ai sistemi di memorizzazione di un sito,
rendendo possibile l’accesso remoto ai dati attraverso il supporto di diversi protocolli
e operazioni. Potenzialmente ognuno dei di↵erenti protocolli può essere utilizzato per
eseguire un’operazione. La scelta dipende da molti fattori che variano dal tipo di
Storage Element e dalle sue interfacce, dal caso d’uso specifico (alcune operazioni in
particolare sono possibili solo con un protocollo ben definito) e infine dalla decisione e
dall’affidablità del sito a supportare l’uno o l’altro protocollo. Le possibili operazioni
sono costituite principalmente da:
• trasferimento, come la copia dei dati fra due SE remoti, o fra uno remoto e l’area
locale;
100
5 Implementazione dei componenti di gestione dei task
• operazioni come la verifica dell’esistenza di un file o directory, controllo dei
permessi, cancellazioni o semplicemente la crezione di una directory; queste
interazioni coinvolgono un solo SE.
Le Storage Element API (SEAPI) sono lo strumento che è stato sviluppato per gestire
un insieme completo di operazioni su molti tipi di Storage Element utilizzando protocolli diversi. Questo framework è disegnato per raccogliere le richieste specifiche ed
eseguire le operazioni necessarie per soddisfarle, traducendo ogni singola richiesta in un
comando da eseguire. L’obiettivo chiave dello sviluppo è stato garantire l’interazione
trasparente indipendentemente dal tipo di SE utilizzato, nascondendo completamente
l’eterogeneità data dalle loro interfacce e le funzionalità fornite dai diversi protocolli.
Quindi le principali motivazioni per lo sviluppo di queste API sono:
• fornire un’interfaccia comune per accedere alle funzionalità specifiche che possa
garantire una trasparenza d’uso completa, indipendentemente dal protocollo;
questo permette di avere uno strumento che apparentemente funziona allo stesso
modo con tutti i protocolli, dando l’idea di interagire con i file remoti come se
fossero file locali;
• ottimizzare l’interazione fra protocolli di diverso tipo quando si eseguono ope-
razioni che prevedono l’interazione fra due SE di↵erenti (ad esempio: copiare i
dati da un sistema di memorizzazione all’altro);
• gestire con precisione i diversi tipi di errori e fallimenti, che dipendono dallo
specifico sistema, dal protocollo e dall’operazione e↵ettuata;
5.4.1
SEAPI: architettura
Le SEAPI sono state implementate con una struttura modulare basata sullo sviluppo
dinamico e separabile, una manutenzione del codice semplice e soprattutto con un
approccio che garantisca l’estendibilità. La programmazione orientata agli oggetti
assieme alla programmazione modulare e all’uso dei plug-in ha permesso di soddisfare
tali requisiti. I plug-in in particolare hanno permesso di costruire uno strumento che
garantisce l’uso corretto di sistemi di memorizzazione, dei protocolli eterogenei inclusa
la gestione degli errori specifici.
Come viene mostrato in figura 5.6 i principali moduli logici sono:
• Interface: è un’entità generica che a seconda della richiesta ricevuta e del tipo
di protocollo associato allo Storage Element carica il plug-in associato che traduce la richiesta nel comando specifico; questo modulo può essere considerato
come intermedio: l’utilizzatore (l’entità che usa le SEAPI) e↵ettua una chiama-
5.4 Supporto per l’interazione trasparente con Storage Element
101
ta uniforme attraverso l’interfaccia che nasconde le specifiche del protocollo in
particolare.
• Storage: è un modulo rappresentato da una classe che viene istanziata dal-
l’utilizzatore al momento di e↵ettuare una richiesta alle SEAPI; l’oggetto viene
passato al momento della richiesta di esecuzione di un’operazione come parametro all’interfaccia; quando devono essere eseguite operazioni di trasferimento che
coinvolgono due entità, l’interfaccia è in grado di gestire contemporaneamente
due istanze di questi oggetti.
• Plug-in: ogni plug-in contiene l’insieme delle istruzioni di uno specifico protocol-
lo; quando l’interfaccia e lo Storage devono inizializzare un’operazione i plug-in
vengono caricati dinamicamente a tempo di esecuzione grazie al dynamic loading.
• ErrorManager: la gestione degli errori è e↵ettuata attraverso un insieme di
metodi che verificano i risultati delle operazioni (ad esempio l’output che viene
stampato dall’esecuzione dei comandi e i relativi codici di uscita) che sono in
grado di riconoscere se vi è stato un fallimento o meno; nel caso in cui viene
rilevato un errore un metodo specifico al protocollo prepara un rapporto con il
messaggio specifico dell’errore, una breve spiegazione di esso e l’intero output
dell’operazione non riuscita;
• Exception: la gestione degli errori è basata sulle eccezioni che vengono sollevate quando un errore viene rilevato; le sottoclassi di eccezioni raggruppano e
associano tutte le classi di errore che è necessario gestire.
In figura 5.7 viene illustrato il diagramma delle classi delle SEAPI secondo il linguaggio
di modellazione e specifica UML. La classe SBinterface rappresenta l’interfaccia delle
SEAPI ed interagisce direttamente con la classe SElement che rappresenta il concetto
di Storage Element. La classe Protocol è una classe concettualmente astratta, i cui
metodi vengono implementati dai vari plug-in dedicati ai protocolli supportati. La
classe che si occupa di gestire le eccezioni è Exceptions, che allo stato attuale contiene
la definizione di 13 gruppi di errori.
5.4.2
SEAPI: funzionamento
In figura 5.8 è mostrato un esempio dell’interazione fra i moduli SEAPI nel caso dell’esecuzione di una richiesta.
L’utilizzatore e↵ettua la richiesta di un’operazione tramite l’interfaccia comune delle
SEAPI. Quest’ultima è generica e funziona come un’entità intermedia che raccoglie e
traduce la richiesta e a seconda delle specifiche sceglie a tempo di esecuzione quale
102
5 Implementazione dei componenti di gestione dei task
Figura 5.6: Principali componenti logiche delle SEAPI.
plug-in deve essere utilizzato. Quindi sempre l’interfaccia inizializza e carica dinamicamente il plug-in giusto che implementa l’insieme di istruzioni del protocollo necessario.
Dunque il plug-in selezionato esegue l’operazione richiesta traducendola nel comando
specifico. Eventuali opzioni (organizzazione virtuale, timeout dell’operazione, i parametri specifici del protocollo) sono passate dall’utilizzatore all’interfaccia che a sua
volta le traduce in parametri aggiuntivi per il plug-in.
Inoltre le SEAPI controllano anche la validità delle credenziali, almeno quando queste
sono necessarie per l’esecuzione del comando. Il loro uso è dunque specificato all’interno dell’insieme di istruzioni di ogni protocollo, che quindi può gestirle a sua necessità.
I tipi di credenziali che attualmente i plug-in stanno utilizzando sono:
• proxy generati tramite certificato
• token di kerberos
5.4 Supporto per l’interazione trasparente con Storage Element
103
SEAPI
1
SBinterface
interface
1..2
1
SElement
1..N
Ogni plugin
corrisponde ad
un protocollo
Protocol
Tipo di protocollo
Plugin 1
1
Plugin 2
Plugin N
1
1
1..N
1..N
Exceptions
1..N
Figura 5.7: Diagramma delle classi degli oggetti delle SEAPI costruito con la specifica
UML.
Operation
Request
Return
Value
Operation
Perform
Figura 5.8: Schema di un caso d’uso delle SEAPI nel caso di un tasferimento da uno
Storage Element ad un altro.
104
5 Implementazione dei componenti di gestione dei task
Capitolo 6
Risultati
“Don’t tell people how to do things.
Tell them what to do and let them
surprise you with their results.”
George S. Patton
6.1
Dalla fase di test alle operazioni in produzione
Nel waterfall model del ciclo di vita dello sviluppo di un software (cap. 2) successivamente alla fase di sviluppo c’è quella d’integrazione e test. Dunque, anche nel caso di
CRAB, prima della messa in produzione sono state e↵ettuate varie fasi di test cosı̀ da
validarne sia le funzionalità che la scalabilità. L’obiettivo è sia di verificare il livello
di maturità del servizio prima delle operazioni, che di fornire indicazioni agli sviluppatori relativamente a comportamenti anomali e possibili colli di bottiglia visibili in
condizioni di carico elevato.
I test di scala del server sono stati curati in modo particolare al fine di assicurare
efficienza di funzionamento sia nella fase iniziale dell’esperimento che a condizioni di
regime. Il numero medio di job da gestire ogni giorno nella fase iniziale è di circa
60000, corrispondenti al numero di core attualmente a disposizione per le attività caotiche e impredicibili. Il numero stimato corrisponde a circa il 50% delle risorse dei T2
è destinato ad aumentare nel tempo. [52]
6.2
Test di scala del server
L’esigenza di scalabilità e affidabilità a numeri molto alti ha chiaramente segnato le
linee guida dello sviluppo, ma soprattutto ha reso necessaria, nel corso del tempo, la
106
6 Risultati
programmazione e l’esecuzione di attente e complesse fasi di test. Fin dal principio
sono state identificate le aree più critiche da controllare attentamente prima della
messa in produzione del servizio:
• l’interazione con il middleware della Grid: per garantire la scalabilità di tutto
il sistema è importante garantire che l’uso dell’infrastruttura sottostante alle
applicazioni sia ottimizzato; proprio a tal fine il server ha un’architettura che
sfrutta le potenzialità della Grid implementando inoltre il concetto di multithreading che permette di suddividere il carico di lavoro su più thread eseguiti in
parallelo (cap. 5);
• la gestione della multi utenza e della relativa concorrenza nell’esecuzione delle
richieste: questo è un aspetto critico in quanto ogni operazione va eseguita
utilizzando le opportune credenziali dell’utente e, ovviamente, la concorrenza di
richieste non deve introdurre ritardi nelle esecuzione delle stesse; anche in questo
caso il concetto del multithreading è stato introdotto per evitare un approccio
del tipo: primo arrivato primo servito.
Entrambe gli aspetti sopra elencati hanno richiesto quindi attente fasi di test e successive iterazioni finalizzate ad ottimizzazioni. Il multithreading infatti se da un lato
risolve aspetti di concorrenza dall’altro introduce problematiche relative al carico di
lavoro della macchina fisica che ospita il server. Questa raggiungendo valori eccessivamente elevati potrebbe inficiare le prestazioni del server.
Per la fase di test è stato creato un ambiente dedicato in cui e↵ettuare le prove necessarie alla verifica della scalabilità e dell’affidabilità del server, fino ai tassi previsti dalla
collaborazione. A tal fine è stato scelto uno Storage Element basato su GridFTP[53]
installato in una macchina separata da quella in cui vengono eseguiti sia il server di
CRAB e che MySQL. Tale configurazione permette di distribuire il carico di lavoro
generato dai trasferimenti delle sandbox degli utenti e della gestione del flusso di lavoro da parte del server. Entrambe le macchine che ospitano i servizi sono costituite da
CPU 2000 MHz Dual Core AMD Opteron con 4 GB di RAM. La Grid utilizzata per
e↵ettuare questi test è stata WLCG (cap. 1). Per quanto riguarda il middleware le
sottomissioni sono state e↵ettuate attraverso due Resource Broker di tipo gLite (cap.
1) dedicati.
Tutti i job sottomessi sono stati configurati in maniera identica, in modo tale da avere
una durata approssimativa di due minuti (questa varia a seconda delle prestazioni dei
Worker Node) senza nessuna lettura di dati o altre operazioni di interazione con gli
Storage Element locali al sito, in modo da non incorrere in eventuali problemi dei siti.
Tale scelta è stata dettata dalla necessità di avere un ambiente di test rigoroso in cui
possono essere messi in evidenza eventuali errori legati al server e anche per limitare
6.2 Test di scala del server
107
l’utilizzo delle risorse dei siti. [39]
I test sono stati divisi in due fasi:
• sottomissione controllata con un solo utente;
• sottomissione multiutente.
6.2.1
Fase con un solo utente
Durante questa fase sono stati inviati al server dei task/job da un unico utente. Per
la sottomissione di jobs sono state usate due diverse configurazioni in modo tale da
avere:
• task composti da 1000 e 2000 job ogni 5 ore;
• task con 500 e 600 job ogni 20 minuti.
In tutto sono stati sottomessi circa 50000 job al giorno per 4 giorni consecutivi, per
un totale di 200000 job, come mostrato nella figura 6.1. I job sono stati distribuiti su
oltre 50 siti.
Durante questa fase di test il server non ha mostrato anomalie di funzionamento. La
gestione del carico indotto non ha mostrato colli di bottiglia e il processamento dei
task non ha accumulato ritardi significativi.
Per quanto riguarda l’e↵etto del test sul carico della macchina è stato controllato in
dettaglio l’utilizzo dei processori. In particolare MySQL ha utilizzato circa 2 core della
CPU (figura 6.2), GridFTP circa 1.5 core, mentre le componenti del server 1 solo core.
[54]
6.2.2
Fase multiutente
La necessità di ulteriori test multiutente, basati sullo stesso ambiente della fase con un
solo utente, è dettata dalla maggiore complessità dovuta dalla gestione di certificati.
Un singolo thread infatti potrebbe trovarsi a gestire richieste di utenti diversi e quindi
credenziali diverse. Questo punto è molto delicato sia per il fatto che la gestione delle
credenziali deve essere sicura, senza confusioni di sorta, sia perché ogni interazione
fra i vari certificati e i relativi ambienti di lavoro potrebbe bloccare la componente
causando dei ritardi non indi↵erenti e la conseguente crescita della coda contenente
le richieste dei vari client. Quindi durante questa seconda fase sono state e↵ettuate
sottomissioni utilizzando più certificati utente, simulando cosı̀ l’utilizzo del server di
CRAB da parte di più utenti.
In modo tale da riprodurre un uso del server il più simile possibile a quello reale sono
stati coinvolti 12 utenti che e↵ettuavano sottomissioni di job con una frequenza ben
108
6 Risultati
Figura 6.1: Distribuzione per stato dei job sottomessi attraverso il server di CRAB sul
middleware gLite durante la fase di test di sottomissioni controllate con singolo utente. Informazioni prelavate dai dati contenuti nella base di dati del server, attraverso
l’HTTPFrontend (cap. 4).
definita. Tale frequenza prevedeva che un utente inviasse 100 job ogni 15 minuti, un
altro 500 ogni 20 minuti, un altro 2000 ogni 6 ore, . . . . Inoltre per avere uno scenario
ancor più realistico due utenti sottomettevano jobs in maniera casuale, a seconda della
loro volontà. Il tipo dei job inviati era lo stesso di quelli sottomessi nella fase di test
con un unico utente.
Analizzando i risultati dei test si è potuto verificare che anche in questa fase il server
di CRAB non ha presentato anomalie nel suo funzionamento, riuscendo cosı̀ a trattare
circa 120000 job in 48 ore. Infatti, come mostrato nella figura 6.3 che mostra il numero
progeressivo di job sottomessi al server durante tale fase e distribuiti per stato, si vede
che dopo 48 ore di attività il server ha processato circa il 99.9% di job terminati che
sono in stato Cleared. Questo dimostra che la gestione del carico e l’utenza diversa non
ha costituito un problema per l’architetuttura del server. Il fatto che il 99.9% dei job è
stato processato dimostra che il carico a cui è stato sottoposto il server non corrisponde
ancora a quello limite, quindi il server potrebbbe gestire ancora più carico. Nonostante
sia ancora possibile aumentare ulteriormente il carico di lavoro di un solo server, questo
non è di immediato interesse dato che l’obiettivo è mettere in produzione il servizio
ora. Infatti, considerando solo la variabile numero di job, un unico server è in grado
6.3 Utilizzo del server di CRAB in produzione
109
Figura 6.2: Utilizzo percentuale della CPU (scala verticale) distribuito nel tempo
(scala orizzontale) da parte del server MySQL (sorgente: HTTPFrontend ).
di soddisfare le esigenze attuali (60000 jobs) e con una frequenza di sottomissione
a regime, quattro server potrebbero garantire senza problemi un ipotetico carico di
200000 jobs.
6.3
Utilizzo del server di CRAB in produzione
Durante il 2009 sono stati messi in produzione un totale di 5 server gestiti dai principali
siti della collaborazione, cioè presso: il CERN di Ginevra, i siti dell’Istituto Nazionale
di Fisica Nucleare di Bari e Legnaro, negli Stati Uniti d’America all’University of California of San Diego e infine presso il Centre de Calcul de l’IN2P3. La possibilità per
gli utenti di accedere ai servizi messi a disposizione del server di CRAB, combinata
con l’arrivo dei dati reali e le relative fasi preparatorie è stato registrato un incremento
significativo delle attività di analisi su Grid. In figura 6.4 sono mostrati il numero di
utenti per giorno che hanno utilizzato i server di CRAB messi in produzione, e come
si può ben vedere c’è un picco in prossimità della presa dei primi dati che è avvenuta
negli ultimi 2 mesi del 2009.
Dunque l’evoluzione di uno strumento come il server di CRAB combinata con l’incremento delle attività degli utenti ha portato ad un utilizzo maggiore delle risorse messe
a disposizione da parte dei siti della collaborazione, in particolare di quelle dei Tier-2
che, come detto nel captolo 3, sono quelle che il modello computazionale di CMS ha
110
6 Risultati
Figura 6.3: Distribuzione per stato dei job sottomessi al server durante la fase di test
multiutente (sorgente: HTTPFrontend ).
previsto di utilizzare per e↵ettuare l’analisi dei dati (simulati o reali che siano). L’utilizzo e↵ettuato è visibile dalle grafico in figura 6.5.
Tali informazioni provano che
il server è in grado di gestire le necessità dell’analisi della collaborazione mettendo a
disposizione un servizio scalabile, cosı̀ come attentamente valutato durante la fase di
test.
6.3.1
Valutazione dell’efficienza dei job
Utilizzando le informazioni accessibili nelle istanze in produzione è stato possibile effettuare delle valutazioni sull’efficienza dei jobs di analisi. Tale parametro permette di
avere un’indice sulla capacità di ottimizzare l’utilizzo delle risorse distribute, consentedo di verificare l’efficienza dell’utilizzo delle risorse. Tale parametro permette di capire
la quantità di potenza computazionale dei siti che viene sprecata per computazioni
che sono fallite, nonché di capire se ed eventualmente come l’applicazione sviluppata
in questo lavoro di tesi può aiutare.
A tal scopo sono stati analizzati i dati accumulati durante tutte le attività del 2009.
Sono stati messi a confronto i risultati relativi alle attività di test e lo scenario reale.
In entrambi i casi è stata utlilizzata la stessa identica infrastruttura. Nel caso dei
job di test sottomessi con CRAB la sottomissione viene controllata centralmente e
6.3 Utilizzo del server di CRAB in produzione
111
Figura 6.4: Distribuzione giornaliera del numeri di utenti diversi che hanno utilizzato
i server di CRAB a partire da Gennaio 2009 fino a metà Gennatio 2010. Grafico
generato tramite le informazioni messe a disposizione dalla Dashboard (cap. 3).
l’efficienza è circa del 90% (figura 6.6(a)). Nel caso di attività svolte dall’utente l’efficienza è di circa il 60% (figura 6.6(b)). Questa sensibile di↵erenza di efficienza nei due
casi, nonostate l’utilizzo della stessa infrastruttura, è dovuta principlamente al codice
che viene esguito, che in un caso è tenuto strettamente sotto controllo in modo da
non avere mal funzionamenti per definizione, mentre nell’altro è fortemente soggetto a
problematiche introdotte dall’utente finale, quali ad esempio memory leak nel codice
dell’eseguibile o problemi di configurazione. Tutto questo è dimostrato anche dalla
distribuzione dei job in stato Aborted, ossia falliti per ragioni esclusivamente dovute
alla Grid. Le distribuzioni in figura 6.6(a) e 6.6(b) mostrano infatti che nei due casi
(test e vita reale) le percentuali di job abortiti sono assolutamente confrontabili. Ulteriori controlli mostrano anche che nel caso degli utenti finali le tre principali cause
di fallimento, esclusi il 10% dei job abortiti, sono:
112
6 Risultati
Figura 6.5: Distribuzione dei job sottomessi tramite i server di CRAB fra i siti della
collaborazione CMS (sorgente: Dashboard ).
• nello stage in, con problemi di accesso ai dati da analizzare localizzati sullo
Storage Element locale;
• nello stage out, che è frequentemente soggetto a problemi di memorizzazione dei
risultati su Storage Element remoto;
• nel codice dell’utente che può contenere errori di programmazione.
Dal punto di vista dell’applicazione (CRAB), al fine di migliorare l’efficienza dei
job di analisi risulteranno di particolare importanza gli sviluppi futuri del server,
in particolare per quanto riguarda:
• la capacità di isolare l’utente in un ambiente controllato garantendogli un accesso
comunque quanto più trasparente possibile;
• la risottomissione intelligente dei job falliti tramite appositi plug-in della componente ErrorHandler;
• ottimizzazione del flusso di lavoro e dell’interazione con gli strumenti della Grid.
113
6.3 Utilizzo del server di CRAB in produzione
1.00
0.80
0.80
0.60
0.60
0.40
0.40
0.20
0.20
0.00
0.00
(a) Job di test.
(b) Job di utenti.
Figura 6.6: Distribuzione della frazione giornaliera di jobs terminati con successo
durante tutto l’anno 2009 (sorgente: Dashboard ).
0.45
0.30
0.40
0.25
0.35
0.20
0.30
0.25
0.15
0.20
0.15
0.10
0.10
0.05
0.05
0.00
0.00
(a) Job di test.
(b) Job di utenti.
Figura 6.7: Distribuzione giornaliera della percentuale di jobs terminati con stato
Abort durante tutto l’anno 2009 (sorgente: Dashboard ).
114
6 Risultati
Conclusioni
In questo lavoro di tesi è stata progettata e sviluppata un’applicazione basata sull’architettura client-server per il calcolo distribuito in ambiente Grid. Il client è stato
disegnato per proporre all’utente un’interfaccia più semplice e intuitiva possibile. Il
server è costituito da agenti indipendenti sviluppati secondo i paradigmi di programmazione modulare e multithreading, che comunicano in modo asincrono tramite un
sistema di messaggistica persistente, gestita attraverso una base di dati. Per garantire
un approccio sistematico alla realizzazione del server sono state seguite le strategie
dell’ingegneria del software sia in fase di progettazione che in fase di codifica, basandosi sul modello waterfall del ciclo di vita del software.
L’aspetto che è stato curato in particolare è quello relativo alla gestione e al tracciamento delle informazioni al livello del task, entità che identifica univocamente la
richiesta e↵ettuata dall’utente e che successivamente viene fattorizzato dall’applicazione in entità minori. Data la crucialità della gestione dei task, è stato necessario
sviluppare un agente dedicato per l’aggregazione di tutte le informazioni relative alle
entità di cui è composto. L’altro aspetto di rilevante importanza è legato alla gestione automatica del ciclo di vita del task e all’automazione di quelle operazioni che
altrimenti richiederebbero l’intevento di un amministratore del server, approccio non
scalabile per un servizio in produzione. Questo riguarda sia la gestione delle credenziali
che gli utenti delegano al server, che la gestione dello spazio disco sull’area di memorizzazione associata al server. Proprio per quest’ultimo è stato necessario implementare
un sistema di API capace di garantire trasparenza e genericità delle interazioni con
gli Storage Element della griglia computazionale, consentendo di e↵ettuare operazioni
su diverse tipologie di sistemi di archiviazione, indipendentemente dal protocollo e
dall’operazione e↵ettuata.
L’introduzione di questi strumenti ha consentito di ottimizzare fortemente la gestione
di tutti i flussi di lavoro (task) controllati dal server. In particolare si possono mettere
in evidenza i tre vantaggi principali sintetizzabili in: possibilità di creare resoconti per
tutti i task, facilitandone quindi il controllo da parte dell’utente; capacità di aggregazione di informazioni per l’amministratore per il controllo dello stato del servizio;
possibilità d’implementazione di sistemi di allarme per l’autogestione dei cicli di vita
dei task e i relativi file memorizzati. È a quest’ultimo livello che le librerie per l’interfacciamento con i servizi di memorizzazione risultano uno strumento essenziale al fine
di garantire l’interoperabilità.
L’applicazione client-server sviluppata è attualmente in uso da tutta la collaborazione
CMS per l’accesso ai dati reali, recentemente prodotti dall’esperimento, nonchè per
piccole produzioni di dati simulati. Precedentemente, inoltre, esso è stato lo strumento utilizzato per i vari test di scala preparatori e↵ettuati dalla collaborazione.
Questo lavoro di tesi si inquadra nel contesto dello sviluppo del sistema di Workload
Management di CMS e costituisce il risultato di 14 mesi di collaborazione con il
Dipartimento di Fisica dell’Università degli Studi di Perugia, la sezione di Perugia
dell’Istituto Nazionale di Fisica Nucleare, il CERN di Ginevra e il progetto europeo
EGEE.
Il progetto del server di CRAB prevede l’estensione del sistema con interfacce per
il supporto dell’interazione con i vari strumenti di calcolo dell’eseperimento CMS al
fine di garantire la gestione automatizzata di flussi di lavoro complessi e concatenati,
caratteristici di un esperimento di fisica delle alte energie. Alcuni prototipi sono già
stati sviluppati e altri sono in fase d’implementazione.
Ringraziamenti
Il primo grazie sincero e dovuto va a Leonello e a Daniele che mi hanno seguito,
spronato e incitato durante tutto questo intenso percorso formativo. Lo stesso vale
per tutti i colleghi, amici e fisici del dipartimento di Fisica, della sezione INFN e del
CERN.
Grazie ad Igor per avermi supportato (o sopportato. . . in ogni caso sappi che è stato
e sarà reciproco in entrambi i casi) da collega di studio e non solo. Grazie anche ad
Hassen che mi ha sopportato nel vero senso della parola, cosı̀ come hanno dovuto fare
tutto il “sesto piano” e gli “informatici” emigrati a fisica.
Ringrazio anche i coinquilini di “Casa dei matti” che nonostante vivano con me hanno
di rado la fortuna di vedermi, eppure si sentono come se io ci fossi sempre (. . . ahimé
direte!): Francesco il vecchietto di casa, Giulia l’unica svizzera che sa cucinare bene
e Martina, lei sı̀ che non sapeva a cosa stesse andando incontro quel giorno in cui mi
disse: “Sı̀, tu vai bene”.
Un grazie ad Enrico che anche oggi starà facendo la parte del più giovane e inserito
della situazione, a Jacopo che mi ha sempre supportato, a Ivan che si è dimostrato un
vero amico, a Valeria che ha perso la sfida di chi finisse per primo e a Silvia che da
quando è diventata Professoressa è un po’, comprensibilmente, scomparsa. . . ma che
comunque si ricorda sempre. Ringrazio anche tutti gli amici con cui ho perso un po’ i
contatti per motivi logistici, ma su cui so di poter sempre contare (ora che l’ho scritto
non potete fare diversamente), fra cui: Andrea C., Andrea G., Andrea T., Christian,
Gianluca, Leonardo e Luca. E per tutti i Dott. Ing. Civili: è un piacere avervi conosciuto, dal primo all’ultimo. Non posso certo dimenticare gli amici con cui ho iniziato
a frequentare gli ambienti universitari, Antó, Fabrizio, Francè, Lauretta, Paolino e gli
altri “studenti”: oggi per me finisce una fase importante e ne inizia un’altra (speriamo) che per me non significherà certo iniziare a dimenticarvi!
Ma i ringraziamenti più importanti vanno alla mia famiglia, senza la quale nulla sarebbe mai stato possibile: non potrò far altro che esservi grato per tutta la vita per quello
che siete e che avete fatto per me. E mi dispiace se non sono stato presente come certe
volte avreste desiderato. Ho semplicemente cercato di raggiungere quegli obiettivi che
Bibliografia
[1] G. E. Moore “Cramming more components onto integrated circuits” Electronics
Magazine Vol. 38, No. 8 (April 19, 1965).
[2] Al Geist et al. “PVM : parallel virtual machine : a users’ guide and tutorial for
networked parallel computing”, 3rd edition, MIT Press, 1996.
[3] Jack Dongarra, Peter Kacsuk, Norbert Podhorszki “Recent advances
in parallel virtual machine and message passing interface”, proceeding of 7th European PVM/MPI users’ group meeting, Balatonfüred (Hungary) 2000, Lecture
notes in computer science, Springer (2000).
[4] I. Foster et al. “Overview of the I-WAY: Wide-Area Visual Supercomputing”,
The International Journal of Supercomputer Applications and High Performance
Computing, Volume 10, Number 2/3, Summer Fall (1996).
[5] I. Foster, C. Kesselman “The Grid:
Blueprint for a New Computing
Infrastructure”, Morgan-Kaufmann (1999).
[6] The Condor Project
http://www.cs.wisc.edu/condor
[7] Streit “UNICORE: Getting to the heart of Grid technologies”, eStrategies,
Projects, 9th edition, British Publishers Ltd (2009).
[8] O. Smirnova et al. “The NorduGrid Architecture And Middleware for Scientific
Applications”, ICCS 2003, LNCS 2657, p. 264., Springer-Verlag (2003).
[9] M. Ellert et al. “Advanced Resource Connector middleware for lightweight
computational Grids”, Future Generation Computer Systems (2006).
[10] LCG - LHC Computing Grid
http://lcg.web.cern.ch/LCG
[11] EGEE - Enabling Grid for E-sciencE
http://www.eu-egee.org
[12] M. Cecchi et al. “The gLite Workload Management System” JPCS Proceedings
of International Conference on Computing in High Energy and Nuclear Physics
(CHEP’07).
[13] OSG - Open Science Grid
http://www.opensciencegrid.org
[14] “European Grid Initiative Blueprint” (2008)
http://eu-egi.eu/,www.eu-egi.eu/blueprint.pdf.
[15] Venugopal S. et al. “Market-Oriented Cloud Computing: Vision, Hype, and
Reality for Delivering IT Services as Computing Utilities”, Proceedings of the
10th IEEE International Conference on High Performance Computing and Communications (HPCC-08, IEEE CS Press, Los Alamitos, CA, USA), Sept. 25-27,
2008, Dalian, China.
[16] I. Foster, C. Kesselman, S. Tuecke “The Anatomy of the Grid: Enable Scalable Virtual Organizations”, proceeding of the Internet and Multimedia Systems,
and Applications (2005).
[17] S. Tuecke “Grid security infrastructure (GSI) roadmap”, Grid Forum Draft,
GSI Working Group (2000).
[18] A. Kertész “Brokering solutions for Grid middlewares”, 1st doctoral workshop
on mathematical and engineering methods in computer science., MEMICS 2005,
Brno (2005).
[19] A. Cooke et al. “R-GMA: An Information Integration System for Grid Monitoring”, On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and
ODBASE, Lecture Notes in Computer Science, Springer Berlin (2003).
[20] The MAGIC-5 Project - Medical Application on a Grid Infrastructure Connection
http://www.magic5.unile.it/
[21] J. D. McCabe “Network Analysis, Architecture, and Design, Third Edition”,
The Morgan Kaufmann Series in Networking (2007).
[22] RFC
3530
“NFS
Version
4
Protocol
Specification”,
http://tools.ietf.org/html/rfc3530 (2003).
[23] Gerald Carter, Jay Ts, Robert Eckstein “Using Samba, Third Edition”,
O’Reilly Media (2007).
[24] “Oracle, Oracle9i Real Application Clusters, Oracle white paper”, February 2002.
[25] S. C. Yadav, S. K. Singh “An Introduction to Client/Server Computing” New
Age International Publishers (2009).
[26] RFC 959 “File Transfer Protocol (FTP)”, http://tools.ietf.org/html/rfc959
(1985).
[27] J. Gutérrez “Business Data Communications and Networking: A Research
Perspective” Ided Group Publishing (2007).
[28] K. Jayaswal “Administering Data Centers: Servers, Storage, And Voice Over
Ip”, Wiley India Pvt. Ltd. (2005).
[29] W. Jia, W. Zhou “Distributed Network and Systems, From Concepts to
Implementations” Springer Science and Business Media, Network Theory and
Applications, Volume 15 (2005).
[30] LHC Homepage, http://cern.ch/lhc
[31] R. Bailey “The LEP collider”, C. R. Physique 3 (2002) 1107–1120.
[32] S. Chartrchyan et al., “The CMS Experiment at CERN LHC”, Jornal of
Instrumentation, vol 3, pp.s08004 (2008).
[33] C.Grandi, D.Stickland, L.Taylor et al., “The CMS Computing Model”,
CERN-LHCC-2004-035/G-083 (2004).
[34] A. Afaq et al., “The CMS dataset bookkeeping service”, J.Phys.Conf.Ser, 119,
072001 (2008).
[35] R. Egeland et al., “Data transfer infrastructure for CMS data taking”,
Proceedings of Science, PoS(ACAT08)033 (2008).
[36] E. W. Dijkstra “A note on two problems in connexion with graphs” Numerische
Mathematik 1: 269–271 (1959).
[37] D. Spiga for the CMS Collaboration, “CMS Workload Management”,
Nucl.Phys.Proc.Suppl. 172:141-144 (2007).
[38] D. Evans et al., “The CMS Monte Carlo Production System: Development
and Design”, 18th Hadron Collider Physics Symposium 2007 (HCP 2007) 2026 May 2007, La Biodola, Isola d’Elba, Italy. Published in Nuclear Physics B Proceedings Supplements, Volumes 177-178 (2008) 285-286.
[39] G. Codispoti, M. Cinquilli, D. Spiga et al., “Distributed analysis with CRAB: the client-server architecture evolution and commissioning”, ACAT
2008 - XII Advanced Computing and Analysis Techniques in Physics Research,
November 3-7 2008 Erice, Italy, proceedings at POS (ACAT) 029.
[40] The CMS Collaboration “CMS Physics Technical Design Report, Volume II:
Physics Performance”, J. Phys. G: Nucl. Part. Phys. 34 995-1579 (2007).
[41] K. Bloom “US CMS Tier-2 Computing”, International Conference on Computing in High Energy and Nuclear Physics (CHEP’07), Journal of Physics:
Conference Series 119 (2008).
[42] I. Fisk “Early Experience with the CMS Computing Model”, Proceedings of XII
Advanced Computing and Analysis Techniques in Physics Research, Nov. 3-7,
2008, PoS(ACAT08)038.
[43] D. Spiga, M. Cinquilli et al., “The CMS Remote Analysis Builder (CRAB)”
High Performance Computing (HiPC 2007), Lecture Notes in Computer Science,
Springer, Volume 4873/2007 (2008).
[44] F. van Lingen, M. Cinquilli, D. Spiga et al. “Job Life Cycle Management
libraries for CMS Workflow Management Projects” 17th International Conference
on Computing in High Energy and Nuclear Physics, Prague, Czech Republic, 21
- 27, Mar 2009.
[45] D. Riehle “Framework Design: A Role Modeling Approach” Swiss Federal
Institute of Technology (2000).
[46] MySQL, http://www.mysql.com
[47] T. W. Doeppner “Parallel program correctness through refinement” Proceedings of the ACM Symposium on the Principles of Programming Languages,
155–169, (1977).
[48] R. A. Van Engelen and K. A. Gallivan “The gSOAP Toolkit for Web Services and Peer-to-Peer Computing Networks” Cluster Computing and the Grid,
IEEE International Symposium on, Los Alamitos, CA, USA, IEEE Computer
Society p. 128, 0-7695-1582-7, (2002).
[49] D. Beazley, P. Lomdahl “Feeding a large-scale physics application to python”
Proceedings of the 6th International Python Conference, (1997).
[50] S. Hellegouarch “CherryPy Essentials:
Rapid Python Web Application
Development”, Packt Publishing, (2007).
[51] SQLite Home Page, http://www.sqlite.org
[52] The CMS Collaboration “The CMS Computing Project - Technical Design
Report” CERN-LHCC-2005-023, CMS TDR 7, 20 June 2005.
[53] W. Allcock et al. “GridFTP: Protocol Extension to FTP for the Grid”, Grid
Forum Internet-Draft, March 2001.
[54] A. Fanfani, D. Spiga, M. Cinquilli et al. “Distributed Analysis in CMS”,
CERN CMS Note (2009).

Scarica

Sviluppo di procedure per l`automatizzazione del flusso di lavoro per

Sviluppo di procedure per l`automatizzazione del flusso di lavoro per

Slide 1

Presentazione standard di PowerPoint

s24_Qui Berlino

MODELLO ISFOL e JOB DESCRIPTION

RondoLift-ST Tavolo due in uno ad altezza regolabile o fissa.

Brainstorming-nuovoPON-COMETA

il mercato del lavoro

Gestione e Pianificazione Aziendale Lezione 10 – 3 giugno 2008

con esercizi svolti dagli studenti

PantoMove-Soft Sedia regolabile in altezza.