Università degli Studi di Napoli Federico II
Scuola Politecnica e delle Scienze di Base
Area Didattica Scienze MM.FF.NN.
Master di I° Livello in
Tecnologie per il CAlcolo Scientifico ad Alte
Prestazioni - CASAP
Tesi di Master
GaaS, un approccio per l'integrazione dei
paradigmi GRID/CLOUD:
i servizi di storage
Relatori
Candidato
Prof. Giuliano Laccetti
Dott.ssa Luisa Carracciuolo
Francesco Iannone
matr. Z62/000014
Anno Accademico 2012-2013
Indice generale
Prefazione.................................................................................................................. 5
Introduzione...............................................................................................................6
1 Le griglie computazionali.......................................................................................8
1.1 Elementi costitutivi di una griglia computazionale.........................................9
1.2 La tecnologia Grid di riferimento: il middleware EMI.................................12
2 Il Cloud Computing..............................................................................................14
2.1 I Modelli di servizio..................................................................................14
2.2 I Modelli di distribuzione.........................................................................15
2.3 Elementi costitutivi di un'infrastruttura di Cloud Computing........................17
2.4 La Tecnologia Cloud di riferimento: la piattaforma OpenStack....................19
3 Il Progetto GaaS...................................................................................................23
4 Grid Site Service: GaaS_GSS..............................................................................26
4.1 Il GaaS Cloud Management Controller: l'architettura generale ....................28
4.2 Architettura di Riferimento............................................................................30
4.3 Il GaaS CMC inserito in una architettura multilivello..................................31
4.4 Il database:gaasDB.......................................................................................34
4.5 Un caso d'uso: richiesta e creazione di un elemento grid..............................38
5 Creazione di un Elemento per lo Storage (SE)....................................................39
5.1 Verifica della disponibilità delle risorse.........................................................40
5.2 Schedulazione delle risorse...........................................................................43
5.3 Definizione e propagazione dei file di contestualizzazione .........................45
Francesco Iannone Z62/000014
Pagina 2 di 53
5.4 Creazione istanza..........................................................................................49
5.5 Funzionalità a contorno....................................................................................49
5.5.1 Update SE..................................................................................................49
5.5.2 Delete SE...................................................................................................51
Conclusioni e sviluppi futuri....................................................................................52
Francesco Iannone Z62/000014
Pagina 3 di 53
Indice delle illustrazioni
Illustrazione 1: Entità e loro interazioni in uno scenario GRID-EMI......................13
Illustrazione 2: Modello architetturale di un'infrastruttura di cloud computing......17
Illustrazione 3: Esempio di un'architettura base di OpenStack...............................21
Illustrazione 4: modello concettuale del servizio GaaS_GSS .................................27
Illustrazione 5: Architettura generale del componente GaaS_CMC.........................28
Illustrazione 6: scelte implementative in merito ai moduli del Gaas_CMC ............30
Illustrazione 7: Schema Entità-Relazione che modella il database gaasDB.............37
Illustrazione 8: caso d'uso per la funzionalità di “creazione di un elemento grid”...38
Illustrazione 9: Diagramma di flusso che verifica la disponibilità delle risorse.......42
Illustrazione 10: Diagramma di flusso della procedura che schedula la richiesta di
risorse .....................................................................................................................44
Illustrazione 11: Diagramma di flusso che sintetizza la fase di definizione dei file di
contestualizzazione..................................................................................................46
Illustrazione 12: Attività eseguite all'avvio dell'istanza della VM sulla quale
èinstanziato il ruolo.................................................................................................47
Illustrazione 13: Diagramma di flusso in merito all'aggiornamento dello spazio
disponibile sullo storage element.............................................................................50
Illustrazione 14: Flusso delle attività svolte in fase di eliminazione dello storage
element.................................................................................................................... 51
Francesco Iannone Z62/000014
Pagina 4 di 53
Prefazione
Il lavoro svolto in questa tesi si colloca in un contesto progettuale più ampio che ha
l'obiettivo di realizzare una piattaforma, GaaS, per l'integrazione dei paradigmi di
Grid e Cloud computing. L'idea progettuale è un'iniziativa del gruppo di gestione
del datacenter SCoPE (scopeadmin).
Il Master CASAP ha fornito l'occasione e le persone per consolidare l'idea
progettuale, già in parte realizzata negli ultimi due anni, attraverso la costituzione di
un gruppo di lavoro al quale hanno partecipato quattro studenti del Master CASAP
(F. Iannone, C. Napolitano, S. Scamardella e A. Solla) e i membri del gruppo di
gestione del datacenter ScoPE (tutor relatori delle rispettive tesi di Master).
Ciascuno degli studenti coinvolti ha contribuito alla definizione e all'arricchimento
dell'architettura generale di GaaS, nonché all'implementazione di specifici servizi di
gestione o di accesso.
L'approccio utilizzato per lo svolgimento delle attività ha richiesto periodici incontri
di coordinamento tra tutti i partecipanti al gruppo di lavoro, nonché una stretta
collaborazione tra gli studenti coinvolti nella realizzazione delle varie attività.
Tutto il lavoro è stato svolto su un set di risorse del datacenter SCoPE dedicate
all'allestimento dell'architettura di riferimento e una versione prototipale del
prodotto realizzato è attualmente disponibile sulle risorse suddette.
Francesco Iannone Z62/000014
Pagina 5 di 53
Introduzione
Le organizzazioni di ricerca si trovano spesso coinvolte in progetti nei quali devono
collaborare con realtà differenti e geograficamente lontane, gruppi di ricerca e
dipartimenti multi-disciplinari, appartenenti a domini amministrativi diversi. Per
rispondere alle esigenze delle moderne sfide scientifiche è necessario un uso
coordinato e condiviso delle risorse, assicurando sempre scalabilità, sicurezza ed
efficienza. Fino ad oggi il mondo scientifico ha utilizzato quasi esclusivamente
soluzioni di tipo Grid scegliendo di, investire in tale ambito molte risorse,
essenzialmente perchè tale paradigma è stato, ed è di fatto, l'unico in grado di
soddifare in maniera efficace le esigenze di calcolo condiviso su larga scala. Ma da
qualche anno molte realtà, non solo aziendali, stanno guardando con interesse ai
servizi che il Cloud Computing è capace di fornire in maniera semplice ed intuitiva.
Si manifestano quindi nuove esigenze da parte di tutti i soggetti coinvolti:gli utenti,
ad esempio, vorrebbero utilizzare i nuovi servizi e le interfacce semplificate del
Cloud Computing pur mantenendo la possibilità di accedere alle risorse tramite
interfacce Grid (soprattutto in quelle comunità che hanno investito molto, in questi
anni, su Grid); dall'altra parte, i fornitori di servizi, vogliono ottimizzare l’uso delle
proprie risorse ed allargare il proprio bacino d’utenza, per esempio supportando
l’accesso e l’approvvigionamento di risorse tramite tecnologie diverse, mantenendo
la sicurezza, dinamicità e scalabilità, raggiunte durante l’esperienza Grid di questi
anni.
La gestione dei dati e delle risorse di calcolo in ambito distribuito è molto
complessa e prevede la risoluzione di alcune problematiche, come ad esempio la
Francesco Iannone Z62/000014
Pagina 6 di 53
fornitura di un accesso efficiente ed integrato, una gestione corretta delle repliche,
l'identificazione univoca e trasparente delle entità, il mantenimento dell'integrità e
della consistenza, l'uso di cache che implementino funzionalità di scadenza e
rimozione dei dati, e così via.
Grid e Cloud computing si sono imposti come soluzioni di rilievo in quest'ambito,
portando ad un livello più avanzato la gestione delle collaborazioni e la qualità del
flusso informativo che intercorre fra le diverse comunità, scientifiche e non. Appare
quindi necessaria una piattaforma che applichi un'integrazione dei principali aspetti
positivi dei due paradigmi di calcolo, una realizzazione che permetta di fornire
risorse e servizi interoperabili, mantenendo i principali benefici raggiunti in questi
anni nel mondo Grid e Cloud.
I primi due capitoli di questa tesi affronteranno gli aspetti relativi ai paradigmi del
Grid e del Cloud Computing, entrando anche nel merito rispettivamente del
middleware EMI e di OpenStack, che permettono di realizzare rispettivamente le
due architetture. Il terzo capitolo sarà interamente dedicato alla piattaforma GaaS,
della quale viene offerta una panoramica delle motivazioni che hanno portato a
realizzarla nonché delle funzionalità che implementa ed dei servizi che offre.
Il quarto capitolo, farà riferimento all'oggetto di questo lavoro di tesi, sarà quindi
introdotto il servizio GaaS_GSS e sarà data una descrizione di come questi sia stato
ampliato ed ottimizzato attraverso la componente GaaS_CMC della quale si
descriverà l'architettura e l'integrazione nell'ambiente GaaS illustrandone il
funzionamento anche grazie ad un diagramma di caso d'uso. Infine nel quinto
capitolo verranno descritti nel dettaglio come tali servizi sono stati implementati.
Francesco Iannone Z62/000014
Pagina 7 di 53
1 Le griglie computazionali
In un ambiente industriale e scientifico in fase di profonda evoluzione tecnologica,
le aziende devono reagire per non restare escluse dal processo di innovazione ma
diventare più competitive sul mercato.
Ciò può essere reso possibile utilizzando una tecnologia d’avanguardia che sfrutti le
risorse a disposizione e limiti al tempo stesso gli investimenti.
Al giorno d’oggi, ogni volta che si presenta un problema dovuto ad una carenza di
potenza di calcolo, la soluzione è unire insieme le risorse sia che si tratti di
un’azienda o di un’istituzione accademica. Tale insieme è quindi pensato ed usato
come una singola, unificata risorsa: la griglia computazionale o GRID
A lungo termine si prefigura uno scenario in cui le capacità di calcolo e di storage di
milioni di sistemi, attraverso la rete globale, funzioneranno come un unico team,
utilizzabile pressoché da chiunque ne avrà bisogno secondo il paradigma più
generale del Distributed Computing..
Di seguito viene riportata la definizione di griglia computazionale data da FosterKesselman nel 1998 [1]:
“A computational Grid is a hardware and software infrastructure that provides
dependable,
consistent,
pervasive
and
inexpensive
access
to
high-end
computational capabilities” .
Dunque si tratta di un'infrastruttura sia Hardware che Software che fornisce un
accesso affidabile, consistente, pervasivo e non costoso verso unità computazionali
di fascia alta.
Francesco Iannone Z62/000014
Pagina 8 di 53
1.1 Elementi costitutivi di una griglia computazionale
Un'infrastruttura di griglia computazionale è costituita dai seguenti servizi:
Virtual Organization Membership Service (VOMS): Si tratta di un servizio che
ha lo scopo di fornire meccanismi di autorizzazione/autenticazione degli utenti di
una Virtual Organizazion (VO)1. Ciò è reso possibile grazie ad un sistema per la
gestione delle identità degli utenti, rappresentate da certificati digitali, organizzate
in gerarchie sulla base di ruoli e attributi. Il servizio VOMS è composto
principalmente da:
•
Un VOMS core service, che rilascia credenziali ad utenti identificati da un
Ente Certificante o Certification Authority (CA).
•
Un VOMS Admin service, che viene utilizzato dal responsabile della VO per
gestire sia le stesse Virtual Organization sia le utenze che ad esse afferiscono.
Workload Management System (WMS): Il ruolo del WMS è gestire l'insieme dei
job presenti sull'infrastruttura allocando ad essi le risorse e monitorandone lo stato.
Sarà comunque compito dell’utente, definire correttamente sia le azioni che il job
deve eseguire sia i suoi requisiti.
Il job da sottomettere al WMS può essere scritto in un apposito linguaggio che
cambia a seconda del middleware in questione.
Computing Element (CE): rappresenta un insieme di risorse computazionali
localizzate in un sito.
1 Con i termini “Virtual Organization” si intende un insieme dinamico di individui o istituzioni che
condividono risorse sulla base di regole e condizioni
Francesco Iannone Z62/000014
Pagina 9 di 53
Un CE include solitamente una generica interfaccia all'insieme dei nodi di calcolo o
(Worke Nodes), detta Grid Gate (GG).
Quest’interfaccia è responsabile dell’accettazione e schedulazione dei job di calcolo
verso i Worker Node, elementi che andremo ad analizzare a breve.
Ciascun Computing Element rende nota la propria esistenza nella griglia
computazionale mediante un sistema informativo, ed è di solito fornito di certificato
digitale che ne attesta l'identità. Si occupa inoltre di gestire l’insieme di risorse di
calcolo rappresentate dai Worker Node tramite un batch system e ordinare i job in
code (queue).
Worker Node (WN): I Worker Node sono i veri e propri nodi di calcolo,, ossia
isistemi sulle quali vengono effettuate le elaborazioni. Tali sistemi vengono gestiti
dal CE, con il quale andranno a interagire direttamente.
User Interface (UI): L’interfaccia utente è il punto di accesso alle risorse della
griglia.
Su tale sistema a ciascun utente in possesso di un certificato personale sono
consentite le seguenti operazioni:
•
la sottomissione del job ad un CE in via diretta o tramite WMS
•
la visualizzazione dello stato del job
•
la cancellazione del job
•
il recupero dell’output del job
Information Sistem (IS): fornisce informazioni sulla struttura della Grid sia agli
utenti che alla Grid stessa (agli elementi che la costituiscono). Tali informazioni
riguardano lo stato delle risorse della Grid e consentono un uso ottimale delle
risorse stesse.
Francesco Iannone Z62/000014
Pagina 10 di 53
Il sistema informativo è organizzato in un sistema a livelli basato su un pull model
gerarchico con architettura ad albero:
– Basso livello (foglie): Grid Resource Information Server (GRIS)
•
Gestisce l’informazione sullo stato di una data risorsa
•
E' disponibile un GRIS su ogni risorsa (CE, SE, etc)
•
utilizza un insieme di sensori che estraggono dati utili sullo stato della
risorsa
– Livello medio: Site BDII (Berkley Database Information Index)
•
Gestisce l’informazione a livello di ‘sito’ , collezionando e propagando ai
livelli superiori le
informazioni raccolte dai GRIS sottostanti che sono
periodicamente interrogati.
•
E' disponibile un BDII per ogni sito
– Alto livello (radice): Top BDII
•
Ottiene informazioni su tutte le risorse registrate.
•
E' disponibile un BDII per ogni VO o multi-VO su base regionale
Storage Elements (SE): Questi elementi forniscono un accesso uniforme ai dati
delle risorse di storage. Ciascuno Storage Element possiede un certificato digitale
che ne attesta l’identità.
Lo Storage Element è il servizio che fornisce servizi per la locazione, l'accesso e il
trasferimento dei files consentendo ad utenti o applicazioni GRID di utilizzare le
risorse di storage, ossia di memorizzare i dati e ritrovarli per usi futuri
Lo storage element fornisce diversi tipi di interfacce: Accesso ai dati (I/O),
Trasferimento dati (GridFTP) , Storage Management (SRM) .
Francesco Iannone Z62/000014
Pagina 11 di 53
L'interfaccia SRM maschera l'eterogeneità dei sistemi di archiviazione (gli SE
possono controllare infatti semplici dischi, array di dischi o dispositivi a nastro)
rendendo uniforme l'accesso alla risorsa e consentendo all'utente di riferirsi ai dati
mediante un nome logico senza farsi carico di conoscere il luogo fisico sul quale
questi sono di fatto memorizzati.
1.2 La tecnologia Grid di riferimento: il middleware EMI
Come tecnologia Grid di riferimento considereremo quella realizzata nell'ambito del
progetto Europeo EMI (The European Middleware Initiative) [2]. Tale progetto
ha come obbiettivo quello di rendere disponibile un insieme consolidato di prodotti
middleware2 basato sui quattro maggiori sistemi middleware presenti in contesto
europeo: ARC, dCache, gLite and UNICORE.
Il middleware EMI implementa un insieme integrato di componenti ciascuno dei
quali rende disponibili i servizi che costituiscono la Griglia Computazionale. Grazie
ad esso si realizza l’infrastruttura accessibile ai membri della comunità organizzati
in Virtual Organizations.
L’infrastruttura fornisce agli utenti servizi di alto livello per la schedulazione e
l’esecuzione di job computazionali, l'accesso ed il trasferimento di dati e l'accesso
alle informazioni sullo stato dell'infrastruttura stessa.
In particolare vengono forniti servizi di autenticazione/autorizzazione (VOMS,
MYPROXY ), allocazione, scoperta della risorse e job scheduling (LB/WMS),
diffusione e recupero delle informazioni relative ai siti Grid (BDII o più in generale
IS) .
Le risorse di calcolo (WNs) sono fornite per mezzo del CE (Computing Element)
2 Con il termine middleware si intende “lo strato software, compreso fra il sistema operativo e le
applicazioni, in grado di interagire con entrambi i suddetti livelli in un contesto di calcolo distribuito."
Francesco Iannone Z62/000014
Pagina 12 di 53
che è un endpoint con un set di code gestite dall’ LRMS (Local Resource
Management System). Lo storage element (SE) fornisce servizi e interfacce relative
all'accesso ed archiviazione dati.
Gli utenti possono accedere ai servizi dalla User Interface (UI).
In figura 1 è rappresentata una griglia computazionale basata sul middleware EMI
che fa uso dei servizi suddetti. Le linee tratteggiate rappresentano le informazioni
scambiate tra i vari componenti (es. info sullo stato del job e delle risorse ) mentre
quelle continue rappresentano il flusso di dati di un job (sia in input che in output )
che “attraversa ” la griglia.
Illustrazione 1: Entità e loro interazioni in uno scenario GRID-EMI
Francesco Iannone Z62/000014
Pagina 13 di 53
2 Il Cloud Computing
Attualmente il termine di Cloud Computing viene usato per indicare l'accesso
tramite internet a servizi disponibili e/o instanziati on-demand.
Per dare una definizione che identifichi il termine “cloud computing” in maniera
più chiara e secondo uno standard ben preciso, si può far riferimento alla
definizione che viene data dal NIST (National Institute of Standards and
Technology) [3] della quale viene di seguito riportata la traduzione:
“Il Cloud Computing è un modello che permette da qualsiasi luogo e in maniera
facile l’accesso su richiesta tramite rete, ad un insieme di risorse di elaborazione
condivise e configurabili (es. reti, server, storage, applicazioni e servizi) che
vengono rapidamente fornite e rilasciate con il minimo sforzo di gestione o di
interazione da parte del fornitore del servizio”.
Il documento pubblicato dal NIST espone, tra l'altro, i modelli di servizio e di
distribuzione del cloud computing che vengono di seguito riportati:
2.1 I Modelli di servizio
Per modello di servizio si intende il tipo di servizio che il fornitore (o cloud
producer) rende disponibile al consumatore (o cloud consumer). Lo standard
definito dal NIST classifica tali tipi in classi a seconda del livello di astrazione
crescente (dalla infrastruttura fino alla piattaforma)
Francesco Iannone Z62/000014
Pagina 14 di 53
Infrastructure as a Service (IaaS): I servizi di tale classe mettono a disposizione
del consumatore risorse di elaborazione, archiviazione, reti e sulle quali il
consumatore è in grado di distribuire e eseguire software arbitrario, che può
includere sistemi operativi e applicazioni. Il consumatore non gestisce e non
controlla l’infrastruttura cloud sottostante, ma ha il controllo su sistemi operativi, e
sulle applicazioni distribuite, ed eventualmente ha il controllo limitato di
componenti di rete (es. firewall host).
Software as a Service (SaaS): I servizi di tale classe mettono a disposizione del
consumatore applicazioni del fornitore in grado di essere eseguite su
un’infrastruttura cloud. Le applicazioni sono accessibili dai vari dispositivi client
attraverso un’ interfaccia di tipo thin client, ad esempio attraverso un web browser,
oppure attraverso API. Il consumatore non gestisce e non controlla l’infrastruttura
cloud sottostante, che comprende la rete, i server, i sistemi operativi, lo storage né
le singole funzionalità delle applicazioni.
Platform as a Service (PaaS): I servizi di tale classe mettono a disposizione del
consumatore la possibilità di eseguire sull'infrastruttura cloud applicazioni acquisite
o create dal consumatore stesso, utilizzando linguaggi di programmazione, librerie,
servizi e strumenti supportati dal fornitore. Il consumatore non gestisce e non
controlla l’infrastruttura cloud sottostante, che comprende la rete, i server, i sistemi
operativi e l’eventuale storage, ma ha il controllo sulle applicazioni distribuite e le
possibili impostazioni di configurazione per l’ambiente che ospita le applicazioni.
2.2 I Modelli di distribuzione
Per modello di distribuzione si intende la modalità con la quale il fornitore rende
disponibile al consumatore le risorse. Lo standard definito dal NIST classifica tali
modalità in classi a seconda dell'accessibilità e condivisone delle risorse.
Francesco Iannone Z62/000014
Pagina 15 di 53
Private cloud: L’infrastruttura cloud viene fornita ad uso esclusivo di una singola
organizzazione che comprende più consumatori. L’infrastruttura può essere di
proprietà, gestita o solo azionata, dall’organizzazione o da terze parti, oppure da una
combinazione di essi. L’ infrastruttura può trovarsi all’interno o al di fuori della sede
dell’organizzazione.
Community cloud: L’infrastruttura cloud viene fornita ad uso esclusivo di una
specifica comunità di consumatori, provenienti da organizzazioni che condividono
fini ed interessi. L’infrastruttura può essere di proprietà, gestita da una o più
organizzazioni all’interno della comunità o da terze parti, oppure da una
combinazione di essi. L’infrastruttura può trovarsi all’interno o al di fuori delle sedi
delle organizzazioni..
Public cloud: L’infrastruttura viene fornita per un utilizzo aperto al grande
pubblico. L’infrastruttura può essere di proprietà, gestita o azionata da
organizzazioni aziendali, accademiche o governative, oppure da una combinazione
di essi. L’infrastruttura è situata nelle sedi del fornitore.
Hybrid cloud: L’infrastruttura cloud è un insieme di due o più infrastrutture cloud
distinte (private, community o public) che mantengono la propria unicità, ma sono
legate tra di loro da tecnologie standard o proprietarie che consentono la portabilità
dei dati e delle applicazioni (es. cloud bursting
3
per il bilanciamento di carico tra
infrastrutture cloud).
3 E’ un concetto che esprime la possibilità per una applicazione che gira all’interno di un'infrastruttura
cloud o data center, di poter utilizzare risorse di elaborazione di un altro cloud nel momento in cui
l’applicazione raggiunge il picco di utilizzo.
Francesco Iannone Z62/000014
Pagina 16 di 53
2.3 Elementi costitutivi di un'infrastruttura di Cloud
Computing
Per facilitare la comprensione dei requisiti, degli usi, delle caratteristiche e degli
standard del cloud computing, in questo paragrafo sarà introdotta un'anteprima
dell'architettura di riferimento per il cloud computing così come formulata da lNIST
[4], indentificando i principali attori coinvolti, le loro attività e funzioni nel cloud
computing.
Illustrazione 2: Modello architetturale di un'infrastruttura di cloud computing
Come mostrato in figura 2, il NIST, in merito all'architettura definisce cinque attori
principali, ognuno dei quali è un'entità (una persona fisica o un'organizzazione) che
partecipa in una transazione o un processo e/o realizza tasks nel cloud computing.
Tali attori vengono elencati e definiti nella tabella che segue:
Francesco Iannone Z62/000014
Pagina 17 di 53
Attore
Definizione
Cloud Consumer
Una persona fisica o un'organizzazione che
mantiene una relazione di business ed usa i
servizi di un Cloud Provider.
Cloud Provider
Una persona o un' organizzazione
responsabile della fornitura di un servizio e
di renderlo disponibile alle parti interessate.
Cloud Auditor
Un soggetto o un gruppo, in grado di
condurre una valutazione sui servizi cloud
offerti, sulle prestazioni e sul livello di
sicurezza implementati.
Cloud Broker
Entità che gestisce l'uso, le prestazioni e la
distribuzione dei servizi cloud, negoziando
le relazioni tra il Cloud Providers ed i Cloud
Consumers.
Cloud Carrier
Un intermediaro che fornisce connettività e
trasporto dei servizi cloud dal fornitore del
servizio verso gli utilizzatori
Tabella 1: Attori e relativa descrizione delle entità coinvolte in un'infrastruttura di cloud
computing
Il Cloud Provider rende disponoibili i seguenti servizi (vedi figura 2):
Il “service orchestration”: Tale servizio è organizzato in livelli
raggruppa e
coordina i tre seguenti componenti:
Al livello superiore troviamo il service layer che definisce le interfacce
attraverso le quali il Cloud Provider permettere l'accesso ai servizi da parte dei
Cloud Consumers.
Il livello intermedio (il middleware) è detto resource abstraction and
control layer. Tale livello contiene i componenti che il Cloud Providers utilizza per
fornire e gestire gli accessi alle risorse di computing fisiche mediante astrazioni
software implementate grazie a componenti quali hypervisors, virtual machines,
virtual data storage etc.
Francesco Iannone Z62/000014
Pagina 18 di 53
Ad un livello più basso della pila troviamo il livello physical resource, il
quale include tutte le risorse fisiche quali ad esempio CPU, memoria RAM,
dispositivi di rete (router, firewall, switch..), componenti di storage (hard disks), etc.
Il “Cloud Service Management” che include tutti quei meccanismi che sono
necessari alla definizione e gestione delle politiche di qualità e tariffazione sui
servizi offerti ai Cloud Consumers.
“Security Services”: l'insieme dei servizi gestori dei processi di autenticazione,
autorizzazione e di verifica dell'integrità delle identità dei principali attori coinvolti
nell'infrastruttura Cloud Provider, Cloud Consumers, etc.
“Privacy Services”: L'insieme dei servizi che consentono ai Cloud providers di
proteggere in modo sicuro, corretto e coerente tutte le informazioni scambiate e/o
disponibili sull'infrastruttura.
2.4 La Tecnologia Cloud di riferimento: la piattaforma
OpenStack
Come tecnologia Cloud di riferimento considereremo quella realizzata dal progetto
Openstack [5].
Il progetto OpenStack è un cloud system manager open source per tutte le tipologie
di clouds,(private, pubbliche etc) che mira ad essere di semplice implementazione,
altamente scalabile e ricco di funzionalità. OpenStack consente di implementare
alcune delle funzionalità previste dal “service orchestration” e dal “Security
Services” dell'architettura di riferimento del NIST.
Francesco Iannone Z62/000014
Pagina 19 di 53
La piattaforma OpenStack, basata sulla possibilità di virtualizzare4 sistemi, fornisce
una soluzione di tipo Infrastructure as a Service (IaaS) attraverso una serie di
servizi fra loro integrati. Ogni servizio offre una serie di interfacce di
programmazione (API), che ne facilita l'integrazione e l'interazione.
Non esite un'architettura statica di OpenStack ma sono i servizi e le varie opzioni di
storage e networking di cui si ha bisogno a delinearne la topologia.
Possiamo però fornire un esempio di architettura base e descriverne alcuni servizi
da essa offerti.
Una sua semplice implementazione può essere realizzata attraverso la creazione di
due nodi:
•
Un Controller Node sul quale vengono eseguiti i servizi di controllo, alcuni
di questi descritti di seguito.
•
Un Compute Node sul quale risiedono le macchine virtuali gestite a loro
volta da un hypervisor5.
4 Virtualizzare: astrarre le componenti hardware, cioè fisiche, degli elaboratori al fine di renderle
disponibili al software in forma di risorsa virtuale. Tramite questo processo è quindi possibile installare
sistemi operativi su hardware virtuale; l'insieme delle componenti hardware virtuali (RAM, CPU, HARD
DISK..) prende il nome di macchina virtuale
5 Un hypervisor o Virtual Machine Monitor (VMM) è un componente software, firmware o hardware che
crea e gestisce le macchine virtuali.
Francesco Iannone Z62/000014
Pagina 20 di 53
Illustrazione 3: Esempio di un'architettura base di OpenStack
I servizi principali forniti in un tale contesto sono (vedi figura 3):
Keystone: l'identity service, fornisce meccanismi di autenticazione e di
autorizzazione che definiscono e implementano le politiche di accesso e/o gestione
degli utenti ai/dei servizi OpenStack.
Glance: l'Image Service, fornisce servizi di discovery, registration e delivery delle
immagini delle macchine virtuali. Tali immagini una volta rese disponibili su tale
servizio possono essere usate dai nodi Compute per fornire le istanze di macchine
virtuali.
Nova: il servizio disponibile sul Controller Node (il cuore del sistema IaaS) che
crea e distrugge, mediante API dell' hypervisor, le istanze di macchine virtuali.
Francesco Iannone Z62/000014
Pagina 21 di 53
L'architettura è stata progettata per “scalare orizzontalmente”, aggiungendo nuovi
Compute Node, su hardware standard, con la capacità di integrarsi con i sistemi
legacy e le tecnologie di terze parti anche proprietarie. Inoltre consente di
automatizzare la gestione di insiemi di risorse interagendo con diverse tecnologie di
virtualizzazione (ad esempio KVM, etc. ).
Neutron: fornisce il servizio NaaS (network connectivity as a service)
permettendo di definire indirizzi e connessioni di rete in un sistema cloud. Ciò
avviene mediante un' API fornita dal servizio stesso che consente inoltre di
configurare e gestire una varietà di servizi di rete (es. L3 forwarding, NAT, load
balancing..,)
KVM, (Kernel-based Virtual Machine) è una tecnologia di virtualizzazione
integrata nel kernel Linux.
Usando KVM, si possono instanziare più macchine virtuali sullo stesso sitema
ospite (hosting system)6, ciascuna con un proprio hardware (virtualizzato): scheda di
rete, disco, scheda grafica, ecc. Tutto ciò in modo trasparente bilanciando e
partizionando opportunamente l'utilizzo delle risorse fisiche del sistema ospite.
L'hypervisor KVM può:
•
allocare le risorse, anche eterogenee, dinamicamente quando e dove
necessario, effettuare un management delle risorse in modo più efficiente
•
facilitare collaudo e debugging di ambienti controllati
•
ridurre in modo significativo i tempi di risposta in merito all'istanzazione di
nuovi sistemi
6 Un computer su cui un hypervisor esegue una o più macchine virtuali è definito come una macchina host
(o sistema ospite). Ogni macchina virtuale viene detta macchina guest
Francesco Iannone Z62/000014
Pagina 22 di 53
3 Il Progetto GaaS
L’idea di sviluppare GaaS (Grid as a Service) [6] , nasce da esigenze pratiche:
trovare una soluzione per rendere l’ambiente di calcolo distribuito, basato sul
modello Grid, più elastico e più sostenibile, sfruttando le caratteristiche del modello
Cloud senza al contempo perdere il modello di accesso Grid alle risorse che risulta
familiare alle diverse comunità di utenti che già utilizzano la griglia
computazionale.
Il modello Grid, infatti, è tipicamente statico e gli utenti non possono:
•
definire nuovi siti Grid
•
aggiungere risorse a quelle esistenti
•
modificare lo schema di aggregazione delle risorse in base alle proprie
necessità
•
modificare dinamicamente il numero di risorse sulla base del reale carico di
lavoro (sprecando in tal modo energia e non realizzando un ambiente
sostenibile ed efficiente).
La piattaforma GaaS può essere definita come un’infrastruttura di calcolo Grid
flessibile che fa uso di risorse Cloud locali o remote (fisiche o virtuali), allo scopo
di adattare un ambiente Grid di produzione alle reali esigenze dell’utenza in nome
di un utilizzo più efficiente e consapevole delle infrastrutture di calcolo stessa .
Si delinea in tal modo un'infrastruttura che supera le limitazioni dei paradigmi
Grid, fornendo un modello d’uso che risulta già familiare alle utenze della Grid, ed
al contempo traendo vantaggi in termini di miglioramento della flessibilità
dell’infrastruttura ed in termini di una più facile integrazione delle risorse.
Dato che modello di accesso di GaaS è di tipo Grid, ma consente di modificare
dinamicamente sulla base dei bisogni degli utenti, un'infrastruttura Grid preesistente
Francesco Iannone Z62/000014
Pagina 23 di 53
in tutte le sue parti dai sistemi allo strato software su di essi disponibile, il modello
può essere classificato come un sistema Grid-as-a-Service (GaaS).
GaaS attualmente consta nei seguenti quattro servizi:
1. Aggiunta di nuove risorse di calcolo (Worker Node Service: GaaS WNS);
2. Aggregazione di risorse di calcolo esistenti in una nuova coda (Queue
Service: GaaS QS);
3. Aggiunta di un nuovo sito Grid per una VO esistente (Grid Site Service:
GaaS GSS);
4. Creazione di un ambiente di esecuzione adatto per un set di applicazioni su
risorse di calcolo nuove o esistenti (Application Environment Service: GaaS
AES).
Il servizio
GaaS_WNS
gestisce l’integrazione di nuovi WNs
su code di
esecuzione già esitenti sui Computing Element.
Il Sistema acquisisce le risorse cloud (pubbliche o private ), configura tali risorse
come WN della grid, seleziona la coda dove il WN deve essere inserito e viene
avviata una procedura che riconfigura il CE per rendere accessibile tali risorse con il
ruolo di WN
Tale servizio è utile in un tale scenario: ampliare on-demand l’insieme di nodi di
calcolo, per realizzare datacenter efficienti in termini di utilizzo delle risorse
accendendo o spegnendo risorse sulla base delle reali esigenze dell'utenza.
Il servizio Queue Service: GaaS_QS
gestisce l’aggiunta di una nuova coda.
L'utente ha la possibilità di modificare lo schema logico di aggregazione delle
risorse di calcolo, In questo caso il sistema richiede una riconfigurazione del CE,
specificando il set dei WN sottostanti e le policies della coda.
Francesco Iannone Z62/000014
Pagina 24 di 53
Un possibile caso d’uso per questo servizio è una community che necessita di una
particolare policy su una parte dei nodi di calcolo, anche per tale servizio sarà
possibile modificare on-demand tali policy (ad esempio possono essere aumentati i
tempi d'accesso e di utilizzo delle risorse o possono essere modificate le priorità
dello LRMS).
Il servizio
GaaS_GSS gestisce l’integrazione in un'infrastruttura Grid, di un
nuovo sito (CE e WN, SiteBDII) usufruibile da una VO esistente.
Il sistema acquisisce le risorse cloud (pubbliche o private), fa richiesta dei servizi
GaaS_WNS e GaaS_QS, configura un
Information System e seleziona
l’infrastruttura grid dove il nuovo sito deve essere inserito.
Un possibile caso d’uso per questo servizio è quello relativo ad una community che
deve condividere risorse durante il ciclo di vita di un progetto. Un altro scenario
ideale si riferisce alla necessità di costruire on the scratch (da zero), e per un breve
periodo di tempo, un ambiente di test su misura.
Il servizio
GaaS_AES si occupa del servizio Application Enviroment Service
(Ambiente applicativo). Il sistema fornisce sulle risorse allocate, mediante
un’appropriata combinazione dei servizi GaaS_WNS, GaaS_QS e GaaS_GSS, tutto
lo strato software configurato in accordo con le richieste della comunità di utenti e
costruito sulla base di un portfolio software messo a disposizione.
Un possibile caso d’uso per tale servizio può riferisi ad una comunità che desidera
aggiungere ai benefici
apportati dai servizi precedentemente elencati anche la
possibilità di un proprio “middleware applicativo”.
La piattaforma GaaS è basata sul middleware grid EMI e sul sistema di gestione
Cloud OpenStack, entrambi descritti nei paragrafi precedenti. Tutti iservizi GaaS
sono stati sviluppati ed integrati nel contesto del Datacenter S.Co.P.E.
Francesco Iannone Z62/000014
Pagina 25 di 53
dell’università Federico II di Napoli.
Il datacenter S.Co.P.E. consta di 2000 cores computazionali. Le risorse
computazionali sono inserite in un contesti grid sia locale che non locale (grid
nazionali - IGI - ed internazionali – EGI).
Un sottoinsieme dei worker node di S.Co.P.E sono assegnati all'insieme di risorse
gestite da OpenStack.
4 Grid Site Service: GaaS_GSS
Il servizio
GaaS_GSS come già accennato nel paragrafo precedente permette
l'aggiunta di un nuovo sito grid da parte di un utente che ne faccia richiesta e che
abbia le credenzialità necessarie. Tale servizio on demand, acquisisce le risorse
Cloud, istanzia i servizi GaaS_WNS e GaaS_QS, configura e mette in relazione gli
elementi della grid quali il Computing Element (coi i relativi Worker Nodes) ed il
Site Bdii (l'elemento dell'Information Sistem a livello di sito).
Un sito grid deve offrire la possibilità di fornire, tra le altre, anche le risorse di
storage. A tal fine, durante tale lavoro di tesi, si è provveduto a progettare ed
implementare le funzionalità del servizio GaaS_GSS che lo rendessero in grado di
creare ed aggiornare l'insieme di risorse di storage nella disponibilità del sito, sia in
fase di creazione del sito stesso, sia in un secondo momento aggiungendo cioè il
servizio di storage ad un sito preesistente.
Francesco Iannone Z62/000014
Pagina 26 di 53
Illustrazione 4: modello concettuale del servizio GaaS_GSS
La figura 4 rappresenta come il servizio GaaS_GSS permetta l'inserimento in una
infrastruttura di griglia computazionale esistente, di un sito grid completo
costituito da risorse cloud senza che tale infrastruttura debba essere a conoscenza a
priori né del numero né del tipo di risorse che vengono richieste on demand dalle
utenze grid.
Inoltre un sito configurato dalla piattaforma GaaS ben si integra nel contesto più
globale della Grid, più precisamente esso viene visto dagli altri elementi che
effettuano richieste, discovery e retreiving delle risorse (UI, WMS ...), come un
normale sito appartenente alla griglia e messo a disposizione della comunità.
Francesco Iannone Z62/000014
Pagina 27 di 53
4.1 Il GaaS Cloud Management Controller: l'architettura
generale
L'approccio utilizzato nella realizzazione della piattaforma GaaS segue il paradigma
dell'architettura modulare. Il GaaS Cloud Management Controller (GaaS-CMC) ha
l'obiettivo di integrare, in una struttura modulare, tutti i meccanismi necessari al
sistema di controllo del servizio GaaS_GSS di GaaS. GaaS-CMC si compone di
moduli che raggruppano una o uno specifico insieme di funzionalità per la fornitura
di uno o più servizi. L'infrastruttura, realizzata in tal modo, risulta altamente
scalabile, flessibile e di facile manutenzione in quanto garantisce una certa
indipendenza dell'intera piattaforma dalle scelte implementative adottate.
Francesco Iannone Z62/000014
Pagina 28 di 53
La figura 5 descrive l'architettura ad un livello più alto di astrazione. Essa racchiude
tutti i moduli nell'unica componente logica:GaaS_CMC.
Quest'ultima può essere suddivisa in due sezioni di cui la prima raccoglie i moduli
per l'interfacciamento con l'esterno della componente CMC (GaaS_Interface)
delegando l'altra (GaaS_Engine) alla gestione dei servizi GaaS.
Di seguito sono descritte le caratteristiche delle sezioni:
GaaS_Interface:
•
Interfacce Utenti: si occupano di far interagire la piattaforma GaaS con gli
applicativi di front-end ultimi (web o mobile) accogliendo le richieste da
parte delle utenze della comunità;
•
Interfacce Grid: si preoccupano di far interagire la piattaforma GaaS con le
Griglie computazionali;
•
Interfacce Cloud: si preoccupano di far interagire la piattaforma GaaS con i
CMS (Cloud Management System).
GaaS_Engine:
•
Moduli GaaS: insieme delle procedure che implementano “l'intelligenza”
del Controller GaaS;
•
Gestore Risorse: strumenti per la memorizzazione e gestione dei dati relativi
allo stato dell'infrastruttura gestita da GaaS..
La struttura modulare dell'architettura permette di considerare i vari moduli come
delle black-box in quanto si considerano, in tale contesto, i servizi che sono offerti
prescindendo dalla loro implementazione. Infatti nulla vieta di sostituire
un'implementazione di un modulo con un'altra purché esso offra lo stesso servizio
con le stesse interfacce di input ed output. Ad esempio, per la gestione dati, può
essere utilizzato in un primo momento un DBMS Mysql e decidere poi di passare
ad un ulteriore DBMS come Oracle, Pgsql, etc.
Francesco Iannone Z62/000014
Pagina 29 di 53
Inoltre, un altro significativo esempio è quello che prevede la possibilità di
interfacciare GaaS con altri e diversi
CMS semplicemente aggiungendo o
sostituendo il modulo di interfacce Cloud.
4.2 Architettura di Riferimento
Vengono descritte, ora, le scelte implementative adottate per i moduli elencati in
precedenza.
La scelta di utilizzare interfacce standard ha naturalmente indirizzato verso
tecnologie open e ampiamente diffuse per l'implementazione dei servizi di GaaS.
Francesco Iannone Z62/000014
Pagina 30 di 53
La figura 6 particolarizza la figura 5 associando i suoi moduli con le relative scelte
implementative, che sono riassunte nella tabella che segue.
Moduli
Scelta Implemetativa
Interfaccia Utenti
Tomcat
Interfaccia Cloud
Client OpenStack
Interfaccia Grid
Strumenti EMI
Gestore delle Risorse
DBMS MySql
Moduli GaaS
Procedure implementate usando linguaggi
quali il python e il bash scripting
4.3 Il GaaS CMC inserito in una architettura multilivello
Il componente GaaS_CMC si inserisce nell'architettura del sistema GaaS
realizzando un modello strutturato secondo
un' architettura client-server
multilivello:
Ad un livello più basso ritroviamo la piattaforma Openstack la quale si compone a
sua volta di:
•
Un Controller Node sul quale sono installati i moduli atti a fornire i servizi
di autenticazione, gestione della rete, dell'avvio delle istanze etc. Descritti nel
paragrafo 2.4.
•
Due Compute Nodes, i quali ospitano le macchine virtuali ed il relativo
hypervisor (kvm) che si occupa della gestione di quest'ultime.
Ad un livello superiore ritroviamo il GaaS_CMC che ha lo scopo di fornire:
Francesco Iannone Z62/000014
Pagina 31 di 53
•
Servizi di monitoraggio e gestione delle risorse: tali servizi sono
implementati mediante i moduli di GaaS contenuti nel Gaas_Engine, che
affiancano quelli già previsti dalla piattaforma cloud utilizzata, ma necessari
ad ottimizzare il processo di schedulazione delle richieste, concorrenti ed
eterogenee, effettuate dagli utilizzatori dei servizi di GaaS.
•
Un DBMS7 MySql, per poter gestire una base di dati relazionale, chiamata
gaasDB volta ad immagazzinare i dati relativi a:
◦ stato delle risorse: disponibili, occupate, in fase di instanziazione, etc
◦ stato delle richieste: in attesa di essere servite, processate ...
◦ le utenze: il ruolo assunto nel contesto della piattaforma GaaS (utente o
amministratore), i siti ai quali afferiscono ...
Diversi sono i moduli che si relazionano alla base dati gaasDB, il quale sarà
più approfonditamente descritto nel prossimo paragrafo:
◦ I moduli GaaS attraverso API MySQLdb8 , per per la gestione e/o il
monitaraggio delle risorse
◦ La java Servlet mediante API JDBC9, per sottomettere le richieste di
creazione, modifica ed eliminazione di elementi di un sito o di una
particolare utenza.
7
DBMS: “DataBase Management System”, si tratta di un particolare software che permette di creare e
gestire un database e consente l''accesso e la manipolazione dei dati in modo semplice, concorrente, e
discriminato (in base ai ruoli concessi ad un entità, persona fisica o sistema).
8 MysQLdb:modulo python che fornisce l'interfacciamento verso il DBMS MySql
9 JDBC: è un connettore per database che consente l'accesso alle basi di dati da qualsiasi programma
scritto con il linguaggio di programmazione Java
Francesco Iannone Z62/000014
Pagina 32 di 53
•
Sicurezza: l'aggiunta di tale ulteriore livello architetturale
limita
l'esposizione dell'infrastruttura Cloud ad attacchi dall'esterno.
•
Funzionalità di interfacciamento:
◦ Verso la piattaforma OpenStack: A tale scopo sono installati i pacchetti:
python-keystoneclient che abilita i comandi per l'interazione con
l'Identity-service di OpenStack; python-novaclient che abilita i comandi
per l'interazione con i servizi di calcolo e di management di OpenStack;
python-neutronclient che abilita i comandi per l'interazione con il gestore
della rete di OpenStack.
◦ Verso le applicazioni di front-end, web o mobile: è presente un server
Tomcat che ospita una Servlet Java che assolve tale compito.
Il GaaS_CMC quindi, da un lato sfrutta i servizi e le funzionalità della
piattaforma openstack di più basso livello, dall'altro serve le richieste delle
applicazioni che arrivano dall'esterno. Dunque può essere visto sia come un
client (nel primo caso) sia come un server (nel secondo).
Francesco Iannone Z62/000014
Pagina 33 di 53
4.4 Il database:gaasDB
L'aggiunta di tale elemento strutturale come già descritto nel paragrafo precedente,
è motivato
•
dalla necessità di tenere traccia delle informazioni sulle esecuzioni delle
operazioni che avvengono sul sistema e conservare le informazioni sullo
stato della piattaforma
•
dall'eterogeneità degli attori coinvolti nel sistema.
Ciò è reso possibile grazie alla presenza del DBMS MySql che consente l''accesso e
la gestione dei dati in modo semplice, concorrente, e sulla base di specifiche
politiche di accesso.
In figura 7 viene riportato il modello ER (Entità-Relazione) del database gaasDB.
Si procederà alla descrizione di alcune delle entità coinvolte, raggruppandole in
base ai moduli e i servizi che ne fanno uso.
I moduli Gaas, per fornire servizi di gestione e di monitoraggio delle risorse in un
ambiente multiutente e concorrente, accedono ed utilizzano i dati contenuti nelle
seguenti tabelle:
ESECUZIONI: contiene le informazioni relative al flusso di richieste dellerisorse.
In particolareraccoglie:
•
l'identificativo dell'utente che ha effettuato la richiesta
•
il momento in cui tale richiesta è stata fatta
•
lo stato in cui versa la richiesta
•
il tipo della richiesta
Usufruendo di tale tabella è possibile dunque gestire le richieste da parte degli utenti
che si ricorda avvengono in modo concorrente.
Francesco Iannone Z62/000014
Pagina 34 di 53
IP: le informazioni relative alla rete di connessione (indirizzi IP, hostname,
etc.)assegnabili in fase di instanziazione degli elementi previsti dai servizi di GaaS
Dal momento che un indirizzo di rete potrà essere utilizzato soltanto se non è stato
già impiegato per l'implementazione di un altro elemento di un sito, ogni tupla di
tale tabella conterrà un campo che descrive tale stato
FLAVOR: le tuple di tale tabella indicano le caratteristiche in termini di CPU,
RAM, numero di dischi...) che possono caratterizzare i vari elementi del sito grid
richiesti on demand dalle utenze GaaS.
RISORSE: tabella atta a contenere le risorse HW (i nodi compute) di macchine
virtuali che implementano gli elementi previsti dai servizi di GaaS .
Le restanti tabelle sono fortemente correlate tra di loro, (presentano molteplici
vincoli di integrità) e forniscono tutto ciò che riguarda le risorse che sono state
istanziate.
Ritroviamo pertanto:
SITI: contiene tutte le informazioni riguardanti i siti istanziati (ID,NOME, INFO,
STATO), gli identificativi degli utenti che hanno fatto richiesta di instanziazione
(USER) e gli elementi che caratterizzano ciascun sito (numero di WN massimo ed
utilizzati, CE).
ELEMENTI: detiene i dati strutturati in merito agli elementi dei siti grid, ciascuna
tupla permette di ricavare informazioni in merito al tipo di elemento (CE, SE...), al
Francesco Iannone Z62/000014
Pagina 35 di 53
sito e all'utente al quale afferisce e così via.
USERS:contiene i dati dei diversi utenti della community grid che fanno uso delle
risorse fornite tramite la piattaforma GaaS,
SE: tabella atta a contenere i dati in merito alle istanze che forniscono i servizi di
storage element. Le informazioni che si è scelto di immagazzinare riguardano
essenzialmente:lo spazio occupato, disponibile e totale.
Nel prossimo capitolo verrà introdotto un caso d'uso che descrive un possibile
scenario collocando le operazioni svolte, ottenute mediante la fornitura dei servizi,
sull'infrastruttura GaaS.
Francesco Iannone Z62/000014
Pagina 36 di 53
Illustrazione 7: Schema Entità-Relazione che modella il database gaasDB
Francesco Iannone Z62/000014
Pagina 37 di 53
4.5 Un caso d'uso: richiesta e creazione di un elemento grid
Dopo aver fatto una panoramica sui servizi offerti dalla piattaforma GaaS, descritto
l'architettura di coordinamento di tali servizi ed introdotto le possibili entità
coinvolte, ci proponiamo di descrivere il flusso delle operazioni che si attivano
allarichiesta, da parte di un utente di un elemento per un sitogrid attraverso un
diagramma dei casi d'uso (vedi figura 8 ). Tale flusso è utile anche per meglio
illustrare le modalità con le quali il GaaS_CMC provvede a coordinare tutte le sue
componenti in risposta alla richiesta utente.
Illustrazione 8: caso d'uso per la funzionalità di “creazione di un elemento grid”
Al componente GaaS_CMC vengono sottoposte le richieste per la creazione di uno
o più elementi della Grid. Tali richieste possono essere sottomesse, tramite apposite
interfacce (Portali WEB, App per dispositivi mobile, etc.), da utenti abilitati
Francesco Iannone Z62/000014
Pagina 38 di 53
all'utilizzo dei servizi di GaaS.
La richiesta di creazione di un elemento Grid, viene gestita dal componente
GaaS_CMC, che sfruttando i servizi presenti su quest'ultimo (keystone client e
tabella USERS del gaasDB), identifica e autorizza la richiesta. Lo step successivo
sarà servire tale richiesta, ciò viene fatto solo a seguito di una verifica di
disponibilità delle risorse rispetto a quelle richieste.
In caso di esito positivo, il GaaS_CMC provvede a definire l'apposito file di
contestualizzazione10 utilizzato nella creazione dell'elemento richiesto sui compute
nodes sfruttando i servizi del Cloud Manager. Una volta che l'istanza è stata avviata
sul nodo compute
questa avvia la procedura di configurazione dell'ambiente
necessario al suo inserimento nel contesto Grid di riferimento.
5 Creazione di un Elemento per lo Storage (SE)
La finalità dei paragrafi che seguiranno è quella di descrivere il flusso di esecuzione
delle procedure richiamate per l'instanziazione e il suo inserimento in un sito Grid
di un elemento di storage o Storage Element (SE). Si è scelto di descrivere il
servizio di storage, ma le modalità e gli approcci utilizzati sono del tutto generali e
sono utilizzabili per l'instanziazione di elementi di altro tipo (Computing Element,
Site BDII, etc.). Si utilizzeranno diagrammi di flusso o flow chart nella cui
descrizione si farà riferimento a tutte le procedure realizzate che si occupano
dell'implementazione di servizi e delle funzionalità descritte nei paragrafi
precedenti.
10 Con i termini di “file di contestualizzazione” si intende l'insieme dei parametri che definiscono la
configurazione del ruolo da instanziare
Francesco Iannone Z62/000014
Pagina 39 di 53
5.1 Verifica della disponibilità delle risorse
Il diagramma di flusso rappresentato in figura 9 descrive una prima parte delle
funzionalità assolte dalla procedura add-se eseguita per rispondere alla richiesta
utente dell'aggiunta di Storage Element ad un sito Grid esistente. I parametri di
input della procedura add-se sono:
•
User: è l'utente che effettua la richiesta di aggiunta SE.
•
Sito: l'id del sito di riferimente al quale lo storage element deve essere
aggiunto.
•
Flavor: le caratteristiche in termine di dischi, memoria ram, numero di cpu
che l'immagine virtuale, customizzata nel ruolo di storage element, dovrà
avere.
Una volta definita l'appartenenza, l'ubicazione (ovviamente logica) ed il profilo
Hardware dell'SE, viene messa in coda una richiesta di controllo risorse. Ciò si
traduce a più basso livello nell'inserimento nella tabella esecuzione del database
gaasDB, della richiesta di controllo delle risorse. Per differenziare le diverse entry
nella suddetta tabella e per una corretta schedulazione, vengono forniti in input oltre
all'utente ed all'id del sito, anche la data in cui tale richiesta avviene.
La procedura che si occupa di fare ciò è db_insert_into_esecuzione che una volta
ricevuti i parametri di ingresso ed agito sul db, restituisce il valore del parametro di
output
esecuzione che coincide con l'identificativo dell'esecuzione stessa, di
profonda utilità poiché adoperato nelle fasi successive.
Il passo seguente infatti utilizza tale parametro per verificare che la coda di
controllo sia vuota, o meglio che il sistema sia pronto a servire il controllo delle
risorse sui nodi compute dell'architettura. In caso affermativo avviene poi l'effettivo
check delle risorse.
Francesco Iannone Z62/000014
Pagina 40 di 53
Il controllo sulla disponibilità delle risorse avviene mediante la procedura
controllo_risorse-se la quale accetta in input il flavor desiderato relativo all'SE
richiesto dall'utente.
Nel caso in cui le risorse richieste non risultino disponibili, si richiama un'ulteriore
procedura che aggiorna la tabella esecuzione inserendo un messaggio di errore (di
tipo ERROR1) che rappresenta tale indisponibilità che sarà resa nota all'utente che
ha fatto richiesta.
In caso di disponibilità invece, vengono avviate una serie di azioni descritte nel
diagramma di flusso in figura 10.
Francesco Iannone Z62/000014
Pagina 41 di 53
Illustrazione 9: Diagramma di flusso che verifica la disponibilità delle risorse
Francesco Iannone Z62/000014
Pagina 42 di 53
5.2 Schedulazione delle risorse
Stabilita
la
disponibilità
delle
risorse,
mediante
la
procedura
db_update_esecuzione, viene effettuata una sottomissione alla coda esecuzioni,
viene aggiornata la tabella esecuzioni con il valore WAIT per indicare all'utente che
l'assegnazione delle risorse è in attesa di essere servita.
La fase successiva effettua un controllo sulla disponibilità di IP da assegnare
all'elemento grid richiesto. Tale controllo avviene con una procedura del tutto
analoga a quella vista precedentemente (vedi paragrafo 5.1) con la differenza che
adesso si va ad interrogare la tabella IP del database gaasDB e che, in caso di
indisponibilità, il messaggio visualizzato sarà di tipo ERROR2.
A questo punto si è pronti ad assegnare risorse sia fisiche che logiche, si procede
allora con una fase di retrieving delle informazioni in merito all'SE e agli elementi
ad esso correlati, ciò avviene grazie a query effettuate sul database attraverso la
procedura db_select_sb. Concorrentemente viene aggiornata la tabella esecuzioni
aggiornando il campo stato con il valore EXECUTING.
Infine si procede con la creazione dello storage element, sfruttando i parametri
ricavati nella fase precedente che vengono passati alla procedura create_se.
Francesco Iannone Z62/000014
Pagina 43 di 53
Illustrazione 10: Diagramma di flusso della procedura che schedula la richiesta di risorse
Viene inoltre aggiornato lo stato di esecuzione che da EXECUTING diventa
Francesco Iannone Z62/000014
Pagina 44 di 53
DONE, indicando che il compito di aggiunta dello storage element è stato assolto.
5.3 Definizione e propagazione dei file di
contestualizzazione
La procedura create_se è utilizzata per inserire in modo opportuno un SE in un
sito già esistente, con propri CE, WNs e SiteBDII.
Nello specifico i parametri di ingresso vengono utilizzati per ricavarne altri (ad
esempio dall'IP dello storage element ne si ricava l'hostname) che vengono
impiegati per la definizione dei file di contestualizzazione, sulla base del template,
in merito alla creazione dell'SE (mediante la procedura crea_scope_se) ed alla
configurazione permanente delle reti (mediante le procedure hosts e scrivi_icfg).
I files creati vengono poi archiviati, per essere “iniettati” nell'istanza della VM che
si andrà a creare mediante la procedura SE.sh descritta nel prossimo paragrafo.
Le informazioni relative all'SE e agli elementi ad esso correlati, ricavate nelle fasi
precedenti, vengono poi immagazzinate nel database gaasDB.
Tale procedura viene richiamata, con i dovuti parametri di ingresso, anche all'atto
della creazione di un nuovo sito Grid, ad esempio in uno scenario in cui un gruppo
di ricerca è già a conoscenza che per la realizzazione ed il successo di un proprio
progetto, necessita oltre alle risorse di calcolo anche di servizi di storage.
Francesco Iannone Z62/000014
Pagina 45 di 53
Illustrazione 11: Diagramma di flusso che sintetizza la fase di definizione dei file di
contestualizzazione
Francesco Iannone Z62/000014
Pagina 46 di 53
Illustrazione 12: Attività eseguite all'avvio dell'istanza della VM sulla quale èinstanziato il
ruolo
Francesco Iannone Z62/000014
Pagina 47 di 53
Tale script dunque, eseguito avvia alla partenza della VM la procedura Mio.sh (vedi
paragrafo successivo) che: abilita lo Storage Element all'inoltro dei pacchetti,
scompatta gli archivi iniettati in fase di creazione della VM, configura i file relativi
ai servizi del middleware EMI ovvero site-info.def, emi_dpm_mysq e emibdii_site, aggiungendo e/o sostituendo variabili d'ambiente relative all'SE
necessarie alla corretta configurazione di yaim.
I files una volta contestualizzati, vengono copiati sugli altri elementi appartenenti al
sito grid di riferimento ovvero il CE ed il Site BDII; la copia è resa necessaria
affinchè nei loro files di configurazione risulti la presenza dello Storage Element,
che si ricorda, può essere aggiunto in un secondo momento.
La procedura prosegue l'esecuzione:
1. consolidando la configurazione dei parametri di rete.
2. configurando il firewall per consentire l'opportuno accesso ai servizi del
middleware, come i protocolli SRM nelle sue diverse versioni, RFIO,
GRIDFTP.
3. eseguendo quanto necessario a completare le fasi di configurazione del
middleware mediante gli opportuni strumenti (comando yaim).
Francesco Iannone Z62/000014
Pagina 48 di 53
5.4 Creazione istanza
La creazione dell'istanza avviene mediante la procedura SE.sh che, interagendo con
gli strumenti messi a disposizione dal Cloud Manager OpenStack,si occupa:
•
della creazione delle interfacce di rete virtuali mediante il comando neutron
port-create
•
della crezione dello script da eseguire all'avvio della VM: Mio.sh (Main
installer object)
•
del lancio della VM mediante il comando nova boot, i cui parametri
specificano cosa fornire alla VM ovvero: chiave e certificato, la lista delle
risorse hardware ed i files locati sul nodo client da iniettare.
5.5 Funzionalità a contorno
5.5.1 Update SE
Tale procedura, eseguibile sul client node, riceve come parametro di ingresso
l'hostname dello Storage Element, sfruttando tale parametro viene effettuato il
collegamento tramite ssh allo stesso SE residente sul relativo nodo compute.
Il collegamento avviene in maniera del tutto automatizzata mediante sshpass, che
come già descritto nell'architettura del sistema GaaS, dovrà essere installato sul
nodo client.
Francesco Iannone Z62/000014
Pagina 49 di 53
A collegamento avvenuto vengono ricavate le informazioni sullo spazio diponibile,
usato e totale. I dati così ottenuti vengonoutilizzati dalla procedura update_space
per aggiornarela tabella SE in merito ai campi che si riferiscono allo stato dello
spazio disponibile sullo storage element.
Illustrazione 13: Diagramma di flusso in merito all'aggiornamento dello spazio
disponibile sullo storage element
Francesco Iannone Z62/000014
Pagina 50 di 53
5.5.2 Delete SE
Tale procedura, eseguibile dal client node, riceve come parametro di ingresso
l'hostname dello Storage Element, che viene utilizzato dai comandi nova per
identificare e cancellare l'istanza stessa mediante il comando nova delete.
La procedura richiama a sua volta la procedura db_delete_se che effettua
l'eliminazione dei dati relativi allo SE nelle opportune tabelle del database gaasDB.
La procedura provvede inoltre a notificare agli altri ruoli del sito che ospita lo SE da
eliminare (CE e site BDII) l'avvenuta eliminazione e a richiedere loro la necessaria
riconfigurazione
Illustrazione 14: Flusso delle attività svolte in fase di eliminazione dello storage element
Francesco Iannone Z62/000014
Pagina 51 di 53
Conclusioni e sviluppi futuri
L'obiettivo di tale lavoro di tesi è stato quello di progettare ed implementare quanto
necessario all'instanziazione di uno dei servizi previsti dalla piattaforma GaaS che si
propone quale approccio possibile all'integrazione dei paradigmi di Grid e Cloud
Computing.
La prima parte della tesi ha descritto la piattaforma GaaS, dopo aver introdotto
alcuni necessari ed utili concetti relativi ai paradigmi del Grid e del Cloud
Computing. Di GaaS è stata offerta una panoramica delle motivazioni che hanno
portato a realizzarla nonchè delle funzionalità che implementa ed dei servizi che
offre.
Nella seconda parte della tesi si è focalizzata l'attenzione sullo specifico obiettivo di
tale lavoro: la progettazione e l'implementazione del GaaS Cloud Management
Controller (GaaS-CMC) che ha l'obiettivo di integrare, in una struttura modulare,
tutti i meccanismi necessari al sistema di controllo del servizio GaaS_GSS, con
particolare riguardo a quanto necessario all'instanziazione di ruoli GRID per la
memorizzazione e l'accesso dei dati.
L'implementazione effettuata, che ha consentito la realizzazione di un prototipo di
GaaS attualmente disponibile sulle risorse del Datacenter SCoPE, consente di
instanziare elementi grid per lo storage di tipo DPM sia in siti grid esistenti che in
nuovi siti da instanziarsi on demand.
Parte dell'attività futura potrebbe essere dedicata sia al miglioramento del
provisioning di ruoli DPM (vedi ad esempio ruoli DPM multidisco e distribuiti) sia
al provisioning di ruoli per lo storage di altro tipo quali ad esempio dCache e Storm.
Francesco Iannone Z62/000014
Pagina 52 di 53
Bibliografia
1: Ian Foster e Carl Kesselman, The Grid: Blueprint for a New Computing Infrastructure,
1998
2: EMI - European Middleware Initiative, http://www.eu-emi.eu/documentation
3: Peter Mell, Timothy Grance, The NIST Definition of CloudComputing,
4: F. Liu, J. Tong, J. Mao, R. Bohn, J. Messina, L. Badger and D. Leaf, NIST Cloud
Computing Reference Architecture, 2011
5: OpenStack Foundation, OpenStack Cloud Software, 2013
6: V. Boccia, G.B. Barone, R.Bifulco, D. Bottalico, L. Carracciuolo, R. Canonico, GaaS:
Customized Grids in the Clouds, Lecture Notes in Computer Science, Proceedings of EuroPar 2012: Parallel Processing Workshops, 7640 , 577-586, 2013,
http://dx.doi.org/10.1007/978-3-642-36949-0_67
Francesco Iannone Z62/000014
Pagina 53 di 53