Introduzione - Gruppo di Ingegneria Informatica -SUN

Introduzione
Lo studio dei sistemi Grid è diventato negli ultimi anni uno dei punti cardine
nell'ambito dell'Ingegneria Informatica. Molti sono i vantaggi connessi all'utilizzo
di questa tecnologia, sia in ambito accademico che commerciale, tanto che
vengono stanziati ogni anno numerosi fondi, da diversi enti, per portarne avanti
l'evoluzione. Come ogni tecnologia di successo, anche il Grid offre enormi
potenzialità ed il suo sviluppo è in questo momento nella fase più importante, il
passaggio da un ambito di ricerca ad un contesto commerciale, con tutte le
difficoltà che questo comporta. Diventa fondamentale, viste le responsabilità
che il nuovo contesto richiede, avere a disposizione ambienti di sviluppo e test
delle tecnologie Grid sempre più efficienti ed affidabili al fine di poterne
analizzare e simulare ogni possibile comportamento.
Questo lavoro ha diversi obiettivi. Partendo da uno studio delle problematiche
connesse ai sistemi Grid si arriva a prendere in considerazione l'insieme di
tecnologie che attualmente costituisce lo stato dell'arte nell'implementazione di
tali sistemi. Vengono studiati i limiti dei sistemi Grid e le tecnologie che
consentono di superarli. Viene posta particolare enfasi alla collaudata
tecnologia degli agenti mobili.
Successivamente si procede con la progettazione e configurazione di un
ambiente in cui far funzionare un sistema Grid basandosi sulle conoscenze
acquisite. L'attenzione viene posta allo sviluppo di un'infrastruttura che possa
offrire una serie di funzionalità basilari per consentire la progettazione ed il
testing di applicazioni più complesse.
Infine, viene progettata un'interfaccia grafica per la gestione, da remoto, di
questo tipo di infrastruttura.
1
Capitolo 1
Il Grid Computing
1.1 Introduzione
Il termine “Grid”, che usualmente viene tradotto letteralmente come “Griglia”, è
stato per la prima volta utilizzato nel 1998 da Ian Foster e Carl Kesselman nella
loro pubblicazione “The Grid: Blueprint for a New Computing Infrastructure”.
Prima di allora è stato spesso usato, per denotare il concetto che a breve
descriveremo, il termine “Metacomputing”.
Se il 1998 è l'anno in cui è stato formalizzato il “Grid Computing”, la sua storia
inizia nei primi anni '90, anni in cui si cominciava a lavorare a progetti che
avevano come obiettivo il collegamento di alcuni centri dotati di supercomputer
al fine di ottenere una potenza di calcolo più elevata per alcune specifiche
applicazioni.
Ricordiamo che all'inizio degli anni '90 l'informatica e la potenza di calcolo
avevano una connotazione ben diversa da quella odierna. Nelle case non
c'erano i computer e le più potenti workstation disponibili nei centri di calcolo
avevano una potenza computazionale di gran lunga più bassa di quella che
abbiamo oggi in un calcolatore domestico. Avendo a disposizione risorse di
calcolo nettamente inferiori a quelle che servivano per alcune applicazioni si è
iniziato, pertanto, a pensare ad un modo per “condividere” le risorse di calcolo
delle varie workstation al fine di avere un calcolatore più potente e,
2
naturalmente, geograficamente distribuito.
Nella pratica, nasceva il Grid.
1.2 Definizioni del Grid
Una rigorosa definizione di Grid e un attento studio degli aspetti teorici
arriveranno qualche anno più tardi in quanto, in un primo tempo, l'attenzione è
stata
posta
allo
studio
di
protocolli
di
comunicazione
adeguati
e
all'organizzazione delle risorse utilizzabili.
Ritornando a Foster e Kesselman, la seguente è la prima definizione pubblicata
di “Grid”:
“A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high­end computational capabilities.”
Successivamente a questa prima pubblicazione sono state date altre altre
definizioni per il Grid Computing, ne riportiamo alcune:
“A grid is a software framework providing layers of services to access and manage distributed hardware and software resources”1
“Widely distributed network of high­performance computers, stored data, instruments, and collaboration environments shared across institutional boundaries”2
Nel 2001 Foster e Kesselman produssero una nuova definizione:
1
2
CCA, http://www.extreme.indiana.edu/ccat/glossary.html.
IPG, http://www.ipg.nasa.gov/ipgflat/aboutipg/glossary.html.
3
“Coordinated resource sharing and problem solving in dynamic, multi­institutional virtual organizations”3
Quest' ultima definizione è attualmente la più comunemente utilizzata per
definire il Grid.
4
Foster, inoltre, ha prodotto nel 2002 una “checklist” che può essere utilizzata
per capire esattamente cosa può essere considerato un sistema Grid. Questa
lista prevede tre punti che riassumiamo di seguito:
“A Grid is a system that:
1) coordinates resources that are not subject to centralized control ...
2) ...using standard, open, general­purpose protocols and interfaces...
3) ...to deliver non­trivial qualities of service.”
Al punto uno possiamo notare che si parla di risorse coordinate, ma senza un
punto di controllo centralizzato. Se questo non è vero, non possiamo dire di
avere a che fare con un Grid System.
Al punto due si parla di standard aperti e protocolli ed interfacce generalpurpose e, quindi, non dedicati. Se questa condizione viene a mancare ci
troviamo probabilmente davanti ad un sistema proprietario o, comunque,
specifico per una determinata applicazione, non un sistema Grid.
Al punto tre capiamo che i componenti di cui è costituito un Grid System
vengono usati e combinati per creare servizi molto complessi i quali vanno ben
al di la di quello che si otterrebbe con una semplice “somma” dei singoli
componenti.
Dalle definizioni date, consegue che il termine Grid denota un'infrastruttura
3 Foster, I., Kesselman, C. and Tuecke, S., The Anatomy of the Grid: Enabling Scalable Virtual
Organizations, International Journal of Supercomputer Applications, 15(3), 2001.
4 Grid Checklist, http://www.gridtoday.com/02/0722/100136.html.
4
hardware e software nata con l'intento di supportare il calcolo scientifico,
coordinare un numero di risorse condivise e distribuite geograficamente e
consentire la condivisione delle risorse per il raggiungimento di un obiettivo
comune. Il tutto tenendo presenti i tre punti di cui sopra.
Va aggiunto, però, che se in origine il Grid è nato nell'ambito scientifico con lo
scopo di favorire il calcolo distribuito intensivo e l'accesso flessibile a una
grande mole di dati, negli ultimi tempi sta ricevendo particolari attenzioni anche
nel campo industriale, commerciale e finanziario.
Di seguito riportiamo la definizione che IBM dà del Grid System:
“a standards­based application/resource sharing architecture that makes it possible for heterogeneous systems and applications to share, compute and storage resources transparently”5
Tutto ciò porta ad affermare che il Grid riguarda la condivisione di risorse.
Dietro questo semplice concetto si celano, però, tutta una serie di
considerazioni che rendono il Grid Computing e il suo studio, qualcosa di
particolarmente complesso.
Nel parlare di condivisione di risorse ci si riferisce a risorse di calcolo, ma anche
a sistemi di data-storage, sensori, networks. Vengono, pertanto, coinvolti
concetti
come
“trust”,
cioè
autenticazioni,
autorizzazioni,
permessi
e
quant'altro; “policies”, ovvero le politiche che devono regolare tali permessi;
“negotiation” ed anche, concetto sempre presente e non di poco conto, se e
come devono essere effettuati pagamenti.
1.3 Principali caratteristiche del Grid
Possiamo formalizzare, quindi, le dieci caratteristiche essenziali che si suppone
5 IBM Grid Computing, http://www-1.ibm.com/grid/grid_literature.shtml.
5
un sistema Grid debba avere per essere considerato tale.
1. Larga scala: un sistema Grid deve essere in grado di coordinare
un numero di risorse che sono nell'ordine dei milioni.
2. Distribuzione geografica: le risorse coinvolte possono trovarsi
a migliaia di chilometri di distanza
3. Eterogeneità: sugli host del sistema Grid, sia le risorse
hardware che software possono essere diverse tra loro. Parliamo
di dati, file, componenti softaware, programmi, sensori, strumenti
scientifici, network, potenza di calcolo, capacità di memoria,
sistemi operativi e quant'altro.
4. Condivisione di risorse: le risorse nel Grid appartengono a
diverse organizzazioni che permettono ad altre organizzazioni (gli
utenti) di accedere ad esse.
5. Amministrazioni multiple: ogni organizzazione può stabilire
diverse politiche di amministrazione e sicurezza riguardanti
l'accesso alle risorse da essa possedute. Questo porta ad un
aumento di complessità delle applicazioni Grid perché bisogna
gestire i conflitti tra le differenti politiche.
6. Coordinamento di risorse: le varie risorse devono essere
coordinate per fornire capacità computazionali aggregate
7. Accesso trasparente: un sistema Grid dovrebbe essere visto
come un unico grande virtual computer
8. Accesso affidabile: un sistema Grid deve assicurare che
l'offerta dei servizi segua sempre dei requisiti di qualità prestabiliti
(Quality of Service QoS). La necessità di servizi affidabili è
fondamentale perché gli utenti richiedono precise assicurazioni
riguardanti il fatto che riceveranno i dati previsti, persistenti e,
6
soprattutto, verranno offerte delle performance adeguate.
9. Accesso consistente: un sistema Grid deve essere progettato
con servizi, protocolli ed interfacce standard che nascondano
l'eterogeneità delle risorse favorendone la scalabilità. Senza
questi standard, lo sviluppo delle applicazioni e l'uso pervasivo
non sarebbero possibili.
10.Accesso pervasivo: il Grid deve garantire l'accesso a risorse
disponibili adattandosi ad un ambiente dinamico in cui i fallimenti
sono un fatto abituale. Questo non vuol dire che le risorse
debbano essere ovunque e sempre disponibili a chiunque le
richieda ma che il Grid deve “confezionare” il miglior servizio
possibile a partire dalle risorse disponibili.
1.4 Virtual Organization
E' necessario ora presentare un nuovo elemento che riveste importanza
cruciale nei Grid Systems. Trattasi della Virtual Organization o, abbreviando,
VO.
Una VO è un insieme di entità, intese come enti, organizzazioni oppure individui
singoli, che condividono le proprie risorse (in un contesto controllato) in modo
tale che i membri di una Virtual Organization possono collaborare tra loro al fine
di conseguire gli stessi obiettivi.
Non ci sono limiti sulle dimensioni di una VO, esse possono essere piccole o
grandi, statiche o dinamiche.
Facendo alcuni esempi di sistemi Grid, sarà facile identificare le VOs e
7
identificare il loro ruolo:
•
Un consorzio industriale formato da aziende ed enti di ricerca si
occupa dello studio della fattibilità di progettazione di aerei
supersonici di nuova generazione, facendo uso di simulazioni
multidisciplinari molto accurate (basate su studi di fluidodinamica,
fisica,
ecc…),
tramite
cui
viene
analizzato
ogni
aspetto
dell’aeroplano. Il programma di simulazione è composto da vari
moduli software, ogni membro del consorzio sviluppa un modulo
utilizzando le proprie conoscenze e competenze, inoltre il
software di simulazione è eseguito direttamente sui propri
calcolatori. In questo scenario ogni componente del progetto deve
avere la capacità sottomettere una simulazione presso le
macchine che contengono il modulo software richiesto, mentre i
dati generati dalle varie simulazioni vengono resi disponibili ad
ogni componente del progetto.
•
Centinaia di ricercatori appartenenti a centri di ricerca ed
università sparse per il mondo collaborano insieme su progetti
comuni, c’è la necessità di poter accedere ad una vasta quantità
di dati, composta da risultati e documentazione prodotti dai vari
gruppi di ricerca.
•
L'astrofisica è una scienza che studia i fenomeni dell'universo,
come la formazione delle stelle, la fisica solare, fenomeni che
nascono dall'insieme di eventi, come la formazione e l'interazione
tra galassie. Ognuno di questi processi risulta complesso e
richiede la conoscenza di diverse materie scientifiche dalla fisica
8
nucleare all'idrodinamica, di conseguenza gli algoritmi sviluppati
per lo studio di questi processi sono complessi e i relativi problemi
computazionali sono immensi. La maggior parte di questi problemi
necessitano di un codice parallelizzato che venga eseguito su
calcolatori estremamente potenti. Un altro problema è dovuto alla
gestione dell'enorme quantità di dati prodotti dalle analisi.
Questi esempi differiscono tra di loro in vari aspetti: per il numero di persone o
enti coinvolti, per il tipo di attività svolte e per l’estensione geografica delle
interazioni. In ogni caso esaminato si può notare che c’è l’esigenza di
condividere delle risorse tra le entità coinvolte, risorse che possono essere dati
(il risultato di un esperimento, dati che servono come parametri per una serie di
test, ecc…), oppure per risorse si può intendere l’accesso e l’utilizzo di software
eseguito su macchine remote (l’esecuzione di un esperimento su di un
simulatore di un centro di ricerca) così come la possibilità di eseguire un
insieme di jobs su di un sistema distribuito di calcolatori.
E' chiaro quindi il ruolo delle VO. Il consorzio industriale che vediamo nel primo
scenario è una VO. Un componente della VO, ad esempio un centro di ricerca
specializzato nella realizzazione di modelli fisici di aeroplani, può richiedere
l’uso del simulatore di un secondo componente del consorzio specializzato
nella progettazione di strutture aeronautiche. Un centro di ricerca universitario è
un altro esempio di VO.
9
1.5 Differenze tra un sistema Grid ed un sistema Distribuito
A questo punto è possibile delineare la differenza tra un sistema Grid ed un
sistema distribuito:
•
In un tipico sistema di calcolo distribuito abbiamo la presenza di
una serie di nodi di calcolo che implementano una macchina
virtuale. Un utente accede ad un account su un nodo e
automaticamente viene autorizzato all'accesso su tutti gli altri
nodi. Questo perché l'insieme l'insieme dei nodi costituisce
un'unica macchina virtuale ed è necessario mantenere la
“trasparenza”. Un utente, teoricamente, non dovrebbe accorgersi
di lavorare su un sistema distribuito anche se è a conoscenza
dell'architettura sulla quale lavora e delle politiche di sicurezza
adottate. La macchina virtuale, essendo costituita da un numero
di nodi che varia molto lentamente nel tempo, può essere
considerata statica. Uno strato software chiamato “middleware”,
che possiamo idealmente immaginare al di sopra dei vari sistemi
operativi funzionanti sui nodi, garantisce la trasparenza e
l'interoperabilità tra sistemi tipicamente eterogenei. Un sistema
distribuito, solitamente, è costituito da un numero di nodi limitato
(10-100) anche se questa non è una condizione forte.
•
Un sistema Grid, in virtù di quanto già affermato, è sempre da
considerarsi una sorta di sistema distribuito, però, alcune delle
sue caratteristiche lo differenziano dalla descrizione appena data.
Esso, infatti, è costituito da un insieme di risorse, che possono
10
essere rappresentate da nodi, geograficamente distribuite. Queste
risorse
possono
essere
“tipiche”
(processori,
memorie,
network...) e “atipiche” (componenti di I/O audio, manipolatori,
sensori...). Queste risorse sono ripartite su diversi domini
amministrativi. L'accesso alla macchina virtuale è consentito solo
se l'utente dispone di credenziali accettare dai proprietari delle
singole risorse. Non possiamo in alcun modo parlare di macchina
virtuale
statica
in
quanto
il
numero
delle
risorse
varia
continuamente nel tempo, abbiamo quindi un insieme virtuale
delle risorse dinamico. Infine, bisogna considerare che, oltre ad
essere variabile, il numero di nodi è nell'ordine delle migliaia,
talvolta anche delle centinaia di migliaia quindi immensamente più
grande di un sistema distribuito convenzionale.
1.6 Grid Architecture
L'architettura Grid è organizzata in livelli ed i componenti all'interno di ogni
livello condividono alcune caratteristiche comuni e possono sfruttare le
funzionalità ed i comportamenti forniti da ogni livello sottostante. Questo viene
detto “modello a clessidra”.
11
Figura 1.1 : Modello a Clessidra
Si parla di clessidra perché tra i diversi protocolli implementati ai livelli superiori
e quelli di più basso livello troviamo un restringimento che è costituito da un
piccolo gruppo di protocolli comuni
ed essenziali per la comunicazione. In
questo modello i livelli superiori fanno uso di quelli inferiori.
Nella figura vediamo uno schema che riassume i livelli ed il loro nome.
Figura 1.2 : L'architettura Grid
12
1.6.1 I livelli dell Architettura Grid
6
Passiamo adesso ad una descrizione rigorosa dei livelli dell'architettura Grid :
Il livello Fabric
Il livello Fabric fornisce l’accesso alle risorse poste in condivise nella griglia,
come risorse di calcolo, sistemi di memorizzazione, cataloghi, risorse di rete, e
così via. I componenti del livello Fabric implementano le operazioni locali fornite
da una specifica risorsa, tali operazioni sono fornite sotto forma di interfacce ai
livelli più alti dell’architettura grid, in questo modo una componente che lavora
ai livelli superiori può utilizzare le varie operazioni della risorsa (fornite dal
Fabric Layer) per implementare un servizio complesso della risorsa stessa e
fornirlo alle applicazioni grid.
Il livello Connectivity
Il Connectivity layer è uno dei livelli dell’architettura Grid che si collocano nel
“collo” del modello a clessidra, il suo compito è quello di rendere possibile lo
scambio dei dati tra le risorse in modo semplice e sicuro. Il livello Connectivity è
costituito dai protocolli di comunicazione e di autenticazione necessari per
l'infrastruttura Grid. La parte di comunicazione definisce le regole di accesso e
scambio di dati tra le varie risorse all'interno del livello Fabric, include protocolli
di trasporto, routing e naming, in genere si adottano i protocolli comunemente
utilizzati in internet, come l’IP e ICMP per la rete, TCP e UDP per il trasporto,
6 http://www.gridcomputing.it/livelli.html
13
DNS per il naming. La parte di autenticazione fornisce i meccanismi per la
verifica dell'identità degli utenti. Molti degli standard di sicurezza adoperati
vengono implementati utilizzando quelli già disponibili tra i protocolli internet.
Il livello Resource
Il livello Resource forma insieme al Connectivity layer il “collo” del modello a
clessidra dell'architettura Grid, si basa sui protocolli di comunicazione ed
autenticazione forniti dai livelli sottostanti e fornisce le interfacce tramite cui i
protocolli dei livelli superiori possono accedere alle funzionalità di una risorsa. Il
livello Resource definisce i protocolli, API e SDK necessari per fornire un
insieme di operazioni sulla singola risorsa, come secure negotiation,
inizializzazione, monitoraggio, controllo ed accounting, per fare ciò utilizza le
operazioni del Fabric layer per accedere e utilizzare localmente la risorsa e del
Connectivity layer per fornire l’accesso sicuro alla risorsa.
7
Nel livello Resource sono definiti anche i seguenti protocolli :
•
GRAM (Grid Resource Allocation Manager) permette l'allocazione,
la prenotazione, il monitoring ed il controllo di risorse remote.
•
GRIP (Grid Resource Information Protocol) basato su LDAP per
definire un modello informativo associato, GRIS (Grid Resource
Information Service).
•
GRRP
(Grid
Resource
Registration
Protocol)
permette
di
registrare le singole risorse all'interno di GIIS (Grid Index
7 http://www.gridcomputing.it/livelli.html
14
Information Server).
GridFTP è una versione estesa di FTP che prevede l'uso di
•
protocolli di sicurezza del livello connectivity,l'accesso parziale ai
file, la gestione del parallelismo dei trasferimenti ad alta velocità.
Il livello Collective
Il livello Collective fornisce protocolli e servizi che gestiscono le interazioni fra
collezioni di risorse:
•
Directory service sfruttano GRIP e GRRP per permettere all'utente
di effettuare ricerche di risorse per nome o per attributi
•
Co-allocation, scheduling and brokering service permettono di
individuare, allocare e utilizzare risorse distribuite fra più
istituzioni
•
Data
replication
service
consentono
di
massimizzare
le
performance di accesso ai dati rispetto a tempo di risposta,
affidabilità e costo mediante la duplicazione.
•
Monitoring and Diagnostic service in caso di failure, attacchi
esterni e sovraccarichi
•
Comunity
authorization,
accounting
and
payment
service
rispettando le policy della VO.
15
Mentre il Resource level fornisce le operazioni disponibili di una singola risorsa,
il Collective layer implementa una serie di operazioni (disponibili alle
applicazioni sotto forma di API o SDK) che operano su una collezione di risorse
condivise contemporaneamente, per ottenere ciò il Collective layer utilizza le
funzioni messe a disposizione dal Resource layer per accedere in ogni istante
alla specifica risorsa, quindi ogni servizio che il livello Collective offre è una
sequenza di operazioni fatte sulle singole risorse che appartengono alla
collezione. La figura mostra un esempio di come il Collective layer utilizza il
Resource
layer
per
accedere
alle
singole
risorse.
Figura 1.4 : Interazione tra il livello collective ed il resource
Il livello Application
L’ultimo livello dell’architettura Grid comprende le applicazioni utente che sono
eseguite all’interno delle macchine di una Virtual Organization. Questi
16
programmi utilizzano i servizi e le interfacce fornite dai livelli sottostanti per
portare a termine il proprio lavoro, ogni livello presenta dei protocolli ben definiti
che forniscono l’accesso ai servizi come la gestione delle risorse, l’accesso ai
dati, ecc… , oltre a fornire delle API con cui le applicazioni possono utilizzare i
loro servizi.
Figura 1.4 : interazione tra il livello applicativo e i livelli sottostanti.
1.7 Standard per il Grid
Per le tecnologie basate su Grid, è di vitale importanza che gli sviluppatori
progettino il loro software in maniera conforme a degli standard universalmente
accettati. Per la Grid-Community le più importanti organizzazioni per gli
8
standard sono il Global Grid Forum (GGF) , che l'organizzazione più importante
8 GGF, http://www.ggf.org.
17
9
per quanto riguarda gli standard Grid, e l' OASIS , un consorzio non a scopo di
lucro che guida lo sviluppo e l'adozione di standard “e-business” che sta
cominciando ad avere un'influenza molto grande nel campo degli standard Grid.
Altri enti che sono coivolti negli sforzi per la standardizzazione sono il
10
Distributed Management Tsk Force (DMTF) in cui si lavora inerentemente agli
standard di management; il Common Information Model (CIM)
11
ed il Web
12
Based Interprice Management (WBEM) . Va aggiunto, inoltre, che il noto World
Wide Web Consortium (W3C)
13
è attivo nella stesura di standard per i Web
Services, in particolare quelli relativi a XML.
Il GGF produce quattro tipi di documenti legati agli standard che sono definiti
come:
•
Informational : usati per informare la comunità di un' idea o un set
di idee utili come per esempio GFD.7 (A Grid Monitoring
Architecture), GFD.8 (A Simple Case Study of a Grid Performance
System) e GFD.11 (Grid Scheduling Dictionary of Terms and
Keywords). Attualmente esistono diciotto documenti di tipo
Informational.
•
Experimental : usati per informare la comunità di un utile
esperimento, banco di prova o implementazione di un idea o un
set di idee come per esempio GFD.5 (Advanced Reservation API),
GFD.21 (GridFTP Protocol Improvements) e GFD.24 (GSS-API
Extensions). Attualmente esistono solo questi tre documenti di tipo
Experimental.
9
10
11
12
13
OASIS, http://www.oasis-open.org
DMTF, http://www.dmtf.org
CIM, http://www.dmtf.org/standards/cim
WBEM, http://www.dmtf.org/standards/wbem
W3C, http://www.w3.org
18
•
Community Practice : servono per informare la comunità di
pratiche e processi comuni con l'obiettivo di influenzarla come per
esempio
GFD.1
(GGF
Document
Series),
GFD.3
(GGF
Management), GFD.16 (GGF Certificate Policy Model). Di questi
documenti attualmente ne esistono quattro.
•
Recommendation : sono usati per documentare una specifica
analogamente ai documenti per gli standard Internet. Come
esempio riportiamo GFD.15 (Open Grid Services Infrastructure),
GFD.20 (GridFTP: Protocol Extentions
to FTP for the Grid),
GFD.23 (Hierarchy of Network Performance Characteristics for
Grid Applications and Services). Di questa tipologia attualmente
esistono quattro documenti.
1.8 OGSA
Probabilmente il più importante standard che è emerso recentemente è l' Open
Grid Services Architecture (OGSA), sviluppato dal GGF. OGSA è una specifica
del GGF di tipo Informational che mira a definire un' architettura per le
applicazioni basate sul Grid comune, standard e aperta. L'obiettivo dell'OGSA è
standardizzare pressoché tutti i servizi che un' applicazione Grid potrebbe
usare, ad esempio servizi per la gestione di risorse, comunicazioni e sicurezza.
OGSA specifica un'architettura orientata ai servizi per il Grid (SOA) che realizza
il modello di un sistema computazionale come un set di pattern distribuiti
realizzati usando servizi Web e tecnologie basilari.
OGSA fu annunciato per la prima volta al GGF4 nel Febbraio del 2002. Nel
Marzo del 2004, al GGF10, fu dichiarato come l' architettura “ammiraglia” del
GGF. Il documento OGSA, rilasciato per la prima volta al GGF11 nel Giugno
19
2004, spiega l'attuale pensiero del team di lavoro dell' OGSA inerentemente alle
attuali potenzialità del Grid e viene rilasciato per favorire lo stimolo a nuove
discussioni.
Le istanziazioni di OGSA dipendono dalle specifiche emergenti. Attualmente il
documento principale non contiene sufficienti informazioni per sviluppare un'
implementazione di un sistema totalmente basato su quest'architettura. Un
attenta analisi di OGSA è stata intrapresa da Gannon
14
ed è attualmente in
corso.
Più avanti in questo lavoro riprenderemo più nel dettaglio l'architettura OGSA
per capire come si sviluppino i Grid Services.
Vi sono molti standard coinvolti nello sviluppo di un'architettura orientata ai
servizi Grid che formano i principali “building-blocks” che permettono alle
applicazioni di eseguire le richieste dei servizi. Questi standard e specifiche
includono:
•
Interazione Program-to-program (SOAP, WSDL and UDDI);
•
Data sharing (eXtensible Markup Language – XML);
•
Messaging (SOAP and WS-Addressing);
•
Messaging affidabile (WS-ReliableMessaging);
•
Gestione del carico di lavoro (WS-Management);
•
Gestione
di
transazioni
(WS-Coordination
and
WS-
AtomicTransaction);
•
Gestione di risorse
(WS-RF or Web Services Resource
Framework);
•
Sicurezza
(WS-Security, WS-SecureConversation, WS-Trust
14 Gannon, D., Chiu, K., Govindaraju, M. and Slominski, A., A Revised Analysis of the Open Grid
Service Infrastructure, Journal of Computing and Informatics, 21, 2002, 321–332,
http://www.extreme.indiana.edu/∼aslom/papers/ ogsa_analysis4.pdf.
20
and WS-Federation);
•
Manipolazione dei metadata (WSDL, UDDI and WS-Policy);
•
Sviluppo e integrazione delle architetture Web Services sul Grid
(vedi OGSA);
•
Flusso di business process ((Business Process Execution
Language for Web Services – BPEL4WS);
•
Eventi che attivano il flusso di processi (WS-Notification).
1.9 Grid Performance
Quando si parla di performance la prima cosa da chiedersi è cosa si vuol
intendere con questo termine. Si parla delle performance dell'infrastruttura Grid
o delle applicazioni Grid? Come vedremo ci si riferisce ad entrambe.
Unificare risorse distribuite può avere due obiettivi: fornire più risorse all'intero
sistema (obiettivo quantitativo) o fornire localmente risorse speciali che
normalmente non sarebbero disponibili (obiettivo qualitativo). Nel primo caso le
risorse possono essere unificate per guadagnare velocità ed eseguire
operazioni dimensionalmente molto grandi e problemi molto complessi in breve
tempo. Nel secondo caso, orientato alla qualità, le performance non sono legate
alla velocità ma, piuttosto, alla qualità delle risorse ed alla loro disponibilità.
Storicamente le performance sono legate alla velocità. Per quanto riguarda il
Grid, invece, la valutazione delle performance riguarda più l'assegnazione di
processi a risorse controllando che vengano rispettati requisiti come
l'affidabilità, la qualità, la capacità, la disponibilità e così via. Visto che l'essenza
del Grid è quella di costruire una virtual-machine a partire da risorse distribuite,
bisogna, inoltre, analizzare come le risorse in gioco vengono selezionate. In
altre parole le performance nel Grid sono legate all'adeguatezza, correttezza,
21
efficacia, economia e leggerezza delle risorse in gioco e la velocità è solamente
uno di questi aspetti. Lo scopo, quindi, è trovare le migliori risorse per una certa
esecuzione e controllare se una singola risorsa mantenga il suo miglior grado di
qualità durante la specifica esecuzione. Chiaramente il concetto di “miglior
grado di qualità” varia da applicazione ad applicazione. Recentemente sono
apparsi modelli di sistemi Grid in grado di distribuire le risorse in base a
particolari modelli economici in modo da trovare in maniera automatica un
equilibrio tra costo e qualità dei servizi offerti.
Lo studio delle performance nei sistemi distribuiti è stato abbondantemente
trattato nella letteratura e tutto ciò che è stato detto è riproponibile per i sistemi
Grid. In più, nei sistemi Grid, abbiamo ulteriori metri di valutazione come:
valutare le performance di una specifica risorsa al momento di assegnarla;
controllare a tempo di runtime se una specifica risorsa può sostenere una
performance richiesta / accettabile; controllare se un certo job può evolvere
regolarmente seguendo specifici checkpoint; controllare l'affidabilità e la
disponibilità di più risorse contemporaneamente.
1.9.1 Una sintesi sulle performance nei sistemi Grid
Mostriamo qui una sintesi di tutti gli aspetti nuovi che sono scaturiti da una
analisi del Grid Computing:
•
Osservazioni, paragoni e analisi sono significativamente più
complesse a causa del fatto che le misurazioni sono prese su
risorse diverse eterogenee e dinamiche. Devono inoltre essere
valutate le performance dell'attuale virtual-machine che, a causa
del
forte
dinamismo,
in
altri
momenti
potrebbe
essere
22
completamente diversa.
•
Ovviamente le performance sono sempre legate al connubio
applicazione-infrastruttura. Solitamente tuttavia, l'analisi ed il
monitoraggio delle risorse è tipicamente omesso visto che in un
sistema distribuito classico le principali caratteristiche sono ben
conosciute ed i loro cambiamenti sono spesso minimi e facilmente
tracciabili. Le applicazioni Grid girano su una virtual-machine sulla
quale non si può assumere nessuna informazione a priori.
•
Il fatto che il Grid fornisca una mappatura tra risorse astratte e
fisiche e che questa mappatura sia utilizzata su entità diverse e
dinamiche introduce nuovi possibili debolezze nelle performance
che in un sistema distribuito convenzionale non si avrebbero.
Questi difetti possono e devono essere definiti in modo da poterli
individuare in un'analisi delle performance.
•
Le normali metriche ed i parametri caratteristici non sono
normalmente utilizzabili per il Grid. Le attuali metriche per le
performance sono applicate, nel Grid, solo a livello fisico. Questo
accade perché quei parametri sono utilizzabili per specifiche
caratteristiche e al di fuori del loro ambito, in particolare a livello
virtuale, diventano inutili.
•
L'ambiente cambia dinamicamente da esecuzione ad esecuzione
e, abbastanza spesso, anche nell'ambito di una singola
esecuzione. Inoltre le esecuzioni stesse sono irripetibili. Pertanto
le analisi post-mortem oppure “off-line” diventano improponibili e
sono necessarie analisi “on line” durante l'esecuzione.
23
1.10 Web Services
Con il termine Web Services si fa riferimento ad una tecnologia per la
programmazione di sistemi distribuiti. In pratica parliamo di un modello che
permette la creazione di applicazioni client-server su un sistema distribuito. I
Web Services fanno uso delle remote procedure call (RPC) ma, a differenza di
altri paradigmi, utilizzano anche i protocolli standard di Internet come http o
XML. Essi sono totalmente indipendenti dalle tipologie di sistemi che girano
sulle varie macchine e dai linguaggi di programmazione. L'architettura dei Web
Services è definita e aggiornata continuamente dai membri del W3C. Nel
documento che ne descrive l'architettura, la W3C descrive un Web Service
come un componente software capace di fare interagire diversi computer
attraverso la rete, che possiede un'interfaccia descritta in un documento WSDL
e specifica anche i modi attraverso cui esso può interagire con altri sistemi.
L'interazione si basa sullo scambio di messaggi effettuato tramite il protocollo di
accesso SOAP e quello di trasporto HTTP.
L'architettura dei Web Services poggia su tre standard che sono:
•
Simple Object Access Protocol (SOAP) che risulta essere il
protocollo di dialogo tra l'entità che fornisce il servizio e quella che
la richiede. Definisce un insieme di convenzioni e regole tramite
cui il requestor invoca una procedura remota (RPC) di un servizio
e ne ottiene i risultati, ciò avviene tramite lo scambio di messaggi
SOAP
che
contengono
le
informazioni
necessarie
per
l’esecuzione del metodo invocato e tali informazioni sono scritte in
formato XML.
24
•
Web services Description Language (WSDL): descrive l’interfaccia
del Web Service, è un documento XML che descrive il Web
Service come un insieme di operazioni che possono essere
invocati tramite uno scambio di messaggi.
•
WS-Inspection: consiste in un linguaggio ed in un insieme di
convenzioni, il suo scopo è quello di trovare la descrizione dei
servizi pubblicati da un service provider. WSIL (WS-Inspection
Language) è un documento che contiene la descrizione dei servizi
forniti da un service provider oppure i link ad altre sorgenti che
contengono descrizioni di servizi, sono documenti pubblici in modo
che possano essere acceduti dai requestor.
25
Figura 1.5 : Un esempio di interazione client­server nei Web Services
1.11 Web Services e Grid
Un framework basato sull’uso dei Web Services si adatta ottimamente ad un
ambito Grid poiché porta con se vari vantaggi:
•
I Web Services offrono il supporto per una gestione dinamica della
ricerca e della composizione di servizi in ambienti eterogenei, che
vengono utilizzati nel grid computing. Ad esempio tramite il WSDL
e WSIL forniscono dei meccanismi per definire le interfacce dei
26
servizi ed effettuarne la registrazione ed il loro rinvenimento
indipendentemente da una loro implementazione.
•
Un framework basato sui Web Services può sfruttare tools utili per
la creazione di servizi, come un WSDL processor che effettuano il
binding per vari linguaggi di programmazione.
1.11.1 Dove si incontrano Grid e Web Services
Si potrebbe affermare che l'OGSA è il punto in cui si incontrano i Web Services
ed il Grid. Cerchiamo ora di entrare più nello specifico e capire come e perché è
nata questa importantissima architettura.
Con lo sviluppo e l'evoluzione del Grid diversi middlware ed applicazioni come
ad esempio portali, motori di ricerca, griglie di dati e sistemi di autenticazione
hanno iniziato a fornire servizi sull'infrastruttura Grid. La necessità di
integrazione ed interoperabilità tra il crescente numero di applicazioni ha portato
le tecnologie Grid verso la progettazione di un'architettura open-Grid che
offrisse un set estendibile di servizi che le Virtual Organization potessero
aggregare in vari modi. Per perseguire questo obiettivo è nato OGSA. E' in
questa architettura aperta che è stato definito ufficialmente il concetto di Grid
Service, basato sui principi e le tecnologie di entrambi il Grid Computing ed i
Web Services. Open indica l’utilizzo di protocolli e processi standard ed
interoperabili. I Web Services ed OGSA mirano a fornire interoperabilità tra
servizi
scarsamente
accoppiati
ed
indipendenti
nell'implementazione,
localizzazione e piattaforma. OGSA definisce meccanismi standard per creare,
nominare, e scoprire istanze persistenti o transienti di Grid Services. Fornisce
trasparenza di locazione e vincoli per le istanze dei servizi. Supporta
27
l'integrazione con strutture native sottostanti. Per fare questo, OGSA definisce
un set di estensioni WSDL e convenzioni sull'uso dei Web Services per il Grid
Computing. Gli sforzi di OGSA mirano a definire un modello di risorse comuni
che sia una rappresentazione astratta sia delle risorse reali, come processori,
dischi, processi e file system, sia delle risorse logiche. Fornisce alcune
operazioni comuni e supporta moltissimi modelli di risorse. In OGSA, tutti i
servizi aderiscono a specifiche interfacce e comportamenti dei Grid services
definite in termini di interfacce WSDL e a convenzioni e meccanismi per creare
e comporre sistemi distribuiti complessi. I vincoli sui servizi possono riferirsi ad
invocazioni affidabili, autenticazione, autorizzazione e delega. Per fare questo
OGSA definisce un Grid Service come un Web Service che fornisce un set di
interfacce ben definite e che segue specifiche convenzioni.
Le interfacce riguardano:
•Scoperta
(Discovery)
•Creazione
•Gestione
di servizi dinamici
del Lifetime
•Notifiche
•Management
Le convenzioni riguardano:
•
Naming
•
Possibilità di upgrade
Le convenzioni permettono agli utenti Grid di determinare quando un servizio
cambia
e
quando
questi
cambiamenti
sono
retrocompatibili
rispetto
all'interfaccia e alle semantiche, ma non necessariamente rispetto al protocollo
28
di rete. OGSA definisce anche meccanismi per il refreshing della conoscenza di
un client relativa ad un certo servizio, incluse le operazioni che esso supporta, e
d i protocolli di rete che il client può usare per comunicare con il servizio. I Grid
Services riguardano anche le autorizzazioni ed i protocolli di concorrenza.
Questo nucleo fondamentale di interfacce, che può essere usato per
implementare tutti i Grid Services, facilita la costruzione di servizi gerarchici che
possono essere trattati uniformamente attraverso strati di astrazione. A
differenza dei Web Services, che hanno servizi di discovery e di invocazione
persistenti, il modello OGSA supporta anche istanze di servizi transienti create
e distrutte dinamicamente. Per questo motivo, un Grid Service è potenzialmente
un Web Service transiente basato sui protocolli Grid ed espresso usando
WSDL. Un'istanza di servizio transiente potrebbe essere una query ad un datawarehouse, un'allocazione di risorse in un network, una sessione di discussioni
in un forum ecc.
La tabella sottostante mostra i servizi di base definiti da OGSA che hanno il
compito di gestire le istanze di un Grid Service, inoltre sono presenti anche
l’insieme di operazioni che devono essere implementate nell’interfaccia di ogni
servizio. Queste sono operazioni necessarie ai servizi base per realizzare i loro
compiti.
29
Figura 1.6 : Servizi di base OGSA
Infine segnaliamo che il GGF ha definito anche un secondo insieme di
specifiche raccolte nell’Open Grid Services Infrastructure (OGSI). Esse sono
composte sia da un insieme di documenti WSDL che descrivono le interfacce
dell’insieme dei servizi base definiti in OGSA, sia le specifiche e la descrizione
dettagliata delle operazioni presenti in ogni Grid Service di tipo OGSA, utili per
consentire la ricerca, la gestione del lifetime, la notificazione e la creazione di
istanze del servizio.
Vediamo una panoramica nell'immagine che segue:
30
Figura 1.7 : Il Grid Service
31
Capitolo 2
Lo stato dell'arte nel Grid Computing, il Globus Toolkit ed il paradigma ad Agenti Mobili
2.1 Introduzione
Avendo decritto la tecnologia del Grid passiamo ora a descrivere quanto, allo
stato attuale, questa tecnologia si sta evolvendo. Si parlerà quindi dello “stato
dell'arte per i sistemi Grid” e di quelle che sono, nel concreto, le piattaforme più
utilizzate per lo sviluppo di questi sistemi. Saranno descritti, inoltre, i principali
progetti attualmente attivi, in particolare nell' Unione Europea, riguardanti i
sistemi Grid. Tra questi troverà ampio spazio la descrizione del Globus Toolkit
della Globus Alliance che è la tecnologia utilizzata in questo lavoro.
Infine verrà fatta una panoramica sul paradigma di programmazione ad agenti
mobili e sugli standard che lo descrivono.
Questo paradigma si rivelerà fondamentale nello sviluppo di Grid Services
come si apprenderà nel Capitolo 3.
32
2.2 Principali progetti attualmente attivi
Saranno riportati adesso brevi estratti di commenti inerenti al Grid ed ai progetti
attivi, fatti dai responsabili dei progetti stessi. Questo per sottolineare
l'importanza che oggi il Grid riveste e per sottolineare il passaggio fondamentale
che le tecnologie Grid stanno vivendo, dal mondo accademico a quello
commerciale. Tale aspetto sarà approfondito più avanti in questo capitolo.
Sempre in questo paragrafo si accennerà ai principali progetti Grid attivi.
15
Viviane Reding , commissario europeo per la società dell'informazione e i
mezzi di comunicazione, non ha dubbi sul valore delle tecnologie Grid per
l'economia europea. "Le architetture Grid e quelle orientate ai servizi sono
tecnologie fondamentali per la produttività e la crescita dell'intera economia
europea", sostiene. "Esse accresceranno la flessibilità e la versatilità delle
attuali infrastrutture per le tecnologie dell'informazione e della comunicazione,
permettendo alle imprese di adattarsi e innovare più rapidamente. Ad esempio,
le tecnologie Grid consentono ai produttori in concorrenza che operano con
fornitori comuni di sviluppare ambienti di ingegneria pienamente integrati in
grado di tutelare gli interessi commerciali di tutte le parti e di migliorare la loro
competitività collettiva".
Attualmente la tecnologia Grid si trova ancora in una fase di transizione,
dall'utilizzo a fini accademici e di ricerca a più ampie applicazioni nel mondo
imprenditoriale. Il progetto BEinGRID (Business Experiments in GRID,
letteralmente "sperimentazioni aziendali nel campo delle tecnologie Grid"), cui è
stata conferita una sovvenzione di 15,7 milioni di euro, ha lo scopo di agevolare
il processo in corso e promuovere una più ampia acquisizione delle tecnologie
nel mondo del lavoro. A tal fine nell'ambito del progetto BEinGRID verranno
svolte 18 sperimentazioni sulle tecnologie Grid in diversi settori e i casi di studio
15 http://www.molecularlab.it/news/view.asp?n=4388
33
che ne emergeranno costituiranno, si auspica, una fonte di ispirazione per altre
aziende.
"I progetti di sperimentazione aziendale selezionati nei differenti settori chiave
rappresentano i migliori candidati a diventare delle storie di successo in questo
ambito e prevediamo che avranno un notevole impatto sul settore ICT
europeo",
spiega
Diego
Pavia,
coordinatore
del
progetto
BEinGRID.
British Telecom (BT) partecipa alla sperimentazione sfruttando le tecnologie
Grid nel campo dei giochi multiutente basati su Internet. "Siamo lieti di notare
un maggior sostegno da parte della Commissione europea per incentivare
l'adozione dei servizi web e delle tecnologie Grid in diversi settori aziendali",
afferma Matt Bross, Chief Technology Officer di BT. "
Un altro progetto che usufruisce di questi recenti finanziamenti è XtreemOS,
per cui sono stati stanziati 14,2 milioni di euro e che ha lo scopo di sviluppare,
implementare, valutare e distribuire un sistema operativo Grid open source
(chiamato XtreemOS) che fornirà supporto alle organizzazioni virtuali. Basato
sul popolare software open source Linux , XtreemOS verrebbe installato su
tutte le macchine facenti parte della rete. Svincolando gli utenti dal doversi
occupare dei complessi aspetti relativi alla gestione delle risorse di un ambiente
Grid, XtreemOS renderà molto più facile l'ingresso in un'organizzazione virtuale.
16
Il progetto «CancerGrid» , avviato di recente, riunirà partner provenienti dal
settore industriale ed accademico per la prima applicazione su ampia scala
della tecnologia Grid utilizzata nell rilevamento e nello sviluppo di nuovi agenti
antitumorali.
Il programma di ricerca multidisciplinare, che durerà tre anni e sarà finanziato
dall'UE, mira a combinare le nuove tecnologie con la biologia, al fine di
arricchire le librerie molecolari e aumentare le probabilità di scoprire potenziali
farmaci per la cura del cancro. «Questo progetto innovativo utilizza una
16 http://www.molecularlab.it/news/view.asp?n=5112
34
tecnologia di calcolo Grid per la progettazione automatizzata di librerie
chimiche, con l'obiettivo di scoprire potenziali cure per il cancro», ha affermato il
dottore di ricerca Michael Guaciaro, presidente e direttore generale dell'AMRI,
uno dei partner industriali del progetto.
Il progetto impiegherà risorse di Grid Computing per consentire ai ricercatori di
usufruire di una potente rete di computer interconnessi, in grado di elaborare
grandi quantità di dati e ridurre il tempo di calcolo. Il cancro colpisce milioni di
persone con un tasso di mortalità a livello mondiale pari al 13%, secondo
quanto riferito dall'Organizzazione mondiale della sanità.
Nel genoma umano vi è un sottoinsieme stimato di circa 3 000 geni che
codificano le proteine, ivi compresi i nuovi target del cancro, che potrebbero
essere
regolati
attraverso
molecole
simili
ai
farmaci
(«drug-like»).
I partner del progetto punteranno allo sviluppo di raccolte di composti chimici
specifici (librerie chimiche «mirate») che interagiscano con le proteine del
cancro.
«Il nostro obiettivo è sviluppare metodi per creare librerie chimiche contenenti
molecole attive contro i target emergenti del cancro», ha spiegato Gyorgy
Dorman, capo del dipartimento per le scienze e le tecnologie dell'AMRI.
«L'impiego di una tecnologia Grid dovrebbe aumentare in modo sostanziale sia
la probabilità di rilevare nuovi composti «guida» antitumorali, sia la
trasposizione delle conoscenze di base nella fase applicativa», ha aggiunto.
Si prevede che questo progetto produrrà e convaliderà anche una tecnologia
per la progettazione «in silico» di librerie e modelli chimici che consentano di
prevedere la specificità del bersaglio e la tossicità. Una volta sviluppate, queste
librerie saranno in teoria applicabili a qualsiasi progetto inteso a scoprire nuovi
farmaci.
Lo sviluppo delle tecnologie Grid rappresenta una delle principali priorità della
Commissione, che nel quadriennio 2002-2006 ha speso 130 milioni di euro
35
soltanto in attività di ricerca e altri 250 milioni per l'attuazione degli studi svolti
2.2.1 La tecnologia Grid in Italia
In una riunione convocata recentemente a Roma presso la sede della
Presidenza, l’INFN ha proposto che l’Italia si doti di un’organizzazione in grado
di coinvolgere le maggiori Istituzioni di ricerca attive nel campo, le Industrie e i
Servizi nel promuovere e sostenere lo sfruttamento puntuale di quanto finora
prodotto, fornendo al tempo stesso, continuità, solidità e fondamento alle future
evoluzioni di questa piattaforma e agli interventi a livello internazionale. Il
Consorzio per l’Open Middleware Enabling Grid Applications (c-OMEGA)
permetterà all’Italia di conservare il suo attuale livello di eccellenza
internazionale rispetto alle recentissime iniziative adottate dagli altri due Paesi
con cui si confronta in questo campo:
17
•
L’Open Middleware Initiave (OMII) in UK
•
La New Middleware Initiative (NMI) in US
18
I principali obiettivi del consorzio c-OMEGA sono:
•
Diventare un punto di riferimento nazionale per la
creazione, lo sviluppo, il supporto e la diffusione della
piattaforma tecnologica Grid in Italia e in Europa, lavorando
anche in stretto coordinamento con gli USA e i paesi
dell’Asia-Pacifico.
•
Sfruttare creativamente le componenti di middleware e gli
17http://www.omii.ac.uk/
18http://www.nsf­middleware.org/
36
ambienti Grid sviluppati da progetti di R&D indipendenti e in
generale i prodotti disponibili come software Open Source,
per costruire in Italia delle releases di servizi coerenti e
interoperanti
basati
sugli
Standard
emergenti
dagli
Organismi Internazionali per Grid e Service-oriented
architectures. (Per esempio specifiche OGSA del Global
Grid Forum, WSRF di OASIS, security di W3C ecc.),
compatibilmente con le modalità e le tipologie di licenze
open source.
•
Far coesistere la missione e gli obiettivi del mondo della
ricerca e accademico, quelli del mondo industriale, in
particolare del settore ICT e dei grandi servizi pubblici
nazionali (Ospedali, Scuole, Amministrazioni pubbliche).
•
Estendere
a
livello
di
tutto
il
paese,
con
attività
d’informazione, formazione e progetti mirati, lo sfruttamento
delle tecnologie Grid in modo da far nascere nuove
opportunità di crescita e di occupazione aumentando nello
stesso tempo la competitività globale del Paese.
Hanno finora dato la propria adesione e sono attivamente coinvolte
nell’iniziativa per la costituzione del consorzio OMEGA, oltre alle Industrie IT
Datamat SpA e Nice srl che dal 2000 collaborano con l’INFN nello sviluppo
delle Grid, i rappresentanti delle maggiori Istituzioni pubbliche di Ricerca: INFN,
CNR, INAF, ICTP, CHEMGRID, il Centro Europeo per Studi Teorici in Fisica
Nucleare e Aree Collegate (ECT), l’Istituto Trentino di Cultura (ITC-irst),
l’Università di Messina e altre Università italiane; vari consorzi IT: SPACI,
CRMPA Consorzio Pisa Ricerche; grandi Industrie come Elasis SpA, società del
37
gruppo FIAT, Engineering Ingegneria Informatica SpA e grandi banche nazionali
oltre a numerose PMI: euriX, Create-Net, Avanade–Italy srl, Synapsis srl e
l’Associazione Italiana per La Telemedicina e Informatica Medica (@TIM).
L’IBM sta fornendo un notevole contributo di idee ed esperienze già avviate
all’estero.
2.3 Lo stato dell'arte per il Grid Computing
Abbiamo dato nel primo capitolo una serie di definizioni relative al Grid, ognuna
delle quali ha caratterizzato un particolare aspetto di questo tipo di sistemi.
Attualmente la definizione che più di tutte rappresenta quello che, di fatto, il Grid
è oggi è la seguente:
“Grid is a type of parallel and distributed system that enables the sharing, selection, and aggregation of geographically distributed "autonomous" resources dynamically at runtime depending on their availability, capability, performance, cost, and users' quality­of­service requirements.”19
Rapportandosi a questa definizione notiamo che vari tipi di sistemi distribuiti
oggi si trovano ad avere un certo numero di caratteristiche simili al Grid. Ci sono
molti sistemi sviluppati e utilizzati per vari scopi ed esistono miriadi di nomi per
descriverli: compute grid, data/storage grid, campus grid, enterprise grid, e così
via.
2.3.1 Il Grid nel mondo commerciale
19 Grid Computing Info Centre: Frequently Asked Questions (FAQ),
http://www.gridcomputing.com/gridfaq.html
38
Potremmo vedere l'anno 2006 come cruciale per lo sviluppo di sistemi Grid. E'
in quel periodo che è cominciato il fondamentale passaggio del Grid dal mondo
accademico, o comunque dei centri di ricerca come ad esempio il CERN, al
mondo delle imprese. E' nel 2006 che il Grid ha cominciato ad essere visto
come il “sistema del futuro”. Dopo varie sperimentazioni in campo accademico,
si è capito che la strada da intraprendere non è più quella della ricerca di una
grande potenza su una singola macchina. Si è capito che non è più conveniente
investire nello sviluppo di potentissime workstation. E' tempo invece di investire
nella condivisione di risorse e nelle “macchine virtuali”. Ecco che, come
abbiamo visto in precedenza, sono stati promossi moltissimi progetti e stanziati
moltissimi fondi per lo sviluppo di questa giovane ma promettente tecnologia.
Analizziamo quindi come è avvenuto questo passaggio verso il mondo del
business.
Oggi vari tipi di sistemi distribuiti operano nel mondo delle imprese, ognuno con
lo scopo di risolvere differenti tipi di problemi. In un sistema tipico, vi sono molte
risorse che sono tipicamente sotto-utilizzate per lunghi periodi di tempo. Un
“Enterprice Grid” può essere definito come un sistema distribuito che cerca di
aggregare dinamicamente e coordinare diverse risorse all'interno della specifica
impresa e migliorare il loro utilizzo cosicché vi sia un grosso aumento di
produttività. I benefici che i sistemi Grid portano al mondo dell'impresa sono
sicuramente enormi risparmi nei costi.
39
Figura 2.1 : paragoni tra le caratteristiche di sistemi distribuiti commerciali e non commerciali
Vi sono varie applicazioni del Grid Computing nel business. Esistono molte
applicazioni commerciali di calcolo intensivo come la modellazione, la
simulazione, analisi degli investimenti e dei loro rischi, processazione di
documenti su vasta scala. Altre applicazioni riguardano strettamente le
operazioni su dati che coinvolgono aggregazione e management di centri di
data-storage distribuiti. Tutte queste tipologie di applicazione possono
abbondantemente beneficiare dei miglioramenti nelle performance e nelle
capacità di aggregazione forniti dalle tecnologie Grid.
40
Come dicevamo, però, la tecnologia Grid attualmente non può ancora
soddisfare appieno tutte le richieste che vengono dal mondo dell'impresa.
Questo perché, come già osservato più volte, il Grid è nato e si è finora evoluto
nel mondo accademico dove molte questioni relative al mondo commerciale
non erano di fondamentale importanza. E' importante notare che vi sono alcune
importanti distinzioni tra i tipi di Grid utilizzati nella comunità di ricerca e quelli
che possono essere utilizzati in un ambiente commerciale. Nella figura
precedente (fig. 2.1), infatti, vengono sottolineate le caratteristiche che
differenziano un Grid commerciale da un Grid orientato alla ricerca. Le stellette
indicano l'importanza/desiderabilità relativa agli attributi di ogni tipo di Grid. La
tecnologia Grid necessita un' evoluzione ed un'espansione per fornire soluzioni
che possano rispondere a questi problemi prima che essa possa diventare
effettivamente uno standard usato da tutti nel mondo commerciale.
2.3.2 Lo stato attuale dell' Enterprice Grid
Nel passaggio che il Grid sta vivendo dal mondo accademico al mondo
commerciale, si sta ponendo particolare enfasi alle architetture orientate ai
servizi (SOA). L'Enterprice Grid, attualmente, include un insieme di applicazioni
che fanno uso di centri dati e cluster per distribuire carichi di lavoro di altre
applicazioni come conto-clienti, analisi del rischio e dei costi negli investimenti,
sicurezza dei capitali nel settore finanziario e assicurativo, ricerca di soluzioni ai
“colli di bottiglia” nella progettazione e sviluppo di un prodotto, ecc. Mentre
molte di queste applicazioni stanno ancora funzionando su applicazioni batchoriented, si stanno contemporanemente iniziando ad usare i concetti di SOA e
Virtual Organization per esplorare le possibilità di far girare applicazioni
transazionali o interattive su Enterprice Grid dove la qualità dei servizi (QoS) è
41
stimata essere più o meno affidabile, specialmente quando determinata da
aggregazioni di livelli dei servizi (SLA).
Si è stimato che l'investimento nell' Enterprice Grid crescerà a dismisura nei
prossimi cinque anni, in contemporanea al fatto che sempre più compagnie
vorranno offrire servizi con un valore aggiunto di qualità. In realtà già moltissime
compagnie stanno offrendo un insieme di servizi come il “Grid and Grow ” di
20
IBM che include hardware grid, sistemi operativi, schedulers, servizi per fare in
modo che il business ottenga grandi vantaggi, traducibili in competitività sul
mercato, dovuti all'utilizzo di risorse più facilmente disponibili e risparmiando
tempo. La soluzione di Oracle per il Grid Computing
21
permette di utilizzare
server e storage modulari e compattare questi ultimi con il database Oracle.
Permette inoltre di automatizzare il task-management. Il “Grid Utility
22
Computing”
di SUN Microsystems è un servizio pay-per-use che permette
agli utenti una fornitura dinamica di potenza di calcolo, dipendente dai requisiti
dell'applicazione. Essi forniscono l'accesso ad un'infrastruttura standardizzata di
Grid Computing che permette di trasferire i flussi di lavoro computazionalmente
pesanti con rischio minimo e nessun investimento di capitale. Non è da
dimenticare, poi, che HP sta rilasciando prodotti di storage basati su Grid che
sono progettati secondo la loro architettura “StorageWorks”.
L'Enterprice Grid Alliance (EGA) è un consorzio aperto, non-profit, creato per
sviluppare soluzioni per l'Enterprice Grid ed accelerare così l'affermazione del
Grid nel mondo commerciale. E' costituito da oltre trenta membri che includono
utenti Grid, venditori e sviluppatori di prodotti che includono IBM, Oracle, Sun,
Intel, HP, DataSynapse, Univa e Dell. L'EGA mira ad incoraggiare ed accelerare
lo spostamento verso un ambiente Open Grid attraverso prodotti interoperabili.
Lavora sugli standard del Grid Computing studiando le specifiche esistenti e
20 IBM’s Grid home, http://www-1.ibm.com/grid/
21 Oracle Grid Solutions, http://www.oracle.com/technology/tech/grid/index.html
22 Grid Computing from Sun Microsystems, http://www.sun.com/servers/grid/
42
cerca di inrodurne di nuove laddove si ritiene necessario. Il software OpenSource è utilizzato tantissimo nello sviluppo degli Enterprice Grid.
Gran parte delle soluzioni Grid sono attualmente basate sul noto Globus
Toolkit
23
, sviluppato dalla Globus Alliance, di cui parleremo dettagliatamente in
seguito. Esso è costituito da un set di servizi software e librerie per il monitoring,
discovery e management di risorse che facilitano la progettazione di Grid
computazionali e di applicazioni basate su Grid con vincoli aziendali, istituzionali
e geografici. Globus offre un middleware Grid che principalmente gira su
piattaforme Unix. Un certo numero di progetti Grid open-source hanno
sviluppato una sorta di middlware a livello utente che lavora con il Globus
24
Toolkit. Uno degno di nota è il progetto Gridbus (Università di Melbourne) che
ha sviluppato il Grid Service Broker che supporta la creazione, lo scheduling e
lo sviluppo di applicazioni Grid computazionali su Enterprice Grid.
Un'altra iniziativa nell'ambito Grid ed open-source è l'Alchemi Enterprice
Grid-Computing Framework
25
che sfrutta la potenza di una rete di computer
su cui girano sistemi operativi Windows.
Per chiarire di più i concetti daremo adesso uno sguardo più attento ad una di
queste tecnologie, in particolare al progetto Alchemi
2.3.2.1 Alchemi
Alchemi è un framework open-source per l'Enterprice Grid Computing,
sviluppato dai ricercatori dei laboratori GRIDS nel dipartimento di Informatica e
Ingegneria del Software dell'Università di Melbourne in Australia.
Questo framework permette senza alcun costo di aggregare la potenza di
calcolo di macchine connesse in rete in un super-computer virtuale e di
23 The Globus Toolkit, http://www.globus.org
24 The Gridbus Project, http://www.gridbus.org
25 Alchemi, http://www.alchemi.net
43
sviluppare applicazioni Grid senza ulteriori investimenti e senza apprezzabili
differenze dal punto di vista degli utenti. E' stato progettato con lo scopo
primario di essere facile da usare senza sacrificare la potenza e la flessibilità. E'
stato progettato per il sistema operativo Windows poiché questa cosa è vista
come un fattore chiave nell'adozione, a livello commerciale, della tecnologia
Grid. Questo perché si stima che su oltre il 90% delle macchine del worldwide
girino sistemi Microsoft.
Le principali caratteristiche offerte dal framework Alchemi sono:
•
Virtualizzazione
di
risorse
di
calcolo
attraverso
la
LAN/Internet
•
Facilità di sviluppo e gestione
•
Modello di programmazione del “grid thread” orientato agli
oggetti per lo sviluppo di applicazioni Grid
•
Modello dei “grid-job” basato su file per avere applicazioni
Grid-Legacy
•
Interfacce a Web Services per l'interoperabilità con altri
middleware Grid.
Nella figura 2.2 possiamo vedere l'architettura di Alchemi. Un Grid Alchemi ha
tre tipi di componenti:
•
Il Manager
•
L'Esecutore
•
La User-Application
Il nodo Manager è un computer con installato il componente Alchemi Manager.
44
La sua funzione principale è di asservire alle richieste degli utenti per la
distribuzione dell'applicazione. Il Manager riceve una richiesta utente,
l'autentica, e distribuisce il carico di lavoro tra i vari Esecutori ad esso connessi.
Il nodo Esecutore è l'unico che effettua il calcolo. Alchemi usa una sicurezza
role-based per autenticare gli utenti ed autorizzare l'esecuzione.
Un semplice Grid si può creare installando gli Esecutori su ogni macchina che
deve essere parte del Grid e collegandole al componente Manager centrale.
L'installer per Windows rende l'operazione di creazione di un nodo Grid davvero
semplice.
Figura 2.2 : Un semplice Grid Alchemi
45
Gli utenti possono sviluppare, eseguire e monitorare le applicazioni Grid usando
le API .NET ed i tools che fanno parte dell'Alchemi SDK. Alchemi offre un
potente modello di programmazione di thread Grid che consente di sviluppare
applicazioni Grid in maniera molto semplice.
E' importante conoscere l'esistenza di questo framework in quanto esso è
largamente usato sia nella comunità accademica sia nel campo commerciale,
per un gran numero di applicazioni.
Alcune delle applicazioni industriali che fanno uso di Alchemi sono qui riportate:
•
Processing di documenti su larga scala (Tier Technologies,
USA)
•
Natural resource modelling (CSIRO, Australia)
•
Task di Excel asincroni che usano XLL (stochastix GmbH,
Germany)
•
Ricerca di pattern e di fattori di trascrizione nei geni dei
mammiferi (The Friedrich Miescher Institute (FMI) for
Biomedical Research, Switzerland)
•
Ricerca della locazione du un trasmettitore radio ad alta
frequenza usando la tecnologia SSL(Correlation Systems
Ltd. , Israel)
•
e molti altri
2.3.3 Il Globus Toolkit
A questo punto, parleremo della più importante e più utilizzata piattaforma per lo
sviluppo di Grid Services, il Globus Toolkit della Globus Alliance. Si cercherà di
46
entrare un po' più nel dettaglio in quanto proprio il Globus Toolkit è stato
utilizzato nello sviluppo di questo lavoro di tesi.
2.3.3.1 La storia
La storia di Globus comincia nel 1994, quando Rick Stevens, direttore del
“mathematics and computer science division at Argonne National Laboratory” e
Tom DeFanti, direttore di “the Electronic Visualization Laboratory” all’Università
di Illinois a Chicago, proposero di stabilire un collegamento temporaneo tra le
reti di undici centri di ricerca per creare una sorta di “griglia nazionale”. Il
progetto fu chiamato I-Way e fu affidato ad Ian Foster, il quale insieme ad un
piccolo team di ricercatori riuscì a far eseguire diverse applicazioni su computer
posti nei differenti paesi che presero parte al progetto. L’esperimento ebbe la
durata di due settimane e fu presentato al “Supercomputing '95 conference”. Il
suo successo spinse il team a continuare il lavoro, fu creato il progetto Globus
con lo scopo di realizzare un software open source per l’interconnessione di
risorse di calcolo e nel 1997 fu realizzata la prima versione di Globus Toolkit,
che collegava 80 siti di ricerca e di calcolo sparsi per il mondo.
All’origine il team di sviluppo di Globus era formato da un gruppo di poche
persone, con il passare degli anni si sono aggiunti nuovi individui e nuove
collaborazioni, fino a formare una grande comunità internazionale di sviluppatori
che nel 2005 fu denominata “Globus Alliance”. Attualmente Globus Alliance
comprende la partecipazione di molte università e centri di ricerca come la
University of Chicago, la University of Edimburgo, il Royal Institute of
Technology in Svezia, il National Center for Supercomputing Applications, Univa
Corporation. Il progetto è sponsorizzato da molti enti, sia agenzie federali come
DOE, NSF, DARPA, and NASA, sia partner commerciali come IBM e Microsoft.
47
Attualmente è disponibile la quarta versione di Globus Toolkit.
2.3.3.2 Sintesi di Globus
Globus è una comunità di utenti e sviluppatori che collaborano sull'uso e sullo
sviluppo di software open-source e sulla relativa documentazione, per il calcolo
distribuito.
Il Globus Toolkit è un insieme di librerie e programmi che risolvono i problemi
comuni che si incontrano durante lo sviluppo di servizi ed applicazioni su
sistemi distribuiti.
Tutta l'infrastruttura che questa comunità sviluppa e utilizza si trova all'indirizzo
Web www.globus.org. Il software fornisce un certo numero di componenti e
capacità, incluse le seguenti:
•
Un set di implementazioni di servizi che si focalizzano sulla
gestione dell'infrastruttura
•
Tool per progettare nuovi Web Services in Java, C e
Python.
•
Una potente infrastruttura di sicurezza basata su standard
•
API per i client e comandi per accedere a tutti questi servizi
e capacità
•
Documentazione dettagliata di questi diversi componenti,
delle loro interfacce e come essi possono essere usati per
progettare applicazioni
Il Globus Toolkit permette di condividere risorse di calcolo, dati, database ed
applicazioni
tra
istituzioni,
in
modo
sicuro,
preservando
l’autonomia
organizzativa, gestionale ed amministrativa di ogni singola organizzazione.
48
L’architettura del GT è modulare e indirizza alcune delle problematiche presenti
in un ambiente di grid computing. Tale architettura può essere rappresentata
come una struttura a tre pilastri con un basamento comune, come illustrato
nella figura successiva. Ogni singolo pilastro rappresenta un servizio che abilita
l’utente a utilizzare la Grid o l’amministratore a gestirla.
I servizi sono:
•
Gestione delle risorse
•
Gestione del sistema informativo
•
Gestione dei dati
Figura 2.3 : Rappresentazione schematica del Globus Toolkit
2.3.3.3 Perché il Globus Toolkit
49
Il software Globus è progettato per creare applicazioni che gestiscano risorse
distribuite come computer, storage, dati, servizi, networks o sensori.
Inizialmente il lavoro svolto su Globus era spinto da motivazioni di ricerca
scientifica. Più di recente le applicazioni commerciali sono diventate
significativamente più importanti. Va detto che il settore scientifico e quello
commerciale hanno talvolta anche problematiche simili.
La gestione di risorse è tipicamente motivata dalla necessità di accedere a
servizi, o alle stesse risorse, che non possono essere facilmente replicabili
localmente. Ad esempio:
•
Uno scienziato vuole accedere a dati localizzati in database
differenti in una collaborazione scientifica
•
Un affarista (o un membro della comunità fisica) vuole allocare
risorse di calcolo, storage e di rete dinamicamente per supportare
un flusso e-commerce tempo variante (o un analisi di dati fisici)
•
Un ingegnere necessita di progettare e fare esperimenti su
dispositivi
remoti,
collegando
e
confrontando
simulazioni
numeriche e fisiche
•
Un esperimento astronomico necessita di replicare un terabyte di
dati al giorno ai siti partner sparsi per il mondo
La comunità che ha sviluppato Globus si è basata sul fatto che, sebbene molte
applicazioni abbiano requisiti unici, un piccolo set di funzioni ricorre molto
spesso: ad esempio spesso c'è la necessità di scoprire quali sono le risorse
disponibili, configurare una risorsa di calcolo per far girare un'applicazione,
spostare dati in maniera affidabile da un sito ad un altro, monitorare i
componenti di sistema, controllare chi può fare cosa e gestire le credenziali
50
degli utenti. Implementazioni di buona qualità di queste funzionalità possono
ridurre considerevolmente i costi di sviluppo. Inoltre se queste funzioni vengono
largamente adottate o, meglio ancora, fanno riferimento a degli standard, ne
guadagna tantissimo l'interoperabilità. Il software Globus raggiunge questi
obiettivi utilizzando un modello open-source in modo da incoraggiare sia i
contributi da parte della comunità sia l'adozione del software stesso.
Il Globus Toolkit 4 (GT4) che è la versione attualmente in uso, fa uso massivo
dei Web Services per definire le interfacce e strutturare i componenti. I Web
services forniscono meccanismi basati su XML flessibili, estensibili e
largamente adottati. In più, i suoi protocolli sono ben documentati e facilmente
comprensibili. Tutte queste caratteristiche facilitano lo sviluppo di architetture
orientate ai servizi, sistemi ed applicazioni strutturate come i servizi di
comunicazione, nei quali sono descritte le interfacce dei servizi, le operazioni
invocate ecc. Mentre le applicazioni di interesse per gli utenti finali sono
tipicamente concentrate su specifiche operazioni sui domini, come gestire un
portafoglio elettronico o analizzare una sequenza genetica, il lavoro di calcolo
richiede la manipolazione e la gestione di infrastrutture: device fisici come
computer, sistemi di storage e strumentazioni. Per questo motivo GT4 fornisce
un insieme di servizi per l'infrastruttura Grid che implementano interfacce per
gestire risorse di calcolo, di storage e di altri tipi. In molte applicazioni che
utilizzano Globus (ad esempio TeraGrid, Open Scienze Grid, LHC Computing
Grid, China Grid, Apgrid), questi servizi sono sviluppati per supportare un certo
insieme di applicazioni per le diverse community, ognuna delle quali esegue il
proprio specifico codice che si trova all'interno di quei servizi.
51
Figura 2.4 : Schema dell'architettura Globus, vengono mostrati molti componenti. I box bianchi rappresentano il codice utente.
2.3.3.4 L'architettura di Globus
La figura 2.4 mostra vari aspetti dell'architettura del Toolkit GT4. Notiamo per
prima cosa, i seguenti tre insiemi di componenti:
•
Un insieme di implementazioni di servizi (la metà in basso della
figura) che implementa utili servizi dell'infrastruttura. Questi
servizi riguardano la gestione dell'esecuzione (GRAM), l'accesso
26
27
ai dati ed il loro spostamento (GridFTP , RFT, OGSA-DAI ),
26 Allcock, W., Chervenak, A., Foster, I., Kesselman, C. and Livny, M., Data Grid Tools: Enabling
Science on Big Distributed Data. SciDAC Conference, 2005
27 Atkinson, M., Chervenak, A., Kunszt, P., Narang, I., Paton, N., Pearson, D., Shoshani, A. and Watson,
P. Data Access, Integration, and Management. The Grid: Blueprint for a New Computing
Infrastructure, Morgan Kaufmann, 2004
52
28
gestione delle repliche (RLS , DRS), monitoring e discovery
29
(Index Trigger, WebMDS), gestione delle credenziali (MyProxy ,
Delegation, SimpleCA), e gestione delle strumentazioni (GTCP).
Per la maggior parte si tratta di servizi Web java ma alcuni (nella
parte in basso a destra nella figura) sono implementati in altri
linguaggi ed usano altri protocolli.
•
Tre container possono essere usati per servizi sviluppati dagli
utenti che girano sugli host, scritti in java, Python e C
rispettivamente. Questi container forniscono implementazioni di
sicurezza, gestione, discovery, gestione dello stato, ed altri
meccanismi richiesti frequentemente quando si sviluppano
servizi. Essi estendono ambienti di hosting open-source che
supportano un insieme di utili specifiche per Web Services, che
includono il WS Resource Framework (WSRF), WS-Notification,
e WS-Security.
•
Un insieme di librerie consentono programmi client in java, C e
Python per invocare operazioni su entrambi i servizi di GT4 e
quelli creati dagli utenti. In molti casi, interfacce multiple
forniscono diversi livelli di controllo: ad esempio, nel caso di
GridFTP, non c'è solo un semplice client a linea di comando ma
anche un certo numero di librerie data-channel e la libreria XIO
che permette l'integrazione di protocolli di trasporto alternativi.
28 Chervenak, A., Deelman, E., Foster, I., Guy, L., Hoschek, W., Iamnitchi, A., Kesselman, C., Kunst, P.,
Ripenu, M., Schwartzkopf, B., Stockinger, H., Stockinger, K. and Tierney, B., Giggle: A Framework
for Constructing Scalable Replica Location Services. SC'02: High Performance Networking and
Computing, 2002
29 Novotny, J., Tuecke, S. and Welch, V., An Online Credential Repository for the Grid: MyProxy. 10th
IEEE International Symposium on High Performance Distributed Computing, San Francisco, 2001,
IEEE Computer Society Press
53
E' importante notare che GT4 è molto più che un semplice insieme di servizi
utili. L'uso di meccanismi di astrazione uniformi significa che i client possono
interagire con servizi differenti in vari modi, che facilitano la progettazione e la
costruzione di sistemi complessi ed interoperabili ed incoraggiano il riuso di
codice. Quest'uniformità si manifesta a livelli differenti:
1. L'infrastruttura WS è conforme al messaging SOAP tra i Web
Service ed i loro client.
2. Una infrastruttura comune di sicurezza e messaging abilita
l'ineroperabilità tra differenti applicazioni e servizi.
3. Un potente ed estensibile framework di autorizzazione supporta un
insieme di diversi meccanismi per lo scopo.
4. Il fatto che tutti i container e la maggior parte dei servizi
implementino meccanismi comuni per la rappresentazione dello
stato e dell' accesso facilita il monitoraggio ed il discovery.
2.3.3.5 Descrizione dettagliata del GT4
Vedremo adesso più nel dettaglio il funzionamento del software Globus e come
sia possibile effettuare le operazioni più importanti che esso consente.
La figura fornisce un'altra prospettiva della struttura del GT4, mostrando i
componenti più importanti usati per un'esecuzione base (sulla destra) e poi (da
sinistra a destra) i servizi di sicurezza, gestione dell'esecuzione, gestione dei
dati ed informazione. Introdurremo questi componenti mostrando come essi
possono essere usati.
54
A) La gestione dell'esecuzione
Immaginiamo di voler mandare in esecuzione un task su un computer, o
pubblicare e gestire un servizio che fornisce alcune capacità ad una community.
In entrambi i casi, necessitiamo di acquisire l'accesso ad un computer,
configurarlo per le nostre necessità, lanciare un eseguibile, iniziare l'esecuzione
di un programma e monitorare e gestire la computazione risultante.
Il servizio Grid resource Allocation and Management (GRAM) di GT4 persegue
questi obiettivi, fornendo un interfaccia Web Services per avviare, monitorare e
gestire l'esecuzione di computazioni arbitrarie su computer remoti. La sua
interfaccia permette al client di esprimere queste cose come il tipo e la quantità
di risorse desiderate, i dati che devono essere inviati o presi dal luogo in cui
avviene l'esecuzione, l'eseguibile ed i suoi argomenti, le credenziali che devono
essere usate ed i requisiti di persistenza dei job. Altre operazioni abilitano il
client a monitorare lo stato sia delle risorse di calcolo sia dei task individuali, al
fine di visualizzare notifiche riguardanti il loro stato e controllare l'evoluzione dei
task.
55
Figura 2.5 : Componenti primari del GT4
Un servizio GRAM può essere utilizzato per differenti scopi. Vediamo qualche
esempio:
•
Il GriPhyN Virtual Data System (VDS), Ninf-G, e Nimrod-G,
sono tool che usano le interfacce GRAM per spedire
(potenzialmente un gran numero) task ai cluster di calcolo.
Ad esempio il GADU service
30
di Rodriguez normalmente
usa VDS per spedire diversi milioni di task.
•
Varie applicazioni utilizzano GRAM come un servizio di
pubblicazione e management usando una richiesta GRAM
30 Rodriguez, A., Sulakhe, D., Marland, E., Nefedova, V., Maltsev, N., Wilde, M. and Foster, I., A GridEnabled Service for High-Throughput Genome Analysis. Workshop on Case Studies on Grid
Applications, Berlin, Germany, 2004
56
prima per iniziare un servizio e poi per controllare il suo
utilizzo delle risorse ed eventualmente riavviare nel caso si
verifichi un evento di fallimento della risorsa o del servizio.
•
L' implementazione MPICH-G2
31
della Message Passing
Interface usa GRAM per co-schedulare sub-task tra diversi
computer. Dong ed altri
condurre
una
32
hanno usato MPICH-52 per
simulazione
completa
dell'apparato
circolatorio umano.
I seguenti componenti per la gestione dell'esecuzione sono anch'essi forniti in
GT4 come “tech-previews”, questo vuol dire che, allo stato attuale, essi non
sono ancora stati testati a fondo rispetto agli altri componenti e più facilmente
potranno cambiare in futuro:
•
Il Workspace Management Service (WMS) fornisce un'allocazione
dinamica degli account UNIX (una variante di questo servizio che
fornisce un'allocazione dinamica di virtual machines è attualmente
in fase prototipale).
•
Il servizio Grid TeleControl Protocol (GTCP) serve a gestire la
strumentazione; è stato utilizzato per applicazioni ingegneristiche
per lo studio di terremoti.
B) L'accesso ai dati ed il loro spostamento
31 Karonis, N., Toonen, B. and Foster, I. MPICH-G2: A Grid-Enabled Implementation of the Message
Passing Interface. Journal of Parallel and Distributed Computing, 63 (5). 551-563. 2003
32 Dong, S., G, K. and Karonis, N. Cross-site computations on the TeraGrid. Computing in Science &
Engineering, 7 (5). 14-23. 2005
57
Le applicazioni Globus spesso necessitano di gestire, fornire accesso ed
integrare grandissime quantità di dati su uno o più siti computazionali. Questo
problema di gestione dei dati è ampio e complesso, e nessuna singola
sottoparte di un software potrebbe risolverlo efficacemente. Tuttavia diversi
componenti di GT4 implementano utili meccanismi che possono essere usati
singolarmente o in maniera congiunta ad altri componenti per sviluppare
soluzioni interessanti (un articolo recente parla di questi tool e dei successi che
33
hanno ottenuto in varie circostanze ):
1. L'implementazione Globus della specifica GridFTP fornisce librerie
e tool per uno spostamento dati memoria-memoria o disco-disco
affidabile, sicuro e con alte performance. Essa realizza reti endto-end su aree ampie con velocità di circa 27 Gbit/s e possono
interoperare con i client e server FTP convenzionali. Il GridFTP
fornisce un sottostrato sul quale lavorano una grande varietà di
tool e applicazioni ad un livello più alto.
2. Il servizio Reliable File Transfer (RFT) garantisce il management
affidabile di trasferimenti GridFTP multipli. E' stato usato, per
esempio, per orchestrare il trasferimento di un milione di file da
un archivio astronomico ad un altro.
3. Il Replica Location Service è un sistema scalabile per mantenere e
fornire l'accesso ad informazioni relative alla localizzazione di file
replicati e di insiemi di dati. L'esperimento LIGO
34
lo usa per
gestire più di un milione di repliche.
4. Il Data Replication Service (DRS, anch'esso una tech-prview)
combina RLS e GridFTP per fornire la gestione di repliche dei
33 Allcock, W., Chervenak, A., Foster, I., Kesselman, C. and Livny, M., Data Grid Tools: Enabling
Science on Big Distributed Data. SciDAC Conference, 2005
34 www.ligo.caltech.edu
58
dati.
5. I tool Globus Data Access and Integration (OGSA-DAI) sviluppati
dal programma UK eScience forniscono l'accesso a dati
relazionali ed XML.
C) Monitoring e Discovery delle risorse
Il Monitoring ed il Discovery sono due funzioni vitali nei sistemi distribuiti,
particolarmente quando il sistema si espande su locazioni molto ampie. In
questo contesto, non può esserci una persona che abbia una conoscenza
dettagliata di tutti i componenti. Il monitoraggio ci permette di trovare e
diagnosticare i vari problemi che possono presentarsi in vari contesti, mentre il
discovery ci permette di identificare risorse e servizi che abbiano le proprietà
desiderate. Entrambi i meccanismi richiedono la capacità di collegare
informazioni da sorgenti multiple e distribuite. Proprio per l'importanza che
rivestono, quindi, i meccanismi di Monitoring e Discovery sono sviluppati in GT4
ad un livello fondamentale (come vediamo in figura).
•
GT4 fornisce meccanismi standardizzati per associare delle
resource-properties basate su XML ad entità di rete. Questi
meccanismi, fondamentalmente implementazioni delle specifiche
di WSRF e WS-Notification, sono presenti in ogni servizio e
container di GT4 e possono anche essere incorporati facilmente in
ogni servizio sviluppato dall'utente. I servizi possono essere
configurati per registrare il proprio container o container con altri
container per abilitare la creazione di organizzazioni gerarchiche.
•
GT4 fornisce due servizi di aggregazione che contengono
l'informazione recente sullo stato che viene recuperata dalle
59
sorgenti di informazione. Poiché non tutte le sorgenti di
informazione supportano le interfacce di WSRF o WS-Notification,
questi servizi di aggregazione possono essere configurati per
prelevare informazioni da qualunque tipo di sorgente, sia basate
su XML che no. I due Aggregator implementano un registro (index)
ed un filtro dati event-driven (il Trigger) rispettivamente.
•
GT4 fornisce un range di interfacce basate su browser, tool a linea
di comando ed interfacce Web Services che permettono agli utenti
di richiedere e accedere alle informazioni. In particolare, il servizio
WebMDS può essere configurato via XSLT per creare viste
specializzate dei dati indicizzati.
Figura 2.6 : L'infrastruttura di Monitoring e Discovery di GT4
Questi diversi meccanismi forniscono un potente framework per monitorare
60
diverse collezioni di componenti distribuiti e per ottenere informazioni circa i
componenti con scopi di discovery. Ad esempio, l'Earth System Grid (ESG)
35
usa questi meccanismi per monitorare lo stato dei vari servizi che esso usa per
distribuire e fornire accesso ad oltre 100TB di dati sul modello climatico.
D) Sicurezza e controllo degli accessi
I problemi di sicurezza sono molto importanti e cambiano quando le risorse e/o
gli utenti sono sparsi su locazioni multiple. C'è bisogno di esercitare il controllo
per sapere chi può fare cosa. Questo concetto riguarda i proprietari di
determinate risorse, gli utenti che vogliono iniziare una computazione, e le VOs
che dovranno gestire la condivisione di risorse. “Esercitare il controllo” può
includere il far rispettare determinate politiche e comportamenti. Nel progettare
questi meccanismi, i componenti della Globus Alliance hanno lavorato non solo
per garantire la sicurezza dei vari flussi di comunicazione, ma anche per limitare
i danni che potrebbero subire gli end-systems in caso di problemi. Sicuramente
questo è un grosso punto a vantaggio del Globus Toolkit. Una soluzione
completa e valida che interessi la sicurezza deve sempre essere costituita da
un sistema che combina i componenti utilizzati per stabilire le identità, applicare
le politiche, tracciare le azioni ecc. per ottenere specifici obiettivi inerenti alla
sicurezza. GT4 e i suoi tool forniscono un potente sistema di blocchi componibili
che può essere usato per costruire un insieme di questi sistemi.
Al livello più basso, GT4 i componenti di GT4 implementano protocolli e
strutture per le credenziali al fine di ottenere servizi come la protezione dei
messaggi, l'autenticazione, la delega, e l'autorizzazione. Come mostrato in
35 Bernholdt, D., Bharathi, S., Brown, D., Chanchio, K., Chen, M., Chervenak, A., Cinquini, L., Drach,
B., Foster, I., Fox, P., Garcia, J., Kesselman, C., Markel, R., Middleton, D., Nefedova, V., Pouchard,
L., Shoshani, A., Sim, A., Strand, G. and Williams, D. The Earth System Grid: Supporting the Next
Generation of Climate Modeling Research. Proceedings of the IEEE, 93 (3). 485-495. 2005
61
figura, il supporto è fornito per (a) WS-Security-compliant message-level con
credenziali basate su certificati X.509, (b) con username e password e (c) per la
sicurezza a livello di trasporto con credenziali X.509.
Nella configurazione di default di GT4, ogni utente e risorsa è assunta avere
una credenziale basata su chiave pubblica X.509. I protocolli sono implementati
in modo trale da permettere a due entità di convalidarsi l'una con l'altra, in
modo da usare queste credenziali per stabilire un canale con caratteristiche di
protezione dei messaggi e in modo da creare e trasportare delle credenziali di
delega che permettano ad un componente remoto di agire per conto di un
utente per un determinato periodo di tempo.
Le Authorization Call associate ai servizi di GT4 possono essere usate per
determinare quando specifiche richieste devono essere permesse. In
particolare, il componente framework di autorizzazione permette catene di
moduli di autorizzazione con interfacce ben definite che possono essere
associate a varie entità (ad esempio i servizi in un container). Esso fornisce
inoltre differenti implementazioni dei moduli di autorizzazione che vanno dalla
tradizionale autorizzazione di Globus basata su grid-map a moduli che usano il
protocollo SAML per richiedere un servizio esterno per decisioni di
autorizzazione.
62
Figura 2.7 : Protocolli di sicurezza di GT436
E) Come si sviluppano i servizi
In GT4 è incluso un vasto insieme di software per supportare lo sviluppo di
componenti che implementano le interfacce Web Services. Questo software è
stato creato, come abbiamo visto, per conseguire numerosi obiettivi come la
gestione di messaggi, la gestione di risorse e la sicurezza permettendo, perciò,
allo sviluppatore di focalizzare la propria attenzione sull'implementazione della
logica dell'applicazione. GT4 include, poi, anche altri componenti addizionali per
fornire container Globus per Web Services dando la possibilità di sviluppare
servizi di gestione scritti in Java, Python e C. Come illustrato in figura, questi
container possono ospitare una grande varietà di servizi:
36 Welch, V. Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective, 2004.
http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-Overview.pdf
63
•
Implementazioni di specifiche basilari per Web Services
come WSDL, SOAP e servizi di supporto WS-Security che
fanno uso di queste specifiche per sviluppare le funzionalità
base dei Web Services.
•
Implementazioni di altre specifiche come WS-Addressing,
WSRF e WS-Notification, servizi di supporto che gestiscono
lo stato di altri servizi, risorse di back-end e attività delle
varie applicazioni (Per esempio, GT4 GRAM ed RFT usano
questi meccanismi per gestire lo stato associato a decine di
migliaia di attività computazionali e trasferimenti di file
rispettivamente).
•
Il container Java è utilizzato per ospitare i vari GT4 Java
Web Services menzionati prima, come GRAM, RFT, DRS,
Delegation, Index e Trigger.
•
Registri molto potenti e capacità di gestione, notabili nella
rappresentazione dell'informazione su servizi in esecuzione
in un container come WS-Resource, facilitano la creazione
di registri distribuiti e tool per il monitoraggio di sistema.
Figura 2.8 : Capacità di un container GT4
64
In generale, il container Java fornisce il più avanzato ambiente di
37
programmazione, il container C le più alte performance , e (affermano
entusiasti gli utilizzatori di Python) il container Python, il più bel linguaggio.
Attualmente numerosi progetti stanno sviluppando servizi molto interessanti e
applicazioni basate su GT4. Per esempio il Belfast eScience Center utilizza
circa 1,5 milioni di linee di codice GT4 Java (convertite da GT3 in un processo
38
che ha richiesto pochissimi cambiamenti nel codice ) che implementano un
insieme di applicazioni che includono il sistema di gestione dei video per la
BBC. Un altro esempio è il China Grid Support Package che fornisce un ricco
insieme di servizi per l'eScience e l'educazione sviluppato sul container GT4
Java.
F) Processi, Risultati e Valutazioni
Il software prodotto dalla Globus Alliance è stato sviluppato negli ultimi cinque
anni e, grazie a filosofie come quella dell' open-source, si è arrivati ad ottenere
il primo posto al mondo nell'ambito delle tecnologie Grid. Il Globus Toolkit è
sicuramente il software per eccellenza nello sviluppo di sistemi Grid. Gli sviluppi
sono continui e la qualità fornita è sempre ai massimi livelli. Questi sviluppi sono
stati possibili grazie ad un gruppo di ingegneri dedicati e grazie agli utenti più
“accaniti” che hanno contribuito, in virtù dell'open-source, a rafforzare
ulteriormente questa piattaforma.
37 Humphrey, M., Wasson, G., Jackson, K., Boverhof, J., Meder, S., Gawor, J., Lang, S., Pickles, S.,
McKeown, M. and Foster, I. A Comparison of WSRF and WS-Notification Implementations: Globus
Toolkit V4, pyGridWare, WSRF:Lite, and WSRF.NET. 14th International Symposium on High
Performance Distributed Computing. 2005
38 Harmer, T., Stell, A. and McBride, D. UK Engineering Task Force Globus Toolkit Version 4
Middleware Evaluation, UK Technical Report UKeS_2005-03, 2005
65
Alcuni dei processi di sviluppo attualmente includono:
•
Suite di test di unità estensivi e l'uso di test-coverage-tools.
•
Frequenti ed automatizzate esecuzioni di ri-compiling e test
su oltre venti piattaforme.
•
Suite di test delle performance utilizzate per valutare i vari
aspetti delle performance già indicati nel primo capitolo,
quindi latenza, capacità produttiva, scalabilità, affidabilità
ecc.
•
Un piano di gestione della documentazione gestito da
specialisti dedicati allo scopo, che assicura una totale
copertura di tutti i componenti seguendo canoni di
uniformità.
•
Una community di circa 200 tester che esegue alfa e beta
test ogni sei mesi.
•
Ed altro...
39
Le performance di GT4 sono riassunte in un recente servizio . Questo report
fornisce, inoltre, riferimenti ad una documentazione più dettagliata, che include
ulteriori reports sulle performance di diversi container per Web Services, che
includono i container GT4 Java, C e Python; l'implementazione di GridFTP di
GT4 ed il servizio di localizzazione delle repliche.
2.3.4 XtreemOS: La risposta Europea a Globus
Un progetto che l'UE sta finanziando nell'ambito del Sesto programma quadro
39 Foster, I. Performance of Globus Toolkit Version 4. Globus Alliance, 2006.
www.globus.org/alliance/publications
66
40
(6PQ) è XtreemOS , il cui obiettivo è progettare e promuovere un sistema
operativo open source che fornirà supporto alle organizzazioni virtuali.
Come sistema operativo esso può essere impiegato per singoli PC e cluster di
computer, come pure per dispositivi mobili, i quali avrebbero tutti accesso alle
risorse di griglia.
Basato sul software open source Linux, XtreemOS mira a diventare
un'alternativa al suo diretto concorrente, il Globus toolkit statunitense, per
affermarsi
come
nuovo
standard
di
questa
importante
tecnologia.
Secondo la coordinatrice del progetto, Sandrine L'Hermitte, «il sistema
XtreemOS offrirà un'alternativa al Globus toolkit, il sistema middleware
attualmente più diffuso per gestire grid di calcolo, nonostante la sua
complessità».
«Il progetto XtreemOS si pensa possa contribuire a promuovere la posizione
dell'Europa nei settori della ricerca che interessano i sistemi operativi e i sistemi
Grid. Infatti, benché il sistema operativo Linux, il sistema Symbian per i telefoni
cellulari e il World Wide Web siano nati in Europa, gli USA predominano in
questi settori. Il progetto XtreemOS dovrebbe quindi aiutare a ristabilire un
equilibrio», ha concluso.
Il progetto, che avrà una durata di quattro anni, mira anche a promuovere il
sistema XtreemOS per grid a livello internazionale. Il consorzio del progetto
annovera già due partner cinesi. L'iniziativa, infatti, tiene gli occhi puntati
sull'Asia e sul suo mercato in rapida espansione.
Il progetto XtreemOS, ancora nella fase iniziale del suo sviluppo, ha
sicuramente tutti i requisiti necessari per poter raggiungere gli obiettivi che si è
prefissato. In questo progetto si può scorgere facilmente la similitudine con
quello che era Globus soltanto 5 anni fa.
40 www.xtreemos.eu/
67
In particolare XtreemOS parte proprio da quelli che si ritengano essere i
principali difetti di Globus. L'approccio di Globus, come abbiamo visto, è quello
di un infrastruttura costituita dalla somma di un certo numero di servizi. In
quest'infrastruttura, i tool sono progettati indipendentemente tra loro e in
risposta alle correnti necessità degli utenti. Globus nacque secondo un
approccio bottom-up per il quale un Grid deve essere costruito come un insieme
di tool sviluppati in base alle richieste degli utenti ed, in effetti, si è sviluppato
(dalla versione GT1 all'attuale GT4) secondo questi criteri. Le varie versioni
sono basate sulla combinazione di componenti che lavorano in un toolkit Grid
composito che espone a pieno il Grid al programmatore. Tuttavia il rischio
associato a questo approccio è che, se il numero di servizi cresce, la mancanza
di un'interfaccia di programmazione comune ai componenti e la mancqanza di
un modello unico che riguardi la loro interazione può avere un impatto negativo
sulla facilità d'uso. Tipicamente, non sempre, queste cose devono essere
gestite dal programmatore che deve preoccuparsi di rendere interoperabile il
servizio che sta sviluppando. Chiaramente, nel fare questo, c'è un aumento dei
41
tempi, costi e risorse impiegate .
2.4 Paradigmi per la progettazione di servizi
Vedremo ora i quattro paradigmi attualmente utilizzati per progettare
applicazioni per la fornitura di servizi.
2.4.1 Client­Server
41 A. Grimshaw, M. Humphrey, and A. Natrajan. A philosophical and technical comparison of legion
and globus. IBM Journal of Research and Development, 48(2), March 2004
68
Nell' approccio client-server il server è un sito che offre un insieme di servizi
ai client e contiene tutti i componenti necessari per svolgere le sue funzioni
(contiene sia il computational component, sia le risorse e sia il codice
necessario). Un client interagisce con il server richiedendo l’esecuzione di un
suo servizio, il server produce il risultato e lo invia al client tramite una seconda
interazione. In questo paradigma i componenti del client e del server effettuano
solo un’interazione tra di loro, non c’è la migrazione di componenti dal sito del
client a quello del server o viceversa. Il server contiene tutto il necessario per
svolgere le funzioni del servizio oppure interagisce con altri server per ottenere
da loro una parte dei risultati che deve fornire al client, in questo caso il server
si comporta come un client nei confronti del secondo server.
Un limite di questo paradigma è che non tiene conto di alcuni fattori importanti
come la dinamicità del codice o la rilocazione dei siti, problematiche che
bisogna considerare in fase di progettazione di un’applicazione.
2.4.2 Remote Evaluation
Nel Remote Evaluation (REV) il client ha il know-how (il codice) ma non ha
le risorse necessarie per svolgere l’esecuzione del servizio, tali risorse sono
localizzate in un host server. Il client invia il codice sulla macchina server, il
computational component del server esegue il codice utilizzando le risorse locali
ed invia il risultato al client tramite un’interazione. Il vantaggio che si ottiene con
questo paradigma è la possibilità di personalizzare i servizi, ad esempio nel
paradigma Client-Server ogni server fornisce un insieme fissato di servizi,
invece con il REV il client invia il codice del servizio che vuole ottenere, tale
codice viene eseguito sulla macchina del server ottenendo un servizio
personalizzato. Per ottenere ciò il server deve offrire un servizio che funziona
69
come un interprete di un particolare linguaggio, ad esempio i DBMS hanno un
interprete SQL, in questo modo il client invia un piccolo programma SQL, il
server lo esegue e restituisce i risultati (un insieme di dati contenuti nel
DataBase) al client.
2.4.3 Code on Demand
Nel Code on Demand (COD) l’host del client ha le capacità elaborative e le
risorse, ma non il codice. In questo caso il client chiede (tramite un’interazione)
al server il know-how del servizio, il server invia il codice al client in modo che
possa eseguire il servizio utilizzando le proprie risorse ed i suoi dati. Un
semplice esempio di questo tipo di applicazioni è il semplice download di un
programma da internet, il quale viene eseguito sulla macchina utente. Un
meccanismo molto diffuso nel web è rappresentato dalle applet java. Le applet
sono programmi scritti in linguaggio Java che possono essere eseguiti da un
Web browser, appaiono visivamente collocati all'interno di pagine Web, sono
solitamente usate per creare pagine dotate di funzioni non realizzabili con altre
tecnologie per il Web. Ad esempio le applet sono utilizzate per fornire contenuti
interattivi alla pagine web che il linguaggio HTML non è in grado di fornire. Un
altro esempio è dato dall’aggiornamento delle funzioni di un programma:
nell’approccio Client-Server l’amministratore della macchina deve effettuare
manualmente l’aggiornamento, invece con il modello COD si utilizza un server
che contiene gli aggiornamenti di tutte le funzioni. Quando un utente, mentre
utilizza il programma sul suo pc, richiama una funzione che deve essere
aggiornata, è il programma stesso che richiede al server l’aggiornamento della
funzionalità desiderata.
70
2.4.4 Mobile Agent
Nel Mobile Agent (MA) il client contiene il processor e il know-how, ma non
ha le risorse necessarie per eseguire il servizio, in tal caso il client “migra”
sull’host server ed esegue il suo servizio utilizzando le risorse locali. Il termine
“migrazione” indica che il client manda sull’host del server sia il suo
computational component che il codice del servizio, oltre ai risultati intermedi
ottenuti fino a quel momento. L’insieme di questi elementi costituisce l’agente
mobile, si tratta di un “programma” che ha un suo stato di esecuzione e sfrutta
le risorse della macchina ospitante per eseguire un servizio e conservarne i
risultati. L’agente mobile può migrare in macchine differenti, eseguire un
servizio per conto di un utente, portare con se i risultati e consegnarli all’utente
alla fine del suo “viaggio”. L’interazione con un agente mobile può essere di
due tipi:
• PUSH,
l’agente può decidere in modo autonomo di spostarsi su
un host che contiene le risorse necessarie all’elaborazione.
• PULL,
un utente può richiedere ad un agente mobile di spostarsi
sul proprio host, in modo che l’agente effettua le operazioni che
interessano all’utente.
E' chiaro che ognuno di questi paradigmi porta con se vantaggi e svantaggi. La
scelta di quale usare è legata al progetto dell'architettura in questione. E' però
importante sottolineare che la scelta della tecnologia (quindi linguaggi di
programmazione,
infrastrutture,
librerie)
è
totalmente
indipendente
dal
paradigma che si utilizzerà anche se alcune volte esistono particolari
abbinamenti tra tecnologie e paradigmi come nel caso di JADE che prenderemo
71
in esame.
2.5 Agenti mobili
Fin dall’avvento delle reti di computer e della programmazione distribuita c'è
stata la necessità di avere un nuovo strumento in grado di sfruttare al massimo
le risorse messe a disposizione: l’agente software mobile.
Diamo innanzitutto una definizione del concetto di agente:
“Agente: entità software autonoma, inserita nell’ambiente, pro­attiva e cooperante” 42
Definizione, questa, che è stata data agli albori del mondo delle reti, ma che
resta a tutt'oggi la più valida e sintetica. Vediamo nel dettaglio cosa vuol dire.
Da questa definizione emergono alcune proprietà che un agente deve avere:
•
Autonomia: ogni agente ha un suo stato che solo lui è in
grado di modificare e le azioni che compie dipendono
esclusivamente dal suo stato.
•
Inserimento nell’ambiente: ogni agente deve essere
in grado di “percepire” l’ambiente circostante mediante
l’utilizzo di opportuni “sensori” e deve essere in grado di
agire nell’ambiente mediante l’uso di opportuni “attuatori”.
Nel caso di agenti software, l’ambiente è l’host e la rete in
cui l’agente è presente e gli attuatori ed i sensori sono
opportune interfacce con tale ambiente.
42 N.R. Jennings and M.Wooldridge, Application of Intelligent Agents, In N.R. Jennings and M.
Wooldridge, editors, Agent Tecnology: Foundation, Application, and Markets, pages 3-28. SpringerVerlag, Berlin, Germany, 1998.
72
•
Pro­attività: il comportamento dell’agente deve essere
guidato da obiettivi. Questo significa che ogni agente ha nel
suo stato un insieme di obiettivi da soddisfare e quindi le
azioni devono essere tali da soddisfare tali obiettivi.
•
Reattività: ovvero la capacità di reagire alle modiche
dell'ambiente che li circonda, ogni qual volta che tali
cambiamenti influenzano il suo obiettivo.
•
Cooperazione: Ogni agente deve essere in grado di
interagire con altri agenti al fine di risolvere un dato
problema.
•
Mobilità: la capacità di muoversi su macchine diverse
all'interno di una rete. Il trasporto dell’agente può avvenire
tramite il sistema dei messaggi: il codice e lo stato viene
serializzato e posto in un messaggio, il quale è inviato sulla
macchina di destinazione dove avviene il processo inverso
(de
serializzazione
del
messaggio
e
ripristino
dell’esecuzione dell’agente).
•
Bidirezionalità: la mobilità dell’agente è bidirezionale,
nel senso che il “client”può inviare un agente al “server”,
ma anche il server può inviare un suo agente nella
macchina del client.
In genere quando si parla di Agenti si introduce pure il termine mobile ad
indicare appunto che tale entità è in grado di spostarsi: la mobilità rafforza
l’autonomia dell’agente, che ad esempio potrebbe decidere su quale computer
migrare in base alle risorse disponibili.
73
Un' altra possibile definizione, che mette in luce un'ulteriore aspetto di
fondamentale importanza negli agenti mobili è la seguente:
“Agente mobile: agente software in grado di trasferirsi su nodi remoti di una rete e di interagire con le risorse nei nodi visitati, scoprendo i servizi offerti.” 43
Dalla definizione si nota che l’Agente deve avere un certo grado di intelligenza,
sia per le decisioni che deve prendere una volta spedito, sia per la capacità di
memorizzare i risultati ottenuti su ciascun nodo visitato (capacità di mantenere
ed aggiornare il suo stato).
Sempre da quest'ultima definizione possiamo estrapolare le seguenti frasi
chiave:
•
Agente software: un agente mobile è innanzi tutto un
agente e quindi deve avere utte le proprietà degli agenti.
•
In grado di trasferirsi su nodi remoti di una rete: aspetto
caratterizzante degli Agenti Mobili è la capacità di trasferire
il loro codice ed il loro stato da un nodo ad un altro. Questo
ha due conseguenze: la prima è che deve esistere una
struttura che consenta all’agente di spostarsi; la seconda è
che tale agente deve avere una certa intelligenza da
renderlo particolarmente autonomo nella decisione degli
spostamenti.
Esistono
due
modalità
principali
di
trasferimento:

Clonazione: il codice e lo stato vengono duplicati nel
43 M. Georgeff, “Agents with Motivation: Essential Technology for Real World Applications”, in Proc.
of the First International Conference on the Practical Applications of Intelligent Agents and MultiAgent Technology, London
74
nodo di arrivo senza rimuoverli dal nodo di partenza.

Migrazione: il codice e lo stato vengono copiati nel
nuovo nodo e rimossi dal vecchio.
•
Interagire con le risorse nei nodi visitati scoprendo i servizi
offerti: una volta che l’agente arriva su un sito deve essere
in grado di interagire con le risorse locali che possono
essere anche altri agenti, e questa capacità è insita nella
tecnologia ad oggetti. Mentre risulta meno semplice
stabilire, da parte dell’Agente, quali servizi il sito mette a
disposizione: entra in gioco a questo punto il meccanismo
di introspezione degli oggetti, ossia un modello in cui
l’informazione su struttura e proprietà delle classi vengono
mantenute da meta-oggetti dinamicamente accessibili per
scoprire le caratteristiche delle classi stesse (n.b. Java
possiede tale meccanismo).
2.6 FIPA
I sistemi multiagente detti MAS (Multiple Agent System) rappresentano
senz'altro uno dei più importanti paradigmi tecnologici per lo sviluppo di sistemi
software distribuiti, aperti ed intelligenti. Come descritto per il Grid, anche la
tecnologia degli agenti ha dovuto, in passato, attraversare una fase in cui è
uscita dal mondo accademico per entrare nel mondo commerciale con tutte le
difficoltà che questo passaggio comporta.
Tipicamente i sistemi basati su agenti mobili venivano implementati con
soluzioni ad hoc (protocolli, linguaggi di comunicazione e quant'altro) per venire
incontro agli specifici requisiti delle applicazioni. In quest'ambito lo standard
75
FIPA (Foundation of Intelligent Physical Agents)
44
rappresenta la risposta alla
necessità di standard che possano governare l'infrastruttura dei sistemi MAS ed
i sistemi di comunicazione tra community eterogenee. FIPA mira a sviluppare
nuovi standard e ad agire come punto focale per il lavoro di ricerca richiesto.
FIPA ha pubblicato un insieme di documenti di riferimento ufficiali, ma solo
recentemente questi sono stati controllati e valutati attraverso applicazioni
pratiche basate sugli standard proposti. In quest'ambito l'obiettivo primario del
FACTS ( FIPA Agent Communication Technologies and Services) EU Project è
quello di validare il lavoro del FIPA, progettando complesse applicazioni reali
basate sugli agenti.
2.6.1 Progettazione e sviluppo di sistemi MAS
Quasi tutti i sistemi MAS si basano su un ricchi ed efficienti linguaggi di
comunicazione per
trasmettersi informazioni di alto livello sui processi in
esecuzione. Potremmo dire che il cuore delle applicazioni multi-agente sta
proprio nei linguaggi di comunicazione.
La parte dei sistemi MAS dedita alla comunicazione è quindi usata per
coordinare e condividere informazioni e servizi. Essere capaci di comunicare in
diversi modi offre potenzialmente la capacità di avere un'infrastruttura aperta,
autonoma, robusta, scalabile e flessibile. Il prezzo da pagare per raggiungere
questi benefici è la complessità degli algoritmi usati per mantenere coerenza tra
le informazioni distribuite. Il costo più grande sta nel coordinare questi diversi
servizi senza piazzare troppe restrizioni sui linguaggi di comunicazione né
tantomeno nella logica interna degli agenti.
44
FIPA - Foundation for Intelligent Physical Agents, http://www.fipa.org/.
76
2.6.1.1 Componenti comuni in un sistema MAS
La maggior parte delle applicazioni MAS ha un insieme di componenti software
che forniscono:
•
Un protocollo di comunicazione, come ACL
(Agent
Communication Language)
•
Una sintassi per il protocollo, come KQML (Knowledge
Query Manipulation Language)
•
Un interfaccia generica (che da un punto di vista formale è il
livello ontologico di base) che fa in modo da garantire la
comprensione e l'uso dei contenuti.
Per supportare un linguaggio di comunicazione, un MAS deve avere almeno un
canale di comunicazione (ad esempio TCP/IP o Corba). La maggior parte dei
MAS si basa su standard per registrare agenti, regole e per richiedere
informazioni relative ad altri agenti.
Un altro componente che normalmente è definito è il dialogue manager che
gestisce i normali protocolli legati ad un agente e interpreta i contenuti dei
messaggi inquadrandoli in uno specifico contesto. Tipicamente, poi, gli agenti in
un sistema MAS sono in grado di tenere traccia delle interazioni con altri agenti
e del loro stato.
2.6.1.2 Gli standard FIPA
L'obiettivo di FIPA è di promuovere lo sviluppo di specifiche per tecnologie
basate su agenti. Specifiche che possano massimizzare l'interoperabilità dentro
e tra le applicazioni ad agenti. FIPA fornisce delle normative relative a tutti i temi
77
che riguardano le tecnologie ad agenti (ad esmpio il ciclo di vita degli agenti, la
comunicazione tra di loro, la mobilità e la sicurezza).
Per lo standard FIPA un sistema basato su agenti mobili deve possedere le
seguenti caratteristiche:
•
La piattaforma ad agenti (AP) che è l'infrastruttura sulla
quale gli agenti effettuano le loro operazioni. In questa
piattaforma sono definite le caratteristiche degli agenti e
tutti gli aspetti che riguardano il loro ciclo di vita e la loro
gestione.
•
Il Message Transport Service (MTP) di cui fa parte
l'Agent Communication Language (ACL) che è il linguaggio
che gli agenti devono usare per codificare i messaggi che si
45
scambiano. L'ACL è basato sulla “speech act theory” : i
messaggi non sono nient'altro azioni che devono essere
eseguite, e vengono inviati da un agente ad un altro. La
specifica consiste in un insieme di messaggi-tipo e nella
descrizione delle loro caratteristiche.
•
Il Content Language, che è il linguaggio usato per
codificare il contenuto di un messaggio. Il “content” è
quella parte del messaggio che rappresenta la componente
dipendente dal dominio. FIPA non fornisce un unico content
language obbligatorio ma un insieme di content language di
46
riferimento .
•
I protocolli, che sono i modelli tipici dello scambio di
messaggi. Essi specificano come la comunicazione verrà
45
46
J. R. Searle. Speech Acts (Cambridge University Press, Cambridge, 1969).
FIPA97 Specification, version 2.0, Part 2, Agent Communication Language
78
eseguita imponendo restrizioni alle interazioni tra gli agenti.
•
Gli agenti: le specifiche FIPA definiscono gli agenti come
processi software che possiedono un proprio ciclo di vita,
gestito dalla piattaforma. Le specifiche delineano quali sono
gli stati in cui può trovarsi un agente durante il suo ciclo di
vita. Alla creazione un agente è posto nello stato initiated al
quale segue lo stato active. Dallo stato active l'agente può
passare
allo
stato
transit
(ad
esempio
durante
un'operazione di spostamento da un nodo della rete ad un
altro), oppure waiting, o ancora suspended. L'agente può
continuare
ad
assumere
i
seguenti
stati
fino
alla
conclusione del suo ciclo vitale.
Figura 2.9: Il ciclo di vita di un agente mobile
•
Directory Facilitator (DF): è un agente che viene
avviato automaticamente dalla piattaforma. Il suo scopo è
quello di interagire con gli altri agenti mobili fornendo loro
79
informazioni sulla posizione degli altri agenti all'interno della
piattaforma e sui servizi che questi offrono, in pratica
contiene la lista dei servizi disponibili di ogni agente
presente nella piattaforma.
•
Agent
Management
System
(AMS): contiene gli
identificativi (Agent Identier AID) degli agenti registrati sulla
piattaforma.
Figura 2.10: Architettura di una piattaforma FIPA
Le specifiche FIPA riflettono alcuni principi che hanno guidato il processo di
standardizzazione. Il primo di questi concetti è la trasparenza: gli agenti
possono collegarsi (o viceversa) a tempo di esecuzione ad un sistema senza la
necessità di ricompilarlo o riconfigurarlo. Tuttavia un agente che vuole
comunicare con un altro agente necessita di seguire le convenzioni FIPA sul
naming e deve effettuare il processo di registrazione sul Directory Facilitator
(DF) per poter localizzare l'altro agente. Un altro concetto strettamente legato ai
precedenti è quello dell'interoperabilità: gli standard FIPA tendono a specificare
80
il minimo set di requisiti in modo da evitare ogni compromissione con particolari
hardware, sistemi operativi o linguaggi di programmazione. Un altro importante
principio fortemente supportato da FIPA è quello delle “explicitness”: le
informazioni e le assunzioni relative al sistema ad agenti (il ruolo e le capacità di
questi agenti, il modo in cui interagiscono, il significato dei contenuti dei
messaggi ecc.) devono essere il più esplicite possibile. In quest'ambito FIPA
fornisce un certo numero di peculiarità:
•
Grazie al meccanismo del Directory Facilitator (DF), le
funzionalità
offerte
dagli
agenti
di
una
particolare
piattaforma sono descritte esplicitamente. In questo modo
un nuovo agente che cerca uno specifico servizio può
facilmente ottenere l'indirizzo dell'agente che lo fornisce.
•
L'utilizzo di protocolli fa in modo di avere specifiche
assunzioni riguardo le interazioni tra gli agenti coinvolti
(cioè riguardo il flusso dei messaggi scambiati ed il tipo di
comunicazioni).
•
Per la comprensione delle informazioni dipendenti dal
dominio FIPA prescrive l'uso di ontologie. Un'ontologia dà
significato ai simboli e alle espressioni all'interno di un dato
linguaggio nel dominio (ad esempio riferendosi alla stessa
ontologia gli agenti attribuiscono lo stesso significato alle
costanti usate nello scambio di messaggi).
Infine FIPA non dichiara di voler fornire specifiche riguardanti la parte interna
degli agenti. Tuttavia questa dichiarazione è in parte fuorviante a causa delle
semantiche utilizzate per definire i linguaggi di comunicazione tra gli agenti che
sono abbastanza restrittive.
81
Capitolo 3
Agenti software su Grid
3.1 Introduzione
Questo capitolo è una breve panoramica, ad alto livello, riguardante “cosa” è
stato fatto in questo lavoro di tesi: sarà presentato il contesto e saranno
descritte le problematiche. I successivi due capitoli riguardano il “come” sono
stati raggiunti gli obiettivi andando a porre l'attenzione sulle tecnologie utilizzate
per raggiungere i vari scopi ed andando ad evidenziare eventuali limiti che sono
stati riscontrati.
Molto sinteticamente, questo lavoro ha avuto tre scopi.
In prima battuta, è stato progettato e configurato un cluster di macchine virtuali
che potessero fungere da “nodo Grid”, sul quale, quindi, potessero essere
offerti dei servizi. Si è poi provveduto a valutare dettagliatamente una serie di
servizi Grid e ad adattarli e a testarli nell'ambiente virtuale. Infine è stata
sviluppata un' interfaccia grafica ad hoc che ha lo scopo di facilitare l'utilizzo di
client e la gestione di servizi sul cluster.
82
3.2 Il cluster virtuale
Un ambiente ideale dove testare i servizi Grid per scopi accademici o di ricerca,
è senz'altro un cluster di macchine collegate in rete tra loro che possano
condividere le proprie risorse (potenza computazionale, memoria RAM,
memoria fisica). Esso è un ambiente privato in cui è possibile testare ciò che
avverrebbe nella rete esterna, internet. Per cluster tipicamente si intende un
insieme di macchine di cui una, il Front-End, rappresenta il nodo principale a cui
fanno riferimento tutti gli altri nodi. E' altrettanto chiaro che tutti i nodi sono poi
interconnessi tra loro. Tipicamente, l'unico accesso dall'esterno è fornito dal
Front-End. Questa macchina è l'unica collegata ad Internet ed occorre loggarsi
su di essa per poter sfruttare le risorse offerte dagli altri nodi.
Figura 3.1 : schema di un cluster di macchine
83
Un cluster, normalmente, è un ottimo ambiente per poter sviluppare e testare i
servizi e le lor funzionalità. Essendo un ambiente privato, esso garantisce una
certa libertà di manovra. Avendo più macchine e quindi più risorse
computazionali, è un ambiente ideale per lo sviluppo di sistemi Grid. Inoltre,
poiché le macchine del cluster (che prendono il nome di nodi) sono collegate da
una rete interna, è possibile testare appieno le potenzialità offerte dai servizi
sviluppati.
E possibile, tuttavia, fare un ulteriore passo avanti. Si può pensare di
“virtualizzare” un cluster. Utilizzando la tecnologia delle macchine virtuali è
possibile infatti creare un cluster virtuale avente le stesse caratteristiche e gli
stessi vantaggi offerti da un cluster reale.
3.2.1 Vantaggi di un cluster virtuale
Utilizzare un cluster virtuale offre, inoltre, una serie di vantaggi:
•
Sicurezza: chi gestisce il cluster virtuale è tipicamente colui che
sta sviluppando e testando i servizi. Ha a disposizione i permessi
di amministrazione per poter effettuare tutte le modifiche che
ritiene opportune. Chi usa un cluster virtuale non deve
preoccuparsi di non arrecare danno ad altri utenti facendo
operazioni azzardate.
•
Test: su un cluster virtuale possono essere effettuati test di ogni
tipo poiché esso simula un sistema reale. E' possibile creare
utenti, farli interagire, controllare come nuove modifiche alla
configurazione possano ripercuotersi su di essi ecc. Una volta
84
testato accuratamente l'ambiente si può portare senza problemi la
configurazione utilizzata sul cluster reale.
•
Manutenibilità: legata ai due precedenti aspetti. Gestendo
macchine virtuali si possono gestire al meglio le modifiche
“hardware” andando semplicemente a modificare dei file di
configurazione. Su un cluster reale, eventuali operazioni di
manutenzione devono essere preventivate,e bisogna avvertire gli
utenti della sospensione temporanea dei servizi.
•
Affidabilità: trattandosi di file immagine, l'unica accortezza
richiesta è che questi file siano conservati in un ambiente sicuro.
Facendo normali back-up è possibile sempre riportarsi ad una
precedente
configurazione
hardware-software
sicuramente
funzionante.
•
Prestazioni di rete: i file immagine normalmente possono
risiedere su una sola macchina ed i collegamenti di rete simulati
saranno estremamente performanti.
L'utilizzo di un cluster virtuale, però, presenta anche degli svantaggi legati alle
prestazioni in generale. Un file immagine rappresentante una macchina virtuale,
avrà assegnato un certo numero di risorse (CPU, RAM, Memoria di Massa) che,
per ovvie ragioni, saranno minori o uguali a quelle presenti sulla macchina reale
che lo ospita. In pratica, se sulla macchina reale ci sono 2GB di RAM non sarà
pensabile assegnarne 3 alla macchina virtuale, ma sarebbe comunque
sconsigliato assegnarne anche 2. Questo perché ipotizzando di usare al
massimo la memoria elettronica della macchina virtuale, non si avrebbe più
85
memoria per la macchina reale.
E' chiaro che la figura utilizzata per descrivere il cluster reale è valida anche per
la descrizione del cluster virtuale. La localizzazione fisica di un cluster virtuale
può essere una macchina connessa ad internet (con adeguata disponibilità di
risorse) o un nodo di un cluster reale (la configurazione usata per questo lavoro
di tesi).
Figura 3.2 : Schema di un cluster virtuale in una macchina reale
In questo ambito l'obiettivo è stato quello di configurare adeguatamente un
cluster virtuale per ospitare e testare un'infrastruttura per la gestione di servizi
Grid. I dettagli sulle tecnologie usate e sulla configurazione sono nel prossimo
capitolo e in Appendice A.
86
3.3 Il sistema Grid
Il passo successivo, previsto da questo lavoro di Tesi, è stato quello di
configurare sul cluster virtuale un'infrastruttura per la creazione e la gestione di
servizi, avvalendosi delle possibilità offerte dai sistemi Grid.
L'obiettivo è stato quindi quello di progettare un' infrastruttura che offra le
funzionalità di base per poter essere successivamente utilizzata per lo sviluppo
ed il testing di servizi più complessi.
Avendo a che fare con un cluster, e quindi con più risorse separate, l'idea è
quella di poter dividere tra esse il carico di lavoro richiesto dalle varie
applicazioni.
Un primo limite, però, è rappresentato dal fatto che i middleware Grid non sono
in grado, da soli, di far migrare un' applicazione tra sistemi differenti, quindi
ambienti eterogenei con sistemi operativi differenti, file system differenti ecc.
L'architettura Grid non fornisce direttamente astrazioni che consentano l'uso di
paradigmi di interazione tra le entità.
Attualmente lo scheduling di jobs su sistemi geograficamente distribuiti non è
supportato dal Grid. L'architettura utilizza, infatti, i meccanismi forniti dai sistemi
operativi o da schedulatori batch.
3.3.1 L'uso degli agenti mobili
Si sarà già intuito, vista la panoramica fatta nel capitolo precedente, che il
paradigma ad agenti mobili offre una serie di valide soluzioni e meccanismi ai
problemi appena visti. Quindi unendo le peculiarità degli agenti mobili ad
87
un'architettura Grid, si potranno ottenere nuove funzionalità quali ad esempio:
•
Mobilità a run­time: gli agenti mobili sono in grado di
spostare l'esecuzione di un'applicazione su qualsiasi host
su cui sia presente una piattaforma ad agenti e, come
abbiamo
visto,
queste
operazioni
sono
totalmente
indipendenti dalla configurazione hardware/software che c'è
sulle macchine. È possibile far migrare l’esecuzione a
seconda dei cambiamenti dinamici nello stato della Grid,
utilizzare nuovi nodi tramite una configurazione a run-time,
adattare l’esecuzione rispetto la configurazione della
macchina e la quantità di risorse disponibili. In questo modo
la tecnologia ad agenti mobili consente di effettuare ed
ottimizzare l’esecuzione di un’applicazione all’interno di
ambienti eterogenei e distribuiti.
•
Forme di collaborazione: gli agenti mobili possono
rimodellare dinamicamente il sistema di comunicazione
iniziale aggiungendo dei differenti meccanismi per lo
scambio dei messaggi (sia di tipo sincrono che asincrono),
così come possono offrire delle forme di collaborazione tra
le varie componenti del programma.
•
Scalabilità nelle elaborazioni: tramite i meccanismi di
migrazione, clonazione e di persistenza gli agenti mobili
sono in grado di determinare il carico computazionale
sostenibile su ogni singola risorsa e distribuire in modo
adeguato i componenti di un’applicazione tra le risorse
88
disponibili. Gli agenti possono essere inviati su macchine
remote che offrono delle risorse computazionali, ogni
agente valuta i parametri del sistema e lo stato della
macchina, quindi interagiscono tra loro per decidere come
distribuire il carico tra le macchine. Ad esempio ogni
agente, dopo aver esaminato lo stato dell’host, decide il
numero di cloni di se stesso da creare, i quali verranno
eseguiti
sulla
macchina.
Inoltre
questo
meccanismo
fornisce una forma di scheduling ottimizzato per ogni
applicazione, poiché consente di distribuire i vari jobs sulle
risorse in modo dipendente sia dall’applicazione che dalle
reali capacità delle singole risorse.
•
Diminuzione dell’overhead dovuto alla latenza delle
comunicazioni, infatti con il paradigma ad agenti mobili è il
codice ad essere portato dove risiedono i dati. Solo dopo
aver finito l’elaborazione dei dati l’agente restituisce i
risultati all’utente, in questo modo viene ridotto il traffico dati
sulla rete.
•
Nuove forme di utenti: un agente mobile possiede la
stessa autorità del suo proprietario, in questo modo la
tecnologia ad agenti mobili offre un meccanismo di
delegazione
dei privilegi che
viene automaticamente
integrato nell’applicazione.
Per la creazione dell'infrastruttura sono state quindi unite la tecnologia Grid,
quella dei Web Services ed il paradigma di programmazione ad agenti mobili, in
89
modo da avere Grid Services le cui applicazioni possano spostarsi tra diverse
entità.
3.4 Il nodo Grid
Il nostro scopo si può sintetizzare con l'obiettivo della creazione di un nodo
Grid. Con questo termine si intende la risorsa Grid che contiene la piattaforma
ad agenti. Un nodo Grid è un insieme di macchine collegate tra di loro tramite
una rete, sulle quali è installata una piattaforma ad agenti mobili che offre il
supporto per la creazione e l’esecuzione di applicazioni multi-agente.
Una delle macchine del Nodo Grid deve avere anche la funzione di
interfacciamento con il mondo Grid, quindi su tale nodo è installato il software
che implementa l’infrastruttura Grid, oltre a contenere il software relativo alla
piattaforma ad agenti. La “parte” grid di questa macchina comprende
l’implementazione dei quattro servizi descritti in precedenza, i quali sono
utilizzati per accedere al Nodo Grid dall’esterno. Il cluster virtuale rappresenta,
quindi, un esempio di Nodo Grid, esso è composto da un insieme di nodi
collegati tra loro tramite una rete dedicata e da un “front-end”. Quest’ultimo,
come già accennato in precedenza, è una macchina collegata con la rete
esterna al cluster e la sua funzione è quella di fornire l’accesso al cluster e di
coordinare le applicazioni distribuite sui nodi.
Sfruttando il paradigma ad agenti mobili, possiamo utilizzarne anche le
nomenclature. Nella collezione di macchine che costituiscono il nodo Grid, la
singola macchina prende il nome di “nodo Agente ”. Sul Front-End del cluster
gira il Container Grid che è l’infrastruttura Grid installata su una macchina e
contiene l’implementazione dei Grid Services e fornisce i metodi di accesso a
questi servizi.
90
3.5 I servizi offerti
Affinché l'infrastruttura di cui si parla nel precedente paragrafo possa essere
completa ed efficiente, essa deve offrire una serie di funzionalità di base che
consentano innanzitutto la possibilità di pubblicare nuovi Grid Services e poi di
poter garantire la gestione delle piattaforme ad agenti che consentano lo
spostamento delle applicazioni tra le diverse macchine coinvolte.
In questa fase del lavoro, si è provveduto quindi ad integrare sull'infrastruttura
una serie di servizi che consentono l'amministrazione ed il monitoraggio di una
piattaforma ad agenti (come vedremo nel prossimo capitolo si tratta di JADE) e
la creazione e gestione degli agenti stessi.
In una fase immediatamente successiva è stato integrato un servizio di mobilità
degli agenti tra piattaforme diverse.
Per poter integrare i vari Grid Services si è effettuato uno studio delle tecniche
per lo sviluppo vero e proprio dei Grid Services. Nel capitolo 4 e in Appendice B
parleremo dettagliatamente dello sviluppo e della successiva pubblicazione sul
container virtuale di un servizio Grid.
I servizi base che sono stati integrati e che esamineremo più nel dettaglio nel
capitolo 4 sono:
•
Monitoraggio: ll servizio di monitoraggio offre le funzioni con cui
ogni utente, che copre il ruolo di amministratore della risorsa Grid,
può esaminare lo stato della piattaforma ad agenti e delle
macchine che compongono la risorsa. Queste operazioni sono utili
per osservare la distribuzione del carico di lavoro tra i singoli nodi
della risorsa. In questo modo l’amministratore del sistema può
ridistribuire le applicazioni in esecuzione tra i nodi della
91
piattaforma, al fine di bilanciare il carico tra le macchine ed evitare
il sovraccarico di un singolo nodo.
•
Amministrazione: Il servizio di amministrazione fornisce un
insieme di operazioni che consentono ad un utente di gestire il
funzionamento della piattaforma ad agenti, queste operazioni sono
rivolte alla configurazione della piattaforma (gestione dei singoli
nodi) e degli agenti.
•
Utente: Questo servizio offre la possibilità ad un utente di
lanciare un agente mobile o di inviare messaggi ad uno degli
agenti in esecuzione sulla piattaforma.
•
Sviluppo: Si tratta di un servizio che offre un supporto per
l’installazione delle applicazioni multi-agente sulla risorsa. L’utente
è in grado di installare ed utilizzare l’insieme di agenti mobili che
ha sviluppato per eseguire un’applicazione multi-agente sulla
piattaforma, inoltre le operazioni presenti nel servizio offrono un
supporto per l’implementazione dei nuovi agenti mobili.
•
Mobilità
inter-piattaforma:
Il servizio di mobilità inter-
piattaforma consente ad un agente di spostarsi tra due diverse
piattaforme ad agenti presenti sul nodo Grid anziché tra i singoli
container all'interno della piattaforma. Nel capitolo 4 vedremo più
nel
dettaglio
come
vengono
gestiti
i
vari
paradigmi
di
comunicazione e con quali protocolli.
92
3.5.1 Modello di funzionamento
I servizi di cui abbiamo parlato finora hanno la specifica funzione di interfacciare
un utente posto all’esterno alla risorsa e le applicazioni ad agenti in esecuzione
al suo interno. Il loro scopo è quello di estendere e rendere utilizzabile il
paradigma di programmazione ad agenti mobili anche in ambito Grid.
Un’azione richiesta al servizio è convertita in una comunicazione verso l’agente
mobile interessato. Il modello tramite cui implementare il meccanismo di
comunicazione tra il servizio ed un agente mobile prevede l’uso di un agente
proxy. Il proxy è in esecuzione nella componente della piattaforma installata
sulla macchina che contiene il container dei servizi Grid (il nostro Front-End
virtuale). Questo agente utilizza metodi di comunicazione locali per dialogare
con il Web Service che implementa il servizio, metodi che sono implementati
utilizzando le tecnologie fornite dal sistema che gestisce la macchina, mentre
usa il sistema di comunicazione della piattaforma per dialogare con l’agente
mobile.
Figura 3.3: Modello di funzionamento
93
3.6 Interfaccia Grafica
L'ultimo passo è stato quello di sviluppare un' interfaccia grafica che potesse
fungere da client esterno per poter utilizzare i servizi Grid basati su agenti
mobili. In pratica si tratta di un'interfaccia Java che gestisce tutte le funzionalità
dei servizi descritti in precedenza. Quest' interfaccia sarà utilizzabile da
qualunque locazione fisica a patto che siano soddisfatti alcuni requisiti (come
vedremo si tratta di un certificato valido per il Nodo grid da parte dell'utente che
vuole usare l'interfaccia ed un indirizzo pubblico del nodo se si vuol utilizzare
quest'interfaccia da Internet). I dettagli implementativi sono nel capitolo 5 e in
Appendice D.
94
Capitolo 4
Configurazione del cluster virtuale e delivering dei principali servizi
4.1 Introduzione
In questo capitolo si andranno ad esaminare nel dettaglio gli “step” effettuati
per raggiungere gli obiettivi prefissati nel capitolo precedente.
Nella prima parte del capitolo ci occuperemo della configurazione del cluster
virtuale e dell'installazione del middlware Grid scelto, il Globus Toolkit. Verrà
fatta anche una breve descrizione della tecnologia Jade, che rappresenta la
scelta fatta nell'ambito delle piattaforme ad agenti mobili.
Successivamente, avendo installato il middlware Grid ed avendo configurato la
gestione della sicurezza, vedremo come si è proceduto ad adattare dei servizi
preesistenti al funzionamento in questo ambiente. In particolare vedremo che
sono state apportate leggere modifiche ai servizi stessi ed in più sono stati
sviluppati dei client ad hoc per poterne testare il funzionamento da terminale.
95
4.2 Lo schema di principio
Come anticipato nel capitolo 3, la scelta dell'ambiente da configurare per
ottenere un Nodo Grid è stata quella di un cluster virtuale. Abbiamo quindi
sfruttato il cluster reale fornito dalla Facoltà, il cui Front-End è chiamato “Vega”.
Vega è connesso ad Internet in un solo punto, il Front-End. Per accedere a un
qualunque nodo di calcolo è necessario quindi accedere prima sul Front-End e
poi collegarsi ad esso.
Figura 4.1: Il cluster “Vega”
Su uno dei nodi di Vega, nello specifico sul “vm-container-0-1” abbiamo posto
96
le immagini delle nostre macchine virtuali ed i file di configurazione per poterle
avviare e spegnere. Abbiamo così la struttura base del nostro cluster virtuale.
Anche in questo caso abbiamo un Front-End ed una serie di macchine ad esso
interconnesse. Ed anche in questo caso l'unico collegamento con l'esterno è
costituito dal Front-End. E' chiaro che, però, il “mondo esterno” è costituito
stavolta dalla rete interna del cluster reale che, ricordiamo, a sua volta è
collegato ad Internet tramite il Front-End reale. Abbiamo già visto, nel
precedente capitolo, i vantaggi di questo tipo di approccio.
La situazione che si presenta è ben descritta dalla figura 4.2:
Figura 4.2: Il cluster virtuale “GlobFecod” all'interno di “Vega”
97
4.3 Il Network File System
Un Network File System (NFS)
47
consente di montare delle partizioni su un
sistema remoto e utilizzarle come se fossero filesystem locali. Ciò permette
l'amministratore del sistema di immagazzinare le risorse in una posizione
centrale sulla rete, garantendo agli utenti autorizzati la possibilità di accedervi
costantemente.
NFS consiste di almeno due parti: un server ed uno o più client. Il client accede
da remoto ai dati conservati sulla macchina server. Affinché questo funzioni,
alcuni processi devono essere configurati e devono essere attivi.
Il server deve avere attivi i seguenti demoni:
Demone
Descrizione
nfsd
Il demone NFS che serve richieste da
client NFS.
mountd
Il demone di mount NFS che serve le
richieste che nfsdgli passa.
rpcbind
Questo demone permette ai client NFS
di scoprire quali porte il server NFS sta
usando.
Il client può anche eseguire un demone, noto come nfsiod Il demone nfsiod
serve le richieste dal server NFS. E' opzionale, aiuta a migliorare le prestazioni
ma non è indispensabile per operazioni corrette. E' con NFS che sono collegate
le macchine del cluster virtuale.
47 http://www.freebsd.org/doc/it_IT.ISO8859-15/books/handbook/network-nfs.html
98
4.4 La configurazione del cluster
E' opportuno innanzitutto uniformare la nomenclatura che sarà usata da ora in
avanti. Si parlerà in maniera equivalente di Front-End reale o di Vega. Quando
ci si vorrà riferire ai nodi del cluster reale si userà il termine “nodi fisici”. Per
quanto riguarda il cluster virtuale si useranno equivalentemente i termini FrontEnd virtuale e GlobFecod (che è il suo hostname) e per indicare i nodi del
cluster virtuale si userà il termine “nodi virtuali”
Per poter lavorare sul cluster virtuale è necessario prima effettuare l'accesso sul
cluster reale. Una volta entrati nel Front-End, sarà possibile collegarsi a tutti i
nodi fisici del cluster. Tipicamente lo si fa con una connessione ssh cui è stato
disabilitato l'accesso tramite password per semplificare le operazioni. Il cluster
virtuale, le cui macchine sono costituite da immagini localizzate fisicamente su
uno dei nodi, è visto dal Front-End reale come una delle tante macchine. In
pratica è visto come un nodo fisico ed è dotato di un suo indirizzo interno. Per
avere accesso al cluster virtuale, quindi, l'unica strada è ripetere le operazioni
che si sono già effettuate per il cluster reale, e loggarsi sul Front-End virtuale.
Una volta lì, si potrà avere accesso ai vari nodi virtuali sempre tramite una
connessione ssh.
Le immagini fornite rappresentano degli host con precise risorse su cui girano
distribuzioni Linux Red Hat. Sono collegate tra loro utilizzando il Network File
System in modo da poter condividere una parte del File System locale, nella
fattispecie la cartella home.
Queste immagini non sono fornite di un X-Server, pertanto è necessario
lavorare da riga di comando. Dal momento che esse sono state fornite senza
alcun software rilevante ai fini di questo lavoro, si è dovuto procedere con una
99
serie di installazioni e configurazioni al fine di avere un ambiente ideale
all'interno del quale far lavorare i servizi.
Una modifica importante che è stata effettuata è la configurazione ad hoc del
protocollo ssh, in modo da poter funzionare senza la richiesta di password ma
solo tramite l'utilizzo del meccanismo a chiave pubblica. Questo ha fatto si che
l'accesso alle macchine avvenisse automaticamente una volta lanciato il
comando per il collegamento ssh. Il vantaggio di questa soluzione (adottata
anche sul cluster reale) è che i servizi che hanno necessità di attivare
funzionalità su altri host remoti possono farlo in maniera totalmente trasparente.
In Appendice A è descritto dettagliatamente il procedimento seguito per la
modifica al protocollo ssh.
4.4.1 Jade
JADE
(JavaAgent
DEvelopment
framework)
è
un
framework
completamente implementato in java dai laboratori TILAB. Esso semplifica
l'implementazione di sistemi MAS attraverso un middleware conforme alle
specifiche FIPA ed attraverso un insieme di tools che supportano le fasi di
debbunging e di deployment. La piattaforma ad agenti puo' essere distribuita
attraverso macchine (che non devono per forza avere gli stessi sistemi
operativi) e la configurazione può essere controllata tramite interfaccia remota.
La configurazione può, inoltre, essere modificata a run-time spostando gli agenti
da una macchina ad un'altra ogni volta che occorre.
Fondamentalmente JADE è un middleware basato su un'architettura di
comunicazione di tipo peer-to-peer. L'intelligenza, le informazioni, le risorse ed il
controllo possono essere totalmente distribuite su terminali mobili o su
computer in una rete fissata. L'ambiente può evolvere dinamicamente con i
100
peers, che in Jade sono costituiti dagli agenti i quali appaiono e scompaiono dal
sistema a seconda delle necessità e delle richieste dell'ambiente di
applicazione. La comunicazione tra gli agenti è completamente simmetrica con
ogni agente che è abilitato ad avere sia il ruolo di “initiator” sia quello di
“responser”.
4.4.1.1 Principi guida
I principi guida su cui si basa Jade sono:
•
Interoperabilità: Jade è conforme allo standard FIPA, di
conseguenza gli agenti di Jade possono interoperare con altri
agenti, purché essi siano conformi allo stesso standard.
•
Uniformità e portabilità: Jade fornisce un set omogeneo di API
che sono indipendenti dal tipo di rete o di versione Java. Più nello
specifico, l'ambiente run-time di Jade fornisce le stesse API per gli
ambienti J2EE, J2SE e J2ME. In teoria, gli sviluppatori di
applicazioni potrebbero decidere l'ambiente run-time di Java al
momento di far partire la piattaforma.
•
Facilità di utilizzo: la complessità del middlware è nascosta
dietro un semplice ed intuitivo insieme di API.
•
Filosofia “Pay as you go ”: i programmatori non necessitano
di utilizzare tutte le caratterstiche fornite dal middleware. Le
caratteristiche
che
non
sono
usate
non
richiedono
al
programmatore alcuna conoscenza in merito, né tantomeno
aggiungono overhead computazionale.
101
4.4.1.2 Il modello architetturale
Jade include tutte le librerie richieste per lo sviluppo di applicazioni ad agenti e
l'ambiente run-time che fornisce i servizi base e che deve essere attivo sul
device prima che gli agenti
possano essere eseguiti. Ogni istanza di un
ambiente run-time di Jade è chiamata “container” (perché appunto contiene
agenti). L'insieme di tutti i container è chiamato piattaforma e fornisce uno strato
omogeneo che nasconde agli agenti (e quindi anche agli sviluppatori
dell'applicazione) la complessità e la diversità degli strati sottostanti (hardware,
sistemi operativi, tipi di rete, JVM ecc.).
Ogni piattaforma JADE può avere un solo Main Container, in cui vengono
eseguiti l’agente AMS (detto anche white page service) e l’agente DF (detto
anche yellow page service). La gestione dei messaggi, scambiati tra gli agenti,
è affidata al componente ACC (Agent Communication Channel), il quale
fornisce una coda di messaggi in ingresso e una coda di messaggi in uscita.
L’ACC utilizza un sistema di trasmissione dati differente a seconda della
destinazione del messaggio, se l’agente ricevente si trova nello stesso
container allora il messaggio è consegnato direttamente all’agente tramite la
condivisione di oggetti java, se l’agente è posto in un container diverso della
piattaforma, il messaggio è inviato tramite JAVA-RMI, infine se il destinatario si
trova su una piattaforma differente si utilizza un protocollo inter-platform per
inoltrare i dati.
4.4.1.3 Il modello Funzionale
Dal punto di vista funzionale, Jade fornisce i servizi di base necessari ad
applicazioni distribuite in un ambiente fatto da host sia fissi che mobili. Jade
permette ad ogni agente di scoprire dinamicamente altri agenti e di comunicare
102
con loro in accordo al paradigma peer to peer. Dal punto di vista
dell'applicazione, ogni agente è identificato da un unico nome e fornisce un
insieme di servizi. Esso può registrare e modificare i suoi servizi e/o cercare
agenti che forniscano specifici servizi, può controllare il suo ciclo di vita e, in
particolare, comunicare con tutti gli altri peer. Gli agenti comunicano tramite lo
scambio di
messaggi asincrono, un modello di comunicazione quasi
universalmente
accettato
per
comunicazioni
tra
elementi
distribuiti
o,
comunque, debolmente accoppiati (per esempio tra entità eterogenee che non
sanno nulla l'una dell'altra). Per comunicare, un agente manda semplicemente
un messaggio alla destinazione. Gli agenti sono identificati da un nome e non vi
è dipendenza temporale tra gli agenti in comunicazione. Il sender ed il receiver
potrebbero non essere attivi allo stesso tempo. Il receiver potrebbe addirittura
non esistere (o comunque non esistere ancora) o potrebbe non essere
direttamente conosciuto dal sender che può specificare una semplice proprietà
(ad esempio “tutti gli agenti interessati al calcio”) come destinazione. Poiché gli
agenti si identificano l'un l'altro tramite il loro nome, il cambiamento “a caldo”
dei loro riferimenti è trasparente alle applicazioni. Nonostante questo tipo di
comunicazione, la sicurezza è ancora preservata perché Jade fornisce
meccanismi propri di autenticazione e verifica dei permessi assegnati agli
agenti,
alle
applicazioni
che
li
richiedono.
Quando
occorre,
perciò,
un'applicazione può verificare l'identità di chi ha inviato un messaggio e fatto
azioni che non era abilitato a fare (ad esempio un agente potrebbe essere
abilitato a ricevere messaggi da un altro agente “capo” ma non essere abilitato
a mandare ad esso messaggi). Tutti i messaggi scambiati tra gli agenti sono
inviati senza alcun impacchettamento, includendo solo le informazioni richieste
dallo strato di trasporto. Questo permette, fra l'altro, di crittare il contenuto di un
messaggio separatamente dall'impacchettamento. La struttura di un messaggio
è conforme al linguaggio ACL definito da FIPA ed include campi, come variabili
103
che indicano a quale contesto si riferisce il messaggio e timeout da attendere
prima che si possa ricevere una risposta, al fine di supportare interazioni
complesse
e
comunicazioni
parallele
multiple.
Per
meglio
supportare
l'implementazione di comunicazioni multiple, Jade fornisce un insieme di
skeleton di tipici modelli di interazione per eseguire specifici task, come
negoziazioni ed aste. Usando questi skeleton (implementati come classi
astratte Java), i programmatori possono liberarsi del carico di traffico con l'uso
di variabili di sincronizzazione, timeout, condizioni di errore, ed in generale, di
tutti quegli aspetti che non sono strettamente legati alla logica dell'applicazione.
Per facilitare la creazione e la manipolazione del contenuto dei messaggi, Jade
fornisce supporto per convertire automaticamente ad un formato utilizzabile per
lo scambio di contenuti (XML ed RDF sono supportati). Questo supporto è
integrato con alcuni tool per la creazione delle ontologie. Per aumentare la
scalabilità o anche venire incontro ad ambienti con risorse limitate, Jade
fornisce l'opportunità di eseguire task multipli paralleli all'interno dello stesso
thread Java. Diversi task elementari, come ad esempio quelli legati alla
comunicazione, potrebbero essere combinati per formare task strutturati più
complessi come macchine a stati finiti concorrenti.
Nell'ambiente J2SE (quello usato per questo lavoro di tesi), Jade supporta la
mobilità del codice e dello stato di esecuzione. Grazie a questo, un agente può
fermarsi su un host, migrare su un diverso host remoto (senza la necessità di
avere il codice dell'agente già installato sull'altro host), e riavviare la sua
esecuzione dal punto in cui era stata interrotta. Questa funzionalità permette,
ad esmpio, di distribuire il carico computazionale a run-time spostando gli agenti
verso macchine meno “cariche” senza alcun impatto sull'applicazione.
La piattaforma include anche un servizio di naming (assicurando che ogni
agente abbia un nome unico) ed un servizio di pagine gialle che può essere
104
distribuito tra host multipli. Un'altra caratteristica molto importante consiste nella
disponibilità di una suite molto ricca di tool grafici che supporta il debugging e le
fasi di gestione/monitoraggio del ciclo di vita dell'applicazione. Grazie a questi
tool è possibile controllare agenti in maniera remota, anche se già in
esecuzione: possono essere emulate le conversazioni tra agenti, possono
essere intercettati gli scambi di messaggi, possono essere monitorati i task e
può essere controllato il ciclo di vita.
Grazie alle funzionalità descritte, e particolarmente la possibilità di attivazione
da remoto, anche su terminali mobili, di task, messaggi, e nuovi agenti, Jade è
uno dei migliori strumenti, forse il migliore in assoluto, per supportare lo
sviluppo e l'esecuzione di applicazioni distribuite, intelligenti e proattive. Esso
ha rappresentato quindi la nostra scelta come framework per la gestione di
piattaforme ad agenti mobili.
Figura 4.3 : Architettura di Jade
105
4.4.2 Installazione del Globus Toolkit
Si è proceduto installando Java, il Framework per agenti mobili Jade, e il
Globus Toolkit 4.0. Sono stati installati inoltre numerosi pacchetti aggiuntivi e
compilatori necessari all' installazione di Globus, ma non è questo il luogo per
scendere così nel dettaglio e una trattazione più rigorosa sarà riportata in
Appendice A.
Qui ci limiteremo a descrivere come si è proceduto per l'installazione del Globus
Toolkit.
Per l'installazione sono stati seguiti i passi fondamentali indicati nel tutorial che
48
si trova sul sito della Globus Alliance . C'è tuttavia da fare una considerazione.
Poiché anche sul cluster Vega è stata eseguita un installazione di Globus e
poiché il Front-End virtuale è visto da Vega come se fosse una delle tante
macchine reali ad esso collegate, non è stato possibile eseguire l'installazione
di Globus come se si trattasse di una “prima installazione”. Questo considerato
anche che, come vedremo a breve, un'installazione Globus implica una
configurazione della sicurezza con certificati X.509. Non è stato quindi possibile
registrare un nuovo certificato, rilasciato da una Certification Authority,
direttamente su GlobFecod.
Si è dovuto procedere come per un'installazione su prima macchina fino alla
configurazione-compilazione-installazione dei sorgenti e, in seguito, seguire le
istruzioni di installazione su seconda macchina per gli aspetti che riguardano
sicurezza, GridFTP e Web Services.
In particolare, per quanto riguarda la sicurezza, si è dovuto generare un badge
temporale, della validità di 12 ore, che fa riferimento al certificato di sicurezza
X.509 custodito su Vega e rilasciato dalla CA. Per ottenerlo si è dovuto
contattare l'amministratore di sistema del cluster reale che ha dovuto
48 http://www.globus.org/toolkit/docs/4.0/admin/docbook/quickstart.html#q-intro
106
“controfirmare” la richiesta e registrarla.
4.4.2.1 Il funzionamento di Globus
Il cuore del funzionamento del Globus Toolkit è il Globus-Container, sul quale
sono pubblicati i servizi Grid disponibili. Nella Home deve essere presente
necessariamente un utente “globus” che è stato creato in fase di installazione e
che avrà i permessi di gestione del Container. Avere i permessi di gestione
vuole anche dire essere abilitato a pubblicare, o eliminare, nuovi servizi Grid.
Per farlo ha bisogno di avere a disposizione un file .gar che rappresenta il
servizio Grid precedentemente creato in qualche ambiente di sviluppo (come
vedremo, nel nostro caso si tratterà di Eclipse 3.2 con linguaggio Java e un
particolare plug-in per la creazione di Grid Services). I client che potranno
utilizzare i servizi avranno bisogno di generare il badge temporale di cui si è
parlato per poterne usufruire. Se non si dispone della passphrase esatta, non si
potranno utilizzare i Grid Services.
Va da sé che un utente che dall'esterno voglia utilizzare i Grid Services
pubblicati sul container di GlobFecod dovrà disporre di tale certificato o di un
qualche meccanismo di tunnelling che consenta di bypassare tale operazione.
4.5 Panoramica del nodo Grid
Abbiamo adesso tutti gli elementi necessari a comprendere come è fatto il
nostro Nodo Grid.
ll Nodo Grid è composto:
107
•
Da un’infrastruttura Grid implementata tramite il Globus
Toolkit ed installata nel frontend del cluster. Il Globus Toolkit
fornisce la tecnologia con cui accedere verso il mondo Grid
ed un container in cui vengono pubblicati i servizi che
offrono le interfacce per l’accesso alla piattaforma ad agenti
e per l’amministrazione del Nodo Grid. E'installato sul
frontend del cluster virtuale GlobFecod.
•
Dal Main Container di Jade posto sul frontend del cluster in
cui, come si diceva, vi è anche il container di Globus
Toolkit. Il Main Container è il componente fondamentale
della piattaforma ad agenti sviluppata con la tecnologia
Jade, tutti i container secondari della piattaforma fanno
riferimento al container centrale, il quale gestisce le
informazioni ed il ciclo di vita sia dei container sugli altri
nodi che degli agenti presenti sulla piattaforma. Inoltre il
Main Container di Jade contiene gli agenti AMS e DF, i quali
offrono i servizi di gestione dell’interna piattaforma ad
agenti del sistema.
•
Da un insieme di container Jade secondari installati sugli
altri nodi del cluster, ogni macchina può ospitare anche più
di un container (ciò vuol dire che anche su GlobFecod
possiamo trovare ulteriori container secondari oltre al
principale). Questi container secondari si collegano al Main
Container posto sul frontend, l’insieme di questi container
compreso quello principale forma la piattaforma ad agenti
del Nodo Grid (AP). Il collegamento tra i nodi nel cluster
108
avviene tramite una rete dati interna e dedicata, collegata
anche al frontend, solo quest’ultimo ha l’accesso anche
all’esterno tramite un secondo collegamento con la rete
Grid.
•
Da una serie di Grid Services implementati nel container di
Globus
Toolkit,
i
quali
forniscono
l’interfaccia
delle
funzionalità utilizzabili dagli utenti Grid, tramite cui possono
accedere
alla
piattaforma
ad
agenti,
chiedere
la
schedulazione di un’applicazione multi-agente ed eseguire
le operazioni per amministrare il Nodo Grid.
Il Main Container di Jade utilizza gli agenti AMS e DF per memorizzare lo stato
di esecuzione della piattaforma e le informazioni relative agli agenti
Vediamo il tutto sintetizzato dalla seguente figura:
109
Figura 4.4: Architettura ad alto livello di un nodo Grid
4.6 Come si generano i servizi Grid
Numerosi sono i metodi tramite i quali è possibile sviluppare nuovi Grid
Services. Per questo lavoro si è deciso di utilizzare un generatore automatico di
codice ed un noto plug-in della piattaforma Eclipse per lo sviluppo di Grid
Services.
In generale, dovendo sviluppare servizi che operino tramite gli agenti mobili, è
utile munirsi di un generatore automatico che possa facilmente creare il codice
110
standard degli agenti proxy a partire da un'interfaccia che il programmatore
dichiara. Il generatore utilizzato per questo lavoro è il WSAG (Web Services
Agent Gateway), che è l'implementazione del progetto WSAI (Web Services
Agent Integration) che permette l’integrazione tra agenti e Web Service.
Naturalmente sarà il programmatore a dover implementare la logica del servizio
e a scrivere il codice che dovrà essere eseguito dai vari agenti proxy. Una
spiegazione più dettagliata del procedimento è presente in appendice. Una
volta ottenuta l'infrastruttura degli agenti, bisogna procedere con lo sviluppo del
servizio Grid. Per farlo ci si è avvalsi, come si diceva precedentemente, del
49
plug-in per Eclipse MAGE GDT , sviluppato dall'Università di Marburg in
Germania. Si tratta di una utility per realizzare Grid
Services che devono essere pubblicati nel container di Globus Toolkit 4, esso
genera automaticamente l’implementazione del servizio seguendo lo schema di
50
programmazione proposto nel tutorial ufficiale di Globus . Con questo tool,
vengono generati automaticamente il codice del client e gli stubs del servizio ed
infine è possibile generare il file di estensione .gar che rappresenta il nostro
servizio completo e che andrà pubblicato direttamente sul Container Globus
installato sulla macchina che dovrà fonire il servizio. In appendice ci sarà una
panoramica dettagliata su come si crea un servizio Grid con il plug-in MAGE.
4.7 I servizi di gestione
Facciamo adesso una panoramica più dettagliata di quelli che sono i servizi di
base che vengono utilizzati per amministrare la piattaforma ad agenti presente
nel nodo Grid. Questi servizi, di cui una breve descrizione è stata già fatta nel
capitolo precedente, sono stati tutti testati sul Nodo Grid del cluster virtuale
49 http://mage.uni-marburg.de/trac/gdt/wiki
50 http://gdp.globus.org/gt4-tutorial/
111
(tramite la scrittura di opportuni client) e costituiscono la base fondamentale da
cui partire per lo sviluppo di servizi più complessi.
I servizi base sono:
•
Monitoraggio:
tramite
questo
servizio
è
possibile
esaminare lo stato della piattaforma ad agenti e delle
macchine che compongono la risorsa grid. Si possono
visualizzare la lista degli agenti mobili in esecuzione sulla
piattaforma, le informazioni sui singoli nodi e sullo stato di
esecuzione di uno specifico agente.
•
Amministrazione: tramite questo servizio si permette ad
un utente di gestire il funzionamento della piattaforma ad
agenti, ad esempio consente l’attivazione della piattaforma
o di un singolo container, e consente di effettuare varie
operazioni
sugli
agenti
(clonazione,
spostamento,
disattivazione).
•
Esecuzione: tramite questo servizio si può avviare
l'esecuzione di un agente mobile sulla piattaforma oppure
inviare un messaggio ad un agente.
•
sviluppo di nuovi agenti: tramite questo servizio si può
fare in modo di creare nuovi agenti in modo tale da poter
eseguire una nuova applicazione MAS all’interno del Nodo
Grid, oppure conoscere i servizi che vengono offerti
all’interno della piattaforma.
112
Figura 4.5: Diagramma UML delle classi per i servizi base
113
Vediamo ora le funzionalità messe a disposizione da ciascuno di questi servizi:
4.7.1 Il servizio di Monitoraggio
Il servizio di monitoraggio è utilizzato da chi deve effettuare delle operazioni di
supervisione sul Nodo Grid. I metodi che l’interfaccia mette a disposizione sono
utili per osservare la distribuzione del carico di lavoro tra i singoli nodi della
risorsa, in modo tale che l’utente possa decidere le opportune azioni da fare per
bilanciare il carico di lavoro tra le macchine ed evitare il sovraccarico di un
singolo nodo. La classe serviziGRID.monitoring.ServizioMonitoringImpl contiene
l’implementazione del Grid Service, la sua interfaccia fornisce le funzioni
seguenti:
•
listaAgenti() : restituisce la lista degli agenti presente nella
piattaforma Jade.
•
listaAgentContainer(nome del container) : restituisce la lista
degli agenti in esecuzione nel particolare container indicato
come parametro.
•
lista Container() : fornisce la lista dei container attivi nella
piattaforma ad agenti.
•
infoContainer(nome del container) : restituisce un insieme
di informazioni sul container indicato dal parametro di
ingresso.
•
cerca Agente(nome dell’agente) : restituisce il nome del
container in cui l’agente è attualmente in esecuzione.
•
leggi Errore() : restituisce una stringa in cui è indicato
l’ultimo fault che è avvenuto nel sistema.
114
4.7.2 Il servizio di Amministrazione
Questo servizio è di gran lunga il più importante in quanto consente agli utenti
di esercitare le funzioni di gestione del sistema. Ogni utente che assume il ruolo
di amministratore del sistema può utilizzare un insieme di operazioni tramite cui
gestire il funzionamento della piattaforma ad agenti. I metodi forniti dal Grid
Service sono rivolti sia alla configurazione della piattaforma (gestione dei singoli
nodi) sia alla gestione degli agenti in esecuzione sulla piattaforma. Un esempio
di utilizzo di questi servizi è quello del bilanciamento del carico di lavoro tra i
nodi della piattaforma ad agenti. Dopo aver controllato la disposizione degli
agenti mobili sui diversi nodi l’amministratore può utilizzare l’operazione che
sposta un agente da un nodo ad un altro, in questo modo può ridistribuire il
carico di lavoro in modo equilibrato tra le macchine del Nodo Grid. Come
vedremo in seguito, è possibile effettuare un'allocazione dinamica del carico di
lavoro avvalendosi di specifici strumenti. Il GridService è implementato nella
classe serviziGRID.administration.ServizioAdministratorImpl
e utilizza tre
Resource Properties (oltre alla proprietà che conserva il messaggio di errore):
configurazione, è un attributo di tipo String, contiene la configurazione di
default della piattaforma ad agenti installata sul Nodo Grid. Il valore di questa
variabile è utilizzato quando l’amministratore attiva la piattaforma sul nodo
utilizzando le impostazioni di default, la configurazione contiene l’insieme dei
container secondari della piattaforma, per ognuno di loro specifica il nome del
container e l’indirizzo della macchina fisica su cui il container sarà installato.
scriptMainContainer, è una stringa che contiene il percorso del file di script
usato per attivare il Main Container sul frontend del cluster.
115
scriptContainer, è l’oggetto String che contiene il percorso del file di script
utilizzato per installare un container secondario su una macchina del Nodo Grid.
I metodi presenti nell’interfaccia del servizio di amministrazione sono:
•
creaContainer(nome del container, host) : installa un
container di Jade sull’host indicato, il primo parametro è il
nome che viene assegnato al container, restituisce il valore
booleano true in caso di successo.
•
chiudeContainer(nome del container) : chiude il container
indicato dal nome, restituisce il valore booleano true in caso
di successo.
•
attivaPiattaforma(nome
della
piattaforma,
default,
configurazione) : attiva la piattaforma Jade sulle macchine
del cluster e assegna il nome indicato dal primo parametro,
questo metodo crea il Main Container sul frontend e i
container secondari su gli altri nodi. Se il valore default è
posto a true si utilizza la configurazione standard (presente
nella Resource Property configurazione) per creare e
distribuire i container tra i nodi del sistema, altrimenti
utilizza il terzo argomento del metodo, il quale è un oggetto
String
che
contiene
una
differente
configurazione.
Restituisce un valore boolean.
•
chiudiPiattaforma() : chiude la piattaforma ad agenti del
Nodo Grid, restituisce il valore booleano true in caso di
successo.
•
spostaAgente(nome dell’agente, nome del container) : il
116
metodo sposta l’agente (indicato dal suo nome) su un
container differente, che l’utente indica tramite il nome.
Restituisce un valore booleano.
•
clonaAgente(nome dell’agente, nome del container, nome
del clone) : crea il clone di un agente mobile, si tratta di un
nuovo agente ma con un nome diverso e posizionato
inizialmente nel container indicato dall’utente, il primo
parametro è il nome dell’agente da clonare. Restituisce un
valore booleano.
•
killAgente(nome dell’agente) : termina l’agente nome
tramite il suo nome, questa informazione è il parametro di
ingresso del metodo, restituisce il valore vero in caso di
successo.
•
cercaAgente(nome dell’agente) : restituisce il nome del
container in cui l’agente indicato è attualmente in
esecuzione, il parametro di ingresso è il nome dell’agente
mobile da cercare.
•
leggiErrore() : restituisce una stringa in cui è indicato
l’ultimo fault che è avvenuto nel sistema.
•
modificaConfigurazione(nuova configurazione):
assegna
una nuova configurazione di default.
•
visualizzaConfigurazione()
:
restituisce
l’attuale
configurazione di default del sistema, è un oggetto String.
•
modificaComandoMainContainer(file di script) : assegna il
percorso (compreso il nome) del nuovo file di script al
sistema, in questo modo quando l’utente attiva la
piattaforma ad agenti il Grid Service utilizza questo script
per eseguire il comando. Il parametro di ingresso è un
117
oggetto String.
•
visualizzaComandoMainContainer() : visualizza il percorso
del file di script attualmente utilizzato per attivare la
piattaforma ad agenti.
•
modificaComandoContainer(file di script) : assegna il
percorso di un nuovo file di script che crea i container
secondari, il parametro di ingresso è una stringa.
•
visualizzaComandoContainer() : visualizza il percorso del
file di script attualmente utilizzato per creare i container
secondari sulle macchine del cluster.
La configurazione della piattaforma è descritta tramite una stringa di testo (un
oggetto String), ogni container è indicato dal nome assegnato e dall’host su cui
deve essere installato, le due informazioni sono separate dal carattere ‘:’
mentre le descrizioni dei container sono separati da uno spazio all’interno della
stringa. L’host è rappresentato sia tramite il nome DNS che con il suo indirizzo
IP. Un esempio di configurazione è data dalla stringa:
“ container1:host1 container2:host2 container3:host3 container4:host4”
4.7.3 Il servizio di Esecuzione
Il servizio di esecuzione consente ad un utente Grid abilitato di poter eseguire la
propria applicazione multi-agente sulla piattaforma Jade del Nodo Grid. L’utente
utilizza il metodo che pone in esecuzione gli agenti mobili, in questo modo
l’utente può creare gli agenti che formano l’applicazione MAS, questi agenti si
distribuiscono sui nodi della piattaforma secondo una loro logica. Il GridServices
118
è implementato tramite la classe serviziGRID.user.ServizioUserImpl, la sua
interfaccia contiene le funzioni:
•
creaAgente(classe java, nome dell’agente, argomenti) :
crea un agente sulla piattaforma Jade, il primo parametro è
il nome della classe java che implementa il codice
dell’agente mobile, il secondo è il nome dell’agente e il
terzo parametro è l’elenco degli argomenti da dare
all’agente, il metodo restituisce un valore booleano.
•
inviaMessaggio(nome agente, contenuto del messaggio) :
invia un messaggio all’agente mobile in esecuzione
all’interno della piattaforma, il primo parametro è il nome
dell’agente destinatario, mentre il secondo è la stringa di
testo da inviare. Il metodo ritorna la risposta dell’agente
posta in un oggetto String.
•
inviaMessaggioFull(nome agente, contenuto, tipo richiesta,
tipo risposta, timeout) : anche questo metodo invia un
messaggio ad un agente mobile della piattaforma Jade, in
questo caso l’utente può decidere il tipo di messaggio da
inviare e quello da ricevere, oltre a settare il timeout. Il
valore restituito è una stringa che contiene la risposta
dell’agente.
4.7.4 Il servizio di Sviluppo
Tramite questo servizio un utente può aggiungere nuove classi java alla libreria
degli agenti, in modo tale che qualsiasi altro utente possa dare vita ad agenti
119
utilizzando le classi aggiunte tramite i metodi di questo servizio. Inoltre il
servizio
fornisce
alcuni
metodi
che
aiutano
lo
sviluppatore
durante
l’implementazione di un agente mobile. Tramite questi metodi il programmatore
può conoscere i servizi erogati dagli agenti che operano all’interno della
piattaforma ed il nome di questi agenti. Il GridService è implementato tramite la
classe serviziGRID.developer.ServizioDeveloperImpl, utilizza due Resource
Properties (oltre alla proprietà che conserva il messaggio di errore):
pathClassi : è un oggetto String che contiene il percorso della cartella in cui si
trovano le classi usate per creare gli agenti mobili all’interno della piattaforma.
pathAgenti : è la stringa che contiene il percorso della cartella dove sono
posti i file JAR degli agenti sviluppati dai programmatori. Jade utilizza un
meccanismo particolare per caricare le classi java che sono state create dopo
l’attivazione della piattaforma, il comando ha l’opzione
jade.Boot jade_core_management_AgentManagementService_agentspath
che specifica una cartella in cui ogni programmatore inserisce le classi java da
lui create, tutte le classi che sono utilizzate per creare un agente mobile devono
essere incluse nello stesso file JAR (compreso il percorso completo delle
cartelle che rispetta la struttura del package di queste classi), il nome del file
JAR è il nome completo della classe principale sostituendo i punti con gli
underscore,
ad
esempio
se
coffeeApp.agents.WaiterAgent,
la
il
classe
file
JAR
principale
deve
di
un
utilizzare
agente
il
è
nome
coffeeApp_agents_WaiterAgent.jar .
I metodi forniti dal servizio sono:
•
copiaClasse(flusso di byte, nome del file jar) : questo
metodo copia il file JAR, creato seguendo le specifiche
120
definite prima, nella cartella indicata dalla Resource
Property pathAgenti. Il contenuto del file è dato in ingresso
al metodo tramite un array di byte, il secondo argomento è il
nome da assegnare al file JAR. Il metodo restituisce un
valore booleano.
•
prelevaClasse(URI del file class) : l’utente può utilizzare i
file class presenti su un server web per eseguire un agente
mobile sulla piattaforma del Nodo Grid, il file class contiene
il codice che sarà utilizzato per creare l’agente. L’utente
indica l’URI del file class come parametro del metodo,
quest’ultimo preleva il file e lo copia nella cartella indicata
dalla Resource Property pathClassi. Il valore di ritorno del
metodo è una variabile booleana.
•
creaAgente(classe java, nome dell’agente, argomenti,
nome del container) : crea un agente sulla piattaforma
Jade, questo metodo è analogo al creaAgente() presente
nel servizio di esecuzione, aggiunge un quarto parametro
che indica il container in cui l’agente inizia la sua
esecuzione, il metodo restituisce un valore booleano.
•
serviziAgente(nome dell’agente) : restituisce l’elenco dei
servizi offerti dall’agente specificato.
•
trovaServizio(tipo di servizio) : restituisce l’elenco degli
agenti che offrono il tipo di servizio indicato.
•
modificaPathAgenti(nuovo pathAgenti) : assegna un nuovo
valore alla Resource Property pathAgenti.
•
visualizzaPathAgenti() : ritorna il valore della risorsa
pathAgenti.
•
modificaPathClassi(nuovo pathClassi) : assegna un nuovo
121
valore alla Resource Property pathClassi.
•
visualizzaPathClassi() : ritorna il valore della risorsa
pathClassi.
Dopo aver configurato il cluster, il passo successivo è stato quello di testare su
di esso il corretto funzionamento di questi servizi e di tutte le funzionalità da
essi offerte. E' ovvia l'importanza della verifica del funzionamento se si pensa
che questi servizi costituiscono l'ossatura base per lo sviluppo di servizi più
complessi. Ad esempio, testare che un agente è libero di spostarsi tra i vari host
del cluster garantisce poi la possibilità di delegare i più svariati tipi di job agli
agenti sapendo che la funzionalità base di “movimento” è garantita. Con un
infrastruttura del genere, e grazie anche ai servizi che verranno decritti più
avanti in questo capitolo, sarà possibile pensare di creare qualunque tipo di
servizio complesso.
Il codice dei client sviluppati per il test delle funzionalità è riportato in appendice.
Qui ci limiteremo a mostrare qualche screen-shot che mostra il funzionamento
dei vari metodi.
122
Figura 4.6: Test del servizio di Amministrazione
123
Figura 4.7: Test del servizio di Monitoraggio
Figura 4.8: Test del servizio Utente
124
4.8 Il servizio di Mobilità inter piattaforma
Sottolineamo il fatto che Jade utilizza meccanismi differenti per lo scambio di
messaggi tra agenti, a seconda della loro posizione reciproca:
•
se il destinatario si trova sullo stesso container, l’oggetto Java
rappresentante il messaggio ACL gli viene passato direttamente,
come
un
oggetto-evento,
senza
alcuna
traduzione.
E’
sicuramente il sistema più veloce;
•
se il destinatario si trova sulla stessa piattaforma ma su di un
container differente, viene utilizzato RMI per l’invio del messaggio
ACL. RMI effettua una serializzazione degli oggetti e li
ricostruisce in maniera trasparente all’utente, per cui l’agente
riceve anche in questo caso un oggetto Java rappresentante il
messaggio .
•
se il destinatario si trova su di una piattaforma differente, allora
viene invocato il protocollo inter-piattaforma (HTTP, IIOP o WAP).
Questo implica la traduzione dell’oggetto ACL in una stringa di
caratteri. Dal lato del destinatario, l’ACC (Agent Communication
Channel) trasforma la stringa di nuovo in un messaggio ACL, e lo
recapita tramite RMI o attraverso un evento Java. E’ il
meccanismo più dispendioso in termini di tempo e risorse.
125
Figura 4.9: I possibili scenari relativi alla mobilità
Riassumendo possiamo dire che in Jade la comunicazione può essere di due
tipi: intra-piattaforma e inter-piattaforma.
La comunicazione intra-piattaforma ha luogo quando due o più agenti che
risiedono
nella
stessa
piattaforma
desiderano
comunicare.
Questa
comunicazione avviene per mezzo del protocollo Jade IMTP (Internal Message
Transport Protocol). Le tecniche IMTP correntemente usate da Jade sono il
passaggio di eventi per la comunicazione intra-container e RMI (Remote
Method Invocation) per la comunicazione inter-container.
La comunicazione inter-piattaforma avviene, come si diceva, per mezzo
dell'ACC (Agent Communication Channel) che può usare un certo numero di
MTPs per permettere lo scambio dei messaggi tra agenti su piattaforme
esterne.
126
Nel nostro caso, la mobilità inter-piattaforma è di grande interesse. Avendo già
testato l'infrastruttura che consente agli agenti di spostarsi da un container
all'altro sulla piattaforma Jade (container che possono naturalmente risiedere su
macchine differenti), diventa fondamentale fare in modo che gli agenti possano
spostarsi da una piattaforma ad un'altra. Avere due piattaforme, ricordiamo,
vuol dire avere due Main-Container, quindi due AMS e due DF. In pratica due
piattaforme Jade totalmente separate. Questo ci porta alla possibilità che
queste due AP non solo possano risiedere all''interno dello stesso nodo Grid,
ma anche su nodi Grid differenti. Testare la mobilità interpiattaforma apre la
porta alla mobilità inter-nodo Grid. Avendo descritto nel primo capitolo le
caratteristiche dei sistemi Grid e la loro potenzialmente illimitata estensione
geografica, ci si rende conto di quanto importante sia la mobilità inter-nodo.
Per la mobilità inter-piattaforma si è studiato e testato un servizio di mobilità
51
sviluppato in un altro lavoro di tesi , che, facendo uso di un particolare MTP
modificato, utilizza un agente simbolico che non fa altro che attivarsi su una
piattaforma Jade e migrare sull'altra. Essendo sviluppato come un servizio Grid,
anche per l'utilizzo del progetto Mobilità e necessario che, perché l'agente
possa attivarsi e migrare, l'utente che fa partire l'agente disponga di un
certificato valido.
Per poter funzionare, quindi, bisogna avere pubblicato il servizio mobilità sul
container Globus che deve offrirlo (seguendo la procedura descritta in
Appendice B), esportare nel Classpath della macchina su cui è installato
Globus il file .jar che contiene l'MTP modificato e lanciare su di essa la
piattaforma Jade. Sulla macchina dalla quale si vuol far migrare l'agente
bisognerà innanzitutto possedere un certificato valido, poi si dovrà far partire
una piattaforma Jade sulla quale dovrà essere installato l'MTP modificato
51 **
127
(ricordiamo che Jade prevede la possibilità che ci possano essere più MTP
installati) ed infine si dovrà lanciare un agente nella cui action non ci sarà altro
che il comando di migrazione.
Per poter effettuare il test di questo servizio sul cluster virtuale, non avendo a
disposizione l'X-Server e quindi la gui di Jade, è stato effettuato il lancio da linea
di comando. In particolare è stata attivata la piattaforma principale (quella
risiedente nel nostro caso su GlobFeCod) con il comando:
java jade.Boot -port 11099 -services
jade.core.mobility.AgentMobilityService\;jade.core.migration.InterPlatformMobiliy
Service
e la secondaria, ovvero quella da cui far partire l'agente, con il comando:
java jade.Boot -port 11099 -services
jade.core.mobility.AgentMobilityService\;jade.core.migration.InterPlatformMobilit
yService -mtp
"jade.mtp.myhttp.MessageTransportProtocol(http://192.168.1.20:7779/acc)"
agentemigratore:agenteMigra.Migra
Laddove si dispone di un certificato valido.
Il comando “-mtp” serve ad installare da linea di comando il nuovo mtp
all'indirizzo sul quale ci troviamo e sulla porta 7779.
Il comando agentemigratore:agenteMigra.Migra fa partire l'agente di nome
Migra.java che si trova nel package agenteMigra mentre “agentemigratore” è il
nome che è stato assegnato all'agente.
Il comando
128
“-services
jade.core.mobility.AgentMobilityService\;jade.core.migration.InterPlatformMobilit
yService”, che ritroviamo entrambe le volte, serve ad avviare le piattaforme
utilizzando il servizio “migration” dell'IPMS (Inter Platform Mobility Service), il
cui file migration.jar era stato precedentemente anch'esso esportato nel
Classpath (di entrambe le macchine coinvolte).
4.9 Condor
Le attuali piattaforme Grid non forniscono uno scheduler che effettua la
schedulazione di jobs direttamente in un ambito distribuito geograficamente,
tipico del Grid, ma utilizzano quelli forniti dai SO dell’host.
Condor
52
è un sistema specializzato di gestione del carico di lavoro per
applicazioni che richiedono grande utilizzo di risorse di carico. Come altri
sistemi batch, Condor fornisce un meccanismo di coda dei job, politiche di
scheduling, schemi di priorità, monitoring delle risorse e gestione delle stesse.
Gli utenti possono fare il submit dei job da eseguire, Condor li pone in una
coda, sceglie quando e dove eseguirli basandosi su una certa politica, monitora
i loro progressi ed informa l'utente del loro completamento.
Sebbene fornisca funzionalità molto simili a quelle di molti altri sistemi batch
tradizionali, l'architettura di Condor permette ad esso di riuscire dove i sistemi di
scheduling tradizionali falliscono. Condor può essere usato per gestire un
cluster di nodi di calcolo dedicati. In più, i suoi meccanismi gli consentono di
sfruttare pienamente le risorse di calcolo sprecate dalle varie workstation
durante il loro operare. Condor può rilevare se una macchina non è più
disponibile. Grande caratteristica di Condor è quella di poter produrre dei
52 http://www.cs.wisc.edu/condor/description.html
129
checkpoint (e di salvare quindi lo stato) in maniera totalmente trasparente.
Sempre in maniera trasparente può far migrare un job su un'altra macchina che
diventa disponibile alleggerendo così il carico di lavoro della macchina su cui il
job si trovava inizialmente. Condor non necessita per forza che ci sia il File
System distribuito. Se non c'è è lo stesso Condor che può trasferire i vari dati a
nome dell'utente o può trasferire direttamente le richieste di I/O dei job
direttamente alla macchina interessata.
In pratica Condor può essere usato per combinare tutte le risorse
computazionali di una data organizzazione in un'unica risorsa.
E quindi chiara l'importanza di questo sistema, Condor può diventare uno
strumento molto potente per la gestione dei job in un Grid System. Una delle
caratteristiche che lo fa diventare molto appetibile è l'allocazione dinamica del
carico. Questa caratteristica consente di delegare a Condor la gestione delle
risorse di calcolo rendendola totalmente trasparente all'utente. Utilizzando
Condor, si delega ad esso la capacità di decidere quali job eseguire prima e,
soprattutto, dove eseguirli in base a determinate politiche di gestione delle
risorse.
In questo lavoro, si è anche pensato di integrare un servizio di allocazione
dinamica del carico basato su Condor, il cui sviluppo è stato oggetto di un altro
lavoro di tesi. Si è quindi cercato di simulare con il cluster virtuale un ambiente
ideale in cui Condor decide a quali nodi schedulare i vari job.
4.9.1 Il servizio di sottomissione agente a Condor
Si è proceduto, innanzitutto, con l'installazione di Condor sul cluster. Per farlo
sono state seguite le istruzioni riportate sul sito, il metodo di installazione è stato
quello che utilizza i codici sorgenti. La versione di Condor utilizzata è stata la
130
7.2.4.
Il servizio che è stato testato, con tutti i margini di miglioramento del caso, è un
semplice servizio che sottomette un agente mobile a Condor, il quale, a sua
volta, attiverà un container jade su una delle macchine del suo “pool” (quelle
del cluster virtuale) secondo delle politiche ben specifiche.
Condor, per lavorare, fa uso di un determinato numero di comandi lanciabili
53
dalla shell, per l'elenco completo si rimanda il lettore al sito di Condor .
Per poterlo gestire da remoto, bisogna utilizzare dei file eseguibili preimpostati
su determinati comandi.
In pratica, le entità in gioco sono le seguenti:
•
Un servizio Grid per la sottomissione dell'agente a Condor
•
Un file eseguibile sh con all'interno il comando “condor_submit”
per sottomettere un agente a Condor
•
Un file .class che rappresenta il nostro agente
•
Un file di estensione .cmd che occorre a Condor per stabilire le
policies in base alle quali sottomettere il job
Per poter essere utilizzato, il servizio Grid (che è costituito da un semplice
metodo “sottometti”) ha bisogno di essere invocato da un client. La struttura
base del client, come sempre, si ottiene con MAGE. Compito del
programmatore è poi quello di scrivere il main per poter testare il metodo.
Il file che il metodo sottometti va ad eseguire è il file .sh con all'interno il
comando “condor_submit Agente.cmd”. Nel file .cmd ci sono tutti i parametri di
53 http://www.cs.wisc.edu/condor/manual/index.html
131
funzionamento di Condor, nonché lo specifico comando che avvia Jade e gli
attiva sopra un agente basandosi sul file .class. Una volta che viene richiamato
il client (avendo a disposizione un certificato valido), Condor provvede da solo
ad attivare il container Jade su cui parte l'agente. Il test è servito a capire che
Condor lascia spazio a moltissime potenzialità. Scrivendo opportuni file .cmd si
può stabilire come Condor debba avviare automaticamente tutta la struttura.
Inoltre, i comandi di Condor consentono di gestire agevolmente il carico di
lavoro sui singoli nodi in base a politiche predefinite.
Nel tool di gestione della Virtual Organization, che vedremo nel prossimo
capitolo, sono stati integrati tutti i suddetti servizi testati sul cluster virtuale
progettato in modo da poterli gestire da remoto.
132
Capitolo 5
Interfaccia di gestione di una Virtual Organization
5.1 Introduzione
Avendo configurato il cluster virtuale e avendo testato una serie di servizi Grid
su di esso, si è pensato di sviluppare un' interfaccia grafica che possa gestire
una Virtual Organization. Questo vuol dire che tale interfaccia dovrà essere
capace di gestire o creare nodi Grid all'interno di un'organizzazione secondo i
criteri visti nel precedente capitolo. In quest'interfaccia sono stati integrati tutti i
servizi che abbiamo visto in precedenza. Per effettuare i test si è fatto
riferimento al cluster virtuale configurato.
5.2 Descrizione delle operazioni svolte
Per lo sviluppo è stata effettuata una re-ingegnerizzazione di un'interfaccia
realizzata in un altro lavoro di tesi che aveva lo scopo di gestire i servizi base di
un singolo nodo Grid preimpostato. Quest'interfaccia è stata realizzata in
linguaggio Java, in particolare facendo uso delle librerie Java Swing per la
progettazione delle finestre.
Quello che si è fatto in questo ambito è stato estendere le finestre pre-esistentie
133
crearne di nuove al fine di integrare i nuovi servizi.Più nello specifico è stato
studiato e modificato il codice in modo da estendere le nuove funzionalità.
Tra le modifiche apportate abbiamo la capacità di gestire più nodi Grid
contemporaneamente nell'ambito di una Virtual Organization e di aggiungerne
nuovi in ogni momento. Inoltre è stata aggiunta una funzionalità che consente di
visualizzare dinamicamente le modifiche ai nodi Grid che, di volta in volta,
vengono effettuate.
5.3 L'Interfaccia grafica
L' interfaccia è composta da una serie di classi java, alcune di queste sono le
classi che implementano i client dei servizi Grid che sono stati integrati, alcune
sono le classi che gestiscono gli eventi che avvengono nell'interfaccia ed altre
sono quelle che implementano la parte grafica dell'interfaccia stessa.
Elenco classi:
•
Classi che implementano le finestre:
GestioneVO,
Window,
Root_Window,
HomePage,
Host_Window,
Container_Window
•
Classi che implementano gli eventi:
GridEntity,
MouseListener, Listener_inf
•
Classi che implementano i client dei servizi di gestione:
GridAdministratorClient,
GridMonitoringClient,
GridDeveloperClient, GridUserClient.
134
5.4 Funzionamento
Per quanto riguarda la gestione della Virtual Organization, il cuore
dell'interfaccia è l'implementazione della classe albero Jtree. La struttura di un
nodo Grid è infatti rappresentabile in maniera gerarchica, per cui l'albero è la
scelta più ovvia.
In pratica, se la Virtual Organization è la radice dell'albero, ad un primo livello
avremo i vari nodi Grid che sono attivi in quest'organizzazione. Ad un secondo
livello, avremo le varie piattaforme Jade che girano sul nodo Grid. Andando
avanti coi livelli troveremo i container che girano sulla singola piattaforma. Infine
troveremo gli agenti che girano sul singolo container.
L'interfaccia sviluppata, quindi, nella pratica gestisce la struttura ad albero
Virtual Organization-->NodoGrid-->AP-->Container-->agente
fornendo le funzionalità base di creazione e manipolazione dei container e degli
agenti.
5.4.1 Gestione dinamica dei nodi Grid
Il primo limite riscontrato è che l'applicazione originaria poteva essere utilizzata
per gestire uno specifico nodo Grid che doveva essere dichiarato nel codice,
quindi una volta effettuata la compilazione, il nodo non era più modificabile.
Il primo obiettivo quindi, è stato quello di fare in modo che l'interfaccia
accettasse in ingresso gli indirizzi fisici dei front-end su cui attivare i nodi Grid.
L'interfaccia, poi, effettua la connessione con ognuno di questi nodi e può quindi
gestire, per ognuno di essi, la creazione di piattaforme, container ed agenti.
Per poter funzionare, la piattaforma dovrà essere lanciata da un utente che ha i
certificati validi per ognuno dei nodi Grid che vuol andare a creare e gestire.
135
5.4.2 Il test di funzionamento
Per poter testare l'interfaccia si è fatto uso del cluster virtuale creato. Poiché, al
momento di scrittura di questo lavoro, il cluster virtuale non è stato dotato di un
indirizzo pubblico (per averlo, il Front-End virtuale dovrebbe risiedere sul FrontEnd reale Vega e non su un suo nodo), l'unico modo di testare il corretto
funzionamento dell'interfaccia dall'esterno è stato quello di spostarla fisicamente
su Vega e lanciarla da lì. Perché ciò fosse possibile è stato necessario portare
su Vega anche le librerie necessarie al funzionamento dell'interfaccia e che
erano state importate in fase di progetto. E' stato necessario, poi, importare
queste librerie nel CLASSPATH di Vega. Per farlo più agevolmente sono stati
scritti due file sh. Infine è importante ricordare che l'utente che vuole lanciare
l'interfaccia dall'esterno necessita di un certificato valido per ogni Nodo Grid che
vuole andare a gestire. Nel nostro caso questo non è stato un problema in
quanto lo stesso cluster virtuale è a sua volta visto come un singolo nodo
computazionale dal Nodo Grid di Vega ed i certificati sono gli stessi (come
descritto anche in Appendice A).
Il test è stato effettuato per un singolo Nodo Grid ma, poiché il codice per la
creazione dei vari nodi Grid sull'albero della Virtual Organization è ciclico è
facilmente ipotizzabile che funzionando per uno funzionerà per tutti i nodo Grid,
a patto di soddisfare i requisiti appena indicati.
L'applicazione si apre con la
Figura 5.1: HomePage
136
La pagina di avvio di una VO ha, invece, l'aspetto seguente:
Figura 5.2: Gestione VO
In questa finestra, è possibile inserire una serie di indirizzi, separati da spazi o,
come nel nostro caso, i nomi di dominio del FrontEnd su cui risiede il Container
Grid. Al momento di dare l'OK, questi indirizzi vengono presi e viene creato
l'albero base. Viene creato un nodo radice di nome “Virtual Organization” e ad
esso vengono aggiunti tanti nodi figli quanti sono gli indirizzi immessi nell'area
testo.
Convenzionalmente, ogni nodo prende il nome di “NodoGrid” seguito
dall'indirizzo che è stato immesso. La situazione è descritta nella figura
seguente:
137
Figura 5.3: Struttura ad Albero
Per poter funzionare in questo modo, gli indirizzi immessi vengono salvati in un
file temporaneo. Successivamente vengono ripresi uno ad uno e viene aggiunto
ciclicamente un nuovo nodo nodo alla radice per ogni indirizzo ricevuto. In
Appendice D c'è la descrizione dettagliata del funzionamento del meccanismo e
del codice.
Queste operazioni avvengono nella classe window.java.
Questa finestra presenta un doppio pannello. Nel primo pannello abbiamo la
rappresentazione grafica dell'albero ed un'area relativa alle informazioni legate
all'elemento selezionato. Nel secondo pannello abbiamo la possibilità di
monitorare un particolare nodo. Anche in questo caso è stata apportata una
modifica all'interfaccia originale in modo da poter selezionare il nodo da
monitorare (che prima era predefinito nei sorgenti).
138
Figura 5.5: Il pannello principale della finestra window.java
Figura 5.6: il pannello secondario della finestra window.java
139
L'approccio utilizzato per la gestione delle azioni sulle finestre è stato quello
delle classi interne. Questo vuol dire che le azioni dei bottoni sono gestite
direttamente con delle classi all'interno della classe grafica. Esistono, però, tre
classi che gestiscono particolari tipi di evento: la classe MouseListener, la
classe GridEntity e la classe Listener_Inf.
•
La classe MouseListener è la classe associata ad un evento del
Mouse. In pratica occorre catturare l'evento “pressione tasto
destro” del mouse sull'oggetto Jtree che rappresenta la nostra VO.
Utilizzando la classe GridEntity, viene riconosciuto il livello
dell'albero
e
viene
attivata
la
finestra
adatta
a
gestire
l'applicazione. Anche in questo caso sono state fatte modifiche al
codice dell'interfaccia di base e sono descritte in appendice.
Queste modifiche riguardano il fatto che ogni elemento dei
sottolivelli dell'albero deve essere in grado di capire a quale Nodo
Grid fa riferimento e deve essere in grado di recuperare l'indirizzo
del FE di questo nodo.
•
La classe GridEntity che assegna ai nodi dell'albero un livello. In
particolare abbiamo il livello ROOT associato ai Nodi Grid, il livello
HOST associato alle piattaforme Jade attive, il livello CONTAINER
associato ai container attivi sulle singole piattaforme ed infine il
livello agente associato ai singoli agenti che girano sui container.
•
La classe Listener_Inf che è associata ad un evento pressione
di un pulsante sull'albero, riconosce, tramite GridEntity, il livello e
fa comparire in una specifica area di testo le possibili azioni da
compiere.
140
Per quanto riguarda i servizi gestione di base esaminati nel precedente capitolo,
essi vengono forniti in maniera analoga a quanto accadeva nei test-client
sviluppati ad hoc (e riportati in appendice). L'interfaccia, infatti, crea istanze dei
client che abbiamo esaminato ed applica su esse i metodi forniti dall'interfaccia
del servizio in base alle specifiche richieste dell'utente.
Come dicevamo, l'albero dei nodi viene creato immediatamente dopo la
dichiarazione degli indirizzi. Per l'effettiva gestione, però, c'è bisogno di avviare
su di essi almeno una piattaforma Jade (che, ricordiamo, ha attivo un MainContainer di default).
Per effettuare questa operazione, nel momento in cui si va a cliccare con il
pulsante destro sul nodo Grid di interesse, per le procedure descritte poc'anzi
viene attivata una finestra (root_window.java) in cui ci sono due possibilità:
•
Attivare una nuova piattaforma ad agenti sul nodo
•
Attivare una piattaforma ad agenti sul nodo specificandone la
configurazione
La prima possibilità è quella di cui stavamo parlando. In pratica, si va a digitare
il nome della piattaforma e automaticamente, nel momento in cui si va a
premere il bottone, viene attivato un blocco di codice (mediante una classe
interna ActionListener) che crea un istanza di GridAdministratorClient e
richiama su di essa il metodo attivaPiattaforma visto nel capitolo 4.
All'istanza di GridAdministratorClient viene passata la stringa che rappresenta
l'indirizzo del FE del nodo Grid, la porta ed il servizio Grid che esso eroga. Per
poter ottenere l'indirizzo è stato modificato il costruttore della classe, a cui
l'indirizzo viene passato sotto forma di stringa al momento della creazione
dell'oggetto root_window.
141
Figura 5.7: Il Menù Nodo Grid della root_window.java
La seconda possibilità è quella di specificare una differente configurazione dei
container secondari attivati automaticamente alla partenza. Il client si avvale del
metodo
modificaConfigurazione()
del
servizio
di
Administration.
La
configurazione di default è convenzionalmente posta a null. La sintassi della
configurazione è la stessa che abbiamo visto nel capitolo precedente. Si
specificano i container e gli indirizzi dei nodi sui quali questi devono essere
attivati, ed il servizio di amministrazione posto sul Container Grid provvederà ad
attivarli. E' chiaro che questo approccio prevede la conoscenza, da parte
dell'utente, dei vari indirizzi locali (o degli hostname) dei nodi del cluster virtuale.
In questa fase, la struttura originaria dell'applicazione è stata pesantemente
modificata.
Si è infatti riscontrato che, con l'applicazione originaria per la gestione del
singolo nodo, non era possibile visualizzare sull'albero i vari sotto-nodi della
piattaforma attivata. Sono state fatte modifiche al codice in modo da poter
142
sfruttare i metodi offerti dal servizio di Monitoring per esplorare la piattaforma
appena attivata e visualizzare a video tutti i suoi sotto-elementi, a partire dal
Main-Container, per arrivare ai singoli agenti.
Inoltre si è riscontrato che non era previsto, se non in alcuni specifici casi, il
refresh dell'albero. E' stata effettuata una modifica a tutti i costruttori delle varie
classi che possono operare modifiche all'albero in modo da passar loro
un'istanza dello stesso sulla quale applicare il metodo repaint() alla fine del
blocco di modifiche.
Come la finestra root_window, esistono altre tre finestre che gestiscono gli
ulteriori tre livelli della classe GridEntity associati all'albero. Abbiamo le classi
host_window,
container_window
ed
agent_window
per
la
gestione,
rispettivamente, delle piattaforme, dei container e degli agenti.
La host_window, di cui uno screenshot è riportato nella figura che segue,
consente di gestire la piattaforma ad agenti, quindi ne consente la chiusura o
l'attivazione di un nuovo container secondario.
Figura 5.8: Il menù piattaforma della host_window.java
143
La container_window consente di gestire un container. Quindi offre la possibilità
di chiuderlo o di attivare su di esso un nuovo agente a partire da una classe che
verrà poi posta in un file .jar messo nel “path agenti” secondo quanto già
definito per il servizio di development.
Figura 5.9: Il Menù Container di container_window.java
La agent_window, infine, serve a gestire i singoli agenti. Consente, quindi, di
gestire le funzionalità offerte dall'interfaccia del servizio di Amministrazione
144
Conclusioni e sviluppi futuri
Questo lavoro è servito a conoscere, a livello teorico e pratico, la tecnologia
Grid. Si è appreso quanto attualmente si sta facendo per migliorare questi
sistemi e quali sono i prossimi obiettivi che questa tecnologia si è prefissa di
raggiungere.
E' stato creato e configurato un cluster virtuale di macchine su modello di un
cluster reale. Il funzionamento di questo cluster virtuale è del tutto analogo al
funzionamento del reale. Su questo cluster sono stati configurati e adattati
diversi servizi che, insieme, costituiscono un'infrastruttura sulla quale sviluppare
applicazioni Grid più complesse. Sono stati inseriti servizi per la creazioni di
agenti, per la mobilità, per il monitoraggio del nodo Grid ed è stato integrato e
testato uno scheduler per la gestione del carico di lavoro.
E' stata creata, infine, un'interfaccia grafica per la gestione da remoto di questi
servizi. Quest'interfaccia, in realtà, può gestire una Virtual Organization e quindi
più nodi Grid parallelamente.
Il lavoro svolto apre le porte a numerosi sviluppi futuri come l'implementazione
di qualunque tipo di applicazione Grid basata su quest'infrastruttura.
E' certamente possibile individuare un paio di passi da compiere nell'immediato
futuro.
Un primo obiettivo è sicuramente quello di integrare il servizio di mobilità interpiattaforma testato, all'interno dell'interfaccia del servizio di amministrazione.
Attualmente, come analizzato nel capitolo 4, il servizio di mobilità è stato testato
attivando due piattaforme Jade e lanciando un agente su una di esse che ha lo
specifico scopo di migrare sull'altra piattaforma. Questo meccanismo, cosi
com'è, non è applicabile ad ogni tipo di agente come invece avviene per lo
spostamento da un container all'altro. Quello che bisogna fare è creare un
nuovo metodo sull'interfaccia del servizio di amministrazione ed un nuovo
agente proxy che asserva a questa funzione (per esempio potrebbe essere
145
“spostaAgentePiattaforma(nomeAgente, porto)”). Una volta creato questo
metodo, la procedura è sempre la stessa: attivare due piattaforme Jade,
installare su entrambe l'MTP modificato e applicare il metodo di spostamento
all'agente. Il metodo spostamento dovrà interrogare l'AMS, ottenere l'id della
piattaforma e migrare su essa (il porto gli viene passato come parametro).
L'interfaccia grafica è stata già predisposta per accogliere questa funzionalità,
quindi, una volta implementata, non si dovrà fare altro che creare, all'interno
dell'Action Listener predisposto, un'istanza di GridAdministratorClient sulla
quale applicare il metodo spostaAgentePiattaforma.
Un secondo obiettivo è quello di migliorare il funzionamento di Condor, che è
stato installato e configurato ma di cui non sono state sfruttate appieno le
potenzialità. Si può ad esempio pensare di integrare sull'interfaccia grafica un
pannello che consenta la gestione da remoto di tutti i comandi di condor,
predisponendo sul nodo Grid dei file sh sviluppati “ad hoc”
In allegato a questa tesi, è fornito tutto il software installato sul Nodo Grid.
146
Appendice A
Configurazione del cluster virtuale
A1 Immagini delle macchine
Il cluster virtuale è costituito da una serie di file immagine che vengono gestiti tramite la
tecnologia Xen. Xen consente una completa emulazione hardware senza andare a
ridurre in modo drastico le risorse del sistema, emulando sistemi operativi diversi tra
loro. Esso non mira a creare un'emulazione dell'hardware di un generico computer x86,
ma piuttosto di regolare e controllare l'accesso alle risorse fisiche della macchina da
parte delle varie istanze delle macchine virtuali. Un processo che va sotto il nome di
paravirtualizzazione.
Per una trattazione specifica su Xen, sul montaggio delle macchine virtuali tramite file
system NFS e sulla creazione di file di configurazione si rimanda il lettore al lavoro di
tesi svolto da Raffaele Lettiero.
Ci limiteremo, per quanto riguarda la configurazione delle immagini, a dire che esse
sono costituite da file di estensione .img. Nello specifico abbiamo i file :
FE-Derosa.img
centos_slave1.4-3.img
centos_slave2.4-3.img
centos_slave3.4-3.img
Di cui il primo rappresenta il front-end virtuale globfecod e gli altri sono slave 1,2 e3.
Queste immagini possono trovarsi all'interno di uno dei tanti nodi del cluster reale,
assicurandosi che siano su partizioni stabili, onde evitare che un calo di alimentazione
147
possa cancellarle definitivamente.
Abbiamo poi i file di configurazione che occorrono a Xen al momento del montaggio
delle immagini e sono:
derosa­fe.cfg ­ derosa­s1.cfg ­ derosa­s2.cfg ­ derosa­s3.cfg
Il file immagine derosa-fe.cfg è il file di configurazione del Front-End ed è fatto in
questa maniera:
kernel = "/state/partition1/vmlinuz­2.6­xen"
memory = 512
name = "GlobFEcod"
vif = [ 'bridge=xenbr.eth0','bridge=xenbr.eth0' ]
disk = ['file:/state/partition1/FE­Derosa.img,sda1,w']
root = "/dev/sda1 ro"
In cui notiamo la prima riga che ci indica il kernel che verrà caricato, la seconda ci
indica il quantitativo di memoria RAM che andremo ad assegnare. E' sconsigliato, per il
FE, usare valori inferiori a 512 MB in quanto il Container di Globus richiede un certo
quantitativo di memoria per girare. E' comunque inutile aumentare troppo la RAM
considerato che sul FE non vi è alcun tipo di X-Server e quindi nessuna interfaccia
grafica. Il terzo parametro è il nome che questa macchina assumerà nel dominio.
Questo è il nome esterno visto dal lato del cluster reale e si differenzia dal nome
interno del dominio che ha, per le nostre applicazioni, un'importanza ben più
fondamentale.
Gli altri parametri sono standard per la configurazione, in particolare il quarto consente
di montare il disco del FE su sda1.
Analogamente questo è il file di configurazione di uno slave:
kernel = "/state/partition1/vmlinuz­2.6­xen"
memory = 128
name = "GlobS1cod"
vif = [ 'bridge=xenbr.eth0' ]
disk = ['file:/state/partition1/centos_slave1.4­3.img,sda1,w']
root = "/dev/sda1 ro"
148
Notiamo alla terza riga che uno slave ha una sola interfaccia di rete a differenza del FE
che ne ha due, una lato cluster reale, l'altra lato cluster virtuale.
Per poter lanciare questi file immagine è necessario avere i permessi da superutente
(sudo) nella cartella in cui li abbiamo messi. Questo per poter lanciare il comando xm
di Xen.
Per farli partire bisogna usare quindi i comandi:
sudo /usr/sbin/xm create derosa­fe.cfg
sudo /usr/sbin/xm create derosa­s1.cfg
sudo /usr/sbin/xm create derosa­s2.cfg
sudo /usr/sbin/xm create derosa­s3.cfg
Bisogna attendere un po' tra un comando e l'altro perché dobbiamo dare ad ogni
macchina il tempo di avviarsi e montare con NFS la cartella home.
Importante: una volta avviato il derosa-fe, ovvero il FE virtuale, bisogna innanzitutto
accedervi e cambiare l'hostname come verrà descritto dettagliatamente in seguito e
solo allora avviare le successive macchine.
Una volta lanciati, è possibile vedere lo stato attuale del dominiousando il comando
sudo /usr/sbin/xm list
Ed otterremo qualcosa del genere:
Name ID Mem(MiB) VCPUs State Time(s)
Domain­0 0 1108 1 r­­­­­ 1721.7
GlobFEcod 85 511 1 ­b­­­­ 246.8
GlobS1cod 89 127 1 ­b­­­­ 9.9
GlobS2cod 87 127 1 ­b­­­­ 8.9
GlobS3cod 90 127 1 ­b­­­­ 9.4
Dove vediamo le nostre macchine avviate con i nomi di dominio impostati nei file di
configurazione. Ancora una volta ribadiamo che questi nomi non sono quelli interni al
149
cluster virtuale e potremmo chiamarli in qualunque modo.
Una volta lanciati, è possibile entrare nel cluster virtuale con una connessione ssh sul
FE virtuale e poi da lì spostarsi sempre con ssh sugli slave. Questo verrà esaminato
meglio più avanti. Adesso ricordiamo che, in caso di emergenza, se una macchina è
stata avviata correttamente, è possibile entrarvi da console con i comandi:
sudo /usr/sbin/xm console GlobFEcod
sudo /usr/sbin/xm console GlobS1cod
sudo /usr/sbin/xm console GlobS2cod
sudo /usr/sbin/xm console GlobS3cod
e loggarsi. Ricordiamo che le password, modificabili successivamente, al momento di
stesura di questo lavoro, sono “globus” per l'utente globus e “root”per l'utente root.
Una volta entrati da terminale sulla console non si potrà tornare alla schermata
precedente a meno di non spegnere la macchina dall'interno della console stessa. E'
comunque sconsigliato spegnere continuamente queste macchine. Tipicamente
vengono lasciate perennemente accese e si avviano, di volta in volta, nuove sessioni
ssh.
Non entrando da console, ma rimanendo nella cartella che contiene i file immagine e di
configurazione, sarà comunque possibile spegnere le macchine con i comandi:
sudo /usr/sbin/xm shutdown GlobFEcod
sudo /usr/sbin/xm shutdown GlobS1cod
sudo /usr/sbin/xm shutdown GlobS2cod
sudo /usr/sbin/xm shutdown GlobS3cod
A2 Accesso al cluster
Per accedere al cluster virtuale è necessario prima loggarsi sul cluster reale. Nel nostro
caso, Vega si trova all'indirizzo 143.225.25.101. Quindi basta essere registrati sul
150
cluster reale e loggarsi ad esso tramite connessione ssh.
Una volta sul Front-End reale, con una connessione ssh potremo accedere al nodo su
cui si trovano i file immagine se è necessario operare con essi. Nel nostro caso, si
trovano su vm-container-0-1 in /state/partition1 (partizione non stabile, quindi prestare
molta attenzione).
In generale, però, quando ci si trova a dover accedere e lavorare con il cluster il modo
di procedere è connettersi sempre tramite connessione ssh e mai da console.
Quindi, come dicevamo, l'unico accesso disponibile al cluster virtuale è proprio dal FE
virtuale. Il FE virtuale ha due interfacce di rete. Quella lato Vega è 10.1.1.20. Per
loggarsi quindi è necessaria una connessione ssh [email protected] e immettere la
password dell'utente globus.
Si accederà così al FE virtuale.
Se è il nostro primo accesso dopo l'accensione dovremo immediatamente andare a
cambiare l'hostname che, come potremo notare, è FEcod di default. Questo è
importante perché il certificato di Globus è stato registrato con un altro nome e non
funzionerebbe. Gli stessi slave sono impostati per riconoscere un FE con un
determinato nome. Se non venisse cambiato il nome e venissero avviati gli slave questi
si bloccherebbero in fase di caricamento sull'istruzione “mounting NFS”.
E' un operazione che andrà fatta ogni volta che avremo spento e riavviato il FE virtuale.
Visto che, però, il FE virtuale dovrebbe teoricamente essere avviato una sola volta e
mai spento (così come gli slave), questa non dovrebbe diventare un'operazione tanto
frequente.
E' stato preimpostato sul FE virtuale un file /etc/hostname con all'interno il giusto nome,
“globfecod.dii.unina2.it”. Per impostarlo basterà dare da root il comando:
hostname -F /etc/hostname
Dove con l'opzione -F stiamo forzando la lettura sul nostro file.
151
E' importante sottolineare che, nel diventare utente root sul FE virtuale, avverrà una
cosa del genere:
[globus@globfecod ~]$ su
Password:
bash: module: command not found
bash: module: command not found
bash­3.00#
con questa bash potremo comunque effettuare ogni comando ma, per una
visualizzazione più consona, basta digitare il comando
/bin/sh
e tutto tornerà alla normalità:
bash­3.00# /bin/sh
[root@globfecod globus]# Questo vale anche per tutti gli slave.
A3 Configurazione degli indirizzi
Con le immagini fornite da questo lavoro di tesi, tutti gli indirizzi sono preconfigurati per
funzionare bene. E' comunque necessario capire che, se si stessero configurando
nuovi file immagine, questi dovranno avere i file relativi agli host di dominio e alle
interfacce di rete, coerenti tra loro.
Per poter visualizzare i vari file è utile l'editor Nano, lanciabile con il comando “nano”
seguito dal nome del file da aprire. Per uscire dall'editor, Ctrl+X, se si desidera salvare
digitare “y” seguito da Invio altrimenti digitare “n”. Stare attenti nelle modifiche di
alcuni file al fatto che talvolta l'editor nano fa andare le righe accapo automaticamente.
152
Se sono file di configurazione non funzioneranno più a meno di non rimettere le righe
com'erano.
Il file /etc/hosts (accessibile ovviamente solo da root) di globfecod è:
127.0.0.1 localhost
192.168.1.20 globfecod.dii.unina2.it globfecod.dii.unina2.it
192.168.1.21 slave1
192.168.1.22 slave2
192.168.1.23 slave3
192.168.1.24 slave4
10.1.1.1 vega vega.ing.unina2.it
Dove notiamo i vari indirizzi di rete degli host facenti parte del dominio virtuale.
Il file /etc/hosts di slave1 è invece:
127.0.0.1 localhost
10.1.1.1 vega2
192.168.1.20 globfecod.dii.unina2.it
192.168.1.21 slave1
192.168.1.22 slave2
192.168.1.23 slave3
192.168.1.24 slave4
Importanti sono anche i file /etc/sysconfig/network-scripts/ifcfg-eth0 del tipo:
TYPE=Ethernet
DEVICE=eth0
BOOTPROT=static
IPADDR=10.1.1.20
NETMASK=255.255.255.0
ONBOOT=yes
USERCTL=yes
PEERDNS=no
NETWORK=10.1.1.0
#BROADCAST=192.168.1.255
In cui troviamo l'interfaccia di rete lato Vega e il file /etc/sysconfig/network-scripts/ifcfgeth1:
153
YPE=Ethernet
DEVICE=eth1
BOOTPROT=static
IPADDR=192.168.1.20
NETMASK=255.255.255.0
ONBOOT=yes
USERCTL=yes
PEERDNS=no
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
Che è l'interfaccia di rete lato dominio virtuale.
Sugli slave troveremo solo i file /etc/sysconfig/network-scripts/ifcfg-eth0, ad esempio il
successivo appartiene a slave2:
TYPE=Ethernet
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.22
ONBOOT=yes
USERCTL=yes
Che rappresenta l'unica interfaccia di rete di cui slave2 è dotato.
Ai fini del corretto funzionamento del cluster, è importante che questi file siano ben
configurati, come negli esempi che abbiamo riportato. Ulteriore cosa da ricordare è che
se si dovesse decidere di cambiare il nome del Front-End si dovrà rigenerare il
certificato, visto che la request di quest'ultimo è stata fatta usando il nome host
“globfecod.dii.unina2.it” altrimenti dall'esterno non potranno essere usati i servizi Grid.
Inoltre, una volta cambiato l'hostname dovranno essere riaggiornati tutti i file di
configurazione di globus che contenfono il vecchio nome. Per trovarli occorre fare
prima una ricerca con “find” di tutti il file “*.conf”, selezionare quelli di globus e tra
questi, cercare con “grep” tutti quelli che contengono il vecchio nome host e modificarli
con il nuovo.
154
A4 Configurazione dei software
Attualmente il cluster è correttamente configurato per poter far girare senza problemi i
servizi Grid, tuttavia si ritiene necessario proporre i vari step necessari alla
configurazione di tutti i software che attualmente funzionano su di esso.
Le distribuzioni Linux che girano sulle macchine sono delle Red Hat - CentOS release
4.3 (Final) con architettura x386.
L'upload dei file, non essendo il cluster virtuale connesso ad internet per questioni di
sicurezza, viene fatto tramite scp.
Questo vuol dire che i file devono essere:
•
inviati tramite scp sul Front-end reale
•
inviati tramite scp sul Front-end virtuale.
Il comando scp funziona nel seguente modo:
scp -r nomeFile1 nomeFile2 nomeFile3 :percorso su cui salvare.
Il -r (recursive) si usa quando tra i file vi sono anche delle cartelle e vogliamo,
ovviamente, inviare anhe tutto il loro contenuto.
Quindi se ad esempio siamo su Vega e vogliamo passare il file pippo e la cartella pluto
(presenti nella cartella in cui ci troviamo) sul FE virtuale (possiamo farlo solo come
utente globus) nella cartella Disney della home dovremo scrivere:
scp -r pippo pluto [email protected]:./Disney/
dove quel ./ ci reindirizza alla home (equivale a dire /home/globus/)
A4.1 Configurazione di Java
155
Java è stato installato, contrariamente alle procedure standard che lo vorrebbero in
/opt o in /usr/lib/, direttamente nella home dell'utente globus (/home/globus/). Il motivo
è che, essendo tale home condivisa, gli slave avranno automaticamente java installato.
Un modo più elegante può essere quello di installarla in /opt/ per ogni macchina, ma il
risultato sarà comunque lo stesso.
Ricordiamo che per installare Java ci sono molti modi. Quello seguito è il procedimento
di installazione tramite file binari.
La scelta della versione è stata dettata da una serie di fattori legati a servizi già
sviluppati in precedenti lavori, avuti in una fase iniziale. Per non avere incompatibilità
tra classi generate da diversi compilatori, si è optato per la versione 1.5.0 release 07.
E' stata comunque installata anche l'ultima versione di java, la 6 release 14 ma nella
cartella /opt/. Come vedremo a breve, tramite il PATH viene stabilito quale versione
usare.
54
E' stata scaricata, dal sito della SUN , la versione java:
jdk­1_5_0_07­linux­i586.bin
E' stata messa nella home ed è stata lanciata col comando ./
Una volta che è stata automaticamente scompattata ed installata, avremo una cartella
jdk1.5.0_07 all'interno della home (/home/globus/). All'interno c'è la cartella bin a cui
dovremo far puntare il PATH perché sia utilizzata questa versione della Java Virtual
Machine.
Per configurare il PATH basta entrate nel file nascosto della home .bashrc col comando
nano .bashrc e scrivere questa riga:
PATH=/home/globus/jdk1.5.0_07/bin:$PATH
In pratica abbiamo aggiunto il percorso della java virtual machine a monte del path già
presente nel sistema. Infatti ricordiamo che i “:” sono i separatori all'interno del
54 http://java.sun.com/products/archive/
156
percorso, se vogliamo aggiungere altri percorsi basterà aggiungere i “:” come
separatori tra essi. Infatti l'ultima riga richiama la variabile PATH già presente nel
sistema. In pratica abbiamo aggiunto a monte.
Ogni volta che facciamo modifiche di questo tipo dobbiamo ricordarci di uscire dalla
sessione corrente di terminale ed aprirne un'altra perché il loro effetto venga registrato.
Per visualizzare il PATH basta dare il comando:
echo $PATH
Infine andrà impostata la variabile d'ambiente JAVA_HOME analogamente a quanto
fatto per il PATH, quindi sempre in .bashrc
export JAVA_HOME=/home/globus/jdk1.5.0_07
Il comando java -version ci servirà a capire se è tutto ok.
A.4.2 Installazione di Jade
Per quanto riguarda l'installazione di Jade, si è proceduto nella maniera classica,
55
ovvero quella di scaricare dal sito di Jade tutta la cartella del framework che include i
quattro archivi jar fondamentali per il funzionamento: jade.jar, jadeTools.jar, iiop.jar,
http.jar. In realtà, per il funzionamento di Jade bastano solo questi quattro archivi, ma
per comodità é stata caricata tutta la cartela Jade-bin-3.5 per uniformare i progetti a
quelli già sviluppati in precedenti lavori di tesi. All'interno della sottocartella lib trovano
posto quegli archivi. In particolare, all'interno di jade.jar è presente la classe Boot che
serve all'avvio del framework. Questi archivi devono essere caricati nel CLASSPATH in
modo che possano essere richiamati ovunque. Come per Java, anche in questo caso
si è preferito porre Jade nella home in modo che potesse essere condiviso anche dagli
slave.
55 http://jade.tilab.com/
157
Per settare il CLASSPATH si deve procedere in maniera analoga a quanto fatto per il
PATH. Bisogna accedere al file .bashrc ed aggiungere la riga:
export CLASSPATH=/home/globus/JADE­bin­3.5/lib/jade.jar:/home/globus/JADE­bin­
3.5/lib/jadeTools.jar:/home/globus/JADE­bin­3.5/lib/iiop.jar:/home/globus/JADE­bin­
3.5/lib/http.jar
come sempre, si deve salvare il file e poi uscire dall'attuale sessione ssh ed avviarne
una nuova perché le modifiche abbiano effetto.
echo $CLASSPATH per vedere se il Classpath è ben configurato e
java jade.Boot per vedere se viene avviato il Main-Container di Jade.
A.4.3 Installazione di Globus
Questa è stata sicuramente la fase più complessa della configurazione. La guida per
l'installazione del Globus Toolkit 4.0.8 che abbiamo scelto si trova sul sito della Globus
56
Alliance . La procedura di installazione è stata eseguita abbastanza fedelmente. La
scelta della versione del Toolkit è stata dettata dal fatto che è la versione installata sul
cluster reale Vega. E' importante sottolineare questo fatto in quanto, come si diceva nel
capitolo 4, all'interno di un Nodo Grid, abbiamo una macchina su cui è installato il
Toolkit ed una serie di macchine, facenti parti del nodo, che sono utilizzate per la
condivisione di risorse. Dal punto di vista del Front-End reale, quindi, il Front-End
virtuale è visto come una delle tante macchine facenti parte del nodo Grid. Inoltre, il
certificato X.509 è stato generato per Vega e non si può pensare di generarne un altro
su una macchina del cluster che deve far parte di quello specifico nodo Grid. In pratica
si è dovuto procedere all'installazione da “seconda macchina” prevista per il Toolkit.
L'installazione da seconda macchina differisce dalla prima installazione proprio sulla
56 http://www.globus.org/toolkit/docs/4.0/admin/docbook/quickstart.html
158
parte inerente ai certificati. Dovrà essere infatti generato una badge temporale della
validità di 12 ore che prende i permessi del certificato principale presente su Vega.
Procediamo dunque alla descrizione dell'installazione del Toolkit.
Configurazione del sistema
Innanzitutto bisogna creare un nuovo utente “globus” per eseguire tutte le operazioni
che andremo a vedere (tranne ovviamente quelle di root).
Lo si può fare con il comando
adduser globus
Come apprendiamo dalla guida, per l'installazione di Globus occorrono una serie di
prerequisiti. Poiché nelle immagini delle macchine fornite all'inizio di questo lavoro non
erano presenti pacchetti o librerie di alcun tipo (se non quelli basilari) si è dovuto
procedere all'installazione di tutti i software e i pacchetti richiesti prima di poter
procedere con l'installazione.
L'elenco dei software è presente nella guida, ne riportiamo qui alcuni : Apache ANT,
compilatore C, compilatore C++, i comandi tar, sed e make, il Perl e tutti i suoi moduli,
in particolare i moduli Parser XML ed, infine, tutte le librerie richieste affinchè questi
pacchetti possano funzionare.
Non essendo presenti, sul FE virtuale, né un gestore di pacchetti, né tanto meno la
connessione a Internet, si è dovuto procedere alla ricerca di queste librerie da un
normale computer connesso al Web e caricare con scp tutti questi pacchetti prima su
Vega e poi su globFeCod. Per conoscere le eventuali dipendenze richieste si è spesso
dovuto attendere l'installazione del pacchetto in questione. I vari pacchetti installati
sono, comunque, attualmente presenti nella home del FE virtuale e sono sempre
57
scaricabili dal portale RPM Search . Di seguito è riportato l'elenco dei pacchetti e delle
librerie installate:
57 http://rpm.pbone.net/
159
cpp­3.4.6­10.i386.rpm
systemimager­i386initrd_template­4.0.2­1.noarch.rpm
db3­3.1.17­4.6x.i386.rpm
db3­devel­3.1.17­4.5x.i386.rpm
db3x­3.2.9­4.i386.rpm gcc­3.4.6­10.i386.rpm glibc­2.0.7­29.i386.rpm krb5­libs­1.4­4.pp­rh73.i386.rpm libgcc­3.4.6­10.i386.rpm libstdc++­2.96­85.i386.rpm openssl­0.9.6c­1.i386.rpm
perl­XML­Parser­2.34­0.rh73.dag.i386.rpm
xinetd­2.3.4­0.8.i386.rpm
perl­XML­Parser­2.36­1.el2.rf.i386.rpm
xinetd­2.3.7­2.i386.rpm
perl­modules­0.04­1.el3.rf.noarch.rpm
perl­modules­5.6.1­8.i386.rpm
perl­modules­5.8.5­3.i386.rpm
postgresql­libs­7.2.4­5.73.i386.rpm
gcc­c++­3.4.6­10.i386.rpm perl­XML­Parser­2.36­3.el3.pp.i386.rpm sudo­1.6.8p12­1rh73.i386.rpm
In grassetto troviamo i componenti fondamentali da installare. Per farlo occorrono le
altre librerie e gli altri pacchetti indicati.
E' importante ricordarsi di configurare anche la variabile d'ambiente ANT_HOME
sempre nel file .bashrc.
Una volta installati questi pacchetti si può procedere all'installazione di Globus.
La prima parte dell'installazione è in comune sia che si tratti di installazione su prima
macchina che su seconda. Abbiamo scelto l'installazione tramite sorgenti e quindi
abbiamo dovuto configurarli, compilarli ed installarli.
Il pacchetto fondamentale che contiene tutti i sorgenti è:
gt4.0.8­all­source­installer.tar.gz
Configurazione, compilazione, installazione.
Innanzitutto bisogna scompattare quest'archivio dando il comando tar xzf seguito dal
nome del file che abbiamo appena indicato. Poi bisogna accedere alla cartella che è
160
appena stata creata e dare il comando ./configure –-prefix=/opt/gt4.0.8 in cui stiamo
creando il make-file per effettuare la compilazione, specificando con il comando -–
prefix che l'installazione dovrà avvenire nella cartella gt4.0.8 sotto /opt. Se tutto va a
buon fine, otterremo il make-file.
Sempre dalla posizione corrente, lanciamo il comando make | tee installer.log
In realtà sarebbe bastato dare il make per avviare il processo di compilazione dei
sorgenti. Con il secondo comando abbiamo fatto in modo di crearci un file di log da
poter consultare se qualcosa dovesse andare storto.
L'operazione di Make durerà circa un'ora.
Una volta che sarà stata completata, diamo l'ultimo comando, il make install ,
aspettiamo qualche secondo ed avremo terminato.
Configurazione della sicurezza
A questo punto dovremo procedere con le istruzioni per l'installazione su seconda
macchina.
Innanzitutto bisogna chiedere all'amministratore di sistema di Vega di fornire una copia
del file globus_simple_ca_dbbe8445_setup-0.19.tar.gz che si trova nella sua
cartella simpleCA. Non abbiamo alcun permesso, su Vega o su un qualunque altro
cluster, di muoverci al di fuori della nostra home, quindi avremo bisogno
dell'amministratore di sistema per fare una serie di operazioni.
Per comodità di lavoro è stata settata una variabile d'ambiente GLOBUS_LOCATION in
.bashrc in questo modo:
export GLOBUS_LOCATION=/opt/gt4.0.8/
in modo da poterla utilizzare comodamente ogni momento.
Cominciamo quindi ad installare il package del certificato con :
$GLOBUS_LOCATION/sbin/gpt­build globus_simple_ca_ebb88ce5_setup­0.18.tar.gz Da utente root poi eseguiamo gli script di setup:
161
source $GLOBUS_LOCATION/etc/globus­user­env.sh
$GLOBUS_LOCATION/setup/globus_simple_ca_ebb88ce5_setup/setup­gsi ­default
Adesso avremo ottenuto una cartella /etc/grid-security/ simile a quella presente su
Vega ed in particolare la cartella /etc/grid-security/certificates/.
Sempre da root, procediamo per ottenere un certificato:
grid-cert-request -host `hostname`
Dove al posto di hostname bisogna mettere il nome dell'host (globFeCod) o, talvolta, il
nome completo di dominio che troviamo in /etc/hosts.
Talvolta possiamo aggiungere il comando -force, qualora avessimo fatto qualche errore
in precedenza, in pratica serve a sovrascrivere la richiesta.
Avendo generato il certificato, basato su quello fornito all'inizio dall'amministratore del
cluster reale, bisognerà ora che questo certificato venga registrato. Per farlo bisognerà
coinvolgere di nuovo l'amministratore di Vega.
Bisogna passargli il file /etc/grid-security/hostcert_request.pem
L'amministratore di Vega dovrà prendere questo file e usare il comando grid-ca-sign
ed immettere la chiave del certificato CA. Dopodiché dovrà recuperare il file che ha
firmato, nella directory .globus che si trova nella sua home, come indicatogli dalla shell.
Quando avremo ottenuto il file, dovremo copiarlo col comando cp in:
/etc/grid­security/hostcert.pem
Questo sempre come utente root sul cluster virtuale. In seguito dovremo dare i
comandi (una volta entrati in /etc/grid-security):
cp hostcert.pem containercert.pem
cp hostkey.pem containerkey.pem
chown globus:globus container*.pem
Per fare in modo da copiare i file hostcert e hostkey in containercert e containerkey e
fare in modo che il proprietario di questi ultimi due file sia l'utente globus.
162
Possiamo controllare che i permessi sui file siano corretti digitando:
ls -l *.pem
Infine, perché un utente possa utilizzare un certificato, è necessario copiare nella sua
home la cartella .globus aggiornata che c'è sul FE reale, ed assegnarle ovviamente il
giusto proprietario ed i giusti permessi (con chown e chmod).
Utilizzo di Globus
A questo punto, è possibile avviare il Container di Globus andando a lanciare (da
utente globus) il comando /etc/init.d/globus start (oppure stop o restart).
Per comodità è stata settata una variabile d'ambiente:
export CONTAINER_GLOBUS=/etc/init.d/globus
in modo da poter più facilmente gestire il container, basterà ad esempio digitare
$CONTAINER_GLOBUS start, per farlo partire. La password che viene richiesta è
quella dell'utente globus. I log relativi a questo container si trovano in /opt/gt4.0.8/
var/, facilmente raggiungibile con la GLOBUS_LOCATION. Di particolare interesse è il
file container.log che contiene l'elenco dei servizi Grid attualmente messi a
disposizione, seguito da tutte le operazioni effettuate dal momento dell'avvio. Nel file
container.pid troviamo il pid con cui il container si è avviato.
Ricordiamo ancora una volta che il container Globus non partirà se non è stato
cambiato l'hostname della macchina o se la memoria RAM è insufficiente.
Per poter pubblicare un servizio, c'è bisogno di un file di estensione .gar (come
ottenerlo sarà oggetto dell' Appendice B). Una volta raggiunta la posizione di quel file
basterà lanciare il comando:
globus­deploy­gar nomefile.gar
per pubblicarlo e
163
globus­undeploy­gar nomefile (senza estensione .gar)
per toglierlo dalla lista.
Tutte le modifiche avranno effetto solo spegnendo e riavviando il container Globus.
Affinché i suddetti comandi funzionino così come li abbiamo descritti (cioè senza
andare ad indicare l'intero percorso dei comandi) bisogna inserire nel PATH la loro
posizione aggiungendo la riga /opt/gt4.0.8/bin nella variabile PATH di .bashrc.
Per poter usufruire dei servizi Grid pubblicati sul Container, bisognerà che l'utente, nella
sessione ssh attuale, lanci il comando per ottenere il badge di 12 ore. Il comando è:
grid­proxy­init
seguito dalla passphrase “globus..”
Esso avrà validità solo per la sessione ssh corrente.
Infine, prima di lanciare un qualunque client per usufruire dei servizi è necessario
caricare nel CLASSPATH tutte le librerie di Globus. Lo si deve fare dalla cartella da cui
si vuol lanciare il programma. Il comando per farlo in maniera rapida è:
source /opt/gt4.0.8/etc/globus­devel­env.sh
un echo $CLASSPATH ci farà capire se il comando ha funzionato.
A questo punto non ci resta che lanciare il nostro client.
Ricordiamo che il file container.log tiene traccia di quello che accade oltre a mostrare
l'elenco dei servizi pubblicati.
A.5 Modifica al protocollo SSH
Un'ulteriore importante modifica fatta al cluster virtuale è stata fare in modo che il
164
protocollo ssh, tra le varie macchine virtuali, funzionasse senza l'utilizzo della password
ma solo tramite autenticazione con chiave pubblica RSA.
Di seguito è illustrato il procedimento seguito:
Sono stati modificati i vari file di configurazione di tutti gli host:
Modifiche al file /etc/ssh/ssh_config
nel file /etc/ssh/ssh_config sono stati posti a yes RhostsRSAAuthentication e
RSAAuthentication ed è stato tolto il commento all'identity file inerente alla chiave
privata rsa
Modifiche al file /etc/ssh/sshd_config
Nel file /etc/ssh/sshd_config abbiamo posto:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeyFile col percorso di authorized_keys
RhostRSAAuthentication yes
PermitEmptyPasswords yes
PasswordAuthentication yes
Modifiche User e Group
Sono stati modificati lo uid ed il gruppo di ogni host in modo che fossero tutti uguali a
505. Per farlo si è usato il comando
/usr/sbin/usermod ­u 505 globus per lo UID e
/usr/sbin/usermod ­g 505 globus per il gruppo.
Per il gruppo, però, bisognava aver precedentemente cambiato manualmente il numero
nel file /etc/group.
Per verificare che è tutto ok, guardare la riga inerente all' utente globus nel file
/etc/passwd.
165
Generazione delle chiavi RSA
Riavviati i demoni ssh per ogni macchina col comando /etc/init.d/sshd restart, è stata
generata la coppia di chiavi pubblica e privata.
Dal FE virtuale
ssh­keygen ­t rsa
con passphrase vuota.
Verrà generata una coppia di chiavi pubblica e privata nella cartella nascosta .ssh
presente nella home.
E' stato copiato il contenuto della chiave pubblica .ssh/id_rsa.pub in un file
appositamente creato, authorized_keys omettendo la parte dopo la chiocciolina, visto
che questa sarà una chiave usata da tutti i membri del cluster (la chiave privata è da
essi condivisa). In pratica bisognerà, alla fine della chiave inserita in authorized_keys,
lasciare “globus@”
Permessi sulle cartelle
A questo punto il passo finale e fondamentale sono i permessi.
L'intera cartella globus deve avere permessi 700. Il file authorized_keys deve avere
permessi 600. Una volta fatto, funzionerà l'ssh senza password ma non funzionerà più
il comando grid-proxy-init.
Per sistemarlo bisognerà entrare in /.globus/ e cambiare in 644 i permessi a
usercert.pem e in 600 i permessi a userkey.pem.
166
Appendice B
Generazione di servizi Grid
Per creare servizi Grid basati su agenti mobili come quelli descritti in questa tesi, è utile
avvalersi di tool automatici per lo sviluppo di codice che semplificano molto il lavoro del
programmatore andando a generare la parte di codice standard.
Nel caso dei servizi trattati, sono stati usati un generatore di codice per agenti mobili ed
un tool per lo sviluppo di servizi Grid.
B1 WSAG
Il primo è il generatore WSAG che implementa lo standard WSAI.
Questo generatore accetta in input una classe java che rappresenta l'interfaccia del
nostro servizio e va a generare il codice dell'interfaccia stessa e gli agenti proxy che
verranno utilizzati, basandosi sui metodi descritti dall'interfaccia presa in ingresso.
Ciò vuol dire che se pongo in ingresso un interfaccia java di questo tipo:
package serviziGRIG.prova
public interface TestInterface()
{
public void metodo1(int a, int b);
public void metodo2(int a, int b);
}
il generatore produrrà tre file java: uno sarà TestInterfaceImpl.java che rappresenta
l'implementazione
dell'interfaccia
del
servizio
e
due
file
TestInterfcaeInterfacemetodo1Agent.java e TestInterfaceInterfacemetodo2Agent.java
167
che sono le implementazioni degli agenti proxy nei quali verrà implementata la logica
delle operazioni (che deve essere definita dal programmatore e non è ovviamente
automatizzabile).
Per poter utilizzare il generatore bisogna essere in possesso del package
com.whitestein.wsi. Ci si deve portare laddove è la cartella com e bisogna aver
precedentemente compilato l'interfaccia java creata (prova).
Quindi lanciare il comando:
com.whitestein.wsi.generator.Generator serviziGrid.prova.TestInterface Target1
Dove Target1 è il nome dell'agente target che potrà essere utilizzato in particolari
servizi. WSAG vuole che sia specificato il nome di quest'agente ma nel nostro caso
esso non dovrà essere utilizzato ed andremo a porre a null il campo in cui viene
registrato in ogni agente proxy:
public TargetAgent getTargetAgent() {
TargetAgent a=new TargetAgent();
a.setName("Target1");
a.setPlatform(null);
return a;
}
Quando il generatore avrà finito troveremo le suddette classi nella cartella generator.
Con WSAG non occorre fare altro.
B2 MAGE GDT
E' stato usato il plug-in di Eclipse Mage GDT sviluppato dall'Università di Marburg per
la generazione automatica di servizi Grid.
Questo plug-in è scaricabile liberamente dal sito
58
tramite il gestore dei plug-in di
58 http://mage.uni-marburg.de/trac/gdt
168
Eclipse. Attualmente, però, ci sono dei problemi di funzionamento con la versione 3.4
di Eclipse per cui abbiamo optato per la versione 3.2.2.
Un altro metodo per installarlo è procurarsi i file relativi alle cartelle plugin e features,
caricarli in Eclipse e poi riavviarlo.
Avremo bisogno, inoltre, che sulla macchina che stiamo utilizzando siano presenti le
librerie Globus GT4 da importare nei vari progetti. Si presentano sotto forma di cartella
chiamata GT4.
Una volta avviato Eclipse noteremo due pulsanti che sono comparsi a seguito
dell'installazione.
Sono i pulsanti per generare gli stubs ed il file gar come vedremo a breve.
Per ora vediamo come si genera un nuovo servizio Grid con Mage.
Per prima cosa clicchiamo su File-->New-->Project e poi selezioniamo Java Project e
diamo “Next”.
Nella finestra che compare dobbiamo specificare il nome che vogliamo dare al progetto
e fare in modo che venga creato nel workspace attuale (impostazione di Default). Nel
blocco JRE dovremo andare ad indicare quale versione della Java Virtual Machine
deve essere utilizzata. Se sul cluster abbiamo messo la 1.5.0_07 dovremo per forza
usarla anche qui altrimenti, al momento del lancio del client, avremo un'eccezione di
169
tipo “Bad Class Version”. L'installazione della JDK è pressoché identica a quella vista
per globFeCod.
Per selezionare la giusta JVM selezioniamo “Configure JREs” e selezioniamo Add, poi
Browse per la Home directory, e selezioniamo la nostra Jdk. Tornati alla schermata
precedente, mettiamo questa JDK come degault e selezioniamo anche il compilance
level che deve essere 5.0.
Tornando alla schermata del “nuovo progetto”, l'ultimo blocco riguarda il punto in cui
devono essere salvati i file .class. Per il corretto funzionamento di MAGE è importante
che sia selezionato “Create separate source and output folders” ovvero mettere i
sorgenti ed i .class in cartelle separate.
Dando l'ok verrà creato il nuovo progetto che comparirà come sempre nella schermata
sinistra. A questo punto dovrà essere usato MAGE. Cliccando col tasto destro sul
nome del progetto, selezioniamo New-->Other-->MAGE GDT Grid Service e diamo
“Next”.
La schermata che ci comparirà sarà quella di selezione delle librerie GT4.
170
Mettiamo la spunta a “Enable project specific settings” e selezioniamo con “Browse” il
percorso locale dove si trova la cartella delle librerie GT4.
La schermata successiva sarà la seguente:
Questa è senz'altro la fase più importante.
•
Come “Service Name” dovremo inserire il nome del Servizio
(che non è collegato assolutamente al nome del progetto che
abbiamo inserito prima). Per esempio, per il servizio di monitoring
qui è stato scritto proprio “Monitoring”.
•
Il campo “Service Namespace” è standard per i servizi sviluppati
dal dipartimento di Ingegneria dell'Informazione di Aversa ed è:
171
“http://globus.ing.unina2.it”.
•
Nel campo “Annotated Package” inseriremo il nome del package
in cui sarà il nostro servizio Grid. Convenzionalmente abbiamo
usato dei package a due livelli in cui la prima cartella è sempre
chiamata “serviziGRID” e la seconda è il nome del servizio
scritto in corsivo. Un esempio quindi è “serviziGRID.monitoring”.
•
Nel campo “Annotated Class” va inserito il nome della classe
che rappresenta l'interfaccia del servizio. E' la classe creata dal
WSAG (nell'esempio di prima TestInterfaceImpl). Poiché, come si
vedrà a breve, dovremo importare il codice di questa classe e
degli agenti proxy, logica impone che il nome sia lo stesso,
altrimenti tutti i riferimenti successivi saranno sbagliati.
•
Per il campo “Service style” selezioneremo “Singleton”: crea
una sola Risorsa. Ogni client usa sempre la Stessa Risorsa,
quindi ogni metodo invocato del Web Service opera sulla stessa
risorsa WSRF.
•
Su “Resource Style” selezioniamo “MAGE-GDT GT4”.
•
Lasciamo vuoti i campi dei due check-button ed infine, su
Package Settings, selezioniamo “Use custom service package”
in modo da utilizzare il package che abbiamo definito più in alto..
•
Infine possiamo cliccare sul tasto “finish”. Nel caso di Eclipse 3.4
è qui che avremo problemi perché non verrà creato il progetto.
Quello che sarà accaduto è che, all'interno del progetto inizialmente creato, saranno
comparse le varie librerie di Globus che abbiamo importato ed un nuovo package,
quello che abbiamo creato, con all'interno la annotated class che abbiamo creato.
Questa classe quindi avrà lo stesso nome di quella principale creata dal WSAG.
Modifiche da apportare per ottenere il grid-service
La prima cosa da fare è copiare tutto il codice che avremo ottenuto da WSAG
172
all'interno di questa classe, stando attenti a non cancellare gli import creati da MAGE
né la riga che comincia con “@GridService” che contiene tutti i parametri
precedentemente impostati. Notiamo che la classe Impl, contiene una classe interna
CallerImpl che estende la classe Caller. E' in questa classe che sono definite le varie
operazioni standard per le funzionalità dell'interfaccia. In pratica, per ogni metodo sono
definite una serie di operazioni che servono a creare ed attivare l'agente proxy che
deve fornire quella funzionalità.
Le modifiche da fare all'intera classe perché il Grid Service possa funzionare sono le
seguenti:
Nella classe CallerImpl bisogna definire il costruttore in questo modo:
ClasseDelServizioImpl questoServizio;
public CallerImpl(ClasseDelServizioImpl ogg){
questoServizio=ogg;
}
Dove ovviamente il nome ClasseDelServizioImpl deve essere quello della classe in cui
stiamo, la “Annotated Class” che abbiamo definito ed in cui stiamo scrivendo.
Poi, dobbiamo aggiungere il prefisso “@GridMethod” ad ognuno dei metodi (che
vengono chiamati all'esterno di CallerImpl). In questi metodi dovremo poi aggiungere la
parola “this” all'interno della chiamata al costruttore di CallerImpl, quindi ad esempio,
per il metodo cercaAgente avremo:
@GridMethod public String cercaAgente(String in0) throws Exception{
return (new CallerImpl(this)).cercaAgente(in0);
}
Ricordiamo che, eventuali altri metodi che fanno parte del servizio Grid ma che non
fanno uso di agenti mobili, devono essere dichiarati al di fuori della classe interna
CallerImpl. Il corpo di questi metodi deve essere quindi ben definito (a differenza del
precedente cercaAgente che crea un oggetto CallerImpl ed attiva l'agente proxy).
Questi metodi devono essere comunque preceduti da “@GridMethod”.
173
Ulteriore passo da fare è quello di portarci nella cartella del workspace che contiene il
file sorgente della classe Impl e copiare vicino ad esso tutti i file degli agenti proxy
generati dal WSAG.
Poi, di nuovo su Eclipse, facciamo un Refresh dell'intero progetto, selezionandolo e
premendo il tasto F5. Infine salviamo.
Vedremo comparire nel package gli agenti proxy che abbiamo caricato e,
automaticamente quando viene salvata la classe annotated, altri due package paralleli
al principale che saranno del tipo :
serviziGRID.nomeservizio.client
serviziGRID.nomeservizio.impl
Il codice del client, per il momento, sarà pieno di errori, ma non bisogna
preoccuparsene.
Adesso dobbiamo aprire il codice degli agenti proxy ed andare a definire il suo
Behaviour. Tipicamente lo si può fare con una classe interna che viene poi richiamata
all'interno del metodo costruttore.
Infine, nel package serviziGRID.nomeservizio.client troviamo il codice del client per il
nostro servizio Grid. E' nel main di questa classe (che troviamo in basso nel codice)
che dobbiamo mettere il codice che vogliamo sia eseguito per l'utente. Quindi è qui che
devono essere richiamati i vari metodi. Più avanti è riportato il codice dei client dei
servizi di gestione, usato per testarne ogni metodo.
Quando avremo finito di scrivere il nostro client, salviamo di nuovo il progetto e poi
clicchiamo sul primo dei due pulsantini:
174
“Generate Stubs” ed attendiamo una trentina di secondi che vengano generati gli
stubs.
Poi clicchiamo sul secondo dei pulsanti, “Package Service”, per generare il file .gar del
nostro servizio, quello che dovremo pubblicare sul Container di Globus.
Attendiamo ancora qualche secondo ed infine troveremo il file .gar all'interno della
cartella del servizio Grid nel workspace (la sottocartella del progetto che porta il nome
del servizio dichiarato in MAGE).
Appendice C
I client dei servizi di gestione ed il loro test
I servizi di gestione costituiscono la struttura base sulla quale far girare nuovi servizi.
Quando si devono effettuare le operazioni basilari con la piattaforma Jade (creazione,
monitoring, creazione di nuovi agenti, spostamento, ecc), bisogna sempre utilizzare
questi servizi.
Un avvio di piattaforma, ad esempio, è eseguito sempre dal servizio di
amministrazione.
175
C1 L'avvio della piattaforma Jade
Sono stati utilizzati dei particolari script all'interno del cluster virtuale, che possono
essere richiamati dal servizio di amministrazione per avviare il Main-Container di Jade
ed i Container secondari. Questi script si trovano nella cartella JADE-bin3.5/scriptAvvio/
Questi script, innanzitutto esportano il CLASSPATH con all'interno tutte le librerie di
Globus (quelle che vengono caricate con il comando source /opt/....visto in Appendice
A), poi al loro interno, contengono tutti i comandi per l'avvio della piattaforma.
Vediamo lo script di avvio del Main Container di una piattaforma Jade:
java jade.Boot ­jade_core_management_AgentManagementService_agentspath /home/globus/JADE­bin­3.5/script_jade/file_agenti ­name $1 ­services jade.core.mobility.AgentMobilityService\;jade.core.migration.InterPlatformMobilityServi
ce ­mtp "jade.mtp.myhttp.MessageTransportProtocol(http://192.168.1.20:7779/acc)" 2>/home/globus/JADE­bin­3.5/script_jade/logs/log_MainContainer.txt &
Esaminiamo più dettagliatamente questo comando:
•
Con jade.Boot avviamo la piattaforma alla porta di default 1099.
•
Con
la
riga
di
istruzione
l'AgentManagementService_agentspath
che
stiamo
riguarda
andando
a
specificare dove devono essere presi i file .class per la creazione
di nuovi agenti.
•
Col comando -name $1 viene ricevuto come parametro il nome
della piattaforma.
•
Con il comando -service stiamo specificando dei particolari
servizi che devono essere utilizzati come il migration di IPMS,
necessario al servizio di mobilità inter-piattaforma.
176
•
Con il comando -mtp stiamo installando un particolare tipo di
MTP sviluppato ad hoc in un altro lavoro di Tesi, sempre per
poter utilizzare la mobilità inter-piattaforma, infine andiamo a
specificare dove devono essere scritti i file di log della
piattaforma.
Vediamo ora lo script di avvio dei container secondari:
java jade.Boot ­container ­container­name $1 ­host globfecod.dii.unina2.it ­jade_core_management_AgentManagementService_agentspath /home/globus/JADE­
bin­3.5/script_jade/file_agenti 2>/home/globus/JADE­bin­
3.5/script_jade/logs/log_$1.txt &
Accadono più o meno le stesse cose. Però questa volta utilizziamo il comando
-container per specificare che stiamo attivando un container secondario ed il comando
-container-name per indicare il nome che gli stiamo dando. Con il comando -host
stiamo indicando qual è il Main-Container a cui deve fare riferimento.
C2 Il codice dei Client
Di seguito riportiamo il codice dei vari main dei client per i servizi di Monitoring,
Administration e User, utilizzato per testarli in assenza di X-Server. Il codice è quello
che produce gli screen-shot presentati nel capitolo 4.
Main del client del servizio di Monitoring:
public static void main(String[] args) {
String instanceURI="https://192.168.1.20:8443/wsrf/services/GridMonitoringService";
boolean useSecurity = false;
try {GridMonitoringClient client = new GridMonitoringClient( instanceURI, useSecurity);
System.out.println("Questa e' la lista dei container attivi: "+client.listaContainer());
System.out.println("Questa e' la lista degli agenti che girano su tutto il nodo Grid: "+client.listaAgenti());
System.out.println("Digitare il nome del container sul quale si vogliono informazioni : ");
InputStreamReader reader = new InputStreamReader (System.in);
177
BufferedReader input = new BufferedReader (reader);
String nomeContainer = new String();
try {nomeContainer = input.readLine();} catch (IOException e) {
System.out.println ("Si è verificato l' errore: " + e);System.exit(­1);}
System.out.println("Questo e' il nome che hai digitato: "+nomeContainer);
System.out.println("Le info richieste sul Container "+nomeContainer+" sono: "+client.infoContainer(nomeContainer));
System.out.println("Digitare il nome dell'agente per il quale si richiedono informazioni sul relativo Container : ");
reader = new InputStreamReader (System.in);
input = new BufferedReader (reader);String nomeAgente = new String();
try { nomeAgente = input.readLine();} catch (IOException e) {
System.out.println ("Si è verificato l' errore: " + e); System.exit(­1);}
System.out.println("Il Container sul quale gira l'agente "+nomeAgente+" ,e' : "+client.cercaAgente(nomeAgente));
System.out.println("Digitare il nome del Container per il quale si vogliono conoscere gli agenti attivi :");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
nomeContainer = new String(); try {nomeContainer = input.readLine();} catch (IOException e) {System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("Gli agenti che girano sul Container "+nomeContainer+" sono: "+client.listaAgentContainer(nomeContainer));
System.out.println("L'ultimo fault che e' avvenuto nel sistema e' :"+client.leggiErrorMessage());
} catch (Exception e) {e.printStackTrace();}}
Main del client del servizio di Administration:
public static void main(String[] args) {
String instanceURI="https://192.168.1.20:8443/wsrf/services/GridAdministratorService";
boolean useSecurity = false;
try {GridAdministratorClient client = new GridAdministratorClient( instanceURI, useSecurity);
java.lang.String nome = new java.lang.String("PiattaformaJADE");
System.out.println("Tentativo di attivazione della piattaforma Jade sulle macchine del cluster");
client.modificaComandoMainContainer("/home/globus/JADE­bin­
3.5/scriptAVVIO/avvio_Main_container.sh");
client.modificaComandoContainer("/home/globus/JADE­bin­
3.5/scriptAVVIO/avvio_container_ssh.sh");
System.out.println("Lo script per l'avvio del Main­Container e': "+client.visualizzaComandoMainContainer());
System.out.println("Lo script per l'avvio dei container secondari sulle macchine del cluster e': "+client.visualizzaComandoContainer());
java.lang.String configurazione= new String("Container1:192.168.1.21 Container2:192.168.1.22 Container3:192.168.1.23"); client.modificaConfigurazione(configurazione, null, null);
System.out.println("La configurazione de DEFAULT attuale e': "+client.visualizzaConfigurazione());
try{boolean verify=false;
verify = client.attivaPiattaforma(nome,true,null);
if(verify==true)
System.out.println("Piattaforma Jade attivata");
else System.out.println("Errore nella attivazione della piattaforma");
}catch (Exception e){e.printStackTrace();}
//attesa String comando = new String("");
178
do{System.out.println("Utilizzare ora il servizio di Monitoring per conoscere la situazione oppure digitare yes per procedere: ");
InputStreamReader reader = new InputStreamReader (System.in);
BufferedReader input = new BufferedReader (reader);
try {comando = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("Questo e' il comando che hai digitato: "+comando); }while(comando.equals("yes")==false);
//Test del metodo clonaAgente()
System.out.println("Test del metodo clonaAgente()");
System.out.println("Digitare ora il nome dell'agente che si desidera clonare: ");
InputStreamReader reader = new InputStreamReader (System.in);
BufferedReader input = new BufferedReader (reader);
String nomeAgente = new String();
try {nomeAgente = input.readLine();} catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("Digitare ora il nome del container sul quale si vuol clonare l'agente "+nomeAgente);
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
String nomeContainer = new String();
try { nomeContainer = input.readLine();} catch (IOException e) {
System.out.println ("Si è verificato l' errore: " + e);System.exit(­1); }
System.out.println("Il container che hai indicato e': "+nomeContainer);
String nomeClone = nomeAgente+"Clone";
System.out.println("Il nome del clone e': "+nomeClone);
try{ if(client.clonaAgente(nomeAgente,nomeContainer,nomeClone)==true)
System.out.println("Agente clonato con successo");
else System.out.println("Non sono riuscito a clonare l'agente");}
catch (Exception e) { e.printStackTrace();}
//attesa comando = new String("");
do{System.out.println("Utilizzare ora il servizio di Monitoring per conoscere la situazione oppure digitare yes per procedere: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
try {comando = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("Questo e' il comando che hai digitato: "+comando); }while(comando.equals("yes")==false);
//Test del metodo spostaAgente()
System.out.println("Test del metodo spostaAgente()");
System.out.println("Digitare ora il nome dell'agente che si desidera trasferire: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
nomeAgente = new String("");
try { nomeAgente = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e); System.exit(­1);}
System.out.println("Digitare ora il nome del container sul quale si vuol trasferire l'agente "+nomeAgente);
reader = new InputStreamReader (System.in);input = new BufferedReader (reader);
nomeContainer = new String("");
try { nomeContainer = input.readLine();} catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("Il container che hai indicato e': "+nomeContainer);
if(client.spostaAgente(nomeAgente,nomeContainer)==true)
System.out.println("Agente trasferito con successo");
else System.out.println("Non sono riuscito a trasferire l'agente");
//Test del metodo cercaAgente
System.out.println("Digitare ora il nome dell'agente che si desidera cercare: ");
179
reader = new InputStreamReader (System.in);
input = new BufferedReader (reader); nomeAgente = new String("");
try { nomeAgente = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("L'agente indicato e': "+nomeAgente);
String Container = client.cercaAgente(nomeAgente);
System.out.println("Il container sul quale gira l'agente "+nomeAgente+" e': "+Container); //attesa comando = new String("");
do{System.out.println("Utilizzare ora il servizio di Monitoring per conoscere la situazione oppure digitare yes per procedere: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
try {comando = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1); }
System.out.println("Questo e' il comando che hai digitato: "+comando); }while(comando.equals("yes")==false);
//Test del metodo UccidiAgente
System.out.println("Test del metodo uccidiAgente");
System.out.println("Digitare ora il nome dell'agente che si vuole uccidere: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
nomeAgente = new String("");
try {nomeAgente = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1);}
System.out.println("L'agente che hai indicato e': "+nomeAgente);
if(client.uccidiAgente(nomeAgente)==true)
System.out.println("Agente ucciso");
else System.out.println("Non sono riuscito ad uccidere l'agente");
//attesa comando = new String("");do{
System.out.println("Utilizzare ora il servizio di Monitoring per conoscere la situazione oppure digitare yes per procedere: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
try { comando = input.readLine();} catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1); }
System.out.println("Questo e' il comando che hai digitato: "+comando); }while(comando.equals("yes")==false); //chiusura della piattaforma
System.out.println("Procedo con la chiusura della piattaforma...");
try{boolean chiusura = client.chiudiPiattaforma();
if(chiusura==true)System.out.println("Piattaforma Jade chiusa");
elseSystem.out.println("Errore nella chiusura della piattaforma");
}catch (Exception e){ e.printStackTrace(); }
} catch (Exception e) { e.printStackTrace(); }}
Main del client del servizio di User:
public static void main(String[] args) {
String instanceURI="https://192.168.1.20:8443/wsrf/services/GridUserService";
boolean useSecurity = false;
try {GridUserClient client = new GridUserClient( instanceURI, useSecurity);
System.out.println("Test del metodo creaAgente()");
System.out.println("Inserire il nome della classe contenente il codice che sarà eseguito dall'agente: ");
180
InputStreamReader reader = new InputStreamReader (System.in);
BufferedReader input = new BufferedReader (reader); String nomeClasse = new String();
try {nomeClasse = input.readLine(); } catch (IOException e) {
System.out.println ("Si e' verificato l' errore: " + e);System.exit(­1); }
System.out.println("Inserire il nome da dare all'agente: ");
reader = new InputStreamReader (System.in); input = new BufferedReader (reader);
String nomeAgente = new String();
try {nomeAgente = input.readLine();} catch (IOException e) {
System.out.println ("Si è verificato l' errore: " + e);System.exit(­1);}
try{
if(client.creaAgente(nomeClasse, nomeAgente, null)==true)
System.out.println("Agente creato con successo");
else System.out.println("Errore nella creazione dell'agente");
}catch (Exception e) {e.printStackTrace();}
} catch (Exception e) {e.printStackTrace(); }}
Appendice D
L'interfaccia grafica
D1 Implementazione
Senza dilungarsi sul codice dell'interfaccia (è molto lungo per essere riportato in queste
pagine), poniamo attenzione a come è stata sviluppata in modo che chi voglia
cimentarsi in eventuali modifiche possa farlo agevolmente.
L'interfaccia è stata sviluppata con Eclipse andando a separar le cartelle dei sorgenti e
dei file .class. Tra i tanti file java dei sorgenti e tra i .class, si noterà che compaiono
anche i file relativi ai client dei servizi che abbiamo visto con la differenza che non
hanno il main. Questo è fondamentale ai fini del corretto funzionamento dell'interfaccia
stessa. Infatti, come si potrà notare esaminando il codice, quando vengono richiamati i
servizi Grid deve essere sempre creata un'istanza del client che potrà usufruirne e
sulla quale potremo applicare i metodi forniti dall'interfaccia del servizio. Questo vale
per qualunque servizio si vorrà gestire dall'interfaccia.
Nel momento in cui si deciderà di sviluppare e pubblicare nuovi servizi Grid sul nodo, si
181
dovranno porre i file del client nell'interfaccia. Questo rispettando il concetto che i
servizi devono essere pubblicati sul container mentre i client possono trovarsi
potenzialmente in qualunque punto della rete.
Quindi bisogna scindere logicamente il progetto dei servizi dal progetto dell'interfaccia.
L'interfaccia implementa un client.
Con MAGE, come abbiamo visto in APPENDICE B, implementiamo un servizio Grid.
Pertanto nell'interfaccia trasportiamo anche i client dei servizi (senza il main).
Affinché non ci vengano dati errori durante lo sviluppo dell'interfaccia, è necessario,
però, che nel progetto vengano importati gli stubs ed il package impl (generato in
automatico quando, avendo sviluppato in precedenza un servizio con MAGE, si è
salvata la classe che implementa l'interfaccia del servizio) sottoforma di file .jar
D2 Utilizzare l'interfaccia grafica
Per usare l'interfaccia grafica bisogna portarsi sul Front-End reale Vega con una
connessione
vnc
come
vedremo
a
breve.
L'interfaccia
deve
essere
stata
precedentemente caricata sul front-end con un scp.
E' importante sottolineare che sul Front-End devono essere caricate anche tutte le
librerie importate per la creazione dell'interfacccia. In particolare, queste librerie devono
essere esportate nel Classpath del Front-End reale.
Il modo più consono di procedere è questo:
•
al momento dello sviluppo del progetto in Eclipse o con qualche altra
piattaforma, facciamo in modo che le librerie che andiamo ad importare
(le GT4) si trovino nella cartella stessa del progetto all'interno del
workspace.
•
Nella cartella del workspace poniamo anche i file jar che importeremo
182
(quindi stubs, impl e quant'altro).
•
Spostiamo con un scp tutta la cartella del progetto interfaccia grafica su
Vega. In questo modo avremo trasportato automaticamente tutte le
librerie che abbiamo importato nel progetto
A questo punto, ogni volta che dovrà essere usata l'interfaccia, bisognerà esportare nel
Classpath tutte le librerie. Sono stati creati due file sh da lanciare per poterlo fare
rapidamente ogni volta.
Il codice è il seguente, bisogna però adattarlo alle specifiche esigenze:
CP=/export/home/derosa/InterfacciaGrafica/gt4/lib/
for i in /export/home/derosa/InterfacciaGrafica/gt4/lib/*.jar
do
CP=$CP:"$i"
done
CLASSPATH=$CP:$CLASSPATH
export CLASSPATH
Questo file si chiama importa_jar_interfaccia.sh
Ne è stato implementato uno analogo per importare altre librerie che servono per far
funzionare il protocollo https su Vega (senza le quali non si riesce a fare la richiesta al
Front-End del nodo Grid). Queste librerie sono fornite in allegato.
Per il funzionamento vero e proprio bisogna connettersi su Vega con un client vnc (va
da se che su Vega deve essere attivo un vnc server su uno specifico porto). Una volta
collegati, bisogna dare il comando source file.sh per ogni file che serve ad importare
librerie (nel nostro caso i due file). Poi bisogna fare il grid-proxy-init usando tutto il
percorso (perchè su Vega i binari di globus non sono nel path) o impostare una
variabile d'ambiente per farlo più rapidamente.
E' chiaro che la cartella .globus con il certificato valido deve essere presente nella
nostra home di Vega.
Fatto questo ci si porta sui file binari dell'interfaccia e si lancia la HomePage con il
comando java HomePage e si comincia ad usarla come descritto nel capitolo 5.
183
Bibliografia [1] “The Grid: Core Technologies ” Maozhen Li and Mark Baker © 2005 John
Wiley & Sons, Ltd
[2] “Grid Characteristics and Uses: a Grid Definition ” Miguel L. BoteLorenzo, Yannis A. Dimitriadis, and Eduardo Gçmeź
Sànchez School of
Telecommunications Engineering, University of Valladolid Camino Viejo del
Cementerio
[3] “Grid performance, grid benchmarks, grid metrics ” Zsolt Német MTA
Computer and Automation Reserach Institute
[4] “The Open Grid Services Architecture: Where the Grid Meets the
Web ” Domenico Talia • University of Calabria
[5] “Enterprise Grid computing: State-of-the-Art ” Krishna Nadiminti and
Rajkumar Buyya Grid Computing and Distributed Systems laboratory,
Department of Computer Science and Software Engineering, The University of
Melbourne.
[6] “The State of the Art in Grid Scheduling Systems ” Yi JIAN Chongqing
University of Posts and Telecommunications, Chongqing 400065, P. R. China
[7] “Globus Toolkit Version 4: Software for Service-Oriented Systems ”
Ian Foster Math & Computer Science Division, Argonne National Lab, Argonne,
IL 60439, U.S.A. Department of Computer Science, University of Chicago,
Chicago, IL 60637, U.S.A.
184
[8] “La condivisione delle risorse di calcolo: Globus Toolkit ” di Claudio
Cacciari, Paolo Malfetti, Andrea Vanni
[9] “XtreemOS: a Grid Operating System Making your Computer Ready
for Participating in Virtual Organizations ” Christine Morin∗ PARIS
Project-team XtreemOS Scientific Coordinator IRISA/INRIA
[10]
“Agenti
Mobili ”
Maurizio Panti, Loris Penserini, Luca SpalazziIstituto di Informatica, Università
di Ancona, Italy Gruppo di Sistemi Informativi
[11]
“Evaluating
the
FIPA Standards and Its Role in Achieving Cooperation in MultiAgent Systems ” P. Charlton R. Cattoni, A. Potrich, and E. Mamdani Imperial
College of Science Technology and Medicine, Department of Electrical and
Electronic Engineering, Exhibition Road, London, UK
[12]
“JADE- A White
Paper” F. Bellifemine, G. Caire, A. Poggi, G. Rimassa TITLAB
185