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



           Corso di laurea i...
Alla mia famiglia.
Indice

  Elenco delle figure                                                               5

1 Dal calcolo sequenziale al...
INDICE


  2.2 L’articolazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   35
  2.3 Virtual Organization i...
Elenco delle figure

 1.1 Ciclo di Von Neumann . . . . . . . . . . . . . . . . . . . . . . . .           2
 1.2 Grafico dell...
ELENCO DELLE FIGURE


3.3 Mappa del portale . . . . . . . . . . . . . . . . . . . . . . . . . . .   57
3.4 Amministrazione...
Capitolo 1

Dal calcolo sequenziale al
grid computing

                     We will probably see the spread of ”computer u...
1.1 Architetture uniprocessore


     come un codice che dovrà essere opportunamente ”riconosciuto” dal pro-
     cessore ...
1.1 Architetture uniprocessore


to ciò a portato ad un costante aumento della velocità di calcolo che è stata
quantificata...
1.1 Architetture uniprocessore


time-sharing stavano gettando le basi per la costruzione di hardware e soft-
ware concorr...
1.1 Architetture uniprocessore


MEM è il Memory Access e WB è il Write/Back. Una volta eseguita la fase
di fetch per l’is...
1.1 Architetture uniprocessore




                     Figura 1.4: Esecuzione superscalare


trebbe sembrare che un proce...
1.1 Architetture uniprocessore




                        Figura 1.5: Esecuzione VLIW


   Inoltre i chip VLIW combinano ...
1.1 Architetture uniprocessore


ciclo di macchina sono applicate alle istruzioni del task assegnato.

1.1.4   Parallelism...
1.1 Architetture uniprocessore


con la UC e con la memoria. La UC legge le istruzioni, se sono scalari le
esegue lei stes...
1.2 Architetture multiprocessore


za implementata nelle architetture ILP e DLP, c’è il limite fisico che riguarda
la conne...
1.2 Architetture multiprocessore


1.2.1   Tassonomia di Flynn

Partendo dal modello di Von Neumann, che consiste di un pr...
1.2 Architetture multiprocessore


SISD

Nel 1946 Von Neumann stabiliva i principi generali di progettazione di un ela-
bo...
1.2 Architetture multiprocessore




                       Figura 1.8: Architettura SIMD


MISD

Sono architetture caratt...
1.2 Architetture multiprocessore


processi è possibile distinguere macchine a grana grossa (poche unità molto
potenti) da...
1.2 Architetture multiprocessore


  la ALU corrisponde ad una unità funzionale o elemento di elaborazio-
  ne in un array...
1.2 Architetture multiprocessore


1.2.3     Ulteriore suddivisione delle macchine MIMD

I computer paralleli di tipo MIMD...
1.2 Architetture multiprocessore


i vari nodi per permetterne il coordinamento e l’ottimizzazione. La modalità
con cui i ...
1.2 Architetture multiprocessore


privata; la sincronizzazione dei processi e la condivisione dei dati avvengo-
no tramit...
1.2 Architetture multiprocessore


impiegano tutti lo stesso tempo per accedervi. La rete di interconnessione
può essere b...
1.2 Architetture multiprocessore


le prestazioni se si suddivide la memoria centrale in diversi banchi e si as-
segna ad ...
1.2 Architetture multiprocessore


• Bus unico condiviso: nella topologia a bus (Figura 1.15) tutti i proces-
  sori sono ...
1.2 Architetture multiprocessore


  nodi di vedere qualsiasi pacchetto inviato sulla rete, ma solo il nodo a cui
  il pac...
1.3 Grid


      processore memoria possono comunicare tra loro contemporaneamente
      grazie alla rete di commutazione....
1.3 Grid


pre è possibile individuare piattaforme adatte in termini di tempo di attesa e
capacità di memorizzazione viste...
1.3 Grid


sparente ad ogni tipo d’informazione digitale: immagini di satelliti, dati da
acceleratori come LHC del CERN, b...
1.3 Grid


già citata legge di Moore, di un fattore 2 ogni 18 mesi a parità di costo e le loro
dimensioni si miniaturizzan...
1.3 Grid


produzione scientifica.
   Il concetto di Grid, proposto per la prima volta da Ian Foster e Karl Kessel-
mann ne...
1.3 Grid


accedere alla Grid in maniera sicura, di eseguire le proprie applicazioni, e di
accedere in modo trasparente ai...
1.3 Grid


La maturità (2003-2006)

Nel successivo Sesto Programma Quadro (FP6) della Comunità Europea le
Grid ottennero u...
1.3 Grid


e-Infrastruttura (Internet e Grid) di scala europea. EGEE si può collegare
alla Cyber-Infrastruttura americana ...
1.3 Grid


da EGEE per le attività di divulgazione [14].

1.3.3     La sfida attuale: dalla fase di R&D allo sfruttameno

L...
1.3 Grid


1.3.4     Lo sfruttamento della piattaforma Grid in Italia

Recentemente l’INFN ha proposto che l’Italia si dot...
1.3 Grid


• Estendere in tutto il paese, con attività d’informazione, formazione e
  progetti mirati, lo sfruttamento del...
Capitolo 2

La Grid di produzione di
EGEE

                   A computational grid is a hardware and software infrastructu...
2.2 L’articolazione


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

...
2.2 L’articolazione


   che verranno illustrati di seguito:

EGEE Networking Activities (NA)

Questo settore si occupa di...
2.2 L’articolazione


     Infatti al crescere del numero delle applicazioni che vengono eseguite
     con successo nella ...
2.2 L’articolazione


     rare e controllare la fornitura in rete dei servizi Grid, in particolare di
     individuare e ...
2.3 Virtual Organization in EGEE


      fico di rete. L’altro obiettivo del team è quello di facilitare l’introduzione
   ...
2.3 Virtual Organization in EGEE


vuole entrare a far parte di EGEE e la Certification Authority (CA) centrale
dell’INFN l...
2.4 EGEE Middleware


utilizzare le risorse della VO alla quale è registrato senza dover ”mostrare” le
sue credenziali ad ...
2.4 EGEE Middleware


e utilizzate dagli utenti. I middleware Application Program Interface (API)
e Software development k...
2.4 EGEE Middleware


Lo sviluppo

Molti centri di ricerca sia universitari che industriali collaborano nello svi-
luppo d...
2.4 EGEE Middleware


Già distribuito su varie Griglie di test e di pre-produzione dell’intero progetto,
i risultati di gL...
Capitolo 3

Il portale web

                          The sharing that we are concerned with is not primarily file
        ...
3.2 La sostenibilità di una Organizzazione Virtuale


della griglia computazionale un insieme di risorse locali che vanno ...
3.2 La sostenibilità di una Organizzazione Virtuale


può essere di tipo passivo se il programma utilizzato è uno di quell...
3.3 Il sistema di crediti


importanti.


3.3    Il sistema di crediti

Per quanto appena detto, la VO necessita di un mec...
3.3 Il sistema di crediti


membri riguarda il funzionamento efficiente di tutte le risorse hardware e
software della comun...
3.4 L’ambiente web


ratori partner della VO. In questo modo si vuole assegnare maggiore impor-
tanza ai servizi che lavor...
3.4 L’ambiente web


  1. Un web server dinamico, basato sul server web Apache [21] con i moduli
      PHP5 [22].

  2. Un...
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Tesi Triennale - Grid Credit System: un portale per la sostenibilità di COMPCHEM
Upcoming SlideShare
Loading in …5
×

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

1,724 views

Published on

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

  • Be the first to comment

  • Be the first to like this

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

  1. 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. 2. Alla mia famiglia.
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×