Capitolo 4
Descrizione
del
progetto
GRid
Application Service Provision (GRASP)
4.1 Introduzione
In questo capitolo mostreremo un caso pratico di Resource Management in ambiente Grid. Il caso di studio trattato si inserisce nel contesto di un progetto europeo chiamato GRid Based Application Service Provision (GRASP). Le
finalità del progetto GRASP sono quelle di studiare, progettare, sviluppare e validare un’infrastruttura innovativa per l’Application Service Provision (ASP) basata su tecnologie Grid e commodity (come Microsoft .NET, Web Services, XML, SOAP, ecc.).
Il progetto GRASP si pone l’obiettivo di realizzare un middleware ASP caratterizzato da un alto livello di scalabilità, affidabilità e sicurezza, funzionalità di accounting, qualità del servizio e amministrazione delle risorse che rappresentano l’avanguardia tecnologica attualmente disponibile.
Il progetto GRASP costituisce una grossa innovazione nel settore dei servizi ASP sia da un punto di vista commerciale che tecnologico. Questa innovazione è realizzata attraverso la fornitura di servizi innovativi a supporto di modelli di business per le Organizzazioni Virtuali.
Gli obiettivi principali sono:
• Progettare ed implementare un’architettura a livelli per la fornitura di servizi usando le tecnologie Grid, per superare la debolezza delle attuali soluzioni ASP riguardo alla gestione delle risorse, la sicurezza, la definizione di un Service Level Agreement (SLA: è l’accordo per la fornitura di un servizio che si instaura tra il fornitore ed il richiedente) e meccanismi di addebito dell’uso delle risorse.
• Analizzare e valutare l’interoperabilità fra il middleware Grid, le tecnologie “commodity” quali Microsoft .NET, Web Services, Microsoft Passport e Halistorm.
• Esaminare e valutare tre differenti business models che utilizzano tecnologie GRID: classico ASP (modello one-to-many con un solo fornitore di servizi ASP e tanti client); modello many-to-many (dove le risorse sono eterogenee e distribuite ed inoltre i client possono rendere disponibili le loro risorse allo scopo di ricevere un compenso); modello federato (dove il fornitore di servizi è costituito da una federazione di ASP).
• Progettare tre applicazioni GRID-aware, sviluppate utilizzando l’architettura GRASP, allo scopo di validare l’efficacia del middleware realizzato.
• Definire metodologie e tecniche per rendere Grid-aware applicazioni già esistenti.
La Figura 1 illustra le attività svolte dalle varie componenti e servizi presenti nell’ambiente GRASP e le loro interazioni. La progettazione e
l’implementazione del componente Service Locator costituisce l’oggetto dello studio condotto nella presente tesi.
Figura 4.1: Componenti e servizi dell’ambiente GRASP e loro interazioni L’ambiente GRASP è strutturato secondo due livelli:
- Applicazione. E’ il livello più esterno in Figura 1 nel quale vengono effettuate le richieste da parte degli utenti (client). A questo livello sono previste funzionalità che permettono alle varie componenti di interagire tra di loro in modo da soddisfare le richieste ricevute da parte dei client. Inoltre vengono presi in considerazione degli aspetti che devono essere trattati interamente (o in parte) a questo livello come:
Service Level Agreement (SLA) che viene trattato anche a Livello Servizio.
Sicurezza, che prevede l’autenticazione dell’utente tramite un identificatore (ID) e password e la concessione di autorizzazioni (complete o parziali) per l’accesso alle risorse.
Ripristino del sistema in seguito ad un fallimento.
Billing (fatturazione) in seguito all’utilizzo delle risorse per l’esecuzione di un Application Service (AS).
- Servizio. E’ il livello più interno in Figura 4.1 in cui vengono rappresentate le funzionalità offerte dalle componenti a livello Applicazione. Quindi questo livello può essere considerato come il “core” dell’ambiente GRASP. Le interazioni tra le componenti descritte a questo livello vengono identificate in maniera diversa secondo l’obiettivo preposto. Parliamo di:
Service Location per individuare un servizio ed i relativi fornitori.
Service Instantiation per istanziare un’istanza di un servizio.
Service task-based Interactions per gestire le interazioni tra le componenti necessarie per eseguire un’istanza di un servizio.
Service Orchestration per coordinare l’esecuzione dei sottoservizi costituenti il workflow di un servizio composito, cioè un servizio composto da più sottoservizi detti workflow del servizio.
Event Handling per la gestione degli eventi.
A livello Applicazione è presente il componente “Application User”, tramite il quale un utente può richiedere un Application Service (AS) che è costituito da uno o più servizi atti a fornire specifiche funzionalità. Un AS per la fornitura del
servizio richiesto riunisce in un'unica entità le componenti software, l’infrastruttura di calcolo (risorse hardware e di rete) ed i costi relativi all’erogazione del servizio stesso.
L’ambiente GRASP permette all’utente di interagire con un AS tramite delle apposite Graphic User Interface (GUI). Tali interfacce rappresentano
sostanzialmente il modo in cui un AS si presenta all’utente finale.
Nelle Figure 4.2 e 4.3 sono mostrate le interazioni tra le componenti a Livello Applicazione ed a Livello Servizio. Queste figure sono state distinte l’una dall’altra solo per ragioni di chiarezza, cioè si è voluto far distinzione tra un livello (Livello Applicazione) in cui abbiamo l’applicazione esposta all’utente finale ed un livello (Livello Servizio) in cui abbiamo i fornitori dei servizi semplici (utilizzati per comporre un Application Service).
In Figura 4.2 sono schematizzate le interazioni tra le 5 componenti che realizzano il livello Applicazione. Ciascuna componente implementa le seguenti funzionalità:
Figura 4.2: Componenti e loro interazioni a livello Applicazione nell’ambiente GRASP Application Creator Application Provider Resource Provider Application User Application Locator Crea il servizio factory Crea applicazione Registra applicazione Trova applicazione
Interazione con il servizio Accordo sulla
fornitura del servizio Gestione e
Monitoring istanza
Application Creator. Genera il software applicativo per la fornitura di un servizio e le relative GUI per un Application Provider. In particolare:
• Genera le informazioni che descrivono il software applicativo e le relative GUI per la fornitura di specifici servizi da parte di un Application Provider.
• Genera il servizio factory per il Resource Provider (Service Host). Il Service Host è il “luogo” preposto alla gestione dell’esecuzione del servizio.
• Fornisce allo Application Provider la descrizione dell’applicazione creata. Application User. É l’utente finale che fa la richiesta di un servizio. Il suo ruolo può essere svolto anche da un Application Provider che sottomette una richiesta di un servizio ad un altro Application Provider. In particolare l’Application User: • Fornisce, tramite una GUI, una descrizione del servizio che intende
richiedere.
• Richiede il servizio allo Application Locator che effettuerà una ricerca del servizio richiesto all’interno del Service Directory (vedi pagina 11). • Seleziona un Application Provider dai risultati della ricerca restituita dallo
Application Locator.
• Negozia il Service Level Agreement (SLA) con lo Application Provider. • Richiede lo Application Service allo Application Provider.
• Può interagire con il servizio in esecuzione sul Resourse Provider (Service Host).
• Riceve informazioni descriventi lo stato del servizio attraverso lo Application Provider e/o il Resourse Provider (Service Host).
• Può eseguire la terminazione del servizio.
Application Locator. Le sue funzionalità sono implementate interamente a livello Servizio dal Service Locator (vedi pagina 8). Si basa su una directory che agisce come un service broker per la ricerca dei fornitori dei servizi richiesti. In particolare:
• Genera il Service Directory (nel seguito anche detta directory).
• Comunica allo Application User del proprio ambiente virtuale l’esistenza del Service Directory. Questo consente ad un Application User di fare la richiesta di un servizio allo Application Locator prima ancora che allo Application Provider.
• Riceve dallo Application Provider le descrizioni delle applicazioni da memorizzare nella directory.
• Gestisce le informazioni contenute all’interno della directory (inserisce, cancella, aggiorna le descrizioni dei servizi ed i puntatori ai rispettivi provider).
• Riceve le richieste dallo Application User e dallo Application Provider. Questo secondo caso si ha quando il Service Provider subappalta un servizio ad un altro Service Provider dello stesso o di un altro ambiente virtuale.
• Riceve le richieste da un altro Application Locator. In questa maniera una richiesta da parte di un cliente viene soddisfatta effettuando una ricerca distribuita su ogni Service Directory (una per ogni VO) appartenente a ciascuna VO che costituisce l’ambiente GRASP.
• Effettua una ricerca all’interno della directory e inoltra la richiesta del servizio ad altri Applicaton Locator di altri ambienti virtuali.
• Restituisce al richiedente una lista di risultati contenente i provider del servizio richiesto.
Application Provider. É un Application Service Provider (ASP) che fornisce il servizio richiesto. In particolare:
• Genera tramite lo Application Creator un Application Service.
• Descrive dettagliatamente i Servizi costituenti un Application Service. • Pubblica lo Application Service tramite lo Application Locator.
• Riceve la richiesta di Application Service dallo Application User (o da altri provider).
• Negozia il Service Level Agreement (SLA) con lo Application User. • Negozia il Service Level Agreement con il Resource Provider. In tal modo
il Service Provider (vedi pagina 8) si accorda con il Resource Provider sulle “modalità” di esecuzione di un servizio ed inoltre verifica la disponibilità delle risorse necessarie per l’esecuzione.
• Attiva un’istanza di un servizio eseguendola sul Resource Provider (Service Host).
• Restituisce un identificatore all’istanza del servizio all’Application User. • Può subappaltare i servizi, ed inoltre quando è richiesto un servizio
composito, delega al Service Orchestrator il compito di effettuare l’esecuzione ed il monitoraggio dei sottoservizi che lo compongono. • Agisce come Application User per servizi subappaltati.
• Monitorizza l’istanza di un servizio in esecuzione sul Resource Provider (Service Host).
• Gestisce l’istanza di un servizio in esecuzione sul Resource Provider (Service Host).
• Può richiedere la terminazione dell’esecuzione dell’istanza del servizio richiesto.
• Emette la fattura al richiedente per l’utilizzo del servizio. • Paga il Resource Provider per l’uso delle risorse di calcolo.
Resource Provider. Mette a disposizione le risorse di calcolo per l’esecuzione delle istanze del servizio richiesto per conto di un Application Provider. In
• Fornisce una descrizione delle risorse utilizzabili.
• Negozia il Service Level Agreement con lo Application Provider. • Riceve le richieste dallo Application Provider.
• Istanzia il servizio.
• Esegue il servizio interagendo con lo Application User (Service Requestor).
• Gestisce il servizio, provvedendo anche alla terminazione.
• Notifica allo Application Provider lo stato del servizio e verifica che i requisiti di QoS siano rispettati.
• Emette la fattura allo Application Provider.
In Figura 4.3 vengono mostrate le interazioni tra le componenti presenti a livello Servizio.
Figura 4.3: Componenti e loro interazioni a livello Servizio nell’ambiente GRASP
Sino ad ora abbiamo parlato di Application Service e lo abbiamo descritto come un insieme di Servizi ognuno dei quali fornisce una specifica funzionalità. Dobbiamo distinguere due casi: nel primo caso un singolo Servizio fornisce una
Service Instantiator Service Orchestrator Service Provider Service Locator Service Host Service Requestor Coordina i sottoservizi Crea l’istanza di un servizio Monitorizza/ Gestisce il servizio Individua il service provider Interazione con il servizio Accordo sulla fornitura del servizio Registra il servizio
specifica funzionalità, mentre nel secondo caso un Servizio che fornisce una funzionalità può essere un Servizio composito, ovvero composto da più sottoservizi descritti tramite un apposito workflow.
Le componenti mostrate in Figura 4.3 svolgono i seguenti ruoli:
Service Requestor (agisce per conto di un Application User o per conto di un Service Provider). Implementa le funzionalità necessarie per invocare e per interagire con un servizio.
Service Provider (utilizzato per gestire il servizio, autorizzare l’accesso alle risorse utilizzate per l’esecuzione del servizio, addebitare l’uso delle risorse di calcolo, etc.).
Implementa le funzionalità necessarie per fornire uno specifico servizio separatamente dalle funzionalità supportate dal Service Orchestrator (coordinazione dell’esecuzione dei sottoservizi e delle loro interazioni) e dal Service Instantiator (creazione di nuove istanze di un servizio). In particolare:
• Tiene traccia dell’identificatore dell’istanza (Service Reference) di un servizio in esecuzione.
• Assicura che i sottoservizi richiesti siano disponibili.
• Aggiorna i “puntatori” dei servizi presenti all’interno delle GUI utente (client) se il servizio è migrato da un Service Host ad un altro oppure se è stato riattivato su un Service Host diverso da quello su cui era in esecuzione al momento della sua interruzione.
Service Host. Viene utilizzato per allocare le risorse necessarie per l’esecuzione di un servizio e per eseguire il servizio richiesto. Inoltre esegue il servizio factory fornito dallo Application Creator.
Service Locator. Viene utilizzato per individuare una istanza di un servizio richiesto. Implementa la funzionalità necessaria per individuare e gestire le descrizioni dei servizi.
Service Instantiator. Viene utilizzato per creare nuove istanze di un servizio. A fronte di richieste provenienti dal Service Provider, in particolare:
• Gestisce il Service Instance Pool (vedi pag. 13), se richiesto.
• Mantiene la registrazione delle istanze (attive ed inattive) del servizio appartenente all’organizzazione virtuale in cui è eseguito.
• Genera, per i servizi che vengono subappaltati, delle istanze con lo stato specificato. Con ciò intendo dire che quando si subappalta un servizio lo Istantiator crea una nuova istanza che dovrà migrare da una VO ad un’altra e per far questo è necessario che le venga attribuito lo stato della vecchia (istanza).
Service Orchestrator. Coordina l’esecuzione del service workflow per conto di un Service Provider, ed in particolare:
• Attiva l’esecuzione dei sottoservizi costituenti un servizio composito. • Coordina l’esecuzione dei sottoservizi e le loro interazioni.
• Monitorizza lo stato del processo che esegue il servizio per conto del Service Provider.
L’ambiente GRASP prevede un componente per la gestione degli eventi e dei messaggi (event management in Figura 4.1). Tale componente gestisce la comunicazione asincrona tra le varie entità nel sistema. Le principali entità presenti nel sistema sono:
Service Instances sono costituite dai processi che eseguono le istanze dei servizi. Interagiscono con il Service Requestor (tramite il Service Host) e
comunicano al Service Provider (tramite il Service Host) i risultati dell’elaborazione.
Service Description, sono costituiti dai service workflow descriventi servizi compositi.
Factories, sono i servizi che permettono l’attivazione dell’esecuzione di istanze di un servizio.
Service Directories, memorizzano le descrizioni dei servizi ed i puntatori ai relativi provider.
Service Registry, memorizzano le descrizioni dell’istanza del servizio ed il puntatore allo host su cui l’istanza è eseguita. Queste entità saranno in seguito distinte in Instance Registry e Local Registry (vedere Figura 4.5). Nel seguito focalizzeremo il nostro studio sul Service Location in quanto oggetto principale della presente tesi.
4.2 Service Location
Figura 4.4: Service Location: componenti e loro interazioni Crea una descrizione del servizio Service Provider service description Service Requestor Service
Locator directory service
Registra il servizio Fornita dal provider descrizione restituita dal locator Richiesta di un servizio/Restituzione di servizi attinenti Aggiornare/ gestire lookup
Il termine Service Location viene usato per riferirci ad un processo che individua la locazione dei servizi ed i relativi Service Provider. Nel contesto GRASP, questo processo coinvolge entità che interagiscono nel modo mostrato in Figura 4.4.
Il Service Provider produce la descrizione dettagliata dei servizi che fornisce. A tal fine utilizza un appropriato “service description language”, quale ad esempio il GSDL[] (un’estensione del WSDL), conforme alle specifiche OGSA [3] per descrivere i servizi Grid.
Il Service Requestor produce e comunica al Service Locator una service request. Le service request sono delle queries sulle funzionalità, sull’uso e sulle caratteristiche di sicurezza e sulle informazioni di accounting del servizio richiesto.
Il Service Locator si occupa di elaborare le service request, di cercare nel Service Directory la descrizione del servizio richiesto e di restituire al Service Requestor una lista di servizi corredati dai puntatori ai relativi provider e da informazioni ausiliarie, come ad esempio una stima di quanto il servizio rispetta le caratteristiche richieste.
4.3 Interazione tra le componenti dell’ambiente GRASP
Al fine di dare una visione completa delle interazioni esistenti tra le varie componenti dell’ambiente GRASP durante l’esecuzione di una richiesta di un servizio, le stesse componenti prima descritte sono state riunite e mostrate in Figura 4.5.
Rispetto alle figure precedenti, in Figura 4.5 non è presente la componente Resource Provider, ma le sue funzionalità vengono svolte dalle componenti Service Host e Service Instantiator che interagiscono con le entità Istance Registry, Local Registry, Istance Pool e factory. Il Service Instantiator è utilizzato per generare una nuova istanza di un servizio, mentre il Service Host è utilizzato per allocare le risorse necessarie all’istanza del servizio per la sua
esecuzione. Per quanto riguarda le entità con cui questi componenti interagiscono possiamo dire che:
- Instance Registry è un file in cui il Service Provider memorizza le istanze (service reference) restituitegli dal Service Instantiator dell’ambiente virtuale in cui risiede e dai Service Instantiator di altri ambienti virtuali.
- Local Registry è un file in cui il Service Host memorizza le istanze locali all’ambiente di esecuzione, ovvero le istanze che vengono eseguite sullo stesso ambiente in cui sono state generate.
- Instance Pool contiene le istanze non attive di uno o più servizi. Le istanze contenute nello Instance Pool sono istanze “dormienti” che sono in attesa di essere svegliate. Generalmente l’attivazione di una applicazione per l’esecuzione di un servizio richiede un consistente overhead a tempo di esecuzione, pertanto l’uso dello Instance Pool è importante per ridurre tale overhead. Grazie allo Instance Pool è possibile applicare la tecnica dello instance pooling. Questa tecnica permette il riuso delle istanze di un servizio in stato di idle che sono in attesa di ricevere un nuovo lavoro. Ciò elimina lo overhead dovuto alla ripetuta creazione di tali istanze.
- Factory è un servizio (OGSA) adibito alla generazione delle istanze di un servizio.
Crea applicazione Service Directory Trova applicazione per l’utente Application Creator Application Provider Service Provider Application Locator Service Locator Service Description Application User Service Requestor Service Host Instance Registry Service Instantiator Service factory Service Instance Local
Registry Instance Pool
Registra applicazione Accordo sulla fornitura del servizio Gestione servizio Monitoring servizio Crea factory Update/manage lookup Descrizione Servizio Crea descrizione Servizio Registra istanza Interazione con il servizio Richiede istanza or run Invoca factory Crea istanza Seleziona Istanza non attiva Riusa istanza Registra
istanza Rimuove istanza Fornisce dettagli di accesso Istance host Registra il servizio Richiesta/restituzione di matching services
Prima di illustrare una generica interazione tra le componenti di Figura 4.5 per soddisfare la richiesta di un servizio, è utile fornire una descrizione della fase di creazione di un Application Service.
La creazione di un Application Service è richiesta allo Application Creator dallo Application Provider. Il Creator genera lo Application Service, la sua descrizione, ed un servizio factory (sempre attivo) che sarà passato al Service Host e verrà utilizzato per l’attivazione di una istanza di un servizio. Lo Application Service e la sua descrizione sono poi passati allo Application Provider che provvederà a registrarli nel Service Directory tramite lo Application Locator. Un Application Service è costituito da uno o più servizi, per questo motivo quando viene passato dallo Application Creator allo Application Provider entra in funzione il Service Provider il quale provvederà a dettagliare ulteriormente la descrizione del Servizio costituente l’Application Service. Per far questo il Service Provider invoca il Service Description che modificherà la descrizione del servizio secondo le direttive ricevute e successivamente la invierà al Service Locator il quale provvederà a registrarla nel “proprio” Service Directory.
E’ importante precisare che:
1. Se il servizio è composito, il Service Provider memorizza nel Service Description il workflow descrivente il servizio stesso.
2. Il Service Directory è creato dal Service Locator nel momento in cui quest’ultimo riceve la “prima” richiesta di registrazione di un servizio da parte del Service Provider. In questa fase il Service Locator comunicherà l’esistenza del Service Directory al Service Requestor del proprio ambiente virtuale. Ciò consentirà al Requestor di inviare la richiesta di un servizio al Service Locator prima ancora che al Service Provider.
Una generica interazione tra le componenti GRASP è iniziata dal Service Requestor che invia una richiesta di servizio al Service Locator. Quest’ultimo
cerca la descrizione del servizio nel proprio Service Directory ed invia la richiesta ad altri Service Locator di altri ambienti virtuali. Il risultato dell’interazione tra i Service Locator dei vari ambienti virtuali produce una lista contenente i riferimenti ai Service Provider che forniscono i servizi corrispondenti a quello richiesto. Tale lista sarà passata al Service Requestor che sceglierà il Service Provider a cui richiedere il servizio. (Se il servizio non esiste, lo Application Locator provvederà ad inviare un messaggio di errore al Service Requestor.)
Scelto il Provider, il Service Requestor gli invia la richiesta. In questa fase le due componenti negoziano il Service Level Agreement tramite una GUI fornita dal Provider stesso. Una volta che l’accordo è stato raggiunto, il Service Provider può passare alla fase di esecuzione del servizio in cui si serve delle componenti Service Instantiator e Service Host, il primo per farsi restituire l’istanza del servizio ed il secondo per negoziare il Service Level Agreement e per mandare in esecuzione l’istanza.
Prima di chiedere al Service Instantiator di creare una istanza di un servizio, il Service Provider negozia il Service Level Agreement con il Service Host. Questo gli permette di essere a conoscenza dello stato delle risorse. Infatti, se fossero tutte occupate, esso subappalta il servizio ad altri Service Provider di altri ambienti virtuali. In tal caso provvede a modificare la descrizione del servizio aggiungendo il puntatore al Provider a cui il servizio è stato subappaltato, e tale descrizione sarà passata al Service Locator che provvederà ad aggiornarla nel Service Directory.
Se l’accordo con il Service Host è stato raggiunto, il Service Provider invoca il Service Instantiator che può trovarsi di fronte a due possibili situazioni:
1. L’istanza di servizio è stata creata in precedenza. In tal caso il Service Instantiator provvede a selezionare l’istanza di tale servizio dallo Istance Pool. L’istanza selezionata sarà poi inviata al Service Istance che provvederà alla sua esecuzione.
2. L’istanza di servizio non esiste. In tal caso il Service Instantiator invoca il servizio factory, che genererà la nuova istanza del servizio. Quest’ultima sarà poi inviata al Service Istance che provvederà alla sua esecuzione.
Dopo che l’istanza è stata creata/selezionata il Service Instantiator restituirà al Service Provider un Service Reference (o istanza) che potrà memorizzare nel suo Instance Registy. È importante per il Service Provider mantenere in un file i service referenze, poiché potrebbe aver iniziato la creazione di differenti istanze dello stesso servizio in vari ambienti di esecuzione, e tali istanze potrebbero essere utilizzate dallo stesso o da differenti Service Requestor. Una volta ricevuta l’istanza, il provider la invierà al Service Requestor appropriato e comunicherà al Service Host di eseguirla. Quest’ultimo provvederà prima ad allocare tutte le risorse necessarie all’istanza del servizio e poi a comunicare al Service Instance di iniziare l’esecuzione.
Nel contesto OGSA ogni istanza di un servizio Grid ha un Grid Service Reference (GSR) ed un Grid Service Handle (GSH). Il metodo di creazione fornisce un GSR per l’istanza di un servizio, ma l’utente accede al servizio usando un handle logico. Per questa ragione, l’istanza di un servizio Grid è registrata tramite un componente chiamato “handle resolution service” da cui riceverà un GSH associato. Questo servizio realizza il mapping tra il GSR ed il GSH che è memorizzato nel Registry OGSA dove si può accedere per recuperarlo.
Inoltre il Service Provider, per mantenere i riferimenti alle istanze di un servizio in esecuzione, può scegliere di rendere utilizzabile la documentazione conforme al WS-Inspection riguardante le istanze di un servizio provenienti dai Registries (OGSA) degli ambienti virtuali utilizzati. Tali Registry (Local Registry) possono essere acceduti dal Service Requestor implementando l’interfaccia FindServiceData consigliata da OGSA.
