13 Maggio 2010, tesi specialistica in informatica. L'ottimizzazione delle risorse della Grid di EGEE mediante un Framework intelligente basato su SOA.

1. `
Universita degli Studi di Perugia
Facolt` di Scienze Matematiche, Fisiche e Naturali
a
Corso di laurea in Informatica
Tesi di Laurea Specialistica
L’Ottimizzazione delle Risorse
della Grid di EGEE
mediante un Framework Intelligente
basato su SOA
Laureando: Relatore:
Davide Ciambelli Prof. Antonio Lagan`
a
Correlatori:
Dr. Leonardo Pacifici
Dr. Carlo Manuali
Anno Accademico 2008/2009

2. A coloro che hanno creduto in me.

3. Costruire
Chiudi gli occhi
immagina una gioia
molto probabilmente
penseresti a una partenza
ah si vivesse solo di inizi
di eccitazioni da prima volta
quando tutto ti sorprende e
nulla ti appartiene ancora
penseresti all’odore di un libro nuovo
a quello di vernice fresca
a un regalo da scartare
al giorno prima della festa
al 21 marzo al primo abbraccio
a una matita intera la primavera
alla paura del debutto
al tremore dell’esordio
ma tra la partenza e il traguardo
nel mezzo c’` tutto il resto
e
e tutto il resto ` giorno dopo giorno
e
e giorno dopo giorno ` e
silenziosamente costruire
e costruire ` potere e sapere
e
rinunciare alla perfezione
ma il finale ` di certo pi` teatrale
e u
cos` di ogni storia ricordi solo
ı
la sua conclusione
cos` come l’ultimo bicchiere l’ultima visione
ı
un tramonto solitario l’inchino e poi il sipario
tra l’attesa e il suo compimento
tra il primo tema e il testamento
nel mezzo c’` tutto il resto
e
e tutto il resto ` giorno dopo giorno
e
e giorno dopo giorno ` e
silenziosamente costruire
e costruire ` sapere e potere
e
rinunciare alla perfezione
ti stringo le mani
rimani qui
cadr` la neve
a
a breve

4. Sommario
La possibilit` di valutare la qualit` del lavoro di un utente o quanto un servizio
a a
offerto pu` essere innovativo e performante, riveste una grande importanza in am-
o
bito di ricerca. Per raggiungere questo obiettivo, in questa Tesi viene proposto
un Framework basato su un’architettura orientata ai servizi dove le informazioni
utili per calcolare la qualit` (Quality of Service/Quality of User) vengono ottenute
a
direttamente da Grid. Il Framework preso in esame ` GriF. L’idea alla base di
e
GriF ` la creazione di un Framework collaborativo che operi in ambiente Grid e sia
e
in grado di consentire l’esecuzione di programmi richiedenti alte capacit` compu-
a
tazionali senza richiedere uno sforzo eccessivo all’utente. Contestualmente, GriF
si propone di gestire l’ottimizzazione delle risorse e l’organizzazione strutturata
dei risultati ottenuti. In sostanza, l’obiettivo della Tesi ` quello di porre solide
e
basi su cui sviluppare un robusto modello di creditizzazione.

5. Abstract
The ability of assessing the quality of work of a user the innovativity and per-
formance of a service is of great importance in the field of research. To achieve
this goal, we propose in this Thesis a Framework based on a Service-Oriented
Architecture in which the information needed to calculate the quality (Quality of
Service/Quality of User) are obtained directly from Grid. The Framework con-
sidered is called the GriF. GriF is based on the idea of creating a collaborative
Framework that operates in a Grid environment and allows the execution of Grid
programs requiring high computational capabilities without asking exceptioned ef-
forts to the users. At the same time, GriF aims at managing resource optimization
and the structured organization of the results. In essence, the Thesi’s objective is
to lay a own solid foundations on which establish a robust crediting model.

6. Indice
1 Introduzione al Grid Computing 1
1.1 Grid Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Alcuni cenni storici . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Lo sviluppo delle griglie di calcolo . . . . . . . . . . . . . . 4
1.1.3 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Le applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Promotori ed applicazioni reali . . . . . . . . . . . . . . . . 10
1.2.1.1 OGF . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1.2 EDG, EGEE e gLite . . . . . . . . . . . . . . . . . 11
1.2.1.3 Globus Alliance . . . . . . . . . . . . . . . . . . . 12
1.2.1.4 Globus Toolkit . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Campi applicativi . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.3 European Grid Initiative . . . . . . . . . . . . . . . . . . . . 14
1.2.3.1 Lo scopo e la struttura di EGI . . . . . . . . . . . 14
1.2.3.2 EGI Design Study . . . . . . . . . . . . . . . . . . 16
1.2.3.3 Obiettivi di EGI . . . . . . . . . . . . . . . . . . . 16
2 Ottimizzazione delle Risorse della Grid di EGEE 18
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 L’architettura Grid di EGEE . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Computing Element . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1.1 CE-CREAM . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Workload Management System . . . . . . . . . . . . . . . . 23
i

7. INDICE
2.2.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4 Job Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.5 Storage Element . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.6 Data Management System . . . . . . . . . . . . . . . . . . . 27
2.2.7 Information System . . . . . . . . . . . . . . . . . . . . . . 30
2.2.8 Virtual Organization Membership Server . . . . . . . . . . 30
2.2.9 MyProxy Server . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 EGEE Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 gLite: La Futura Generazione di Middleware EGEE . . . . 32
2.3.1.1 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1.2 Lo sviluppo . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1.3 Il software . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Ottimizzazione delle risorse . . . . . . . . . . . . . . . . . . . . . . 34
3 GriF: Algoritmi Adattivi e Queue Ranking 36
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 SOA e Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Cos’` un’architettura SOA . . . . . . . . . . . . . . . . . . .
e 38
3.2.1.1 Una nuova architettura . . . . . . . . . . . . . . . 39
3.2.1.2 Le regole . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.1.3 Gli standard per i Web Service . . . . . . . . . . . 42
3.2.1.4 Web Service per Chi? . . . . . . . . . . . . . . . . 44
3.2.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2.1 Le caratteristiche di base del Framework . . . . . 45
3.2.2.2 Perch´ un Framework? . . . . . . . . . . . . . . .
e 47
3.2.2.3 Usare un Framework . . . . . . . . . . . . . . . . . 47
3.2.2.4 Vantaggi e svantaggi nell’utilizzo di un Framework 48
3.2.2.5 Scegliere un Framework . . . . . . . . . . . . . . . 49
3.2.2.6 Java e Framework . . . . . . . . . . . . . . . . . . 50
3.3 Analisi delle code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
ii

8. INDICE
3.4 Un approccio adattivo per il filtraggio delle code . . . . . . . . . . 57
4 Le Ottimizzazioni Realizzate 60
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 MySQL e Database GriF . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1 Modello Entit`-Relazione . . . . . . . . . . . . . . . . . . .
a 65
4.2.2 Il motore InnoDB . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.2.1 Funzionalit` del motore InnoDB di MySQL . . . .
a 68
4.2.2.2 Limiti delle tabelle InnoDB . . . . . . . . . . . . . 68
4.2.2.3 Come creare un tabella di tipo InnoDB . . . . . . 69
4.2.3 Il Database di GriF . . . . . . . . . . . . . . . . . . . . . . 69
4.3 Lo Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3.1 Perch´ programmare in Shell . . . . . . . . . . . . . . . . .
e 73
4.3.2 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.3 Lo Script rank.sh . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.3.1 Descrizione dello Script . . . . . . . . . . . . . . . 75
4.3.4 Lo Script state.sh . . . . . . . . . . . . . . . . . . . . . . . . 79
4.3.4.1 Descrizione dello Script . . . . . . . . . . . . . . . 81
5 Conclusioni e Future Work 86
A Sorgenti 88
A.1 grif.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Glossario 92
Bibliografia 98
iii

9. Elenco delle figure
1.1 Esempio di sistema Grid. . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Architettura a livelli dell’ambiente Grid proposta da M. Chetty e
R. Buyya. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 EGI DS Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Elementi della Grid di EGEE. . . . . . . . . . . . . . . . . . . . . . 20
2.2 Interfacce SRM e Posix-like File I/O. . . . . . . . . . . . . . . . . . 29
2.3 Il middleware gLite. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Gli elementi di una Service-Oriented Architecture. . . . . . . . . . 39
3.2 I due layer operativi di Applicazioni e Framework. . . . . . . . . . 46
3.3 Funzionamento dell’architettura Java. . . . . . . . . . . . . . . . . 51
3.4 Design Pattern Layers. . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5 L’ambiente GriF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Il Database di GriF. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2 Lo schema generale di funzionamento del YP di GriF e le interazioni
con la Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
iv

10. Elenco delle tabelle
1.1 Ere computazionali. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
v

11. Elenco dei sorgenti
4.1 I sorgenti delle tabelle Rules e Rank del database GriF. . . . . . . 72
4.2 Lo script per l’analisi delle code rank.sh. . . . . . . . . . . . . . . . 77
4.3 Lo script di ottimizzazione state.sh. . . . . . . . . . . . . . . . . . 82
vi

12. Capitolo 1
Introduzione al Grid
Computing
Un giorno le macchine riusciranno a risolvere tutti i problemi,
ma mai nessuna di esse potr` porne uno.
a
- Albert Einstein -
1.1 Grid Computing
Il termine Grid Computing (in italiano letteralmente griglia di calcolo) indica,
come mostrato in Figura 1.1, un’infrastruttura distribuita che consente l’accesso a
risorse computazionali costituite da un numero indistinto di piattaforme distribui-
te geograficamente ed interconnesse da una rete. L’uso del termine griglia deriva
dalla similitudine, fatta dai primi sviluppatori delle piattaforme Grid, secondo i
quali in un prossimo futuro si sarebbe arrivati ad utilizzare le risorse di calco-
lo alla stessa stregua dell’energia elettrica, ovvero semplicemente collegando una
spina all’infrastruttura energetica (Power grid). L’idea del Grid computing, cui
spesso ci si fa riferimento quale prossima rivoluzione dell’informatica (come a suo
tempo fu il World Wide Web), nasce attorno alla met` degli anni novanta con
a
l’obiettivo di risolvere problemi computazionali su larga scala in ambito scientifico
e ingegneristico. Esse si sono sviluppate originariamente in seno alla fisica delle
alte energie e il loro impiego ` oggi esteso alla chimica, alla medicina, alla biologia,
e
all’astronomia e, in qualche maniera, a molti altri settori. La griglia garantisce
agli utenti appartenenti ad un gruppo (gergalmente detto VO, acronimo di Vir-
1

13. 1.1 Grid Computing
Figura 1.1: Esempio di sistema Grid.
tual Organization) un accesso coordinato e controllato a una grande quantit`
a
di risorse condivise che vengono viste come un unico sistema di calcolo logico cui
sottomettere le proprie applicazioni. Essa fa leva sul fatto che in media l’utilizzo
delle risorse informatiche, appartenenti ad una determinata istituzione, ` pari al
e
5% della sua reale potenzialit`. Il modello prevede che le risorse di calcolo ven-
a
gano fornite da diverse entit` in modo da creare un’infrastruttura in media pi`
a u
efficiente rispetto a quella della singola entit`.
a
1.1.1 Alcuni cenni storici
L’idea della Grid nasce negli Stati Uniti alla fine degli anni ’90 come risultato del-
l’elaborazione collettiva della comunit` scientifica internazionale in tema di calcolo
a
distribuito. Le sue basi vennero gettate nel 1989-90 all’INFN [1], al CERN e nei
maggiori Centri di Calcolo in Europa e negli USA. Tale tecnologia si affiancava a
quella del WEB e di Internet ed aveva le caratteristiche necessarie per portare, nel
giro di pochi anni, all’integrazione delle griglie fornite da cluster di workstation e
Personal Computer (PC) con i grandi supercalcolatori mainframe. Infatti i main-
2

14. 1.1 Grid Computing
frame, basati su architetture speciali sviluppate in maniera dedicata, richiedono
tempi, costi di progettazione e realizzazione tali da non poter tenere il passo con lo
sviluppo dei processori “commodity” adottati da milioni di utenti. I semplici PC
e i dischi poco costosi ad essi collegati, insieme alle interfacce di rete e ai backbone
standard per le reti locali (Ethernet), sono le componenti elementari di sistemi con
potenze davvero ragguardevoli. Le prestazioni di queste componenti sono progres-
sivamente migliorate, seguendo la legge di Moore, di un fattore 2 ogni 18 mesi, a
parit` di costo. In Italia uno dei primi cluster di workstation basato su processori
a
commodity, noto come “INFN Farm” ` stato realizzato nel 1989 dall’INFN in col-
e
laborazione con il CERN. Esso mostr` al mondo scientifico come questa tecnologia
o
potesse essere utilizzata nell’ambito dell’esperimento DELPHI [2] per le relative
esigenze di calcolo con costi che, per le applicazioni di quell’esperimento, erano
considerevolmente pi` bassi di quelli delle tecnologie precedenti.
u
Negli anni ’90 questa trasformazione fu completata. I modelli di calcolo “cen-
tralizzati” basati sui grandi supercomputer, attorno ai quali sono nati i grandi
Centri di Calcolo con migliaia di utenti negli USA e in Europa, sono stati pro-
gressivamente affiancati e a volte sostituiti da modelli distribuiti che potevano
sfruttare i cluster di PC, attualmente disponibili in molte Universit` e Centri di
a
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
a
decrescere ancora pi` rapidamente di quanto previsto dalla legge di Moore per
u
CPU e dischi (Tabella 1.1). Alla fine degli anni ’90 erano quindi disponibili, su
una rete a banda larga che collegava le universit` e i centri di ricerca con velocit`
a a
di trasmissione sempre pi` elevata e costi sempre pi` ridotti, un numero crescente
u u
di risorse computazionali e di memoria.
Si pose quindi il problema dello sviluppo di una nuova tecnologia che per-
mettesse alla comunit` scientifica di sfruttare e condividere in modo dinamico le
a
risorse distribuite per accelerare i processi innovativi ed aumentare la propria ef-
3

15. 1.1 Grid Computing
ficienza produttiva. Questo obiettivo fu centrato da Ian Foster e Carl Kesselman
nella primavera del 1999 [3] quando proposero per la prima volta il concetto di
Grid. Tale tecnologia rapidamente adottata da tutta la comunit` scientifica inter-
a
nazionale si basa sullo sviluppo di servizi e protocolli standard per la condivisione
di risorse distribuite nascondendone all’utente l’eterogeneit`.
a
Era Relazione tra Architettura di Architettura di
calcolatori e utenti condivisione super calcolo
Anni ’70 Uno a molti Sistemi Time sharing Supercalcolatore
Anni ’80 Uno a uno PC e Workstation Supercalcolatore
Anni ’90 Molti a uno Clusterizzazione COW
Terzo millennio Molti a molti Grid Grid
Tabella 1.1: Ere computazionali.
1.1.2 Lo sviluppo delle griglie di calcolo
Fu infatti proprio nel 1998 che, a seguito del progetto Globus [4] di Foster e
Kesselman, si iniziarono a sviluppare alcuni servizi di base che miravano ad una
prima implementazione di Grid. Questi sono stati rapidamente resi disponibili
come Open Source attraverso il Globus Toolkit (GTK) [5] che divenne un primo
standard internazionale per l’accesso e la condivisione di risorse computaziona-
li distribuite. Il GTK ` un software studiato per risolvere problemi legati allo
e
sviluppo di servizi ed applicazioni per Grid. La Grid si basa su di una serie di
servizi e protocolli che sono implementati attraverso API e SDK nel GTK. Tale
software permette la condivisione di risorse di calcolo, database e altri strumenti
in maniera sicura, senza la necessit` di sacrificare le autonomie locali. Il Toolkit
a
fornisce servizi e librerie per il monitoraggio e la gestione delle risorse computa-
zionali, ma anche servizi per la gestione della sicurezza delle informazioni. Nel
2000 l’INFN promosse in Europa la creazione del primo progetto Grid europeo
denominato DataGrid [6]. Tale progetto, finanziato dall’Unione Europea con 10
Milioni di Euro, raccolse una ventina di partner provenienti da diversi paesi Eu-
4

16. 1.1 Grid Computing
ropei e comprendenti soggetti di molte discipline scientifiche e dell’industria. Gli
obiettivi principali di DataGrid erano:
• lo sviluppo di nuove componenti di middleware per l’accesso a dati disponibili
in domini di gestione diversi e distribuiti a livello geografico;
• la realizzazione di un primo “testbed” Europeo e internazionale che permet-
tesse l’inizio di effettive attivit` utili per la comunit` scientifica;
a a
• l’ottimizzazione della gestione dei carichi di lavoro su risorse computazionali
distribuite a livello geografico.
Inoltre l’INFN, in collaborazione con il CERN, avvi` nel 2001 il progetto Data-
o
TAG [7] che affrontava il problema dell’interoperabilit` con le Grid in sviluppo
a
negli Stati Uniti e nei Paesi dell’area Asiatica. DataTAG stabiliva uno stretto
legame di collaborazione con i principali 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. Nei due anni seguenti un
numero crescente di attivit` di ricerca e sviluppo sulle Grid fu finanziato da quasi
a
tutti i Paesi e dalla Comunit` Europea che gi` nel biennio 2001/03 del Quinto
a a
Programma Quadro (PQ) approvarono una ventina di progetti di finanziamento.
Contemporaneamente negli Stati Uniti la National Science Foundation (NSF) e il
Department Of Energy (DOE) finanziarono vari progetti, tra i quali TeraGrid, che
aveva come obiettivo la costruzione di un’infrastruttura nazionale di supercalcolo.
In Italia a INFN Grid si affiancano altri progetti nazionali, come ad esempio Grid.it
[11] (del quale fece parte anche l’universit` di Perugia) che coinvolgeva vari istituti
a
di ricerca e Universit`, il progetto di Grid per la finanza (EGrid) [8], il progetto
a
Grid per il supercalcolo al sud SPACI [9], il progetto Grid Inter-dipartimentale a
Napoli e altri progetti minori. Si pu` quindi tranquillamente affermare che i mag-
o
giori Enti di ricerca (INFN, CNR, INAF ed ENEA ) e molte Universit` negli ultimi
a
anni sono stati progressivamente coinvolti nelle attivit` di sviluppo e utilizzo della
a
5

17. 1.1 Grid Computing
Grid. Nel successivo Sesto PQ, i progetti basati sullo sviluppo di Grid, ottennero
un posto di primo piano. Di fatto nel Sesto PQ venne approvato e finanziato il
progetto EGEE [10] del CERN, di durata biennale. Esso prevedeva la realizza-
zione della prima Grid Europea per le scienze, e aperta inoltre all’industria e al
commercio. EGEE ` l’acronimo di Enabling Grids for E-sciencE e pu` essere
e o
considerato il successore di DataGrid e DataTAG che ha portato alla costruzione
della prima Grid Europea di produzione. Essa ` stata un’impresa storica; vi han-
e
no partecipato pi` di 70 Enti ed Istituzioni scientifiche appartenenti a 26 Paesi
u
Europei organizzati in 9 grandi Federazioni. EGEE ha richiesto inoltre lo sviluppo
di un middleware Grid Open Source, costruito con stretti criteri d’ingegneria del
software in grado di durare nel tempo che ` andato a sostituire quello esistente
e
facendo passare definitivamente l’Europa dalla fase di “sperimentazione” a quella
di “produzione”. Il middleware si basa sui nuovi standard come il Web Service
Resource Framework (WSRF) [12] per la costruzione di Web e Grid services, de-
finiti a livello internazionale da W3C [13] e OASIS [14], organizzati in una logica
di Open Grid Services Architecture. Oggi EGEE rappresenta una grande sfida
vinta dalla comunit` scientifica Europea, chiamata ad organizzarsi in tempi brevi
a
in un grande progetto competitivo a livello internazionale. EGEE costituisce un
passo fondamentale del processo di integrazione di tutte le esistenti infrastrutture
Grid nazionali in una grande e-Infrastruttura (Internet e Grid) su scala Europea.
EGEE si pu` collegare alla Cyber-Infrastruttura americana proposta dalla Natio-
o
nal Science Foundation e alle Grid asiatiche in costruzione in Cina e Giappone.
Esso ` un passo decisivo verso la costruzione di una Grid mondiale, necessaria alle
e
moderne societ` che mettono la conoscenza alla base dello sviluppo. Si tratta di
a
una svolta epocale dal punto di vista scientifico e tecnologico, poich´ le Grid di
e
produzione cambieranno il modo di produrre e fare ricerca, sia per gli enti pubblici
che per le aziende private. Di fatto in EGEE l’INFN ha promosso la costituzio-
ne di una Joint Research Unit (JRU) di cui fanno parte alcune Universit` (come
a
Calabria, Lecce, Napoli e Perugia), alcuni enti (come CNR, ENEA, GARR), al-
6

18. 1.1 Grid Computing
cune importanti aziende (come Datamat, Nice), alcune scuole prestigiose (come
SISSA) e alcuni consosrzi (come CASPUR, SPACI). Oggi che si sta strutturando
la European Grid Initiative (EGI) [15] questa JRU sta giocando un ruolo chiave
per la sua costruzione e si sta costituendo a tale scopo come infrastruttura nazio-
nale, IGI (Italian Grid Infrastructure), di riferimento. Grazie ad essa l’Italia pu`
o
giocare un ruolo di primo piano nello sviluppo delle Grid in Europa e nel mondo.
E proprio a seguito di tali iniziative, infrastrutture Grid d’interesse generale per
svariate discipline scientifiche, cominciano a divenire operanti in Italia, in Europa
e in USA con funzionalit` costantemente incrementate. Ci` a reso possibile la
a o
completa automatizzazione degli strumenti per l’installazione del middleware e lo
sviluppo di sistemi per il controllo. A seguito di tutto ci`, infatti, gli utenti Grid
o
possono oggi installare e aggiornare il loro middleware abbastanza semplicemen-
te e dispongono di un portale (Genius) che consente l’uso trasparente dei servizi
della Grid. Inoltre, possono provare direttamente queste funzionalit` tramite la
a
piattaforma di prova (testbed) GILDA [16] messa a punto dall’INFN ed utilizzata
da EGEE per le attivit` di divulgazione [17].
a
1.1.3 Middleware
Secondo la definizione di Ian Foster [19] una Grid ` un’infrastruttura hard-
e
ware e software che permette un accesso sicuro, consistente, diffuso
ed economico a risorse computazionali di alto livello. L’utilizzo di questo
insieme di risorse richiede una infrastruttura hardware capace di fornire le inter-
connessioni necessarie e gli strumenti software (come il middleware) per gestire e
controllare il sistema. Con il termine “middleware” si intende un insieme di soft-
ware che fungono da intermediari tra diverse applicazioni. La Figura 1.2 mostra
l’architettura a livelli dell’ambienti Grid proposta da M. Chetty e R. Buyya [18].
Nella parte inferiore dello stack in figura sono state distribuite le risorse ammini-
strate localmente e interconnesse attraverso reti locali o wide-area (Grid fabric).
Il Grid fabric incorpora:
7

19. 1.1 Grid Computing
• computer come PC, workstation, o SMPs (multiprocessori simmetrici) con
sistemi operativi Unix o Windows;
• cluster con diversi sistemi operativi;
• Resource Management System come Load Sharing Facility, Condor, Portable
Batch System e Sun Grid Engine;
• dispositivi di archiviazione;
• database;
• speciali strumenti scientifici come telescopi, radio e sensori.
Figura 1.2: Architettura a livelli dell’ambiente Grid proposta da M. Chetty e R.
Buyya.
Il livello superiore successivo ` l’infrastruttura di sicurezza e fornisce un accesso
e
sicuro ed autorizzato alle risorse Grid. Lo strato ancora superiore, il nucleo princi-
pale del middleware Grid, offre un accesso uniforme e sicuro alle risorse (pu` anche
o
implementare un livello di sicurezza). I due strati successivi sono uno strato midd-
8

20. 1.2 Le applicazioni
leware a livello utente, costituito da Resource broker e/o da utilit` di pianificazio-
a
ne responsabili all’aggregazione di risorse, e un ambiente per la programmazione
Grid. I Resource broker gestiscono l’esecuzione di applicazioni su risorse distri-
buite utilizzando appropriate strategie di programmazione. L’ultimo strato infine
comprende le applicazioni di rete che vanno dal calcolo collaborativo per l’accesso
remoto fino allo sviluppo di applicazioni commerciali e strumenti scientifici per
simulazioni. Un esempio di middleware ` il gestore delle transazioni, ovvero un
e
componente che ` interposto tra l’utente e il gestore del database, o l’applicazione
e
in generale, o il sistema client/server. In queste situazioni, il middleware acce-
lera il completamento delle richieste dell’utilizzatore, riducendo il numero delle
richieste di collegamento al database e rendendo ogni collegamento pi` efficiente.
u
Esempi di questo tipo di programmi sono CICS [20], IBM WebSphere MQ [21] e
Tibco [22]. L’utilizzo di uno strato software aggiuntivo, il middleware appunto,
consente di ottenere un elevato livello di servizio per gli utenti ed un elevato livello
di astrazione per i programmatori. Inoltre, rende pi` semplice la manutenzione,
u
l’implementazione e l’integrazione delle applicazioni. Tale ruolo rappresenta un’e-
voluzione del ruolo del middleware, che inizialmente era preposto esclusivamente
al miglioramento e all’ottimizzazione dell’efficienza del sistema.
1.2 Le applicazioni
Dopo anni di ricerche e sviluppi in questo campo, sono stati individuati cinque
settori principali sui quali le Grid possono avere un impatto notevole:
• Distributed Supercomputing (supercalcolo distribuito);
• High Throughput Computing (calcolo di gran volume);
• on-Demand Computing (calcolo a richiesta);
• Data intensive applications (calcolo ad alta intensit` di dati);
a
• Collaborative Computing (calcolo collaborativo).
9

21. 1.2 Le applicazioni
Di seguito vengono illustrate le caratteristiche principali dei 5 settori.
Distributed Supercomputing
La griglia ` usata per schedulare un numero limitato di task pesanti (tra loro indi-
e
pendenti o scarsamente accoppiati) con l’obiettivo di utilizzare in contemporanea
le potenti risorse dei supercomputer delle large scale facilities.
High-Throughput Computing
La griglia ` usata per schedulare un largo numero di task indipendenti o scarsa-
e
mente accoppiati, con l’obiettivo di utilizzare i cicli di processori di qualsiasi tipo
inutilizzati per ottenere lavoro utile. L’obiettivo principale ` quello di massimiz-
e
zare il throughput finale.
On-Demand Computing
La griglia ` usata per accedere a risorse non disponibili di cui non ` conveniente,
e e
o possibile, disporre a lungo termine e localmente. L’obiettivo principale ` quello
e
di ottimizzare il rapporto costo-prestazione.
Data Intensive application
La griglia ` utilizzata per elaborare quantit` massicce di dati indipendentemente
e a
da dove essi sono memorizzati e dove si localizza l’utente. L’obiettivo ` sintetizza-
e
re nuova informazione da dati mantenuti in repository, librerie digitali e database
geograficamente distribuiti.
Collaborative Computing
Riguardano principalmente la gestione coordinata delle interazioni umane in un
ambiente geograficamente distribuito. L’obiettivo ` quello di garantire Quality of
e
Service in ambiente distribuito.
1.2.1 Promotori ed applicazioni reali
Le tecnologie su cui si deve basare lo sviluppo delle Grid si richiede siano standard
e non proprietarie, in modo da garantire interoperabilit` e affidabilit` tra i sistemi
a a
(in generale eterogenei) che i singoli utenti includono nella Grid stessa. In linea
con questo protocollo, la progettazione degli standard per le infrastrutture Grid
10

22. 1.2 Le applicazioni
` guidata da enti e associazioni creati dalla partecipazione di un gran numero di
e
centri di ricerca e aziende interessate a questa tecnologia. Di seguito verranno
descritti i maggiori enti di sviluppo delle tecnologie Grid e il loro apporto allo
stato dell’arte.
1.2.1.1 OGF
L’Open Grid Forum (OGF) [23] nasce nel 2006 dall’unione tra il Global Grid
Forum e l’Enterprise Grid Alliance. In particolare, il Global Grid Forum venne
costituito dalla fusione tra i Grid Forum americano, europeo e giapponese, che
essenzialmente organizzavano conferenze tenute e seguite da ricercatori ed esperti
nell’ambito del calcolo ad alte prestazioni. Il secondo invece ` una partnership tra
e
varie aziende del settore, anche di grosso calibro quali IBM, Sun Microsystems e
Cisco Systems, con l’obiettivo di rendere possibile l’uso estensivo dei data center
aziendali alla comunit` degli utenti di Grid. L’OGF ha finora prodotto un discre-
a
to numero di standard di grande rilevanza nello sviluppo della tecnologia Grid,
primo fra tutti l’Open Grid Services Architecture, che pone le basi tecniche per
lo sviluppo di un’infrastruttura Grid. Altro risultato importante ` la Distribu-
e
ted Resource Management Application API, la descrizione di un’interfaccia per la
sottomissione e la gestione di job all’interno di un sistema distribuito, standard
implementato anche nel Grid Engine supportato da Sun.
1.2.1.2 EDG, EGEE e gLite
Lo European Data Grid (EDG) [24] era un progetto finanziato dalla Comunit`
a
Europea per lo sviluppo di una Grid a supporto dei centri di ricerca, rivolta in
particolare alla biologia, fisica delle particelle e scienze della Terra. Nel 2004 il
progetto ` stato considerato concluso e molti dei suoi risultati sono stati ripresi in
e
un secondo progetto, l’Enabling Grid For E-sciencE, sempre finanziato dall’Unio-
ne Europea ma che vede partecipazioni internazionali, dall’America all’Estremo
Oriente. Il middleware prodotto nel progetto EDG ` stato la base dell’infrastrut-
e
tura creata come supporto all’immensa richiesta computazionale del Large Hadron
11

23. 1.2 Le applicazioni
Collider, installato al CERN di Ginevra. Questo middleware fu adattato per lo
sviluppo di EGEE mentre in parallelo veniva sviluppato gLite, che oltre al codi-
ce dell’EDG incorpora pezzi di codice fra i pi` diffusi sistemi middleware per il
u
calcolo distribuito, come il GTK e Condor Cycle Scavenger.
1.2.1.3 Globus Alliance
La Globus Alliance [25] ` un’associazione di vari enti, in particolar modo Unive-
e
sit` e centri di ricerca Europei, Americani e dall’Estremo Oriente, che ha come
a
obiettivo lo sviluppo di un middleware per la creazione e gestione di sistemi Grid:
il Globus Toolkit, il pi` diffuso attualmente. Oltre alle Universit` e ai centri di
u a
ricerca, ` da notare la presenza all’interno della Globus Alliance di Univa Cor-
e
poration, societ` commerciale fondata nel 2004 dai ricercatori Tuecke, Foster e
a
Kesselman, che si propone come supporto alle aziende per l’utilizzo della tecnolo-
gia Grid. Sono presenti anche altre partecipazioni di aziende private quali IBM e
Microsoft.
1.2.1.4 Globus Toolkit
Il Globus Toolkit (GTK) ` un middleware per il supporto di Grid e applicazioni
e
orientate a questa tecnologia. Il software viene liberamente distribuito su Internet
unitamente ad una serie di applicazioni pensate per affrontare vari aspetti del-
l’amministrazione e dell’utilizzo di Grid quali sicurezza, fault detection, resource
management. Nato dall’unione tra vari gruppi interessati alla tecnologia Grid, si
propone come progetto mirato a risolvere i problemi reali che si affrontano nella
messa in opera di un sistema Grid, fornendo uno strato di middleware basato su
standard internazionali, come ad esempio lo standard SOAP definito dalla W3C,
che supporta la produzione e l’utilizzo di applicativi per Grid. La grande diffu-
sione del GTK, insieme al fatto di essere Open Source, ha permesso di avvicinare
molte aziende al Grid Computing. Come suggerisce il suo nome, il GTK non `
e
un unico blocco software monolitico, ma si presenta come una composizione di
elementi specializzati, ognuno dei quali ` pensato per assolvere ad un preciso com-
e
12

24. 1.2 Le applicazioni
pito ed affrontare un problema circoscritto. In particolare i componenti principali
del Toolkit sono:
• WS-Core, un’implementazione dello standard OGSA basato sui Web Ser-
vices.
• GSI, uno strato software che utilizza la tecnica di crittografia a chiave pub-
blica per fornire servizi di sicurezza ad ampio spettro (segretezza, autenti-
cazione, etc).
Queste due componenti sono poi affiancate da un insieme di altre applicazioni
di utilit`, sempre basate su interfacce standard, che offrono alcuni dei principali
a
servizi richiesti ad una griglia, quali data management, resource discovery e mo-
nitoring. Inoltre, viene anche fornita una API per lo sviluppo di applicativi per il
Grid per i linguaggi Java e C++, insieme ad una collezione di esempi riguardanti
la stessa API e i servizi ad essa collegati.
1.2.2 Campi applicativi
Uno dei problemi chiave delle Grid riguarda il rapporto tra il bacino di utenti, ov-
vero quali comunit` o gruppi di persone utilizzano l’infrastruttura, e l’apparato di
a
servizio ovvero quali comunit` o gruppi di persone garantiscono la predisposizio-
a
ne, e la necessaria sostenibilit` e fruibilit` dell’infrastruttura. Grid specializzate
a a
e progettate per supportare obiettivi e gruppi specifici. Alcuni possibili scenari di
utilizzo della Grid da parte delle comunit` per i loro obiettivi, sono:
a
Governi
Un numero relativamente piccolo di pianificatori e scienziati che utilizzano le po-
tenze di calcolo dei computer in Grid per risolvere problemi di Governance, quali la
difesa nazionale, le pianificazioni a lungo termine delle risorse, ma anche problemi
di tipo amministrativo come la gestione degli archivi catastali o della popolazione.
La ricerca scientifica
La comunit` scientifica che utilizza le risorse disponibili e il parco delle apparec-
a
chiature disponibili (come microscopi elettronici, acceleratori di particelle, sorgenti
13

25. 1.2 Le applicazioni
di raggi X, etc) in forma collaborativa tra gruppi diversi, geograficamente dispersi
e con competenze, strumentazioni e archivi di “know-how” complementari.
Mercato
Le diverse comunit` (che includono anche i consumatori) che provvedono a fornire
a
dei particolari servizi, come ad esempio modelli finanziari, studi sull’andamento
del mercato e quant’altro possa riguardare l’economia, la logistica, l’energia, le
materie prime, gli alimenti, il patrimonio naturalistico e artistico etc riferiti in ge-
nere ai relativi database necessari per effettuare le relative elaborazioni statistiche
e approntamento di scenari.
1.2.3 European Grid Initiative
Come gi` accennato, l’attivit` di EGEE si concluder` con la fine di Maggio 2010
a a a
con l’entrata in regime operativo di EGI (Figura 1.3) come da piano di implemen-
tazione previsto dalla commissione EGI DS coordinata da Ludek Martyska nel
2008. In quella occasione Robert Jones, il direttore di EGEE, passer` le consegne
a
a Steven Newhouse, direttore di EGI che ha il suo quartier generale in Amster-
dam. Gli azionisti di EGI sono le National Grid Initiatives (NGI), entit` nazionali
a
che nascono come aggregazione e rappresentanti di tutte le iniziative nate in un
dato paese Europeo. L’obiettivo di EGI ` quello di garantire la sostenibilit` del-
e a
l’infrastruttura Grid in Europa. EGI mette a disposizione un forum per collegare
insieme le risorse di calcolo in diversi paesi Europei a sostegno della ricerca interna-
zionale in molte discipline scientifiche. Gi` comunque dal 2007 l’embrione di EGI
a
sotto forma di commissione EGI DS ha iniziato le sue attivit` di pianificazione
a
ed ` stata supportata da organizzazioni operanti per conto delle costituende NGI
e
sotto forma di JRU in molti dei 36 paesi europei interessati fornendo un sostegno
all’infrastruttura sviluppata da EGEE.
1.2.3.1 Lo scopo e la struttura di EGI
Gi` sin d’oggi ` chiaro comunque che quanto ` avvenuto in EGEE per la scienza
a e e
altro non ` che il processo di innesco di una linea di sviluppo pi` generalizzato.
e u
14

26. 1.2 Le applicazioni
Figura 1.3: EGI DS Schedule.
L’innovazione, garanzia per lo sviluppo economico, ` intimamente connessa al ra-
e
pido progresso scientifico che a sua volta ` diventato sempre pi` dipendente dalla
e u
collaborazione tra i ricercatori di tutto il mondo. Di fatto, come gi` accennato
a
in precedenza, l’utilizzo di elevate capacit` di calcolo ` sempre pi` necessario per
a e u
modellare sistemi complessi e per elaborare i risultati sperimentali. Le griglie di
calcolo per l’e-Science nate per rispondere alle necessit` di discipline scientifiche
a
(come la fisica delle alte energie e la bioinformatica, ecc) condividendo e combi-
nando la potenza dei computer e i sofisticati, spesso unici, strumenti scientifici
dal 2009 hanno fatto molta strada finendo per combinare le discipline pi` sva-
u
riate e coordinare strategie di sviluppo di tutte le Scienze. Cos` facendo EGEE
ı
` evoluta in un vero e proprio modello di organizzazione paneuropeo capace di
e
garantire la sostenibilit` a lungo termine delle e-Infrastrutture Grid e di integrare
a
le strategie nazionali di finanziamento a sostegno della e-Science. Le NGI nate a
livello nazionale per questo scopo stanno perci` attrezzandosi per rispondere in
o
modo coordinato ed efficace sia alle esigenze delle discipline scientifiche all’interno
dei singoli paesi sia per sostenere un ruolo propulsivo pi` generale nei confronti
u
di pi` vasti settori della societ`. Le NGI sono infatti organismi con la missione
u a
15

27. 1.2 Le applicazioni
pubblica di integrare finanziamenti a livello nazionale per la fornitura di servizi
basati su Grid. Essi finiranno perci` per rappresentare un “one-stop-shop” per
o
una serie di servizi comuni basati su Grid per le comunit` di ricerca nazionali i
a
cui rappresentanti (uno per ciascuna NGI) costituiranno la struttura di governo di
EGI. Tale Consiglio controller` l’organismo esecutivo che gestir` le collaborazioni
a a
internazionali tra le NGI.
1.2.3.2 EGI Design Study
Come accennato in precedenza il progetto di implementazione di EGI ` stato cu-
e
rato dalla commissione EGI Design Study (EGI DS) attivata nel Settembre 2007
i cui lavori si sono conclusi alla fine del Novembre 2009 dopo che, a latere del
Congresso EGEE ’09 tenutosi nel Settembre 2009 a Barcellona, ` stata formal-
e
mente costituita l’assemblea dei rappresentati delle NGI che ha eletto come suo
presidente Peter Oster, Direttore del CSC (Center for Scientific Computing) di
Helsinki. Il progetto ` stato parzialmente finanziato dalla Commissione Europea
e
attraverso il Settimo Programma Quadro al fine di:
• valutare i requisiti e casi d’uso per EGI;
• identificare i processi ed i meccanismi per fondare EGI;
• definire la struttura di EGI;
• avviare la costruzione di EGI.
1.2.3.3 Obiettivi di EGI
Per EGI sono stati definiti i seguenti obiettivi:
• assicurare la sostenibilit` a lungo termine della e-Infrastruttura Europea;
a
• coordinare l’integrazione e l’interazione tra le NGI;
• mettere in funzione un’infrastruttura di produzione Grid di livello Europeo,
per una vasta gamma di discipline scientifiche da collegare alle NGI;
16

28. 1.2 Le applicazioni
• fornire servizi e supporto globali ad integrazione e/o coordinamento dei
servizi nazionali (Autenticazione, supporto alle VO, sicurezza, ecc);
• coordinare lo sviluppo e la standardizzazione del middleware per migliorare
le infrastrutture;
• fornire la documentazione e materiale di formazione per il middleware e le
operazioni;
• tenere conto degli sviluppi effettuati a livello nazionale da parte dei progetti
di e-Science che avevano lo scopo di sostenere le varie comunit`;
a
• collegare l’infrastruttura Europea con analoghe infrastrutture altrove;
• collaborare strettamente con industrie, fornitori di tecnologie e di servizi,
per promuovere l’adozione rapida ed efficace delle tecnologie di rete da parte
dell’industria Europea.
17

29. Capitolo 2
Ottimizzazione delle Risorse
della Grid di EGEE
Sono convinto che l’informatica abbia molto in comune con la fisica.
Entrambe si occupano di come funziona il mondo a un livello abbastanza fondamentale.
La differenza, naturalmente, ` che mentre in fisica devi capire come ` fatto il mondo,
e e
in informatica sei tu a crearlo. Dentro i confini del computer, sei tu il creatore.
Controlli – almeno potenzialmente – tutto ci` che vi succede.
o
Se sei abbastanza bravo, puoi essere un dio. Su piccola scala.
- Linus Torvalds -
2.1 Introduzione
EGEE, (Enabling Grids for E-sciencE), cui abbiamo gi` fatto ripetutamente ri-
a
ferimento ` il progetto europeo che per antonomasia ha mirato ad integrare le
e
infrastrutture Grid preesistenti per creare in Europa un’unica piattaforma per il
supporto alla ricerca scientifica e permettere ai ricercatori un accesso alle maggiori
risorse computazionali, indipendentemente dalla loro collocazione geografica. La
piattaforma EGEE supporta le comunit` che condividono la necessit` di accede-
a a
re a ingenti risorse computazionali e che siano disposte ad integrare in essa la
propria infrastruttura accettando una politica di accesso comune. La nascita di
EGEE risale al 1 Aprile 2004, come prosecuzione del progetto EDG (European
DataGrid) che in tre anni di attivit` ha portato ad un grande sviluppo di software
a
e middleware necessario alla realizzazione di un’infrastruttura Grid utilizzata da
molti progetti di ricerca nei campi della fisica, della chimica, della biologia e della
18

30. 2.2 L’architettura Grid di EGEE
geologia. Il progetto ha avuto una durata biennale. Esso ha per` trovato prosecu-
o
zione e finanziamento come EGEE II, nell’ambito del Sesto Programma Quadro
dell’unione europea. Un successivo finanziamento ha consentito il varo, poi, di
EGEE III. In EGEE sono stati creati collegamenti con simili iniziative di altri
continenti. Il progetto EGEE gestisce ogni giorno centinaia di migliaia di ope-
razioni informatiche e costituisce l’infrastruttura di griglia di calcolo pi` grande
u
al mondo. L’infrastruttura EGEE comprende 91 partner istituzionali di 32 paesi
Europei, Asiatici e Statunitensi. Essa ` collegata alla rete europea di comunica-
e
zioni ad alta velocit` GEANT2 [26] e ad altre reti simili. Per effettuare i calcoli
a
vengono attivati cluster di varie centinaia, e addirittura migliaia di computer, ri-
correndo in tutto a oltre 100 000 CPU e a diversi milioni di gigabyte di memoria di
massa. Recentemente il sistema EGEE ` diventato interoperabile con altre griglie
e
scientifiche nazionali e internazionali come l’Open Science Grid [27] negli USA e
NAREGI [28] in Giappone. Oltre che alle applicazioni scientifiche, EGEE si ` este-
e
so anche ai servizi all’industria. Tre societ` si sono impegnate finora a collaborare
a
nel progetto EGEE Business Associates (EBA) al fine di rendere l’infrastruttura
di calcolo distribuito della griglia pi` accessibile, pi` efficace e pi` sicura in un
u u u
contesto industriale. Il progetto EBA specifica come le piccole e medie imprese
(quindi il settore economico) possano adottare in una maniera totalmente sicura
e fiduciosa le tecnologie della Grid. Questa apertura della comunit` scientifica
a
all’industria rappresenta un qualificante passo in avanti rispetto alla condivisione
di risorse e know-how scientifico in campi diversi quali appunto il mondo della
ricerca e quello dell’industria.
2.2 L’architettura Grid di EGEE
L’architettura Grid di EGEE ` articolata in componenti che assicurano al suo
e
interno l’operativit` di funzioni diverse. Elementi di fondamentale importanza
a
nell’infrastruttura di EGEE di cui daremo qui di seguito una breve descrizio-
ne sono il Computing Element (CE), il Workload Management System (WMS),
19

31. 2.2 L’architettura Grid di EGEE
la User Interface (UI), il Job Wrapper (JW), lo Storage Element (SE), il Data
Management Service (DMS), l’Information System (IS), il Virtual Organization
Membership Server (VOMS) e il MyProxy Server (MPS) (le cui componenti fisiche
sono evidenziate in violetto nella Figura 2.1)
Figura 2.1: Elementi della Grid di EGEE.
2.2.1 Computing Element
Il Computing Element o CE, ` la componente che garantisce le risorse compu-
e
tazionali di un sito e svolge il ruolo di intermediario tra le richieste di servizi Grid
da parte di una entit` autorizzata e il Resource Management System (RMS). Il
a
Resource Management System ` un’applicazione campione sviluppata dalle indu-
e
20

32. 2.2 L’architettura Grid di EGEE
strie partner della Sun Microsystems. L’applicazione utilizza tecnologie J2EE ed
` utilizzata per tracciare risorse per progetti cui partecipano le industrie stesse.
e
Comunque, l’applicazione pu` essere adattata per venire incontro a molte esigen-
o
ze, come ad esempio vari tipi di applicazioni e-commerce. Il CE ` formato da due
e
componenti:
• EDG: ` la componente che funge da gateway fra il Resource Broker (gestore
e
delle risorse della Grid) e il Resource Management System (RMS) o diret-
tamente il Local Batch System che accetta e processa i job, tipicamente su
cluster realizzati con PC di tipo “commodity”. Esempi di Batch Systems
usati nella GRID sono: LSF, PBS, torque;
• Jobmanager: ` l’applicazione che si interfaccia all’RMS o direttamente
e
al Local Batch System durante l’esecuzione del job fornendo, tramite il
Workload Manager, le informazioni sullo stato del job;
Oltre al CE, nel meccanismo di sottomissione dei job alla Grid, prendono parte
anche altre componenti e applicazioni come:
• Local Centre Authorization Service (LCAS): ` il servizio che rilascia
e
l’autorizzazione per la richiesta fatta al sito dalla Grid. La decisione viene
presa basandosi sulle credenziali dell’utente e le specifiche del job. Le VO
autorizzate sono inserite nella Grid Access Control List (GACL). Questo
servizio tiene conto anche di eventuali liste nere;
• Local Credential Mapping Service (LCMAPS): ` un servizio che fornisce
e
tutte le credenziali necessarie al job che ` stato accettato nel sito;
e
• Job Repository: ` un archivio locale che contiene le informazioni sui job in
e
esecuzione o su quelli che sono stati eseguiti. Le informazioni sono ottenute
dal LCMAPS e dal Jobmanager (` l’interfaccia verso il Resource Manage-
e
ment System o verso il Batch System e fornisce informazioni aggiornate al
Workload Manager sullo stato del job). Queste informazioni sono utilizzate
21

33. 2.2 L’architettura Grid di EGEE
anche per prevedere la durata di esecuzione del job (parametro utilizzato
dal Resource Broker per lo scheduling). Il Job Repository non ` accessibile
e
dall’esterno del sito;
• Local Batch System (scheduler): ` il servizio che accetta e processa i job
e
diretti ad un insieme di nodi di elaborazione e si occupa di distribuire il
carico di lavoro tra loro;
• Information Provider: ` il servizio che pubblica le informazioni circa lo
e
stato del CE acquisendole dal Local Batch System e propagandole all’ap-
posito Information System. Queste informazioni possono essere utilizzate
anche dal Workload Management System per trovare il miglior sito Grid per
l’esecuzione di uno specifico job;
2.2.1.1 CE-CREAM
CREAM (Computing Resource Execution And Management) ` un servizio leg-
e
gero che implementa tutte le operazioni di livello CE. Presenta una Web Service-
based Interface ed ` implementato come una estensione Java-Axis servlet (svi-
e
luppato all’interno dell’Apache Tomcat container). L’obiettivo di CREAM ` ga-
e
rantire l’interoperabilit` con client scritti in vari tipi di linguaggio e operanti su
a
differenti computer platform. L’interfaccia ` definita usando Web Serice Descrip-
e
tion Language (WSDL) e gli utenti possono generare il proprio client CREAM
molto semplicemente. CREAM supporta:
• Job Submission;
• job di tipo batch e MPI;
• delegazione automatica e manuale dei job;
• Job Cancellation;
• Job Info configurabili con livello di filtraggio basato sul tempo di sottomis-
sione e/o stato del job;
22

34. 2.2 L’architettura Grid di EGEE
• Job List;
• GSI based authentication;
• VOMS based authorization;
• Job Purge (per terminare i job);
• possibilit` (per gli amministratori) di disabilitare nuove sottomissioni.
a
Inoltre CREAM pu` essere usato:
o
• dal WMS, tramite il servizio ICE (Interface to CREAM Environment);
• da un generico client (ad esempio un software di livello utente che sottomette
job direttamente verso il CREAM CE);
• tramite C++ command line interface e JAVA clients.
2.2.2 Workload Management System
Il processo che prevede la selezione di risorse in base alle richieste dell’applicazione
` chiamato “resource matching”. In un ambiente Grid dinamico, dove le risorse
e
possono cambiare, ` necessario rendere automatica la loro ricerca. A tal proposito
e
` stato sviluppato il Workload Management System o WMS, il componen-
e
te middleware che ha il compito di trovare e gestire le risorse Grid in modo da
garantire l’esecuzione dell’applicazione ed allo stesso tempo un utilizzo non ecces-
sivo delle risorse stesse. Per svolgere questi compiti, il WMS interagisce con altri
servizi Grid e pi` precisamente con:
u
• Information System: per avere un immagine delle caratteristiche e dello
stato delle risorse Grid.
• Replica Manager: per ottenere informazioni sulla locazione e sui costi di
accesso dei dati.
• Computing Element: per sottomettere job al Local Resource Manage-
ment System.
23

35. 2.2 L’architettura Grid di EGEE
• Authentication and Authorization Services: per l’autenticazione e
l’autorizzazione della richiesta dell’utente attraverso le sue credenziali.
Il WMS ` composto da molti componenti importanti che interagiscono tra loro e
e
fanno s` che la gestione delle risorse sia completamente trasparente all’utente. Tra
ı
questi elementi i pi` importanti sono il Workload Manager o WM ed il Resour-
u
ce Broker o RB. Il WM ` il nucleo di tutto il sistema. A partire da una richiesta
e
valida esso deve intraprendere l’azione corretta. Per fare ci` esso deve interagire
o
con gli altri componenti, che si occupano delle richieste specifiche. Questi com-
ponenti sono chiamati helper ed hanno il compito di ricevere un file codificato in
formato JDL (Job Description Language) e di restituirlo completo delle specifiche
relative all’espletamento dell’azione richiesta. Per esempio, se la richiesta ` quella
e
di trovare una risorsa per un job, l’input ` un’espressione JDL fatta dall’utente
e
con la descrizione del job, mentre l’output sar` la stessa espressione con l’aggiunta
a
del CE scelto per l’esecuzione in base allo stato delle risorse Grid. Fra tutti gli
helper del WM, il pi` importante ` sicuramente il Resource Broker. A partire da
u e
un’espressione JDL che rappresenta la richiesta di sottomissione del job, la sua
principale funzione ` quella di trovare la risorsa (o le risorse) che meglio soddisfino
e
la richiesta. Il Resource Broker pu` essere visto come l’unione di due moduli: il
o
primo che restituisce tutte le risorse che soddisfano l’espressione; il secondo che
classifica le risorse ottenute e trova la migliore, basandosi sulle informazioni dei
vari CE e sulle informazioni ottenute attraverso il Replica Manager. Inoltre il
WMS comprende i moduli del middleware responsabili della distribuzione e del-
la gestione dei job attraverso le risorse di GRID, in maniera tale da garantire la
corretta esecuzione delle applicazioni. L’esecuzione di un job comporta due tipi
di richieste: la sottomissione e la cancellazione; in particolare sottomettere un
job significa delegare la sua esecuzione ad un appropriato CE tenendo conto dei
requisiti necessari per portare a buon fine l’operazione. La decisione riguardo la
migliore risorsa utilizzabile ` il risultato del processo di matchmaking tra le ri-
e
chieste e le risorse disponibili; quest’ultimo aspetto dipende sia dallo stato della
24

36. 2.2 L’architettura Grid di EGEE
risorsa considerata che dalle politiche di utilizzo definite dal suo amministratore
o dalla VO a cui l’utente appartiene. Lo scheduling dei job ` un’altra funzione
e
del WM. Anche in questo caso possono essere applicate differenti politiche, come
scegliere la risorsa pi` vicina (eager scheduling) o rimandare la sottomissione fino
u
a quando la risorsa non diventi disponibile (lazy scheduling). Dal punto di vista
del processo di matchmaking questi due tipi di politiche implicano, nel primo caso,
la scelta tra diverse risorse possibili, nel secondo, la scelta tra diversi job. L’archi-
tettura interna del WM si adatter` all’applicazione delle diverse politiche possibili
a
attraverso l’implementazione di plugins, operazione questa che dovr` risultare fa-
a
cile e senza conseguenze sul corretto funzionamento del WMS. Tali cambiamenti
potranno essere anche adottati in seguito ad eventi particolari (come il cambia-
mento dello stato di Grid nel suo insieme) ossia in seguito ad eventi non definiti
a priori. Il meccanismo che permette l’applicazione delle diverse politiche e la se-
parazione tra le informazioni riguardanti le risorse e quelle riguardanti il loro uso,
` l’Information Supermarket (ISM). L’ISM consiste di un archivio di informazioni
e
sulle risorse accessibile in sola lettura dal modulo adibito al matchmaking e il cui
aggiornamento ` il risultato di notifiche provenienti dalle risorse o da verifiche ef-
e
fettuate dal WMS. L’ISM potr` essere configurato in maniera tale da far innescare
a
il processo di matchmaking da particolari eventi verificatisi. Queste funzionalit`
a
migliorano la modularit` del software e il supporto a politiche analoghe al lazy
a
scheduling. Un’altra possibilit` di gLite ` quella di conservare una richiesta di
a e
sottomissione per un determinato periodo di tempo, se le risorse richieste non so-
no immediatamente disponibili. Questa eventualit` si potr` verificare adottando
a a
lo hearing scheduling e verr` affrontata ripetendo la richiesta periodicamente o
a
attendendo la notifica da parte delle risorse richieste che giungeranno all’ISM. Il
modulo che implementa questa funzione ` chiamato Task Queue (TQ). Ci sono
e
diverse interazioni tra i componenti interni al WMS e tra questi ed i servizi esterni
come il Logging and Bookkeeping e il Data Management. Queste interazioni sono
possibili attraverso l’utilizzo di particolari interfacce chiamate Web Services.
25

37. 2.2 L’architettura Grid di EGEE
2.2.3 User Interface
La User Interface (UI) ` il componente dell’infrastruttura Grid che permette
e
agli utenti l’accesso a tutti i servizi offerti dal WMS, che ` l’unico con il quale
e
interagisce. La UI permette di specificare diversi tipi di richieste, intese come
operazioni su oggetti (job o gruppi di job legati insieme da delle dipendenze). Tali
operazioni sono ad esempio la sottomissione di job, la cancellazione, la richiesta di
informazioni e la richiesta dell’output. Per fare tutto ci` la UI si basa sul linguaggio
o
JDL, concepito per descrivere le caratteristiche, le richieste e le preferenze di un
oggetto. JDL ` basato sul Classified Advertisement Language definito dal progetto
e
Condor [29] che permette la gestione di espressioni di tipo DAG (espressioni che
identificano le dipendenze tra i job). Le operazioni permesse sono:
• la sottomissione di job e la specifica di espressioni DAG per l’esecuzione su un
CE remoto, includendo la ricerca automatica delle risorse, la comunicazione
con il job in esecuzione e l’eventuale restart di un job da un precedente punto
di checkpoint;
• la ricerca delle risorse che possono eseguire uno specifico job, in accordo con
i suoi requisiti;
• la cancellazione del job sottomesso;
• la restituzione dell’output;
• la restituzione degli stati di checkpoint.
Tutti questi servizi sono resi disponibili attraverso un’interfaccia a linea di coman-
do, un’interfaccia grafica Java e delle API che permettono la creazione dinamica
di file JDL.
26

38. 2.2 L’architettura Grid di EGEE
2.2.4 Job Wrapper
Il Job Wrapper (JW) ` uno script generato dal WMS per ogni richiesta di
e
sottomissione di job; questo script ` quello che viene sottomesso al LRMS del CE
e
ed ` responsabile di creare l’ambiente per l’esecuzione del job, che comprende:
e
• il trasferimento dei file di input;
• la definizione delle variabili d’ambiente;
• l’avvio del job con gli argomenti specificati;
• l’upload e la registrazione dei file di output del job attraverso il Replica
Manager;
• il trasferimento dell’output dopo il completamento del job;
• la pulizia dell’area di esecuzione delle variabili.
2.2.5 Storage Element
Lo Storage Element (SE) ` l’interfaccia Grid al sistema di archiviazione di
e
massa Mass Storage System (MSS). L’accesso ai dati ed il loro trasferimento `
e
implementato attraverso un protocollo particolare: il GridFTP. Nelle specifiche
di esecuzione di un job l’utente pu` scegliere se trasferire su un SE e registrare
o
nel servizio di Catalog della Grid alcuni file di output del suo job. A tale scopo
vanno specificati il nome dello Storage Element desiderato ed il Logical File Name
(LFN) del file, con il quale il file verr` identificato nella Grid. Scegliere un SE per
a
il salvataggio dei propri file vincola il Resource Broker in modo da scegliere, per
l’esecuzione del job, il CE pi` vicino allo SE in questione.
u
2.2.6 Data Management System
La replicazione dei dati su pi` nodi all’interno della Grid, ` utilizzata per ridurre
u e
la latenza durante l’accesso ai dati, aumentare le prestazioni della Grid stessa e
permettere un’accesso veloce e trasparente agli utenti. Tuttavia, per mantenere le
27

39. 2.2 L’architettura Grid di EGEE
varie copie dei dati allineate e registrarne la loro posizione, viene utilizzato un siste-
ma di gestione dei dati di alto livello. Nella Grid europea il Data Management
System (DMS) ` implementato attraverso vari servizi:
e
• Replica Location Service (RLS): utilizzato per localizzare le copie nella
Grid ed assegnare i nomi fisici dei file;
• Replica Metadata Catalog (RMC): utilizzato per richiedere ed assegnare
i nomi logici ai file;
• Replica Optimization Service (ROS): utilizzato per individuare la mi-
gliore copia cui accedere;
• R-GMA: ` l’EDG Information Service che fornisce le informazioni sui SE e
e
CE;
• Globus Libraries: permettono il buon funzionamento del protocollo di
trasferimento GridFTP;
• EDG Network Monitoring Services: sono dei servizi che permettono di
ottenere statistiche e caratteristiche della rete;
• Storage Services: sono i servizi di memorizzazione dei dati.
Il DMS pu` essere suddiviso in tre gruppi di servizi riguardanti l’accesso ai dati:
o
Storage Element, Catalog Services e Data Scheduling. La loro funzione sar` quella
a
di gestire le repliche dei file dell’utente. I servizi di Data Scheduling forniranno
le interfacce necessarie all’allocazione dei dati, mentre il loro accesso avverr` at-
a
traverso l’SE. Nello Storage Element i metodi di accesso saranno prima di tutto
definiti a seconda dal tipo di supporto di memorizzazione che verr` utilizzato,
a
inoltre si utilizzeranno due tipi di interfacce (Figura 2.2): la SRM dedicata alle
operazioni di controllo e gestione e la Posix-like File I/O che permetter` l’accesso
a
e la modifica dei files da parte dell’utente. Un altro aspetto della gestione dei dati
riguarda il loro trasferimento con l’introduzione del File Transfer Service (FTS).
28

40. 2.2 L’architettura Grid di EGEE
Figura 2.2: Interfacce SRM e Posix-like File I/O.
Questo si occupa del trasferimento fisico dei dati da un punto all’altro della griglia
permettendo ai siti coinvolti di poter controllare l’utilizzo delle risorse di rete. Una
caratteristica importante dell’FTS ` che tratta solo file fisici, per cui successive
e
trasformazioni dei dati che porteranno alla creazione, ad esempio, di file logici sa-
ranno fatte da servizi di livello superiore. Il processo di trasferimento ` eseguito,
e
dall’utente, in maniera analoga alla sottomissione di un’applicazione a GRID. In
FTS la descrizione del job da sottomettere sar` costituita da un unico file in cui
a
saranno descritti gli indirizzi dei file da trasferire e la loro destinazione, i para-
metri necessari per impostare correttamente l’operazione e autenticare l’utente.
Una volta che il job ` stato sottomesso a FTS, il trasferimento dei dati avverr`
e a
utilizzando un “canale”, ossia una pipe specificamente creata all’interno della rete.
Questo sistema ha un duplice vantaggio: prima di tutto permette un’ottimizzazio-
ne dell’utilizzo della banda disponibile, poi rende il trasferimento completamente
trasparente per l’utente: la configurazione e la definizione della topologia dei ca-
nali ` controllata dai siti o dalle VO, per cui l’utente, dopo aver sottomesso il job,
e
delegher` a queste la gestione del trasferimento. All’interno del Data Manage-
a
ment ` anche incluso il servizio del Package Manager, incaricato di automatizzare
e
i processi d’installazione, aggiornamento, configurazione e rimozione di pacchetti
29

41. 2.2 L’architettura Grid di EGEE
software provenienti da un’area condivisa nel sito GRID.
2.2.7 Information System
L’Information System (IS), garantisce due diversi servizi.
• Publish Service: permette agli utenti di pubblicare delle informazioni at-
traverso un R-GMA Produttore. Le informazioni pubblicate dai “produtto-
ri” vengono mantenute fino a quando non ci sono pi` richieste da parte dei
u
“Consumatori”. A tale scopo sono stati introdotti dei database relazionali
che provvedono a cancellarle periodicamente.
• Consumer Service: permette di accedere alle informazioni pubblicate at-
traverso i vari R-GMA Produttori. Nella pratica si traduce in espressioni
SQL da sottomettere ai database informativi, in modo da realizzare ricerche
globali o mirate ai singoli Produttori.
2.2.8 Virtual Organization Membership Server
Il Virtual Organization Membership Server (VOMS) ` un database di utenti
e
autorizzati ad utilizzare le risorse della VO. Il server ` utilizzato per due scopi
e
principali: il primo ` quello di ottenere informazioni sulle risorse a disposizione
e
della VO, tramite la lista degli utenti, il secondo consiste nel fornire agli utenti
le credenziali da utilizzare per ottenere l’accesso alle risorse della VO. In questo
modo, dopo una prima comunicazione, non ne sono necessarie altre tra il servizio
VOMS e il sito. Questo tipo di servizio rappresenta un compromesso tra i requisiti
di sicurezza del sistema e la fruibilit` delle risorse. Attraverso il VOMS, infatti,
a
ogni utente crea un proxy di durata prefissata che gli permette di utilizzare le
risorse della VO alla quale ` registrato senza dover comunicare le sue credenziali
e
ad ogni accesso.
30

42. 2.3 EGEE Middleware
2.2.9 MyProxy Server
Il MyProxy Server (MPS) ` un servizio che permette di salvare delle credenziali
e
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. Il vantaggio del
o
MyProxy Server ` che pu` essere utilizzato per rinnovare un normale proxy, in mo-
e o
do da rendere possibile l’esecuzione di job molto lunghi, che altrimenti verrebbero
abortiti alla scadenza del proxy.
2.3 EGEE Middleware
L’architettura di un sistema definisce gli scopi, le modalit` di funzionamento e le
a
interazioni fra i suoi componenti fondamentali. A questo scopo serve un architet-
tura “aperta”, in continua evoluzione, che fissi regole ben precise che soddisfino
i bisogni di estensibilit` ed interoperabilit` richieste da Grid. A tal proposito il
a a
middleware rappresenta un componente cruciale. Con il termine inglese “midd-
leware” si intende un insieme di programmi e procedure che fungono da intermedia-
ri tra diverse applicazioni. Sono spesso utilizzati come supporto per applicazioni
distribuite complesse. L’utilizzo di uno strato software aggiuntivo, il middleware
appunto, consente 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 consentendo indipendenti metodi di control-
lo e gestione locale delle risorse, abilitino le interazioni tra i diversi componenti
del sistema e definiscano i meccanismi di base attraverso cui le risorse condivise
possano essere viste e utilizzate dagli utenti. I middleware API (Application Pro-
gram Interface) e SDK (Software Development Kit) aiutano la rapida costruzione
di applicazioni che utilizzino al meglio le potenzialit offerte da Grid. API definisce
dei metodi standard per invocare uno specifico insieme di funzionalit`. Questo in-
a
sieme pu` essere dato da una chiamata ad una subroutine o da metodi di oggetti
o
(Object-Oriented API). SDK sono degli insiemi di codice che vengono utilizza-
31

43. 2.3 EGEE Middleware
ti dagli sviluppatori per implementare specifiche funzionalit` nei programmi che
a
realizzano.
2.3.1 gLite: La Futura Generazione di Middleware EGEE
2.3.1.1 L’idea
Per qualsiasi impegno sul Grid Computing, il middleware rappresenta sempre
un componente cruciale. Per EGEE, era stato deciso che un approccio a due fasi
poteva essere la soluzione migliore. Originariamente, il progetto EGEE ha usato il
middleware basato sul lavoro del suo predecessore (l’European DataGrid o EDG).
Questo opportunamente modificato in seguito nel middleware LCG ` stato usato
e
nella prima infrastruttura di EGEE. Parallelamente, EGEE ha sviluppato e re-
ingegnerizzato gran parte della struttura di tale middleware ed ha prodotto una
nuova soluzione, chiamata gLite [30], che utilizza attualmente (Figura 2.3). La
struttura di 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 componenti provenienti dai migliori progetti di middleware al momento
disponibili, quali Condor e GTK, 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
a
di fornire servizi fondamentali che facilitino la realizzazione di applicazioni Grid
provenienti da tutti i campi.
2.3.1.2 Lo sviluppo
Molti centri di ricerca sia universitari che industriali collaborano allo sviluppo
del software, organizzati in diverse aree di ricerca: Security, Accesso alle Risor-
se (Computing e Storage Elements), Accounting, Data Management, Workload
Management, Logging and Bookkeeping, Information and Monitoring, 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 documentazione in linea sia con seminari e
32

44. 2.3 EGEE Middleware
Figura 2.3: Il middleware gLite.
tutorial on line. La formazione inoltre ` disponibile sul testbed per l’attivit` di di-
e a
vulgazione, GILDA. Essa ` caratterizzata dalla propria Autorit` di Certificazione
e a
(CA), e dalla possibilit` di permettere agli utenti e agli amministratori di sistema
a
di testare tutti gli aspetti di sviluppo ed utilizzo del middleware gLite.
2.3.1.3 Il software
I servizi Grid di gLite adottano l’Architettura Orientata ai Servizi, il che significa
che con essi diventa molto semplice collegare il software ad un’altro servizio Grid
facilitando la compatibilit` con i gli standard Grid di nuova generazione, per esem-
a
pio la Web Service Resource Framwork (WSRF) di OASIS e la Open Grid Service
Architecture (OGSA) del Global Grid Forum. La struttura di gLite concepita co-
me un sistema modulare, abilitando gli utenti a sviluppare servizi differenti idonei
alle loro esigenze, piuttosto che costringerli ad usare l’intero sistema. Questo `
e
33

45. 2.4 Ottimizzazione delle risorse
stato concepito per permettere agli utenti di adattare il sistema ad ogni specifica
esigenza. Basandosi sull’esperienza dello sviluppo del middlware EDG e LCG,
gLite aggiunge nuove funzionalit` in tutti i livelli della struttura software. In par-
a
ticolare assicura una maggiore sicurezza, maggiore interfacciabilit` per la gestione
a
dei dati e la sottomissione dei job, una struttura del sistema rivisitata, e molte
altre funzionalit` che rendono facile ed efficente l’uso di gLite. Gi` distribuito su
a a
varie Griglie di test e di pre-produzione dell’intero progetto, i risultati di gLite sui
servizi di pre-produzione sono in aumento.
2.4 Ottimizzazione delle risorse
Le tematiche prese in esame nell’ambito delle attivit` di ricerca relative alla Grid
a
hanno come oggetto principalmente lo studio di alcuni problemi relativi alla ot-
timizzazione delle risorse Grid, sullo scheduling di job distribuiti e in particolare
all’ottimizzazione delle code (queue ranking). Nella teoria dello scheduling su Grid
si assume che ogni job, per essere eseguito, richieda un processore per un certo
intervallo di tempo chiamato tempo di processamento. Questa assunzione rimane
valida per tutti i modelli di sistemi di processamento classici ed in particolare per i
sistemi manifatturieri come le macchine parallele, dove n job devono essere proces-
sati contemporaneamente. Il job j richiede una singola operazione che pu` essere
o
eseguita su una qualsiasi delle m macchine o eventualmente su una delle macchi-
ne appartenenti ad un certo sottoinsieme Mj di m. Lo scheduling ` un campo
e
tradizionale dell’informatica, ma nonostante siano state studiate molte tecniche
per numerose tipologie di sistemi (da uniprocessore a multiprocessore e ai sistemi
distribuiti), le caratteristiche tipiche delle griglie di dati rendono molti di questi
approcci inadeguati. Infatti, mentre nei sistemi tradizionali le risorse e i job sono
sotto il diretto controllo dello schedulatore, le risorse delle griglie sono geografi-
camente distribuite, di natura eterogenea e appartengono a diversi individui e/o
organizzazioni, ciascuno con le proprie politiche di scheduling, di modelli di costo
di accesso con carichi di lavoro e disponibilit` di risorse che variano dinamicamen-
a
34

46. 2.4 Ottimizzazione delle risorse
te nel tempo. La mancanza di un controllo centralizzato, insieme alla presenza di
utenti che generano job, molto diversi l’uno dall’altro, rendono la schedulazione
molto pi` complessa di quella dei sistemi di calcolo tradizionali. I recenti sviluppi
u
nei sistemi di produzione e di comunicazione hanno richiesto un nuovo sforzo per
costruire modelli in grado di descrivere approcci alternativi per la schedulazione
delle code. In particolare, si fa riferimento a sistemi in cui l’esecuzione di un job
richiede la copresenza di pi` risorse che ne richiede la disponibilit` simultanea.
u a
Per risolvere tali problematiche ` stato necessario trasformare i job ossia intro-
e
durre nuovi prototipi noti come job parametrici nei quali si assume che ogni job,
adeguatamente “frammentato” in n subjob, possa richiedere per la sua esecuzione
pi` processori contemporaneamente. Inoltre, considerando il fatto che la Grid pre-
u
sa in esame utilizza un sistema informativo (IS) basato su policy statiche, spesso
le informazioni in esso contenute non sono in alcun modo aderenti a quanto sta
veramente accadendo. Inoltre, nessuna informazione viene pubblicata in relazione
alle performance di calcolo istantaneo o di elaborazione complessiva. Ci` rende
o
il problema dello scheduling delle code un problema di ottimizzazione di risorse
eterogenee la cui ottimizzazione aumenterebbe significativamente le velocit`, le
a
performance e il retrieve dei risultati dei job sottomessi in griglia.
35

47. Capitolo 3
GriF: Algoritmi Adattivi e
Queue Ranking
Penso che la cosa pi` misericordiosa al mondo sia l’incapacit`
u a
della mente umana di mettere in relazione i suoi molti contenuti.
Viviamo su una placida isola d’ignoranza in mezzo a neri mari d’infinito
e non era previsto che ce ne spingessimo troppo lontano.
Le scienze, che finora hanno proseguito ognuna per la sua strada,
non ci hanno arrecato troppo danno: ma la ricomposizione del quadro d’insieme
ci aprir`, un giorno, visioni cos` terrificanti della realt` e del posto
a ı a
che noi occupiamo in essa, che o impazziremo per la rivelazione
o fuggiremo dalla luce mortale nella pace e nella sicurezza di una nuova et` oscura.
a
- Howard Phillips Lovecraft -
3.1 Introduzione
Dal desiderio di ottimizzare l’uso della Grid ` nata l’idea di progettare e im-
e
plementare GriF (Grid Framework), un Framework intelligente basato su una
Service-Oriented Architecture (SOA) dedicata alla gestione e la sottomissione
dei job da distribuire in griglia ottimizzandone la fruibilit`, la velocit` di esecu-
a a
zione e il recupero (nonch´ il controllo) dei risultati. Dalla vasta disponibilit`
e a
delle risorse della Grid e dal crescente numero dei suoi possibili fruitori nasce il
problema affrontato nella mia Tesi: come ` possibile ottimizzare la gestione delle
e
risorse di Grid in modo da soddisfare il pi` equamente possibile le richieste. Per
u
questo motivo il mio lavoro di Tesi si ` concentrato sullo studio della gestione delle
e
code di una VO e la ricerca dei criteri per la loro ottimizzazione. Partendo da
un’analisi teorica di come vengono gestite le code di una VO ` stata analizzata
e
36

48. 3.2 SOA e Framework
una strategia per ottimizzare la sottomissione dei job attraverso due metodolo-
gie informatiche quali il ranking e gli algoritmi adattivi. Una volta precisati gli
ambiti di tali metodi si ` affrontato lo studio dettagliato del loro impatto sulla
e
disponibilit`, raggiungibilit` e performance. Portando avanti tale analisi abbia-
a a
mo dovuto affrontare le problematiche relative alla gestione delle code di job, alla
classificazione degli utenti, all’assegnazione delle risorse, alla parametrizzazione
dei job, alle code libere e le relative CPU, al retrive dei risultati dei job nonch´
e
all’introduzione di una base di dati per la raccolta, in tempo reale, di tutte le in-
formazioni provenienti dalla griglia. Tutto questo ` stato fatto facendo riferimento
e
alla Grid di EGEE accessibile alla VO COMPCHEM e su questo si ` proceduto
e
a configurare l’ambiente di sviluppo di GriF installando Java, Tomcat, Axis,
MySQL e garantendo l’interoperabilit` attraverso un Framework basato su SOA.
a
3.2 SOA e Framework
Il settore del middleware sta vivendo un momento molto importante grazie al-
l’avvento di Framework, Web Service e SOA, tecnologie in grado di garantire
il miglioramento della produttivit` tramite il ri-uso di componenti applicative.
a
La globalizzazione e la straordinaria evoluzione delle tecnologie dell’informazione
e delle comunicazioni stanno, infatti, producendo rapidi e continui cambiamen-
ti. Con l’avvento delle SOA sta diventando obsoleto il concetto di applicazione
mentre diventa fondamentale quello di “Servizio” inteso come una funzionalit` di
a
business realizzata tramite “componenti” che rispettano un’interfaccia standard.
Il passaggio dalla struttura tradizionale dei prodotti software a quella innovativa
sta avvenendo grazie ad alcuni passi fondamentali compiuti a livello internaziona-
le negli ultimi vent’anni, come la definizione e l’accettazione di standard aperti,
accompagnati da crescita e affidabilit`, di prestazioni e di economicit` d’uso delle
a a
reti di comunicazione, su cui si sono affermati Internet e i sistemi distribuiti. La
creazione di un’unica interfaccia di programmazione per accedere a qualsiasi fonte
di dati, dai database relazionali alle pagine XML, ha rappresentato una tappa
37