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

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


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

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


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


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


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


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


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


• 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


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.


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


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


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

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


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


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


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.


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


• 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


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


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


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


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


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


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


Figura 3.5: Amministrazione - calcolo dei crediti

62


Figura 3.6: Utente - schermata dell’area personale

63


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

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

Education

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