Introduzione - Gruppo di Ingegneria Informatica -SUN
Transcript
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 highend 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 highperformance 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, multiinstitutional 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, generalpurpose protocols and interfaces... 3) ...to deliver nontrivial 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 standardsbased 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 clientserver 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.nsfmiddleware.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' qualityofservice 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 ClientServer 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, proattiva 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 • Proattività: 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 runtime: 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: derosafe.cfg derosas1.cfg derosas2.cfg derosas3.cfg Il file immagine derosa-fe.cfg è il file di configurazione del Front-End ed è fatto in questa maniera: kernel = "/state/partition1/vmlinuz2.6xen" memory = 512 name = "GlobFEcod" vif = [ 'bridge=xenbr.eth0','bridge=xenbr.eth0' ] disk = ['file:/state/partition1/FEDerosa.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/vmlinuz2.6xen" memory = 128 name = "GlobS1cod" vif = [ 'bridge=xenbr.eth0' ] disk = ['file:/state/partition1/centos_slave1.43.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 derosafe.cfg sudo /usr/sbin/xm create derosas1.cfg sudo /usr/sbin/xm create derosas2.cfg sudo /usr/sbin/xm create derosas3.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) Domain0 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 bash3.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à: bash3.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: jdk1_5_0_07linuxi586.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/JADEbin3.5/lib/jade.jar:/home/globus/JADEbin 3.5/lib/jadeTools.jar:/home/globus/JADEbin3.5/lib/iiop.jar:/home/globus/JADEbin 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 cpp3.4.610.i386.rpm systemimageri386initrd_template4.0.21.noarch.rpm db33.1.174.6x.i386.rpm db3devel3.1.174.5x.i386.rpm db3x3.2.94.i386.rpm gcc3.4.610.i386.rpm glibc2.0.729.i386.rpm krb5libs1.44.pprh73.i386.rpm libgcc3.4.610.i386.rpm libstdc++2.9685.i386.rpm openssl0.9.6c1.i386.rpm perlXMLParser2.340.rh73.dag.i386.rpm xinetd2.3.40.8.i386.rpm perlXMLParser2.361.el2.rf.i386.rpm xinetd2.3.72.i386.rpm perlmodules0.041.el3.rf.noarch.rpm perlmodules5.6.18.i386.rpm perlmodules5.8.53.i386.rpm postgresqllibs7.2.45.73.i386.rpm gccc++3.4.610.i386.rpm perlXMLParser2.363.el3.pp.i386.rpm sudo1.6.8p121rh73.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.8allsourceinstaller.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/gptbuild globus_simple_ca_ebb88ce5_setup0.18.tar.gz Da utente root poi eseguiamo gli script di setup: 161 source $GLOBUS_LOCATION/etc/globususerenv.sh $GLOBUS_LOCATION/setup/globus_simple_ca_ebb88ce5_setup/setupgsi 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/gridsecurity/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: globusdeploygar nomefile.gar per pubblicarlo e 163 globusundeploygar 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 è: gridproxyinit 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/globusdevelenv.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 sshkeygen 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/JADEbin3.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/JADEbin3.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 containername $1 host globfecod.dii.unina2.it jade_core_management_AgentManagementService_agentspath /home/globus/JADE bin3.5/script_jade/file_agenti 2>/home/globus/JADEbin 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/JADEbin 3.5/scriptAVVIO/avvio_Main_container.sh"); client.modificaComandoContainer("/home/globus/JADEbin 3.5/scriptAVVIO/avvio_container_ssh.sh"); System.out.println("Lo script per l'avvio del MainContainer 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