Your SlideShare is downloading. ×
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

1,174
views

Published on

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

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


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,174
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. U NIVERSITÀ DEGLI S TUDI DI P ERUGIA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di laurea in I NFORMATICA Tesi di Laurea Triennale Grid Credit System: un portale per la sostenibilità di COMPCHEM Laureando: Relatore: Davide Ciambelli Prof. Antonio Laganà Correlatore: Dr. Leonardo Pacifici Anno Accademico 2006/2007
  • 2. Alla mia famiglia.
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. Capitolo 1 Dal calcolo sequenziale al grid computing We will probably see the spread of ”computer utilities”, which, like present electric and telephone utilities, will service individual homes and offices across the country. - Len Kleinrock - 1.1 Architetture uniprocessore 1.1.1 Calcolo sequenziale Le architetture a singolo processore sono basate sul noto modello di Von Neu- mann [1]. In questo modello l’unità di elaborazione, dal momento della sua accensione fino allo spegnimento, attraversa incessantemente, ripetitivamen- te ed alla sua massima velocità il ciclo mostrato in Figura 1.1. Nella fase di bootstrap il processore esegue una serie di istruzioni prelevandole da una ROM (il BIOS ad esempio) che mettono la macchina in grado di funzionare correttamente. Successivamente, il processore entra nel vero e proprio ciclo di funzionamento e vengono seguite le seguenti operazioni: • fetch (caricamento): produce il caricamento della prossima istruzione da eseguire. • decode (decodifica): interpreta l’istruzione che si trova nella memoria 1
  • 8. 1.1 Architetture uniprocessore come un codice che dovrà essere opportunamente ”riconosciuto” dal pro- cessore ed eseguito. • operand assembly (preparazione degli operandi): raccoglie gli eventua- li operandi necessari a svolgere l’istruzione corrente (per esempio: gli addendi di una somma, un indirizzo di memoria da incrementare, ecc.). • execute (esecuzione): consiste nell’eseguire effettivamente l’istruzione corrente sugli operandi collezionati. Figura 1.1: Ciclo di Von Neumann A valle di questa fase il processore controlla se si sono verificati degli inter- rupt, ovvero particolari istruzioni che consentono l’interruzione di un processo qualora si verifichino determinate condizioni o quando un processo deve effet- tuare una richiesta al sistema operativo (questa fase non è mostrata nella fi- gura). Successivamente ritorna alla fase di fetch per procedere all’esecuzione dell’istruzione successiva. L’architettura di Von Neumann ha rappresentato il punto di partenza per la manipolazione efficiente delle informazioni. Rispetto all’originale, l’archi- tettura ha subito importanti cambiamenti per aumentare la velocità e miglio- rare l’efficienza. Il grande passo verso i calcolatori più veloci è stato suppor- tato dagli avanzamenti della tecnologia nel campo dello sviluppo di circuiti integrati. L’aumento di elementi circuitali in un processore ha reso le CPU più efficienti, le memorie più capienti ed i bus più veloci e performanti. Tut- 2
  • 9. 1.1 Architetture uniprocessore to ciò a portato ad un costante aumento della velocità di calcolo che è stata quantificata nel 1965 dalla prima legge di Moore (Figura 1.2): Le prestazioni dei processori, e il numero di transistor ad essi relativo, raddoppiano ogni 18 mesi. Tuttavia, essendoci un limite a questo processo (un segnale non può essere più veloce rispetto alle velocità della luce nel mezzo in cui si propaga), la ricer- ca si è sviluppata lungo direttrici parallele, compresi circuiti ottici, dispositivi molecolari, calcolatori quantistici, ecc... Figura 1.2: Grafico della legge di Moore 1.1.2 Gestione della concorrenza La concorrenza era già un concetto intrinseco nel modello di Von Neumann in quanto tale architettura utilizza bus per il trasferimento parallelo di bit. Il primo calcolatore a valvole termoioniche (ENIAC [2]) era costituito da 25 uni- tà di calcolo indipendenti. Tuttavia, la maggior parte del progresso iniziale venne ottenuto solo a livello gestionale. I concetti di multiprogrammazione e 3
  • 10. 1.1 Architetture uniprocessore time-sharing stavano gettando le basi per la costruzione di hardware e soft- ware concorrente in computer sequenziali. A tal proposito, concetti e tecnolo- gie come il prefetching e il rescheduling delle istruzioni avevano come intento quello di aumentare la concorrenza. Il reale avanzamento, tuttavia, è stato raggiunto attraverso la duplica- zione delle CPU, la segmentazione delle unità di elaborazione e il partizio- namento della memoria. Questa forma di concorrenza implementata su una macchina sequenziale è chiamata ”parallelismo”. 1.1.3 Parallelismo a livello di istruzione Nel parallelismo a livello di istruzioni (Instruction Level Parallelism, ILP) avviene l’esecuzione di più istruzioni in maniera concorrente. Questo è realiz- zabile utilizzando il pipeling: viene sfruttata l’organizzazione dell’hardware all’interno della CPU dividendolo in distinte sezioni impiegate per la gestione delle diverse fasi delle istruzioni. Un insieme di porte logiche viene utilizza- to per la gestione della fase di fetch, un’altra sezione per la decodifica delle istruzioni, e così via. Questo significa che ad ogni istante è attiva solo una sezione, rendendo quindi possibile l’utilizzo delle altre sezioni per gestire la fase corrispondente in una successiva istruzione. Questo rappresenta il concetto di base dell’architettura pipeline (Figu- ra 1.3): Figura 1.3: Esecuzione pipeline dove IF è l’Instruction Fetch, ID è l’Instruction Decode, EX è l’Execution, 4
  • 11. 1.1 Architetture uniprocessore MEM è il Memory Access e WB è il Write/Back. Una volta eseguita la fase di fetch per l’istruzione i, si può procedere ad eseguire il fetch per l’istruzione i+1, mentre l’istruzione i passa alla fase di decode. Successivamente si potrà passare alla fase di fetch per l’istruzione i+2 mentre l’istruzione i+1 è nella fase di decode e l’istruzione i in quella di execute. Architetture superscalari In una macchina di tipo pipeline, sebbene le istruzioni vengano eseguite in concorrenza, in ciascuno stage della pipe è presente una sola istruzione. In una macchina superscalare di grado n invece, il numero di istruzioni atti- ve è n. Per sfruttare completamente questa ”pipe replicata”, devono esserci n istruzioni eseguibili in parallelo (grado di ILP = n), altrimenti si dovranno for- zare delle attese per attendere i dati provenienti dalle precedenti istruzioni. Formalmente: • istruzioni caricate per ciclo = n • latenza di ciascuno stadio della pipe = 1 • ILP necessario = n Nell’esempio della Figura 1.4 il grado di parallelismo assume un valore ugua- le a due (n = 2). Molti microprocessori utilizzano questa tecnologia, con livelli di parallelismo due, tre, quattro oppure, come nel caso del multichip IBM PO- WER2, con livello sei. Nella figura IF è l’Instruction Fetch, ID è l’Instruction Decode, EX è l’Execution, MEM è il Memory Access e WB è il Write/Back. Architetture VLIW Il principio di funzionamento delle architetture VLIW (Very Long Instruction Word) si basa sulla specifica di un certo insieme di istruzioni caricate ed ese- guite contemporaneamente dal processore (Figura 1.5). Dalla definizione po- 5
  • 12. 1.1 Architetture uniprocessore Figura 1.4: Esecuzione superscalare trebbe sembrare che un processore superscalare e un processore VLIW siano analoghi. In realtà si differenziano per due caratteristiche principali: • Nelle macchine VLIW la selezione delle istruzioni da caricare in un ciclo di clock avviene durante la compilazione mentre per le macchi- ne superscalari avviene durante l’esecuzione del programma. La lo- gica di decodifica per le VLIW risulta molto più semplice rispetto alle superscalari. • Quando in una macchina superscalare la densità di codice è maggiore, il grado di ILP è inferiore a quello disponibile nell’architettura VLIW. Infatti il formato di istruzioni della VLIW è fisso e comprende dei bit anche per istruzioni inutili che non verranno utilizzate. I chip di tipo VLIW non necessitano dei complessi circuiti di controllo che i chip superscalari, invece, adottano per coordinare le operazioni parallele: i chip VLIW trasferiscono gran parte della mole di lavoro ai compilatori. In questo modo, gli strumenti di sviluppo software che i programmatori utilizza- no per compilare i loro programmi in codice eseguibile hanno la responsabilità di organizzare le istruzioni nel modo più efficiente possibile. 6
  • 13. 1.1 Architetture uniprocessore Figura 1.5: Esecuzione VLIW Inoltre i chip VLIW combinano due o più istruzioni in un singolo pac- chetto; il compilatore organizza quindi questi pacchetti in modo che il chip VLIW possa rapidamente eseguire le istruzioni in parallelo, liberando il mi- croprocessore dal compito di dover eseguire le complesse e continue analisi che invece devono essere condotte dagli altri chip in fase di runtime. Architetture multiscalari Il più recente paradigma ILP è quello Multiscalare [3], nel quale la granu- larità del parallelismo, sfruttata a livello di istruzione, è maggiore rispetto a quella delle architetture superscalari. In questa architettura il programma caricato in memoria è suddiviso frache molti task indipendenti e logicamen- te disaccoppiati che vengono distribuiti alle unità funzionali, dove le fasi del 7
  • 14. 1.1 Architetture uniprocessore ciclo di macchina sono applicate alle istruzioni del task assegnato. 1.1.4 Parallelismo a livello dei dati Il parallelismo sfruttato a livello dei dati (Data Level Parallelism, DLP) dif- ferisce dall’ILP nella granularità degli operandi coinvolti nelle operazioni. Le operazioni aritmetiche sono eseguite su array di oggetti: in questo modo il pa- radigma risulta efficiente rispetto ad applicazioni che coinvolgono un elevato numero di operazioni su matrici. Processori vettoriali Questo tipo di processori, oltre ai normali registri e istruzioni scalari, contiene degli speciali tipi di registri (registri vettoriali) che possono contenere N valori contemporaneamente, ed ogni operazione che coinvolga uno di questi registri viene eseguita su tutti i valori in esso memorizzati. Affinché questo meccanismo sia efficiente è necessario che il collegamento con la memoria sia molto veloce, ovvero che abbia una banda passante mol- to elevata; in questo tipo di macchine anche la memoria è caratterizzata da un’architettura vettoriale, vale a dire strutturata in modo che sia possibile leggere o scrivere esattamente N valori contemporaneamente. É inoltre possibile specificare un altro registro vettoriale come destinazio- ne dell’operazione corrente, nel quale il risultato verrà ulteriormente mani- polato. Queste macchine sono programmabili con facilità (il parallelismo è gestito in maniera del tutto trasparente al programmatore), ma danno buone prestazioni solo nel caso di algoritmi con molte operazioni vettoriali. Array processor Un array processor non ha istruzioni scalari, ma solo vettoriali: è costituito da una unità di controllo (UC) che gestisce un array di processori (Processing Element, PE): i collegamenti fra i PE e fra PE e memoria, sono di tipo matrice bidimensionale, vale a dire che ogni PE comunica con i suoi quattro vicini, 8
  • 15. 1.1 Architetture uniprocessore con la UC e con la memoria. La UC legge le istruzioni, se sono scalari le esegue lei stessa mentre se sono vettoriali le invia ad ogni PE che si occupa di un singolo dato dell’array, in parallelo: quando tutti i PE hanno terminato, la UC passa all’istruzione successiva. Per questo un array processor viene considerato una macchina a parallelismo spaziale cioè un insieme di unità funzionali replicate e utilizzate nello stesso tempo per realizzare una singola o diverse computazioni. Le prestazioni di un array processor sono ancora più legate al tipo di operazione: è molto veloce solo quando opera su array e vettori. Una evoluzione dell’array processor è la Connection Machine, che al posto dei normali PE introduce delle celle costituite da un PE e una memoria locale, connesse con una topologia ipercubica. Array sistolici Gli array sistolici sono delle architetture che elaborano un flusso di dati che si muove in modo prevedibile e ritmico lungo uno specifico percorso durante la sua elaborazione. Sono utilizzati spesso nell’elaborazione dei segnali in quanto i dati sono campionati con delle frequenze conosciute e devono subire delle elaborazioni predefinite che interessano tutti i dati. In questi array ogni elemento esegue una specifica elaborazione che dipende solamente dai dati di ingresso e dal suo stato interno. I dati elaborati vengono mandati in uscita dove un altro elemento provvederà a riceverli ed elaborarli. Le operazioni sono sincronizzate tramite un clock globale. Gli algoritmi eseguiti su questi array sono detti sistolici in analogia al flusso sanguigno che fluisce ad impulsi tramite percorsi predefiniti. 1.1.5 Limiti delle architetture sequenziali Le architetture sequenziali descritte nelle sezioni precedenti stanno raggiun- gendo il limite fisico delle loro prestazioni. Infatti, oltre alla velocità di esecu- zione, che può essere aumentata usando la già citata gestione della concorren- 9
  • 16. 1.2 Architetture multiprocessore za implementata nelle architetture ILP e DLP, c’è il limite fisico che riguarda la connessione diretta di una singola CPU ad una memoria sufficientemente grande. Consideriamo il caso di un computer scalare che deve eseguire in un secondo il seguente ciclo nel quale vengono trasferite 3 · 1012 variabili dalla memoria ai registri di CPU: Do i=1 to 1000000000000 a(i)=b(i)+c(i) EndDo Ciò implica che se r è la distanza media di una parola dalla memoria alla CPU, la distanza generale da coprire mentre vengono trasferite 3 · 1012 variabili in un secondo è 3 · 1012 · r. Poiché la velocità della luce è 3 · 108 m/s si ottiene r = 10−4 m. Se abbiamo 3 · 1012 celle di memoria (ognuna contenente una parola) disposte come una matrice bidimensionale, allora si hanno circa 106 celle per riga. Questo significa che ogni cella non può avere una dimensione più grande di 10−6 · r oppure 10−10 m che rappresenta il diametro medio di un atomo. Di conseguenza, poiché non possiamo immagazzinare un numero di bit pari a 32/64 in una locazione del calibro di un atomo, non possiamo costruire un computer scalare con le prestazioni massime di 1 Tflops. Ciò significa che per aumentare le prestazioni dell’hardware si devono sviluppare piattaforme aventi molti processori ciascuno dei quali circondato da una memoria locale. 1.2 Architetture multiprocessore Come già accennato il parallelismo è definito come la simultanea esecuzione di operazioni indipendenti. Lo sfruttamento del parallelismo può riguardare tutti i livelli di astrazione di un computer. A tal proposito, è utile introdurre una tassonomia di classificazione che identifica le varie architetture in base ai flussi di dati e istruzioni. 10
  • 17. 1.2 Architetture multiprocessore 1.2.1 Tassonomia di Flynn Partendo dal modello di Von Neumann, che consiste di un processore che ese- gue sequenzialmente una serie di istruzioni per produrre un risultato, una classificazione può essere basata sul concetto di flusso di istruzioni e flusso di dati. La più famosa ed accettata classificazione delle architetture per i sistemi paralleli è quella proposta da Michael J. Flynn [4]. Secondo questa classificazione, le due più importanti caratteristiche di un elabratore sono: • il numero di flussi d’istruzioni che può processare ad ogni istante; • il numero di flussi di dati sul quale può operare simultaneamente. In base a questa classificazione ogni sistema di calcolo rientra in una di queste categorie (Figura 1.6): • SISD (Singola Istruzione Singolo flusso di Dati); • SIMD (Singola Istruzione Multiplo flusso di Dati); • MISD (Multiple Istruzioni Singolo flusso di Dati); • MIMD (Multiple Istruzioni Multiplo flusso di Dati). Figura 1.6: Architetture di calcolo 11
  • 18. 1.2 Architetture multiprocessore SISD Nel 1946 Von Neumann stabiliva i principi generali di progettazione di un ela- boratore. L’architettura SISD (Figura 1.7) si basa proprio su questi principi essendo essenzialmente una macchina seriale con un unico flusso di istruzioni dove ad ogni ciclo di clock viene eseguita una sola istruzione. Le prestazioni vengono calcolate in MIPS (Milioni d’Istruzioni Per Secondo). Molte delle ap- plicazioni sviluppate con questa tecnologia non vengono fatte rientrare nella categoria dei supercomputer. Figura 1.7: Architettura SISD SIMD É ancora un’architettura di Von Neumann ma con istruzioni che operano su più elementi (Figura 1.8). Questa tecnologia utilizza processori identici e interconnessi che ricevono dati diversi da un host intermediario ed eseguo- no le stesse operazioni sui dati ricevuti. La velocità d’elaborazione si misu- ra in MFLOPS (Million FLOating-Point per Second). Le architetture SIMD possono essere suddivise in due classi: • SIMD vettoriali, che nello stesso istante lavorano sull’intero vettore di dati. É previsto un host che si occupa di distribuire i dati ai vari worker; • SIMD paralleli, che inviano la stessa istruzione vettoriale a tutti i pro- cessori. In questo caso l’host si occupa soltanto del controllo, mentre i dati vengono scambiati tramite memoria condivisa o rete d’interconnes- sione. 12
  • 19. 1.2 Architetture multiprocessore Figura 1.8: Architettura SIMD MISD Sono architetture caratterizzate dall’avere processori che svolgono diverse operazioni su di un singolo flusso di dati, allo stesso istante di tempo (Fi- gura 1.9). É da notare che, mentre nella classe SIMD la granularità, ovvero la dimensione delle attività eseguibili in parallelo, è quella delle istruzioni, nella classe MISD la granularità è quella dei processi ovvero dei programmi composti da più istruzioni. Figura 1.9: Architettura MISD MIMD Rappresenta il modello d’architettura parallela più potente e flessibile, per- ché in grado di gestire flussi d’istruzioni e dati multipli (Figura 1.10). Ogni processore riceve dalla propria unità di controllo un flusso d’istruzioni e rice- ve un flusso di dati tramite la memoria condivisa o la rete d’interconnessione, lavorando così in maniera asincrona rispetto agli altri. É quindi di fondamen- tale importanza che il carico di lavoro sia bilanciato. A seconda del numero di 13
  • 20. 1.2 Architetture multiprocessore processi è possibile distinguere macchine a grana grossa (poche unità molto potenti) da quelle a grana fina (molte unità poco potenti). Una ulteriore classificazione di queste macchine riguarda i metodi di co- municazione. I computer MIMD che usano la memoria condivisa sono chia- mati multiprocessori (Tightly Coupled Machines) mentre quelli che utilizza- no la rete d’interconnessione sono chiamati multicomputer (Loosely Coupled Machines). Figura 1.10: Architettura MIMD 1.2.2 Altre tassonomie La tassonomia di Flynn presenta dei limiti che la rendono inadeguata rispet- to alla classificazione delle architetture più moderne. Questa tassonomia, infatti, confina tutte le macchine parallele nella classe MIMD. Per questa ragione, altre tassonomie sono state proposte da vari autori. Esse fornisco- no parametri supplementari per classificare attualmente tutte le macchine disponibili: • Tassonomia di Handler [5]: nel 1977 Handler propose una notazio- ne elaborata per esprimere il pipeling ed il parallelismo dei computer. La tassonomia di Handler descrive un computer in base a tre elementi architetturali la PCU (Processor Control Unit), la ALU (Arithmetic Lo- gic Unit), e il BLC (Bit-Level Circuit). La PCU corrisponde alla CPU, 14
  • 21. 1.2 Architetture multiprocessore la ALU corrisponde ad una unità funzionale o elemento di elaborazio- ne in un array processor e il BLC corrisponde alla logica necessaria per realizzare operazione one-bit nella ALU. In particolare, la tassonomia di Handler fa uso di tre coppie di interi per descrivere un computer: Computer = (k*k’, d*d’, w*w’) k = numero di PCU k’= numero di PCU che formano la pipeline d = numero di ALU controllate da ogni PCU d’= numero di ALU che formano la pipeline w = numero di bit nella ALU o parole processing element (PE) w’= numero di pipeline segmentate su tutta la ALU o in un singolo PE Per esempio, il CRAY-1 è un computer a singolo processore a 64 bit con 12 unità funzionali aventi da 1 a 14 segmenti che possono essi stessi essere messi in pipe. Per esempio, secondo la tassonomia di Handler la notazione per il CRAY-1 è la seguente: Cray-1 = (1, 12*8, 64*(1 ~ 14)) • Tassonomia di Shore [6]: Shore propose la sua tassonomia nel 1973. É basata sulla struttura e sul numero di unità funzionali incorporate nel computer. Questa tassonomia è caratterizzata da sei categorie diverse ognuna delle quali è associata ad un numero (Type-I - Type-VI). • Tassonomia di Hockney e Jesshope [7]: Hockney e Jesshope han- no sviluppato una notazione elaborata chiamata ASN (Algebraic-style Structural Notation) al fine di descrivere computer paralleli. Questa notazione è alla base della loro tassonomia strutturale. 15
  • 22. 1.2 Architetture multiprocessore 1.2.3 Ulteriore suddivisione delle macchine MIMD I computer paralleli di tipo MIMD possono generalmente implementare due diversi modelli architetturali: 1. macchine con memoria locale che comunicano mediante messaggi (clu- ster Beowulf) 2. macchine con memoria condivisa che comunicano attraverso lo spazio in memoria (macchine SMP) Un tipico cluster Beowulf è un insieme di macchine con singola CPU, connes- se usando schede Ethernet ed è, pertanto, una macchina a memoria locale. Una macchina SMP a 4 vie è una macchina a memoria condivisa e può essere usata per eseguire applicazioni parallele che comunichino tramite la memo- ria condivisa. Le macchine a memoria locale sono caratterizzate dall’essere altamente scalabili mentre il numero di CPU in macchine a memoria deve essere limitato a causa di conflitti nell’accesso alla memoria. Tuttavia, è possibile connettere molte macchine a memoria condivisa per creare una macchina a memoria condivisa ”ibrida”. Queste macchine ibride ”appaiono” all’utente come una grande macchina SMP e un esempio è rap- presentato dalle macchine di tipo NUMA (Non Uniform Memory Access) nel- le quali la memoria globale vista dal programmatore è condivisa da tutte le CPU. É anche possibile connettere macchine SMP come nodi di calcolo a me- moria locale. Le tipiche schede madri della CLASSE I hanno 2 o 4 CPU e spesso rappresentano un mezzo per ridurre il costo del sistema complessivo. Lo schedulatore interno del sistema operativo determina come queste CPU gestiscano le risorse condivise. L’utente pertanto, non può assegnare uno spe- cifico task ad uno specifico processore SMP. L’utente può, comunque, iniziare due processi indipendenti oppure un processo multithreaded e aspettarsi un aumento di performance rispetto ad un sistema avente una singola CPU. Per- ciò è importante tenere in considerazione le modalità di comunicazione tra 16
  • 23. 1.2 Architetture multiprocessore i vari nodi per permetterne il coordinamento e l’ottimizzazione. La modalità con cui i processi possono comunicare dipende dall’architettura della memoria e può essere di tre tipi: • memoria condivisa • memoria distribuita • memoria gerarchica Memoria Condivisa Nelle architetture a memoria condivisa i processori operano in maniera indi- pendente e la sincronizzazione è ottenuta controllando i valori che essi leg- gono e scrivono (Figura 1.11). La condivisione dei dati tra i processi avviene velocemente (in base alle velocità di accesso alla memoria). Uno dei proble- mi più comuni è rappresentato dall’accesso simultaneo alla stessa locazione di memoria da parte di più processori. Inoltre il bus che connette memo- ria e processore ha una banda limitata che può causare dei colli di bottiglia. Per risolvere i problemi di concorrenza relativi all’accesso in memoria, de- vono essere implementati da parte del programmatore dei vincoli (semafori lock-unlock) per evitare situazioni di stallo o di indeterminazione. Figura 1.11: Memoria condivisa Memoria distribuita Questo tipo di architettura di memoria è tipico delle reti di computer (Figu- ra 1.12). Ogni processore opera indipendentemente e con la propria memoria 17
  • 24. 1.2 Architetture multiprocessore privata; la sincronizzazione dei processi e la condivisione dei dati avvengo- no tramite la rete. Il meccanismo di comunicazione maggiormente usato è il message passing, implementato esplicitamente attraverso le primitive SEND e RECEIVE eliminando così il pericolo di interferenze. Queste architettu- re sono caratterizzate dal fatto che la banda per la comunicazione aumenta con l’aumentare del numero dei nodi, e il programmatore è responsabile della gestione dello scambio dei dati. Figura 1.12: Memoria distribuita Memoria Gerarchica Questa architettura è una combinazione delle due descritte precedentemente. Si ha una memoria condivisa globale che comunica con delle memorie locali anch’esse condivise dai processori. Le memorie locali sono molto veloci e pos- sono essere usate per fornire dati ai processori mentre la memoria globale, che è più lenta, può essere usata per un ”backfill” alle memorie più piccole attraverso il trasferimento di pagine di dati. Questo metodo può risultare inefficiente se viene utilizzata solo una piccola parte delle pagine. Il program- matore deve occuparsi degli schemi di accesso alle memorie e strutturare la memorizzazione dei dati. 1.2.4 Macchine UMA (Uniform Memory Access) Si tratta tipicamente di multiprocessori simmetrici (SMP), con strutture di interconnessione a bassa latenza ed elevato grado di interconnessione ( Figu- ra 1.13). La memoria è uniformemente condivisa da tutti i processori, i quali 18
  • 25. 1.2 Architetture multiprocessore impiegano tutti lo stesso tempo per accedervi. La rete di interconnessione può essere bus comune o crossbar switch. La sincronizzazione tra i processo- ri avviene mediante variabili condivise nella memoria comune. L’accesso ai dispositivi di I/O può essere simmetrico, dove ogni processore è in grado di eseguire le parti di sistema operativo relative all’I/O, o asimmetrico, dove al- cuni processori (master) possono eseguire le chiamate di sistema dell’I/O e gli altri processori (slave) fanno richiesta ai primi. Solo attraverso ottimizzazioni è possibile ridurre l’occupazione di memoria di uno o più ordini di grandezza rispetto al valore numericamente uguale alla performance. Figura 1.13: Modello UMA 1.2.5 Macchine NUMA (Non Uniform Memory Access) Ogni processore ha la propria memoria locale, ma può accedere anche a quel- la di un altro processore passando attraverso la rete di interconnessione con tempi di accesso ovviamente più lunghi. Queste macchine (Figura 1.14) sono idealmente adatte anche ad applicazioni irregolari, con alto grado di località degli accessi, che utilizzano paradigmi di parallelizzazione control parallel e data parallel e che operano anche su grandi insiemi di dati (basi di dati tradi- zionali o intelligenti). L’architettura NUMA fornisce ad ogni processore una piccola zona di memoria ad accesso esclusivo e veloce in modo da evitare la creazione di colli di bottiglia. Nel caso di applicazioni che richiedono la condi- visione di dati come nel caso di server e simili l’architettura NUMA migliora 19
  • 26. 1.2 Architetture multiprocessore le prestazioni se si suddivide la memoria centrale in diversi banchi e si as- segna ad ogni banco un numero ridotto di processori. Naturalmente i dati non sono realmente separati nelle memorie dei singoli processori e se dei dati devono essere elaborati da più processori questo è possibile. In questo caso l’architettura NUMA prevede che il software o dei dispositivi hardware prov- vedano a spostare i dati da un banco a un altro. Questa copia dei dati rallenta i processori e quindi l’efficienza delle architetture NUMA dipende molto dai compiti svolti dal sistema. Figura 1.14: Modello NUMA 1.2.6 Alcuni metodi di interconnessione di un sistema distri- buito La differenza principale tra le architetture MIMD (indistintamente dal ti- po di modello di memoria utilizzato) consiste nella modalità di scambio dei dati. Infatti, in N macchine a processore singolo (non importa se MIMD o SI- MD) lo scambio di dati, informazioni e segnali può avvenire in due modalità differenti: • adottando variabili condivise su memoria condivisa • adottando scambio di messaggi su reti di interconnessione Le topologie principali delle reti di interconnessione possono essere raggrup- pate come di seguito illustrato: 20
  • 27. 1.2 Architetture multiprocessore • Bus unico condiviso: nella topologia a bus (Figura 1.15) tutti i proces- sori sono connessi tra loro in modo lineare, tali da formare una sequen- za. Le estremità di un bus non sono collegate tra loro, ma devono essere sempre terminate, altrimenti i segnali che raggiungono la fine del cavo possono fare un eco indietro, disturbando la trasmissione. Nelle reti con topologia a bus viene di solito utilizzata la trasmissione a ”commutazio- ne di pacchetto”. Un elemento che vuole trasmettere delle informazioni divide il messaggio in tanti piccoli pacchetti e li invia uno alla volta. La topologia a bus è usata spesso con la cablatura in cavo coassiale. Un grosso limite è dato dal fatto che un’interruzione del cavo interrompe la trasmissione in ogni direzione. Poiché tutti i computer connessi condivi- dono lo stesso mezzo trasmissivo, essi utilizzano dei protocolli che garan- tiscono che in ogni istante un solo elemento stia trasmettendo. Un caso particolare della topologia a bus è quella ad anello dove le due estremità sono unite tra loro a formare un anello. In questa topologia le informa- zioni viaggiano in una sola direzione. I dati, organizzati in pacchetti ognuno dei quali contiene l’indirizzo di destinazione, girano all’interno di questo anello fino a raggiungere il computer di destinazione. Figura 1.15: Bus • Connessione a stella: nella topologia a stella (Figura 1.16) tutti i com- puter sono connessi ad un nodo centrale che può essere un semplice ripetitore (hub) o un dispositivo intelligente (switch o router). Nelle reti con topologia a stella i pacchetti che vengono inviati da un nodo ad un altro sono ripetuti su tutte le porte dell’hub. Questo permette a tutti i 21
  • 28. 1.2 Architetture multiprocessore nodi di vedere qualsiasi pacchetto inviato sulla rete, ma solo il nodo a cui il pacchetto è indirizzato lo copierà sul proprio hard disk. Uno dei van- taggi è dato dal fatto che se vi è un’interruzione su una delle connessioni della rete solo il nodo collegato a quel segmento ne risentirà, mentre tut- ti gli altri continueranno ad operare normalmente. Uno svantaggio è il costo aggiuntivo imposto dall’acquisto di uno o più hub. Di solito questa spesa è compensata dalla più facile installazione e dalla economicità del cablaggio in twisted pair rispetto al cavo coassiale. Figura 1.16: Stella • Ipercubo: questa topologia (Figura 1.17) consiste di 2k nodi organizzati come un ipercubo di dimensione k. I nodi sono numerati da 0 a 2k − 1 e due nodi sono connessi solo se la loro rappresentazione binaria differisce solo per un bit. Figura 1.17: Ipercubo • Crossbar switch: i processori e le memorie formano i due lati della rete di interconnessione come si vede dalla Figura 1.18: coppie distinte 22
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 1.3 Grid La maturità (2003-2006) Nel successivo Sesto Programma Quadro (FP6) della Comunità Europea le Grid ottennero un posto di primo piano. Ottenne il via libera anche il nuovo progetto Europeo EGEE 1 . Il progetto partì il 1 aprile 2004, con durata di 2 anni, e realizzò la prima Grid euro- pea per la scienza, aperta all’industria al commercio e alle piccole e medie imprese. EGEE è l’acronimo di Enabling Grids for E-sciencE e può essere considerato il successore di DataGrid e DataTAG. La costruzione della prima Grid Europea di produzione da parte di EGEE è stata un’impresa storica, coordinata dal CERN di Ginevra, a cui partecipa- no più di 70 Enti e Istituzioni scientifiche appartenenti a 26 Paesi Europei organizzati in 9 grandi Federazioni. Questa struttura deve fornire le risorse di calcolo e storage, le applicazioni, i servizi operativi e di gestione necessari per far funzionare questa grande infrastruttura. Un sistema di ”accounting” tiene conto dell’uso delle risorse mentre un robusto e sicuro sistema d’au- tenticazione e autorizzazione garantisce ad un numero sempre più vasto d’u- tenti (dell’ordine di decine di migliaia) appartenenti a varie organizzazioni e comunità scientifiche, la sicurezza e la riservatezza necessaria. EGEE ha sviluppato anche un middleware Grid Open Source robusto ed affidabile, costruito con stretti criteri d’ingegneria del software e in grado di durare nel tempo. Questo è andato a sostituire quello esistente facendo passare definitivamente l’Europa dalla fase di ”sperimentazione” a quella di ”produzione”. Oggi EGEE rappresenta una grande sfida vinta dalla comunità scienti- fica europea chiamata ad organizzarsi in tempi brevi in un grande progetto competitivo a livello mondiale. EGEE integra tutte le esistenti infrastrut- ture Grid nazionali con le loro strutture tecniche e operative in una grande 1 Come vedremo meglio in seguito è stato finanziato EGEE 2 (all’interno del quale Perugia è presente tra le attività unfunded di NA4). É in fase di presentazione la domanda per il finanziamento di EGEE 3 all’interno del quale è previsto un piccolo finanziamento per Perugia. 29
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. Capitolo 2 La Grid di produzione di EGEE A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities. - Carl Kesselman and Ian Foster - 2.1 Introduzione Il progetto europeo EGEE (Enabling Grids for E-sciencE) mira ad integrare le piattaforme Grid già esistenti per creare un’unica infrastruttura di calcolo per il supporto alla ricerca 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
  • 41. 2.2 L’articolazione che per la maggior parte provengono dalla Comunità Europea ma anche da altri paesi non comunitari. 2.2 L’articolazione Tutte le discipline scientifiche che hanno bisogno di risorse computaziona- li avanzate possono beneficiare dal progetto EGEE. Due applicazioni pilota sono state scelte per guidare l’implementazione iniziale e certificare le pre- stazioni e le funzionalità della infrastruttura Grid in evoluzione. La prima è la già citata LHC, che necessita di un’infrastruttura in grado di archiviare ed analizzare petabyte di dati provenienti dagli esperimenti della fisica del- le alte energie al CERN. L’altra è la Biomedical Grid, all’interno della quale molte comunità stanno affrontando sfide molto ardue, quali il datamining su database genomici e l’indicizzazione di database medici negli ospedali, che ammontano a molti terabyte di dati per ospedale all’anno. In totale sono state coinvolte 71 organizzazioni di 27 paesi differenti, che sono organizzate in Grid regionali, con una capacità stimata di oltre 20.000 CPU: la più grande struttura Grid internazionale mai sviluppata. L’obiettivo preposto è quello di avere 3000 utenti attivi nell’infrastruttura provenienti da almeno 5 settori scientifici diversi entro la fine del secondo anno di atti- vità; la fase successiva del progetto prevede lo sfruttamento di tale risorsa anche in ambito Geofisico, Nanotecnologico e dei Modelli climatici, e quindi un incremento esponenziale di risorse ed utenti. La ricerca all’interno del progetto EGEE è organizzata in 11 attività diver- se, ognuna delle quali si occupa di uno dei campi di realizzazione ed utilizzo della Grid. Queste attività sono a loro volta raggruppate in tre diversi settori • EGEE Networking Activities (NA) • EGEE Specific Service Activities (SA) • EGEE Joint Research Activities (JRA) 35
  • 42. 2.2 L’articolazione che verranno illustrati di seguito: EGEE Networking Activities (NA) Questo settore si occupa di tutti gli aspetti organizzativi necessari al coordi- namento del progetto e al rapporto con i partner e di promuovere un’adegua- ta campagna di informazione per focalizzare sul progetto l’attenzione di enti, industrie, università e governi. All’interno di questa sezione sono presenti cinque diverse attività: NA1 - Project Management: ha lo scopo di gestire l’intera struttura orga- nizzativa, coordinare i lavori, presentare dei rapporti in collaborazione con l’attività che si occupa della QoS (Quality of Service), sviluppare una licenza Open Source per il software prodotto all’interno del progetto ed istruire lo staff del progetto; NA2 - Dissemination and Outreach: il leader di questa attività è il con- sorzio TERENA. Lo scopo di questa attività è diffondere le idee del progetto, attirare nuovi partner dalla comunità scientifica e dall’indu- stria. Questo gruppo ha inoltre il compito di organizzare due conferenze all’anno sul progetto; NA3 - User Traning and Induction: molto importante per la riuscita del progetto è un programma di formazione aggiornato ed accessibile, tenu- to da un gruppo di docenti di elevatissima qualità ed esperienza. Più di 22 paesi partecipano a questa attività ed è stato istituito un programma di formazione all’utilizzo dei portali e dei tool di installazione; NA4 - Application Identification and Support: questa attività si occupa di curare l’ingresso di nuovi utenti ed organizzazioni e di fornire assi- stenza per l’installazione di nuovi nodi Grid. Il ruolo di questo gruppo è fondamentale al fine di incrementare i settori applicativi in cui viene sperimentata l’infrastruttura Grid e ne viene dimostrata l’importanza. 36
  • 43. 2.2 L’articolazione Infatti al crescere del numero delle applicazioni che vengono eseguite con successo nella Grid, aumenta l’importanza di EGEE e della Grid stessa; NA5 - Policy and International Cooperation: l’obiettivo è di permettere al progetto EGEE di partecipare allo sviluppo di una Grid globale e di assicurarsi che il progetto collabori con le maggiori iniziative Grid di tut- to il mondo. NA5 è attualmente collegato con le principali iniziative Grid europee: DEISA (Distributed European Infrastructure for Supercompu- ting Applications), SEE-GRID (South Eastern European Grid-enabled eInfrastructure Development), DILIGENT (Testbed Digital Library In- frastructure on Grid Enabled Technology) e GRIDcc (Grid Enabled Re- mote Instrumentation with Distributed Control and Computation). Inol- tre sono stati stabiliti collegamenti anche con altre iniziative extraeu- ropee, tra le quali la ”US NFS Cyberinfrastructure initiative” e l’EGEE Project Management Board (PMB) in collaborazione con Stati Uniti e Russia. EGEE Specific Service Activities (SA) Quest’area si occupa di sviluppare, migliorare e mantenere aggiornato il soft- ware che costituisce il middleware sul quale si basa la Grid e quindi dello sviluppo della Grid stessa. Due attività compongono questa area: SA1 - Grid Support Operation and Management: questa attività ha lo sco- po di gestire l’operatività dell’infrastruttura Grid e di fornire il supporto necessario ai gestori delle varie componenti della Grid al fine di garan- tire un’erogazione dei servizi affidabile e stabile nel tempo. Le funzioni chiave sono la creazione dei servizi, il monitoraggio e il controllo della Grid, lo sviluppo del middleware ed il supporto agli utenti; SA2 - Network Resource Provision: questa attività si occupa di monito- 37
  • 44. 2.2 L’articolazione rare e controllare la fornitura in rete dei servizi Grid, in particolare di individuare e correggere tutti quei problemi, soprattutto inerenti alla rete, che possono compromettere la fruibilità del servizio. EGEE Joint Research Activities (JRA) L’ultima area del progetto si occupa delle attività di sviluppo, ricerca e verifica delle nuove soluzioni per il miglioramento dei servizi offerti agli utenti. JRA è divisa in quattro diverse attività: JRA1 - Middleware Re-Engineering and Integration: l’obiettivo è quel- lo di fornire componenti software di middleware robusti, eseguibili su diverse piattaforme e sistemi operativi, in modo che il software EGEE sia soggetto ad un processo evolutivo continuo e possa essere integrato e diffuso nei nuovi siti che si aggiungono alla Grid; JRA2 - Quality Assurance: questa attività è volta alla certificazione della qualità di tutte le componenti di EGEE. Oltre a monitorare il livello di qualità offerto dai vari servizi di EGEE, è stato previsto un rapporto sulla qualità del progetto alla fine del biennio di attività; JRA3 - Security: lo scopo di questa attività è quello di gestire, implemen- tare e monitorare l’architettura inerente alla sicurezza del progetto. L’affidabilità di tutto il prgetto EGEE dipende dal livello di sicurezza implementato e dal fatto che tutti si attengano ai criteri dettati da JRA3; JRA4 - Network Services Development: una parte dell’attività è stata in- dirizzata a garantire la connettività della rete, specificata in termini di banda, durata e QoS; inoltre il team si occupa di monitorare la perfor- mance della rete e per fare ciò ha sviluppato un’interfaccia implementa- ta attraverso i web service che permette a tutti i siti e ai domini di rete di inviare informazioni per poter così bilanciare efficientemente il traf- 38
  • 45. 2.3 Virtual Organization in EGEE fico di rete. L’altro obiettivo del team è quello di facilitare l’introduzione del protocolli IPv6. 2.3 Virtual Organization in EGEE Un elemento fondamentale per il corretto funzionamento della Grid e dei suoi servizi è la gestione delle risorse e degli utenti. Si devono cioè definire delle regole per gestire l’accesso alle risorse da parte degli utenti. Un insieme di individui e/o istituzioni che condivide le stesse regole di accesso costituisce una Virtual Organization (VO). All’interno di una infrastruttura Grid vengono definite diverse Virtual Or- ganization e un utente può appartenere ad una o più di esse ed accedere co- sì alle risorse condivise; chi fornisce le risorse, a sua volta, specifica quali Virtual Organization vi possono accedere e con quali criteri. Un utente, quindi, può accedere alla Grid solo se autorizzato da una VO e può utilizzare solo le risorse a disposizione di quella VO; la gestione degli utenti viene effettuata dalle singole VO in modo da gestire la grande quantità di utenti e risorse di una Grid con dei meccanismi poco costosi e molto rigorosi. Un ulteriore beneficio derivante dalla classificazione in VO è la semplifi- cazione della struttura della Grid fornita all’utente; attraverso le Virtual Or- ganization, infatti, un utente ha una visione semplificata della Grid, limitata alle sole risorse alle quali ha accesso. Le VO attive all’interno del progetto EGEE sono attualmente 23: ATLAS, ALICE, CMS, LHCB, DTEAM, SIXT, BIO, ENEA, INAF, PLANCK, BIOMED, ESR, INFNGRID, THEOPHYS, CDF, GILDA, INGV, VIRGO, BA- BAR, COMPCHEM, GRIDIT, MAGIC, ZEUS. In questa tesi faremo riferimento alla VO COMPCHEM che è supportata dal nodo di UNI-PERUGIA. L’ingresso di nuovi nodi Grid nel progetto avviene attraverso una procedu- ra di affiliazione ad una delle VO esistenti che si pone tra l’organizzazione che 39
  • 46. 2.3 Virtual Organization in EGEE vuole entrare a far parte di EGEE e la Certification Authority (CA) centrale dell’INFN la quale si occupa di ricevere le richieste di emissione di certificati da distribuire agli utenti e agli amministratori dei nodi. Un altro dei compiti affidati alle VO è quello di fornire supporto tecnico per l’installazione e la configurazione dei nuovi nodi Grid e per l’aggiornamento del software dei nodi già esistenti. All’interno di ogni VO, viene definito almeno un sito di riferimento che permette di fornire servizi di autenticazione e catalogazione delle risorse a disposizione degli utenti della Grid per la sottomissione e la gestione di job (il nodo UNI-PERUGIA è il sito di riferimento per COMPCHEM). Questi servizi vengono resi disponibili attraverso i nodi Resource Broker e Logging Server. Il Logging Server viene impiegato per registrare tutte le richieste effet- tuate dagli utenti. Il Resource Broker invece deve trovare quale tra tutte le risorse disponibili risulta migliore per lo svolgimento de job. Per esempio, se un job necessita di un particolare software, il Resource Broker deve scegliere il miglior sito che soddisfi questa richiesta. Per far ciò, un Resource Broker contatta un ”Resource Catalog” che centralizza tutte le risorse disponibili. 2.3.1 Virtual Organization Membership Server Il Virtual Organization Membership Server (VOMS) è un database di utenti che sono autorizzati ad utilizzare le risorse della VO. Il server è utilizzato per due scopi principali; il primo è quello di ottenere informazioni sulle risorse a disposizione della VO, tramite la lista degli utenti; il secondo è quello di fornire agli utenti le credenziali da utilizzare per ottene- re l’accesso alle risorse. In questo modo, dopo una prima comunicazione, non ne sono necessarie altre tra il servizio VOMS e il sito. Questo tipo di servizio tenta di soddisfare sia i requisiti di sicurezza del sistema che la semplice e veloce fruibilità delle risorse. Attraverso il VOMS, infatti, ogni utente crea un proxy di durata prefissata che gli permette di 40
  • 47. 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
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. Capitolo 3 Il portale web The sharing that we are concerned with is not primarily file exchange but rather direct access to computers, software, data, and other resources, as is required by a range of collaborative problemsolving and resource-brokering strategies emerging in industry, science, and engineering. This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization. - Carl Kesselman, Ian Foster and Steve Tuecke - 3.1 Introduzione Come già detto le griglie computazionali nascono per venire incontro alle esi- genze delle organizzazioni virtuali che per le loro attività di ricerca e sviluppo di conoscenza, necessitano di condividere risorse e dati attraverso regole ben determinate. Tale condivisione è dinamica in quanto le organizzazioni virtua- li non sono insiemi statici definiti a priori, ma possono modificare nel corso del tempo le proprie necessità, avere bisogno di nuovi o particolari servizi, abili- tare l’uso di questi servizi a nuovi utenti o escluderne degli altri. Una VO è caratterizzata dal corpo di laboratori che ne fanno parte (membri) e dalle sue politiche di accesso e utilizzo dei servizi e delle risorse condivise. La base di questo meccanismo è la forte collaborazione che si instaura tra i laboratori membri di una data VO. I vari laboratori mettono a disposizione 45
  • 52. 3.2 La sostenibilità di una Organizzazione Virtuale della griglia computazionale un insieme di risorse locali che vanno a far parte di un pool di risorse computazionali distribuite e condivise tra tutti gli utenti. La VO è gestita da un comitato (Management Committee o MC) in cui i vari livelli di appartenenza alla VO sono rappresentati. Inoltre ogni laboratorio agisce sia da client che da server (così come avviene nella tecnologia peer to peer). All’interno di queste comunità vengono sviluppati e sperimentati programmi e software che in seguito vengono condivisi attraverso la griglia garantendone crescita e lo sviluppo. Da ciò si evince che la sostenibilità è la chiave per la crescita di una VO. 3.2 La sostenibilità di una Organizzazione Virtuale Il fattore fondamentale per l’affermarsi di una organizzazione virtuale è la sua sostenibilità [20]. Per questo scopo ogni organizzazione virtuale deve of- frire ai suoi membri con meccanismi cristallini e oggettivi vantaggi tangibili come ad esempio la possibilità di svolgere estese campagne di calcolo (spe- cialmente quando sono così complesse da non essere realizzabili utilizzando piattaforme di calcolo locali, seriali o parallele che siano) che li ricompensi per il lavoro fatto per la comunità. Solo in questo modo i laboratori si assumeran- no l’onere di portare avanti il lavoro supplementare ancora oggi richiesto dal fatto di operare in Grid su base collaborativa. Ad ogni membro che non sia il semplice utente esterno viene infatti richiesto di implementare sull’ambiente distribuito della VO almeno un codice sia pure per mero uso personale. Più spesso viene anche richiesta la condivisione di risorse con gli altri laboratori. I laboratori in questo modo vengono proiettati verso il concetto di cooperazio- ne tramite la partecipazione attiva all’infrastruttura Grid. In cambio ciascun utente ha la possibilità di avvalersi del ”know-how” degli altri utenti della VO. L’appartenenza ad una VO può pertanto avvenire a livelli di partecipazione diversa. In COMPCHEM il livello di ingresso è quello di utente che compor- ta l’utilizzo sulla griglia di produzione della VO di un programma. L’adesione 46
  • 53. 3.2 La sostenibilità di una Organizzazione Virtuale può essere di tipo passivo se il programma utilizzato è uno di quelli imple- mentati dalla VO (o da uno dei suoi membri) o di tipo attivo se il programma utilizzato è stato implementato dall’utente. Tale livello ha una durata li- mitata in forma gratuita (che può essere diversa per il tipo passivo e attivo) negoziata con l’MC. Una volta concluso il periodo di durata limitata, esso può essere esteso successivamente in forma onerosa. COMPCHEM incoraggia pe- rò l’utente a passare a livello successivo di laboratorio membro conferendo o dei programmi (Software Provider o SP) o dei computer (Grid Deployer o GP) alla VO e alla infrastruttura Grid da essa utilizzata. Ambedue queste modalità possono essere sia attive che passive. Per un laboratorio membro di una VO il requisito necessario è quello di rendere disponibile per l’uso da parte di altri uno dei propri programmi imple- mentati sulla Grid per un uso condiviso tra tutti gli altri membri. Ciò implica la validazione di una versione stabile del codice e l’assemblaggio di tutte le interfacce necessarie al suo utilizzo. Inoltre devono essere resi noti i servizi di manutenzione del software e l’assistenza agli utenti. Tale modalità viene detta passiva. Viene detta attiva, invece, la modalità in cui il membro rende il proprio software integrabile con altri programmi contribuendo al suo uso coordinato nell’ambito di un workflow più complesso o di un sistema esper- to. Per quanto riguarda il laboratorio membro di una VO come GD di tipo passivo, il requisito necessario è quello di inserire nella infrastruttura Grid della VO un cluster di computer o processori occupandosi della sua gestione. L’equivalente di tipo attivo è invece coinvolto nella vera e propria gestione (ed eventuale sviluppo) della infrastruttura Grid. Ad ogni buon conto il contri- buto di maggior valore per la sostenibilità di una VO è rappresentato dalla capacità dei suoi membri di innovare, fare ricerca e sviluppo. Esiste poi un livello superiore di coinvolgimento detto azionista o stake-holder che riguarda la gestione di sistemi software e hardware. A questo livello appartengono quei laboratori che dedicano a tale attività una quantità di tempo e di competenze 47
  • 54. 3.3 Il sistema di crediti importanti. 3.3 Il sistema di crediti Per quanto appena detto, la VO necessita di un meccanismo di gratificazione dei propri membri attivi per il lavoro svolto. A tale scopo è stato sviluppato un sistema di assegnazione di crediti che premia le attività portate avan- ti a favore della VO (anche se di pura ricerca). I crediti possono essere ri- scattati acquistando servizi dalla stessa VO oppure scambiandoli con risorse finanziarie. Per questo è importante che una VO reperisca risorse finanziarie parte- cipando a progetti e prestando servizi a terzi dietro compenso. Tali risorse finanziarie vengono abitualmente indicate con la sigla SFR (Spinoff Finan- cial Resources). Le risorse così reperite, una volta detratte le spese vive di gestione della VO, verranno destinate per una certa frazione alla ricerca e distribuite secondo una graduatoria di merito scientifico stabilita secondo un criterio di peer rewiew esterno che misuri la produttività scientifica sulla base dei ”report” interni e articoli pubblicati su riviste scientifiche internazionali. In ogni caso vengono anche valutati i contributi scientifici contenuti nei report sui servizi. I relativi report devono infatti sempre contenere una descrizione dettagliata dello svolgimento dell’attività di ricerca. Questo è dato dal fatto che COMPCHEM considera attività ricerca e sviluppo come una risorsa in sé indipendentemente dai risultati ottenuti nel breve periodo e per questa ra- gione la VO è considerata anche come un’area di libera circolazione di idee e produzione di innovazione da supportare finanziariamente. La parte restante verrà suddivisa per una percentuale decisa dall’MC ai membri azionisti e la parte restante messa a disposizione per essere scambiata con i crediti. I crediti vengono maturati come ricompensa per i servizi realizzati da membri della VO. Tali servizi sono classificati come interni, esterni e spe- ciali. Il servizio interno principale che deve essere garantito dai laboratori 48
  • 55. 3.3 Il sistema di crediti membri riguarda il funzionamento efficiente di tutte le risorse hardware e software della comunità virtuale. Impegni presi dai laboratori della VO per l’espletamento di progetti o servizi commerciali sono altresì considerati servi- zi interni, così come quelli orientati alla gestione delle infrastrutture e delle attività della comunità virtuale, alla creazione di nuove attività e allo svolgi- mento di quelle esistenti. I servizi esterni sono quelli forniti da un laboratorio membro della VO direttamente a terzi. Infine i servizi speciali sono quelli re- lativi alla vendita dei prodotti sviluppati all’interno della comunità virtuale a terzi. Al fine di dare una base quantitativa e un criterio imparziale per la di- stribuzione degli SFR è stato sviluppato l’algoritmo secondo l’equazione 3.1 che viene descritto in dettaglio nel riferimento [19]. L’assegnamento dei cre- diti è semplice e diretto per il conferimento di risorse hardware e software e quindi valutare gli utilizzi, le performance ed i parametri statistici diventa automatico in un ambiente Grid. Dunque l’assegnamento dei crediti ai la- boratori dipende direttamente dall’identificazione e quantificazione dei costi riscontrati, l’utilità dei servizi forniti e i profitti generati da progetti e/o atti- vità all’interno della VO. Questi criteri sono incorporati nell’indice Ξl (fattore di scambio [20]): Nα Ξl = αT αT ωs (Tsl ) + αI αI ωi Iil + αC αC ωk Ckl (3.1) s Tsl + ζ i k dove l, s, i e k sono gli indici che identificano rispettivamente il laboratorio, il servizio, il profitto e il costo mentre Tsl , Iil e Ckl sono il tempo di calcolo associato al servizio fornito dal laboratorio l, il profitto generato dall’attività commerciale o dal progetto i relativo al laboratorio l ed il costo k incontrato (o il valore delle risorse conferite) dal laboratorio l, rispettivamente. Nel primo termine dell’equazione N indica il numero di accessi al servizio, ζ un fattore di scalaggio e Tsl il tempo totale di utilizzo del servizio da parte di tutti i labo- 49
  • 56. 3.4 L’ambiente web ratori partner della VO. In questo modo si vuole assegnare maggiore impor- tanza ai servizi che lavorano in un tempo di calcolo medio-basso assegnando loro più credito rispetto a quelli che lavorano in un tempo di calcolo elevato. I termini α rappresentano i pesi che vengono dati ai termini delle sommato- rie cui appartengono (servizi, profitti o costi) ed identificano l’importanza che l’MC della VO assegna a ciascuna sezione. I termini α rappresentano i coef- ficienti di conversione che prendono in considerazione le differenti unità di misura utilizzate. Naturalmente per fare in modo che il peso sia consistente la somma dei tre coefficienti α deve essere uguale ad 1 e la scelta dei valori da assegnare ad alcuni pesi dipende pesantemente dalle strategie scelte dal Management Committee della VO. Vale la pena a questo punto notare che per il lavoro di tesi si è semplificato il problema considerando i vari tipi di ser- vizio tutti alla stessa stregua riservandoci di implementare successivamente la differenziazione discussa in precedenza. Anche gli ω sono dei pesi fissati dall’MC per determinare il valore di un certo servizio che potrebbe, ad esem- pio, variare di anno in anno. Come dettagliato nel riferimento [19] l’algoritmo corrispondente all’equazione 3.1 è stato dapprima implementato utilizzando il linguaggio C++. 3.4 L’ambiente web Per la gestione del sistema di crediti per la griglia è stata sviluppata una interfaccia web. Questa scelta presenta dei vantaggi per tutti coloro che par- tecipano alla Grid. Prima di tutto un’applicazione web è indipendente dal sistema operativo utilizzato dall’utente. L’utente, inoltre, è in grado di visua- lizzare gli aggiornamenti che avvengono sulla griglia in qualunque momen- to. Un altro vantaggio è rappresentato dalla semplicità di realizzazione di un’interfaccia grafica. Per queste ragioni abbiamo creato un ”cross-bar site” sfruttando una tecnologia serverside. Il relativo ambiente web (Figura 3.1) è stato implementato usando i seguenti elementi: 50
  • 57. 3.4 L’ambiente web 1. Un web server dinamico, basato sul server web Apache [21] con i moduli PHP5 [22]. 2. Un DBMS (MySQL [23] nel nostro caso) per la memorizzazione dei dati e il supporto alla fase di autenticazione. Il portale è stato sviluppato e testato usando software GPL e free. In particolare è stato utilizzato Apache 2.2.3 e MySQL 5.0.27 contenuti nel tool EasyPHP 2.0b1. Figura 3.1: L’ambiente web PHP PHP è un linguaggio di scripting interpretato, con licenza open source, ori- ginariamente concepito per la realizzazione di pagine web dinamiche. At- tualmente è utilizzato per sviluppare applicazioni web lato server, ma può essere sfruttato anche per scrivere applicazioni stand alone (oggetto capace di funzionare da solo, indipendentemente dalla presenza di altri oggetti con cui potrebbe comunque interagire) con interfaccia grafica. L’obiettivo fin dall’inizio era quello di sviluppare un’interfaccia con le ca- ratteristiche di un portale web in cui fosse possibile compiere operazioni in maniera semplice, ma soprattutto dinamica: è per questo che la scelta è caduta su questo linguaggio. 51
  • 58. 3.4 L’ambiente web Il suo nome è un acronimo che sta per Hypertext Preprocessor (prepro- cessore di ipertesti) ed è nato nel 1994 ad opera del danese Rasmus Lerdorf. PHP era in origine una raccolta di script CGI (Common Gateway Interface), tecnologia standard usata dai web server per interfacciarsi con applicazioni esterne. Il pacchetto originario venne in seguito esteso e riscritto dallo stesso Lerdorf in linguaggio C, aggiungendo funzionalità quali il supporto al databa- se mSQL e divenne PHP/FI, dove FI sta per Form Interpreter (interprete di form), prevedendo la possibilità di integrare il codice PHP nel codice HTML in modo da semplificare la realizzazione di pagine dinamiche. A questo pun- to il linguaggio cominciò a godere di una certa popolarità tra i progetti open source del web e venne così notato da due giovani programmatori: Zeev Su- raski e Andi Gutmans. I due collaborarono nel 1998 con Lerdorf allo sviluppo della terza versione di PHP (il cui acronimo assunse il significato attuale), riscrivendone il motore che fu battezzato Zend da una contrazione dei loro nomi. Le caratteristiche chiave della versione PHP 3.0 erano la straordinaria estensibilità, la connettività ai database e il supporto iniziale per il paradig- ma a oggetti. Verso la fine del 1998 PHP 3.0 era installato su circa il 10% dei web server presenti su Internet. PHP diventò a questo punto talmente maturo da competere con ASP, linguaggio lato server analogo a PHP svilup- pato da Microsoft, cominciando ad essere usato su larga scala. La versione 4 di PHP venne rilasciata nel 2000 e prevedeva notevoli migliorie. Attualmen- te siamo alla quinta versione, sviluppata da un team di programmatori, che comprende ancora Lerdorf, oltre a Suraski e Gutmans. La popolarità del linguaggio PHP è in costante crescita grazie alla sua semplicità: nel Giugno 2001, ha superato il milione di siti che lo utilizzano. Nell’ottobre 2002, più del 45% dei server Apache usavano PHP. Nel gennaio 2005 è stato insignito del titolo di ”Programming Language of 2004” dal TIO- BE Programming Community Index, classifica che valuta la popolarità dei linguaggi di programmazione sulla base di informazioni raccolte dai motori 52
  • 59. 3.4 L’ambiente web di ricerca. Nel 2005 la configurazione LAMP (Linux, Apache, MySQL, PHP) superava il 50% del totale dei server sulla rete mondiale. PHP riprende per molti versi la sintassi del C, come peraltro fanno molti linguaggi moderni, ed è per questo motivo che non è stato complicato tradurre l’algoritmo da una codifica in C++ ad una in PHP. PHP è in grado di inter- facciarsi ad innumerevoli database tra i quali MySQL, PostgresSQL, Oracle, Firebird, IBM DB2 e Microsoft SQL Server e supporta numerose tecnologie, come XML, SOAP, IMAP, FTP, CORBA. Esso si integra anche con altri lin- guaggi/piattaforme (quali Java e .NET) e fornisce un’API specifica per intera- gire con Apache, nonostante funzioni naturalmente con numerosi web server. PHP è ottimamente integrato con il database MySQL per il quale possiede più di una API. Per questo motivo esiste un’enorme quantità di script e librerie in PHP disponibili liberamente su Internet. MySQL Come precedentemente accennato, per la memorizzazione dei dati è stato uti- lizzato un database da cui l’algoritmo potesse attingere direttamente. Per manipolare la collezione di dati ci siamo serviti di un DBMS (Database Mana- gement System), un sistema software progettato per consentire la creazione e manipolazione efficiente di database da parte di più utenti. I DBMS svolgono un ruolo fondamentale in numerose applicazioni informatiche, dalla contabi- lità alla gestione delle risorse umane e la finanza, fino a contesti tecnici come la gestione di reti o la telefonia. Se in passato i DBMS erano diffusi princi- palmente presso le grandi aziende e istituzioni, oggi il loro utilizzo è diffuso praticamente in ogni contesto. Un esempio di DBMS è MySQL. MySQL è un DBMS relazionale composto da un client con interfaccia a caratteri e un server, entrambi disponibili sia per sistemi Unix che per Win- dows, anche se prevale un suo utilizzo in ambito Unix. Dal 1996 supporta la maggior parte della sintassi SQL e si prevede in futuro il pieno rispetto del- 53
  • 60. 3.5 Il database Crediti lo standard ANSI. Possiede delle interfacce per diversi linguaggi, compreso un driver ODBC, due driver Java e un driver per Mono e .NET. Il codice di MySQL viene sviluppato fin dal 1979 dalla ditta TcX ataconsult (adesso My- SQL AB) ma è solo dal 1996 che viene distribuita una versione che supporta SQL, utilizzando in parte codice di un altro prodotto: mSQL. Il codice di My- SQL è di proprietà della omonima società ma viene distribuito con la licenza GNU GPL oltre che con una licenza commerciale. Buona parte del codice del client è licenziato con la GNU LGPL e può dunque essere utilizzato per ap- plicazioni commerciali. MySQL svolge il compito di DBMS nella piattaforma LAMP, una delle più usate e installate su Internet per lo sviluppo di siti e applicazioni web dinamiche. Esistono diversi tipi di MySQL Manager, ovvero di strumenti per l’am- ministrazione di MySQL. Quello utilizzato nell’implementazione del portale, uno dei programmi più popolari per amministrare i database MySQL, è php- MyAdmin. Questo tool richiede un web server come Apache_HTTP_Server ed il supporto del linguaggio PHP. Si può utilizzare facilmente tramite un qual- siasi browser. La versione di phpMyAdmin utilizzata è la 2.9.1.1 mentre la versione di Apache è la 2.2.3 e quella di PHP è la 5.2.0. 3.5 Il database Crediti Vista la grande mole di informazioni da memorizzare è stato implementato un database SQL. Il database che abbiamo realizzato è costituito da 10 tabelle come mostrato in (Figura 3.2): • amministratore: contiene le informazioni relative ad ogni amministra- tore di una organizzazione virtuale; • superuser: contiene le informazioni relative ad ogni amministratore di un laboratorio appartenente ad una organizzazione virtuale; 54
  • 61. 3.5 Il database Crediti • vo: tabella utilizzata per memorizzare i nomi delle organizzazioni vir- tuali; • laboratorio: tabella utilizzata per memorizzare i nomi dei laboratori appartenenti ad una organizzazione virtuale; • credito: contiene le informazioni relative al credito assegnato ad un laboratorio; • costo: contiene le informazioni relative ai costi incontrati da un labora- torio; • prog_att: contiene le informazioni relative ai profitti generati da un laboratorio; • servizio: contiene le informazioni relative ai servizi offerti da un labo- ratorio; • data: tabella utilizzata per tenere traccia degli accessi degli utenti al portale; • voto: tabella utilizzata per memorizzare i voti assegnati ai servizi da parte degli utenti di una organizzazione virtuale. Il file che contiene il database è stato rinominato come crediti.sql e per le fasi di testing è stato caricato nel server localhost utilizzando phpMyAdmin versione 2.9.1.1. Nello schema mostrato in (Figura 3.2) si evince che ciascuna organizzazione virtuale può essere amministrata da un solo amministratore e ciascun laboratorio appartiene ad una sola VO mentre una VO può possedere da uno ad N laboratori. Un laboratorio può possedere da uno ad N utenti mentre un utente appartiene ad un solo laboratorio. 55
  • 62. 3.6 L’architettura del portale Figura 3.2: Schema E/R 3.6 L’architettura del portale Il portale è costituito da un set di pagine generate dinamicamente in base all’input (Figura 3.3). Queste pagine permettono di gestire, visualizzare e modificare i dati memorizzati nel database attraverso la GUI (Graphical User Interface). L’accesso al portale è consentito solamente a due classi di utenti: • amministratori: coloro che si occupano della gestione delle organizza- zioni virtuali; • utenti: coloro che si occupano della gestione dei laboratori appartenenti ad una organizzazione virtuale (amministratori dei laboratori). Inizialmente il portale era stato concepito per la sola amministrazione del- le VO e perciò era prevista esclusivamente la classe amministrativa. In segui- to l’utilizzo del portale è stato esteso anche agli amministratori dei laboratori. In questo modo ci siamo avvicinati fortemente alla filosofia della griglia che si basa sulla cooperazione delle organizzazioni virtuali ed in particolare sulla collaborazione tra i laboratori delle VO. 56
  • 63. 3.6 L’architettura del portale Figura 3.3: Mappa del portale La prima pagina è index.php dalla quale è possibile accedere alle varie sezioni del portale. L’accesso alle altre pagine avviene solo dopo la fase di au- tenticazione, nella quale viene richiesto l’inserimento di username e password nei rispettivi campi del form Member login. 3.6.1 Amministratore Pagina principale Se l’utente appena autenticato appartiene alla classe amministrativa avrà accesso alla propria area personale (Figura 3.4). In questa sezione sarà in grado di visualizzare le novità riguardanti l’attività della sua organizzazione virtuale (nella sezione news) che vengono visualizzate attraverso una Mes- 57
  • 64. 3.6 L’architettura del portale sage Box. Questa casella di posta in arrivo contiene i messaggi spediti dai laboratori della VO che attendono di essere validati dall’amministratore. La validazione consiste nel sottoporre, ad esempio un servizio, ad un periodo di valutazione da parte dei membri della VO durante il quale vengono comunque accumulati dei crediti derivanti dal suo utilizzo (crediti di tipo provvisorio). Sarà cura dell’amministratore decidere se validare o meno il servizio (e quin- di i crediti provvisori) e inviare la comunicazione al relativo laboratorio. I messaggi in arrivo si dividono in tre categorie: • servizi: specifica il numero dei nuovi servizi (servizi provvisori) inseriti sulla griglia dai laboratori; • costi: specifica il numero di costi sostenuti di recente dai laboratori della VO; • profitti: specifica il numero di profitti derivanti da progetti o attività che i laboratori della VO hanno generato. Ognuna di queste categorie contiene messaggi che attendono di essere vali- dati. In pratica l’amministratore ha il compito di visualizzare il contenuto di tali messaggi e decidere se validarli o meno. Naturalmente la validazione è una fase fondamentale per lo sviluppo di una VO. Come già detto, ogni vol- ta che una VO offre un nuovo servizio, incontra un costo oppure genera un profitto è necessario valutare se questi andranno ad aumentare l’efficienza della griglia. Un nuovo servizio per esempio, prima di essere validato, dovrà affrontare un periodo di prova in cui gli utenti della griglia potranno testarlo e votarne l’utilità. In base ai parametri del servizio (compreso il gradimen- to degli utenti che lo hanno utilizzato) l’amministratore deciderà se validarlo oppure no. Per un costo relativo all’acquisto di una risorsa l’amministratore dovrà prevedere quanto questo influirà sullo sviluppo e la crescita della gri- glia analogamente a quanto accade per un progetto in cui bisogna prevedere i tempi di realizzazione e quindi il profitto generato. Le decisioni di validazio- 58
  • 65. 3.6 L’architettura del portale ne saranno automaticamente comunicate ai rispettivi laboratori della VO. Da questa sezione è inoltre possibile accedere alle altre aree attraverso il menù posto nel lato sinistro della pagina. Figura 3.4: Amministrazione - area personale Laboratori In questa sezione l’amministratore può accedere ad informazioni relative ai laboratori membri della sua organizzazione virtuale. Selezionando un labo- ratorio è possibile visualizzare i servizi che esso offre, i costi che incontra e i profitti che genera. Da questa sezione è inoltre possibile eliminare un laboratorio esistente oppure aggiungerne uno nuovo. Utenti In questa sezione vengono mostrate le informazioni relative agli amministra- tori di ciascun laboratorio della VO. Attraverso il form Mostra utente è possi- 59
  • 66. 3.6 L’architettura del portale bile visualizzare gli utenti ordinandoli per cognome o laboratorio di apparte- nenza mentre il form Cerca utente per nome offre la possibilità di cercare uno specifico utente attraverso il suo nome e cognome. Crediti La sezione crediti è sicuramente la più importante (Figura 3.5). Selezionan- do un laboratorio l’amministratore è in grado di calcolare i crediti validati e provvisori. Nella form Calcola crediti convalidati viene calcolato il credito totale validato mentre nella form Calcola crediti provvisori viene calcolato il credito totale che include quello non validato. I valori verranno stampati a vi- deo attraverso una finestra di dialogo. Ogni volta che l’amministratore calcola il credito di un laboratorio aggiorna automaticamente il valore di quello vec- chio: in questo modo l’amministratore del laboratorio sarà in grado di vedere il credito effettivo solo quando verrà validato dall’amministratore della VO. Inoltre da questa sezione è possibile calcolare il crediti maturati dai singoli servizi provvisori. Statistiche Da questa speciale sezione è possibile visualizzare le statistiche relative ai servizi, profitti e costi di un laboratorio. Selezionando un laboratorio si accede in un’area in cui vengono mostrati i grafici relativi a ciascun servizio, profitto e costo. 3.6.2 Utente Pagina principale Se l’utente appena autenticato è un normale membro avrà accesso esclusi- vamente alla propria area personale (Figura 3.6). Se invece si tratta di un amministratore di laboratorio potrà visualizzare le news riguardanti l’attivi- tà dello stesso. Anche in questo caso le news vengono visualizzate attraverso 60
  • 67. 3.6 L’architettura del portale una Message Box. A differenza della parte amministrativa però qui si trova- no le informazioni relative al numero di messaggi relativi ai servizi validati o meno dall’amministratore della VO per: • servizi • costi • profitti Nella stessa sezione si trovano anche le informazioni sul numero dei nuovi servizi che sono stati inseriti sulla griglia dai laboratori partner (Figura 3.7). Servizi, costi e profitti possono essere mantenuti nella Message Box oppure possono essere eliminati. Per quanto riguarda i nuovi servizi inseriti dagli altri laboratori invece viene data la possibilità di testarne il funzionamento. In base alla qualità e al gradimento del servizio si può assegnare un voto da 1 a 5: maggiore è il voto e più alto è il gradimento. I messaggi relativi ai nuovi servizi inseriti sulla griglia saranno visibili finché il servizio non sa- rà validato o meno dall’amministratore della VO. Nella pagina principale è anche possibile visualizzare i crediti validati e provvisori totali maturati dal laboratorio. Per ciascuno di essi viene indicata anche la data in cui il credi- to è stato calcolato dall’amministratore della VO. Sempre in questa sezione, inoltre, viene data la possibilità di calcolare i crediti accumulati dai singoli servizi provvisori erogati dal laboratorio stesso. Gestione In questa sezione l’utente è in grado di inserire nelle apposite form le informa- zioni relative ai servizi, costi e profitti erogati dal proprio laboratorio. Per ogni occorrenza inserita si deve specificare anche una breve descrizione con le ca- ratteristiche salienti della risorsa. Tutte queste informazioni verranno visua- lizzate in apposite tabelle accessibili sia dai membri sia dall’amministratore della VO. 61
  • 68. 3.6 L’architettura del portale Figura 3.5: Amministrazione - calcolo dei crediti 62
  • 69. 3.6 L’architettura del portale Figura 3.6: Utente - schermata dell’area personale 63
  • 70. 3.6 L’architettura del portale Figura 3.7: Utente - schermata dell’attività della griglia 64
  • 71. 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
  • 72. Appendice A Sorgenti A.1 Database −− Database c r e d i t i −− −− c a n c e l l a l e t a b e l l e −− DROP TABLE immagine CASCADE; DROP TABLE voto CASCADE; DROP TABLE c r e d i t o b e t a CASCADE; DROP TABLE c r e d i t o CASCADE; DROP TABLE data CASCADE; DROP TABLE s e r v i z i o CASCADE; DROP TABLE c o s t o CASCADE; DROP TABLE p r o g _ a t t CASCADE; DROP TABLE superuser CASCADE; DROP TABLE l a b o r a t o r i o CASCADE; DROP TABLE amministratore CASCADE; DROP TABLE vo CASCADE; −− crea l e t a b e l l e −− CREATE TABLE vo ( nome varchar ( 2 0 ) PRIMARY KEY ) TYPE = InnoDB ; CREATE TABLE amministratore ( nome varchar ( 2 0 ) NOT NULL, cognome varchar ( 2 0 ) NOT NULL, user varchar ( 1 0 ) NOT NULL, password numeric ( 1 0 ) NOT NULL, 66
  • 73. A.1 Database mail varchar ( 3 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, PRIMARY KEY ( user , nome_vo ) , FOREIGN KEY ( nome_vo ) REFERENCES vo ( nome ) ON UPDATE CASCADE ON DELETE CASCADE ) TYPE = InnoDB ; CREATE TABLE l a b o r a t o r i o ( nome varchar ( 5 0 ) NOT NULL, nomevo varchar ( 2 0 ) 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 ( 2 0 ) NOT NULL, cognome varchar ( 2 0 ) NOT NULL, users varchar ( 1 0 ) NOT NULL, pass numeric ( 1 0 ) NOT NULL, mail varchar ( 3 0 ) NOT NULL, nome_l varchar ( 5 0 ) UNIQUE NOT NULL, vo varchar ( 2 0 ) NOT NULL, PRIMARY KEY ( users , nome_l , vo ) , FOREIGN KEY ( nome_l ) REFERENCES l a b o r a t o r i o ( nome ) ON UPDATE CASCADE ON DELETE CASCADE, FOREIGN KEY ( vo ) REFERENCES l a b o r a t o r i o ( nomevo ) ON UPDATE CASCADE ON DELETE CASCADE ) TYPE = InnoDB ; CREATE TABLE p r o g _ a t t ( nome varchar ( 2 0 ) NOT NULL, t i p o varchar ( 3 0 ) NOT NULL, i i l float , wi f l o a t NOT NULL, v a l i d a z i o n e numeric ( 1 ) NOT NULL, nome_lab varchar ( 5 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, g i u s t i f i c a z i o n e varchar ( 2 0 0 0 ) , d e s c r i z i o n e varchar ( 2 0 0 0 ) , PRIMARY KEY ( nome , nome_lab , nome_vo ) , FOREIGN KEY ( nome_lab ) REFERENCES l a b o r a t o r i o ( nome ) ON UPDATE CASCADE ON DELETE CASCADE, 67
  • 74. A.1 Database FOREIGN KEY ( nome_vo ) REFERENCES l a b o r a t o r i o ( nomevo ) ON UPDATE CASCADE ON DELETE CASCADE ) TYPE = InnoDB ; CREATE TABLE c o s t o ( nome_l varchar ( 5 0 ) NOT NULL, t i p o varchar ( 2 0 0 ) NOT NULL, c k l f l o a t NOT NULL, wk f l o a t NOT NULL, v a l i d a z i o n e numeric ( 1 ) NOT NULL, data date NOT NULL, g i u s t i f i c a z i o n e varchar ( 2 0 0 0 ) , d e s c r i z i o n e varchar ( 2 0 0 0 ) , PRIMARY KEY ( nome_l , t i p o , data ) , FOREIGN KEY ( nome_l ) REFERENCES l a b o r a t o r i o ( nome ) ON UPDATE CASCADE ON DELETE CASCADE ) TYPE = InnoDB ; CREATE TABLE s e r v i z i o ( nome varchar ( 2 0 ) NOT NULL, t s l float , ws f l o a t NOT NULL, a c c e s s i numeric , t i p o varchar ( 2 0 ) NOT NULL, v a l i d a z i o n e numeric ( 1 ) NOT NULL, data date NOT NULL, nome_lab varchar ( 5 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, d e s c r i z i o n e varchar ( 2 0 0 0 ) , g i u s t i f i c a z i o n e varchar ( 2 0 0 0 ) , piattaforma varchar ( 5 0 ) NOT NULL, p r o c e s s o r e varchar ( 5 0 ) NOT NULL, ram varchar ( 8 ) NOT NULL, u t i l i z z o _ r a m numeric NOT NULL, so varchar ( 5 0 ) NOT NULL, s t o r a g e numeric NOT NULL, home_page varchar ( 5 0 ) , voto numeric ( 1 ) NOT NULL, PRIMARY KEY ( nome , nome_lab , nome_vo ) , FOREIGN KEY ( nome_lab ) REFERENCES l a b o r a t o r i o ( nome ) ON UPDATE CASCADE ON DELETE CASCADE, FOREIGN KEY ( nome_vo ) REFERENCES l a b o r a t o r i o ( nomevo ) ON UPDATE CASCADE ON DELETE CASCADE 68
  • 75. A.1 Database ) TYPE = InnoDB ; CREATE TABLE data ( user varchar ( 1 0 ) NOT NULL, data date NOT NULL, PRIMARY KEY ( user , data ) ) TYPE = InnoDB ; CREATE TABLE c r e d i t o ( v a l o r e numeric NOT NULL, nome_lab varchar ( 5 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, data date NOT NULL, PRIMARY KEY ( valore , nome_lab , nome_vo , data ) ) TYPE = InnoDB ; CREATE TABLE c r e d i t o b e t a ( v a l o r e numeric NOT NULL, nome_lab varchar ( 5 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, data date NOT NULL, PRIMARY KEY ( valore , nome_lab , nome_vo , data ) ) TYPE = InnoDB ; CREATE TABLE voto ( superuser varchar ( 2 0 ) NOT NULL, voto r e a l NOT NULL, nome_ser varchar ( 2 0 ) NOT NULL, nome_lab varchar ( 5 0 ) NOT NULL, nome_vo varchar ( 2 0 ) NOT NULL, PRIMARY KEY ( superuser , voto , nome_ser , nome_lab , nome_vo ) ) TYPE = InnoDB ; CREATE TABLE immagine ( p e r c o r s o varchar ( 2 0 0 ) NOT NULL, 69
  • 76. A.2 Interfaccia nome varchar ( 2 0 ) NOT NULL, lab varchar ( 5 0 ) NOT NULL, PRIMARY KEY ( percorso , nome , lab ) , FOREIGN KEY ( lab ) REFERENCES l a b o r a t o r i o ( nome ) ON UPDATE CASCADE ON DELETE CASCADE ) TYPE = InnoDB ; A.2 Interfaccia A.2.1 login.php <?php // i n i z i o s e s s i o n e session_start ( ) ; $ok = 0 ; $connessione = mysql_connect ( ’ l o c a l h o s t ’ , ’ r o o t ’ , ’ ’ ) 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_vo FROM amministratore WHERE amministratore . user = ’ " .$_REQUEST[ " username " ] . " ’ AND amministratore . password = ’ " .$_REQUEST[ " password " ] . " ’ " ) ; $ r i s u l t a t o = mysql_query ( $query ) ; i f (mysql_num_rows ( $ r i s u l t a t o ) > 0 ) { $data = mysql_fetch_array ( $ r i s u l t a t o ) ; // v a r i a b i l i di s e s s i o n e $_SESSION [ "name" ] = $data [ "nome" ] ; $_SESSION [ " surname " ] = $data [ " cognome " ] ; $_SESSION [ " admin " ] = $data [ " user " ] ; $_SESSION [ " mail " ] = $data [ " mail " ] ; $_SESSION [ " v i r _ o r g " ] = $data [ " nome_vo " ] ; 70
  • 77. A.2 Interfaccia header ( " Location : prima_home . php " ) ; $ok = 1 ; } else { header ( " Location : index . php? e r r o r e =1 " ) ; $ok = 2 ; } mysql_close ( $connessione ) ; i f ( $ok == 0 or $ok ==2) { $connessione1 = mysql_connect ( ’ l o c a l h o s t ’ , ’ r o o t ’ , ’ ’ ) 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 , vo FROM superuser WHERE users = ’ " .$_REQUEST[ " username " ] . " ’ AND pass = ’ " . ( $_REQUEST[ " password " ] ) . " ’ " ) ; $ r i s u l t a t o 1 = mysql_query ( $query1 ) ; i f (mysql_num_rows ( $ r i s u l t a t o 1 ) > 0 ) { $data1 = mysql_fetch_array ( $ r i s u l t a t o 1 ) ; // v a r i a b i l i di s e s s i o n e $_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? e r r o r e =1 " ) ; } mysql_close ( $connessione1 ) ; } ?> 71
  • 78. A.2 Interfaccia A.2.2 logout.php <?php ob_start ( ) ; session_start ( ) ; session_unset ( ) ; session_destroy ( ) ; header ( " Location : index . php " ) ; ob_end_flush ( ) ; ?> A.2.3 checkuser.php <?php session_start ( ) ; i f ( ! i s s e t ( $_SESSION [ " admin " ] ) ) { header ( " Location : index . php? s e s s i o n e =1 " ) ; } ?> A.2.4 checksuperuser.php <?php session_start ( ) ; i f ( ! i s s e t ( $_SESSION [ " admin_sup " ] ) ) { header ( " Location : index . php? s e s s i o n e =1 " ) ; } ?> A.2.5 checklab.php <?php session_start ( ) ; $ok = 0 ; 72
  • 79. A.2 Interfaccia i f ( $_POST [ " s e l e c t " ] == ’ ’ ) { $ok = 2 ; } i f ( $ok == 0 ) { $connessione = mysql_connect ( " l o c a l h o s t " , " r o o t " , " " ) 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 l a b o r a t o r i o . nome FROM l a b o r a t o r i o WHERE l a b o r a t o r i o . nome = ’ " .$_REQUEST[ " s e l e c t " ] . " ’ " ; $ r i s u l t a t o = mysql_query ( $query ) ; i f (mysql_num_rows ( $ r i s u l t a t o ) > 0 ) { $data = mysql_fetch_array ( $ r i s u l t a t o ) ; $_SESSION [ " labdapassare " ] = $data [ "nome" ] ; $ok = 1 ; } } i f ( $ok == 1) { header ( " Location : manage_ser . php " ) ; } i f ( $ok == 2) { header ( " Location : l a b o r a t o r i o . php? not =1. php " ) ; } ?> A.2.6 op_crediti.php <?php session_start ( ) ; $connessione = mysql_connect ( ’ l o c a l h o s t ’ , ’ r o o t ’ , ’ ’ ) or die ( " Connessione non r i u s c i t a : " . mysql_error ( ) ) ; $ok = 1 ; i f ( $_POST [ " lab " ] == ’ ’ ) { $ok = 0 ; header ( " Location : c r e d i t o . php? e r r o r e =1 " ) ; } 73
  • 80. 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 p r o g e t t o _ a t t i v i t à FROM p r o g _ a t t WHERE p r o g _ a t t . nome_lab = ’ " .$_REQUEST[ " lab " ] . " ’ AND p r o g _ a t t . nome_vo = ’ " . $_SESSION [ " v i r _ o r g " ] . " ’ AND p r o g _ a t t . v a l i d a z i o n e = ’ 1 ’ " ) ; $ r i s u l t a t o = mysql_query ( $query ) ; while ( $ t o t a l e = mysql_fetch_array ( $ r i s u l t a t o ) ) { $somma = $somma + $ t o t a l e [ " p r o g e t t o _ a t t i v i t à " ] ; } $somma2 = 0 ; $query2 = ( "SELECT c k l ∗wk AS c o s t o _ t o t a l e FROM c o s t o JOIN l a b o r a t o r i o ON ( c o s t o . nome_l = l a b o r a t o r i o . nome ) WHERE c o s t o . nome_l = ’ " .$_REQUEST[ " lab " ] . " ’ AND l a b o r a t o r i o . nomevo = ’ " . $_SESSION [ " v i r _ o r g " ] . " ’ AND c o s t o . v a l i d a z i o n e = ’ 1 ’ " ) ; $ r i s u l t a t o 2 = mysql_query ( $query2 ) ; while ( $ t o t a l e 2 = mysql_fetch_array ( $ r i s u l t a t o 2 ) ) { $somma2 = $somma2 + $ t o t a l e 2 [ " c o s t o _ t o t a l e " ] ; } $somma3 = 0 ; $query3 = ( "SELECT ∗ FROM s e r v i z i o WHERE s e r v i z i o . nome_lab = ’ " .$_REQUEST[ " lab " ] . " ’ AND s e r v i z i o . nome_vo = ’ " . $_SESSION [ " v i r _ o r g " ] . " ’ AND s e r v i z i o . v a l i d a z i o n e = ’ 1 ’ " ) ; $ r i s u l t a t o 3 = mysql_query ( $query3 ) ; while ( $ t o t a l e 3 = mysql_fetch_array ( $ r i s u l t a t o 3 ) ) { $ m o l t i p l i c a z i o n e = $ t o t a l e 3 [ "ws" ] ∗ ( $totale3 [ " accessi " ] ∗ $totale3 [ " t s l " ] ) ; $somma3 = $somma3 + $ m o l t i p l i c a z i o n e ; } $aggiunta = 100; $uno = 0 . 2 ∗ $somma ; $due = 0 . 3 ∗ $somma2 ; $ t r e = 0 . 5 ∗ $somma3 ; $condizione_scambio = $uno + $due + $ t r e + 0.000001; preg_match ( " / [ 0 − 9 ] ∗ . / " , $condizione_scambio , $matches ) ; $ r i s u l t a t o 4 = substr ( $matches [ 0 ] , 0 , −1) + $aggiunta ; 74
  • 81. A.2 Interfaccia i f ( $ r i s u l t a t o 4 == 0 ) { $pro = 0 ; $_SESSION [ " r i s " ] = $pro ; } i f ( $ r i s u l t a t o 4 != 0 ) { $_SESSION [ " r i s " ] = $ r i s u l t a t o 4 ; } $_SESSION [ " lab " ] = $_REQUEST[ " lab " ] ; header ( " Location : c r e d i t o . 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 c a l h o s t ’ , ’ r o o t ’ , ’ ’ ) 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? n o s i n g o l o=1&# c a l c o l a " ) ; } i f ( $ok==1) { mysql_select_db ( ’ c r e d i t i ’ ) ; $query = ( "SELECT ∗ FROM s e r v i z i o WHERE s e r v i z i o . nome = ’ " .$_REQUEST[ " s e l e c t " ] . " ’ AND s e r v i z i o . nome_lab = ’ " . $_SESSION [ " lab_sup " ] . " ’ AND s e r v i z i o . nome_vo = ’ " . $_SESSION [ " vir_org_sup " ] . " ’ " ) ; $ r i s u l t a t o = mysql_query ( $query ) ; while ( $ t o t a l e = mysql_fetch_array ( $ r i s u l t a t o ) ) { $ m o l t i p l i c a z i o n e = $ t o t a l e [ "ws" ] ∗ ( $totale [ " accessi " ] ∗ $totale [ " tsl " ] ) ; $somma = $ m o l t i p l i c a z i o n e ; $normaliz = ( 0 . 5 ∗ $somma) + 0.0000001; } 75
  • 82. A.2 Interfaccia preg_match ( " / [ 0 − 9 ] ∗ . / " , $normaliz , $matches ) ; $ t o t = substr ( $matches [ 0 ] , 0 , −1); // $ t o t = round ( $somma , 2 ) ; i f ( $ t o t == 0 ) { $pro = 0 ; $_SESSION [ " sommina " ] = $pro ; } i f ( $ t o t != 0 ) { $_SESSION [ " sommina " ] = $ t o t ; } header ( " Location : superuser_home . php? r i s u l t a t o =1&# c a l c o l a " ) ; } ?> 76
  • 83. 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
  • 84. 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
  • 85. 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