Globus Toolkit e il servizio MDS
La chiave per la sopravvivenza dell’umanità e per il progresso futuro è la cooperazione.
Anonimo
Questo capitolo presenta una discussione generale delle caratteristiche del Globus Toolkit, un’infrastruttura software che integra risorse computazionali e informative, geograficamente distribuite. Attualmente il Globus Toolkit si sta imponendo come standard de facto per ambienti Grid. La terza e ultima versione di Globus (GT3) è basata sui Grid Service. Prima di esaminare il Globus Toolkit vengono descritti OGSA (Open Grid Service Architecture) e OGSI (Open Grid Service Infrastructure). Il primo affronta i problemi architetturali relativi ai servizi largamente interoperabili di Griglia. OGSA parte dal modello dei Web Service e mette a fuoco le caratteristiche richieste dalle infrastrutture e dalle applicazioni Grid. Il secondo, invece, definisce le specifiche dettagliate che un servizio deve implementare per essere OGSA-compliant. Successivamente viene descritto in particolare il servizio MDS (Monitoring and Discovery Service) che fornisce informazioni sullo stato dell’infrastruttura Grid. Questo servizio memorizza e fornisce informazioni riguardanti le risorse. Vedremo le sue funzionalità sia in GT2 che in GT3. Infine vengono presentati diversi approcci alternativi allo MDS.
2.1 OGSA/OGSI
Sia nello e-business che nello e-science, spesso debbono essere integrati i servizi attraverso “organizzazioni virtuali” distribuite, eterogenee e dinamiche formate sia da risorse presenti all’interno di una singola impresa, sia da risorse appartenenti a differenti imprese il cui utilizzo è soggetto a regole di condivisione. Questa integrazione può essere tecnicamente impegnativa a causa della necessità di raggiungere varie qualità di servizio quando questi servizi funzionano su piattaforme differenti. Queste problematiche vengono affrontate da OGSA [OGSA] che definisce una nuova architettura standard per applicazioni basate su Grid. Costruita sui concetti della tecnologia Grid e dei Web Service, OGSA definisce cosa sono i Grid Service, quali sono le loro funzionalità e su quali tecnologie sono basati. OGSA non dà una specifica dettagliata e tecnica che dovrebbe essere necessaria per implementare un Grid Service.
OGSI è una specifica formale e tecnica dei concetti descritti in OGSA, inclusi i Grid Service, mentre GT3 è l’implementazione delle specifiche di OGSI (e quindi di tutto ciò che è definito da OGSA). La figura seguente mostra le relazioni esistenti tra OGSA, OGSI e GT3 [Sot].
Figura 2.1: relazioni tra OGSA, OGSI e GT3.
Per comprendere meglio la figura 2.1 si consideri il seguente esempio: si supponga di voler costruire una nuova casa; la prima cosa da fare è assumere un architetto per disegnarla in modo da avere un’idea di come sarà. Una volta completato il disegno l’ingegnere specificherà i dettagli di costruzione: dove mettere le travi portanti, i cavi elettrici, l’impianto idraulico, etc. Successivamente, l’ingegnere passerà i progetti dettagliati ai lavoratori professionali (operai, elettricisti, idraulici, etc.) che costruiranno la casa. La relazione è molto chiara: OGSA (la definizione) è l’architetto, OGSI (la specifica) è l’ingegnere e GT3 (l’implementazione) sono i lavoratori.
Di seguito vengono descritte le due tecnologie su cui è stata costruita OGSA: i Web Service, che sono emersi come una struttura basata su standard per accedere alle applicazioni di rete e il Globus Toolkit, ampiamente adottato come soluzione della tecnologia Grid per il calcolo tecnico e scientifico.
2.1.1 Web Service
Un Web Service [WSCA] è un servizio che mette a disposizione una collezione di operazioni, accessibili attraverso una rete mediante messaggi standard XML. È descritto usando un formato XML standard chiamato descrizione del servizio. Questa descrizione contiene tutti i dettagli necessari per interagire con il servizio, incluso il formato dei messaggi, i protocolli di trasporto, ecc. I Web Service sono indipendenti sia dal linguaggio di programmazione nel quale i servizi sono scritti, sia dallo hardware e dalla piattaforma software sulla quale i servizi sono implementati. Il modello di funzionamento dei Web service prevede che un’organizzazione che voglia mettere a disposizione i propri servizi Web (Service Provider) renda pubbliche le descrizioni dei servizi fornendole a un registro distribuito (Service Registry). Le organizzazioni che vogliono avvalersi di questi servizi (Service Requestor) non devono far altro che interrogare il registro per avere le specifiche del servizio e quindi connettersi (binding) con il fornitore del servizio.
La standardizzazione dei Web Service è stata realizzata attraverso la definizione di una serie di protocolli quali Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Universal Description Discovery and Integration (UDDI).
2.1.2 Globus Toolkit
Il Globus Toolkit [GPaRS] è un software sviluppato ad Argonne National
Laboratory [ANL] ed Information Sciences Institute [ISI]. Comprende una serie
di componenti (alcuni sono elencati in Tabella 2.1) che implementano servizi di base per la sicurezza, l’allocazione e la gestione delle risorse, la comunicazione, l’informazione, il monitoraggio e l’accesso a dati remoti. In sostanza il toolkit offre una cosiddetta “borsa di servizi”, da cui gli sviluppatori di applicazioni o strumenti che necessitano dell’infrastruttura Grid possono attingere secondo le proprie necessità. Spesso nelle applicazioni Grid si ha la necessità di integrare
l’utilizzo di un ampio e variegato numero di applicazioni ad alto livello su sistemi altamente eterogenei e, deve essere sempre possibile poter aggiungere nuovi servizi senza che questo implichi cambiamenti della struttura sottostante. Ogni modulo di questa “borsa di servizi” deve quindi fornire un’interfaccia ben definita, che consenta un accesso uniforme alle diverse implementazioni dei servizi locali. I servizi globali di più alto livello vengono quindi definiti in funzione di questa interfaccia. Il modello di riferimento per questo tipo di architettura è detto “a clessidra” (figura 2.2). I servizi offerti si posizionano nel collo della clessidra, fornendo un’interfaccia attraverso la quale le applicazioni di alto livello utilizzano in modo trasparente i sistemi sottostanti.
Figura 2.2: il modello a clessidra secondo Globus.
Grazie a questo modello, una qualsiasi risorsa che voglia far parte di un ambiente Grid si deve preoccupare solo di fornire i servizi fondamentali, costruendo un limitato numero di moduli. Nel momento in cui viene deciso che una macchina debba entrare a far parte di una Griglia computazionale è necessario quindi
installare su di essa il software Globus secondo due modalità differenti, a seconda della politica scelta:
• se si vuole che la macchina abbia la doppia funzione di client e server
nella Griglia, cioè oltre ad utilizzare le risorse mette anche le proprie a disposizione degli utenti, allora è necessaria un’installazione completa del software (fase di install e fase di deploy);
• se si vuole che la macchina sia un punto di accesso per gli utenti per
l’utilizzo di risorse di Griglia ma non si vuole che metta a disposizione le proprie (solo funzione client) allora è necessaria solo la fase di install per dotare la macchina dei comandi necessari per l’autenticazione alla Griglia e la sottomissione di job.
Tabella 2.1: Descrizione di alcuni servizi offerti da Globus
2.2 Architettura di Griglia e Globus
L’architettura di Griglia [KFT] organizza i componenti in livelli come appare in figura 2.3. I componenti all’interno di ogni livello, condividono caratteristiche comuni ma si possono basare sulle funzionalità e sui comportamenti forniti da
Servizio Nome Descrizione
Security GSI Autenticazione correlati basati su Public Key e servizi Infrastructure (PKI)
Information
Infrastucture MDS Fornisce informazioni sui componenti del sistema
Resource
Management GRAM Allocazione delle risorse e gestione dei processi
qualsiasi livello più basso. Nello specificare i vari livelli dell’architettura di Griglia, vengono seguiti i principi del “modello a clessidra”. Il collo stretto della clessidra definisce un piccolo insieme di astrazioni e protocolli (per esempio, TCP e HTTP), su cui possono essere mappati molti comportamenti differenti ad alto livello (la parte superiore della clessidra) e che loro stessi possono essere mappati su molte tecnologie differenti (la base della clessidra). Dalla definizione, il numero dei protocolli definiti in corrispondenza del collo della clessidra deve essere basso. Il collo della clessidra consiste dei protocolli di Resource e di
Connectivity, che facilitano la condivisione delle singole risorse. I protocolli a
questi livelli sono progettati in modo che possono essere implementati su una vasta gamma di tipi di risorse, definite al livello Fabric. Il livello Collective, così chiamato perché coinvolge l’uso coordinato di risorse multiple, si basa sui livelli sottostanti per la costruzione di una vasta gamma di servizi e applicazioni globali, dai comportamenti specifici.
Per ognuno dei livelli si illustrano i protocolli definiti all’interno del Globus Toolkit.
Figura 2.3: l’architettura di Griglia a livelli e il suo rapporto con l’architettura del protocollo Internet.
2.2.1 Livello Fabric
Il livello Fabric è composto dalle risorse il cui accesso è mediato dai protocolli di Grid; ad esempio: risorse di calcolo, sistemi di memorizzazione, cataloghi, risorse di rete, e sensori. Una “risorsa” può essere un’entità logica, come un file system distribuito, un cluster di calcolatori, o un gruppo distribuito di calcolatori; in tali casi, un’implementazione delle risorse può coinvolgere protocolli interni ai singoli componenti. I componenti di Fabric implementano le operazioni locali che occorrono su specifiche risorse (o fisiche o logiche) come conseguenza delle operazioni di condivisione ai livelli più alti. L’esperienza suggerisce che, al minimo, le risorse dovrebbero implementare da una parte i meccanismi di
enquiry, che permettono la scoperta della loro struttura, condizione e capacità e
dall’altra meccanismi di gestione delle risorse che forniscono un certo controllo nello scoprire la qualità dei servizi.
Globus Toolkit: il Globus Toolkit è stato progettato per usare i componenti
Fabric esistenti, compreso i protocolli e le interfacce fornite dal venditore. Tuttavia, se un venditore non fornisce il funzionamento necessario al livello Fabric, il Globus Toolkit include le funzionalità omesse. Per esempio, il software di enquiry è fornito per scoprire la struttura e le informazioni di stato per vari tipi di risorsa comune, come i calcolatori (per esempio, versione del sistema operativo, configurazione hardware, carico, stato della coda dello scheduler), i sistemi di memorizzazione (per esempio, spazio disponibile) e le reti (per esempio, carico corrente e carico futuro previsto) e per raggruppare queste informazioni in una forma che facilita l’implementazione dei protocolli di livello più alto, specificamente al livello Resource.
2.2.2 Livello Connectivity
Il livello Connectivity definisce i protocolli di comunicazione e di autenticazione richiesti per le transazioni di rete, specifiche per le Griglie. I protocolli di
comunicazione, permettono lo scambio di dati fra le risorse a livello Fabric. I protocolli di autenticazione, si basano sui servizi di comunicazione per fornire meccanismi sicuri per verificare l’identità degli utenti e delle risorse. Questi due protocolli si basano su standard sviluppati nel contesto dell’insieme dei protocolli Internet.
I protocolli di autenticazione dovrebbero avere le seguenti caratteristiche:
• Singolo sign-on: gli utenti devono effettuare il “log on” (autenticazione)
solo una volta e poi hanno accesso a tutte le risorse di Griglia definite nel livello Fabric, senza un ulteriore intervento dell’utente.
• Delega: un utente deve poter dotare un programma della capacità di
funzionare a favore di quell’utente, di modo che il programma possa accedere alle risorse sulle quali l’utente è autorizzato. Il programma
dovrebbe anche permettere (facoltativamente) di delegare
condizionalmente un sottoinsieme dei suoi diritti ad un altro programma.
• Integrazione con le varie soluzioni locali di sicurezza: ogni sito o fornitore
di risorsa, può impiegare una qualunque soluzione locale di sicurezza, quindi le soluzioni di sicurezza di Griglia devono potere interoperare con queste varie soluzioni locali.
• Rapporti di fiducia basati sull’utente: affinché un utente usi risorse di
fornitori multipli, il sistema di sicurezza non deve richiedere che ogni fornitore di risorsa cooperi o interagisca con tutti gli altri. Per esempio, se un utente ha diritto ad usare i siti A e B, l’utente dovrebbe poter usare i siti A e B insieme senza richiedere che i gestori di sicurezza di B e di A interagiscano.
Globus Toolkit: per poter utilizzare le risorse della Grid gli utenti devono essere
autenticati ed autorizzati. Questi processi sono realizzati dai protocolli Grid Security Infrastructure (GSI) basati su chiave pubblica; questi protocolli, inoltre,
sono anche usati per la protezione delle comunicazioni. GSI si basa ed estende i protocolli Transport Layer Security (TLS) affrontando la maggior parte dei problemi elencati sopra, in particolare: singolo sign-on, delega, integrazione con varie soluzioni di sicurezza locali e rapporti di fiducia basati sull’utente.
2.2.3 Livello Resource
Il livello Resource si basa sui protocolli di comunicazione e di autenticazione del livello Connectivity per definire protocolli, API e SDK per la negoziazione sicura, il controllo e l’accounting di operazioni eseguite sulle singole risorse. Per l’implementazione dei protocolli a livello Resource si usano le funzioni definite a livello Fabric per l’accesso e il controllo delle risorse locali. Inoltre questi protocolli riguardano interamente singole risorse ignorando quindi problemi di stato globale.
Possono essere distinte due principali categorie di protocolli a livello Resource:
• I protocolli di informazione sono usati per ottenere informazioni sulla
struttura e sulla condizione di una risorsa. Esempi di queste informazioni possono essere la configurazione, il carico corrente e la politica di uso (per esempio, il costo) della risorsa stessa.
• I protocolli di gestione sono usati per negoziare l’accesso ad una risorsa
comune, specificando, per esempio, i requisiti della risorsa (compreso la prenotazione delle risorse e la qualità di servizio) e le operazioni da effettuare, quali la creazione di un processo o l’accesso ai dati.
A questo livello possono essere immaginati diversi protocolli; tuttavia, siccome i livelli Resource e Connectivity costituiscono il collo della clessidra, i protocolli si dovrebbero limitare ad un piccolo e focalizzato insieme. Infatti, dovrebbero essere scelti in modo tale da catturare i meccanismi fondamentali della condivisione su molti differenti tipi di risorse (per esempio, differenti sistemi di
gestione delle risorse locali), cercando di non vincolare i protocolli di alto livello che potrebbero essere sviluppati.
Globus Toolkit: è adottato un piccolo insieme di protocolli standard, in
particolare:
• Un Grid Resource Information Protocol (GRIP), attualmente basato sul
protocollo Lightweight Directory Access Protocol (LDAP), è usato per recuperare informazioni sulle risorse e per definire un modello delle informazioni. Le informazioni, usando il Grid Resource Registration Protocol (GRRP), sono registrate e mantenute in un Server di indicizzazione delle Risorse (GIIS).
• Il protocollo di gestione e di accesso alle risorse di Griglia (GRAM)
basato su HTTP è usato per l’allocazione delle risorse di calcolo e il controllo del calcolo su quelle risorse.
• Una versione estesa del File Transfer Protocol, il GridFTP, è un protocollo
di gestione per l’accesso ai dati; le estensioni includono l’uso dei protocolli di sicurezza a livello Connectivity.
2.2.4 Livello Collective
Mentre il livello Resource si occupa delle interazioni con una singola risorsa, il livello successivo dell’architettura contiene protocolli, servizi, API e SDK che non sono associati ad una risorsa specifica ma piuttosto sono globali e catturano le interazioni attraverso collezioni di risorse. Per tale motivo, questo livello dell’architettura viene riferito come il livello Collective. Poiché i componenti Collective si basano sui livelli Connectivity e Resource in corrispondenza del collo “stretto” del modello a clessidra, questi possono implementare un’ampia varietà di comportamenti di condivisione delle risorse senza disporre su queste ultime nuovi requisiti. Per esempio:
• I Directory service permettono ai partecipanti delle VO di scoprire
l’esistenza e/o le proprietà delle risorse delle VO. Un directory service può permettere ai relativi utenti di richiedere informazioni sulle risorse, effettuando la query per nome e/o per attributi quali, ad esempio, tipo, disponibilità o carico. I protocolli GRRP e GRIP sono usati per costruire le directory.
• Co-allocazione, scheduling e servizi di brokering permettono ai
partecipanti delle VO di richiedere l’allocazione di una o più risorse per uno scopo specifico e lo scheduling di job su risorse adatte.
• Monitoraggio e servizi di diagnostica supportano il monitoraggio delle
risorse delle VO per fallimenti, attacchi (“rilevazione di intrusioni”), sovraccarico e così via.
• Servizi di replicazione di dati supportano la gestione delle risorse di
memorizzazione delle VO per massimizzare le prestazioni di accesso ai dati rispetto alle metriche quali il tempo di risposta, l’affidabilità e il costo.
Globus Toolkit: in aggiunta agli esempi dei servizi elencati in questa sezione,
molti dei quali costruiti sui protocolli Resource e Connectivity, accenniamo al Monitoring and Discovery Service (MDS), che fornisce un sistema per ottenere informazioni sulle risorse.
2.2.5 Livello Application
Lo strato finale dell’architettura di Griglia contiene le applicazioni dell’utente eseguite nell’ambiente di calcolo fornito dalle VO. Le applicazioni sono costruite in termini dei servizi definiti a qualsiasi livello. Ad ogni livello, vengono definiti protocolli che forniscono l’accesso ad un certo servizio utile: gestione di risorse, accesso ai dati, scoperta delle risorse, e così via.
2.3 Il servizio MDS del GT2
MDS [MdsUg] è il servizio di informazione del Globus Toolkit; esso fornisce un sistema di directory service da utilizzare per ottenere informazioni sulle risorse presenti nella Griglia.
MDS è stato progettato per ottenere:
• buoni tempi di risposta a frequenti e complessi aggiornamenti,
• una buona efficienza e scalabilità per un ampio e crescente numero sia di
risorse da monitorare che di entità che richiedono informazioni,
• un accesso uniforme e flessibile alle informazioni, • un accesso a sorgenti di informazioni multiple, • un supporto per i dati dinamici,
• un mantenimento decentralizzato delle informazioni.
MDS utilizza un framework estendibile per gestire informazioni statiche e dinamiche sullo stato dei componenti della Griglia: reti, nodi computazionali, sistemi di memorizzazione dati, ecc. MDS utilizza Lightweight Directory Acces Protocol (LDAP) come back-end per ottenere tutte le informazioni: in questo modo viene fornita all’utente una base sulla quale è possibile implementare le funzionalità principali di MDS.
Figura 2.4: struttura dell’Information Service di Globus.
MDS ha una struttura gerarchica che si basa su 3 componenti principali:
• Grid Index Information Service (GIIS): è un servizio che incorpora un
insieme di GRIS server per fornire informazioni su di una intera organizzazione.
• Grid Resource Information Service (GRIS): è un servizio di
informazioni distribuito che può rispondere a richieste sullo stato di una particolare risorsa. Per esempio si possono ottenere informazioni quali: il nome dell’host (incluso il sistema operativo e la sua versione), il processore, la quantità di memoria a disposizione.
• Information Provider (IP): è un servizio locale ad una singola risorsa e
fornisce informazioni sulla risorsa stessa.
L’installazione di default del Globus Toolkit 2.2 crea un GRIS ed un GIIS per ogni macchina destinata a far parte della Griglia: è possibile però, tramite le API messe a disposizione, creare ulteriori servizi per gestire al meglio le varie situazioni locali che possono presentarsi.
2.3.1 Tipi di informazioni disponibili da MDS
In MDS, le interazioni fra i servizi di più alto livello (o gli utenti) ed gli IP, sono definiti in termini di due protocolli base:
1. un protocollo di registrazione (GRRP) per identificare le entità che partecipano al servizio d’informazione e
2. un protocollo di enquiry (GRIP) per il recupero delle informazioni su quelle entità, o attraverso query oppure mediante sottoscrizione.
Un IP usa il protocollo di registrazione per informare i servizi di più alto livello della sua esistenza; un servizio di più alto livello usa il protocollo di enquiry per ottenere le informazioni sulla risorsa monitorata da un IP.
MDS 2.2 memorizza le informazioni statiche (versione del sistema operativo, tipo di CPU, numero di processori, ecc.) e dinamiche (media del carico, coda dello scheduler, ecc.) descriventi gli host, le informazioni del sistema di memorizzazione (spazio disco disponibile, spazio disco totale, ecc.) e le informazioni di rete attraverso il Network Weather Service (larghezza di banda e latenza della rete, sia misurate che previste).
Un insieme di programmi di information provider è incluso con MDS 2.2. Questi programmi possono essere usati per pubblicare vari tipi di informazioni della Griglia in MDS.
2.3.2 Grid Index Information Service (GIIS)
MDS 2.2 fornisce una struttura per la costruzione di indici aggregati denominati GIIS. Essi possono essere legati tra di loro tramite messaggi di registrazione, in modo da formare una struttura gerarchica. Il GIIS accetta i messaggi di registrazione dal figlio GRIS o GIIS e fonde queste fonti di informazioni in uno
spazio unificato delle informazioni. Le ricerche del cliente possono ottenere informazioni da alcuni o tutti i figli di GIIS.
Mentre una configurazione tipica deve avere un GIIS che agisce come server nei confronti di uno o più GRIS clients, un GIIS può essere un client, un server o entrambi, a seconda del rapporto gerarchico (se c’è) con altre macchine host. Un GIIS fornisce un servizio di “caching”. Estrae le informazioni quando ciò viene richiesto da un cliente. Se le informazioni non sono più valide, o perché non sono più nella cache nel caso di informazioni statiche o perché il time-to-live è terminato nel caso di informazioni non statiche, invia la richiesta ai GIIS o ai GRIS sottostanti.
La funzionalità di GIIS è implementata come un back-end special purpose per un server OpenLDAP. Il front-end di OpenLDAP decodifica i messaggi di registrazione e li trasporta al back-end per eseguire tutte le azioni necessarie a costruire e mantenere gli indici di GIIS.
2.3.3 Grid Resource Information Service (GRIS)
MDS 2.2 include una struttura standard e configurabile di information provider denominata GRIS. Questa struttura è implementata come un server. Ogni macchina di MDS può eseguire un GRIS locale. Per default, un servizio GRIS è configurato automaticamente ed è assegnato alla porta 2135; inoltre può essere configurato per registrarsi con i servizi di indici aggregati (GIIS) in modo che questi servizi possano comunicare ad altri le informazioni sulla macchina.
Un GRIS autentica ed analizza ogni richiesta di informazioni ricevuta e poi spedisce quelle richieste ad uno o più information provider “locali”, a seconda del tipo di informazioni presenti nella richiesta. Successivamente, viene fatto il
merge dei risultati prima che questi vengano restituiti al cliente o al GIIS. Per ridurre efficientemente l’elaborazione della ricerca, i risultati restituiti da un information provider, prima di essere inviati alla loro destinazione, vengono filtrati dal GRIS per eliminare tutti gli oggetti che non sono uniformi allo spazio di ricerca del cliente e/o ai vincoli di filtro.
Per controllare l’invadenza delle operazioni GRIS e migliorare il tempo di risposta, i risultati di ogni fornitore possono essere memorizzati per un determinato periodo di tempo al fine di ridurre il numero di invocazioni del fornitore. Questo tempo di vita della memorizzazione è specificato da ogni fornitore come componente della configurazione locale.
Le implementazioni di GIIS e di GRIS in MDS 2.2 contano su un front-end LDAP per l’autenticazione e il filtraggio dei risultati. Entrambe possono coesistere all’interno dello stesso server. L’uso di un protocollo comune per le interazioni dell’indice e del fornitore promuove non soltanto l’interoperabilità, ma facilita anche l’implementazione.
2.3.4 Information Provider (IP)
Un IP, ogni volta che viene interrogato dal GRIS, fornisce informazioni sulla risorsa da esso controllata. All’installazione MDS crea un insieme predefinito di IP; tuttavia un utente può crearne di nuovi per monitorare particolari risorse, ad esempio i file contenuti in una directory.
2.4 Da GT2 a GT3
GT2 e GT3 [GTfaq] sono due versioni del Globus Toolkit. Il Globus Toolkit è un software open source e open architecture che contiene gli strumenti che rendono più facile lo sviluppo di infrastrutture di Griglia e applicazioni per Griglia. GT2 e GT3 forniscono entrambi un insieme di servizi di Griglia per la sicurezza,
l’amministrazione delle risorse, l’accesso all’informazione e l’amministrazione di dati. Tutti i componenti forniti da GT2 per la costruzione dell’infrastruttura di Griglia e per lo sviluppo di applicazioni per Griglia rimangono disponibili in GT3. Specificatamente, esso include il software che fornisce la sicurezza di Griglia (GSI), la sottomissione e il controllo di job remoti (GRAM) e il trasferimento sicuro di dati ad elevate prestazioni (GridFTP). Le implementazioni fornite in GT2 sono state progettate prima di OGSA e OGSI, mentre molte implementazioni fornite in GT3 sono OGSI-compliant. Un servizio è OGSI-compliant se è conforme alle specifiche dei Grid Service.
Mentre i servizi chiave forniti da GT3 sono ora OGSI-compliant e implementati in Java, per gli altri servizi, ad esempio GridFTP, rimangono le implementazioni di GT2 ad elevate prestazioni scritte in C; con le successive versioni tutti i servizi di GT migreranno nella struttura di OGSA. Il primo e principale beneficio di usare GT3 rispetto a GT2 è che GT3 implementa gli standard che sono stati adottati dalle Comunità di e-Commerce e di e-Science. Questa standardizzazione dei protocolli di Griglia è la chiave per supportare l’interoperabilità attraverso la Griglia ed è vista come il futuro del Grid computing. L’architettura OGSA e l’infrastruttura OGSI forniscono una struttura comune per i servizi di Griglia, in modo da facilitare lo sviluppo di nuovi servizi OGSI-compliant.
2.4.1 Come si differenzia MDS da GT2 a GT3
Le caratteristiche fornite in GT2 dallo MDS sono ora fornite in GT3 da un insieme di servizi di Griglia costruiti per il framework OGSI. Una volta usati insieme con i meccanismi standard di OGSI, che forniscono un modo uniforme di interrogare ogni servizio di Griglia sulle relative configurazioni ed informazioni di stato, questi servizi forniscono ed estendono tutte le capacità di MDS-GT2, tutto all’interno di un ambiente OGSA-compliant.
Figura 2.5: struttura dell’Index Service.
Il nucleo OGSI del GT3 prevede una collezione di informazioni, Service Data, disponibile per tutti i Grid Service; ogni servizio ha così a disposizione metodi standard per l’interrogazione e la pubblicazione di dati. I Service Data, in pratica, sostituiscono le funzionalità del GRIS di MDS-GT2, sostituendo i meccanismi di sicurezza GSI-enabled di LDAP con quelli di binding di OGSA.
Per facilitare lo sviluppo di Service Data Providers, GT3 fornisce un’architettura di Information Provider simile a quella usata in GT2.
L’Index Service del GT3 fornisce un servizio di aggregazione delle informazioni che è più estendibile del GIIS di GT2 [GTfaq]. Per concludere, OGSI fornisce ulteriori servizi importanti: un meccanismo per i servizi di notifica dei cambiamenti negli elementi service data, permettendo che i dati siano inseriti o eliminati dagli indici.
In MDS-GT2 i dati sono memorizzati nel formato LDIF, specificato da LDAP, in particolari server LDAP; in GT3 i dati sono scambiati, ricevuti e pubblicati in formato XML, utilizzando differenti depositi di dati, tra cui database XML e filesystem cache.
I clients dello MDS-GT2, quindi, non potranno comunicare con gli Index Service di GT3 o usare le caratteristiche dei Service Data di GT3 senza le necessarie modifiche.
2.5 Approcci alternativi a MDS
All’interno di Globus, MDS è stato, fin dalla sua concezione, uno dei componenti principali. Per tale motivo ha subito molte modifiche al fine di ridurre i suoi limiti e quindi adattarlo alle esigenze che di volta in volta si presentano. In questa sezione vengono descritti alcuni approcci alternativi.
2.5.1 Relational GIS.
Questo approccio [RGIS], basato sul modello dei dati relazionale, è stato seguito nel progetto Unified Relational Grid Information Services (URGIS) [URGIS] svolto in collaborazione tra la NorthWestern University e la Indiana University. Nasce dalla necessità di avere un sistema potente, flessibile, con un linguaggio di query complesso e che supporta la distribuzione dei dati.
I limiti principali di MDS2 derivano dalla mancanza di un vero e proprio linguaggio di query. LDAP è un linguaggio procedurale, che manca di una rigorosa descrizione semantica e richiede che gli utenti conoscano in anticipo la struttura dell’albero delle directory, a differenza di un linguaggio dichiarativo, come SQL, che affermi cosa può essere recuperato e non come. La sintassi di un linguaggio di query stile LDAP richiede che gli utenti dichiarino lo spazio di ricerca, cioè il nodo origine da cui iniziare la query. Gli attributi che appaiono nella query devono avere un percorso relativo al nodo origine. LDAP è veloce
database per rispondere rapidamente, mentre rispondere alle altre query, delle quali non si conosce la struttura, può essere molto costoso.
I database relazionali invece permettono di costruire e gestire indici, in modo separato, sugli attributi, permettendo così di ottimizzare le query per renderle più efficienti.
Un vantaggio nel seguire l’approccio dello RGIS è che gli utenti possono scrivere query SQL per cercare composizioni complesse di risorse, come ad esempio gruppi di host e di risorse di rete, che soddisfano determinati requisiti collettivi. Il costo di queste query è dato dal gran numero di giunzioni presenti in esse. Il problema del costo è stato, in parte, risolto introducendo le query non deterministiche. Fondamentalmente, una query non deterministica permette all’utente (e allo RGIS) di controbilanciare tra il tempo di esecuzione di una query o il carico che essa pone su un server RGIS e il numero dei risultati restituiti.
Un’altra tecnica utilizzata per diminuire i tempi di risposta è quella di adottare query approssimate, nelle quali il numero delle giunzioni è ridotto mediante tecniche di riscrittura delle query stesse effettuate dal gestore delle query. Questo tipo di query, però, introduce principalmente due restrizioni. La prima è che i risultati restituiti da una query approssimata sono un sottoinsieme di quelli della query originale. Pertanto, è possibile che nessun risultato sia restituito anche nel caso in cui esistano dei risultati per una data query. La seconda restrizione è che non tutte le query possono essere approssimate; infatti ci sono situazioni nelle quali non c’è modo di evitare o minimizzare l’uso delle giunzioni.
2.5.2 Knowledge Grid
Le principali applicazioni industriali, scientifiche e commerciali necessitano di analizzare ampi insiemi di dati contenuti in diversi siti distribuiti geograficamente. La distribuzione geografica e l’ampia quantità di dati coinvolti spesso obbligano i progettisti ad usare sistemi paralleli e distribuiti. La Grid può
giocare un ruolo significativo nel fornire un effettivo supporto computazionale per applicazioni distribuite di data mining e knowledge discovery.
K-Grid (Knowledge Grid) [KGrid] è un sistema software, progettato presso lo ICAR-CNR [ICAR], che supporta applicazioni geograficamente distribuite ad alta performance di knowledge discovery.
L’architettura K-Grid è definita sui servizi e sugli strumenti di Grid che usa per costruire servizi specifici per l’estrazione di conoscenza. Seguendo un approccio integrato all’architettura di Grid, questi servizi possono essere sviluppati in diversi modi. La versione attuale usa il Globus Toolkit 2.
Il servizio che ci interessa particolarmente è il Knowledge Directory Service (KDS); questo servizio estende MDS di Globus ed è responsabile del mantenimento dei metadati che descrivono tutti i dati e gli strumenti usati in K-Grid. Le informazioni dei metadati sono rappresentati da documenti XML e memorizzati nel Knowledge Metadata Repository (KMR). Per quanto riguarda i dati da elaborare, è più efficiente mantenerli in un contenitore per la conoscenza scoperta, Knowledge Base Repository (KBR), piuttosto che mantenerli in un contenitore ad hoc.
A differenza dello MDS in cui i metadati sono rappresentati da entry nel Directory Information Tree (DIT) mantenuto dal server LDAP, in K-Grid i metadati sono rappresentati usando sia LDAP che XML. Il KMR è implementato dalle entry LDAP e da documenti XML; la porzione LDAP è usata come primo punto di accesso per informazioni più specifiche contenute dai documenti XML.
2.5.3 Grid Monitor
Grid Monitor [MOS02, GSM] è un prototipo che permette il monitoraggio dei server di informazione della Grid UK. Questo progetto è sviluppato presso il Central Laboratory for the Research Councils (CLRC) come parte del programma UK e-science. Il prototipo software è una utility web, a tre livelli, progettata per aiutare gli amministratori e gli utenti di Griglia a tenere traccia
della disponibilità e del carico delle risorse di un sito Grid. L’architettura del prototipo comprende i seguenti elementi:
• Web Clients (applet per interfaccia utente), • Web Server/servlet,
• Database relazionale (deposito per i dati storici e le registrazioni dei siti
Grid).
Quando un’organizzazione si registra allo UK Grid Support Centre vengono richiesti i metadati che descrivono il sito. Queste informazioni sono memorizzate all’interno di un database centrale che agisce come una sorgente di dati per il software di controllo. Successivamente alla registrazione, il server MDS dell’organizzazione, il GIIS di livello più alto, è collegato direttamente al Web server. Il Web server utilizza un database locale che agisce sia da cache nei confronti del database centrale, fornendo informazioni sul sito direttamente al servlet, sia da deposito per i dati recuperati. Il servlet legge i dati di registrazione di un sito dal database locale; questi sono usati per connettersi, periodicamente, al server per determinare se il servizio MDS è disponibile. Eventuali fallimenti sono registrati nel database locale.
L’interfaccia utente utilizza le applet java che, sotto normali vincoli di sicurezza, possono solo comunicare con il server dal quale sono state create. Quando l’applet viene eseguita visualizza una mappa della UK che evidenzia i server MDS registrati. Lo stato di ogni server MDS è mostrato dal colore dell’icona la quale rappresenta il sito sulla mappa. L’utente cliccando sull’icona ottiene maggiori informazioni sulle risorse di quel sito. Inoltre l’utente possiede una lista dei siti di cui è informato. Tale lista viene aggiornata ogni qualvolta l’utente effettua una richiesta al Web server. L’utente, oltre al risultato della richiesta, riceve anche la nuova lista che verrà utilizzata per aggiornare la mappa.
2.5.4 Software Agents
Questo progetto integra lo MDS di Globus Toolkit 2 con un sistema esistente basato su agenti software [KCS] per offrire il servizio di informazione di Grid. L’architettura del sistema è simile a quella di MDS 2.2; ad ogni risorsa è associato un GRIS che comunica con il GIIS non più direttamente ma attraverso il Local Resource Manager. L’agente si interfaccia con il GIIS che contiene le informazioni di ogni risorsa del proprio dominio amministrativo.
Quando un utente desidera eseguire un’applicazione sulla Griglia invia una richiesta all’agente. Tale richiesta consiste di un’applicazione e dei requisiti richiesti dalla applicazione stessa. L’agente comunica con il GIIS per sapere se sono disponibili le risorse adatte ad eseguire l’applicazione; altrimenti la richiesta viene inviata all’agente di livello superiore o inferiore nella gerarchia. Nel caso in cui il GIIS non avesse le informazioni necessarie per rispondere alla richiesta dell’agente comunicherebbe con i Local Resource Manager, che mantengono le informazioni all’interno di una propria cache e interrogano periodicamente i GRIS per aggiornare tali informazioni. Pertanto, rispetto a MDS2, il tempo di risposta è migliorato e la capacità di schieramento è massimizzata.
L’agente inoltre è in grado di valutare le prestazioni che l’applicazione avrà su tali risorse.
2.6 Conclusioni
In questo capitolo è stato introdotto il Globus Toolkit, un’infrastruttura software che permette alle applicazioni di gestire le risorse di calcolo distribuite ed eterogenee come una singola macchina virtuale. Il toolkit, come già visto, consiste di un insieme di componenti che implementano servizi di base come la sicurezza, la gestione delle risorse, la comunicazione ed altro. In particolare, è stato analizzato il funzionamento del servizio MDS che fornisce accesso alle informazioni sulla struttura e sullo stato delle risorse di Grid. Inoltre, sono state
messe in evidenza le differenze di implementazione di questo servizio in GT2 e in GT3. Per concludere, sono stati discussi alcuni approcci alternativi allo MDS.
