Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM

U NIVERSITÀ DEGLI S TUDI DI P ERUGIA
Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di laurea in I NFORMATICA

Tesi di Laurea Triennale

Grid Credit System:
un portale per la sostenibilità
di COMPCHEM

Laureando: Relatore:
Davide Ciambelli Prof. Antonio Laganà

Correlatore:
Dr. Leonardo Paciﬁci

Anno Accademico 2006/2007

Indice

Elenco delle ﬁgure 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 sﬁda 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

Bibliograﬁa 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 al
grid 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


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


to ciò a portato ad un costante aumento della velocità di calcolo che è stata
quantiﬁcata 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: Graﬁco 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


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 decodiﬁca delle
istruzioni, e così via. Questo signiﬁca 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


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


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


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


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


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 1000000000000
a(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.


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.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


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 ﬂusso 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


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


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


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 PCU
k’= numero di PCU che formano la pipeline
d = numero di ALU controllate da ogni PCU
d’= numero di ALU che formano la pipeline
w = 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 ﬁne di descrivere computer paralleli. Questa
notazione è alla base della loro tassonomia strutturale.

15


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


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


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 ”backﬁll” alle memorie più piccole
attraverso il trasferimento di pagine di dati. Questo metodo può risultare
inefﬁciente 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


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


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’efﬁcienza 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


• 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 ﬁne 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 ﬁno 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


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 grande
1
Come 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 il
finanziamento 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 ﬁnora 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 speciﬁche 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 di
EGEE

A computational grid is a hardware and software infrastructure
that 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 scientiﬁca 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 ﬁnanziamenti

34

2.2 L’articolazione

che per la maggior parte provengono dalla Comunità Europea ma anche da
altri paesi non comunitari.


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


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


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


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.


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


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 file
exchange but rather direct access to computers, software, data, and
other resources, as is required by a range of collaborative problemsolving
and resource-brokering strategies emerging in industry,
science, and engineering. This sharing is, necessarily, highly
controlled, with resource providers and consumers defining clearly
and carefully just what is shared, who is allowed to share, and the
conditions under which sharing occurs. A set of individuals and/or
institutions 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.


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


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 workﬂow 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.


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


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]):

Nα
Ξl = αT αT ωs (Tsl ) + αI αI ωi Iil + αC αC ωk Ckl (3.1)
s Tsl + ζ i k

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++.


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


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 graﬁca.
L’obiettivo ﬁn 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

Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM

Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM

Ähnlich wie Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM (19)

Mehr von Davide Ciambelli

Mehr von Davide Ciambelli (20)

Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM