tesi specialistica - l'ottimizzazione delle risorse della grid di egee mediante un framework...
DESCRIPTION
13 Maggio 2010, tesi specialistica in informatica. L'ottimizzazione delle risorse della Grid di EGEE mediante un Framework intelligente basato su SOA.TRANSCRIPT
Universita degli Studi di PerugiaFacolta di Scienze Matematiche, Fisiche e Naturali
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 Lagana
Correlatori:
Dr. Leonardo Pacifici
Dr. Carlo Manuali
Anno Accademico 2008/2009
A coloro che hanno creduto in me.
Costruire
Chiudi gli occhiimmagina una gioiamolto probabilmentepenseresti a una partenza
ah si vivesse solo di inizidi eccitazioni da prima voltaquando tutto ti sorprende enulla ti appartiene ancora
penseresti all’odore di un libro nuovoa quello di vernice frescaa un regalo da scartareal giorno prima della festa
al 21 marzo al primo abbraccioa una matita intera la primaveraalla paura del debuttoal tremore dell’esordioma tra la partenza e il traguardo
nel mezzo c’e tutto il restoe tutto il resto e giorno dopo giornoe giorno dopo giorno esilenziosamente costruiree costruire e potere e sapererinunciare alla perfezione
ma il finale e di certo piu teatralecosı di ogni storia ricordi solola sua conclusione
cosı come l’ultimo bicchiere l’ultima visioneun tramonto solitario l’inchino e poi il sipariotra l’attesa e il suo compimentotra il primo tema e il testamento
nel mezzo c’e tutto il restoe tutto il resto e giorno dopo giornoe giorno dopo giorno esilenziosamente costruiree costruire e sapere e potererinunciare alla perfezione
ti stringo le manirimani quicadra la nevea breve
Sommario
La possibilita di valutare la qualita del lavoro di un utente o quanto un servizio
offerto puo essere innovativo e performante, riveste una grande importanza in am-
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 qualita (Quality of Service/Quality of User) vengono ottenute
direttamente da Grid. Il Framework preso in esame e GriF. L’idea alla base di
GriF e la creazione di un Framework collaborativo che operi in ambiente Grid e sia
in grado di consentire l’esecuzione di programmi richiedenti alte capacita compu-
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 e quello di porre solide
basi su cui sviluppare un robusto modello di creditizzazione.
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.
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
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’e un’architettura SOA . . . . . . . . . . . . . . . . . . . 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 Perche un Framework? . . . . . . . . . . . . . . . 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
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 Entita-Relazione . . . . . . . . . . . . . . . . . . . 65
4.2.2 Il motore InnoDB . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.2.1 Funzionalita del motore InnoDB di MySQL . . . . 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 Perche programmare in Shell . . . . . . . . . . . . . . . . . 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
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
Elenco delle tabelle
1.1 Ere computazionali. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
v
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
Capitolo 1
Introduzione al Grid
Computing
Un giorno le macchine riusciranno a risolvere tutti i problemi,ma mai nessuna di esse potra porne uno.
- 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 meta degli anni novanta con
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 e oggi esteso alla chimica, alla medicina, alla biologia,
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
1.1 Grid Computing
Figura 1.1: Esempio di sistema Grid.
tual Organization) un accesso coordinato e controllato a una grande quantita
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, e pari al
5% della sua reale potenzialita. Il modello prevede che le risorse di calcolo ven-
gano fornite da diverse entita in modo da creare un’infrastruttura in media piu
efficiente rispetto a quella della singola entita.
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 comunita scientifica internazionale in tema di calcolo
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
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
parita di costo. In Italia uno dei primi cluster di workstation basato su processori
commodity, noto come “INFN Farm” e stato realizzato nel 1989 dall’INFN in col-
laborazione con il CERN. Esso mostro al mondo scientifico come questa tecnologia
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 piu bassi di quelli delle tecnologie precedenti.
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 Universita 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 meta degli anni ’90 nel settore delle telecomunicazioni, i costi cominciarono a
decrescere ancora piu rapidamente di quanto previsto dalla legge di Moore per
CPU e dischi (Tabella 1.1). Alla fine degli anni ’90 erano quindi disponibili, su
una rete a banda larga che collegava le universita e i centri di ricerca con velocita
di trasmissione sempre piu elevata e costi sempre piu ridotti, un numero crescente
di risorse computazionali e di memoria.
Si pose quindi il problema dello sviluppo di una nuova tecnologia che per-
mettesse alla comunita scientifica di sfruttare e condividere in modo dinamico le
risorse distribuite per accelerare i processi innovativi ed aumentare la propria ef-
3
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 comunita scientifica inter-
nazionale si basa sullo sviluppo di servizi e protocolli standard per la condivisione
di risorse distribuite nascondendone all’utente l’eterogeneita.
Era Relazione tra Architettura di Architettura dicalcolatori 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 e un software studiato per risolvere problemi legati allo
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 necessita di sacrificare le autonomie locali. Il Toolkit
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
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 attivita utili per la comunita scientifica;
• l’ottimizzazione della gestione dei carichi di lavoro su risorse computazionali
distribuite a livello geografico.
Inoltre l’INFN, in collaborazione con il CERN, avvio nel 2001 il progetto Data-
TAG [7] che affrontava il problema dell’interoperabilita con le Grid in sviluppo
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 attivita di ricerca e sviluppo sulle Grid fu finanziato da quasi
tutti i Paesi e dalla Comunita Europea che gia nel biennio 2001/03 del Quinto
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’universita di Perugia) che coinvolgeva vari istituti
di ricerca e Universita, il progetto di Grid per la finanza (EGrid) [8], il progetto
Grid per il supercalcolo al sud SPACI [9], il progetto Grid Inter-dipartimentale a
Napoli e altri progetti minori. Si puo quindi tranquillamente affermare che i mag-
giori Enti di ricerca (INFN, CNR, INAF ed ENEA ) e molte Universita negli ultimi
anni sono stati progressivamente coinvolti nelle attivita di sviluppo e utilizzo della
5
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 e l’acronimo di Enabling Grids for E-sciencE e puo essere
considerato il successore di DataGrid e DataTAG che ha portato alla costruzione
della prima Grid Europea di produzione. Essa e stata un’impresa storica; vi han-
no partecipato piu di 70 Enti ed Istituzioni scientifiche appartenenti a 26 Paesi
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 e andato a sostituire quello esistente
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 comunita scientifica Europea, chiamata ad organizzarsi in tempi brevi
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 puo collegare alla Cyber-Infrastruttura americana proposta dalla Natio-
nal Science Foundation e alle Grid asiatiche in costruzione in Cina e Giappone.
Esso e un passo decisivo verso la costruzione di una Grid mondiale, necessaria alle
moderne societa che mettono la conoscenza alla base dello sviluppo. Si tratta di
una svolta epocale dal punto di vista scientifico e tecnologico, poiche le Grid di
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 Universita (come
Calabria, Lecce, Napoli e Perugia), alcuni enti (come CNR, ENEA, GARR), al-
6
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 puo
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 funzionalita costantemente incrementate. Cio a reso possibile la
completa automatizzazione degli strumenti per l’installazione del middleware e lo
sviluppo di sistemi per il controllo. A seguito di tutto cio, infatti, gli utenti Grid
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 funzionalita tramite la
piattaforma di prova (testbed) GILDA [16] messa a punto dall’INFN ed utilizzata
da EGEE per le attivita di divulgazione [17].
1.1.3 Middleware
Secondo la definizione di Ian Foster [19] una Grid e un’infrastruttura hard-
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
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 e l’infrastruttura di sicurezza e fornisce un accesso
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 (puo anche
implementare un livello di sicurezza). I due strati successivi sono uno strato midd-
8
1.2 Le applicazioni
leware a livello utente, costituito da Resource broker e/o da utilita di pianificazio-
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 e il gestore delle transazioni, ovvero un
componente che e interposto tra l’utente e il gestore del database, o l’applicazione
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 piu efficiente.
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 piu semplice la manutenzione,
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 intensita di dati);
• Collaborative Computing (calcolo collaborativo).
9
1.2 Le applicazioni
Di seguito vengono illustrate le caratteristiche principali dei 5 settori.
Distributed Supercomputing
La griglia e usata per schedulare un numero limitato di task pesanti (tra loro indi-
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 e usata per schedulare un largo numero di task indipendenti o scarsa-
mente accoppiati, con l’obiettivo di utilizzare i cicli di processori di qualsiasi tipo
inutilizzati per ottenere lavoro utile. L’obiettivo principale e quello di massimiz-
zare il throughput finale.
On-Demand Computing
La griglia e usata per accedere a risorse non disponibili di cui non e conveniente,
o possibile, disporre a lungo termine e localmente. L’obiettivo principale e quello
di ottimizzare il rapporto costo-prestazione.
Data Intensive application
La griglia e utilizzata per elaborare quantita massicce di dati indipendentemente
da dove essi sono memorizzati e dove si localizza l’utente. L’obiettivo e sintetizza-
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 e quello di garantire Quality of
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 interoperabilita e affidabilita tra i sistemi
(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
1.2 Le applicazioni
e guidata da enti e associazioni creati dalla partecipazione di un gran numero di
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 e una partnership tra
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 comunita degli utenti di Grid. L’OGF ha finora prodotto un discre-
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 e la Distribu-
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 Comunita
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 e stato considerato concluso e molti dei suoi risultati sono stati ripresi in
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 e stato la base dell’infrastrut-
tura creata come supporto all’immensa richiesta computazionale del Large Hadron
11
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 piu diffusi sistemi middleware per il
calcolo distribuito, come il GTK e Condor Cycle Scavenger.
1.2.1.3 Globus Alliance
La Globus Alliance [25] e un’associazione di vari enti, in particolar modo Unive-
sita e centri di ricerca Europei, Americani e dall’Estremo Oriente, che ha come
obiettivo lo sviluppo di un middleware per la creazione e gestione di sistemi Grid:
il Globus Toolkit, il piu diffuso attualmente. Oltre alle Universita e ai centri di
ricerca, e da notare la presenza all’interno della Globus Alliance di Univa Cor-
poration, societa commerciale fondata nel 2004 dai ricercatori Tuecke, Foster e
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) e un middleware per il supporto di Grid e applicazioni
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 e pensato per assolvere ad un preciso com-
12
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 utilita, sempre basate su interfacce standard, che offrono alcuni dei principali
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 comunita o gruppi di persone utilizzano l’infrastruttura, e l’apparato di
servizio ovvero quali comunita o gruppi di persone garantiscono la predisposizio-
ne, e la necessaria sostenibilita e fruibilita dell’infrastruttura. Grid specializzate
e progettate per supportare obiettivi e gruppi specifici. Alcuni possibili scenari di
utilizzo della Grid da parte delle comunita per i loro obiettivi, sono:
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 comunita scientifica che utilizza le risorse disponibili e il parco delle apparec-
chiature disponibili (come microscopi elettronici, acceleratori di particelle, sorgenti
13
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 comunita (che includono anche i consumatori) che provvedono a fornire
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 gia accennato, l’attivita di EGEE si concludera con la fine di Maggio 2010
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, passera le consegne
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), entita nazionali
che nascono come aggregazione e rappresentanti di tutte le iniziative nate in un
dato paese Europeo. L’obiettivo di EGI e quello di garantire la sostenibilita del-
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. Gia comunque dal 2007 l’embrione di EGI
sotto forma di commissione EGI DS ha iniziato le sue attivita di pianificazione
ed e stata supportata da organizzazioni operanti per conto delle costituende NGI
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
Gia sin d’oggi e chiaro comunque che quanto e avvenuto in EGEE per la scienza
altro non e che il processo di innesco di una linea di sviluppo piu generalizzato.
14
1.2 Le applicazioni
Figura 1.3: EGI DS Schedule.
L’innovazione, garanzia per lo sviluppo economico, e intimamente connessa al ra-
pido progresso scientifico che a sua volta e diventato sempre piu dipendente dalla
collaborazione tra i ricercatori di tutto il mondo. Di fatto, come gia accennato
in precedenza, l’utilizzo di elevate capacita di calcolo e sempre piu necessario per
modellare sistemi complessi e per elaborare i risultati sperimentali. Le griglie di
calcolo per l’e-Science nate per rispondere alle necessita di discipline scientifiche
(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 piu sva-
riate e coordinare strategie di sviluppo di tutte le Scienze. Cosı facendo EGEE
e evoluta in un vero e proprio modello di organizzazione paneuropeo capace di
garantire la sostenibilita a lungo termine delle e-Infrastrutture Grid e di integrare
le strategie nazionali di finanziamento a sostegno della e-Science. Le NGI nate a
livello nazionale per questo scopo stanno percio attrezzandosi per rispondere in
modo coordinato ed efficace sia alle esigenze delle discipline scientifiche all’interno
dei singoli paesi sia per sostenere un ruolo propulsivo piu generale nei confronti
di piu vasti settori della societa. Le NGI sono infatti organismi con la missione
15
1.2 Le applicazioni
pubblica di integrare finanziamenti a livello nazionale per la fornitura di servizi
basati su Grid. Essi finiranno percio per rappresentare un “one-stop-shop” per
una serie di servizi comuni basati su Grid per le comunita di ricerca nazionali i
cui rappresentanti (uno per ciascuna NGI) costituiranno la struttura di governo di
EGI. Tale Consiglio controllera l’organismo esecutivo che gestira le collaborazioni
internazionali tra le NGI.
1.2.3.2 EGI Design Study
Come accennato in precedenza il progetto di implementazione di EGI e stato cu-
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, e stata formal-
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 e stato parzialmente finanziato dalla Commissione Europea
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 sostenibilita a lungo termine della e-Infrastruttura Europea;
• 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
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 comunita;
• 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
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, e che mentre in fisica devi capire come e fatto il mondo,in informatica sei tu a crearlo. Dentro i confini del computer, sei tu il creatore.
Controlli – almeno potenzialmente – tutto cio che vi succede.Se sei abbastanza bravo, puoi essere un dio. Su piccola scala.
- Linus Torvalds -
2.1 Introduzione
EGEE, (Enabling Grids for E-sciencE), cui abbiamo gia fatto ripetutamente ri-
ferimento e il progetto europeo che per antonomasia ha mirato ad integrare le
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 comunita che condividono la necessita di accede-
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 attivita ha portato ad un grande sviluppo di software
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
2.2 L’architettura Grid di EGEE
geologia. Il progetto ha avuto una durata biennale. Esso ha pero trovato prosecu-
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 piu grande
al mondo. L’infrastruttura EGEE comprende 91 partner istituzionali di 32 paesi
Europei, Asiatici e Statunitensi. Essa e collegata alla rete europea di comunica-
zioni ad alta velocita GEANT2 [26] e ad altre reti simili. Per effettuare i calcoli
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 e diventato interoperabile con altre griglie
scientifiche nazionali e internazionali come l’Open Science Grid [27] negli USA e
NAREGI [28] in Giappone. Oltre che alle applicazioni scientifiche, EGEE si e este-
so anche ai servizi all’industria. Tre societa si sono impegnate finora a collaborare
nel progetto EGEE Business Associates (EBA) al fine di rendere l’infrastruttura
di calcolo distribuito della griglia piu accessibile, piu efficace e piu sicura in un
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 comunita scientifica
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 e articolata in componenti che assicurano al suo
interno l’operativita di funzioni diverse. Elementi di fondamentale importanza
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
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, e la componente che garantisce le risorse compu-
tazionali di un sito e svolge il ruolo di intermediario tra le richieste di servizi Grid
da parte di una entita autorizzata e il Resource Management System (RMS). Il
Resource Management System e un’applicazione campione sviluppata dalle indu-
20
2.2 L’architettura Grid di EGEE
strie partner della Sun Microsystems. L’applicazione utilizza tecnologie J2EE ed
e utilizzata per tracciare risorse per progetti cui partecipano le industrie stesse.
Comunque, l’applicazione puo essere adattata per venire incontro a molte esigen-
ze, come ad esempio vari tipi di applicazioni e-commerce. Il CE e formato da due
componenti:
• EDG: e la componente che funge da gateway fra il Resource Broker (gestore
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: e l’applicazione che si interfaccia all’RMS o direttamente
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): e il servizio che rilascia
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): e un servizio che fornisce
tutte le credenziali necessarie al job che e stato accettato nel sito;
• Job Repository: e un archivio locale che contiene le informazioni sui job in
esecuzione o su quelli che sono stati eseguiti. Le informazioni sono ottenute
dal LCMAPS e dal Jobmanager (e l’interfaccia verso il Resource Manage-
ment System o verso il Batch System e fornisce informazioni aggiornate al
Workload Manager sullo stato del job). Queste informazioni sono utilizzate
21
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 e accessibile
dall’esterno del sito;
• Local Batch System (scheduler): e il servizio che accetta e processa i job
diretti ad un insieme di nodi di elaborazione e si occupa di distribuire il
carico di lavoro tra loro;
• Information Provider: e il servizio che pubblica le informazioni circa lo
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) e un servizio leg-
gero che implementa tutte le operazioni di livello CE. Presenta una Web Service-
based Interface ed e implementato come una estensione Java-Axis servlet (svi-
luppato all’interno dell’Apache Tomcat container). L’obiettivo di CREAM e ga-
rantire l’interoperabilita con client scritti in vari tipi di linguaggio e operanti su
differenti computer platform. L’interfaccia e definita usando Web Serice Descrip-
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
2.2 L’architettura Grid di EGEE
• Job List;
• GSI based authentication;
• VOMS based authorization;
• Job Purge (per terminare i job);
• possibilita (per gli amministratori) di disabilitare nuove sottomissioni.
Inoltre CREAM puo essere usato:
• 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
e chiamato “resource matching”. In un ambiente Grid dinamico, dove le risorse
possono cambiare, e necessario rendere automatica la loro ricerca. A tal proposito
e stato sviluppato il Workload Management System o WMS, il componen-
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 piu precisamente con:
• 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
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 e composto da molti componenti importanti che interagiscono tra loro e
fanno sı che la gestione delle risorse sia completamente trasparente all’utente. Tra
questi elementi i piu importanti sono il Workload Manager o WM ed il Resour-
ce Broker o RB. Il WM e il nucleo di tutto il sistema. A partire da una richiesta
valida esso deve intraprendere l’azione corretta. Per fare cio esso deve interagire
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 e quella
di trovare una risorsa per un job, l’input e un’espressione JDL fatta dall’utente
con la descrizione del job, mentre l’output sara la stessa espressione con l’aggiunta
del CE scelto per l’esecuzione in base allo stato delle risorse Grid. Fra tutti gli
helper del WM, il piu importante e sicuramente il Resource Broker. A partire da
un’espressione JDL che rappresenta la richiesta di sottomissione del job, la sua
principale funzione e quella di trovare la risorsa (o le risorse) che meglio soddisfino
la richiesta. Il Resource Broker puo essere visto come l’unione di due moduli: il
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 e il risultato del processo di matchmaking tra le ri-
chieste e le risorse disponibili; quest’ultimo aspetto dipende sia dallo stato della
24
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 e un’altra funzione
del WM. Anche in questo caso possono essere applicate differenti politiche, come
scegliere la risorsa piu vicina (eager scheduling) o rimandare la sottomissione fino
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 adattera all’applicazione delle diverse politiche possibili
attraverso l’implementazione di plugins, operazione questa che dovra risultare fa-
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,
e l’Information Supermarket (ISM). L’ISM consiste di un archivio di informazioni
sulle risorse accessibile in sola lettura dal modulo adibito al matchmaking e il cui
aggiornamento e il risultato di notifiche provenienti dalle risorse o da verifiche ef-
fettuate dal WMS. L’ISM potra essere configurato in maniera tale da far innescare
il processo di matchmaking da particolari eventi verificatisi. Queste funzionalita
migliorano la modularita del software e il supporto a politiche analoghe al lazy
scheduling. Un’altra possibilita di gLite e quella di conservare una richiesta di
sottomissione per un determinato periodo di tempo, se le risorse richieste non so-
no immediatamente disponibili. Questa eventualita si potra verificare adottando
lo hearing scheduling e verra affrontata ripetendo la richiesta periodicamente o
attendendo la notifica da parte delle risorse richieste che giungeranno all’ISM. Il
modulo che implementa questa funzione e chiamato Task Queue (TQ). Ci sono
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
2.2 L’architettura Grid di EGEE
2.2.3 User Interface
La User Interface (UI) e il componente dell’infrastruttura Grid che permette
agli utenti l’accesso a tutti i servizi offerti dal WMS, che e l’unico con il quale
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 cio la UI si basa sul linguaggio
JDL, concepito per descrivere le caratteristiche, le richieste e le preferenze di un
oggetto. JDL e basato sul Classified Advertisement Language definito dal progetto
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
2.2 L’architettura Grid di EGEE
2.2.4 Job Wrapper
Il Job Wrapper (JW) e uno script generato dal WMS per ogni richiesta di
sottomissione di job; questo script e quello che viene sottomesso al LRMS del CE
ed e responsabile di creare l’ambiente per l’esecuzione del job, che comprende:
• 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) e l’interfaccia Grid al sistema di archiviazione di
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 puo scegliere se trasferire su un SE e registrare
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 verra identificato nella Grid. Scegliere un SE per
il salvataggio dei propri file vincola il Resource Broker in modo da scegliere, per
l’esecuzione del job, il CE piu vicino allo SE in questione.
2.2.6 Data Management System
La replicazione dei dati su piu nodi all’interno della Grid, e utilizzata per ridurre
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
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) e implementato attraverso vari servizi:
• 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: e l’EDG Information Service che fornisce le informazioni sui SE 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 puo essere suddiviso in tre gruppi di servizi riguardanti l’accesso ai dati:
Storage Element, Catalog Services e Data Scheduling. La loro funzione sara quella
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 avverra at-
traverso l’SE. Nello Storage Element i metodi di accesso saranno prima di tutto
definiti a seconda dal tipo di supporto di memorizzazione che verra utilizzato,
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 permettera l’accesso
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
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 e che tratta solo file fisici, per cui successive
trasformazioni dei dati che porteranno alla creazione, ad esempio, di file logici sa-
ranno fatte da servizi di livello superiore. Il processo di trasferimento e eseguito,
dall’utente, in maniera analoga alla sottomissione di un’applicazione a GRID. In
FTS la descrizione del job da sottomettere sara costituita da un unico file in cui
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 e stato sottomesso a FTS, il trasferimento dei dati avverra
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 e controllata dai siti o dalle VO, per cui l’utente, dopo aver sottomesso il job,
deleghera a queste la gestione del trasferimento. All’interno del Data Manage-
ment e anche incluso il servizio del Package Manager, incaricato di automatizzare
i processi d’installazione, aggiornamento, configurazione e rimozione di pacchetti
29
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 piu richieste da parte dei
“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) e un database di utenti
autorizzati ad utilizzare le risorse della VO. Il server e utilizzato per due scopi
principali: il primo e quello di ottenere informazioni sulle risorse a disposizione
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 fruibilita delle risorse. Attraverso il VOMS, infatti,
ogni utente crea un proxy di durata prefissata che gli permette di utilizzare le
risorse della VO alla quale e registrato senza dover comunicare le sue credenziali
ad ogni accesso.
30
2.3 EGEE Middleware
2.2.9 MyProxy Server
Il MyProxy Server (MPS) e 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 puo creare il proxy per l’utilizzo delle risorse. Il vantaggio del
MyProxy Server e che puo essere utilizzato per rinnovare un normale proxy, in mo-
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 modalita di funzionamento e le
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 estensibilita ed interoperabilita richieste da Grid. A tal proposito il
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 funzionalita. Questo in-
sieme puo essere dato da una chiamata ad una subroutine o da metodi di oggetti
(Object-Oriented API). SDK sono degli insiemi di codice che vengono utilizza-
31
2.3 EGEE Middleware
ti dagli sviluppatori per implementare specifiche funzionalita nei programmi che
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 e stato usato
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’interoperabilita e l’obiettivo
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
2.3 EGEE Middleware
Figura 2.3: Il middleware gLite.
tutorial on line. La formazione inoltre e disponibile sul testbed per l’attivita di di-
vulgazione, GILDA. Essa e caratterizzata dalla propria Autorita di Certificazione
(CA), e dalla possibilita di permettere agli utenti e agli amministratori di sistema
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 compatibilita con i gli standard Grid di nuova generazione, per esem-
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
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 funzionalita in tutti i livelli della struttura software. In par-
ticolare assicura una maggiore sicurezza, maggiore interfacciabilita per la gestione
dei dati e la sottomissione dei job, una struttura del sistema rivisitata, e molte
altre funzionalita che rendono facile ed efficente l’uso di gLite. Gia 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.
2.4 Ottimizzazione delle risorse
Le tematiche prese in esame nell’ambito delle attivita di ricerca relative alla Grid
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 puo essere
eseguita su una qualsiasi delle m macchine o eventualmente su una delle macchi-
ne appartenenti ad un certo sottoinsieme Mj di m. Lo scheduling e un campo
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 disponibilita di risorse che variano dinamicamen-
34
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 piu complessa di quella dei sistemi di calcolo tradizionali. I recenti sviluppi
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 piu risorse che ne richiede la disponibilita simultanea.
Per risolvere tali problematiche e stato necessario trasformare i job ossia intro-
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
piu processori contemporaneamente. Inoltre, considerando il fatto che la Grid pre-
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. Cio rende
il problema dello scheduling delle code un problema di ottimizzazione di risorse
eterogenee la cui ottimizzazione aumenterebbe significativamente le velocita, le
performance e il retrieve dei risultati dei job sottomessi in griglia.
35
Capitolo 3
GriF: Algoritmi Adattivi e
Queue Ranking
Penso che la cosa piu misericordiosa al mondo sia l’incapacitadella mente umana di mettere in relazione i suoi molti contenuti.
Viviamo su una placida isola d’ignoranza in mezzo a neri mari d’infinitoe 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 aprira, un giorno, visioni cosı terrificanti della realta e del postoche noi occupiamo in essa, che o impazziremo per la rivelazione
o fuggiremo dalla luce mortale nella pace e nella sicurezza di una nuova eta oscura.- Howard Phillips Lovecraft -
3.1 Introduzione
Dal desiderio di ottimizzare l’uso della Grid e nata l’idea di progettare e im-
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 fruibilita, la velocita di esecu-
zione e il recupero (nonche il controllo) dei risultati. Dalla vasta disponibilita
delle risorse della Grid e dal crescente numero dei suoi possibili fruitori nasce il
problema affrontato nella mia Tesi: come e possibile ottimizzare la gestione delle
risorse di Grid in modo da soddisfare il piu equamente possibile le richieste. Per
questo motivo il mio lavoro di Tesi si e concentrato sullo studio della gestione delle
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 e stata analizzata
36
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 e affrontato lo studio dettagliato del loro impatto sulla
disponibilita, raggiungibilita e performance. Portando avanti tale analisi abbia-
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 nonche
all’introduzione di una base di dati per la raccolta, in tempo reale, di tutte le in-
formazioni provenienti dalla griglia. Tutto questo e stato fatto facendo riferimento
alla Grid di EGEE accessibile alla VO COMPCHEM e su questo si e proceduto
a configurare l’ambiente di sviluppo di GriF installando Java, Tomcat, Axis,
MySQL e garantendo l’interoperabilita attraverso un Framework basato su SOA.
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 produttivita tramite il ri-uso di componenti applicative.
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 funzionalita di
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 affidabilita, di prestazioni e di economicita d’uso delle
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
3.2 SOA e Framework
importante per arrivare quindi al risultato finale. E stato un percorso difficile non
solo per gli aspetti tecnici, pur complessi, ma anche per le difficolta dovute alla
recessione economica, vista la mole degli investimenti necessari, che difficilmente
sono sostenibili da una singola istituzione.
3.2.1 Cos’e un’architettura SOA
Una SOA o architettura orientata ai (o basata sui) servizi, nasce per integrare
i rapporti Business to Business (B2B). In questo scenario B2B le aziende svi-
luppano sempre piu rapporti di partnership e diventa quindi indispensabile che i
rispettivi sistemi informativi riescano a raggiungere un certo livello di integrazione,
tenendo presente che il piu delle volte le piattaforme di partenza sono eterogenee.
Una SOA e progettata per il collegamento a richiesta di risorse computazionali
(principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti,
che possono essere utenti finali o altri servizi. L’OASIS (Organizzazione per lo
sviluppo di standard sull’informazione strutturata) definisce la SOA cosı:
Un paradigma per l’organizzazione e l’utilizzazione delle risorse distribuite che
possono essere sotto il controllo di domini di proprieta differenti. Esso fornisce
un mezzo uniforme per offrire, scoprire, interagire ed usare le capacita di produrre
gli effetti voluti consistentemente con presupposti e aspettative misurabili. Anche
se esistono molteplici definizioni di SOA, solo il gruppo OASIS ha prodotto una
definizione formale applicabile profondamente sia alla tecnologia che ai domini
aziendali. La nascita della SOA deve percio essere vista come un’evoluzione del
middleware, che, dall’integrazione delle applicazioni della singola azienda, viene
esteso all’integrazione delle applicazioni di piu imprese e alla gestione dei flussi
di lavoro per via telematica (e-Business). La SOA e composta da una serie di
strumenti che permettono di descrivere i flussi organizzativi cercando di estendere
tale funzionalita sino ad avere degli strumenti che permettano di leggere gli stessi
flussi oltre che all’essere umano anche alla macchina, attraverso software specifici,
come mostrato in Figura 3.1. Lo scopo primario e quello di passare da un mondo
38
3.2 SOA e Framework
Figura 3.1: Gli elementi di una Service-Oriented Architecture.
eterogeneo dove le varie architetture si sommano in un agglomerato caotico ad
un insieme piu ordinato di risorse le quali gravitano attorno ad un nucleo detto
“infrastruttura di integrazione”, che si preoccupa di collegare tutto l’insieme orga-
nizzativo. I sistemi informatici moderni sono progettati per essere interconnessi:
le tipologie di sistemi operativi, le tecnologie software e hardware sono differenti,
e nessuna ha il sopravvento sulle altre. Con l’appoggio crescente da parte delle
maggiori industrie del software, l’architettura basata sui servizi promette di fornire
quello che CORBA [31] e D-COM [32] non sono mai riusciti a realizzare appieno:
l’utilizzo di servizi a prescindere da dove e come siano realizzati.
3.2.1.1 Una nuova architettura
Per approfondire questo aspetto si consideri il caso in cui i responsabili IT di
un’azienda debbano integrare il sistema informativo che e stato costruito negli
anni tenendo conto che sia verso l’interno dell’azienda che verso l’esterno di essa
si sente sempre piu il bisogno di utilizzare risorse eterogenee. Si dia per tanto il
caso che l’inventario sia gestito su un server Linux, i processi gestionali e l’applica-
39
3.2 SOA e Framework
tion server risiedono su Windows 2003, i fornitori hanno server per le ordinazioni
raggiungibili su Internet, ma dietro un firewall, e cosı i clienti. Tutti questi siste-
mi, lontani geograficamente operanti con sistemi operativi diversi possono ancora
darci le informazioni e i servizi di cui abbiamo bisogno ma, utilizzando le tecniche
esposte finora, cio sarebbe estremamente difficile. Conviene, invece, cambiare la
prospettiva e pensare alle varie componenti in gioco non piu come astrazioni di un
prodotto, ma come erogatori di servizi di cui il sistema informatico considerato e
fruitore. Questa e una solida base per costruire un’applicazione distribuita, le cui
parti sono:
• Fornitori di servizi (o provider), che possiamo utilizzare indipendentemente
da dove si trovano, dalla tecnologia su cui sono basati e dalla piattaforma
software o hardware che li realizza;
• Fruitori (o consumer) di tali servizi definiti anche questi indipendentemente
da dove si trovano, dalla tecnologia che usano e dalla piattaforma software
o hardware su cui lavorano.
3.2.1.2 Le regole
A questa impostazione fa chiaramente seguito l’adozione di alcune regole che ci
permettano di utilizzare i relativi servizi. Queste sono:
• Un linguaggio comune che consenta ai fornitori di servizi di comprendere
le richieste e di rendere comprendibili le loro risposte;
• Un contratto stipulato tra il fruitore e il fornitore di servizi basato su poche
regole chiare e persistenti e implementate in maniera univoca sulle macchine
(protocollo);
• Dinamicita dei servizi aggiuntivi purche sempre formulati sulla base del
protocollo implementato cosı che la fornitura e l’utilizzo di nuovi servizi sia
istantaneo e non ambiguo;
40
3.2 SOA e Framework
• Un canale di comunicazione sicuro, semplice e universalmente ac-
cettato (per esempio HTTP o HTTPS).
Quanto appena descritto esiste gia ed e la base delle SOA, cioe delle architetture
basate sui servizi, ovvero delle architetture in cui la parte di logica del client e
quella di funzionalita del business sono nettamente separate e dove quest’ultima
e realizzata mediante moduli piu semplici (i servizi), definiti formalmente inter-
facce. Quella che e stata realizzata e un’architettura client-server dove il client di
GriF (denominato YC, Yet a Consumer) sfruttando un’interfaccia User Friendly,
puo effettuare operazioni in griglia come ad esempio sottomettere uno o piu job,
conoscere il relativo stato, quindi compilare eseguibili customizzati, creare input
file mediante interfacce user-driven e altro ancora. Il server principale (denomi-
nato YP, ovvero Yet a Provider) risiede su un cluster di workstation formato da
2 front-end e 8 nodi. Le caratteristiche tecniche dei front-end sono riportate di
seguito:
• Single processor Quad-Core CPU Intel(R) Xeon(R) X3210 2.13GHz;
• Hard Disk da 250 GB SATA;
• SO Scientific Linux SL release 5.2 (Boron);
• Rete Gigabit Ethernet;
• Kernel versione 2.6.18-128.7.1.el5xen.
Un altro componente fondamentale del nostro progetto e la UI che normalmen-
te rappresenta l’interfaccia utente verso la Grid. Essa e interconnessa ai front-
end attraverso una rete pubblica di tipo MAN (Metropolitan Area Network). Le
caratteristiche tecniche principali della UI sono:
• Single processor Quad-Core CPU Intel(R) Xeon(TM) 3.06GHz;
• SO Scientific Linux CERN SLC release 4.8 (Beryllium);
41
3.2 SOA e Framework
• Rete Fast Ethernet;
• Kernel versione 2.6.9-89.0.16.ELsmp.
Le richieste che vengono inviate dal YC a GriF e quindi alla Grid, scendendo leg-
germente nel dettaglio, sono in realta chiamate a Web Service i quali effettueranno
le operazioni a basso livello in griglia passando per la UI e infine restituiranno i
risultati direttamente al YC. Inoltre un secondo server, denominato YR (Yet a
Registry), basato sul protocollo UDDI (Universal Description, Definition, and In-
tegration) agisce come un registro che espone i servizi offerti da GriF. In pratica,
gli utenti ispezionano il YR, mediante una semplice ricerca basata su una o piu’
parole chiave, al fine di trovare ed invocare l’appropriato Web Service residente su
uno specifico YP identificato, insieme al servizio, dal YR stesso.
3.2.1.3 Gli standard per i Web Service
Il linguaggio comune e l’XML, di cui si utilizza un dialetto, SOAP (Simple
Object Access Protocol) e anche XML-RPC (XML Remote Procedure Calling)
per inviare richieste e ricevere risposte. L’utilizzo di SOAP su HTTP/HTTPS
(ma si potrebbero usare anche altri protocolli ad esempio SMTP o FTP) e la
base dei Web Service, secondo quanto la maggior parte dell’industria del software
ha ormai stabilito come standard di fatto. Lo standard di descrizione dei Web
Service e il WSDL (Web Service Description Language). Una macchina puo
quindi interrogare un fornitore di servizi, esaminare il file WSDL dato in risposta,
e avere tutte le informazioni utili per interrogare il Web Service che le interessa,
sapendone interpretare correttamente le risposte. Lo strumento, o protocollo, che
viene utilizzato per “scoprire” il Web Service di cui abbiamo bisogno, cioe per
cercare in modo automatico un Web Service che risponda alle nostre esigenze, e
UDDI. L’utilizzo dei Web Service fa sı che tutto quello che viene sviluppato nel
corso degli anni non vada perso, ma possa essere integrato grazie ad una nuova
filosofia secondo la quale gli oggetti, i componenti, diventano dei Web Service che
interagiscono tra loro senza pero che le loro specifiche implementazioni debbano
42
3.2 SOA e Framework
essere condivise. L’unica cosa condivisa e il contratto fra il service provider e
il client (ovvero gli standard di comunicazione). Quindi piu in dettaglio, nella
prospettiva di una SOA:
• Il servizio e la realizzazione di determinate funzionalita mentre WSDL e il
linguaggio utilizzato per la descrizione dei contratti. Il componente (il Web
Service) e scritto in modo da poter essere utilizzato solo in base al contratto
esposto (interfaccia);
• I servizi sono coarse grained, ovvero la granularita dei servizi piu utili e
grossa: un servizio generalmente fornira delle informazioni ottenute dopo
una elaborazione significativa. Per esempio, la lista delle code ordinata per
CPU totali e CPU libere. Servizi a granularita piu fine, come quello che
fornisce le CPU occupate per una singola coda, vengono utilizzati “dietro le
quinte” dal Web Service principale. Oggetti, componenti e servizi sono posti
in scala crescente di utilita business e decrescente granularita;
• Un Web Service e auto-contenuto, anzi di piu: un Web Service mantiene al
suo interno il proprio stato. Generalmente le chiamate sono stateless ovvero
non presuppongono il mantenimento di informazioni sullo stato del servizio
tra una chiamata e l’altra;
• Un Web Service e “debolmente accoppiato” (loosely coupled) con gli al-
tri Web Service, cioe sostanzialmente indipendente da essi. Questo e un
concetto fondamentale, anche per considerazioni di scalabilita e versatilita
dell’applicazione;
• Un Web Service puo essere fruitore di Web Service e al tempo stesso fornitore
di altri Web Service;
• I vari Web Service interagiscono scambiandosi messaggi su un canale virtuale
detto message bus o service bus che puo essere esterno o interno all’azienda.
43
3.2 SOA e Framework
Tale canale, se interno, non utilizza necessariamente SOAP su HTTP. Al-
l’interno dell’azienda, infatti, si potrebbe utilizzare, per esempio, un sistema
di accorpamento di messaggi e, se la comunicazione dei messaggi e punto a
punto, una buona scelta e XML-RPC;
• I Web Service assumono che la connettivita sia asincrona: alta latenza e alta
rumorosita del canale non sono un problema. Il famoso sviluppatore/autore
Don Box dice che questo concetto puo anche estendersi alle persone coinvolte
nella realizzazione dell’applicazione SOA: scambiandosi XML-schema e non
tipi (o per esempio classi Java) si parla a “rumore zero”. Il servizio quindi
porta all’estremo il concetto di incapsulamento (o information hiding).
3.2.1.4 Web Service per Chi?
Chi utilizza all’interno del progetto i vari Web Service? I processi. I processi
fanno quella che viene chiamata orchestrazione (orchestation) dei Web Service:
la logica di business utilizza i vari servizi per ottenere lo scopo voluto. L’azione di
sincronizzazione e di scambio di messaggi fra diversi gruppi di Web Service/pro-
cessi viene generalmente chiamata coreografia (coreography). Chi ha esperienza
di scrittura di applicazioni enterprise avra intuito alcune delle problematiche nuo-
ve che una architettura di questo genere fa nascere. Per esempio nasce il bisogno
di un nuovo modello di transazione. Nasce l’idea della long-term transaction, ov-
vero di una transazione di lungo termine, che coinvolge diverse entita, di cui non
e possibile a priori determinare il tempo di risposta. Occorre quindi anche una
nuova semantica delle transazioni, essendo il modello ACID (Atomicita, Consi-
stenza, Isolamento, Durabilita) non del tutto adeguato. I Web Service da soli non
risolvono tutti i problemi: e necessario uno strato di integrazione dei servizi, che
ne determini la descrizione, la “scoperta” (discovery), la composizione (composi-
tion) e la gestione processo e intraprocesso (orchestration, coreography) dei Web
Service.
44
3.2 SOA e Framework
3.2.2 Framework
Un Framework, uno strumento ormai sempre piu in voga nello sviluppo di appli-
cazioni Java, e una struttura di supporto su cui un software puo essere organizzato
e progettato. Alla base di un Framework c’e sempre una serie di librerie di codice
utilizzabili con uno o piu linguaggi di programmazione, spesso corredate da una
serie di strumenti di supporto allo sviluppo del software, come ad esempio un IDE
(nel nostro caso Netbeans), un debugger, o altri strumenti ideati per aumentare
la velocita di sviluppo del prodotto finito. Un Framework Java e un insieme di
classi e interfacce di base che costituisce un’architettura generica per lo sviluppo
di applicazioni in una determinata area tecnologica (Java). Quando si utilizza
un Framework Java, lo sviluppatore implementa interfacce o estende classi per
tale Framework, ma il controllo del flusso applicativo e a carico del Framework
Java. Quindi il codice applicativo dello sviluppatore non e direttamente invocato
dall’intervento dell’utente sul sistema, ma il flusso elaborativo passa attraverso il
codice del Framework: sono quindi le classi del Framework che invocano il codice
applicativo dello sviluppatore e non viceversa come quando si utilizza una libreria
di classi.
3.2.2.1 Le caratteristiche di base del Framework
E molto frequente imbattersi nel termine “Framework” nella letteratura riguar-
dante lo sviluppo di applicazioni. Molto spesso pero non si ha un’idea chiara di
cosa si intenda con questo termine. Un Framework e una architettura generica che
costituisce l’infrastruttura per lo sviluppo di applicazioni in una determinata area
tecnologica. Detto in maniera molto semplice e un insieme di classi ed interfacce
di base, che costituiscono l’infrastruttura di una applicazione come mostrato in
Figura 3.2. In base a questa definizione e facile pensare erroneamente che utiliz-
zare un Framework equivalga ad usare una libreria di classi. In realta vi e una
sostanziale differenza tra le due cose. Una libreria di classi, quali ad esempio le
classi di base del linguaggio Java, viene utilizzata dallo sviluppatore per svolgere
45
3.2 SOA e Framework
Figura 3.2: I due layer operativi di Applicazioni e Framework.
determinate funzionalita. In questo caso il codice che viene scritto invoca il codi-
ce esistente per svolgere una certa funzione, ma il controllo del flusso applicativo
rimane del codice scritto. Adottare un Framework significa invece affidarsi ad un
specifica architettura ovvero, con altre parole, estendere le classi del Framework
e/o implementarne le interfacce. In tal caso sono i componenti del Framework
che hanno la responsabilita di controllare il flusso elaborativo. Nel mondo dell’ar-
chitettura del software un Framework e considerato come una parte di software
esistente nel quale inserire il proprio, che puo essere parafrasato con il noto slo-
gan di Hollywood “don’t call us we call you”. Il nostro codice applicativo non e
direttamente invocato dall’intervento dell’utente sul sistema ma il flusso elabora-
tivo passa attraverso il codice del Framework: sono le classi del Framework che
invocano il nostro codice applicativo e non viceversa come e invece nel caso delle
librerie di classi.
46
3.2 SOA e Framework
3.2.2.2 Perche un Framework?
Lo scopo di un Framework e di risparmiare allo sviluppatore la riscrittura di co-
dice gia steso in precedenza per compiti simili. Questa circostanza si e presentata
sempre piu spesso man mano che le interfacce utente sono diventate piu complesse,
o piu in generale man mano che e aumentata la quantita di software con funzio-
nalita secondarie simili. Ad esempio, il tipo di interazione con l’utente offerta da
un menu a tendina sara sempre la stessa indipendentemente dall’applicazione cui
il menu appartiene (o almeno questo e cio che l’utente si aspetta). In casi come
questo un Framework, che permette di aggiungere la funzionalita di una finestra
con un menu a tendina con poche righe di codice sorgente a carico del programma-
tore, o magari permettendogli di disegnare comodamente il tutto in un ambiente
di sviluppo, permettera di concentrarsi sulle vere funzionalita dell’applicazione,
senza doversi far carico di scrivere codice “di contorno”. Il termine inglese Fra-
mework quindi puo essere tradotto come intelaiatura o struttura, che e appunto
la sua funzione, a sottolineare che al programmatore rimane solo la creazione del
contenuto vero e proprio dell’applicazione. Un Framework e definito da un insie-
me di classi astratte e dalle relazioni tra esse. Istanziare un Framework significa
fornire un’implementazione delle classi astratte. L’insieme delle classi concrete,
definite ereditando il Framework, eredita le relazioni tra le classi. Si ottiene in
questo modo un insieme di classi concrete con un insieme di relazioni tra classi.
3.2.2.3 Usare un Framework
Come abbiamo evidenziato nel precedente paragrafo, utilizzare un Framework
significa implicitamente adottare una specifica architettura per la propria applica-
zione. Anche se questo puo sembrare a prima vista vincolante e, invece, nel caso
di un Framework valido (e vedremo quali criteri lo rendono tale), uno dei maggio-
ri vantaggi. All’inizio di un progetto infatti la scelta dell’architettura e uno dei
momenti fondamentali che puo determinare il successo o l’insuccesso del progetto
stesso. A volte e una scelta che viene trascurata o sottovalutata, principalmente
47
3.2 SOA e Framework
per un errato approccio allo sviluppo applicativo considerato esclusivamente come
una attivita di scrittura di codice, ma che produce effetti disastrosi se non pon-
derata attentamente. Utilizzare un Framework maturo e gia ampiamente testato
significa attenersi ad una architettura che funziona e quindi significa iniziare un
progetto da una base solida. Cio porta inoltre ad un significativo risparmio di
tempo e risorse in quanto lo sviluppatore non deve piu preoccuparsi di realizza-
re componenti infrastrutturali ma puo concentrarsi esclusivamente sullo sviluppo
della logica di business che poi e il valore aggiunto della applicazione che si scrive.
Non e raro nello sviluppo di un progetto assistere alla riscrittura di componenti
di base che gia esistono e che sono stati gia ampiamente testati. Possiamo dire
che uno dei vantaggi nell’utilizzo di un Framework e che si viene aiutati a non
“reinventare la ruota” come spesso purtroppo accade. E chiaro che tutto cio e
vero quando si fa riferimento ad un Framework giunto ad uno stadio di sviluppo
maturo, gia adottato da molti sviluppatori e quindi gia ampiamente provato “sul
campo”. Da un punto di vista pratico adottare un Framework significa senz’altro
ridurre i tempi di un progetto ed evitare errori nella fase di disegno in quanto
si utilizza una infrastruttura realizzata secondo le best-practice dell’ambito tec-
nologico di riferimento. E bene precisare che un Framework non va confuso con
un design-pattern. Un design-pattern e una strategia di soluzione di un problema
comune, e qualcosa di concettuale che prescinde dall’implementazione tecnologi-
ca. Un Framework e invece qualcosa di concreto, e un insieme di componenti
che puo essere usato per realizzare una applicazione (componenti che, quando il
Framework e ben strutturato, sono sviluppati secondo i design-pattern piu diffusi
nell’ambito specifico).
3.2.2.4 Vantaggi e svantaggi nell’utilizzo di un Framework
In genere i vantaggi dell’utilizzo di un Framework vanno ben oltre gli svantaggi,
anzi si puo affermare che quanto piu il progetto sia di grandi dimensioni tanto
piu consigliabile e l’utilizzo di un Framework. Di seguito vengono schematica-
48
3.2 SOA e Framework
mente riassunti alcuni dei principali vantaggi che si ottengono nell’adozione di un
Framework nello sviluppo di applicazioni Java:
• Disegno architetturale: un buon Framework e fondato su un disegno
architetturale valido, in quanto il suo codice e scritto in base alle best-practice
della tecnologia in uso. Cio conferisce al proprio progetto fondamenta solide
dalle quali partire;
• Riduzione dei tempi di progetto: lo sviluppatore deve implementare
esclusivamente la logica applicativa potendo risparmiare le energie e il tempo
necessari alla scrittura di componenti infrastrutturali;
• Semplificazione dello sviluppo: un buon Framework semplifica lo svilup-
po applicativo perche fornisce tutta una serie di componenti che risolvono
la gran parte dei compiti comuni a tutte le applicazioni (controllo del flus-
so, logging, gestione messaggi di errore, debugging, internazionalizzazione,
validazione dei dati, e cosı via).
Va precisato che ovviamente un Framework non e la soluzione di tutti i problemi.
Adottarne uno che non si adatta al proprio problema puo portare molti svantag-
gi, per questo la scelta di quello giusto per le proprie esigenze e di fondamentale
importanza. In genere e comunque sempre preferibile evitare Framework poco
generici, che impongono l’utilizzo di strumenti proprietari e che legano indissolu-
bilmente la propria applicazione ad una specifica struttura. Il Framework deve
fornire una base per lo sviluppo ma la logica applicativa sviluppata deve essere
utilizzabile anche al di fuori della struttura del Framework stesso.
3.2.2.5 Scegliere un Framework
Esistono molti Framework per lo sviluppo di applicazioni Java, sia Open-Source
che prodotti commerciali. La scelta di un Framework e importante per tutte le
ragioni che abbiamo visto precedentemente e investe aspetti non solo tecnici ma
anche economici. I criteri per la scelta sono molteplici ed e bene chiarire che non
49
3.2 SOA e Framework
esiste il Framework “ideale”. Di seguito sono elencate alcune caratteristiche che
servono per valutare un Framework:
• Maturita del progetto: e sconsigliabile adottare un Framework che sia
in una fase iniziale di sviluppo e che sia poco adottato nella comunita de-
gli sviluppatori e quindi poco testato sul campo in progetti reali. Meglio
indirizzarsi verso progetti gia stabili e sperimentati;
• Documentazione: va sempre verificato che la documentazione sia ricca e
ben fatta. Questo facilita la risoluzione dei problemi che si incontrano nella
realizzazione dell’applicazione e la comprensione del suo funzionamento;
• Validita del disegno architetturale: proprio perche la scelta di un Fra-
mework influisce sull’architettura applicativa e bene verificare che sia dise-
gnato correttamente e quindi che siano adottati i design-pattern e le best-
practice della tecnologia di riferimento;
• Adozione degli standard: un Framework deve essere fondato sui com-
ponenti standard della tecnologia di riferimento. Nel nostro caso sulle API
che costituiscono la Java EE (Java Enterprise Edition). Quanto piu un Fra-
mework impone soluzioni proprietarie, l’uso di specifici tool di sviluppo o
un modello troppo indirizzato ad uno specifico caso applicativo tanto piu va
evitato;
• Estendibilita: deve essere possibile estendere le funzionalita del Framework
per adattarlo alle alle proprie esigenze.
3.2.2.6 Java e Framework
“Write Once, Run Anywhere” e il motto che la Sun ha utilizzato, anni orsono,
per identificare Java. Gia da questa semplice frase si capisce qual e l’obiettivo
di questo linguaggio: rendere il codice scritto indipendente dalla piattaforma. In
Java e possibile scrivere un programma in ambiente Linux ed eseguirlo in ambien-
te Windows, senza apportare alcuna modifica al codice sorgente. Per ottenere
50
3.2 SOA e Framework
questa indipendenza viene utilizzata una architettura particolare che e illustra-
ta in Figura 3.3. L’architettura funziona nel modo seguente: l’utente scrive il
Figura 3.3: Funzionamento dell’architettura Java.
proprio codice seguendo le regole grammaticali e sintattiche del Java. Il file pro-
dotto, identificato dall’estensione .java, viene “compilato” ed in questa maniera
viene creato un codice intermedio indipendente dalla macchina denominato byte
code che e contenuto all’interno dei file .class. A questo punto entra in gioco
la “virtual machine” (VM) ovvero il componente fondamentale della struttura;
ne esiste una per ogni sistema operativo ed e lei che si occupa di interpretare e
quindi rendere effettivamente portabile il codice. Quando un programma viene
eseguito, prima viene caricata la VM (se non e gia stato fatto) la quale si occupa
di chiamare ed eseguire le classi (byte code) di cui si ha bisogno e, utilizzando
51
3.2 SOA e Framework
una compilazione JIT (Just In Time), si preoccupera di tradurre in linguaggio
macchina le istruzioni del programma. I compilatori JIT hanno la particolarita
di effettuare la compilazione “al volo” ovvero durante l’esecuzione del programma
stesso. Per eseguire il medesimo programma su di un sistema operativo diverso
basta assicurarsi che sulla macchina di destinazione sia presente una VM appro-
priata, copiare sulla macchina il byte code del programma ed eseguirlo. In questa
semplice maniera viene mantenuta la portabilita del codice. Una delle caratteristi-
che fondamentali di Java e l’orientamento agli oggetti che si riferisce a un moderno
metodo di programmazione e progettazione, ovvero la programmazione orientata
agli oggetti (OOP). L’idea alla base della OOP e di rappresentare, nella proget-
tazione del software, le entita reali o astratte che compongono il problema sotto
forma di oggetti istanziati da classi. Gli oggetti sono caratterizzati da proprieta
(definite variabili o campi di istanza o di esemplare) e da metodi o funzioni appli-
cabili sugli oggetti stessi, che possono ad esempio modificarne lo stato o estrarne
informazioni. I programmi scritti in Java possono essere unicamente orientati agli
oggetti, di conseguenza tutto il codice deve essere necessariamente incluso in una
classe. Sebbene Java possa operare sia su oggetti che su tipi di dati primitivi,
e considerato un linguaggio ad oggetti puro, ovvero nel quale gli oggetti sono le
entita di base del linguaggio anziche essere costruiti partendo da costrutti ad un
inferiore livello di astrazione. Per sviluppare programmi in Java e teoricamente
sufficiente un qualsiasi editor di testo; in pratica, se si vuole scrivere qualcosa di
piu del classico hello world, occorre un ambiente di sviluppo integrato. Esistono
diversi IDE (Integrated Development Environment, ovvero ambiente di sviluppo
integrato), alcuni gratuiti ed altri a pagamento. La Sun ha promosso l’implemen-
tazione di un ambiente di sviluppo gratuito e Open Source chiamato NetBeans e
lo mette a disposizione gratuitamente insieme a Sun Java Studio. Questi due am-
bienti sono scritti in Java e NetBeans e distribuito insieme alla macchina virtuale.
Come entita separata, NetBeans e scaricabile da netbeans.org ed e stato l’IDE
scelto per l’implementazione di GriF.
52
3.2 SOA e Framework
Come abbiamo detto nei paragrafi precedenti, l’utilizzo di un Framework nelle
attivita di sviluppo di software orientato agli oggetti, accelera notevolmente i tem-
pi permettendo ai progettisti di occuparsi dei problemi in astratto senza scendere
nei dettagli, un rischio sempre presente durante l’attivita di progettazione. Inol-
tre, implementare le parti di codice relative alla GUI con un IDE come Netbeans
permette di velocizzare ulteriormente lo sviluppo. Abbiamo anche detto che il Fra-
mework puo essere visto come un livello aggiuntivo indipendente al quale chiedere
servizi ignorando come e fatto e cosa nasconde. Questa struttura sposa benissimo
uno schema di progettazione (design-pattern) dove la struttura logica del sistema
viene suddivisa in livelli, separando interfacce grafiche, gestione della sessione, lo-
gica applicativa, servizi di business, servizi tecnici e fondamenta, come mostrato
in Figura 3.4. Questa suddivisione pone l’enfasi sul fatto che i livelli superiori uti-
Figura 3.4: Design Pattern Layers.
lizzano e conoscono i livelli inferiori. I livelli inferiori invece non utilizzano quelli
53
3.3 Analisi delle code
superiori, al piu li conoscono ma solo tramite interfacce apposite. Questo fa sı che
la riusabilita aumenta scendendo di livello. I primi due livelli infatti sono dedicati
alla specifica User Interface (UI) e, cosı come il terzo, sono fortemente accoppiati
dall’applicazione specifica. Dal quarto livello in poi si presentano livelli sempre piu
disaccoppiati con l’applicazione offrendo servizi di interesse generale, quindi mag-
giormente riusabili. Nell’ultimo livello in particolare (Foundation) risiedono tutti
i servizi tecnici di basso livello, i Framework e altri servizi di utilita. Il Framework
infatti non sa nulla di chi lo utilizza (in questo caso i livelli sovrastanti) mentre, al
contrario, viene usato liberamente dagli eventuali altri livelli sottostanti. In genere
l’utilizzo di Framework, proprio per questa separazione di ambito di applicazione,
porta beneficio a tutto il sistema in termini di alta coesione (High Coesion) e basso
accoppiamento (Low Coupling). Inoltre, il Framework nasconde la struttura inter-
na fornendo solo poche classi e metodi per l’utilizzo dei servizi garantendo quindi
variazioni protette (Protected Variation). GriF si colloca proprio come uno strato
software a se stante, al quale il programmatore chiede servizi come fossero API di
Java. Uno degli obiettivi di GriF e quello di fornire uno strumento che permetta
un approccio semplificato e trasparente alla Grid utilizzando Basi di Dati, SQL,
Java Script Shell e Web Service come mostrato in Figura 3.5.
3.3 Analisi delle code
I gestori di un sistema Grid hanno bisogno di capire come vengono gestite le risorse
e come esse vengono assegnate agli utenti che ne fanno richiesta. Inoltre, hanno la
necessita di conoscere gli skill degli utenti ossia le capacita o le incapacita che essi
possiedono per l’utilizzo di tali risorse. Oltre a permettere l’utilizzo di varie fun-
zionalita Grid in modo trasparente al programmatore, GriF ha anche l’obiettivo di
ottimizzare la gestione delle risorse partendo dall’analisi delle code. Abbiamo gia
detto quali sono i limiti della Grid dal punto di vista dello scheduling delle code. I
limiti diventano ancora piu evidenti se si pensa che e cambiato il modo in cui i job
vengono processati. Fino a qualche anno fa i job presi in considerazione facevano
54
3.3 Analisi delle code
Figura 3.5: L’ambiente GriF.
riferimento a modelli di processamento classici, ossia seriali. Le macchine parallele
hanno aperto nuovi scenari e nuove problematiche in quanto n job possono essere
eseguiti in parallelo. Qui entra in gioco l’insufficiente strutturazione delle code,
incapaci di schedulare job paralleli ottimizzando le prestazioni. In particolare le
applicazioni parallele consistono di piu componenti (subjob) eseguiti in parallelo
su uno o piu processori di uno o piu cluster o supercalcolatori presso differenti
siti. Tali applicazioni possono cosı accedere efficacemente ad un numero di risorse
computazionali molto piu ampio di quello a disposizione utilizzando un qualsia-
si supercalcolatore o cluster singolo. Un’opportuna distribuzione dei subjob tra
55
3.3 Analisi delle code
le risorse disponibili consente a queste applicazioni di beneficiare, in termini di
prestazioni, di questa potenza computazionale aggregata nonostante l’overhead
addizionale introdotto dalle comunicazioni (tra i subjob) che utilizzano le reti piu
lente. E chiaro che, frammentando un job in n subjob, diventa difficile, se non im-
possibile, velocizzare la loro esecuzione con l’architettura che oggi la griglia mette
a disposizione. Ad esempio il meccanismo che a tutt’oggi governa la politica di
scheduling quando si sottomette un job parametrico e abbastanza aleatorio. Non e
possibile infatti prevedere ne l’identita della coda in cui il job verra processato ne
le sue caratteristiche reali, quali ad esempio performance, CPU libere e memoria
disponibile. Questo di fatto condiziona molto l’esito del risultato sia in termini di
velocita di esecuzione che di affidabilita. Infatti, in molti casi, l’effetto delle scelte
fatte automaticamente dalla griglia e negativo, con il conseguente fallimento di
molti job che spesso non vengono neppure terminati.
Non potendo, ovviamente, cambiare l’architettura Grid, abbiamo cercato un
criterio che ottimizzasse la diffusione dei job attraverso la rete rispetto ad alcuni
parametri da noi ritenuti importanti. Il primo di questi (considerato come condi-
zione necessaria) e la raggiungibilita della coda (coda up). Il test per esaminare se
una coda e up viene effettuato sfruttando il programma ping che misura il tempo,
espresso in millisecondi, impiegato da uno o piu pacchetti ICMP a raggiungere la
coda in rete e quindi ritornare indietro all’origine. Macroscopicamente, se il tempo
di risposta e ritenuto soddisfacente la coda e definita up e viene accettata mentre le
altre definite down vengono scartate. Altra condizione necessaria e la disponibilita
delle CPU. Ogni coda possiede un certo numero di CPU e queste possono essere
libere oppure occupate. Le code prese in considerazione sono quelle che hanno al-
meno due CPU libere cosı da evitare il rischio di accodamenti indesiderati o stalli.
L’ultima condizione da soddisfare non e una vera e propria condizione ma una ga-
ranzia di rendimento della coda. Essa consiste in un ranking basato su un indice
di prestazione della coda che utilizza una funzione che considera il numero totale
di job processati, il numero di job completati con successo (Done), il numero dei
56
3.4 Un approccio adattivo per il filtraggio delle code
job falliti (Aborted) e la sommatoria dei tempi di ogni subjob eseguito, reperendo
l’informazione dal Database utilizzato per salvare tutte le attivita svolte da ogni
coda. Con questa funzione e possibile assegnare un punteggio alle code che altro
non e che il Rank relativo.
3.4 Un approccio adattivo per il filtraggio delle code
La Grid e una piattaforma che si sta rapidamente affermando come luogo di di-
vulgazione e condivisione coordinata di risorse ma la sua crescita e profondamente
legata all’evoluzione tumultuosa delle tecnologie informatiche. Negli ultimi dieci
anni, a partire dai primi esperimenti di macchine parallele virtuali realizzate su
reti locali, sino a giungere a concezioni avveniristiche come la potenza di calcolo
su richiesta, un filo conduttore puo essere individuato nella necessita di superare
il problema dell’eterogeneita, sia a livello hardware che a livello software, al fine di
fornire un’immagine integrata del sistema. Questo problema, tuttavia, si presen-
ta in nuove forme ogni qualvolta, trovata una soluzione accettabile per dominare
il livello di eterogeneita precedentemente affrontato, si voglia superare la conce-
zione precedente per aprire l’orizzonte a nuove idee e possibilita. Problemi quali
la gestione dell’elevatissimo livello di eterogeneita e l’ottimizzazione delle risorse,
restando irrisolti, rendono ancora improponibile un effettivo avvento del Grid in
qualita di tecnologia pervasiva. Tuttavia GriF vuole candidarsi come una sorta di
Single System Image (SSI) per rendere piu agevole l’utilizzo della griglia anche
ad utenti neofiti. Si parla di SSI quando, in un ambiente costituito da risorse ete-
rogenee e/o distribuite, si cerca di costruire, a beneficio dell’utente, un’interfaccia
che unifichi la gestione e l’utilizzo di queste risorse mascherandone le differenti
caratteristiche. E importante sottolineare come la definizione del concetto di SSI
non dipenda da disomogeneita in termini di prestazioni, ma solo in termini di
possibilita di utilizzo. In questa nuova ottica, dunque, GriF non rappresenta piu
semplicemente un’infrastruttura di calcolo distribuito, utilizzata per l’elaborazione
di job parametrici, ma diventa l’ambiente eletto a svolgere processi di ottimizza-
57
3.4 Un approccio adattivo per il filtraggio delle code
zione attraverso la formazione di “contenitori” virtuali di apprendimento al cui
interno si analizzano i comportamenti dei job.
Alla luce di questo nuovo approccio ci siamo concentrati su un meccanismo
adattivo in grado di migliorare le prestazioni della griglia sfruttando le informazioni
che compongono la struttura dei job. In modo particolare, tale modello e legato
alla complessita e all’elaborazione in tempo reale di ciascun job. In base a questi
precisi requisiti abbiamo definito un modello che realizzasse un tipo di adattivita
dei contenuti a breve termine, in modo da cogliere informazioni momentanee sui
job, osservando il loro comportamento per un intervallo di tempo molto breve,
combinando le informazioni fornite da GriF con quelle gia in nostro possesso.
Per adattivo si intende un meccanismo che cambia il suo comportamento sulla
base delle informazioni disponibili. La creazione del repository (la tabella Rules
del Database GriF) in cui immagazzinare gli eventi trascorsi relativi alle code, ha
avuto il merito principale di rendere attuabile questo meccanismo. In questo modo
vari agenti artificiali sono in grado di sfruttare le informazioni derivanti da Grid
per popolare il repository costruendo delle regole di ottimizzazione basate sulle
caratteristiche computazionali dei job. Percio, ogni volta che un utente sottomette
un job, il sistema e in grado di analizzare tale richiesta per poter individuare la
coda migliore tra quelle disponibili semplicemente esaminando le regole presenti
nel repository. Gli agenti artificiali sono di fatto Script Shell che vengono eseguiti
periodicamente dal sistema e si comportano come filtri adattivi che intercettano
le informazioni provenienti dalla griglia e le usano per aggiornare il repository.
Questo raffinamento produce regole via via piu efficienti offrendo risultati sempre
piu soddisfacenti. In definitiva, un risultato e da ritenersi soddisfacente nel caso
in cui le regole applicate consentano ad un job di terminare con successo (Done)
in un tempo accettabile. E da notare, da ultimo, che il repository viene utilizzato
anche come contenitore temporaneo in cui possono presentarsi non solo job con
stati finali quali Done o Aborted, ma anche job con stati intermedi come Waiting,
Ready, Scheduled e Running. Nel prossimo capitolo vedremo nel dettaglio come
58
3.4 Un approccio adattivo per il filtraggio delle code
avverra il popolamento della tabella Rules del Database attraverso l’interazione
degli Script con la Grid ed i componenti di GriF.
59
Capitolo 4
Le Ottimizzazioni Realizzate
La realta e quella cosa che, anche se smetti di crederci, non svanisce.- Philip Kindred Dick -
4.1 Introduzione
Nei capitoli precedenti abbiamo introdotto il concetto di job parametrico focaliz-
zando la nostra attenzione sui vantaggi della parametrizzazione. Quando parliamo
di job parametrici assumiamo che un job (che noi chiameremo job padre) viene
frammentato in tante parti (i cosiddetti subjob o job figli). La divisione viene
effettuata sfruttando il parametro k che divide l’input del job padre e determina il
numero dei subjob. In particolare, la sperimentazione e stata condotta su un Ser-
vizio GriF che consente l’esecuzione parametrica in Grid del programma ABC [33].
Tale programma, il cui compito e quello di calcolare la reattivita di un sistema
atomo diatomo utilizzando la meccanica quantistica, si caratterizza soprattutto
per il sistema usato e l’intervallo di energia esplorato. Il sistema studiato viene
caratterizzato mediante dei dati di input e da una routine che ne definisce l’intera-
zione (comunemente detta superficie di energia potenziale), mentre l’intervallo di
energia e definito in input mediante i suoi valori estremi e il numero di energie di
collisione da calcolare. Nello specifico, tale numero verra diviso per la costante di
distribuzione Grid (k) generando cosı gli n subjob che verranno eseguiti in paral-
lelo. Ciascun subjob, quindi, usera la stessa superficie utilizzata dal job padre ma
ognuno avra una parte di input propria da computare. La computazione, come
60
4.2 MySQL e Database GriF
accennato, viene eseguita in parallelo e questo e il principale vantaggio nell’utiliz-
zo dei job parametrici. I risultati di questo approccio tuttavia possono provocare
alcuni svantaggi causati dalla crescita del numero dei job. Il fulcro su cui gravita
l’ottimizzazione delle risorse riguarda proprio questo aspetto ossia come fare in
modo che le performance di GriF non calino al crescere del numero dei subjob.
Infatti piu job vengono sottomessi in griglia e maggiore sara il lavoro che spetta
al Framework. L’obiettivo di GriF e quindi quello di interagire con la griglia in
modo rapido ed efficace. Nei capitoli precedenti abbiamo accennato alla scarsa
efficienza della Grid, a volte inaffidabile per problemi di overhead e correttezza
nel retrieve dei risultati. In particolare, dai test effettuati, abbiamo potuto notare
che le informazioni sullo stato dei job non sempre coincidevano con la realta e que-
sto ha fatto perdere credibilita ad alcuni dei servizi della griglia computazionale
presa in esame. Per questi ed altri motivi, sono stati introdotti alcuni strumenti
di qualita per aumentare le prestazioni del Framework. Prima di tutto e stato
introdotto un Database, strumento necessario per avere sempre a disposizione
la grande quantita di informazioni derivanti dalla propagazione dei subjob in gri-
glia. L’impiego di una base di dati ha permesso, infatti, l’interazione di GriF con
uno strumento molto piu veloce, affidabile ed efficiente rispetto alle informazioni
da recuperare in griglia. Infine, sono stati implementati due Script, denominati
rank.sh e state.sh, il cui compito e quello di reperire le informazioni provenienti
dalla griglia e quindi salvarle nella base di dati. In questo scenario, cruciale e il
ruolo rivestito dal Database, usato come ponte fra GriF e la griglia, e aggiornato
di volta in volta dagli script, costantemente in relazione con la Grid.
4.2 MySQL e Database GriF
Il piu diffuso database Open Source basato sul linguaggio SQL e MySQL [34].
Il codice di MySQL viene sviluppato fin dal 1979 dalla ditta TcX ataconsult -
che poi e diventata MySQL AB. E pero solo dal 1996 che viene distribuita una
versione che supporta SQL e in futuro si prevede il pieno rispetto dello standard
61
4.2 MySQL e Database GriF
ANSI. MySQL e composto da un client con interfaccia a caratteri e un server,
entrambi disponibili sia per sistemi Unix come GNU/Linux che per Windows. Il
codice di MySQL viene rilasciato sotto licenza duale GPL e non libera. Grazie a
questa doppia licenza, chiunque sia interessato all’uso di MySQL in un ambiente
libero od Open Source puo utilizzarlo sotto i termini della normale licenza GPL,
mentre chi lo volesse utilizzare per scopi non liberi puo acquistare la licenza d’uso
[35] dai proprietari del software, e quindi evadere le restrizioni poste dalla licen-
za GPL. Tale licenza viene erroneamente dichiarata da MySQL AB come licenza
commerciale, in realta non e esatto chiamarla in questo modo, poiche un soft-
ware libero puo essere allo stesso tempo commerciale. Tuttavia, fino alla versione
4.0, una buona parte del codice del client era licenziato con la GNU LGPL e
poteva dunque essere utilizzato per applicazioni commerciali. Dalla versione 4.1
in poi, anche il codice dei client e distribuito sotto GNU GPL. Esiste peraltro
una clausola estensiva che consente l’utilizzo di MySQL con una vasta gamma
di licenze libere. Soffermandoci sulle caratteristiche tecniche possiamo affermare
che MySQL e un RDBMS, ossia un sistema di gestione per database relazionali.
Un database e essenzialmente un insieme strutturato di dati. MySQL si occupa
della strutturazione e della gestione a basso livello dei dati stessi, in modo da
velocizzarne l’accesso, la modifica e l’inserimento di nuovi elementi. L’acronimo
RDBMS significa “Relational DataBase Management System” e sta ad indicare
che MySQL offre la possibilita di conservare i dati non in un enorme “storeroom”
ma in diverse tabelle, in modo da velocizzarne l’accesso. L’acronimo SQL significa
“Structured Query Language” ed indica il linguaggio standard di interrogazione
dei Database. Esso e utilizzato per interrogare e gestire basi di dati mediante
l’utilizzo di costrutti di programmazione denominati query. Con SQL si leggono,
si modificano e si cancellano dati nonche si esercitano funzioni gestionali ed ammi-
nistrative sul sistema del database. Alcune delle critiche piu frequenti rivolte ad
SQL riguardano la mancanza di portabilita del codice fra vendors diversi, il modo
inappropriato con cui vengono trattati i dati mancanti (NULL), e la semantica
62
4.2 MySQL e Database GriF
a volte inutilmente complicata. L’utilizzo di MySQL comporta pero importanti
vantaggi:
• E veloce: basta dare un’occhiata ai benchmark1 ufficiali per rimanerne
impressionati [36];
• E affidabile: essendo stato progettato per manipolare molti dati;
• E scalabile: puo funzionare utilizzando da 2 MegaByte di RAM fino a
4GigaByte;
• E versatile: la sua natura Open Source garantisce una versione per ogni
piattaforma.
MySQL svolge il compito di DBMS nella piattaforma LAMP (GNU/Linux: il si-
stema operativo, Apache: il Web server, MySQL: il database management system
(o database server), Perl, PHP e/o Python: i linguaggi di scripting), una delle piu
usate e installate su Internet per lo sviluppo di siti e applicazioni web dinamiche.
Il 16 Gennaio 2008 Sun Microsystem (di recente a sua volta rilevata da Oracle)
ha acquistato la societa per un miliardo di dollari, stimando il mercato del data-
base in 15 miliardi di dollari. I principali introiti provengono dal supporto agli
utilizzatori di MySQL tramite il pacchetto Enterprise, dalla vendita delle licenze
commerciali e dall’utilizzo da parte di terzi del marchio MySQL. MySQL e scritto
in C e C++ e viene testato con un ampia gamma di diversi compilatori. Inoltre
lavora su diverse piattaforme come:
• IBM AIX 4.x e 5.x;
• FreeBSD 5.x e versioni superiori con threads nativi;
• HP-UX 11.x e versioni superiori con threads nativi;1Con il termine benchmark si intende un insieme di test software volti a fornire una misura delle
prestazioni di un computer per quanto riguarda diverse operazioni. Vi e una seconda definizione,relativa ai test di particolari software: in questo caso il benchmark e la determinazione dellacapacita di detto software di svolgere piu o meno velocemente, precisamente od accuratamente,un particolare compito per cui e stato progettato.
63
4.2 MySQL e Database GriF
• Linux;
• Mac OS X;
• NetBSD 1.3/1.4 Intel e NetBSD 1.3 Alpha;
• Novell NetWare 6.0 e 6.5;
• OpenBSD 2.5 con threads nativi e OpenBSD nelle versioni precedenti alla
2.5 con il MIT-pthreads package;
• SCO OpenServer 5.0.X con il recente porting del FSU Pthreads package;
• SCO Openserver 6.0.x;
• SCO UnixWare 7.1.x;
• SGI Irix 6.x con threads nativi;
• Solaris 2.5 e versioni superiori con i threads nativi su SPARC e x86;
• Tru64 Unix;
• Windows 2000, Windows XP, Windows Vista, Windows Server 2003, Win-
dows Server 2008 e Windows Vienna.
L’architettura di MySQL e multilivello con moduli indipendenti. Inoltre essa
e completamente multi-threads con la possibilita di utilizzare piu CPU qualora
disponibili e fornisce Storage Engine sia transazionali che non-transazionali. Il
motore originale di MySQL e costituito da una serie di librerie ISAM per l’accesso
ai dati. L’efficienza dell’implementazione, la stabilita delle release, la possibilita
di utilizzo in rete e la natura Open Source ne hanno decretato l’enorme successo.
Si tratta infatti del piu diffuso RDBMS per le applicazioni web.
64
4.2 MySQL e Database GriF
4.2.1 Modello Entita-Relazione
Per la progettazione dei database viene utilizzato il modello Entity-Relationship
[37] (anche detto modello entita-relazione, modello entita-associazione o modello
E-R) che rende possibile la rappresentazione concettuale dei dati ad un alto livello
di astrazione. Viene spesso utilizzato nella prima fase della progettazione di una
base di dati in cui e necessario tradurre le informazioni risultanti dall’analisi di
un determinato dominio in uno schema concettuale. Il modello E-R si basa su un
insieme di concetti molto vicini alla realta di interesse: quindi facilmente intuibili
dai progettisti (e in genere considerati sufficientemente comprensibili e significati-
vi anche per i non-tecnici), ma non implementabili sugli elaboratori. Infatti, pur
essendo orientato alla progettazione di basi di dati, il modello prescinde dai criteri
specifici di organizzazione fisica dei dati persistenti nei sistemi informatici. Esisto-
no tecniche per la traduzione dei concetti ad alto livello (meglio comprensibili per
gli umani) in concetti di piu basso livello tipici dei vari modelli logici (ad esempio
il modello relazionale) implementati nei diversi RDBMS esistenti. Il modello E-R
ha rappresentato per lungo tempo (e ancora oggi) uno degli approcci piu solidi per
la modellazione di domini applicativi in ambito informatico. Per questo motivo,
e stato spesso usato anche al di fuori del contesto della progettazione di database
ed e stato utilizzato come modello di riferimento per numerose altre notazioni per
la modellazione. Al modello E-R era ispirata, tra l’altro, la notazione OMT poi
confluita in UML. I costrutti principali del modello E-R sono entita, associazioni
e attributi:
• Entita: rappresentano classi di oggetti (come fatti, cose e persone) che
hanno proprieta comuni ed esistenza autonoma ai fini dell’applicazione di
interesse. Un’occorrenza di un’entita e un oggetto della classe che l’entita
stessa rappresenta. Non si parla qui del valore che identifica l’oggetto, ma
piuttosto l’oggetto stesso. Un’interessante conseguenza di questo fatto e che
un’occorrenza di entita ha un’esistenza indipendente dalle proprieta a esso
associate. Da questo punto di vista il modello E-R presenta una marcata
65
4.2 MySQL e Database GriF
differenza rispetto al modello relazionale nel quale non possiamo rappre-
sentare un oggetto senza conoscere alcune sue proprieta. In uno schema
ogni entita ha un nome che la identifica univocamente e viene rappresentata
graficamente tramite un rettangolo con il nome dell’entita all’interno;
• Associazioni: le associazioni (dette anche relazioni) rappresentano un le-
game tra due o piu entita. Il numero di entita collegate identifica il grado
dell’associazione. Un buono schema E-R e caratterizzato da una prevalenza
di associazioni di grado 2. E possibile legare un’entita con se stessa (attraver-
so un’associazione ad anello), sia legare le stesse entita con piu associazioni.
Di norma viene rappresentata graficamente da un rombo contenente il nome
dell’associazione;
• Attributi: un’entita e descritta usando una serie di attributi. Tutti gli og-
getti della stessa classe entita hanno gli stessi attributi: questo e cio che si
intende quando si parla di oggetti simili. La scelta degli attributi riflette il
livello di dettaglio con il quale vogliamo rappresentare le informazioni sulle
entita. Per ogni attributo associato ad una classe entita, dobbiamo definire
un dominio di possibili valori (ad esempio, per l’attributo nome, il domi-
nio potrebbe essere l’insieme delle stringhe di 15 caratteri). Per ciascuna
classe entita, dobbiamo definire anche una chiave. La chiave e un insieme
minimale di attributi che identificano univocamente una tupla all’interno del
database. Potrebbe esserci piu di una chiave ed in questo caso si parla di
chiavi candidate. La scelta pero deve ricadere solo su una chiave candidata,
detta chiave primaria. L’attributo si identifica con un’ellisse al cui inter-
no viene specificato il nome dell’attributo o anche semplicemente, nel caso
di diagrammi complessi, solo il nome. In caso di chiave primaria, il nome
dell’attributo viene sottolineato.
66
4.2 MySQL e Database GriF
4.2.2 Il motore InnoDB
In MySQL una tabella puo essere di diverse tipologie. Ogni tipo di tabella presenta
proprieta e caratteristiche differenti (transazionale o non-transazionale, diverse
prestazioni e strategie di locking piuttosto che altre funzioni particolari). Il tipo di
tabella predefinito di MySQL e denominato MyISAM. Tuttavia MySQL supporta
anche il tipo InnoDB, un particolare motore per il salvataggio dei dati di MySQL,
fornito in tutte le sue distribuzioni e utilizzato nel presente elaborato di Tesi. La
sua caratteristica principale e quella di supportare le transazioni di tipo ACID.
Recentemente e stato acquistato dalla Oracle, che ha intenzione, in generale, di
mantenere inalterate le principali caratteristiche di MySQL AB. Le differenze tra
MyISAM e InnoDB sono:
• Per recuperare una tabella dopo un crash del sistema, InnoDB riesegue le
ultime istruzioni registrate nei log. MyISAM deve invece eseguire una scan-
sione completa della tabella per poi recuperarla, ed eventualmente ricostruire
gli indici. Di conseguenza, il tempo impiegato da InnoDB per il recupero
non aumenta con il crescere dei dati contenuti nella tabella, mentre il tempo
impiegato da MyISAM e proporzionale alle dimensioni della tabella;
• Mentre MyISAM si affida al sistema operativo per il caching delle letture e
delle scritture sulle tabelle, InnoDB ha una sua propria gestione della cache.
Le pagine di dati modificate non vengono cosı inviate immediatamente al
sistema e cio, in alcuni casi, consente a InnoDB di modificare i dati molto
piu rapidamente;
• MyISAM generalmente immagazzina i record di una tabella nell’ordine in cui
sono state create, mentre InnoDB le immagazzina nell’ordine seguito dalla
chiave primaria. Conseguentemente, quando viene utilizzata la chiave per la
lettura di una riga, l’operazione avviene piu rapidamente;
• InnoDB comprime i record molto meno rispetto a MyISAM. Questo significa
che la memoria e lo spazio su disco richiesti da InnoDB sono maggiori, no-
67
4.2 MySQL e Database GriF
nostante nella versione 5 di MySQL lo spazio su disco richiesto sia diminuito
del 20%;
• Allo stato attuale, InnoDB non supporta le ricerche fulltext.
4.2.2.1 Funzionalita del motore InnoDB di MySQL
InnoDB mette a disposizione le seguenti funzionalita:
• transazioni SQL con savepoint e transazioni XA;
• Lock a livello di record;
• Chiavi esterne;
• Integrita referenziale;
• Colonne AUTOINCREMENT;
• Tablespace.
Il lock in InnoDB per quanto riguarda i comandi SELECT e di tipo non-locking.
InnoDB offre delle ottime performance in termini di prestazioni e utilizzo del-
la CPU specialmente quando si ha a che fare con una grande quantita di dati.
InnoDB puo interagire tranquillamente con tutti gli altri tipi di tabelle in MySQL.
4.2.2.2 Limiti delle tabelle InnoDB
Le tabelle InnoDB sono soggette alle seguenti limitazioni:
• Non e possibile creare piu di 1000 colonne per tabella;
• Su alcuni sistemi operativi le dimensione del tablespace non possono superare
i 2 Gb;
• La grandezza di tutti i file di log di InnoDB deve essere inferiore ai 4 Gb;
• La grandezza minima di un tablespace e di 10 Mb;
68
4.2 MySQL e Database GriF
• Non possono essere creati indici di tipo FULLTEXT;
• Le SELECT COUNT(*) su tabelle di grandi dimensioni possono essere molto
lente.
4.2.2.3 Come creare un tabella di tipo InnoDB
Per sapere se InnoDB e presente nella propria installazione di MySQL, eseguire il
comando:
SHOW VARIABLES LIKE ’have_innodb’;
Questo comando mostra il valore della variabile have\_innodb: se essa presenta
il valore “YES”, InnoDB e attivo. Inoltre, per avere una panoramica di tutti i tipi
di tabella attivi e non attivi e possibile eseguire il comando:
SHOW ENGINES;
La sintassi per creare una tabella di tipo InnoDB e la seguente (due alternative):
CREATE TABLE prova (att1 VARCHAR, .....) ENGINE = InnoDB;CREATE TABLE prova (att1 VARCHAR .....) TYPE = InnoDB;
Per convertire una tabella gia esistente in InnoDB Type (due alternative):
ALTER TABLE prova ENGINE = InnoDB;ALTER TABLE prova TYPE = InnoDB;
E comunque consigliato utilizzare la sintassi che prevede l’utilizzo della parola
chiave ENGINE poiche la parola chiave TYPE (utilizzata nelle vecchie versioni di
MySQL) e ormai considerata obsoleta.
4.2.3 Il Database di GriF
Come accennato, GriF ha richiesto l’utilizzo di un Database il cui schema logico
mostrato Figura 4.1. In particolare, vengono rappresentate le seguenti entita:
• VO: le Organizzazioni Virtuali presenti in Grid che utilizzano GriF;
69
4.2 MySQL e Database GriF
Figura 4.1: Il Database di GriF.
• VO User: l’insieme degli utenti (per VO) che utilizzano i servizi di GriF.
Amministratori, Passive User, Active User, Software Developer e Service
Provider sono le classi di appartenenza di ciascun utente, identificate in
base al tipo di attivita e all’utilizzo delle risorse computazionali da parte di
ogni utente;
• Service: i servizi messi a disposizione da ogni VO. Nel nostro elabora-
to di Tesi GriF mette a disposizione degli utenti un solo servizio che e il
programma ABC.
• Rules: ogni job sottomesso in griglia da un utente viene diviso in n subjob
in base al valore della costante k. Tale costante viene scelta dalla VO e rende
possibile la parametrizzazione di un job ossia la suddivisione del suo input
file. La divisione genera quindi n file di input simili tra loro (alcuni para-
metri restano inalterati). “Rules” di fatto contiene le informazioni relative
ai subjob quali ad esempio l’URL, l’URI, lo stato, la data di sottomissione
e la coda che lo ha processato. Lo stato di un job puo essere Null (default),
Waiting, Ready, Scheduled, Running, Aborted e Done con gli ultimi due che
70
4.2 MySQL e Database GriF
decretano il successo o l’insuccesso di un job. E evidente che gli ultimi due
stati sono “stati finali” dai quali il job non puo piu uscire mentre i primi
cinque sono “stati intermedi” che il job assume temporaneamente. La tabel-
la Rules non viene utilizzata esclusivamente come storico di eventi in tempo
reale ma anche come container di regole utilizzate per rendere intelligente
la sottomissione di nuovi subjob in base al successo o all’insuccesso dei job
contenuti in essa;
• Rank: questa tabella, insieme a “Rules”, rappresenta il cuore della base
di dati come mostrato nel Sorgente 4.1. “Rank” memorizza le informazioni
di ciascuna coda comprese la disponibilita, la raggiungibilita, le performan-
ce e le CPU libere. I parametri vengono recuperati dalla griglia mediante
wrapping comando Grid
’lcg-infosites --vo <VO_name> ce’.
L’attributo last_performance di questa tabella viene calcolato utilizzando
una funzione che considera i job totali contenuti nella tabella Rules (TO-
TALJOBS ) eseguiti in ciascuna coda, classificandoli in base al loro successo
(Done) o all’insuccesso (Aborted). In particolare, la funzione utilizzata e la
seguente:
LAST PERFORMANCE =
��DONE
FAILED
�· TOTALJOBS
�
TIME(m)(4.1)
I valori di ciascuna variabile vengono inizializzati rispettivamente a 1000, 1,
1, 1 (DONE, FAILED, TOTALJOBS, TIME ) per evitare errori di inconsi-
stenza. Time rappresenta il tempo medio di esecuzione di una certa coda cal-
colato come sommatoria dei tempi di esecuzione di ogni subjob normalizzati
secondo k. Nel dettaglio:
71
4.2 MySQL e Database GriF
TIME(m) =n�
j=1
EXEC TIME(m)j
k(j), j �= 0 (4.2)
dove n corrisponde al numero totale dei subjob completati con successo e
EXEC TIME e il tempo parziale di esecuzione di un subjob. Questi attributi
vengono poi utilizzati successivamente per calcolare il Rank vero e proprio,
ossia il punteggio che verra assegnato ad ogni coda.
Sorgente 4.1: I sorgenti delle tabelle Rules e Rank del database GriF.1 . . .2 . . .34 CREATE TABLE ru l e s5 (6 u r l s j o b VARCHAR(200) NOT NULL,7 u r i s j o b VARCHAR(200) NOT NULL,8 submit id MEDIUMINT NOT NULL,9 u r l p a r en t VARCHAR(200) NOT NULL,
10 sub date TIMESTAMP(14) DEFAULT 0 ,11 su r f a c e VARCHAR(20) NOT NULL,12 constant INT(2) NOT NULL,13 queue VARCHAR(200) NOT NULL,14 s t a t e ENUM ( ’ Waiting ’ , ’Ready ’ , ’ Scheduled ’ , ’ Running ’ , ’ Aborted ’ ,
’Done ’ ) ,15 t o t a l t ime INT(20) ,16 get ENUM ( ’ no ’ , ’ yes ’ ) ,1718 PRIMARY KEY ( u r l s j ob , u r l p a r en t ) ,19 FOREIGN KEY ( submit id ) REFERENCES submit ( id ) ON UPDATE CASCADE ON DELETE
CASCADE,20 FOREIGN KEY ( u r l pa r en t ) REFERENCES submit ( u r l j o b ) ON UPDATE CASCADE ON
DELETE CASCADE21 )22 ENGINE = InnoDB DEFAULT CHARSET = UTF8;2324 CREATE TABLE rank25 (26 id MEDIUMINT NOT NULL AUTO INCREMENT PRIMARY KEY,27 code VARCHAR(200) UNIQUE KEY,28 f r e e cpu INT(10) ,29 ping FLOAT(10 ,1 ) ,30 l a s t pe r f o rmance FLOAT(10 ,3 ) ,31 ranking FLOAT(10 ,1 )32 )33 ENGINE = InnoDB DEFAULT CHARSET = UTF8;3435 . . .36 . . . ✠✆
72
4.3 Lo Scripting
4.3 Lo Scripting
In informatica un linguaggio di scripting e un linguaggio di programmazione in-
terpretato, destinato in genere a compiti di automazione del sistema (batch) o
delle applicazioni (macro). I programmi sviluppati con questi linguaggi vengono
detti Script, termine della lingua inglese utilizzato in ambito teatrale per indi-
care il testo dove vengono tracciate le parti che devono essere interpretate dagli
attori. Gli Script generalmente sono semplici programmi il cui scopo e quello di
interagire con altri programmi molto piu complessi in cui avvengono le operazioni
piu significative. Gli script si distinguono dai programmi con cui interagiscono, i
quali solitamente sono implementati in un linguaggio differente e non interpretato.
La Shell e uno dei possibili interpreti dei comandi. Molto piu che una semplice
interfaccia tra il kernel del sistema operativo e l’utilizzatore, e ad oggi anche un
vero e proprio potente linguaggio di programmazione. Lo script e uno strumento
semplice da usare per creare applicazioni “incollando” insieme chiamate e coman-
di di sistema, utility e file binari (eseguibili). Ad esempio, uno Shell Script puo
utilizzare virtualmente l’intero repertorio di comandi, utility e strumenti di un
sistema UNIX. Inoltre i comandi interni della shell, come i costrutti condizionali
ed i cicli iterativi, forniscono ulteriore potenza e flessibilita agli Script.
4.3.1 Perche programmare in Shell
Imparare a scrivere degli Script non e difficile ed e veramente esigua la serie di
operatori ed opzioni specifiche che e necessario conoscere. La sintassi e sempli-
ce e chiara, come quella necessaria per eseguire e concatenare utility da riga di
comando. Uno Shell Script e un metodo rapido per costruire un prototipo di
un’applicazione complessa. Inoltre, eseguire anche una serie ridotta di istruzioni
tramite uno Shell Script e spesso un utile primo passo nello sviluppo di un proget-
to. In questo modo si puo verificare e sperimentare la struttura di un’applicazione
e scoprirne i principali errori prima di procedere alla codifica finale in altro lin-
guaggio come ad esempio C, C++, Java o Perl. Lo scripting di Shell e attento
73
4.3 Lo Scripting
alla filosofia classica UNIX e per questo e altamente versatile ed eseguibile su ogni
piattaforma compatibile. Infine “programmare Shell” significa conoscere i siste-
mi operativi, abilitando il programmatore ad eseguire operazioni particolarmente
complesse in modo leggero e con il minimo sforzo.
4.3.2 Caratteristiche
Nei linguaggi di scripting il programmatore generalmente si disinteressa delle ri-
sorse di sistema che il programma finito dovra consumare, demandando il tutto
al sistema stesso. Per risorse si intendono, per esempio, la gestione della allo-
cazione e deallocazione della memoria, la conversione tra tipi, l’inizializzazione
e la chiusura dell’applicazione. In questo modo si evitano molti problemi tipi-
ci della programmazione tradizionale, che inoltre costringe il programmatore ad
occuparsi di problematiche non sempre strettamente connesse con l’obiettivo del
software che deve creare. L’utilizzo di un linguaggio di scripting permette quindi
di concentrarsi direttamente sulla soluzione del problema.
4.3.3 Lo Script rank.sh
L’obiettivo dello script rank.sh e quello di raccogliere le informazioni sullo stato
delle code per poi poterle classificare attraverso la funzione Rank. Abbiamo gia
detto che il Ranking e una funzione che calcola un punteggio che viene assegnato
alla coda in base alle sue performance. Le code vengono messe a disposizione dalle
organizzazioni di una VO (ad esempio l’Universita degli Studi di Perugia della VO
COMPCHEM) che decide le politiche con cui esse vengono gestite, in accordo con
le regole generali della Grid. Di fatto, ogni organizzazione mette a disposizione
uno o piu CE nel quale vengono abilitate una o piu code di esecuzione. In questo
modo si puo scegliere di sottomettere i job in code differenti (tipicamente deno-
minate short, long e infinite) a seconda dei valori minimi e massimi delle policy
utilizzate. Una volta che le code sono a disposizione della griglia possono essere
analizzate. Qui entra in gioco lo script mostrato in figura Figura 4.2. I risultati
dei test effettuati in griglia hanno evidenziato i difetti dei CE, componenti a volte
74
4.3 Lo Scripting
inadatti a fornire informazioni precise riguardo lo stato reale delle code. I CE sono
responsabili della computazione dei job finche essi non sono terminati. Quando
un job raggiunge uno stato finale (Done o Aborted) verra creato automaticamente
(attraverso meccanismi di basso livello gestiti da GriF) il relativo file dei risulta-
ti nell’SE che conferma la sua terminazione. Questa operazione istantanea (che
dovrebbe determinare il raggiungimento di uno stato “Done” per il job) spesso
non viene opportunamente rilevata dalla Grid che quindi introduce un notevole ed
inutile ritardo. Per questo motivo lo script in questione interagisce direttamente
con l’SE al fine di comprendere il reale stato di un job (in particolare se gia in uno
stato “Done”) in un dato istante.
4.3.3.1 Descrizione dello Script
L’unica interazione dello script con la Grid si verifica quando vengono recuperate le
informazioni delle code dei CE attraverso il comando ’lcg-infosites --vo $VO ce’
come mostato nel Sorgente 4.2 (riga 12). L’output del comando viene poi salvato
nel file denominato lcg-infosites.out che da qui in avanti verra utilizzato per
eseguire tutte le operazioni. Dalla riga 15 alla riga 23, tramite i comandi awk e
sed, vengono salvati i nomi delle code e il valore delle CPU libere nei file deno-
minati code e freeCPU. Alla riga 29 si lancia un comando che cancella la tabella
rank in modo tale da avere ogni volta un ambiente ripulito dai risultati delle pre-
cedenti operazioni e quindi aggiornabile in tempo reale. Dalla riga 32 alla riga
43, vengono effettuate le scritture nella tabella. In particolare, per mantenere le
corrispondenze tra ogni coda e il rispettivo valore di CPU libere ci siamo serviti
della funzione AUTO_INCREMENT di MySQL utilizzandola come contatore. Dalla
riga 46 alla riga 58, abbiamo calcolato il tempo medio necessario per raggiungere
ogni coda, salvando poi i risultati nel file denominato ping.tmp. Per sfruttare
al meglio le performance del programma ping abbiamo utilizzato le opzioni -i e
-w che consentono, rispettivamente, di aspettare al piu 2 decimi di secondo tra
ogni invio dei pacchetti ICMP e di diminuire il valore del timeout. Inoltre e sta-
75
4.3 Lo Scripting
ta utilizzata l’opzione -c che, inviando un massimo di cinque pacchetti ICMP di
tipo “ECHO RESPONSE”, garantisce un’esecuzione rapida del comando. Nella
riga 61 viene lanciata una query SQL che rimuove dalla tabella tutte le code con
valori nulli in corrispondenza dei campi ping e free_cpu. Dalla riga 64 fino alla
115 vengono poi calcolate le ultime performance della coda attraverso la funzione
LAST_PERFORMANCE (4.1) gia illustrata nel paragrafo 4.2.3. Dalla riga 138 fino al
termine dello script viene finalmente calcolato il Rank per ogni coda utilizzando
la seguente funzione:
RANK (x, y, z, w) = x (α · y + (z + β) (w + γ)) (4.3)
dove:
• x indica se la coda e up o down e puo assumere rispettivamente i valori 1 o
0;
• y rappresenta la funzione last_performance;
• z rappresenta il numero di CPU libere per ogni coda;
• w rappresenta il tempo di raggiungibilita relativo ad ogni coda;
• α, β e γ rappresentano i pesi che consentono di aumentare o diminuire
l’importanza di ogni componente della funzione.
Piu il valore risultante sara alto, maggiori saranno le performance e quindi mi-
gliore il suo Rank della coda considerata. A questo punto l’inserimento nella
tabella rank e completato e si ha la certezza di avere a disposizione tutte le code
raggiungibili. Da notare che per eseguire lo Script in questione viene utilizzato
crontab, un processo di sistema che consente la pianificazione di comandi UNIX
che poi vengono mandati in esecuzione periodicamente, ad intervalli di tempo. In
particolare rank.sh viene eseguito ogni 15 minuti.
76
4.3 Lo Scripting
Sorgente 4.2: Lo script per l’analisi delle code rank.sh.1 #!/bin/bash
23 USER=”robot@ui . hpc . unipg . i t ”4 VO=”compchem”5 INFOSITES=” lcg− i n f o s i t e s −−vo $VO ce ”6 RANKING=”/var / l i b / tomcat5/programs/LAST GRIF/”7 MYSQL=”mysql −u root −−password=<password> −D g r i f −e”89 ### MAIN ###
1011 # Recupero le informazioni delle code
12 ssh $USER ”$INFOSITES” > ”$RANKING” lcg− i n f o s i t e s . out1314 #CODE
15 awk ’{ pr in t $6 } ’ ”$RANKING” lcg− i n f o s i t e s . out > ”$RANKING”code . tmp16 sed −e ’1 ,/ˆ $/d ’ −e ’ / ˆ [ ]∗ $/d ’ ”$RANKING”code . tmp > ”$RANKING”code17 rm ”$RANKING”code . tmp1819 #FREE CPU
20 awk ’{ pr in t $2 } ’ ”$RANKING” lcg− i n f o s i t e s . out > ”$RANKING”freeCPU . tmp21 sed −e ’1 ,/ˆ $/d ’ −e ’ / ˆ [ ]∗ $/d ’ ”$RANKING”freeCPU . tmp > ”$RANKING”freeCPU22 rm ”$RANKING”freeCPU . tmp23 rm ”$RANKING” lcg− i n f o s i t e s . out2425 CODE=‘ cat ”$RANKING”code ‘26 FREE=‘ cat ”$RANKING”freeCPU ‘2728 # Comando che ripulisce ogni volta la tabella rank
29 $MYSQL ”TRUNCATE TABLE rank app ; ”3031 # Inserisce le code nella tabella rank_app
32 f o r i in $CODE;33 do34 $MYSQL ”INSERT INTO rank app ( code ) VALUES( ’ $i ’ ) ; ”35 done3637 # Inserisce le free cpu nella tabella rank_app
38 z=139 f o r j in $FREE40 do41 $MYSQL ”UPDATE rank app SET f r e e cpu =’$j ’ WHERE id=’$z ’ ; ”42 l e t ”z+=1”43 done4445 # Calcola il ping e lo inserisce nella tabella rank_app
46 awk −F ’ : ’ ’{ pr in t $1 } ’ ”$RANKING”code > ”$RANKING” ping code . tmp47 PING CODE=‘ cat ”$RANKING” ping code . tmp ‘48 z=149 f o r i in $PING CODE50 do51 ssh $USER ”ping − i 0 . 2 −c 5 −w 1 $ i ” > ”$RANKING”ping . tmp52 PING=$ ( sed −n / r t t /p ”$RANKING”ping . tmp | awk −F ’= ’ ’{ pr in t $2 } ’ | awk
−F ’/ ’ ’{ pr in t $2 } ’ )53 $MYSQL ”UPDATE rank app SET ping=’$PING’ WHERE id=’$z ’ ; ”54 l e t ”z+=1”55 done5657 rm ”$RANKING” ping code . tmp58 rm ”$RANKING”ping . tmp5960 # Rimuove le code dove free_cpu =0 e ping =0.0
77
4.3 Lo Scripting
61 $MYSQL ”DELETE FROM rank app WHERE f r e e cpu = ’0 ’ or ping = ’0 .0 ’ ; ”6263 # Calcolo LAST_PERFORMANCE
64 $MYSQL ”SELECT code FROM rank app ; ” > ”$RANKING” code rank . tmp65 sed −e ’1d ’ ”$RANKING” code rank . tmp > ”$RANKING” code rank . out66 rm ”$RANKING” code rank . tmp67 CODE RANK=‘ cat ”$RANKING” code rank . out ‘6869 CMD=$ (command)70 u=171 # Per ogni coda in rank..
72 f o r i in $CODE RANK73 do74 QUEUE=$ ( sed −n ”$u”p ”$RANKING” code rank . out | awk ’{ pr in t $1 } ’ )75 # Conto i job Done computati dalla coda
76 F=$ ($MYSQL ”SELECT COUNT(∗ ) AS Fat t i FROM ru l e s WHERE s t a t e =’Done ’ andqueue=’$QUEUE’ ; ” )
77 # Comando che elimina "Fatti di n" e restituisce solo il valore
78 FATTI=‘echo $F | sed ’ s /\S∗\ s ∗// ’ ‘79 # Calcolo il tempo totale servito a computare i job Done
80 TEMP=$ ($MYSQL ”SELECT SUM(( t o t a l t ime / constant ) ) AS Time from ru l e s WHEREqueue=’$QUEUE’ AND s t a t e =’Done ’ ; ” )
81 TEMPO=‘echo $TEMP | sed ’ s /\S∗\ s ∗// ’ ‘82 i f [ ”$TEMPO” == ”NULL” ]83 then84 TEMPO=”0”85 e l s e86 TEMPO=‘echo ” s c a l e =3; $TEMPO / $FATTI” | bc ‘87 f i88 # Conto i job totali computati dalla coda
89 TOT=$ ($MYSQL ”SELECT COUNT(∗ ) AS Tota l i FROM ru l e s WHERE queue=’$QUEUE’ ; ”| awk ’{ pr in t $1 } ’ )
90 TOTALI=‘echo $TOT | sed ’ s /\S∗\ s ∗// ’ ‘91 # Conto i job Aborted computati dalla coda
92 A=$ ($MYSQL ”SELECT COUNT(∗ ) AS Abo r t i t i FROM ru l e s WHERE s t a t e =’Aborted ’and queue=’$QUEUE’ ; ” )
93 ABORTITI=‘echo $A | sed ’ s /\S∗\ s ∗// ’ ‘94 i f [ ”$TOTALI” −eq 0 ]95 then96 FATTI=100097 ABORTITI=198 TOTALI=199 TEMPO=1
100 f i101 i f [ ”$FATTI” −eq 0 ]102 then103 FATTI=‘expr $FATTI + 1 ‘104 f i105 i f [ ”$ABORTITI” −eq 0 ]106 then107 ABORTITI=‘expr $ABORTITI + 1 ‘108 f i109 # Funzione che calcola last_performance
110 LAST PERFORMANCE=‘echo ” s c a l e =4; ( ( ( ( $FATTI) / ($ABORTITI) ) ∗ $TOTALI) /$TEMPO)” | bc ‘
111 $MYSQL ”UPDATE rank app SET la s t pe r f o rmance =’$LAST PERFORMANCE’ WHEREcode=’$QUEUE’ ; ”
112 l e t ”u+=1”113 done114115 rm ”$RANKING” code rank . out116
78
4.3 Lo Scripting
117 # Funzione che calcola il ranking
118 ALFA=100000119 BETA=1120 GAMMA=1121 $MYSQL ”SELECT code ,
($ALFA∗ l a s t pe r f o rmance +(($BETA+f r e e cpu ) ∗($GAMMA+ping ) ) ) AS rankingFROM rank app ; ” > ”$RANKING” ranking . tmp
122123 sed −e ’1d ’ ”$RANKING” ranking . tmp > ”$RANKING” ranking . out124125 CMD=$ (command)126 h=1127 R OUT=‘ cat ”$RANKING” ranking . out ‘128 # Per ogni coda in rank..
129 f o r k in $R OUT130 do131 QUEUE=$ ( sed −n ”$h”p ”$RANKING” ranking . out | awk ’{ pr in t $1 } ’ )132 RANK=$ ( sed −n ”$h”p ”$RANKING” ranking . out | awk ’{ pr in t $2 } ’ )133 # Inserisco il rank della coda
134 $MYSQL ”UPDATE rank app SET ranking =’$RANK’ WHERE code=’$QUEUE’ ; ”135 l e t ”h+=1”136 done137138 rm ”$RANKING” ranking . tmp139 rm ”$RANKING” ranking . out140 rm ”$RANKING”freeCPU141 rm ”$RANKING”code142143 $MYSQL ”CREATE TABLE IF NOT EXISTS rank LIKE rank app ; ”144 $MYSQL ”TRUNCATE TABLE rank ; ”145 $MYSQL ”INSERT INTO rank (SELECT ∗ FROM rank app ) ; ” ✠✆
4.3.4 Lo Script state.sh
L’obiettivo dello script state.sh, mostrato nel Sorgente 4.3, e quello di aggiun-
gere regole di ottimizzazione nella tabella rules. Abbiamo anticipato che rules,
oltre a contenere le informazioni sui job Done e Aborted, viene utilizzata come
repository temporaneo per aggiornare gli stati intermedi dei job. Tuttavia, gli
aggiornamenti hanno un ruolo secondario rispetto al vero scopo di questa tabella
che e quello di fornire a GriF una collezione di regole per ottimizzare la scelta
delle code. Nel caso, infatti, che un job venga sottomesso in griglia, GriF, cono-
scendo le caratteristiche del job, ha il compito di selezionare una coda tra quelle
disponibili in rules. Un passaggio chiave e percio quello di individuare quelle
code che in passato hanno completato un job simile a quello appena sottomes-
so. Cio consentira di premiare quelle code che, a parita o comunque per Ranking
molto performanti, hanno eseguito job simili. Il confronto avviene in base a due
79
4.3 Lo Scripting
parametri: la superficie scelta dall’utente, che deve coincidere, e la costante k uti-
lizzata per la suddivisione dei job (con uno scostamento di k di ±2). Se la query
risultante generata dal Framework fornisce un risultato significa che esistono una
serie di job cui corrisponde un esito positivo del confronto. In questo modo il
Framework sara in grado di selezionare, tra le code migliori, quelle dove sono stati
eseguiti job simili a quello attuale. Si ricorda che al crescere del numero di regole
(ovvero al crescere dei job eseguiti con successo da GriF) cresce la probabilita di
trovare code adeguatamente performanti. Anche per state.sh abbiamo costruito
una sequenza di operazioni per evitare il piu possibile l’interazione con la Grid
come illustrato nello schema generale di funzionamento del YP di GriF riportato
in Figura 4.2.
Figura 4.2: Lo schema generale di funzionamento del YP di GriF e le interazionicon la Grid.
80
4.3 Lo Scripting
4.3.4.1 Descrizione dello Script
La tabella rules contiene esclusivamente subjob. Come accennato in precedenza,
ogni subjob include il riferimento al job padre. Lo Script deve aggiornare le infor-
mazioni dei subjob discendenti da job padri con stato Null. Null infatti e lo stato
che il job presenta come default. Se lo stato di un job padre e Null significa che i
suoi subjob (o una parte di essi) non sono ancora stati completati. Dalla riga 13
alla riga 21 vengono recuperate le informazioni dei job padri dividendole in due
file denominati rispettivamente url_job.out e insert_rules.out. Il primo file
contiene la lista dei job padri con stato Null mentre il secondo file contiene tutte
le informazioni da replicare nei job figli. Dalla riga 24 alla riga 40 viene lancia-
to il comando glite-job-status per ogni URL presente nel file url_job.out.
L’output di questo comando mostra tutti i subjob in cui il job padre e stato fram-
mentato. Dalla riga 42 alla riga 60 vengono dichiarati una serie di vettori utili al
salvataggio delle informazioni sui subjob derivanti dall’esecuzione del precedente
comando. Da questo punto in avanti, lo Script effettua una sequenza di query
che aggiornano rules assicurandosi di non ricontrollare job gia esaminati in pre-
cedenza. Infatti lo Script deve aggiornare gli stati dei subjob discendenti da job
padri appena sottomessi ma oltre a cio deve anche controllare periodicamente lo
stato dei subjob vecchi. Per fare cio, dalla riga 82 alla riga 101, viene controllata
la presenza di file di risultati (estensione .gz) direttamente nell’SE. Questa ope-
razione e rapida ed efficace ed elimina le imprecisioni derivanti dall’interrogazione
circa lo stato dei job effettuata alla Grid. Il controllo dello stato di un job (Done
o Aborted) si basa sull’esistenza e sulla dimensione degli eventuali file dei risultati,
come segue:
• se il file .gz esiste e la dimensione e = 0 il job e terminato con un insuccesso
(stato Aborted);
• se il file .gz esiste e la dimensione e �= da 0 il job e terminato con successo
(stato Done);
81
4.3 Lo Scripting
Dalla riga 106 alla fine dello script viene effettuata una sequenza di query per
controllare l’integrita delle informazioni precedentemente contenute nel Database
con quelle appena raccolte. Si ricorda infatti che le informazioni derivanti dall’SE
hanno la priorita rispetto a tutto il resto (in quanto piu affidabili). Anche in
questo caso lo Script in questione viene eseguito mediante il comando crontab.
In particolare, lo Script state.sh viene lanciato ogni 60 minuti.
Sorgente 4.3: Lo script di ottimizzazione state.sh.1 #!/bin/bash
23 USER=”robot@ui . hpc . unipg . i t ”4 JOBSTATUS=” g l i t e−job−s t a tu s ”5 STATUS=”/var / l i b / tomcat5/programs/LAST GRIF/”6 MYSQL=”mysql −u root −−password=<password> −D g r i f −e”7 URL SJOB=” i n f o ”8 STATUS STRING=”Current ”9 QUEUE=” Dest ina t i on ”
1011 ### MAIN ###
1213 #seleziono gli url dei job padri
14 $MYSQL ”SELECT u r l j o b FROM submit WHERE s t a t e =’Null ’ ANDjob type=’Parametric ’ ; ” > ”$STATUS” u r l j o b . tmp
15 sed −e ’1d ’ ”$STATUS” u r l j o b . tmp > ”$STATUS” u r l j o b . out16 rm ”$STATUS” u r l j o b . tmp1718 $MYSQL ”SELECT id , username , sur face , constant , sub date FROM submit WHERE
s t a t e =’Null ’ AND job type=’Parametric ’ ; ” > ”$STATUS” i n s e r t r u l e s . tmp19 sed −e ’1d ’ ”$STATUS” i n s e r t r u l e s . tmp | sed s / :// g | sed s/−//g >
”$STATUS” r u l e s . out20 cat ”$STATUS” r u l e s . out | awk −F”\n” ’{ pr in t
subs t r ( $1 , 1 , ( l ength ( $1 )−7) ) subs t r ( $1 , ( l ength ( $1 )−5) , l ength ( $1 ) ) } ’ >
”$STATUS” i n s e r t r u l e s . out21 rm ”$STATUS” i n s e r t r u l e s . tmp2223 #faccio il glite -job -status per ogni url padre
24 CMD=$ (command)25 URL=‘ cat ”$STATUS” u r l j o b . out | t r −d ’\015 ’ ‘26 z=027 f o r i in $URL28 do29 ssh $USER $JOBSTATUS $ i > ”$STATUS” j ob s t a t u s . out30 sed −e ’1 ,11d ’ ”$STATUS” j ob s t a t u s . out > ”$STATUS” j ob s t a t u s . tmp31 URLSJ=$ ( sed −n /$URL SJOB/p ”$STATUS” j ob s t a t u s . tmp | awk ’{ pr in t $7 } ’ )32 STATE=$ ( sed −n /$STATUS STRING/p ”$STATUS” j ob s t a t u s . tmp | awk ’{ pr in t
$3 } ’ )33 Q=$ ( sed −n /$QUEUE/p ”$STATUS” j ob s t a t u s . azz | awk ’{ pr in t $2 } ’ )34 ID=$ (awk ’{ pr in t $1 } ’ ”$STATUS” i n s e r t r u l e s . out )35 USER=$ (awk ’{ pr in t $2 } ’ ”$STATUS” i n s e r t r u l e s . out )36 SURFACE=$ (awk ’{ pr in t $3 } ’ ”$STATUS” i n s e r t r u l e s . out )37 CONSTANT=$ (awk ’{ pr in t $4 } ’ ”$STATUS” i n s e r t r u l e s . out )38 SUB DATE=$ (awk ’{ pr in t $5 } ’ ”$STATUS” i n s e r t r u l e s . out )39 rm ”$STATUS” j ob s t a t u s . tmp40 rm ”$STATUS” j ob s t a t u s . out4142 de c l a r e −a URLVECTOR
82
4.3 Lo Scripting
43 de c l a r e −a STATEVECTOR44 de c l a r e −a QUEUEVECTOR45 de c l a r e −a DATEVECTOR46 de c l a r e −a SURFVECTOR47 de c l a r e −a CONSTVECTOR48 de c l a r e −a IDVECTOR49 de c l a r e −a USERVECTOR5051 IDVECTOR=($ID )52 USERVECTOR=($TMPUSER)53 DATEVECTOR=($SUB DATE)54 SURFVECTOR=($SURFACE)55 CONSTVECTOR=($CONSTANT)56 URLVECTOR=($URLSJ)57 STATEVECTOR=($STATE)58 QUEUEVECTOR=($Q)59 N=${#URLVECTOR [*]}60 N=‘expr $N − 1 ‘61 # Comando che serve per vedere se ho gia ’ controllato gli url padri
62 INSIDE=$ ($MYSQL” SELECT count (∗ ) AS count FROM ru l e s WHEREur l pa r en t =’ $i ’ ; ” )
63 COUNT=‘echo $INSIDE | sed ’ s /\S∗\ s ∗// ’ ‘64 i f [ ”$COUNT” −eq 0 ]65 then66 f o r j in ‘ seq 0 $N ‘67 do68 # Toglie il .f dall ’estensione della superfice
69 SUP=$ ( echo ${SURFVECTOR[ z ]} | t r ” . ” ”\n” | sed 2d)70 # Costruisce l’uri che ci aspettiamo
71 URI SJOB=”ABC−””${USERVECTOR[ z ]} ””−””${DATEVECTOR[ z ]} ”” . ””$SUP”” . x”” . out−”” $ j ”” . gz”
72 # Query di inserimento (la fa solo la prima volta per i sub_job dei
job nuovi)
73 $MYSQL ”INSERT INTO ru l e s VALUES ( ’ ${URLVECTOR[ j ] } ’ , ’ $URI SJOB ’ ,’ ${IDVECTOR[ z ] } ’ , ’ $ i ’ , ’ ${DATEVECTOR[ z ] } ’ , ’ ${SURFVECTOR[ z ] } ’ ,’ ${CONSTVECTOR[ z ] } ’ , ’ ${QUEUEVECTOR[ j ] } ’ , ’ ${STATEVECTOR[ j ] } ’ ,’ ’ , ’ no ’ ) ; ”
74 done75 e l s e76 f o r j in ‘ seq 0 $N ‘77 do78 # Toglie il .f dall ’estensione della superfice
79 SUP=$ ( echo ${SURFVECTOR[ z ]} | t r ” . ” ”\n” | sed 2d)80 URI SJOB=”ABC−””${USERVECTOR[ z ]} ””−
””${DATEVECTOR[ z ]} ”” . ””$SUP”” . x”” . out−”” $ j ”” . gz”81 # Calcolo la dimensione dei file .gz che recupero dall ’SE
82 DIMENSIONE=$ ( ssh $USER / a l tboo t /opt/ g l i t e / bin / g l i t e−g r id f tp− l s − lg s i f t p : // se . hpc . unipg . i t /tmp/ | grep $URI SJOB | awk ’{ pr in t $5 } ’ )
83 i f [ −z ”$DIMENSIONE” ]84 then85 DIMENSIONE=−186 f i87 i f [ ”$DIMENSIONE” −eq 0 ]88 then89 $MYSQL ”UPDATE ru l e s SET s t a t e =’Aborted ’ WHERE
u r l s j o b =’${URLVECTOR[ j ]} ’ AND ( s t a t e =’Ready ’ ORs t a t e =’Scheduled ’ OR s t a t e =’Running ’ OR s t a t e =’Waiting ’ ) ; ”
90 f i91 i f [ ”$DIMENSIONE” −gt 0 ]92 then93 ATTUALE=‘date ”+%Y−%m−%d %H:%M:%S” ‘
83
4.3 Lo Scripting
94 T=$ ($MYSQL”SELECT sub date from ru l e s WHEREu r l s j o b =’${URLVECTOR[ j ]} ’ ” )
95 TIME DB=‘echo $T | sed ’ s /\S∗\ s ∗// ’ ‘96 MIN=$ ($MYSQL ”SELECT TIMESTAMPDIFF(MINUTE, ’ $TIME DB’ , ’$ATTUALE’ ) AS
MIN; ” )97 MINUTI=‘echo $MIN | sed ’ s /\S∗\ s ∗// ’ ‘98 $MYSQL ”UPDATE ru l e s SET s t a t e =’Done ’ , t o t a l t ime =’$MINUTI ’ WHERE
u r l s j o b =’${URLVECTOR[ j ]} ’ AND ( s t a t e =’Ready ’ ORs t a t e =’Scheduled ’ OR s t a t e =’Running ’ OR s t a t e =’Waiting ’ ) ; ”
99 f i100 i f [ ”$DIMENSIONE” −eq −1 ]101 then102 # Query di update del campo state dei sub_job dei padri gia ’ presi
precedentemente
103 $MYSQL ”UPDATE ru l e s SET s t a t e =’${STATEVECTOR[ j ] } ’ WHEREu r l s j o b =’VECTOR[ j ] } ’ AND ( s t a t e =’Ready ’ OR s t a t e =’Scheduled ’OR s t a t e =’Running ’ OR s t a t e =’Waiting ’ ) ; ”
104 f i105 # Controllo integrita ’ DB con SE
106 URI DA =$ ($MYSQL ” Se l e c t u r i s j o b from ru l e s whereu r l s j o b =’${URLVECTOR[ j ] } ’ ; ” )
107 URI DA CONTROLLARE=‘echo $URI DA | sed ’ s /\S∗\ s ∗// ’ ‘108 STATO DA =$ ($MYSQL ” Se l e c t s t a t e from ru l e s where
u r l s j o b =’${URLVECTOR[ j ] } ’ ; ” )109 STATO DA CONTROLLARE=‘echo $STATO DA | sed ’ s /\S∗\ s ∗// ’ ‘110 DIM=$ ( ssh $USER / a l tboo t /opt/ g l i t e / bin / g l i t e−g r id f tp− l s − l
g s i f t p : // se . hpc . unipg . i t /tmp/ | grep $URI DA CONTROLLARE | awk’{ pr in t $5 } ’ )
111 i f [ −z ”$DIM” ]112 then113 DIM=−1114 f i115 i f [ ”$DIM” − l t 0 ] && [ ”$STATO DA CONTROLLARE” == ”Done” ]116 then117 $MYSQL ”UPDATE ru l e s SET s t a t e =’Aborted ’ WHERE
u r l s j o b =’${URLVECTOR[ j ] } ’ ; ”118 f i119 i f [ ”$DIM” −gt 0 ] && [ ”$STATO DA CONTROLLARE” == ”Aborted” ]120 then121 ATTUALE=‘date ”+%Y−%m−%d %H:%M:%S” ‘122 T=$ ($MYSQL”SELECT sub date from ru l e s WHERE
u r l s j o b =’${URLVECTOR[ j ]} ’ ” )123 TIME DB=‘echo $T | sed ’ s /\S∗\ s ∗// ’ ‘124 MIN=$ ($MYSQL ”SELECT TIMESTAMPDIFF(MINUTE, ’ $TIME DB’ , ’$ATTUALE’ ) AS
MIN; ” )125 MINUTI=‘echo $MIN | sed ’ s /\S∗\ s ∗// ’ ‘126 $MYSQL ”UPDATE ru l e s SET s t a t e =’Done ’ , t o t a l t ime =’$MINUTI ’ WHERE
u r l s j o b =’${URLVECTOR[ j ] } ’ ; ”127 f i128 i f [ ”$DIM” −gt 0 ] && [ ”$STATO DA CONTROLLARE” == ”Done” ]129 then130 ATTUALE=‘date ”+%Y−%m−%d %H:%M:%S” ‘131 T=$ ($MYSQL”SELECT sub date from ru l e s WHERE
u r l s j o b =’${URLVECTOR[ j ]} ’ ” )132 TIME DB=‘echo $T | sed ’ s /\S∗\ s ∗// ’ ‘133 MIN=$ ($MYSQL ”SELECT TIMESTAMPDIFF(MINUTE, ’ $TIME DB’ , ’$ATTUALE’ ) AS
MIN; ” )134 MINUTI=‘echo $MIN | sed ’ s /\S∗\ s ∗// ’ ‘135 $MYSQL ”UPDATE ru l e s SET to t a l t ime =’$MINUTI ’ WHERE
u r l s j o b =’${URLVECTOR[ j ] } ’ ; ”136 f i137 i f [ ”$DIM” −eq 0 ] && [ ”$STATO DA CONTROLLARE” == ”Done” ]
84
4.3 Lo Scripting
138 then139 $MYSQL ”UPDATE ru l e s SET s t a t e =’Aborted ’ WHERE
u r l s j o b =’${URLVECTOR[ j ] } ’ ; ”140 f i141 done142 f i143 l e t ”z+=1”144 J=$ ($MYSQL ”SELECT count (∗ ) FROM ru l e s WHERE ur l pa r en t =’ $i ’ ; ” )145 JOB=‘echo $J | sed ’ s /\S∗\ s ∗// ’ ‘146 echo $JOB147 D=$ ($MYSQL ”SELECT count (∗ ) FROM ru l e s WHERE ur l pa r en t =’ $i ’ AND
s t a t e =’Done ’ ; ” )148 DONE=‘echo $D | sed ’ s /\S∗\ s ∗// ’ ‘149 echo $DONE150 A=$ ($MYSQL ”SELECT count (∗ ) FROM ru l e s WHERE ur l pa r en t =’ $i ’ AND
s t a t e =’Aborted ’ ; ” )151 ABORT=‘echo $A | sed ’ s /\S∗\ s ∗// ’ ‘152 echo $ABORT153 K=‘expr $DONE + $ABORT‘154 i f [ $ABORT −eq $JOB ]155 then156 $MYSQL ”UPDATE submit SET s t a t e =’Aborted ’ WHERE u r l j o b =’$i ’ ; ”157 f i158 i f [ $K −eq $JOB ] && [ $DONE −ne 0 ]159 then160 $MYSQL ”UPDATE submit SET s t a t e =’Done ’ WHERE u r l j o b =’$i ’ ; ”161 f i162 done163164 rm ”$STATUS” r u l e s . out165 rm ”$STATUS” i n s e r t r u l e s . out166 rm ”$STATUS” u r l j o b . out ✠✆
85
Capitolo 5
Conclusioni e Future Work
Anche da giovane non riuscivo a condividere l’opinione che,se la conoscenza e pericolosa, la soluzione ideale risiede nell’ignoranza.Mi e sempre parso, invece, che la risposta autentica a questo problema
stia nella saggezza. Non e saggio rifiutarsi di affrontare il pericolo,anche se bisogna farlo con la dovuta cautela. Dopotutto, e questo il senso
della sfida posta all’uomo fin da quando un gruppo di primati si evolsenella nostra specie. Qualsiasi innovazione tecnologica puo essere pericolosa:
il fuoco lo e stato fin dal principio, e il linguaggio ancor di piu;si puo dire che entrambi siano ancora pericolosi al giorno d’oggi,
ma nessun uomo potrebbe dirsi tale senza il fuoco e senza la parola.- Isaac Asimov -
Il lavoro svolto in questo elaborato di Tesi ha portato allo sviluppo di un
Framework collaborativo per la sottomissione ottimizzata di job parametrici in
ambiente Grid. In particolare sono stati analizzati gli aspetti che hanno porta-
to al miglioramento delle performance delle code, fin qui anello particolarmente
debole dell’architettura della Grid presa in esame. Questo lavoro si basa essen-
zialmente sull’implementazione di due script che interagiscono con il Database di
GriF che esenta tale Framework da continue interazioni con la griglia. Questo
ha comportato il fatto che la prima parte del presente lavoro sia stato dedicato
all’analisi dettagliata della Grid di produzione del progetto EGEE. Sta diventando
infatti sempre piu evidente che la tecnologia Grid rappresentera il detonatore di
una profonda rivoluzione organizzativa ed una forte spinta per la reale convergen-
za di tutte quelle metodologie scientifiche e di calcolo di molti campi della ricerca.
Nella seconda parte invece il comportamento dei job e stato analizzato al fine di
86
5. Conclusioni e Future Work
studiare e mettere a punto delle strategie per rendere performanti le esecuzioni
nelle code Grid. I due Script prodotti (rank.sh e state.sh) sono i componenti
essenziali che rendono il Framework considerato intelligente e capace di avviare in-
dagini riguardanti la tipologia degli utenti che lo utilizzano. Il presente elaborato
di Tesi troverebbe, percio, un naturale sbocco nello sviluppo di un ulteriore com-
ponente o modulo capace di eseguire profilazioni ripartite per modelli di utilizzo
allo scopo di calcolare indici di Qualita relativi alle attivita degli utenti (Quality
of User, o QoU), a partire dalle informazioni registrate dai sensori di GriF circa il
comportamento ed i risultati ottenuti dagli utenti. Solo una adeguata profilazione
(e quindi il calcolo di una accurata QoU) puo consentire infatti alle VO, quale ad
esempio COMPCHEM, di raggiungere importanti obiettivi come la creditizzazione
degli utenti e in fin dei conti la sua stessa sostenibilita in Grid.
87
Appendice A
Sorgenti
A.1 grif.sql
12 -- DATABASE grif --
34 -- cancella le tabelle --
56 DROP TABLE IF EXISTS ru l e s CASCADE;7 DROP TABLE IF EXISTS submit CASCADE;8 DROP TABLE IF EXISTS own CASCADE;9 DROP TABLE IF EXISTS s e r v i c e CASCADE;
10 DROP TABLE IF EXISTS vouser CASCADE;11 DROP TABLE IF EXISTS vo CASCADE;12 DROP TABLE IF EXISTS rank CASCADE;1314 -- crea le tabelle --
1516 -- TABLE rank
1718 CREATE TABLE rank19 (20 id MEDIUMINT NOT NULL AUTO INCREMENT PRIMARY KEY,21 code VARCHAR(200) UNIQUE KEY,22 f r e e cpu INT(10) ,23 ping FLOAT(10 ,1 ) ,24 l a s t pe r f o rmance FLOAT(10 ,3 ) ,25 ranking FLOAT(10 ,1 )26 )27 ENGINE = InnoDB DEFAULT CHARSET = UTF8;2829 -- TABLE vo
3031 CREATE TABLE vo32 (33 name VARCHAR(20) PRIMARY KEY,34 admin VARCHAR(20)35 )36 ENGINE = InnoDB DEFAULT CHARSET = UTF8;3738 -- TABLE vouser
3940 CREATE TABLE vouser
88
A.1 grif.sql
41 (42 username VARCHAR(20) NOT NULL,43 name vo VARCHAR(20) NOT NULL,44 passwd VARCHAR(50) NOT NULL,45 s a l t VARCHAR(50) NOT NULL,46 name VARCHAR(30) NOT NULL,47 surname VARCHAR(30) NOT NULL,48 address VARCHAR(100) NOT NULL,49 te l ephone VARCHAR(15) NOT NULL,50 mail VARCHAR(30) NOT NULL,51 type ENUM ( ’ admin ’ , ’ p a s s i v e u s e r ’ , ’ a c t i v e u s e r ’ ,
’ s o f twa r e deve l ope r ’ , ’ s e r v i c e p r o v i d e r ’ ) ,52 e r r s i n INT(5) ,53 err sem1 INT(5) ,54 err sem2 INT(5) ,55 err sem3 INT(5) ,56 num comp INT(5) ,57 err comp INT(5) ,5859 PRIMARY KEY ( username , name vo ) ,60 FOREIGN KEY (name vo ) REFERENCES vo (name) ON UPDATE CASCADE ON DELETE
CASCADE61 )62 ENGINE = InnoDB DEFAULT CHARSET = UTF8;6364 -- TRIGGER validazione mail
6566 -- INSERT
6768 DELIMITER //6970 DROP TRIGGER IF EXISTS check mai l //7172 CREATE TRIGGER check mai l73 BEFORE INSERT ON vouser74 FOR EACH ROW75 BEGIN76 IF NEW. mail NOT REGEXP77 ’ ˆ [ a−z0−9 \.−]+@[ a−z0−9 − ]+\ . [ a−z0−9 \.−]+$ ’ THEN78 SET NEW. mail = ’ e−mail@not . ok ’ ;79 END IF ;80 END//8182 -- UPDATE
8384 DROP TRIGGER IF EXISTS check mai l up //8586 CREATE TRIGGER check mai l up87 AFTER UPDATE ON vouser88 FOR EACH ROW89 BEGIN90 IF NEW. mail NOT REGEXP91 ’ ˆ [ a−z0−9 \.−]+@[ a−z0−9 − ]+\ . [ a−z0−9 \.−]+$ ’ THEN92 UPDATE vouser SET username = OLD. username , name vo = OLD. name vo ,
passwd = OLD. passwd ,93 s a l t = OLD. sa l t , name = OLD. name , surname = OLD. surname , address =
OLD. address ,94 te l ephone = OLD. te lephone , mail = OLD. mail , type = OLD. type WHERE
username = NEW. username ;95 END IF ;96 END//97
89
A.1 grif.sql
98 DELIMITER ;99
100 -- TABLE service
101102 CREATE TABLE s e r v i c e -- alias job
103 (104 name VARCHAR(20) NOT NULL,105 yp VARCHAR(150) NOT NULL,106 co s t FLOAT(10 ,2 ) NOT NULL,107 d e s c r i p t i o n VARCHAR(500) NOT NULL,108109 PRIMARY KEY (name , yp )110 )111 ENGINE = InnoDB DEFAULT CHARSET = UTF8;112113 -- TRIGGER controllo costo
114115 -- INSERT
116117 DELIMITER //118119 DROP TRIGGER IF EXISTS check co s t //120121 CREATE TRIGGER check co s t122 BEFORE INSERT ON s e r v i c e123 FOR EACH ROW124 BEGIN125 IF NEW. co s t < 0 THEN126 SET NEW. co s t = 0 ;127 END IF ;128 END//129130 -- UPDATE
131132 DROP TRIGGER IF EXISTS check cos t up //133134 CREATE TRIGGER check cos t up135 AFTER UPDATE ON s e r v i c e136 FOR EACH ROW137 BEGIN138 IF NEW. co s t < 0 THEN139 UPDATE s e r v i c e SET name = OLD. name , yp = OLD. yp , co s t = OLD. cost ,
d e s c r i p t i o n = OLD. d e s c r i p t i o n140 WHERE name = NEW. name AND yp = NEW. yp ;141 END IF ;142 END//143144 DELIMITER ;145146 -- TABLE own
147148 CREATE TABLE own149 (150 vo VARCHAR(20) NOT NULL ,151 s e r v i c e VARCHAR(20) NOT NULL,152 yp VARCHAR(150) NOT NULL,153154 PRIMARY KEY (vo , s e r v i c e , yp ) ,155 FOREIGN KEY (vo ) REFERENCES vo (name) ON UPDATE CASCADE ON DELETE CASCADE,156 FOREIGN KEY ( s e rv i c e , yp ) REFERENCES s e r v i c e (name , yp ) ON UPDATE CASCADE
ON DELETE CASCADE157 )
90
A.1 grif.sql
158 ENGINE = InnoDB DEFAULT CHARSET = UTF8;159160 -- TABLE submit
161162 CREATE TABLE submit163 (164 id MEDIUMINT NOT NULL AUTO INCREMENT PRIMARY KEY,165 username VARCHAR(20) NOT NULL,166 s e r v i c e VARCHAR(20) NOT NULL,167 yp VARCHAR(150) NOT NULL,168 u r l j o b VARCHAR(200) NOT NULL UNIQUE KEY,169 sub date TIMESTAMP(14) DEFAULT CURRENT TIMESTAMP,170 u r i VARCHAR(200) NOT NULL,171 s t a t e ENUM ( ’ Aborted ’ , ’Done ’ , ’ Nul l ’ ) ,172 su r f a c e VARCHAR(20) NOT NULL,173 lnput VARCHAR(40) NOT NULL,174 constant INT(2) NOT NULL,175 enrg FLOAT(10 ,2 ) NOT NULL,176 dnrg FLOAT(10 ,2 ) NOT NULL,177 nnrg FLOAT(10 ,2 ) NOT NULL,178 job type ENUM ( ’ S e r i a l ’ , ’ Parametric ’ ) ,179 r e t r i e v e ENUM ( ’N ’ , ’Y ’ ) NOT NULL,180181 FOREIGN KEY ( username ) REFERENCES vouser ( username ) ON UPDATE CASCADE ON
DELETE CASCADE,182 FOREIGN KEY ( s e rv i c e , yp ) REFERENCES s e r v i c e (name , yp ) ON UPDATE CASCADE
ON DELETE CASCADE183 )184 ENGINE = InnoDB DEFAULT CHARSET = UTF8;185186 -- TABLE rules
187188 CREATE TABLE ru l e s189 (190 u r l s j o b VARCHAR(200) NOT NULL,191 u r i s j o b VARCHAR(200) NOT NULL,192 submit id MEDIUMINT NOT NULL,193 u r l p a r en t VARCHAR(200) NOT NULL,194 sub date TIMESTAMP(14) DEFAULT 0 ,195 su r f a c e VARCHAR(20) NOT NULL,196 constant INT(2) NOT NULL,197 queue VARCHAR(200) NOT NULL,198 s t a t e ENUM ( ’ Waiting ’ , ’Ready ’ , ’ Scheduled ’ , ’ Running ’ , ’ Aborted ’ ,
’Done ’ ) ,199 t o t a l t ime INT(20) ,200 get ENUM ( ’ no ’ , ’ yes ’ ) ,201202 PRIMARY KEY ( u r l s j ob , u r l p a r en t ) ,203 FOREIGN KEY ( submit id ) REFERENCES submit ( id ) ON UPDATE CASCADE ON DELETE
CASCADE,204 FOREIGN KEY ( u r l pa r en t ) REFERENCES submit ( u r l j o b ) ON UPDATE CASCADE ON
DELETE CASCADE205 )206 ENGINE = InnoDB DEFAULT CHARSET = UTF8;207208 ALTER TABLE vo ADD FOREIGN KEY(admin ) REFERENCES vouser ( username ) ; ✠✆
91
Glossario
ACID Atomicity, Consistency, Isolation, Durability,
44
ANSI American National Standards Institute, 61
API Application Programming Interface, 4
CA Certificate Authority, 32
CASPUR Consorzio interuniversitario per le Applicazio-
ni di Supercalcolo Per Universita e Ricerca,
5
CE Computing Element, 19
CERN Organizzazione Europea per la Ricerca
Nucleare, 2
CICS Customer Information Control System, 8
CNR Consiglio Nazionale delle Ricerche, 5
COMPCHEM Computational Chemistry, 36
CORBA Common Object Request Broker Architectu-
re, 38
CREAM Computing Resource Execution And Mana-
gement, 22
CSC Center for Scientific Computing, 16
92
Glossario
DELPHI DEtector with Lepton, Photon and Hadron
Identification, 2
DMS Data Management Service, 19
EBA EGEE Business Associates, 18
EDG European Data Grid, 11
EGEE Enabling Grids for E-sciencE, 5
EGI European Grid Initiative, 5
EGI DS EGI Design Study, 14
ENEA Ente per le Nuove Tecnologie, l’Energia e
l’Ambiente, 5
FTP File Transfer Protocol, 42
FTS File Transfer Service, 28
GACL Grid Access Control List, 21
GARR Gestione Ampliamento Rete Ricerca, 5
GILDA Grid INFN Laboratory for Dissemination
Activities, 5
GNU GNU’s Not Unix, 61
GPL General Public Licence, 61
GriF Grid Framework, 36
GSI Grid Security Infrastructure, 13
GUI Graphical User Interface, 52
HTTP HyperText Transfer Protocol, 40
HTTPS HyperText Transfer Protocol Secure sockets,
40
93
Glossario
ICE Interface to CREAM Environment, 23
ICMP Internet Control Message Protocol, 56
IDE Integrated Development Environment, 50
IGI Italian Grid Infrastructure, 5
INAF Istituto Nazionale di Astrofisica, 5
INFN Istituto Nazionale di Fisica Nucleare, 2
IS Information Service, 19
ISM Information Supermarket, 24
J2EE Java 2 Enterprise Edition, 20
JDL Job Description Language, 24
JIT Just In Time, 50
JRU Joint Research Unit, 5
JW Job Wrapper, 19
LAMP Linux, Apache, MySQL, PHP/Python/Perl,
63
LCAS Local Centre Authorization Service, 21
LCMAPS Local Credential Mapping Service, 21
LGPL Lesser General Public License, 61
LRMS Local Resource Management System, 26
LSF Load Sharing Facility, 21
MAN Metropolitan Area Network, 41
MPS MyProxy Server, 19
MSS Mass Storage System, 27
94
Glossario
NAREGI NAtional REsearch Grid Initiative, 18
NGI National Grid Initiatives, 14
OASIS Advancing open standars for the information
society, 5
OGF Open Grid Forum, 11
OGSA Open Grid Services Architecture, 13
OMT Object Modeling Technique, 64
OOP Object Oriented Programming, 50
PBS Portable Batch System, 21
RAM Random-Access Memory, 63
RB Resource Broker, 24
RDBMS Relation Database Management System, 61
RLS Replica Location Service, 28
RMC Replica Metadata Catalog, 28
RMS Resource Management System, 20
ROS Replica Optimization Service, 28
RPC Remote Procedure Call, 42
SDK Software Development Kit, 4
SE Storage Element, 19
SISSA Scuola Internazionale Superiore di Studi
Avanzati, 5
SMTP Simple Mail Transfer Protocol, 42
SOA Service-Oriented Architecture, 36
SOAP Simple Object Access Protocol, 12
95
Glossario
SPACI Southern Partnership for Advanced Compu-
tational Infrastructures, 5
SQL Structured Query Language, 52
SRM Storage Resource Management, 28
SSI Single System Image, 57
TQ Task Queue, 24
UDDI Universal Description Discovery and Integra-
tion, 42
UI User Interface, 19
UML Unified Modelling Language, 64
URI Universal Resource Identifier, 70
URL Universal Resource Locator, 70
VM Virtual Machine, 50
VO Virtual Organization, 1
VOMS Virtual Organization Membership Server, 19
W3C World Wide Web Consortium, 5
WM Workload Manager, 24
WMS Workload Management System, 19
WSDL Web Serice Description Language, 22
WSRF Web Service Resource Framwork, 33
XA eXtended Architecture, 68
XML Extensible Markup Language, 37
96
Glossario
YC Yet a Consumer, 41
YP Yet a Provider, 41
YR Yet a Registry, 42
97
Bibliografia
[1] Istituto Nazionale di Fisica Nucleare, http://www.infn.it
[2] DELPHI Experiment, http://delphiwww.cern.ch/Welcome.html
[3] I. Foster, C. Kesselman, The GRID - Blueprint for a new Computing
Infrastructure, Argonne National Laboratory & University of Chicago.
[4] I. Foster, C. Kesselman, The anatomy of the Grid, Morgan Kaufmann Press
1998.
[5] Globus Toolkit Homepage, http://www.globus.org/toolkit
[6] The DataGrid Project, http://eu-datagrid.web.cern.ch/eu-datagrid
[7] Research & technological development for a Data TransAtlantic Grid
http://datatag.web.cern.ch/datatag
[8] Home of the EGRID project, http://www.egrid.it
[9] Southern Partnership for Advanced Computational Infrastructures:
http://spacin-wn02.dma.unina.it/index.php/it/members/spaci-srl
[10] EGEE Portal, http://www.eu-egee.org
[11] GRID.IT: An Italian National Research Council Project on Grid Computing
Funded under the National Programme
http://www.grid.it
[12] The WS-Resource Framework, http://www.globus.org/wsrf
98
BIBLIOGRAFIA
[13] Ufficio Italiano W3C, http://www.w3c.it
[14] Advancing open standars for the information society:
http://www.oasis-open.org/home/index.php
[15] European Grid Initiative Design Study, http://web.eu-egi.eu
[16] The Gilda, http://glite.web.cern.ch/glite
[17] Italian Grid Infrastructure, http://Grid-it.cnaf.infn.it
[18] M. Chetty, R. Buyya, Weaving Electrical and Computational Grids: How
Analogous Are They? Technical Report, Monash University, Novembre 2001
http://buyya.com/papers/gridanalogy.pdf.
[19] I. Foster, C. Kesselman, Computational Grids, Argonne National
Laboratory & University of Chicago (2001).
[20] CISC, http://www.ibm.com/C ISC
[21] Websphere, http://www.ibm.com/software/websphere
[22] The Tibco, http://www.tibco.com
[23] Open Grid Forum, http://www.ogf.org
[24] European Data Grid:
ttp://www.globus.org/alliance/news/EDG-index.html
[25] The Globus Alliance, http://www.globus.org
[26] The GEANT2, http://www.geant2.net
[27] The Open Science Grid, http://www.opensciencegrid.org
[28] Nationl Research Grid Initiative, http://www.naregi.org
[29] Condor Project Homepage, http://www.cs.wisc.edu/condor
99
BIBLIOGRAFIA
[30] Lightweight Middleware for Grid Computing, http://glite.web.cern.ch/glite
[31] CORBA, the Common Object Request Broker Architecture:
http://www.corba.org/
[32] Distributed Component Object Model:
http://it.wikipedia.org/wiki/Distributed Component Object Model
[33] D. Skouteris, J. F. Castillo, D. E. Manolopoulos: ABC: A Quantum
Reactive Scattering Program, Comp. Phys. Comm., 133, 128-135 (2000).
[34] MySQL website, http://www.mysql.com
[35] MySQL Non-free license:
http://www.mysql.com/company/legal/licensing/commercial-license.html
[36] MySQL/Sun set World Record SPECJ Benchmark:
http://www.mysql.com/why-mysql/benchmarks/
[37] Entity-relationship model:
http://en.wikipedia.org/wiki/Entity-relationship model
100
Grazie
Giunto al termine di questo lavoro desidero ringraziare ed esprimere la mia rico-
noscenza nei confronti di tutte le persone che, in modi diversi, mi sono state vicine
e hanno permesso e incoraggiato sia i miei studi che la realizzazione e stesura di
questa tesi. I miei piu sentiti ringraziamenti vanno a chi mi ha seguito in questi
mesi:
il Prof. Antonio Lagana, per la fiducia fin da subito dimostratami e per avermi
seguito durante lo svolgimento del lavoro con consigli e confronti che mi hanno
aiutato ad intraprendere, ogni volta, le scelte piu appropriate.
Il Dott. Carlo Manuali, per la continua disponibilita e prontezza nei charimenti
e suggerimenti, per la rilettura critica di tutti i capitoli della tesi e per avermi gui-
dato con i suoi suggerimenti durante la conclusione di questo percorso formativo.
Il Dott. Leonardo Pacifici, per i suoi preziosi consigli e per la sincerita dimo-
stratami come uomo e come amico.
Rimarra in me il piacevole ricordo di questi sette anni di studio che ho trascorso
“a tempo pieno” in questo dipartimento nel quale ho trovato, quasi sempre, pro-
fessori che hanno contribuito, con indicazioni e suggerimenti, al raggiungimento di
questo traguardo per me importante. Ringrazio la mia famiglia e tutti gli amici
per essermi stati vicini durante questi anni trascorsi da studente, per avermi sem-
pre supportato ma piu di tutto “sopportato”.
Il mio primo pensiero va ai miei genitori a cui dedico questo lavoro di tesi: senza
il loro aiuto non avrei mai raggiunto questa meta. Sono davvero grato per tutto
il sostegno economico ricevuto ma piu di ogni altra cosa per quell’aiuto tacito o
101
esplicito venuto dal loro cuore, per tutte quelle volte che mi hanno incoraggiato
vedendomi preso dallo studio, da un esame o da questa tesi. Mi auguro che tutti
i sacrifici fatti siano in questo modo, almeno in parte, ripagati.
Un pensiero particolare va a mio fratello Giorgio che ha tentato di spronarmi nei
recenti momenti di difficolta.
Ringrazio Orsola che con estrema pazienza ha sopportato i miei sbalzi di umore
e le mie paranoie quando, sotto stress, mi sono sfogato con lei. Se ho raggiunto
questo traguardo lo devo anche alla sua continua presenza, per avermi fatto capire
che potevo farcela, incoraggiandomi a non mollare mai.
Come non ringraziare tutti gli Amici dell’Universita e in particolare i miei compa-
gni dell’“Aula B2” con i quali ho vissuto piu da vicino tre anni di intenso studio
ma anche di piacevoli svaghi. Ora, piu di tutti, possono comprendere il mio grado
di soddisfazione.
Ringrazio di cuore Andrea con il quale ho affrontato il mio percorso di studi e
la maggior parte degli esami ma soprattutto perche insieme abbiamo condiviso
con tenacia passioni e aspirazioni comuni e mi auguro che continueremo a farlo.
Non dimentichero mai quello che ha fatto per me, cosa mi ha insegnato e come
mi ha sostenuto nei tanti momenti delicati. E stato un privilegio trascorrere tutto
questo tempo con una persona cosı straordinaria e mi sento fortunato per averla
incontrata.
Grazie all’umorismo e all’ottimismo di Simone: senza la sua influenza positiva
non avremmo fatto cosı tanti esami in poco tempo.
Non dimentico di certo Danilo con il quale ho condiviso casa per due anni e con
cui ho preparato alcuni degli ultimi esami (in particolare l’esame di Crittografia).
Desidero ringraziare tutte le persone con cui ho iniziato e trascorso gli studi, con
cui ho scambiato pensieri, idee e risate all’interno del dipartimento. In diversi mo-
di hanno contribuito al mio percorso formativo, aiutandomi a credere in me stesso,
suscitando in me nuovi interessi e suggerendomi, direttamente o indirettamente,
il modo per coltivarli.
102
Un ringraziamento particolare va a Salvatore Marella, guida invisibile rimasta
al mio fianco per tutta la durata di questo cammino.
Infine voglio ringraziare il DAP senza il quale oggi non apprezzerei la vera bellez-
za della vita con la consapevolezza che aver attraversato gli ultimi sette mesi mi
fa credere ancora di piu che “IMPOSSIBLE IS NOTHING”.
Maggio 2010
Davide
103