tesi triennale - grid credit system: un portale per la sostenibilità di compchem
Post on 29-Nov-2014
1.655 Views
Preview:
DESCRIPTION
TRANSCRIPT
UNIVERSITÀ DEGLI STUDI DI PERUGIAFacoltà di Scienze Matematiche, Fisiche e Naturali
Corso di laurea in INFORMATICA
Tesi di Laurea Triennale
Grid Credit System:un portale per la sostenibilità
di COMPCHEM
Laureando: Relatore:Davide Ciambelli Prof. Antonio Laganà
Correlatore:Dr. Leonardo Pacifici
Anno Accademico 2006/2007
Alla mia famiglia.
Indice
Elenco delle figure 5
1 Dal calcolo sequenziale al grid computing 1
1.1 Architetture uniprocessore . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Calcolo sequenziale . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Gestione della concorrenza . . . . . . . . . . . . . . . . . . 3
1.1.3 Parallelismo a livello di istruzione . . . . . . . . . . . . . 4
1.1.4 Parallelismo a livello dei dati . . . . . . . . . . . . . . . . 8
1.1.5 Limiti delle architetture sequenziali . . . . . . . . . . . . 9
1.2 Architetture multiprocessore . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Tassonomia di Flynn . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Altre tassonomie . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.3 Ulteriore suddivisione delle macchine MIMD . . . . . . . 16
1.2.4 Macchine UMA (Uniform Memory Access) . . . . . . . . . 18
1.2.5 Macchine NUMA (Non Uniform Memory Access) . . . . . 19
1.2.6 Alcuni metodi di interconnessione di un sistema distribuito 20
1.3 Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.1 Cenni storici . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Lo sviluppo delle Grid . . . . . . . . . . . . . . . . . . . . 27
1.3.3 La sfida attuale: dalla fase di R&D allo sfruttameno . . . 31
1.3.4 Lo sfruttamento della piattaforma Grid in Italia . . . . . 32
2 La Grid di produzione di EGEE 34
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3
INDICE
2.2 L’articolazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3 Virtual Organization in EGEE . . . . . . . . . . . . . . . . . . . 39
2.3.1 Virtual Organization Membership Server . . . . . . . . . 40
2.3.2 MyProxy Server . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4 EGEE Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.1 gLite: La Futura Generazione di Middleware EGEE . . . 42
3 Il portale web 45
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 La sostenibilità di una Organizzazione Virtuale . . . . . . . . . 46
3.3 Il sistema di crediti . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 L’ambiente web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5 Il database Crediti . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6 L’architettura del portale . . . . . . . . . . . . . . . . . . . . . . . 56
3.6.1 Amministratore . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6.2 Utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Conclusioni 65
A Sorgenti 66
A.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.2 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2.1 login.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2.2 logout.php . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.2.3 checkuser.php . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.2.4 checksuperuser.php . . . . . . . . . . . . . . . . . . . . . . 72
A.2.5 checklab.php . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.2.6 op_crediti.php . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.2.7 op_crediti_singolo.php . . . . . . . . . . . . . . . . . . . . 75
Bibliografia 77
4
Elenco delle figure
1.1 Ciclo di Von Neumann . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Grafico della legge di Moore . . . . . . . . . . . . . . . . . . . . . 3
1.3 Esecuzione pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Esecuzione superscalare . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Esecuzione VLIW . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Architetture di calcolo . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Architettura SISD . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Architettura SIMD . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.9 Architettura MISD . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.10 Architettura MIMD . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.11 Memoria condivisa . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.12 Memoria distribuita . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.13 Modello UMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.14 Modello NUMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.15 Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.16 Stella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.17 Ipercubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.18 Crossbar switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.19 Butterfly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 L’ambiente web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Schema E/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5
ELENCO DELLE FIGURE
3.3 Mappa del portale . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 Amministrazione - area personale . . . . . . . . . . . . . . . . . 59
3.5 Amministrazione - calcolo dei crediti . . . . . . . . . . . . . . . . 62
3.6 Utente - schermata dell’area personale . . . . . . . . . . . . . . . 63
3.7 Utente - schermata dell’attività della griglia . . . . . . . . . . . 64
6
Capitolo 1
Dal calcolo sequenziale algrid computing
We will probably see the spread of ”computer utilities”, which,like present electric and telephone utilities, will service
individual homes and offices across the country.- Len Kleinrock -
1.1 Architetture uniprocessore
1.1.1 Calcolo sequenziale
Le architetture a singolo processore sono basate sul noto modello di Von Neu-
mann [1]. In questo modello l’unità di elaborazione, dal momento della sua
accensione fino allo spegnimento, attraversa incessantemente, ripetitivamen-
te ed alla sua massima velocità il ciclo mostrato in Figura 1.1. Nella fase di
bootstrap il processore esegue una serie di istruzioni prelevandole da una
ROM (il BIOS ad esempio) che mettono la macchina in grado di funzionare
correttamente. Successivamente, il processore entra nel vero e proprio ciclo
di funzionamento e vengono seguite le seguenti operazioni:
• fetch (caricamento): produce il caricamento della prossima istruzione da
eseguire.
• decode (decodifica): interpreta l’istruzione che si trova nella memoria
1
1.1 Architetture uniprocessore
come un codice che dovrà essere opportunamente ”riconosciuto” dal pro-
cessore ed eseguito.
• operand assembly (preparazione degli operandi): raccoglie gli eventua-
li operandi necessari a svolgere l’istruzione corrente (per esempio: gli
addendi di una somma, un indirizzo di memoria da incrementare, ecc.).
• execute (esecuzione): consiste nell’eseguire effettivamente l’istruzione
corrente sugli operandi collezionati.
Figura 1.1: Ciclo di Von Neumann
A valle di questa fase il processore controlla se si sono verificati degli inter-
rupt, ovvero particolari istruzioni che consentono l’interruzione di un processo
qualora si verifichino determinate condizioni o quando un processo deve effet-
tuare una richiesta al sistema operativo (questa fase non è mostrata nella fi-
gura). Successivamente ritorna alla fase di fetch per procedere all’esecuzione
dell’istruzione successiva.
L’architettura di Von Neumann ha rappresentato il punto di partenza per
la manipolazione efficiente delle informazioni. Rispetto all’originale, l’archi-
tettura ha subito importanti cambiamenti per aumentare la velocità e miglio-
rare l’efficienza. Il grande passo verso i calcolatori più veloci è stato suppor-
tato dagli avanzamenti della tecnologia nel campo dello sviluppo di circuiti
integrati. L’aumento di elementi circuitali in un processore ha reso le CPU
più efficienti, le memorie più capienti ed i bus più veloci e performanti. Tut-
2
1.1 Architetture uniprocessore
to ciò a portato ad un costante aumento della velocità di calcolo che è stata
quantificata nel 1965 dalla prima legge di Moore (Figura 1.2):
Le prestazioni dei processori, e il numero di transistor ad essi relativo,
raddoppiano ogni 18 mesi.
Tuttavia, essendoci un limite a questo processo (un segnale non può essere
più veloce rispetto alle velocità della luce nel mezzo in cui si propaga), la ricer-
ca si è sviluppata lungo direttrici parallele, compresi circuiti ottici, dispositivi
molecolari, calcolatori quantistici, ecc...
Figura 1.2: Grafico della legge di Moore
1.1.2 Gestione della concorrenza
La concorrenza era già un concetto intrinseco nel modello di Von Neumann in
quanto tale architettura utilizza bus per il trasferimento parallelo di bit. Il
primo calcolatore a valvole termoioniche (ENIAC [2]) era costituito da 25 uni-
tà di calcolo indipendenti. Tuttavia, la maggior parte del progresso iniziale
venne ottenuto solo a livello gestionale. I concetti di multiprogrammazione e
3
1.1 Architetture uniprocessore
time-sharing stavano gettando le basi per la costruzione di hardware e soft-
ware concorrente in computer sequenziali. A tal proposito, concetti e tecnolo-
gie come il prefetching e il rescheduling delle istruzioni avevano come intento
quello di aumentare la concorrenza.
Il reale avanzamento, tuttavia, è stato raggiunto attraverso la duplica-
zione delle CPU, la segmentazione delle unità di elaborazione e il partizio-
namento della memoria. Questa forma di concorrenza implementata su una
macchina sequenziale è chiamata ”parallelismo”.
1.1.3 Parallelismo a livello di istruzione
Nel parallelismo a livello di istruzioni (Instruction Level Parallelism, ILP)
avviene l’esecuzione di più istruzioni in maniera concorrente. Questo è realiz-
zabile utilizzando il pipeling: viene sfruttata l’organizzazione dell’hardware
all’interno della CPU dividendolo in distinte sezioni impiegate per la gestione
delle diverse fasi delle istruzioni. Un insieme di porte logiche viene utilizza-
to per la gestione della fase di fetch, un’altra sezione per la decodifica delle
istruzioni, e così via. Questo significa che ad ogni istante è attiva solo una
sezione, rendendo quindi possibile l’utilizzo delle altre sezioni per gestire la
fase corrispondente in una successiva istruzione.
Questo rappresenta il concetto di base dell’architettura pipeline (Figu-
ra 1.3):
Figura 1.3: Esecuzione pipeline
dove IF è l’Instruction Fetch, ID è l’Instruction Decode, EX è l’Execution,
4
1.1 Architetture uniprocessore
MEM è il Memory Access e WB è il Write/Back. Una volta eseguita la fase
di fetch per l’istruzione i, si può procedere ad eseguire il fetch per l’istruzione
i+1, mentre l’istruzione i passa alla fase di decode. Successivamente si potrà
passare alla fase di fetch per l’istruzione i+2 mentre l’istruzione i+1 è nella
fase di decode e l’istruzione i in quella di execute.
Architetture superscalari
In una macchina di tipo pipeline, sebbene le istruzioni vengano eseguite in
concorrenza, in ciascuno stage della pipe è presente una sola istruzione. In
una macchina superscalare di grado n invece, il numero di istruzioni atti-
ve è n. Per sfruttare completamente questa ”pipe replicata”, devono esserci n
istruzioni eseguibili in parallelo (grado di ILP = n), altrimenti si dovranno for-
zare delle attese per attendere i dati provenienti dalle precedenti istruzioni.
Formalmente:
• istruzioni caricate per ciclo = n
• latenza di ciascuno stadio della pipe = 1
• ILP necessario = n
Nell’esempio della Figura 1.4 il grado di parallelismo assume un valore ugua-
le a due (n = 2). Molti microprocessori utilizzano questa tecnologia, con livelli
di parallelismo due, tre, quattro oppure, come nel caso del multichip IBM PO-
WER2, con livello sei. Nella figura IF è l’Instruction Fetch, ID è l’Instruction
Decode, EX è l’Execution, MEM è il Memory Access e WB è il Write/Back.
Architetture VLIW
Il principio di funzionamento delle architetture VLIW (Very Long Instruction
Word) si basa sulla specifica di un certo insieme di istruzioni caricate ed ese-
guite contemporaneamente dal processore (Figura 1.5). Dalla definizione po-
5
1.1 Architetture uniprocessore
Figura 1.4: Esecuzione superscalare
trebbe sembrare che un processore superscalare e un processore VLIW siano
analoghi. In realtà si differenziano per due caratteristiche principali:
• Nelle macchine VLIW la selezione delle istruzioni da caricare in un
ciclo di clock avviene durante la compilazione mentre per le macchi-
ne superscalari avviene durante l’esecuzione del programma. La lo-
gica di decodifica per le VLIW risulta molto più semplice rispetto alle
superscalari.
• Quando in una macchina superscalare la densità di codice è maggiore,
il grado di ILP è inferiore a quello disponibile nell’architettura VLIW.
Infatti il formato di istruzioni della VLIW è fisso e comprende dei bit
anche per istruzioni inutili che non verranno utilizzate.
I chip di tipo VLIW non necessitano dei complessi circuiti di controllo che i
chip superscalari, invece, adottano per coordinare le operazioni parallele: i
chip VLIW trasferiscono gran parte della mole di lavoro ai compilatori. In
questo modo, gli strumenti di sviluppo software che i programmatori utilizza-
no per compilare i loro programmi in codice eseguibile hanno la responsabilità
di organizzare le istruzioni nel modo più efficiente possibile.
6
1.1 Architetture uniprocessore
Figura 1.5: Esecuzione VLIW
Inoltre i chip VLIW combinano due o più istruzioni in un singolo pac-
chetto; il compilatore organizza quindi questi pacchetti in modo che il chip
VLIW possa rapidamente eseguire le istruzioni in parallelo, liberando il mi-
croprocessore dal compito di dover eseguire le complesse e continue analisi
che invece devono essere condotte dagli altri chip in fase di runtime.
Architetture multiscalari
Il più recente paradigma ILP è quello Multiscalare [3], nel quale la granu-
larità del parallelismo, sfruttata a livello di istruzione, è maggiore rispetto a
quella delle architetture superscalari. In questa architettura il programma
caricato in memoria è suddiviso frache molti task indipendenti e logicamen-
te disaccoppiati che vengono distribuiti alle unità funzionali, dove le fasi del
7
1.1 Architetture uniprocessore
ciclo di macchina sono applicate alle istruzioni del task assegnato.
1.1.4 Parallelismo a livello dei dati
Il parallelismo sfruttato a livello dei dati (Data Level Parallelism, DLP) dif-
ferisce dall’ILP nella granularità degli operandi coinvolti nelle operazioni. Le
operazioni aritmetiche sono eseguite su array di oggetti: in questo modo il pa-
radigma risulta efficiente rispetto ad applicazioni che coinvolgono un elevato
numero di operazioni su matrici.
Processori vettoriali
Questo tipo di processori, oltre ai normali registri e istruzioni scalari, contiene
degli speciali tipi di registri (registri vettoriali) che possono contenere N valori
contemporaneamente, ed ogni operazione che coinvolga uno di questi registri
viene eseguita su tutti i valori in esso memorizzati.
Affinché questo meccanismo sia efficiente è necessario che il collegamento
con la memoria sia molto veloce, ovvero che abbia una banda passante mol-
to elevata; in questo tipo di macchine anche la memoria è caratterizzata da
un’architettura vettoriale, vale a dire strutturata in modo che sia possibile
leggere o scrivere esattamente N valori contemporaneamente.
É inoltre possibile specificare un altro registro vettoriale come destinazio-
ne dell’operazione corrente, nel quale il risultato verrà ulteriormente mani-
polato. Queste macchine sono programmabili con facilità (il parallelismo è
gestito in maniera del tutto trasparente al programmatore), ma danno buone
prestazioni solo nel caso di algoritmi con molte operazioni vettoriali.
Array processor
Un array processor non ha istruzioni scalari, ma solo vettoriali: è costituito
da una unità di controllo (UC) che gestisce un array di processori (Processing
Element, PE): i collegamenti fra i PE e fra PE e memoria, sono di tipo matrice
bidimensionale, vale a dire che ogni PE comunica con i suoi quattro vicini,
8
1.1 Architetture uniprocessore
con la UC e con la memoria. La UC legge le istruzioni, se sono scalari le
esegue lei stessa mentre se sono vettoriali le invia ad ogni PE che si occupa
di un singolo dato dell’array, in parallelo: quando tutti i PE hanno terminato,
la UC passa all’istruzione successiva. Per questo un array processor viene
considerato una macchina a parallelismo spaziale cioè un insieme di unità
funzionali replicate e utilizzate nello stesso tempo per realizzare una singola
o diverse computazioni. Le prestazioni di un array processor sono ancora
più legate al tipo di operazione: è molto veloce solo quando opera su array e
vettori.
Una evoluzione dell’array processor è la Connection Machine, che al posto
dei normali PE introduce delle celle costituite da un PE e una memoria locale,
connesse con una topologia ipercubica.
Array sistolici
Gli array sistolici sono delle architetture che elaborano un flusso di dati che
si muove in modo prevedibile e ritmico lungo uno specifico percorso durante
la sua elaborazione. Sono utilizzati spesso nell’elaborazione dei segnali in
quanto i dati sono campionati con delle frequenze conosciute e devono subire
delle elaborazioni predefinite che interessano tutti i dati. In questi array ogni
elemento esegue una specifica elaborazione che dipende solamente dai dati di
ingresso e dal suo stato interno. I dati elaborati vengono mandati in uscita
dove un altro elemento provvederà a riceverli ed elaborarli. Le operazioni
sono sincronizzate tramite un clock globale. Gli algoritmi eseguiti su questi
array sono detti sistolici in analogia al flusso sanguigno che fluisce ad impulsi
tramite percorsi predefiniti.
1.1.5 Limiti delle architetture sequenziali
Le architetture sequenziali descritte nelle sezioni precedenti stanno raggiun-
gendo il limite fisico delle loro prestazioni. Infatti, oltre alla velocità di esecu-
zione, che può essere aumentata usando la già citata gestione della concorren-
9
1.2 Architetture multiprocessore
za implementata nelle architetture ILP e DLP, c’è il limite fisico che riguarda
la connessione diretta di una singola CPU ad una memoria sufficientemente
grande. Consideriamo il caso di un computer scalare che deve eseguire in un
secondo il seguente ciclo nel quale vengono trasferite 3 · 1012 variabili dalla
memoria ai registri di CPU:
Do i=1 to 1000000000000a(i)=b(i)+c(i)
EndDo
Ciò implica che se r è la distanza media di una parola dalla memoria alla CPU,
la distanza generale da coprire mentre vengono trasferite 3 · 1012 variabili in
un secondo è 3 · 1012 · r. Poiché la velocità della luce è 3 · 108 m/s si ottiene r =
10−4 m. Se abbiamo 3 · 1012 celle di memoria (ognuna contenente una parola)
disposte come una matrice bidimensionale, allora si hanno circa 106 celle per
riga. Questo significa che ogni cella non può avere una dimensione più grande
di 10−6 · r oppure 10−10 m che rappresenta il diametro medio di un atomo. Di
conseguenza, poiché non possiamo immagazzinare un numero di bit pari a
32/64 in una locazione del calibro di un atomo, non possiamo costruire un
computer scalare con le prestazioni massime di 1 Tflops. Ciò significa che
per aumentare le prestazioni dell’hardware si devono sviluppare piattaforme
aventi molti processori ciascuno dei quali circondato da una memoria locale.
1.2 Architetture multiprocessore
Come già accennato il parallelismo è definito come la simultanea esecuzione
di operazioni indipendenti. Lo sfruttamento del parallelismo può riguardare
tutti i livelli di astrazione di un computer. A tal proposito, è utile introdurre
una tassonomia di classificazione che identifica le varie architetture in base
ai flussi di dati e istruzioni.
10
1.2 Architetture multiprocessore
1.2.1 Tassonomia di Flynn
Partendo dal modello di Von Neumann, che consiste di un processore che ese-
gue sequenzialmente una serie di istruzioni per produrre un risultato, una
classificazione può essere basata sul concetto di flusso di istruzioni e flusso
di dati. La più famosa ed accettata classificazione delle architetture per i
sistemi paralleli è quella proposta da Michael J. Flynn [4]. Secondo questa
classificazione, le due più importanti caratteristiche di un elabratore sono:
• il numero di flussi d’istruzioni che può processare ad ogni istante;
• il numero di flussi di dati sul quale può operare simultaneamente.
In base a questa classificazione ogni sistema di calcolo rientra in una di queste
categorie (Figura 1.6):
• SISD (Singola Istruzione Singolo flusso di Dati);
• SIMD (Singola Istruzione Multiplo flusso di Dati);
• MISD (Multiple Istruzioni Singolo flusso di Dati);
• MIMD (Multiple Istruzioni Multiplo flusso di Dati).
Figura 1.6: Architetture di calcolo
11
1.2 Architetture multiprocessore
SISD
Nel 1946 Von Neumann stabiliva i principi generali di progettazione di un ela-
boratore. L’architettura SISD (Figura 1.7) si basa proprio su questi principi
essendo essenzialmente una macchina seriale con un unico flusso di istruzioni
dove ad ogni ciclo di clock viene eseguita una sola istruzione. Le prestazioni
vengono calcolate in MIPS (Milioni d’Istruzioni Per Secondo). Molte delle ap-
plicazioni sviluppate con questa tecnologia non vengono fatte rientrare nella
categoria dei supercomputer.
Figura 1.7: Architettura SISD
SIMD
É ancora un’architettura di Von Neumann ma con istruzioni che operano su
più elementi (Figura 1.8). Questa tecnologia utilizza processori identici e
interconnessi che ricevono dati diversi da un host intermediario ed eseguo-
no le stesse operazioni sui dati ricevuti. La velocità d’elaborazione si misu-
ra in MFLOPS (Million FLOating-Point per Second). Le architetture SIMD
possono essere suddivise in due classi:
• SIMD vettoriali, che nello stesso istante lavorano sull’intero vettore di
dati. É previsto un host che si occupa di distribuire i dati ai vari worker;
• SIMD paralleli, che inviano la stessa istruzione vettoriale a tutti i pro-
cessori. In questo caso l’host si occupa soltanto del controllo, mentre i
dati vengono scambiati tramite memoria condivisa o rete d’interconnes-
sione.
12
1.2 Architetture multiprocessore
Figura 1.8: Architettura SIMD
MISD
Sono architetture caratterizzate dall’avere processori che svolgono diverse
operazioni su di un singolo flusso di dati, allo stesso istante di tempo (Fi-
gura 1.9). É da notare che, mentre nella classe SIMD la granularità, ovvero
la dimensione delle attività eseguibili in parallelo, è quella delle istruzioni,
nella classe MISD la granularità è quella dei processi ovvero dei programmi
composti da più istruzioni.
Figura 1.9: Architettura MISD
MIMD
Rappresenta il modello d’architettura parallela più potente e flessibile, per-
ché in grado di gestire flussi d’istruzioni e dati multipli (Figura 1.10). Ogni
processore riceve dalla propria unità di controllo un flusso d’istruzioni e rice-
ve un flusso di dati tramite la memoria condivisa o la rete d’interconnessione,
lavorando così in maniera asincrona rispetto agli altri. É quindi di fondamen-
tale importanza che il carico di lavoro sia bilanciato. A seconda del numero di
13
1.2 Architetture multiprocessore
processi è possibile distinguere macchine a grana grossa (poche unità molto
potenti) da quelle a grana fina (molte unità poco potenti).
Una ulteriore classificazione di queste macchine riguarda i metodi di co-
municazione. I computer MIMD che usano la memoria condivisa sono chia-
mati multiprocessori (Tightly Coupled Machines) mentre quelli che utilizza-
no la rete d’interconnessione sono chiamati multicomputer (Loosely Coupled
Machines).
Figura 1.10: Architettura MIMD
1.2.2 Altre tassonomie
La tassonomia di Flynn presenta dei limiti che la rendono inadeguata rispet-
to alla classificazione delle architetture più moderne. Questa tassonomia,
infatti, confina tutte le macchine parallele nella classe MIMD. Per questa
ragione, altre tassonomie sono state proposte da vari autori. Esse fornisco-
no parametri supplementari per classificare attualmente tutte le macchine
disponibili:
• Tassonomia di Handler [5]: nel 1977 Handler propose una notazio-
ne elaborata per esprimere il pipeling ed il parallelismo dei computer.
La tassonomia di Handler descrive un computer in base a tre elementi
architetturali la PCU (Processor Control Unit), la ALU (Arithmetic Lo-
gic Unit), e il BLC (Bit-Level Circuit). La PCU corrisponde alla CPU,
14
1.2 Architetture multiprocessore
la ALU corrisponde ad una unità funzionale o elemento di elaborazio-
ne in un array processor e il BLC corrisponde alla logica necessaria per
realizzare operazione one-bit nella ALU. In particolare, la tassonomia di
Handler fa uso di tre coppie di interi per descrivere un computer:
Computer = (k*k’, d*d’, w*w’)k = numero di PCUk’= numero di PCU che formano la pipelined = numero di ALU controllate da ogni PCUd’= numero di ALU che formano la pipelinew = numero di bit nella ALU o parole
processing element (PE)w’= numero di pipeline segmentate
su tutta la ALU o in un singolo PE
Per esempio, il CRAY-1 è un computer a singolo processore a 64 bit con
12 unità funzionali aventi da 1 a 14 segmenti che possono essi stessi
essere messi in pipe. Per esempio, secondo la tassonomia di Handler la
notazione per il CRAY-1 è la seguente:
Cray-1 = (1, 12*8, 64*(1 ~ 14))
• Tassonomia di Shore [6]: Shore propose la sua tassonomia nel 1973.
É basata sulla struttura e sul numero di unità funzionali incorporate nel
computer. Questa tassonomia è caratterizzata da sei categorie diverse
ognuna delle quali è associata ad un numero (Type-I - Type-VI).
• Tassonomia di Hockney e Jesshope [7]: Hockney e Jesshope han-
no sviluppato una notazione elaborata chiamata ASN (Algebraic-style
Structural Notation) al fine di descrivere computer paralleli. Questa
notazione è alla base della loro tassonomia strutturale.
15
1.2 Architetture multiprocessore
1.2.3 Ulteriore suddivisione delle macchine MIMD
I computer paralleli di tipo MIMD possono generalmente implementare due
diversi modelli architetturali:
1. macchine con memoria locale che comunicano mediante messaggi (clu-
ster Beowulf)
2. macchine con memoria condivisa che comunicano attraverso lo spazio in
memoria (macchine SMP)
Un tipico cluster Beowulf è un insieme di macchine con singola CPU, connes-
se usando schede Ethernet ed è, pertanto, una macchina a memoria locale.
Una macchina SMP a 4 vie è una macchina a memoria condivisa e può essere
usata per eseguire applicazioni parallele che comunichino tramite la memo-
ria condivisa. Le macchine a memoria locale sono caratterizzate dall’essere
altamente scalabili mentre il numero di CPU in macchine a memoria deve
essere limitato a causa di conflitti nell’accesso alla memoria.
Tuttavia, è possibile connettere molte macchine a memoria condivisa per
creare una macchina a memoria condivisa ”ibrida”. Queste macchine ibride
”appaiono” all’utente come una grande macchina SMP e un esempio è rap-
presentato dalle macchine di tipo NUMA (Non Uniform Memory Access) nel-
le quali la memoria globale vista dal programmatore è condivisa da tutte le
CPU. É anche possibile connettere macchine SMP come nodi di calcolo a me-
moria locale. Le tipiche schede madri della CLASSE I hanno 2 o 4 CPU e
spesso rappresentano un mezzo per ridurre il costo del sistema complessivo.
Lo schedulatore interno del sistema operativo determina come queste CPU
gestiscano le risorse condivise. L’utente pertanto, non può assegnare uno spe-
cifico task ad uno specifico processore SMP. L’utente può, comunque, iniziare
due processi indipendenti oppure un processo multithreaded e aspettarsi un
aumento di performance rispetto ad un sistema avente una singola CPU. Per-
ciò è importante tenere in considerazione le modalità di comunicazione tra
16
1.2 Architetture multiprocessore
i vari nodi per permetterne il coordinamento e l’ottimizzazione. La modalità
con cui i processi possono comunicare dipende dall’architettura della memoria
e può essere di tre tipi:
• memoria condivisa
• memoria distribuita
• memoria gerarchica
Memoria Condivisa
Nelle architetture a memoria condivisa i processori operano in maniera indi-
pendente e la sincronizzazione è ottenuta controllando i valori che essi leg-
gono e scrivono (Figura 1.11). La condivisione dei dati tra i processi avviene
velocemente (in base alle velocità di accesso alla memoria). Uno dei proble-
mi più comuni è rappresentato dall’accesso simultaneo alla stessa locazione
di memoria da parte di più processori. Inoltre il bus che connette memo-
ria e processore ha una banda limitata che può causare dei colli di bottiglia.
Per risolvere i problemi di concorrenza relativi all’accesso in memoria, de-
vono essere implementati da parte del programmatore dei vincoli (semafori
lock-unlock) per evitare situazioni di stallo o di indeterminazione.
Figura 1.11: Memoria condivisa
Memoria distribuita
Questo tipo di architettura di memoria è tipico delle reti di computer (Figu-
ra 1.12). Ogni processore opera indipendentemente e con la propria memoria
17
1.2 Architetture multiprocessore
privata; la sincronizzazione dei processi e la condivisione dei dati avvengo-
no tramite la rete. Il meccanismo di comunicazione maggiormente usato è il
message passing, implementato esplicitamente attraverso le primitive SEND
e RECEIVE eliminando così il pericolo di interferenze. Queste architettu-
re sono caratterizzate dal fatto che la banda per la comunicazione aumenta
con l’aumentare del numero dei nodi, e il programmatore è responsabile della
gestione dello scambio dei dati.
Figura 1.12: Memoria distribuita
Memoria Gerarchica
Questa architettura è una combinazione delle due descritte precedentemente.
Si ha una memoria condivisa globale che comunica con delle memorie locali
anch’esse condivise dai processori. Le memorie locali sono molto veloci e pos-
sono essere usate per fornire dati ai processori mentre la memoria globale,
che è più lenta, può essere usata per un ”backfill” alle memorie più piccole
attraverso il trasferimento di pagine di dati. Questo metodo può risultare
inefficiente se viene utilizzata solo una piccola parte delle pagine. Il program-
matore deve occuparsi degli schemi di accesso alle memorie e strutturare la
memorizzazione dei dati.
1.2.4 Macchine UMA (Uniform Memory Access)
Si tratta tipicamente di multiprocessori simmetrici (SMP), con strutture di
interconnessione a bassa latenza ed elevato grado di interconnessione ( Figu-
ra 1.13). La memoria è uniformemente condivisa da tutti i processori, i quali
18
1.2 Architetture multiprocessore
impiegano tutti lo stesso tempo per accedervi. La rete di interconnessione
può essere bus comune o crossbar switch. La sincronizzazione tra i processo-
ri avviene mediante variabili condivise nella memoria comune. L’accesso ai
dispositivi di I/O può essere simmetrico, dove ogni processore è in grado di
eseguire le parti di sistema operativo relative all’I/O, o asimmetrico, dove al-
cuni processori (master) possono eseguire le chiamate di sistema dell’I/O e gli
altri processori (slave) fanno richiesta ai primi. Solo attraverso ottimizzazioni
è possibile ridurre l’occupazione di memoria di uno o più ordini di grandezza
rispetto al valore numericamente uguale alla performance.
Figura 1.13: Modello UMA
1.2.5 Macchine NUMA (Non Uniform Memory Access)
Ogni processore ha la propria memoria locale, ma può accedere anche a quel-
la di un altro processore passando attraverso la rete di interconnessione con
tempi di accesso ovviamente più lunghi. Queste macchine (Figura 1.14) sono
idealmente adatte anche ad applicazioni irregolari, con alto grado di località
degli accessi, che utilizzano paradigmi di parallelizzazione control parallel e
data parallel e che operano anche su grandi insiemi di dati (basi di dati tradi-
zionali o intelligenti). L’architettura NUMA fornisce ad ogni processore una
piccola zona di memoria ad accesso esclusivo e veloce in modo da evitare la
creazione di colli di bottiglia. Nel caso di applicazioni che richiedono la condi-
visione di dati come nel caso di server e simili l’architettura NUMA migliora
19
1.2 Architetture multiprocessore
le prestazioni se si suddivide la memoria centrale in diversi banchi e si as-
segna ad ogni banco un numero ridotto di processori. Naturalmente i dati
non sono realmente separati nelle memorie dei singoli processori e se dei dati
devono essere elaborati da più processori questo è possibile. In questo caso
l’architettura NUMA prevede che il software o dei dispositivi hardware prov-
vedano a spostare i dati da un banco a un altro. Questa copia dei dati rallenta
i processori e quindi l’efficienza delle architetture NUMA dipende molto dai
compiti svolti dal sistema.
Figura 1.14: Modello NUMA
1.2.6 Alcuni metodi di interconnessione di un sistema distri-buito
La differenza principale tra le architetture MIMD (indistintamente dal ti-
po di modello di memoria utilizzato) consiste nella modalità di scambio dei
dati. Infatti, in N macchine a processore singolo (non importa se MIMD o SI-
MD) lo scambio di dati, informazioni e segnali può avvenire in due modalità
differenti:
• adottando variabili condivise su memoria condivisa
• adottando scambio di messaggi su reti di interconnessione
Le topologie principali delle reti di interconnessione possono essere raggrup-
pate come di seguito illustrato:
20
1.2 Architetture multiprocessore
• Bus unico condiviso: nella topologia a bus (Figura 1.15) tutti i proces-
sori sono connessi tra loro in modo lineare, tali da formare una sequen-
za. Le estremità di un bus non sono collegate tra loro, ma devono essere
sempre terminate, altrimenti i segnali che raggiungono la fine del cavo
possono fare un eco indietro, disturbando la trasmissione. Nelle reti con
topologia a bus viene di solito utilizzata la trasmissione a ”commutazio-
ne di pacchetto”. Un elemento che vuole trasmettere delle informazioni
divide il messaggio in tanti piccoli pacchetti e li invia uno alla volta. La
topologia a bus è usata spesso con la cablatura in cavo coassiale. Un
grosso limite è dato dal fatto che un’interruzione del cavo interrompe la
trasmissione in ogni direzione. Poiché tutti i computer connessi condivi-
dono lo stesso mezzo trasmissivo, essi utilizzano dei protocolli che garan-
tiscono che in ogni istante un solo elemento stia trasmettendo. Un caso
particolare della topologia a bus è quella ad anello dove le due estremità
sono unite tra loro a formare un anello. In questa topologia le informa-
zioni viaggiano in una sola direzione. I dati, organizzati in pacchetti
ognuno dei quali contiene l’indirizzo di destinazione, girano all’interno
di questo anello fino a raggiungere il computer di destinazione.
Figura 1.15: Bus
• Connessione a stella: nella topologia a stella (Figura 1.16) tutti i com-
puter sono connessi ad un nodo centrale che può essere un semplice
ripetitore (hub) o un dispositivo intelligente (switch o router). Nelle reti
con topologia a stella i pacchetti che vengono inviati da un nodo ad un
altro sono ripetuti su tutte le porte dell’hub. Questo permette a tutti i
21
1.2 Architetture multiprocessore
nodi di vedere qualsiasi pacchetto inviato sulla rete, ma solo il nodo a cui
il pacchetto è indirizzato lo copierà sul proprio hard disk. Uno dei van-
taggi è dato dal fatto che se vi è un’interruzione su una delle connessioni
della rete solo il nodo collegato a quel segmento ne risentirà, mentre tut-
ti gli altri continueranno ad operare normalmente. Uno svantaggio è il
costo aggiuntivo imposto dall’acquisto di uno o più hub. Di solito questa
spesa è compensata dalla più facile installazione e dalla economicità del
cablaggio in twisted pair rispetto al cavo coassiale.
Figura 1.16: Stella
• Ipercubo: questa topologia (Figura 1.17) consiste di 2k nodi organizzati
come un ipercubo di dimensione k. I nodi sono numerati da 0 a 2k − 1 e
due nodi sono connessi solo se la loro rappresentazione binaria differisce
solo per un bit.
Figura 1.17: Ipercubo
• Crossbar switch: i processori e le memorie formano i due lati della
rete di interconnessione come si vede dalla Figura 1.18: coppie distinte
22
1.3 Grid
processore memoria possono comunicare tra loro contemporaneamente
grazie alla rete di commutazione.
Figura 1.18: Crossbar switch
• Butterfly: una rete butterfly (Figura 1.19) ha (k + 1)2k nodi distribuiti
tra (k + 1) linee, ognuna costituita da 2k nodi di interconnessione.
Figura 1.19: Butterfly
1.3 Grid
Molte applicazioni scientifiche, soprattutto nell’ambito della chimica e della
fisica, possiedono dei requisiti di memoria e CPU tali da poter essere eseguiti
efficientemente solo su piattaforme distribuite. Attualmente però, non sem-
23
1.3 Grid
pre è possibile individuare piattaforme adatte in termini di tempo di attesa e
capacità di memorizzazione viste le moli di output (Gbyte) prodotte da molte
applicazioni. Questi problemi stanno trovando soluzione grazie alla nascita di
piattaforme di calcolo distribuite geograficamente e coordinate tra loro grazie
a particolari software chiamati middleware. Tali piattaforme sono le griglie
computazionali (Grid). La prima grid in Europa nasce nel febbraio del 2000
all’interno dell’INFN (Istituto Nazionale di Fisica Nucleare), l’Ente pubblico
italiano che promuove, coordina e sviluppa ricerche sperimentali e teoriche di
base nell’ambito della fisica nucleare e sub-nucleare, da sempre all’avanguar-
dia nello sviluppo di tecnologie avanzate. Il progetto INFN-Grid [8] coinvolge
da allora le strutture di calcolo di 20 sedi localizzate nelle principali Uni-
versità italiane e di 5 laboratori nazionali. Sebbene focalizzato allo sviluppo
dell’infrastruttura di calcolo per il Large Hadron Collider (LHC) (il nuovo
acceleratore di paticelle del CERN), il progetto parte con l’obiettivo di svilup-
pare una soluzione generale aperta alle esigenze delle comunità scientifiche
e dell’industria. La grid è la nuova tecnologia che permetterà agli scienziati
di collaborare a grandi obiettivi internazionali di ricerca, raggiungibili solo
mettendo in comune le centinaia di migliaia di PC e i grandi super-computers
delle Università, degli Enti di Ricerca e dei Centri di Calcolo di tutta l’Europa
e del mondo, come se fossero un’unica grande risorsa.
Analogamente al WEB (sviluppato al CERN intorno al 1990), che ha pro-
messo di rivoluzionare l’accesso all’informazione disponibile in domini di ge-
stione diversi e distribuiti geograficazmente, così il software utilizzato da Grid
(middleware) rivoluzionerà lo sfruttamento dell’enorme mole d’informazio-
ni digitali che le moderne società producono sempre più abbondantemente,
renderà fruibili a tutti risorse computazionali indipendentemente dalla loro
localizzazione e permetterà lo sviluppo di nuove applicazioni in ogni settore.
Per raggiungere tale scopo il Middleware di Grid affianca al servizio HTTP
del WEB una nuova serie di servizi che consentono di accedere in modo tra-
24
1.3 Grid
sparente ad ogni tipo d’informazione digitale: immagini di satelliti, dati da
acceleratori come LHC del CERN, basi di dati della genomica e proteomica,
immagini mediche da TAC, NMR, PET, disegni tecnici da CAD indipenden-
temente dal dominio geografico o di gestione nel quale si trovano. Questa
tecnologia è implementata in modo sicuro grazie ad un’infrastruttura di sicu-
rezza distribuita, basata su certificati personali di tipo X509 rilasciati da un
insieme d’autorità di certificazione, legate ad un sistema d’autorizzazione che
permette di mantenere un completo controllo locale su chi e quando può usare
le proprie risorse. Nello stesso tempo tale sistema consente di stabilire dina-
micamente in modo centralizzato politiche generali per regolare le priorità e
l’uso delle stesse risorse.
1.3.1 Cenni storici
L’idea della Grid nasce negli USA alla fine degli anni ’90 come risultato finale
dell’elaborazione collettiva della comunità scientifica sul calcolo distribuito,
iniziata agli inizi di quel decennio.
Nel 1989-90 comincia all’INFN, al CERN e nei maggiori Centri di Calcolo
in Europa e negli USA, la rivoluzione che si affiancò a quella del WEB e di
Internet e che porterà, nel giro di pochi anni, all’integrazione delle griglie
con i grandi supercalcolatori mainframe, i cluster di workstation e i Personal
Computer (PC).
I mainframe, costruiti su architetture speciali sviluppate per pochi gran-
di sistemi, richiedono tempi e costi di progettazione e realizzazione tali che
rapidamente non è possibile più tenere il passo con lo sviluppo dei processori
”commodity” adottati da milioni di utenti. I semplici PC (che tutti possono tro-
vare e gestire) e i dischi poco costosi a questi collegati, assieme alle interfacce
di rete standard e agli standard backbones per le reti locali (Ethernet), diven-
tano componenti elementari per costruire sistemi di calcolo davvero ragguar-
devoli. Le prestazioni di queste componenti da allora migliorano, seguendo la
25
1.3 Grid
già citata legge di Moore, di un fattore 2 ogni 18 mesi a parità di costo e le loro
dimensioni si miniaturizzano tanto che oggi si arriva ad alloggiare centinaia
di CPU e dischi in un rack standard di 60× 80 cm2.
L’INFN è stato all’avanguardia in questa trasformazione. Nel 1989 rea-
lizzò al CERN, in un comune progetto di ricerca e sviluppo con Digital, uno
dei primi cluster di workstations basato su processori commodity, noto co-
me ”INFN Farm”. Esso mostrò al mondo scientifico come questa tecnologia
potesse essere utilizzata nell’ambito dell’esperimento DELPHI [9] per le pro-
prie esperienze con costi che, per le applicazioni di quell’esperimento, a parità
di potenza erogata, erano inferiori di circa un ordine di grandezza rispetto a
quelli del grande mainframe della Computing Division.
Negli anni ’90 questa trasformazione fu completata. I modelli di calcolo
”centralisti” basati sui grandi supercomputers (IBM, Cray), attorno ai qua-
li sono nati i grandi Centri di Calcolo con migliaia di utenti negli USA e in
Europa, sono stati progressivamente sostituiti da modelli distribuiti che pos-
sono sfruttare i clusters di PC, i quali sono attualmente disponibili in molte
Università e Centri di Ricerca.
L’ultimo passo importante per le Grid fu la riduzione dei costi per l’uso
della rete geografica. Grazie alle liberalizzazioni intervenute in tutto il mondo
a metà degli anni ’90 nel settore delle telecomunicazioni, i costi cominciarono
a decrescere ancora più rapidamente di quanto previsto dalla legge di Moore
per CPU e dischi.
Alla fine degli anni ’90 erano quindi disponibili, su una rete a banda larga
che collegava le università e i centri di ricerca di tutto il pianeta con veloci-
tà di trasmissione sempre più elevata e costi sempre più ridotti, un numero
crescente di risorse computazionali e di memoria. Si pose quindi il problema
dello sviluppo di una nuova tecnologia che permettesse alla comunità scien-
tifica di sfruttare e condividere in modo dinamico queste risorse distribuite
per accelerare i processi innovativi ed aumentare la propria efficienza nella
26
1.3 Grid
produzione scientifica.
Il concetto di Grid, proposto per la prima volta da Ian Foster e Karl Kessel-
mann nella primavera del 1999 [17], propose una strategia che è stata rapi-
damente adottata da tutta la comunità scientifica internazionale che si basa
sullo sviluppo di servizi e protocolli standard per la condivisione di risorse
distribuite che ne nascondeno all’utente l’eterogeneità.
1.3.2 Lo sviluppo delle Grid
Nel 1998 a seguito del progetto Globus (Argonne National Laboratory e ISI
California) si iniziarono a sviluppare alcuni servizi di base che cercavano di
realizzare il concetto di Grid. Questi sono rapidamente stati resi disponi-
bili come Open Source attraverso il Globus Toolkit [10] che divenne un pri-
mo standard internazionale de facto per l’accesso e la condivisione di risorse
computazionali distribuite.
In Europa nel 2000 è stato l’INFN a promuovere la costituzione del primo
grande progetto Grid europeo, DataGrid [11].
Gli obiettivi principali di DataGrid prevedevano:
• lo sviluppo di nuove componenti di middleware per l’accesso a dati di-
sponibili in domini di gestione diversi e distribuiti a livello geografico;
• l’ottimizzazione della gestione dei carichi di lavoro su risorse computa-
zionali distribuite a livello geografico;
• la realizzazione di un primo ”testbed” Europeo che permettesse l’inizio
di effettive attività utili per la comunità scientifica.
All’interno di DataGrid l’INFN ha collaborato fin da subito con la Data-
mat SpA per lo sviluppo del middleware e con NICE per la realizzazione del
portale GENIUS (Grid Enabled web environment for site Independent User
job Submission). GENIUS [12] permette all’utente in modo molto semplice di
27
1.3 Grid
accedere alla Grid in maniera sicura, di eseguire le proprie applicazioni, e di
accedere in modo trasparente ai dati della comunità di cui fa parte.
Inoltre l’INFN in collaborazione con il CERN e altri partners europei avviò
nel 2001 il progetto DataTAG [13] che affronta il problema dell’interoperabi-
lità con le Grid in sviluppo negli Stati Uniti e nei paesi dell’area Asia-Pacifico.
DataTAG tentò di stabilire uno stretto legame di collaborazione con i princi-
pali progetti Grid avviati negli Stati Uniti (Globus e Condor, per esempio) per
lo sviluppo d’interfacce comuni e di standard internazionali anche all’interno
della nuova organizzazione mondiale che venne allora a crearsi per questo
scopo, il Global Grid Forum.
La fase di consolidamento (2001-2003)
Nei due anni seguenti un numero crescente d’attività di ricerca e sviluppo sul-
le Grid è stato finanziato da quasi tutti i Paesi e dalla Comunità Europea che
già nel Quinto Programma Quadro (biennio 2001-2003) approvò circa venti
progetti di finanziamento. Di questi l’Italia ottenne il 10%.
Contemporaneamente negli Stati Uniti la National Science Foundation
(NSF) e il Department Of Energy (DOE) finanziarono diversi progetti tra cui
spicca TeraGrid che aveva come obiettivo la costruzione di un’infrastruttura
nazionale di supercalcolo.
In Italia vennero sviluppati alcuni progetti tra i quali emerse GRID.IT
che coinvolge molte Istituzioni di ricerca e università (compresa l’Università
di Perugia), il progetto Grid per la finanza (EGrid), il progetto Grid per il
supercalcolo al sud S-PACI, il progetto Grid Inter-dipartimentale a Napoli
e altri progetti minori. Tutti i maggiori Enti di ricerca (INFN, CNR, INAF,
INGV, ASI ed ENEA) e molte università sono stati progressivamente coinvolti
nelle attività di sviluppo e sfruttamento della Grid.
28
1.3 Grid
La maturità (2003-2006)
Nel successivo Sesto Programma Quadro (FP6) della Comunità Europea le
Grid ottennero un posto di primo piano.
Ottenne il via libera anche il nuovo progetto Europeo EGEE 1. Il progetto
partì il 1 aprile 2004, con durata di 2 anni, e realizzò la prima Grid euro-
pea per la scienza, aperta all’industria al commercio e alle piccole e medie
imprese. EGEE è l’acronimo di Enabling Grids for E-sciencE e può essere
considerato il successore di DataGrid e DataTAG.
La costruzione della prima Grid Europea di produzione da parte di EGEE
è stata un’impresa storica, coordinata dal CERN di Ginevra, a cui partecipa-
no più di 70 Enti e Istituzioni scientifiche appartenenti a 26 Paesi Europei
organizzati in 9 grandi Federazioni. Questa struttura deve fornire le risorse
di calcolo e storage, le applicazioni, i servizi operativi e di gestione necessari
per far funzionare questa grande infrastruttura. Un sistema di ”accounting”
tiene conto dell’uso delle risorse mentre un robusto e sicuro sistema d’au-
tenticazione e autorizzazione garantisce ad un numero sempre più vasto d’u-
tenti (dell’ordine di decine di migliaia) appartenenti a varie organizzazioni e
comunità scientifiche, la sicurezza e la riservatezza necessaria.
EGEE ha sviluppato anche un middleware Grid Open Source robusto ed
affidabile, costruito con stretti criteri d’ingegneria del software e in grado
di durare nel tempo. Questo è andato a sostituire quello esistente facendo
passare definitivamente l’Europa dalla fase di ”sperimentazione” a quella di
”produzione”.
Oggi EGEE rappresenta una grande sfida vinta dalla comunità scienti-
fica europea chiamata ad organizzarsi in tempi brevi in un grande progetto
competitivo a livello mondiale. EGEE integra tutte le esistenti infrastrut-
ture Grid nazionali con le loro strutture tecniche e operative in una grande1Come vedremo meglio in seguito è stato finanziato EGEE 2 (all’interno del quale Perugia
è presente tra le attività unfunded di NA4). É in fase di presentazione la domanda per ilfinanziamento di EGEE 3 all’interno del quale è previsto un piccolo finanziamento per Perugia.
29
1.3 Grid
e-Infrastruttura (Internet e Grid) di scala europea. EGEE si può collegare
alla Cyber-Infrastruttura americana proposta dalla National Science Foun-
dation e alle Grid asiatiche in costruzione in Cina e Giappone. É un passo
decisivo verso la costruzione di una Grid mondiale, necessaria alle moderne
società che mettono la conoscenza alla base di ogni nuovo sviluppo. Si tratta
di una svolta epocale dal punto di vista scientifico e tecnologico, poiché le Grid
di produzione cambieranno il modo di fare ricerca sia per gli enti pubblici sia
per le aziende private.
L’Italia svolge un ruolo in tutte le attività di EGEE. L’INFN coordina la
federazione italiana a cui partecipano le tre Università del consorzio S-PACI
(Southern Partnership for Advanced Computational Infrastructures) Calabria,
Lecce, Milano, Napoli, Perugia, l’ENEA e le industrie Datamat SpA e NICE.
L’Italia dunque interpreta un ruolo d’eccellenza in questo settore grazie al
ruolo svolto dall’INFN e da altri enti nella sperimentazione e nello sviluppo
delle Grid in Europa e nel mondo.
In Italia grazie agli investimenti nel progetto INFN Grid e nell’infrastrut-
tura di Calcolo per LHC, fatti in anticipo rispetto al resto degli altri Paesi
Europei, stanno rendendo possibile la creazione di un’infrastruttura naziona-
le e-Science condivisa da molti settori di ricerca come la Fisica, l’Astrofisica, la
Geofisica, la Biologia, la Chimica Computazionale che si pone all’avanguardia
nel mondo.
Numerosi sono i progressi effettivamente realizzati per la diffusione di
questa tecnologia in Italia. Sono stati completamente automatizzati gli stru-
menti per l’installazione del midleware e lo sviluppo di quelli per il controllo e
il management operativo procede a ritmi incessanti. Gli utenti Grid possono
già installare e aggiornare il loro middleware abbastanza semplicemente e di-
spongono del portale GENIUS che consente l’uso trasparente dei servizi della
Grid. Gli utenti possono provare direttamente questa funzionalità tramite la
piattaforma di prova (testbed) GILDA messa a punto dall’INFN ed utilizzata
30
1.3 Grid
da EGEE per le attività di divulgazione [14].
1.3.3 La sfida attuale: dalla fase di R&D allo sfruttameno
Le recenti attività di ricerca e sviluppo hanno portato ad una vasta produ-
zione di software per middleware, in gran parte disponibili in Open Source,
che permettono di certificare ed autorizzare gli utenti, elaborare dati digitali
distribuiti, sostenere estesi processi di modellizzazione e condividere in modo
trasparente risorse computazionali distribuite. Molti di questi servizi, grazie
al loro utilizzo in varie infrastrutture del mondo della ricerca (DataGrid, LHC
Computing Grid, EGEE), cominciano a possedere livelli di robustezza e qua-
lità tali da poter fornire una soluzione operativa per altri settori della società.
Obiettivi primari della fase attuale per l’Italia e l’Europa sono:
• costruire un framework (Piattaforma Tecnologica a livello EU) per il
coordinamento delle attività su Grid svolte a livello nazionale.
• Gestire e facilitare il passaggio da una prima fase di Ricerca e Sviluppo
ad una caratterizzata dallo sfruttamento della tecnologia Grid in nuove
e-Infrastrutture e a livello industriale.
• consolidare le componenti middleware, sviluppate finora in modo non
coordinato in progetti indipendenti, in una piattaforma di servizi Grid
coerenti e interoperabili maggiormente aderenti a Standard Internazio-
nali e resi disponibili come sofware Open Source.
• Avviare una serie di progetti pilota per lo sfruttamento di questa piat-
taforma nella Ricerca, nell’Industria e nei Servizi.
É evidente quanto l’utilizzo delle Grid possa avere un impatto dirompente
sull’evoluzione tecnologica futura del mondo della ricerca, di quello dell’indu-
stria e dei servizi e possa essere in grado di sostenere lo sviluppo di nuovi
settori produttivi, com’è stato per il WEB nel passato.
31
1.3 Grid
1.3.4 Lo sfruttamento della piattaforma Grid in Italia
Recentemente l’INFN ha proposto che l’Italia si doti di un’organizzazione in
grado di coinvolgere le maggiori istituzioni di ricerca attive nel campo nel pro-
muovere e sostenere lo sfruttamento puntuale di quanto finora prodotto, for-
nendo al tempo stesso continuità, solidità e fondamento alle future evoluzioni
di questa piattaforma e agli interventi a livello internazionale. Il Consor-
zio per l’Open Middleware Enabling Grid Applications (c-OMEGA) permet-
terà all’Italia di conservare il suo attuale livello di eccellenza internazionale
rispetto alle recenti iniziative adottate da altri paesi:
• L’Open Middleware Initiave (OMII) in UK [15]
• La New Middleware Initiative (NMI) in US [16]
I principali obiettivi del consorzio c-OMEGA sono:
• Diventare un punto di riferimento nazionale per la creazione, lo svilup-
po, il supporto e la diffusione della piattaforma tecnologica Grid in Italia
e in Europa, lavorando anche in stretto coordinamento con gli USA e i
paesi dell’Asia.
• Sfruttare creativamente le componenti di middleware e gli ambienti
Grid già sviluppati indipendentemente per costruire in Italia delle re-
leases di servizi coerenti e interoperanti basati sugli Standard emer-
genti dagli Organismi Internazionali per Grid e architetture Service-
oriented. (Per esempio specifiche OGSA del Global Grid Forum, WSRF
di OASIS, security di W3C), compatibilmente con le modalità e le tipo-
logie di licenze open source.
• Far coesistere la missione e gli obiettivi del mondo della ricerca e acca-
demico con quelli del mondo industriale ed in particolare quelli dei gran-
di servizi pubblici nazionali (Ospedali, Scuole, Amministrazioni pubbli-
che).
32
1.3 Grid
• Estendere in tutto il paese, con attività d’informazione, formazione e
progetti mirati, lo sfruttamento delle tecnologie Grid in modo da far
nascere nuove opportunità di crescita e di occupazione aumentando allo
stesso tempo la competitività globale del Paese.
33
Capitolo 2
La Grid di produzione diEGEE
A computational grid is a hardware and software infrastructurethat provides dependable, consistent, pervasive, and inexpensive
access to high-end computational capabilities.- Carl Kesselman and Ian Foster -
2.1 Introduzione
Il progetto europeo EGEE (Enabling Grids for E-sciencE) mira ad integrare
le piattaforme Grid già esistenti per creare un’unica infrastruttura di calcolo
per il supporto alla ricerca scientifica e permettere ai ricercatori un accesso
a grandi risorse computazionali, indipendentemente dalla loro ubicazione e
appartenenza. L’infrastruttura supporta le comunità che hanno in comune la
necessità di avere accesso a particolare risorse computazionali e sono pron-
te ad integrare la propria infrastruttura accettando una politica di accesso
comune.
La nascita di EGEE, come abbiamo visto, risale al 1 Aprile 2004, come
prosecuzione del progetto EDG (European DataGrid) che in tre anni di atti-
vità ha portato ad un grande sviluppo di software e middleware, necessario
alla realizzazione di un’infrastruttura Grid.
Il progetto ha una durata biennale, ma fa parte di un programma qua-
driennale e ne costituisce la base per la concessione di nuovi finanziamenti
34
2.2 L’articolazione
che per la maggior parte provengono dalla Comunità Europea ma anche da
altri paesi non comunitari.
2.2 L’articolazione
Tutte le discipline scientifiche che hanno bisogno di risorse computaziona-
li avanzate possono beneficiare dal progetto EGEE. Due applicazioni pilota
sono state scelte per guidare l’implementazione iniziale e certificare le pre-
stazioni e le funzionalità della infrastruttura Grid in evoluzione. La prima
è la già citata LHC, che necessita di un’infrastruttura in grado di archiviare
ed analizzare petabyte di dati provenienti dagli esperimenti della fisica del-
le alte energie al CERN. L’altra è la Biomedical Grid, all’interno della quale
molte comunità stanno affrontando sfide molto ardue, quali il datamining su
database genomici e l’indicizzazione di database medici negli ospedali, che
ammontano a molti terabyte di dati per ospedale all’anno.
In totale sono state coinvolte 71 organizzazioni di 27 paesi differenti, che
sono organizzate in Grid regionali, con una capacità stimata di oltre 20.000
CPU: la più grande struttura Grid internazionale mai sviluppata. L’obiettivo
preposto è quello di avere 3000 utenti attivi nell’infrastruttura provenienti
da almeno 5 settori scientifici diversi entro la fine del secondo anno di atti-
vità; la fase successiva del progetto prevede lo sfruttamento di tale risorsa
anche in ambito Geofisico, Nanotecnologico e dei Modelli climatici, e quindi
un incremento esponenziale di risorse ed utenti.
La ricerca all’interno del progetto EGEE è organizzata in 11 attività diver-
se, ognuna delle quali si occupa di uno dei campi di realizzazione ed utilizzo
della Grid. Queste attività sono a loro volta raggruppate in tre diversi settori
• EGEE Networking Activities (NA)
• EGEE Specific Service Activities (SA)
• EGEE Joint Research Activities (JRA)
35
2.2 L’articolazione
che verranno illustrati di seguito:
EGEE Networking Activities (NA)
Questo settore si occupa di tutti gli aspetti organizzativi necessari al coordi-
namento del progetto e al rapporto con i partner e di promuovere un’adegua-
ta campagna di informazione per focalizzare sul progetto l’attenzione di enti,
industrie, università e governi. All’interno di questa sezione sono presenti
cinque diverse attività:
NA1 - Project Management: ha lo scopo di gestire l’intera struttura orga-
nizzativa, coordinare i lavori, presentare dei rapporti in collaborazione
con l’attività che si occupa della QoS (Quality of Service), sviluppare una
licenza Open Source per il software prodotto all’interno del progetto ed
istruire lo staff del progetto;
NA2 - Dissemination and Outreach: il leader di questa attività è il con-
sorzio TERENA. Lo scopo di questa attività è diffondere le idee del
progetto, attirare nuovi partner dalla comunità scientifica e dall’indu-
stria. Questo gruppo ha inoltre il compito di organizzare due conferenze
all’anno sul progetto;
NA3 - User Traning and Induction: molto importante per la riuscita del
progetto è un programma di formazione aggiornato ed accessibile, tenu-
to da un gruppo di docenti di elevatissima qualità ed esperienza. Più di
22 paesi partecipano a questa attività ed è stato istituito un programma
di formazione all’utilizzo dei portali e dei tool di installazione;
NA4 - Application Identification and Support: questa attività si occupa
di curare l’ingresso di nuovi utenti ed organizzazioni e di fornire assi-
stenza per l’installazione di nuovi nodi Grid. Il ruolo di questo gruppo
è fondamentale al fine di incrementare i settori applicativi in cui viene
sperimentata l’infrastruttura Grid e ne viene dimostrata l’importanza.
36
2.2 L’articolazione
Infatti al crescere del numero delle applicazioni che vengono eseguite
con successo nella Grid, aumenta l’importanza di EGEE e della Grid
stessa;
NA5 - Policy and International Cooperation: l’obiettivo è di permettere
al progetto EGEE di partecipare allo sviluppo di una Grid globale e di
assicurarsi che il progetto collabori con le maggiori iniziative Grid di tut-
to il mondo. NA5 è attualmente collegato con le principali iniziative Grid
europee: DEISA (Distributed European Infrastructure for Supercompu-
ting Applications), SEE-GRID (South Eastern European Grid-enabled
eInfrastructure Development), DILIGENT (Testbed Digital Library In-
frastructure on Grid Enabled Technology) e GRIDcc (Grid Enabled Re-
mote Instrumentation with Distributed Control and Computation). Inol-
tre sono stati stabiliti collegamenti anche con altre iniziative extraeu-
ropee, tra le quali la ”US NFS Cyberinfrastructure initiative” e l’EGEE
Project Management Board (PMB) in collaborazione con Stati Uniti e
Russia.
EGEE Specific Service Activities (SA)
Quest’area si occupa di sviluppare, migliorare e mantenere aggiornato il soft-
ware che costituisce il middleware sul quale si basa la Grid e quindi dello
sviluppo della Grid stessa. Due attività compongono questa area:
SA1 - Grid Support Operation and Management: questa attività ha lo sco-
po di gestire l’operatività dell’infrastruttura Grid e di fornire il supporto
necessario ai gestori delle varie componenti della Grid al fine di garan-
tire un’erogazione dei servizi affidabile e stabile nel tempo. Le funzioni
chiave sono la creazione dei servizi, il monitoraggio e il controllo della
Grid, lo sviluppo del middleware ed il supporto agli utenti;
SA2 - Network Resource Provision: questa attività si occupa di monito-
37
2.2 L’articolazione
rare e controllare la fornitura in rete dei servizi Grid, in particolare di
individuare e correggere tutti quei problemi, soprattutto inerenti alla
rete, che possono compromettere la fruibilità del servizio.
EGEE Joint Research Activities (JRA)
L’ultima area del progetto si occupa delle attività di sviluppo, ricerca e verifica
delle nuove soluzioni per il miglioramento dei servizi offerti agli utenti. JRA
è divisa in quattro diverse attività:
JRA1 - Middleware Re-Engineering and Integration: l’obiettivo è quel-
lo di fornire componenti software di middleware robusti, eseguibili su
diverse piattaforme e sistemi operativi, in modo che il software EGEE
sia soggetto ad un processo evolutivo continuo e possa essere integrato
e diffuso nei nuovi siti che si aggiungono alla Grid;
JRA2 - Quality Assurance: questa attività è volta alla certificazione della
qualità di tutte le componenti di EGEE. Oltre a monitorare il livello di
qualità offerto dai vari servizi di EGEE, è stato previsto un rapporto
sulla qualità del progetto alla fine del biennio di attività;
JRA3 - Security: lo scopo di questa attività è quello di gestire, implemen-
tare e monitorare l’architettura inerente alla sicurezza del progetto.
L’affidabilità di tutto il prgetto EGEE dipende dal livello di sicurezza
implementato e dal fatto che tutti si attengano ai criteri dettati da JRA3;
JRA4 - Network Services Development: una parte dell’attività è stata in-
dirizzata a garantire la connettività della rete, specificata in termini di
banda, durata e QoS; inoltre il team si occupa di monitorare la perfor-
mance della rete e per fare ciò ha sviluppato un’interfaccia implementa-
ta attraverso i web service che permette a tutti i siti e ai domini di rete
di inviare informazioni per poter così bilanciare efficientemente il traf-
38
2.3 Virtual Organization in EGEE
fico di rete. L’altro obiettivo del team è quello di facilitare l’introduzione
del protocolli IPv6.
2.3 Virtual Organization in EGEE
Un elemento fondamentale per il corretto funzionamento della Grid e dei suoi
servizi è la gestione delle risorse e degli utenti. Si devono cioè definire delle
regole per gestire l’accesso alle risorse da parte degli utenti. Un insieme di
individui e/o istituzioni che condivide le stesse regole di accesso costituisce
una Virtual Organization (VO).
All’interno di una infrastruttura Grid vengono definite diverse Virtual Or-
ganization e un utente può appartenere ad una o più di esse ed accedere co-
sì alle risorse condivise; chi fornisce le risorse, a sua volta, specifica quali
Virtual Organization vi possono accedere e con quali criteri.
Un utente, quindi, può accedere alla Grid solo se autorizzato da una VO
e può utilizzare solo le risorse a disposizione di quella VO; la gestione degli
utenti viene effettuata dalle singole VO in modo da gestire la grande quantità
di utenti e risorse di una Grid con dei meccanismi poco costosi e molto rigorosi.
Un ulteriore beneficio derivante dalla classificazione in VO è la semplifi-
cazione della struttura della Grid fornita all’utente; attraverso le Virtual Or-
ganization, infatti, un utente ha una visione semplificata della Grid, limitata
alle sole risorse alle quali ha accesso.
Le VO attive all’interno del progetto EGEE sono attualmente 23:
ATLAS, ALICE, CMS, LHCB, DTEAM, SIXT, BIO, ENEA, INAF, PLANCK,
BIOMED, ESR, INFNGRID, THEOPHYS, CDF, GILDA, INGV, VIRGO, BA-
BAR, COMPCHEM, GRIDIT, MAGIC, ZEUS.
In questa tesi faremo riferimento alla VO COMPCHEM che è supportata
dal nodo di UNI-PERUGIA.
L’ingresso di nuovi nodi Grid nel progetto avviene attraverso una procedu-
ra di affiliazione ad una delle VO esistenti che si pone tra l’organizzazione che
39
2.3 Virtual Organization in EGEE
vuole entrare a far parte di EGEE e la Certification Authority (CA) centrale
dell’INFN la quale si occupa di ricevere le richieste di emissione di certificati
da distribuire agli utenti e agli amministratori dei nodi.
Un altro dei compiti affidati alle VO è quello di fornire supporto tecnico per
l’installazione e la configurazione dei nuovi nodi Grid e per l’aggiornamento
del software dei nodi già esistenti.
All’interno di ogni VO, viene definito almeno un sito di riferimento che
permette di fornire servizi di autenticazione e catalogazione delle risorse a
disposizione degli utenti della Grid per la sottomissione e la gestione di job (il
nodo UNI-PERUGIA è il sito di riferimento per COMPCHEM). Questi servizi
vengono resi disponibili attraverso i nodi Resource Broker e Logging Server.
Il Logging Server viene impiegato per registrare tutte le richieste effet-
tuate dagli utenti. Il Resource Broker invece deve trovare quale tra tutte le
risorse disponibili risulta migliore per lo svolgimento de job. Per esempio, se
un job necessita di un particolare software, il Resource Broker deve scegliere
il miglior sito che soddisfi questa richiesta. Per far ciò, un Resource Broker
contatta un ”Resource Catalog” che centralizza tutte le risorse disponibili.
2.3.1 Virtual Organization Membership Server
Il Virtual Organization Membership Server (VOMS) è un database di utenti
che sono autorizzati ad utilizzare le risorse della VO.
Il server è utilizzato per due scopi principali; il primo è quello di ottenere
informazioni sulle risorse a disposizione della VO, tramite la lista degli utenti;
il secondo è quello di fornire agli utenti le credenziali da utilizzare per ottene-
re l’accesso alle risorse. In questo modo, dopo una prima comunicazione, non
ne sono necessarie altre tra il servizio VOMS e il sito.
Questo tipo di servizio tenta di soddisfare sia i requisiti di sicurezza del
sistema che la semplice e veloce fruibilità delle risorse. Attraverso il VOMS,
infatti, ogni utente crea un proxy di durata prefissata che gli permette di
40
2.4 EGEE Middleware
utilizzare le risorse della VO alla quale è registrato senza dover ”mostrare” le
sue credenziali ad ogni accesso.
2.3.2 MyProxy Server
Il MyProxy Server è un servizio che permette di salvare delle credenziali per
un proxy a lungo termine. Un utente salva le sue credenziali sul server e
da quel momento in poi può creare il proxy per l’utilizzo delle risorse, come
previsto dalla normale routine.
Il vantaggio del MyProxy Server è che può essere utilizzato per rinnova-
re un normale proxy in modo da rendere possibile l’esecuzione di job molto
lunghi che altrimenti verrebbero abortiti alla scadenza della vita del proxy.
2.4 EGEE Middleware
L’architettura di un sistema definisce gli scopi, le modalità di funzionamento
e le interazioni fra i suoi componenti fondamentali. Serve un architettura
”aperta”, in continua evoluzione, che fissi regole ben precise da soddisfare i
bisogni di estensibilità ed interoperabilità richieste da Grid. A tal proposito
il middleware rappresenta un componente cruciale. Con il termine inglese
”middleware” si intende un insieme di programmi e procedure che fungono
da intermediari tra diverse applicazioni. Sono spesso utilizzati come supporto
per applicazioni distribuite complesse.
L’utilizzo di uno strato software aggiuntivo, il middleware appunto, con-
sente di ottenere un elevato livello di servizio per gli utenti, e di astrazione per
i programmatori. Inoltre, consente di facilitare la manutenzione, la stesura e
l’integrazione di applicazioni.
Grid deve possedere, innanzi tutto, un insieme di protocolli comuni, che
pur garantendo indipendenti metodi di controllo e gestione locale delle risor-
se, abilitino le interazioni tra i diversi componenti del sistema e definiscano
i meccanismi di base attraverso cui le risorse condivise possano essere viste
41
2.4 EGEE Middleware
e utilizzate dagli utenti. I middleware Application Program Interface (API)
e Software development kit (SDK) aiutano la rapida costruzione di applica-
zioni che utilizzino al meglio le potenzialità offerte da Grid. API definisce
dei metodi standard per invocare uno specifico insieme di funzionalità. Que-
sto insieme può essere dato da una chiamata ad una subroutine o da metodi
di oggetti (object-oriented API). SDK sono degli insiemi di codice che vengo-
no utilizzati dagli sviluppatori per implementare specifiche funzionalità nei
programmi che realizzano.
2.4.1 gLite: La Futura Generazione di Middleware EGEE
L’idea
Per qualsiasi impegno sul Grid Computing, il middleware rappresenta sem-
pre un componente cruciale. Per EGEE, era stato deciso che un approccio
a due fasi poteva essere la soluzione migliore. Originariamente, il progetto
EGEE usava il middleware basato sul lavoro del suo predecessore, il proget-
to European DataGrid (EDG), modificato in seguito nel middleware LCG, ed
usato nella prima infrastruttura di EGEE. Parallelamente, EGEE sviluppava
e re-ingegnerizzava gran parte della struttura di questo middleware per una
sua nuova soluzione, chiamata gLite [18], che è attualmente utilizzata nel ser-
vizio di pre-produzione. La struttura gLite combina il cuore del middleware a
basso livello con una serie di servizi ad alto livello.
Distribuito su licenza commerciale open source, gLite integra sia compo-
nenti provenienti dai migliori progetti di middleware al momento disponibili,
quali Condor e Globus Toolkit, sia componenti sviluppati per il progetto LCG.
Il risultato è un ottimo middleware di basso livello, compatibile con gestori di
job come PBS, Condor e LSF, e costruito tenendo presente l’interoperabilità
e l’obiettivo di fornire servizi fondamentali che facilitino la realizzazione di
applicazioni Grid provenienti da tutti i campi.
42
2.4 EGEE Middleware
Lo sviluppo
Molti centri di ricerca sia universitari che industriali collaborano nello svi-
luppo del software, organizzati in diverse aree di ricerca: Security, Accesso al-
le Risorse (Computing e Storage Elements), Accounting, Data Management,
Workload Management, Logging and Bookkeeping, Information and Moni-
toring, Network Monitoring e Provisioning. Sviluppo e distribuzione sono
inoltre supportati dal programma intensivo di formazione (t-Infrastructure)
realizzato da EGEE. Questo programma fornisce supporto sia con documen-
tazione in linea che con seminari e tutorials on line. La formazione è inoltre
disponibile sul testbed per l’attività di divulgazione, GILDA, caratterizzata
dalla propria Autorità di Certificazione (CA), e dalla possibilità di permette-
re agli utenti e agli amministratori di sistema di testare tutti gli aspetti di
sviluppo ed utilizzo del middleware gLite.
Il prodotto
I servizi Grid di gLite seguono l’Architettura Orientata ai Servizi, ciò significa
che con essi diventa molto semplice collegare il software ad un’altro servizio
Grid, ed inoltre ciò facilita la compatibilita’ con i gli standard Grid di nuo-
va generazione, per esempio la Web Service Resource Framwork (WSRF) di
OASIS e la Open Grid Service Architecture (OGSA) del Global Grid Forum.
La struttura di gLite è concepita come un sistema modulare, abilitando gli
utenti a sviluppare servizi differenti idonei alle loro esigenze, piuttosto che
costringerli ad usare l’intero sistema. Questo è concepito per permettere ad
ogni utente di adattare il sistema ad ogni specifica esigenza.
Basandosi sull’esperienza dello sviluppo del middlware EDG e LCG, gLi-
te aggiunge nuove funzionalità in tutti i livelli della struttura software. In
particolare assicura una maggiore sicurezza, maggiore interfacciabilità per
la gestione dei dati e la sottomissione dei job, una struttura del sistema rivi-
sitata, e molte altre funzionalità che rendono facile ed efficente l’uso di gLite.
43
2.4 EGEE Middleware
Già distribuito su varie Griglie di test e di pre-produzione dell’intero progetto,
i risultati di gLite sui servizi di pre-produzione sono in aumento.
44
Capitolo 3
Il portale web
The sharing that we are concerned with is not primarily fileexchange but rather direct access to computers, software, data, and
other resources, as is required by a range of collaborative problemsolvingand resource-brokering strategies emerging in industry,
science, and engineering. This sharing is, necessarily, highlycontrolled, with resource providers and consumers defining clearlyand carefully just what is shared, who is allowed to share, and the
conditions under which sharing occurs. A set of individuals and/orinstitutions defined by such sharing rules form what we call a
virtual organization.- Carl Kesselman, Ian Foster and Steve Tuecke -
3.1 Introduzione
Come già detto le griglie computazionali nascono per venire incontro alle esi-
genze delle organizzazioni virtuali che per le loro attività di ricerca e sviluppo
di conoscenza, necessitano di condividere risorse e dati attraverso regole ben
determinate. Tale condivisione è dinamica in quanto le organizzazioni virtua-
li non sono insiemi statici definiti a priori, ma possono modificare nel corso del
tempo le proprie necessità, avere bisogno di nuovi o particolari servizi, abili-
tare l’uso di questi servizi a nuovi utenti o escluderne degli altri. Una VO è
caratterizzata dal corpo di laboratori che ne fanno parte (membri) e dalle sue
politiche di accesso e utilizzo dei servizi e delle risorse condivise.
La base di questo meccanismo è la forte collaborazione che si instaura tra
i laboratori membri di una data VO. I vari laboratori mettono a disposizione
45
3.2 La sostenibilità di una Organizzazione Virtuale
della griglia computazionale un insieme di risorse locali che vanno a far parte
di un pool di risorse computazionali distribuite e condivise tra tutti gli utenti.
La VO è gestita da un comitato (Management Committee o MC) in cui i vari
livelli di appartenenza alla VO sono rappresentati. Inoltre ogni laboratorio
agisce sia da client che da server (così come avviene nella tecnologia peer
to peer). All’interno di queste comunità vengono sviluppati e sperimentati
programmi e software che in seguito vengono condivisi attraverso la griglia
garantendone crescita e lo sviluppo. Da ciò si evince che la sostenibilità è la
chiave per la crescita di una VO.
3.2 La sostenibilità di una Organizzazione Virtuale
Il fattore fondamentale per l’affermarsi di una organizzazione virtuale è la
sua sostenibilità [20]. Per questo scopo ogni organizzazione virtuale deve of-
frire ai suoi membri con meccanismi cristallini e oggettivi vantaggi tangibili
come ad esempio la possibilità di svolgere estese campagne di calcolo (spe-
cialmente quando sono così complesse da non essere realizzabili utilizzando
piattaforme di calcolo locali, seriali o parallele che siano) che li ricompensi per
il lavoro fatto per la comunità. Solo in questo modo i laboratori si assumeran-
no l’onere di portare avanti il lavoro supplementare ancora oggi richiesto dal
fatto di operare in Grid su base collaborativa. Ad ogni membro che non sia il
semplice utente esterno viene infatti richiesto di implementare sull’ambiente
distribuito della VO almeno un codice sia pure per mero uso personale. Più
spesso viene anche richiesta la condivisione di risorse con gli altri laboratori.
I laboratori in questo modo vengono proiettati verso il concetto di cooperazio-
ne tramite la partecipazione attiva all’infrastruttura Grid. In cambio ciascun
utente ha la possibilità di avvalersi del ”know-how” degli altri utenti della VO.
L’appartenenza ad una VO può pertanto avvenire a livelli di partecipazione
diversa. In COMPCHEM il livello di ingresso è quello di utente che compor-
ta l’utilizzo sulla griglia di produzione della VO di un programma. L’adesione
46
3.2 La sostenibilità di una Organizzazione Virtuale
può essere di tipo passivo se il programma utilizzato è uno di quelli imple-
mentati dalla VO (o da uno dei suoi membri) o di tipo attivo se il programma
utilizzato è stato implementato dall’utente. Tale livello ha una durata li-
mitata in forma gratuita (che può essere diversa per il tipo passivo e attivo)
negoziata con l’MC. Una volta concluso il periodo di durata limitata, esso può
essere esteso successivamente in forma onerosa. COMPCHEM incoraggia pe-
rò l’utente a passare a livello successivo di laboratorio membro conferendo
o dei programmi (Software Provider o SP) o dei computer (Grid Deployer
o GP) alla VO e alla infrastruttura Grid da essa utilizzata. Ambedue queste
modalità possono essere sia attive che passive.
Per un laboratorio membro di una VO il requisito necessario è quello di
rendere disponibile per l’uso da parte di altri uno dei propri programmi imple-
mentati sulla Grid per un uso condiviso tra tutti gli altri membri. Ciò implica
la validazione di una versione stabile del codice e l’assemblaggio di tutte le
interfacce necessarie al suo utilizzo. Inoltre devono essere resi noti i servizi
di manutenzione del software e l’assistenza agli utenti. Tale modalità viene
detta passiva. Viene detta attiva, invece, la modalità in cui il membro rende
il proprio software integrabile con altri programmi contribuendo al suo uso
coordinato nell’ambito di un workflow più complesso o di un sistema esper-
to. Per quanto riguarda il laboratorio membro di una VO come GD di tipo
passivo, il requisito necessario è quello di inserire nella infrastruttura Grid
della VO un cluster di computer o processori occupandosi della sua gestione.
L’equivalente di tipo attivo è invece coinvolto nella vera e propria gestione (ed
eventuale sviluppo) della infrastruttura Grid. Ad ogni buon conto il contri-
buto di maggior valore per la sostenibilità di una VO è rappresentato dalla
capacità dei suoi membri di innovare, fare ricerca e sviluppo. Esiste poi un
livello superiore di coinvolgimento detto azionista o stake-holder che riguarda
la gestione di sistemi software e hardware. A questo livello appartengono quei
laboratori che dedicano a tale attività una quantità di tempo e di competenze
47
3.3 Il sistema di crediti
importanti.
3.3 Il sistema di crediti
Per quanto appena detto, la VO necessita di un meccanismo di gratificazione
dei propri membri attivi per il lavoro svolto. A tale scopo è stato sviluppato
un sistema di assegnazione di crediti che premia le attività portate avan-
ti a favore della VO (anche se di pura ricerca). I crediti possono essere ri-
scattati acquistando servizi dalla stessa VO oppure scambiandoli con risorse
finanziarie.
Per questo è importante che una VO reperisca risorse finanziarie parte-
cipando a progetti e prestando servizi a terzi dietro compenso. Tali risorse
finanziarie vengono abitualmente indicate con la sigla SFR (Spinoff Finan-
cial Resources). Le risorse così reperite, una volta detratte le spese vive di
gestione della VO, verranno destinate per una certa frazione alla ricerca e
distribuite secondo una graduatoria di merito scientifico stabilita secondo un
criterio di peer rewiew esterno che misuri la produttività scientifica sulla base
dei ”report” interni e articoli pubblicati su riviste scientifiche internazionali.
In ogni caso vengono anche valutati i contributi scientifici contenuti nei report
sui servizi. I relativi report devono infatti sempre contenere una descrizione
dettagliata dello svolgimento dell’attività di ricerca. Questo è dato dal fatto
che COMPCHEM considera attività ricerca e sviluppo come una risorsa in sé
indipendentemente dai risultati ottenuti nel breve periodo e per questa ra-
gione la VO è considerata anche come un’area di libera circolazione di idee e
produzione di innovazione da supportare finanziariamente. La parte restante
verrà suddivisa per una percentuale decisa dall’MC ai membri azionisti e la
parte restante messa a disposizione per essere scambiata con i crediti.
I crediti vengono maturati come ricompensa per i servizi realizzati da
membri della VO. Tali servizi sono classificati come interni, esterni e spe-
ciali. Il servizio interno principale che deve essere garantito dai laboratori
48
3.3 Il sistema di crediti
membri riguarda il funzionamento efficiente di tutte le risorse hardware e
software della comunità virtuale. Impegni presi dai laboratori della VO per
l’espletamento di progetti o servizi commerciali sono altresì considerati servi-
zi interni, così come quelli orientati alla gestione delle infrastrutture e delle
attività della comunità virtuale, alla creazione di nuove attività e allo svolgi-
mento di quelle esistenti. I servizi esterni sono quelli forniti da un laboratorio
membro della VO direttamente a terzi. Infine i servizi speciali sono quelli re-
lativi alla vendita dei prodotti sviluppati all’interno della comunità virtuale a
terzi.
Al fine di dare una base quantitativa e un criterio imparziale per la di-
stribuzione degli SFR è stato sviluppato l’algoritmo secondo l’equazione 3.1
che viene descritto in dettaglio nel riferimento [19]. L’assegnamento dei cre-
diti è semplice e diretto per il conferimento di risorse hardware e software e
quindi valutare gli utilizzi, le performance ed i parametri statistici diventa
automatico in un ambiente Grid. Dunque l’assegnamento dei crediti ai la-
boratori dipende direttamente dall’identificazione e quantificazione dei costi
riscontrati, l’utilità dei servizi forniti e i profitti generati da progetti e/o atti-
vità all’interno della VO. Questi criteri sono incorporati nell’indice Ξl (fattore
di scambio [20]):
Ξl = α′T α
′′T
∑s
ωs(TslNα
Tsl + ζ) + α
′Iα
′′I
∑i
ωiIil + α′Cα
′′C
∑k
ωkCkl (3.1)
dove l, s, i e k sono gli indici che identificano rispettivamente il laboratorio,
il servizio, il profitto e il costo mentre Tsl, Iil e Ckl sono il tempo di calcolo
associato al servizio fornito dal laboratorio l, il profitto generato dall’attività
commerciale o dal progetto i relativo al laboratorio l ed il costo k incontrato (o
il valore delle risorse conferite) dal laboratorio l, rispettivamente. Nel primo
termine dell’equazione N indica il numero di accessi al servizio, ζ un fattore
di scalaggio e Tsl il tempo totale di utilizzo del servizio da parte di tutti i labo-
49
3.4 L’ambiente web
ratori partner della VO. In questo modo si vuole assegnare maggiore impor-
tanza ai servizi che lavorano in un tempo di calcolo medio-basso assegnando
loro più credito rispetto a quelli che lavorano in un tempo di calcolo elevato.
I termini α′ rappresentano i pesi che vengono dati ai termini delle sommato-
rie cui appartengono (servizi, profitti o costi) ed identificano l’importanza che
l’MC della VO assegna a ciascuna sezione. I termini α′′ rappresentano i coef-
ficienti di conversione che prendono in considerazione le differenti unità di
misura utilizzate. Naturalmente per fare in modo che il peso sia consistente
la somma dei tre coefficienti α′ deve essere uguale ad 1 e la scelta dei valori
da assegnare ad alcuni pesi dipende pesantemente dalle strategie scelte dal
Management Committee della VO. Vale la pena a questo punto notare che
per il lavoro di tesi si è semplificato il problema considerando i vari tipi di ser-
vizio tutti alla stessa stregua riservandoci di implementare successivamente
la differenziazione discussa in precedenza. Anche gli ω sono dei pesi fissati
dall’MC per determinare il valore di un certo servizio che potrebbe, ad esem-
pio, variare di anno in anno. Come dettagliato nel riferimento [19] l’algoritmo
corrispondente all’equazione 3.1 è stato dapprima implementato utilizzando
il linguaggio C++.
3.4 L’ambiente web
Per la gestione del sistema di crediti per la griglia è stata sviluppata una
interfaccia web. Questa scelta presenta dei vantaggi per tutti coloro che par-
tecipano alla Grid. Prima di tutto un’applicazione web è indipendente dal
sistema operativo utilizzato dall’utente. L’utente, inoltre, è in grado di visua-
lizzare gli aggiornamenti che avvengono sulla griglia in qualunque momen-
to. Un altro vantaggio è rappresentato dalla semplicità di realizzazione di
un’interfaccia grafica. Per queste ragioni abbiamo creato un ”cross-bar site”
sfruttando una tecnologia serverside. Il relativo ambiente web (Figura 3.1) è
stato implementato usando i seguenti elementi:
50
3.4 L’ambiente web
1. Un web server dinamico, basato sul server web Apache [21] con i moduli
PHP5 [22].
2. Un DBMS (MySQL [23] nel nostro caso) per la memorizzazione dei dati
e il supporto alla fase di autenticazione.
Il portale è stato sviluppato e testato usando software GPL e free. In
particolare è stato utilizzato Apache 2.2.3 e MySQL 5.0.27 contenuti nel tool
EasyPHP 2.0b1.
Figura 3.1: L’ambiente web
PHP
PHP è un linguaggio di scripting interpretato, con licenza open source, ori-
ginariamente concepito per la realizzazione di pagine web dinamiche. At-
tualmente è utilizzato per sviluppare applicazioni web lato server, ma può
essere sfruttato anche per scrivere applicazioni stand alone (oggetto capace
di funzionare da solo, indipendentemente dalla presenza di altri oggetti con
cui potrebbe comunque interagire) con interfaccia grafica.
L’obiettivo fin dall’inizio era quello di sviluppare un’interfaccia con le ca-
ratteristiche di un portale web in cui fosse possibile compiere operazioni in
maniera semplice, ma soprattutto dinamica: è per questo che la scelta è
caduta su questo linguaggio.
51
3.4 L’ambiente web
Il suo nome è un acronimo che sta per Hypertext Preprocessor (prepro-
cessore di ipertesti) ed è nato nel 1994 ad opera del danese Rasmus Lerdorf.
PHP era in origine una raccolta di script CGI (Common Gateway Interface),
tecnologia standard usata dai web server per interfacciarsi con applicazioni
esterne. Il pacchetto originario venne in seguito esteso e riscritto dallo stesso
Lerdorf in linguaggio C, aggiungendo funzionalità quali il supporto al databa-
se mSQL e divenne PHP/FI, dove FI sta per Form Interpreter (interprete di
form), prevedendo la possibilità di integrare il codice PHP nel codice HTML
in modo da semplificare la realizzazione di pagine dinamiche. A questo pun-
to il linguaggio cominciò a godere di una certa popolarità tra i progetti open
source del web e venne così notato da due giovani programmatori: Zeev Su-
raski e Andi Gutmans. I due collaborarono nel 1998 con Lerdorf allo sviluppo
della terza versione di PHP (il cui acronimo assunse il significato attuale),
riscrivendone il motore che fu battezzato Zend da una contrazione dei loro
nomi. Le caratteristiche chiave della versione PHP 3.0 erano la straordinaria
estensibilità, la connettività ai database e il supporto iniziale per il paradig-
ma a oggetti. Verso la fine del 1998 PHP 3.0 era installato su circa il 10%
dei web server presenti su Internet. PHP diventò a questo punto talmente
maturo da competere con ASP, linguaggio lato server analogo a PHP svilup-
pato da Microsoft, cominciando ad essere usato su larga scala. La versione 4
di PHP venne rilasciata nel 2000 e prevedeva notevoli migliorie. Attualmen-
te siamo alla quinta versione, sviluppata da un team di programmatori, che
comprende ancora Lerdorf, oltre a Suraski e Gutmans.
La popolarità del linguaggio PHP è in costante crescita grazie alla sua
semplicità: nel Giugno 2001, ha superato il milione di siti che lo utilizzano.
Nell’ottobre 2002, più del 45% dei server Apache usavano PHP. Nel gennaio
2005 è stato insignito del titolo di ”Programming Language of 2004” dal TIO-
BE Programming Community Index, classifica che valuta la popolarità dei
linguaggi di programmazione sulla base di informazioni raccolte dai motori
52
3.4 L’ambiente web
di ricerca. Nel 2005 la configurazione LAMP (Linux, Apache, MySQL, PHP)
superava il 50% del totale dei server sulla rete mondiale.
PHP riprende per molti versi la sintassi del C, come peraltro fanno molti
linguaggi moderni, ed è per questo motivo che non è stato complicato tradurre
l’algoritmo da una codifica in C++ ad una in PHP. PHP è in grado di inter-
facciarsi ad innumerevoli database tra i quali MySQL, PostgresSQL, Oracle,
Firebird, IBM DB2 e Microsoft SQL Server e supporta numerose tecnologie,
come XML, SOAP, IMAP, FTP, CORBA. Esso si integra anche con altri lin-
guaggi/piattaforme (quali Java e .NET) e fornisce un’API specifica per intera-
gire con Apache, nonostante funzioni naturalmente con numerosi web server.
PHP è ottimamente integrato con il database MySQL per il quale possiede più
di una API. Per questo motivo esiste un’enorme quantità di script e librerie
in PHP disponibili liberamente su Internet.
MySQL
Come precedentemente accennato, per la memorizzazione dei dati è stato uti-
lizzato un database da cui l’algoritmo potesse attingere direttamente. Per
manipolare la collezione di dati ci siamo serviti di un DBMS (Database Mana-
gement System), un sistema software progettato per consentire la creazione e
manipolazione efficiente di database da parte di più utenti. I DBMS svolgono
un ruolo fondamentale in numerose applicazioni informatiche, dalla contabi-
lità alla gestione delle risorse umane e la finanza, fino a contesti tecnici come
la gestione di reti o la telefonia. Se in passato i DBMS erano diffusi princi-
palmente presso le grandi aziende e istituzioni, oggi il loro utilizzo è diffuso
praticamente in ogni contesto. Un esempio di DBMS è MySQL.
MySQL è un DBMS relazionale composto da un client con interfaccia a
caratteri e un server, entrambi disponibili sia per sistemi Unix che per Win-
dows, anche se prevale un suo utilizzo in ambito Unix. Dal 1996 supporta la
maggior parte della sintassi SQL e si prevede in futuro il pieno rispetto del-
53
3.5 Il database Crediti
lo standard ANSI. Possiede delle interfacce per diversi linguaggi, compreso
un driver ODBC, due driver Java e un driver per Mono e .NET. Il codice di
MySQL viene sviluppato fin dal 1979 dalla ditta TcX ataconsult (adesso My-
SQL AB) ma è solo dal 1996 che viene distribuita una versione che supporta
SQL, utilizzando in parte codice di un altro prodotto: mSQL. Il codice di My-
SQL è di proprietà della omonima società ma viene distribuito con la licenza
GNU GPL oltre che con una licenza commerciale. Buona parte del codice del
client è licenziato con la GNU LGPL e può dunque essere utilizzato per ap-
plicazioni commerciali. MySQL svolge il compito di DBMS nella piattaforma
LAMP, una delle più usate e installate su Internet per lo sviluppo di siti e
applicazioni web dinamiche.
Esistono diversi tipi di MySQL Manager, ovvero di strumenti per l’am-
ministrazione di MySQL. Quello utilizzato nell’implementazione del portale,
uno dei programmi più popolari per amministrare i database MySQL, è php-
MyAdmin. Questo tool richiede un web server come Apache_HTTP_Server ed
il supporto del linguaggio PHP. Si può utilizzare facilmente tramite un qual-
siasi browser. La versione di phpMyAdmin utilizzata è la 2.9.1.1 mentre la
versione di Apache è la 2.2.3 e quella di PHP è la 5.2.0.
3.5 Il database Crediti
Vista la grande mole di informazioni da memorizzare è stato implementato un
database SQL. Il database che abbiamo realizzato è costituito da 10 tabelle
come mostrato in (Figura 3.2):
• amministratore: contiene le informazioni relative ad ogni amministra-
tore di una organizzazione virtuale;
• superuser: contiene le informazioni relative ad ogni amministratore di
un laboratorio appartenente ad una organizzazione virtuale;
54
3.5 Il database Crediti
• vo: tabella utilizzata per memorizzare i nomi delle organizzazioni vir-
tuali;
• laboratorio: tabella utilizzata per memorizzare i nomi dei laboratori
appartenenti ad una organizzazione virtuale;
• credito: contiene le informazioni relative al credito assegnato ad un
laboratorio;
• costo: contiene le informazioni relative ai costi incontrati da un labora-
torio;
• prog_att: contiene le informazioni relative ai profitti generati da un
laboratorio;
• servizio: contiene le informazioni relative ai servizi offerti da un labo-
ratorio;
• data: tabella utilizzata per tenere traccia degli accessi degli utenti al
portale;
• voto: tabella utilizzata per memorizzare i voti assegnati ai servizi da
parte degli utenti di una organizzazione virtuale.
Il file che contiene il database è stato rinominato come crediti.sql e per le
fasi di testing è stato caricato nel server localhost utilizzando phpMyAdmin
versione 2.9.1.1. Nello schema mostrato in (Figura 3.2) si evince che ciascuna
organizzazione virtuale può essere amministrata da un solo amministratore e
ciascun laboratorio appartiene ad una sola VO mentre una VO può possedere
da uno ad N laboratori. Un laboratorio può possedere da uno ad N utenti
mentre un utente appartiene ad un solo laboratorio.
55
3.6 L’architettura del portale
Figura 3.2: Schema E/R
3.6 L’architettura del portale
Il portale è costituito da un set di pagine generate dinamicamente in base
all’input (Figura 3.3). Queste pagine permettono di gestire, visualizzare e
modificare i dati memorizzati nel database attraverso la GUI (Graphical User
Interface). L’accesso al portale è consentito solamente a due classi di utenti:
• amministratori: coloro che si occupano della gestione delle organizza-
zioni virtuali;
• utenti: coloro che si occupano della gestione dei laboratori appartenenti
ad una organizzazione virtuale (amministratori dei laboratori).
Inizialmente il portale era stato concepito per la sola amministrazione del-
le VO e perciò era prevista esclusivamente la classe amministrativa. In segui-
to l’utilizzo del portale è stato esteso anche agli amministratori dei laboratori.
In questo modo ci siamo avvicinati fortemente alla filosofia della griglia che
si basa sulla cooperazione delle organizzazioni virtuali ed in particolare sulla
collaborazione tra i laboratori delle VO.
56
3.6 L’architettura del portale
Figura 3.3: Mappa del portale
La prima pagina è index.php dalla quale è possibile accedere alle varie
sezioni del portale. L’accesso alle altre pagine avviene solo dopo la fase di au-
tenticazione, nella quale viene richiesto l’inserimento di username e password
nei rispettivi campi del form Member login.
3.6.1 Amministratore
Pagina principale
Se l’utente appena autenticato appartiene alla classe amministrativa avrà
accesso alla propria area personale (Figura 3.4). In questa sezione sarà in
grado di visualizzare le novità riguardanti l’attività della sua organizzazione
virtuale (nella sezione news) che vengono visualizzate attraverso una Mes-
57
3.6 L’architettura del portale
sage Box. Questa casella di posta in arrivo contiene i messaggi spediti dai
laboratori della VO che attendono di essere validati dall’amministratore. La
validazione consiste nel sottoporre, ad esempio un servizio, ad un periodo di
valutazione da parte dei membri della VO durante il quale vengono comunque
accumulati dei crediti derivanti dal suo utilizzo (crediti di tipo provvisorio).
Sarà cura dell’amministratore decidere se validare o meno il servizio (e quin-
di i crediti provvisori) e inviare la comunicazione al relativo laboratorio. I
messaggi in arrivo si dividono in tre categorie:
• servizi: specifica il numero dei nuovi servizi (servizi provvisori) inseriti
sulla griglia dai laboratori;
• costi: specifica il numero di costi sostenuti di recente dai laboratori della
VO;
• profitti: specifica il numero di profitti derivanti da progetti o attività che
i laboratori della VO hanno generato.
Ognuna di queste categorie contiene messaggi che attendono di essere vali-
dati. In pratica l’amministratore ha il compito di visualizzare il contenuto di
tali messaggi e decidere se validarli o meno. Naturalmente la validazione è
una fase fondamentale per lo sviluppo di una VO. Come già detto, ogni vol-
ta che una VO offre un nuovo servizio, incontra un costo oppure genera un
profitto è necessario valutare se questi andranno ad aumentare l’efficienza
della griglia. Un nuovo servizio per esempio, prima di essere validato, dovrà
affrontare un periodo di prova in cui gli utenti della griglia potranno testarlo
e votarne l’utilità. In base ai parametri del servizio (compreso il gradimen-
to degli utenti che lo hanno utilizzato) l’amministratore deciderà se validarlo
oppure no. Per un costo relativo all’acquisto di una risorsa l’amministratore
dovrà prevedere quanto questo influirà sullo sviluppo e la crescita della gri-
glia analogamente a quanto accade per un progetto in cui bisogna prevedere i
tempi di realizzazione e quindi il profitto generato. Le decisioni di validazio-
58
3.6 L’architettura del portale
ne saranno automaticamente comunicate ai rispettivi laboratori della VO. Da
questa sezione è inoltre possibile accedere alle altre aree attraverso il menù
posto nel lato sinistro della pagina.
Figura 3.4: Amministrazione - area personale
Laboratori
In questa sezione l’amministratore può accedere ad informazioni relative ai
laboratori membri della sua organizzazione virtuale. Selezionando un labo-
ratorio è possibile visualizzare i servizi che esso offre, i costi che incontra
e i profitti che genera. Da questa sezione è inoltre possibile eliminare un
laboratorio esistente oppure aggiungerne uno nuovo.
Utenti
In questa sezione vengono mostrate le informazioni relative agli amministra-
tori di ciascun laboratorio della VO. Attraverso il form Mostra utente è possi-
59
3.6 L’architettura del portale
bile visualizzare gli utenti ordinandoli per cognome o laboratorio di apparte-
nenza mentre il form Cerca utente per nome offre la possibilità di cercare uno
specifico utente attraverso il suo nome e cognome.
Crediti
La sezione crediti è sicuramente la più importante (Figura 3.5). Selezionan-
do un laboratorio l’amministratore è in grado di calcolare i crediti validati
e provvisori. Nella form Calcola crediti convalidati viene calcolato il credito
totale validato mentre nella form Calcola crediti provvisori viene calcolato il
credito totale che include quello non validato. I valori verranno stampati a vi-
deo attraverso una finestra di dialogo. Ogni volta che l’amministratore calcola
il credito di un laboratorio aggiorna automaticamente il valore di quello vec-
chio: in questo modo l’amministratore del laboratorio sarà in grado di vedere
il credito effettivo solo quando verrà validato dall’amministratore della VO.
Inoltre da questa sezione è possibile calcolare il crediti maturati dai singoli
servizi provvisori.
Statistiche
Da questa speciale sezione è possibile visualizzare le statistiche relative ai
servizi, profitti e costi di un laboratorio. Selezionando un laboratorio si accede
in un’area in cui vengono mostrati i grafici relativi a ciascun servizio, profitto
e costo.
3.6.2 Utente
Pagina principale
Se l’utente appena autenticato è un normale membro avrà accesso esclusi-
vamente alla propria area personale (Figura 3.6). Se invece si tratta di un
amministratore di laboratorio potrà visualizzare le news riguardanti l’attivi-
tà dello stesso. Anche in questo caso le news vengono visualizzate attraverso
60
3.6 L’architettura del portale
una Message Box. A differenza della parte amministrativa però qui si trova-
no le informazioni relative al numero di messaggi relativi ai servizi validati o
meno dall’amministratore della VO per:
• servizi
• costi
• profitti
Nella stessa sezione si trovano anche le informazioni sul numero dei nuovi
servizi che sono stati inseriti sulla griglia dai laboratori partner (Figura 3.7).
Servizi, costi e profitti possono essere mantenuti nella Message Box oppure
possono essere eliminati. Per quanto riguarda i nuovi servizi inseriti dagli
altri laboratori invece viene data la possibilità di testarne il funzionamento.
In base alla qualità e al gradimento del servizio si può assegnare un voto da
1 a 5: maggiore è il voto e più alto è il gradimento. I messaggi relativi ai
nuovi servizi inseriti sulla griglia saranno visibili finché il servizio non sa-
rà validato o meno dall’amministratore della VO. Nella pagina principale è
anche possibile visualizzare i crediti validati e provvisori totali maturati dal
laboratorio. Per ciascuno di essi viene indicata anche la data in cui il credi-
to è stato calcolato dall’amministratore della VO. Sempre in questa sezione,
inoltre, viene data la possibilità di calcolare i crediti accumulati dai singoli
servizi provvisori erogati dal laboratorio stesso.
Gestione
In questa sezione l’utente è in grado di inserire nelle apposite form le informa-
zioni relative ai servizi, costi e profitti erogati dal proprio laboratorio. Per ogni
occorrenza inserita si deve specificare anche una breve descrizione con le ca-
ratteristiche salienti della risorsa. Tutte queste informazioni verranno visua-
lizzate in apposite tabelle accessibili sia dai membri sia dall’amministratore
della VO.
61
3.6 L’architettura del portale
Figura 3.5: Amministrazione - calcolo dei crediti
62
3.6 L’architettura del portale
Figura 3.6: Utente - schermata dell’area personale
63
3.6 L’architettura del portale
Figura 3.7: Utente - schermata dell’attività della griglia
64
Conclusioni
Il lavoro svolto in questa tesi ha portato allo sviluppo di un ambiente web
per il calcolo di crediti virtuali maturati dai laboratori membri dell’orga-
nizzazione virtuale COMPCHEM appartenente alla griglia di produzione di
EGEE. Questo lavoro che avvia per la prima volta la costruzione di un porta-
le per la valutazione dei crediti maturati da un membro di una VO, si basa
essenzialmente sullo sviluppo di una interfaccia GUI, ed offre, sia pure in un
contesto in forte evoluzione e carente di ricerche e statistiche dettagliate, un
approccio oggettivo alla economia di una VO in ambiente Grid. Questo ha
comportato che gran parte della tesi è dedicata all’analisi dettagliata di una
struttura Grid e in particolare di quella di produzione del progetto EGEE. Sta
diventando infatti sempre più evidente che la tecnologia Grid rappresenterà
il detonatore di una profonda rivoluzione organizzativa e una forte spinta per
la reale convergenza di tutte quelle metodologie scientifiche in tutti i campi
della ricerca.
Lo sforzo maggiore si è appuntato sulla realizzazione di una interfaccia
grafica in grado di interagire direttamente con un database. La peculiarità
di questo sforzo sta nel fatto che l’input dei dati è stato curato in modo da
studiare il comportamento di casi in cui la distribuzione dei costi, dei profitti
e dei servizi resi hanno una forma modello anche se il portale è stato strut-
turato in modo tale da prevedere il popolamento della base di dati con valori
derivanti da misurazioni reali del comportamento dei laboratori della Grid.
65
Appendice A
Sorgenti
A.1 Database
−− Database c r e d i t i −−
−− cancel la l e t a b e l l e −−
DROP TABLE immagine CASCADE;DROP TABLE voto CASCADE;DROP TABLE creditobeta CASCADE;DROP TABLE cred i to CASCADE;DROP TABLE data CASCADE;DROP TABLE se rv i z i o CASCADE;DROP TABLE costo CASCADE;DROP TABLE prog_att CASCADE;DROP TABLE superuser CASCADE;DROP TABLE laborator io CASCADE;DROP TABLE amministratore CASCADE;DROP TABLE vo CASCADE;
−− crea l e t a b e l l e −−
CREATE TABLE vo(
nome varchar (20) PRIMARY KEY)TYPE = InnoDB ;
CREATE TABLE amministratore(
nome varchar (20) NOT NULL,cognome varchar (20) NOT NULL,user varchar (10) NOT NULL,password numeric (10) NOT NULL,
66
A.1 Database
mail varchar (30) NOT NULL,nome_vo varchar (20) NOT NULL,PRIMARY KEY ( user , nome_vo ) ,FOREIGN KEY ( nome_vo ) REFERENCES vo (nome)ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
CREATE TABLE laborator io(
nome varchar (50) NOT NULL,nomevo varchar (20) NOT NULL,PRIMARY KEY (nome, nomevo ) ,FOREIGN KEY ( nomevo ) REFERENCES vo (nome)ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
CREATE TABLE superuser(
nome varchar (20) NOT NULL,cognome varchar (20) NOT NULL,users varchar (10) NOT NULL,pass numeric (10) NOT NULL,mail varchar (30) NOT NULL,nome_l varchar (50) UNIQUE NOT NULL,vo varchar (20) NOT NULL,PRIMARY KEY ( users , nome_l , vo ) ,FOREIGN KEY ( nome_l ) REFERENCES laborator io (nome)ON UPDATE CASCADE ON DELETE CASCADE,FOREIGN KEY ( vo ) REFERENCES laborator io ( nomevo )ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
CREATE TABLE prog_att(
nome varchar (20) NOT NULL,t ipo varchar (30) NOT NULL,i i l float ,wi float NOT NULL,val idazione numeric ( 1 ) NOT NULL,nome_lab varchar (50) NOT NULL,nome_vo varchar (20) NOT NULL,g i u s t i f i c a z i o n e varchar (2000) ,descr iz ione varchar (2000) ,PRIMARY KEY (nome, nome_lab , nome_vo ) ,FOREIGN KEY ( nome_lab ) REFERENCES laborator io (nome)ON UPDATE CASCADE ON DELETE CASCADE,
67
A.1 Database
FOREIGN KEY ( nome_vo ) REFERENCES laborator io ( nomevo )ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
CREATE TABLE costo(
nome_l varchar (50) NOT NULL,t ipo varchar (200) NOT NULL,ckl float NOT NULL,wk float NOT NULL,val idazione numeric ( 1 ) NOT NULL,data date NOT NULL,g i u s t i f i c a z i o n e varchar (2000) ,descr iz ione varchar (2000) ,PRIMARY KEY ( nome_l , t ipo , data ) ,FOREIGN KEY ( nome_l ) REFERENCES laborator io (nome)ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
CREATE TABLE se rv i z i o(
nome varchar (20) NOT NULL,t s l float ,ws float NOT NULL,access i numeric ,t ipo varchar (20) NOT NULL,val idazione numeric ( 1 ) NOT NULL,data date NOT NULL,nome_lab varchar (50) NOT NULL,nome_vo varchar (20) NOT NULL,descr iz ione varchar (2000) ,g i u s t i f i c a z i o n e varchar (2000) ,piattaforma varchar (50) NOT NULL,processore varchar (50) NOT NULL,ram varchar ( 8 ) NOT NULL,uti l izzo_ram numeric NOT NULL,so varchar (50) NOT NULL,storage numeric NOT NULL,home_page varchar ( 50 ) ,voto numeric ( 1 ) NOT NULL,PRIMARY KEY (nome, nome_lab , nome_vo ) ,FOREIGN KEY ( nome_lab ) REFERENCES laborator io (nome)ON UPDATE CASCADE ON DELETE CASCADE,FOREIGN KEY ( nome_vo ) REFERENCES laborator io ( nomevo )ON UPDATE CASCADE ON DELETE CASCADE
68
A.1 Database
)TYPE = InnoDB ;
CREATE TABLE data(
user varchar (10) NOT NULL,data date NOT NULL,PRIMARY KEY ( user , data )
)TYPE = InnoDB ;
CREATE TABLE cred i to(
valore numeric NOT NULL,nome_lab varchar (50) NOT NULL,nome_vo varchar (20) NOT NULL,data date NOT NULL,PRIMARY KEY ( valore , nome_lab , nome_vo , data )
)TYPE = InnoDB ;
CREATE TABLE creditobeta(
valore numeric NOT NULL,nome_lab varchar (50) NOT NULL,nome_vo varchar (20) NOT NULL,data date NOT NULL,PRIMARY KEY ( valore , nome_lab , nome_vo , data )
)TYPE = InnoDB ;
CREATE TABLE voto(
superuser varchar (20) NOT NULL,voto real NOT NULL,nome_ser varchar (20) NOT NULL,nome_lab varchar (50) NOT NULL,nome_vo varchar (20) NOT NULL,PRIMARY KEY ( superuser , voto , nome_ser , nome_lab , nome_vo )
)TYPE = InnoDB ;
CREATE TABLE immagine(
percorso varchar (200) NOT NULL,
69
A.2 Interfaccia
nome varchar (20) NOT NULL,lab varchar (50) NOT NULL,PRIMARY KEY ( percorso , nome, lab ) ,FOREIGN KEY ( lab ) REFERENCES laborator io (nome)ON UPDATE CASCADE ON DELETE CASCADE
)TYPE = InnoDB ;
A.2 Interfaccia
A.2.1 login.php
<?php// i n i z i o sess ionesession_start ( ) ;$ok = 0;
$connessione = mysql_connect ( ’ l o ca lhos t ’ , ’ root ’ , ’ ’ ) or die (" Connessione non r i u s c i t a : " . mysql_error ( ) ) ;
mysql_select_db ( ’ c r e d i t i ’ ) ;
//−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−////−−−−−−−−−−−−−−AMMINISTRATORE−−−−−−−−−−−−−−−−−−−−−////−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−//
$query = ( "SELECT amministratore . nome, amministratore . cognome ,amministratore . user , amministratore . mail , amministratore . nome_voFROM amministratoreWHERE amministratore . user = ’ " .$_REQUEST[ "username" ] . " ’AND amministratore . password = ’ " .$_REQUEST[ " password " ] . " ’ " ) ;
$ r i su l ta to = mysql_query ( $query ) ;
i f (mysql_num_rows ( $r i su l ta to ) > 0){
$data = mysql_fetch_array ( $r i su l ta to ) ;
// v a r i a b i l i di sess ione$_SESSION[ "name" ] = $data [ "nome" ] ;$_SESSION[ "surname" ] = $data [ " cognome" ] ;$_SESSION[ "admin" ] = $data [ " user " ] ;$_SESSION[ " mail " ] = $data [ " mail " ] ;$_SESSION[ " vir_org " ] = $data [ "nome_vo" ] ;
70
A.2 Interfaccia
header ( " Location : prima_home . php" ) ;$ok = 1;
}else{
header ( " Location : index . php? errore=1" ) ;$ok = 2;
}mysql_close ( $connessione ) ;
i f ( $ok == 0 or $ok ==2){
$connessione1 = mysql_connect ( ’ l o ca lhos t ’ , ’ root ’ , ’ ’ )or die ( " Connessione non r i u s c i t a : " . mysql_error ( ) ) ;
mysql_select_db ( ’ c r e d i t i ’ ) ;
//−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−////−−−−−−−−−−−−−−−−SUPERUSER−−−−−−−−−−−−−−−−−−−////−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−//
$query1 = ( "SELECT nome, cognome , users , mail , nome_l , voFROM superuser WHERE users = ’ " .$_REQUEST[ "username" ] . " ’AND pass = ’ " . ($_REQUEST[ " password " ] ) . " ’ " ) ;
$r isu l tato1 = mysql_query ( $query1 ) ;
i f (mysql_num_rows ( $r isu l tato1 ) > 0){
$data1 = mysql_fetch_array ( $r isu l tato1 ) ;
// v a r i a b i l i di sess ione$_SESSION[ "name_sup" ] = $data1 [ "nome" ] ;$_SESSION[ "surname_sup" ] = $data1 [ " cognome" ] ;$_SESSION[ "admin_sup" ] = $data1 [ " users " ] ;$_SESSION[ " lab_sup " ] = $data1 [ " nome_l " ] ;$_SESSION[ " vir_org_sup " ] = $data1 [ " vo " ] ;
header ( " Location : prima_superuser_home . php" ) ;}else{
header ( " Location : index . php? errore=1" ) ;}mysql_close ( $connessione1 ) ;}?>
71
A.2 Interfaccia
A.2.2 logout.php
<?phpob_start ( ) ;
session_start ( ) ;session_unset ( ) ;session_destroy ( ) ;
header ( " Location : index . php" ) ;ob_end_flush ( ) ;?>
A.2.3 checkuser.php
<?phpsession_start ( ) ;i f ( ! isset ($_SESSION[ "admin" ] ) ){
header ( " Location : index . php? sessione=1" ) ;}?>
A.2.4 checksuperuser.php
<?phpsession_start ( ) ;i f ( ! isset ($_SESSION[ "admin_sup" ] ) ){
header ( " Location : index . php? sessione=1" ) ;}?>
A.2.5 checklab.php
<?php
session_start ( ) ;$ok = 0;
72
A.2 Interfaccia
i f ($_POST[ " s e l e c t " ] == ’ ’ ){
$ok = 2;}i f ( $ok == 0){$connessione = mysql_connect ( " l o ca lhos t " , " root " , " " )or die ( " Connessione non r i u s c i t a : " . mysql_error ( ) ) ;
mysql_select_db ( ’ c r e d i t i ’ ) ;$query = "SELECT laborator io . nome FROM laborator ioWHERE laborator io . nome = ’ " .$_REQUEST[ " s e l e c t " ] . " ’ " ;
$ r i su l ta to = mysql_query ( $query ) ;i f (mysql_num_rows ( $r i su l ta to ) > 0){
$data = mysql_fetch_array ( $r i su l ta to ) ;
$_SESSION[ " labdapassare " ] = $data [ "nome" ] ;$ok = 1;
}}
i f ( $ok == 1){
header ( " Location : manage_ser . php" ) ;}i f ( $ok == 2){
header ( " Location : laborator io . php? not =1.php" ) ;}?>
A.2.6 op_crediti.php
<?php
session_start ( ) ;
$connessione = mysql_connect ( ’ l o ca lhos t ’ , ’ root ’ , ’ ’ ) or die (" Connessione non r i u s c i t a : " . mysql_error ( ) ) ;$ok = 1;i f ($_POST[ " lab " ] == ’ ’ ){
$ok = 0;header ( " Location : cred i to . php? errore=1" ) ;
}
73
A.2 Interfaccia
i f ( $ok==1){mysql_select_db ( ’ c r e d i t i ’ ) ;$somma = 0;$query = ( "SELECT i i l ∗wi AS proget to_at t iv i tà FROM prog_attWHERE prog_att . nome_lab = ’ " .$_REQUEST[ " lab " ] . " ’AND prog_att . nome_vo = ’ " . $_SESSION[ " vir_org " ] . " ’AND prog_att . val idazione = ’1 ’ " ) ;
$ r i su l ta to = mysql_query ( $query ) ;while ( $tota le = mysql_fetch_array ( $r i su l ta to ) ){$somma = $somma + $tota le [ " proge t to_at t iv i tà " ] ;}
$somma2 = 0;$query2 = ( "SELECT ckl ∗wk AS cos to_ to ta le FROM costoJOIN laborator io ON ( costo . nome_l = laborator io . nome)WHERE costo . nome_l = ’ " .$_REQUEST[ " lab " ] . " ’AND laborator io . nomevo = ’ " . $_SESSION[ " vir_org " ] . " ’AND costo . val idazione = ’1 ’ " ) ;
$r isu l tato2 = mysql_query ( $query2 ) ;while ( $totale2 = mysql_fetch_array ( $r isul tato2 ) ){$somma2 = $somma2 + $totale2 [ " cos to_ to ta le " ] ;}
$somma3 = 0;$query3 = ( "SELECT ∗ FROM serv i z i oWHERE serv i z i o . nome_lab = ’ " .$_REQUEST[ " lab " ] . " ’AND serv i z i o . nome_vo = ’ " . $_SESSION[ " vir_org " ] . " ’AND serv i z i o . val idazione = ’1 ’ " ) ;
$r isu l tato3 = mysql_query ( $query3 ) ;while ( $totale3 = mysql_fetch_array ( $r isul tato3 ) ){$molt ip l icazione = $totale3 [ "ws" ] ∗( $totale3 [ " access i " ] ∗ $totale3 [ " t s l " ] ) ;$somma3 = $somma3 + $molt ip l icazione ;}$aggiunta = 100;$uno = 0.2 ∗ $somma;$due = 0.3 ∗ $somma2 ;$tre = 0.5 ∗ $somma3 ;$condizione_scambio = $uno + $due + $tre + 0.000001;preg_match ( " / [0 −9]∗\. / " , $condizione_scambio , $matches ) ;$r isu l tato4 = substr ( $matches [ 0 ] , 0 ,−1) + $aggiunta ;
74
A.2 Interfaccia
i f ( $r isu l tato4 == 0){
$pro = 0;$_SESSION[ " r i s " ] = $pro ;
}
i f ( $r isu l tato4 != 0){$_SESSION[ " r i s " ] = $r isul tato4 ;}$_SESSION[ " lab " ] = $_REQUEST[ " lab " ] ;header ( " Location : cred i to . php? r i s u l t a t o =1" ) ;}?>
A.2.7 op_crediti_singolo.php
<?php
session_start ( ) ;
$connessione = mysql_connect ( ’ l o ca lhos t ’ , ’ root ’ , ’ ’ ) or die (" Connessione non r i u s c i t a : " . mysql_error ( ) ) ;$ok = 1;i f ($_POST[ " s e l e c t " ] == ’ ’ ){
$ok = 0;header ( " Location : superuser_home . php? nosingolo=1&#ca l co la " ) ;
}
i f ( $ok==1){mysql_select_db ( ’ c r e d i t i ’ ) ;$query = ( "SELECT ∗ FROM serv i z i oWHERE serv i z i o . nome = ’ " .$_REQUEST[ " s e l e c t " ] . " ’AND serv i z i o . nome_lab = ’ " . $_SESSION[ " lab_sup " ] . " ’AND serv i z i o . nome_vo = ’ " . $_SESSION[ " vir_org_sup " ] . " ’ " ) ;
$ r i su l ta to = mysql_query ( $query ) ;while ( $tota le = mysql_fetch_array ( $r i su l ta to ) ){
$molt ip l icazione = $tota le [ "ws" ] ∗( $tota le [ " access i " ] ∗ $tota le [ " t s l " ] ) ;$somma = $molt ip l icazione ;$normaliz = (0 .5 ∗ $somma) + 0.0000001;
}
75
A.2 Interfaccia
preg_match ( " / [0 −9]∗\. / " , $normaliz , $matches ) ;$tot = substr ( $matches [ 0 ] , 0 ,−1);//$to t = round ($somma, 2 ) ;i f ( $tot == 0){
$pro = 0;$_SESSION[ "sommina" ] = $pro ;
}
i f ( $tot != 0){$_SESSION[ "sommina" ] = $tot ;}header ( " Location : superuser_home . php? r i s u l t a t o=1&#ca l co la " ) ;}?>
76
Bibliografia
[1] W. Aspray, John von Neumann and the origins of modern computing,
(1990).
[2] http://it.wikipedia.org/wiki/ENIAC.
[3] G. S. Sohi, S. E. Breach, and T.N. Vijaykumar, Multiscalar processor, In
Proceedings of the 22nd Annual International Symposium on Computer
Architecture, 414-425 (1995).
[4] M. J. Flynn, Very high-speed computing system, In Proc. of the IEEE, vol.
54, 1901 (1966)
[5] W. Handler, in: Parallel Processing Systems, An Advanced Course, ed.
C.U. Press, 41, Evans DJ ed., Cambridge, (1982).
[6] http://www.gigaflop.demon.co.uk/comp/chap7.html.
[7] R. W. Hockney and C. R. Jesshope, Parallel Computers 2, Adam
Hilger/IOP Publishing, Bristol, (1988).
[8] http://grid.infn.it.
[9] http://delphiwww.cern.ch.
[10] http://www.globus.org.
[11] http://eu-datagrid.web.cern.ch/eu-datagrid/.
[12] https://genius.ct.infn.it.
77
BIBLIOGRAFIA
[13] http://www.cern.ch/datatag.
[14] http://Grid-it.cnaf.infn.it/.
[15] http://www.omii.ac.uk.
[16] http://www.nsf-middleware.org.
[17] I. Foster, C. Kesselman, K. Morgan: The Grid 2: Blueprint for a New
Computing Infrastructure, 2nd Edition (2003).
[18] http://www.eu-egee.org.
[19] A. Manfucci, Tesi di Laurea (2007)
[20] A. Laganà, A. Riganelli and O. Gervasi, In On the Structuring of the
Computational Chemistry Virtual Organization COMPCHEM, Lecture
Notes in Computer Science 3980, 665 (2006)
[21] The Apache Software Foundation (http://www.apache.org)
[22] PHP: Hypertext Preprocessor (http://www.php.net)
[23] Database Open Source (http://www.mysql.com)
78
Grazie
Vorrei rivolgere un sentito ringraziamento al Professor Antonio Laganà per
avermi concesso l’opportunità di svolgere questo appassionante lavoro di tesi
e per il fondamentale contributo datomi nella realizzazione di questa.
Vorrei inoltre ringraziare il Dottor Leonardo Pacifici per il costante aiuto for-
nitomi e per la disponibilità dimostratami in questi quattro mesi di lavoro.
Un immenso grazie ad Andrea, compagno insostituibile di studio che mi ha
sostenuto dandomi sempre la forza per andare avanti in questa avventura.
Un grazie speciale a Marta per avermi sopportato per tutto questo tempo e a
Michele per avermi dato l’opportunità di vivere a Perugia.
Vorrei ringraziare infine tutti gli amici del dipmat. In particolare quelli del
clan ”UDM” e quelli delle serate ”LOST”.
79
top related