Capitolo 1
Introduzione
Una piattaforma grid è una infrastruttura per il calcolo basata su un sistema distribuito in cui i nodi di elaborazione possono essere macchine di varia natura (supercomputer, cluster di pc,workstation etc.) interconnessi tramite reti estese anche geograficamente; oltre ai nodi di calcolo, la piattaforma può includere altre classi di risorse, come per esempio, sottosistemi di archiviazione di vario genere o apparecchiature scientifiche specializzate. La piattaforma grid deve fornire un’astrazione tale da permettere una modalità di accesso uniforme alle risorse che la compongono e deve rendere possibile aggregarle dinamicamente al fine di utilizzare l’insieme così ottenuto come infrastruttura a supporto dell’esecuzione delle applicazioni. Le piattaforme grid trovano impiego in problemi che necessitano, per la loro soluzione, di una grande capacità di calcolo, caratteristica presente, per esempio, in molti problemi nel campo della fisica computazionale e dell’ingegneria. Le piattaforme grid sono quindi caratterizzate oltre che dall’eterogeneità delle risorse che le compongono, anche dalla dinamicità dell’ambiente stesso; questo vuol dire che la piattaforma potrebbe essere, in generale, in continuo mutamento. Le risorse che compongono la piattaforma infatti possono essere aggiunte e rimosse con grande libertà e la possibilità di includere nella piattaforma anche risorse computazionali non dedicate comporta ulteriori incertezze riguardo alla loro disponibilità nel tempo. La classe di applicazioni che considereremo in questa tesi è quella delle applicazioni parallele high performance. Le applicazioni considerate
devono possedere le due caratteristiche seguenti: devono mantenere un determinato livello prestazionale e necessitano di sfruttare le risorse offerte dalla piattaforma sottostante in modo da eseguire la loro computazione parallelamente. Al fine di controllare il livello prestazionale delle applicazioni, in un ambiente fortemente dinamico come quello considerato, è imperativo l’utilizzo di tecniche per il controllo del QoS. Il processo di gestione del QoS necessita della specifica dei requisiti di performance che l’applicazione dovrà rispettare. Tali requisiti, adeguatamente interpretati, serviranno a guidare la fase di deployment allo scopo di fornire all’applicazione le condizioni iniziali adatte al rispetto del QoS. Successivamente il processo di gestione del QoS dovrà prevedere il monitoring costante delle prestazioni dell’applicazione a tempo di esecuzione e in caso di violazione dei requisiti di performance sarà necessario reagire adeguatamente per ripristinare il livello prestazionale specificato. La seconda caratteristica è supportata tramite l’uso di linguaggi adatti alla descrizione di programmi paralleli, dalla successiva fase di compilazione che produce il codice eseguibile in grado di sfruttare la piattaforma sottostante e da una adeguata fase di deployment. Generalmente un programma parallelo compilato per un ambiente distribuito è rappresentato da un’insieme di eseguibili che, una volta in esecuzione, coopereranno in una rete di processi che realizza l’applicazione. La condizione necessaria affinché l’applicazione parallela possa essere avviata è che gli eseguibili che la compongono devono essere allocati sulle risorse di calcolo contemporaneamente (co-allocazione). La co-allocazione degli eseguibili dovrà essere garantita da un tool di deployment, il quale si occupa del lancio dell’applicazione attraversando almeno le seguenti fasi: Resource Discovery, Resource Selection, Staging e Application Execution.
Al fine di supportare in maniera consistente sia la gestione del QoS sia la co-allocazione è auspicabile che le risorse che verranno sfruttate dall’applicazione siano prenotabili. Il meccanismo della prenotazione, denominato in letteratura Advance Reservation, permette di associare le risorse alle applicazioni per un intervallo di tempo specificato; questo meccanismo consente di evitare che in fase di allocazione dei processi vengano selezionate risorse già assicurate ad altre applicazioni violando così il loro QoS.
Il nostro lavoro di tesi consiste nella proposta e nell’implementazione di un sistema che fornisce la funzionalità di Advance Reservation integrata a quella di Information Gathering, a supporto delle fasi di Resource Discovery e Resource Selection effettuate dal tool di deployment. Parte del nostro lavoro è consistito nell’integrazione dal sistema da noi proposto nel GEA1, il tool di deployment fornito con l’ambiente di programmazione ASSIST2.
ASSIST è un ambiente di programmazione integrato che fornisce un’insieme di strumenti a supporto dello sviluppo di applicazioni parallele e distribuite. Una caratteristica dell’ambiente di sviluppo è quella di offrire un approccio omogeneo alla programmazione di tali applicazioni, permettendone l’esecuzione su un’ampia gamma di architetture che include macchine a parallelismo massiccio, cluster, reti di workstation e piattaforme Grid. Le applicazioni sono espresse come grafi generici i cui nodi sono componenti e gli archi rappresentano i meccanismi che regolano la loro composizione ed interazione. L’applicazione quindi può sfruttare sia il parallelismo inter-componente che quello intra-componente, quest’ultimo offerto dai componenti stessi che possono, al loro interno, avvalersi di varie
forme di parallelismo. ASSIST supporta lo sviluppo di applicazioni dinamicamente adattive fornendo i meccanismi per guidare, a runtime, l’eventuale processo di ristrutturazione dei componenti paralleli (es. modifica del loro grado di parallelismo), aggiunta di risorse, de-allocazione di componenti e loro rescheduling su nodi di calcolo alternativi. Inoltre è supportata l’eterogeneità delle risorse di calcolo permettendo di creare codice eseguibile dipendentemente dall’architettura dei nodi disponibili. Il meccanismo che ASSIST prevede allo scopo di abilitare il controllo del QoS è quello del contratto di performance. Quest’ultimo viene prodotto automaticamente in base alle annotazioni di performance aggiunte al codice sorgente dal programmatore e servirà, opportunamente trattato, sia per guidare le fasi di Resource Discovery e Resource Selection sia per rilevare eventuali variazioni delle prestazioni a tempo di esecuzione che potrebbero scatenare i meccanismi di riconfigurazione dinamica al fine di ristabilire il QoS. I sorgenti di un programma ASSIST vengono compilati in un insieme di file binari. La struttura parallela dell’applicazione è estratta dal codice sorgente e usata per produrre il contratto di performance iniziale. La fase successiva prevede la valutazione del contratto e la produzione del file di descrizione delle risorse, questo contiene tutte le caratteristiche necessarie ad effettuare il lancio dell’applicazione con un insieme iniziale di risorse adatto al rispetto dei vincoli imposti dal contratto di performance. Il lancio dell’applicazione viene effettuato per mezzo del GEA che prende in input i file precedentemente illustrati; in particolare il file di descrizione delle risorse serve al GEA per eseguire la fase di Resource Discovery che prevede l’interrogazione dei GIS3 disponibili. Successivamente le risorse raccolte saranno utilizzate nella fase di Resource Selection in cui viene
eseguito il mapping dei processi sulle risorse e la prenotazione di quest’ultime.
Il sistema da noi proposto fornisce sia la funzionalità di Information Gathering, quindi agendo come un GIS durante la fase di Resource Discovery, sia la funzionalità di Advance Reservation offrendo la possibilità di prenotare le risorse durante la fase di Resource Selection.
Le funzionalità di Information Gathering offerte dal sistema sono:
• Catalogazione e pubblicazione delle risorse appartenenti ad un dominio amministrativo che si vogliono mettere a disposizione della piattaforma Grid. Questo tool offre un linguaggio di descrizione delle risorse espandibile. Attualmente è in grado di descrivere risorse di tipo computazionale.
• Interrogazione del catalogo tramite un meccanismo basato su filtri. L’utente del IGS potrà specificare all’interno di un filtro un’insieme di vincoli. Il sistema provvederà a restituire solo le risorse che rispetteranno i vincoli espressi nel filtro. E’ possibile anche richiedere, specificando alcuni parametri nel filtro, l’ordinamento delle risorse filtrate rispetto ai loro attributi; l’ordine di precedenza tra questi è definibile a piacere. L’approccio utilizzato per il matchmaking è quello simmetrico: il formalismo usato per la descrizione delle risorse viene utilizzato anche per esprimere le interrogazioni.
• La restituzione dei risultati delle interrogazioni tramite un iteratore. L’iteratore permette di scorrere l’insieme di risorse che soddisfa i vincoli impostati nel filtro. E’ possibile richiedere l’iteratore in due versioni differenti: locale o remoto; il primo consente di scorrere più
velocemente l’insieme delle risorse e tende ad ammortizzare maggiormente l’overhead delle comunicazioni, il secondo, fornisce risultati più aggiornati.
Le caratteristiche del sottosistema di Advance Reservation sono: • Associa ad ogni risorsa gestita una lista di prenotazioni
• Possibilità di associare alle prenotazioni una classe di priorità. • E’ possibile prenotare frazioni di risorse (storage, cpu, etc.).
• Possibilità di rappresentare sia prenotazioni definite che indefinite. Le prenotazioni definite sono attive in un arco di tempo ben precisato; quelle indefinite sono attive dall’istante iniziale specificato in poi.
• L’intervallo di tempo rappresentato dalle prenotazioni può essere definito con la precisione di un secondo.
Durante la fase di resource Discovery il GEA dovrà interrogare lo Information Gathering al fine di recuperare un insieme di risorse che presentino le caratteristiche necessarie al lancio dell'applicazione. Per questo scopo riteniamo sia necessario che il sistema di Information Gathering fornisca una funzionalità di filtraggio attraverso cui specificare i requisiti desiderati dalle risorse. Per mettere a disposizione tale funzionalità abbiamo scelto di implementare lo Information Gathering per mezzo di un motore di matchmaking simmetrico simile a quello adottato da Condor [COND]. Poiché l'ambito delle applicazioni parallele restringe molto il possibile ventaglio di tipologie di risorse che il sistema dovrà gestire non è
necessario adottare le metodologie introdotte dall’ ontology-based matchmaking. Infatti l'approccio semantico è guidato dall'idea di realizzare una griglia orientata ai servizi, nella quale saranno presenti risorse di ogni genere, in continua evoluzione e con diversi livelli di astrazione. Nel caso di griglie realizzate al fine di eseguire applicazioni parallele ci troveremo a dover gestire principalmente risorse di calcolo, di storage e di rete. In questo ambito i problemi di flessibilità e di estendibilità del matchmaker assumono un peso meno rilevante. Tale considerazione unita a valutazioni sulla semplicità di realizzazione, hanno portato alla scelta di implementare un prototipo basato sul modello simmetrico. In pratica, l'implementazione attuale del sistema lavora solo su risorse di tipo computazionale, ma per mezzo di accorgimenti tecnici di programmazione e di una adeguata astrazione delle risorse, si è cercato di realizzare un motore di matching generico e facilmente estendibile per la gestione di risorse di vario genere. Chiaramente l'estendibilità che si ottiene nel modello semantico basato sulle ontologie è ad un livello molto più alto, perché è l'utente del sistema che può aggiungere nuove risorse o inserire nuove regole deduttive al motore di matching. Nel nostro caso, se si vogliono estendere le capacità di matching del sistema, è necessario l'intervento di un programmatore che dovrà implementare un nuovo modulo di gestione di un tipo di risorsa, senza intervenire sulla struttura del motore di matching.
La mancanza di un sistema di information gathering nativo del GEA e la necessità di dover avere una rappresentazione delle risorse ai fini della Advance Reservation ha portato alla progettazione di un sistema dove lo Information Gathering e la Advance Reservation condividono logicamente la stessa rappresentazione delle risorse e gli stessi meccanismi di comunicazione. In definitiva il sistema opera come un mediatore tra i
fornitori delle risorse e il GEA, utilizzato dagli utenti al fine di mandare in esecuzione le proprie applicazioni. Per questo semplice motivo il nostro sistema prende il nome di broker system.
Il sistema di brokering è composto da due entità, un modulo server denominato Broker e un modulo libreria denominato BrokerLib. I server Broker sono le entità predisposte alla gestione delle risorse locali di un dominio amministrativo4. Il sistema di brokering è distribuito e può essere composto da un numero qualsiasi di broker, ognuno rappresentante il punto di accesso alle informazioni sulle risorse di un certo AD. All'interno di un dominio amministrativo è possibile eseguire più di un'istanza di broker. In tal caso, tutti i broker del dominio dovranno essere interconnessi in modo tale da formare una struttura gerarchica ad albero. La radice di tale albero risulterà l'unico punto di contatto per le richieste provenienti dagli strumenti che utilizzano la libreria BrokerLib, mentre i broker annidati nei nodi interni dell'albero saranno contattati ricorsivamente e in modo trasparente. Ogni nodo dell'albero potrà avere una qualsiasi arietà. La possibilità di instaurare una gerarchia tra i broker all'interno di un dominio consente di riflettere gli eventuali annidamenti di sotto-domini amministrativi. Tale meccanismo permette sia di riflettere la topologia della rete, sia di rispettare le relative politiche amministrative e di sicurezza.
I restanti capitoli sono organizzati nel seguente modo:
• Capitolo 2 vengono introdotte le caratteristiche delle griglie computazionali, delle applicazioni grid-aware e il modello a componenti. Viene presentata una definizione di qualità del servizio
e le relative metodologie per il suo ottenimento. In seguito viene descritto il sistema per la gestione delle risorse con particolare attenzioni alle fasi di mapping/scheduling e deploy delle applicazioni. Infine viene presentato lo stato dell’arte degli strumenti che offrono funzionalità di Advance Reservation e dei sistemi di Matchmaking.
• Capitolo 3 viene introdotto all’ambiente di programmazione ASSIST ed al tool di deployment GEA. Vengono illustrati i passi necessari dalla compilazione alla messa in esecuzione dell’applicazione. In seguito vengono presentate le caratteristiche del sistema da noi implementato e le modalità di integrazione con il GEA.
• Capitolo 4 inizialmente viene descritta e motivata l’astrazione utilizzata per descrivere le risorse computazionali e la possibilità di espansione garantite dal sistema. In seguito viene presentato il linguaggio per la descrizione delle risorse e il concetto di filtro e di vincolo, che rappresentano i meccanismi adottati per effettuarne la selezione e la prenotazione. Successivamente è presentata l’architettura del sistema e delle sue singole parti (broker e libreria) fino ad arrivare ai dettagli implementativi dei meccanismi che realizzano il sistema di prenotazione. Infine è presentata una breve introduzione all’uso dell’API con la quale è possibile sfruttare le funzionalità del sistema.
inizialmente con microbenchmark eseguiti sui sottosistemi di filtraggio e prenotazione. Successivamente i test hanno coinvolto l’intero sistema di brokering al fine di indagare l’andamento dei temi di risposta in funzione sia del numero di risorse gestite sia dal numero di clienti serviti. Infine sono presentate delle considerazioni sui futuri sviluppi che potrebbe avere il sistema.
• Appendice vengono presentati alcune parti di codice ritenute più significative al fine della comprensione dei meccanismi e delle strutture dati utilizzate nell’implementazione del sistema.
