Analisi degli standard OCCI per il Cloud Computing

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Analisi degli standard OCCI per il Cloud Computing Anno Accademico 2013/2014 Candidato: Luigi Vanacore matr. N46/000037

2 Per i molti che non hanno creduto in me, Per i pochi che l hanno fatto, Per i miei Amici

3 Indice Analisi degli standard OCCI per il Cloud Computing... I Indice... III Introduzione... 4 Capitolo 1: Il Cloud Computing e lo Standard OCCI Il Cloud Computing Lo standard OCCI Il vero obiettivo: l Open Cloud Capitolo 2: Lo Standard OCCI - analisi Storia dello standard I tre modelli di OCCI Modello Centrale OCCI Modello Rendering HTTP OCCI Modello Infrastruttura OCCI Capitolo 3: Caso d uso Framework SLA@SOI Conclusioni Dedica Bibliografia... 30

4 Introduzione Sempre di più l'intera nostra società è dipendente dalla tecnologia, e ancor di più dall'informazione. Va da sé che lo sviluppo del ICT (Information and communications technology), ovvero l'insieme delle tecnologie che gestiscono e trasmettono le informazioni, ha enormi impatti nelle nostre vite. Ogni qual volta una nuova tecnologia del ICT viene alla luce, migliorando e incrementando il flusso di informazioni, si ha una vera e propria rivoluzione sociale. Questo è vero soprattutto quando questa nuova tecnologia diventi accessibile al vasto pubblico. Esempi di quanto detto si sprecano nella storia degli ultimi cinquant'anni. Partendo dalla diffusione massiccia dei personal computer nel mercato consumer, fino all'introduzione delle prime reti internet accessibili da tutti, e non più appannaggio solo dei campus universitari o apparati militari. Ogni anno sembra che sia difficile che qualcosa di nuovo possa non solo essere inventata, ma soprattutto che possa entrare senza problemi nel vasto insieme di di tecnologie, componenti, hardware e software, che fanno parte dell'intero ecosistema del ICT. Eppure in questi anni una tecnologia si sta facendo sempre più strada in maniera decisa, con il sicuro risultato di rivoluzionare completamente non solo l'interazione delle persone con le tecnologie informatiche, ma anche soprattutto le loro vite: il Cloud Computing. Nella sua iniziale diffusione il Cloud Computing fu utilizzato per lo più nelle grandi aziende, che vedevano in questa tecnologia un modo per migliorare non solo la loro gestione dell'informazione, ma anche i costi di mantenimento che ne derivano, senza perderne né in efficienza che in qualità, ma ottenendo inoltre notevole flessibilità nella gestione delle risorse IT. A questa iniziale sostenuta crescita dell'adozione della tecnologia, è avvenuta in seguito un inesorabile declino. Declino che si è arrestato da alcuni anni, facendo risultare una nuova crescita, questa volta 4

5 però più sostenuta. Il Cloud Computing è ritornato quindi ad essere una tecnologia dall'utilizzo sempre più diffuso. Sono nati sempre più provider che offrono servizi Cloud, sia essi di semplice storage, o anche elaborativo, offerti sia all'utente consumer comune che alle grandi aziende. Questo nuovo sviluppo sembra non volersi fermare più. Un tale sviluppo però porta numerosi problemi. La progressiva frammentazione dei provider di servizi ha iniziato a creare un problema di comunicazione e interfacciamento fra le varie incarnazioni di Cloud Computing che le grandi compagnie hanno sviluppato. Questo ha portato a un sempre più bisogno di avere un nuovo modo di comunicare fra realtà diverse in un ambiente sempre più eterogeneo. Questo bisogno ha portato alla nascita di progetti open source volti a creare un'interfaccia comune fra i vari CC. Non solo sono nati progetti come OpenGrid, OpenStack, e altri progetti volti a rendere più omogeneo la realtà del CC, ma è anche nato un insieme di standard volti a creare un interfaccia comune fra le varie realtà. Un insieme di Api e di applicazioni, ovvero il progetto OCCI (Open Cloud Computing Interface). 5

6 Capitolo 1: Il Cloud Computing e lo Standard OCCI 1.1 Il Cloud Computing Come molte realtà ancora in divenire, non esiste una definizione accettata da tutti per il Cloud Computing. Ne esistono infatti diverse, ognuna delle quali lo descrive secondo diversi punti di vista. La più diffusa definisce il Cloud Computing come un servizio fornito su rete, che ci permette di utilizzare un insieme di risorse, sia hardware che software, contenute in una particolare struttura, alla quale vi si può accedere via Internet o tramite una rete locale. L'insieme di risorse IT e la loro gestione verranno nascoste all'utente finale, che percepirà il tutto solo come servizio offerto da un provider. L'implementazione effettiva delle risorse non è definita in modo dettagliato; anzi l'idea è proprio che l'implementazione sia un insieme eterogeneo e distribuito di risorse. Sarà compito del provider del servizio provvedere alla gestione e alla manutenzione delle risorse. I vantaggi dell'uso del Cloud Computing sono molti, soprattutto economici e tecnici. Il primo da considerare è sicuramente l'abbassamento dei costi della gestione e della manutenzione delle risorse IT per le aziende, demandando così il fabbisogno di queste all'utilizzo di servizi Cloud. Le aziende piccole medie e grandi hanno costi ridotti e maggiori flessibilità, senza dotarsi di forniture ICT che hanno il loro maggiore utilizzo solo nei momenti di forte stress. Inoltre i costi di installazione, configurazione e manutenzione dei sofisticati apparecchi e costose licenze non è più considerato. Inoltre le aziende possono aziende piccole, medie e grandi hanno costi ridotti e maggiore flessibilità nel breve e medio termine in quanto non hanno più bisogno di installare, configurare e dismettere sofisticati apparecchi o costose licenze. Le aziende possono aumentare la loro richiesta di hardware e software necessari, il tutto semplicemente con un cambio di provider, senza dover smantellare le infrastrutture esistenti, ottenendo di conseguenza un notevole ritorno economico in termini di risparmio e ottimizzazione. Questi sono solo alcuni dei punti a favore dell'adozione del Cloud Computing da parte 6

7 delle aziende, che ne hanno decretato quindi un notevole successo nell'ambito business. Per quanto riguarda il mercato consumer, il Cloud Computing non è ancora diventato una tecnologia dominante. Sicuramente sono aumentati gli utilizzi di servizi cloud specialmente di storage da parte degli utenti. Nonostante questo, le maggiori compagnie IT vedono per il cloud un grande futuro nell'utilizzo dell'utente comune. Servizi come Skydrive di Microsoft, GoogleDrive di Google e molti altri, dimostrano che il futuro per il Cloud deve ancora essere scritto. Di sicuro il Cloud Computing entrerà sempre più nelle nostre vite, per rimanerci a lungo. 7

8 1.2 Lo standard OCCI Lo Open Cloud Computing Interface (OCCI) comprende un insieme di protocolli e Api, sviluppate attraverso l'open Grid Forum, il cui scopo è quello di creare un'interfaccia aperta e standardizzata fra più servizi cloud. Costruito sopra i fondamentali del World Wide Web, OCCI usa l'approccio Representational State Transfer (REST). Basato inizialmente sul modello di servizio cloud Infrastructure as a service (Iaas), permetteva lo sviluppo di strumenti interoperabili per compiti comuni, incluso lo sviluppo, lo scaling automatico e il monitoraggio delle risorse. Da lì, OCCI si è ulteriormente evoluto, riuscendo ore a servire gli altri due maggiori modelli di servizio, quali Platform as a Service (PaaS) e Software as a Service (SaaS). 8

9 Gli obiettivi di OCCI sono i seguenti: Interoperabilità: permettere a differenti provider di Cloud di lavorare insieme senza la traduzione di schema/formati dei dati, facade/proxying fra Api e dipendenza fra multiple Api. Portabilità: permettere la possibilità che il servizio si muova fra diversi provider permettendo al client di cambiare facilmente provider in modo da conseguire diversi obiettivi di business ( per esempio riduzione di costo), con il minimo impatto e incoraggiando la competizione. Integrazione: può essere implementata sia sull'ultima infrastruttura che quelle legacy. Lo sviluppo e la crescita di OCCI continua ancora oggi, con lo sviluppo guidato dalle direttive della comunità dell'open Grid Forum. 9

10 1.3 Il vero obiettivo: l Open Cloud Migrare servizi nel cloud porta tutti i benefici di elasticità, scalabilità e costi tagliati. Comunque, la migrazione dei servizi fra diverse infrastrutture cloud o al di fuori del cloud non è ovviamente una facile operazione. In aggiunta, i servizi distribuiti su multipli provider di cloud, o un installazione ibrida richiedono un implementazione apposita che deve essere ripetuta al cambio di infrastruttura. Questa situazione alza il problema del lock-in e scoraggia l'adozione del cloud. Gli standard open del cloud computing sono progettati per provvedere a risolvere queste situazioni e portare interoperabilità e portabilità all'ambiente cloud. Il vero problema però non risiede nelle diverse implementazioni di ogni provider, ma nella diversità della rappresentazione dei dati memorizzati (documenti, record di database, etc). tipicamente i provider di servizi cloud memorizzano i dati in ordine di fornire un servizio, non è semplicemente possibile iniziare a utilizzare un servizio da un altro provider si ha bisogno infatti prima di esportare tutti i dati dal primo provider in un formato standard open e poi importare il tutto nel secondo. Per di più, per automatizzare il processo si ha bisogno che tutti e due i provider espongano un interfaccia standardizzata e aperta. Usando quindi open standard in questo campo è possibile garantire all'utente importanti libertà e contemporaneamente permettere alle compagnie provider di aumentare i loro profitto, questo è quello che significa quando si parla di Open Cloud L'Open Cloud è quindi un obiettivo primario nello sviluppo del Cloud Computing. Ma dopo aver compreso la sua importanza, è altrettanto importante saper capire quali sono i requisiti che l'open Cloud deve rispettare per perseguire appieno il suo scopo. 10

11 I requisiti che l'open Cloud deve rispettare sono: Formati Aperti: Tutti i dati e i metadati degli utenti devono essere rappresentati in un formato Open Standard Interfacce Aperte: tutte le funzionalità devono essere esposto attraverso un'interfaccia Open Standard. Nessuna Barriera: Gli utenti devono essere in grado di accedere ( nessuna barriera di ingresso) e di lasciare ( nessuna barriera di uscita) qualsiasi servizio di cloud, senza dare importanza a chi essi sono ( nessuna discriminazione) e quale sistema essi usano ( neutralità tecnologica). I venditori supportati devono, di conseguenza, cooperare sugli standard, implementando quelli che esistono ( dove applicabile) e collaborare per avviare un processo aperto di sviluppo per quelli che non esistono ancora, con l'obiettivo di arrivare a una competizione dei vari servizi basato solo sulla qualità. 11

12 Capitolo 2: Lo Standard OCCI - analisi 2.1 Storia dello standard Lo sviluppo di OCCI iniziò nel Marzo 2009 e fu inizialmente guidato da co-chair da quella che era la Sun Microsystems, RabbitMq e l'università Complutense de Madrid. Oggi il gruppo di lavoro raccoglie oltre 250 membri attivi e include numerosi partner individuali sia industriali che accademici. Alcuni di questi membri che hanno contribuito allo sviluppo sono: Industria: Rackspace, Oracle, Platform Computing, GoGrid, Cisco, Flexiscale, ElasticHosts, CloudCentral, RabbitMQ, CohesiveFT, CloudCentral. Università & Ricerca: SLA@SOI, RESERVOIR, Claudia Project, OpenStack, OpenNebula, DGSI. Le specifiche esistenti per il modello IaaS sono fornite da singoli venditore, lo sviluppo è invece basato sulla community con lo scopo di creare un open standard API royalty-free. OCCI migliora l'interoperabilità Iaas e incrementerà la competizione. OCCI è anche un importante enabler per la creazione di architetture cloud ibride che colleghino multipli data center e servizi cloud. Questo e i relativi open standard abbasseranno il costo di migrazione a e da cloud pubici, portando gestioni automatizzati di capacità di picco, minimizzando outages e riducendo i costi. Un esempio di come OCCI permette di creare architetture cloud ibride è la dimostrazione della collaborazione di due dei maggiori progetti integrati di ricerca: SLA@SOI e RESERVOIR. Entrambi i progetti richiedono un modello dinamico di computing offerto da IaaS e entrambi hanno bisogno un modello per interagire con le risorse gestite da IaaS. 12

13 Scegliendo di implementare le specifiche OCCI, la collaborazione di entrambi i progetti fu significamene agevolata, permettendo l'interoperabilità di due differenti infrastrutture. L'importanza di questa facilità nelle inter operazioni. non può essere sottostimata, specialmente nel contesto di grandi progetti europei, dato le loro dimensioni. Utilizzando l'approccio REST, OCCI fornisce API composte di circa cinquanta comandi. Con un URL l'utente può identificare un specifico cloud provider e la specifica istanza di risorsa che deve essere controllata. Queste risorse possono essere computer, storage o network. 13

14 Ognuna di queste risorse ha associato degli attributi. Un insieme di risorse possono essere collegate fra di loro e gestite attraverso le tipiche operazioni start, stop, update e delete usando i comandi HTTP quali Get e Post. La community di OCCI lavora in un distribuito, open community con il supporto dell'open Grid Forum (OGF) usando una wiki e mainlling list per collaborare. La gestione del modello assicura diritti per ogni voce attraverso il gruppo di lavoro come un corpo aperto. Chiunque può assicura diritti per ogni voce attraverso il gruppo di lavoro OCCI con un open body. Chiunque può entrare liberamente e partecipare. Il processo open di OGF è comparabile con standard bodies come organizzazione sorella IETF e le complete specifiche con qualsiasi documento sono pubblicamente e liberamente disponibili in accordo con le leggi sulle proprietà intellettuali di OGF. Il gruppo di lavoro di OCCI aggiungerà contributi e assisterà gli sforzi di altri gruppi attraverso il processo. Avendo esaminato Api esistenti sviluppando requisiti attraverso la collezione di casi d'uso, il gruppo è stato in grado di produrre rapidamente una specifica tecnica implementabile. Guardando avanti ci sono continui lavori su numerosi implementazioni di occi. Alcune interessanti implementazioni includono: OpenNebula, parte della distribuzione Ubuntu SLA@SOI implementa un infrastruttura per l automatizzazione dei contratti per servizi cloud L Instituto Natiolate di Fisica Nucleare (INFN) sta usando OCCI per potenziare la sua infrastruttura computazionale on-demand. 14

15 2.2 I tre modelli di OCCI Lo standard OCCI è un protocollo i cui obiettivi di interoperabilità ed estendibilità hanno contribuito in maniera determinante nel suo processo di progettazione. Se si andrà ad analizzare l'architettura software scelta per il protocollo, si vedrà infatti che è un architettura modulare, basata su tre moduli centrali, ognuno con uno scopo specifico e che cooperano fra di loro. I moduli di OCCI sono i seguenti: Modello Centrale Il modello centrale impone un modo comune per gestire risorse generiche, provedendo semantiche per definire il tipo di una data entità, definendo le interdipendenze fra differenti entità e definendo caratteristiche operative su di loro. Modello Rendering RESTful HTTP Il modello centrale di OCCI è libero di ogni rendering e forma la base di OCCI. Basato su questo modello, OCCI descrive un rendering serializzato. Modello Infrastruttura Questo modello definisce l'estensione per l'infrastruttura di OCCI per il modello IaaS. All'interno del modello vengono definiti nuovi tipi di risorse, i loro attributi e le funzionalità che possono essere usate su ogni tipo di risorsa. 15

16 2.3 Modello Centrale OCCI Il modello centrale OCCI definisce un'astrazione delle risorse del mondo reale, presenti in un servizio cloud. L'astrazione è resa associando a ciascuna risorsa reale, un'istanza di una classe, definita all'interno del modello, che verrà poi manipolata attraverso un'implementazione rendering OCCI. Questa astrazione permette di attribuire ad ogni risorsa proprietà di identificazione, associazione ed estensione. All'interno del modello è inoltre definito un sistema di classificazione, che rende facile e sicuro l'esposizione del modello verso un protocollo text- o binary-based. Una fondamentale proprietà del modello centrale è quella di poter essere esteso in modo che qualsiasi estensione possa essere visibile e studiabile dal client OCCI a run-time. Il diagramma delle classi UML mostrato in figura da una vista generale al modello centrale OCCI. Deve però essere chiaro che il diagramma UML non è una completa definizione del modello. 16

17 Partendo dal diagramma delle classi, verranno ora presentate ciascuna classe del diagramma, dandone una descrizione generale, insieme alle relative specifiche. La classe Category è la base del meccanismo di identificazione usato dal sistema di classificazione di OCCI. Le istanze della classe Category sono solo usate per identificare le istanze della classe Action. Tutti gli altri usi dei suoi attributi sono gestiti attraverso le sue sotto classi Kind e Mixin. Un'istanza Category è identificata in modo unico dal concatenamento dello schema categorizzante con il termine category; per esempio Questo è fatto per abilitare la scoperta di definizione di Category in rendering basati sul testo come HTTP. Gli schemi categorizzanti definiti nella specifica OCCI devono tutti usare l'url di base La classe Kind è una specializzazione di Category e contiene al suo interno un istanza della classe Action. Le seguenti regole si applicano a tutte le istanze del tipo Kind. Un'unica istanza Kind deve essere assegnata a tutte le varie sotto classi di Entity, inclusi le stesse Entity. Un'istanza Kind deve esporre l'attributo name della sotto classe Entity che rappresenta. Un'istanza Kind deve esporre l'istanza Action definita per il suo sotto tipo Entity. Le istanze Action sono esposte attraverso gli attributi action di Kind. Le relazioni Kind sono definite attraverso i relatevi attributi presenti in ogni istanza Kind. Un'istanza Kind identifica un'unica classe Entity o sua sotto classe. Le relazioni Kind sono ricorsive, ogni istanza Kind deve essere relazionato all'istanza 17

18 Kind della classe parente. Le relazioni Kind rispecchiano la struttura ereditaria del modello centrale OCCI e di ogni sua estensione. Il tipo Action è un tipo astratto. Ogni sotto tipo di Action definisce un operazione applicabile a un'istanza di una sotto classe Entity. In generale, Action modifica lo stato, per esempio, eseguendo una complicata operazione come il reboot di una macchina virtuale. Un'istanza Action deve essere sempre associata a un'istanza Kind o Mixin attraverso un'associazione di composizione. Un'istanza Action può essere considerata come una funzionalità che l'istanza Kind o Mixin a cui è associata può eseguire. L'istanza Action può essere invocata su qualsiasi istanza di risorsa associata con l'istanza Kind o Mixing che la definisce. Alla classe Action è associato l'identificatore della classe Category: La classe Mixin completa la classe Kind nella definizione del sistema classificazione del modello centrale OCCI. La classe Mixin rappresenta un meccanismo di estensione, il quale permette di aggiungere nuove capacità alle istanze di risorse sia a tempo di creazione che a tempo di esecuzione. Un'istanza Mixin può essere associata con qualsiasi istanza di risorsa esistente e anche aggiungere nuove risorse capacità La classe Entity è una classe astratta, da cui ereditano le classe Resource e Link. Essendo una classe astratta, la classe Entity non può essere instanziata e le classi figle devono implementare i suoi metodi. Entity impone a tutti i suoi sotto tipi un attributo fondamentale occi.core.id e uno opzionale occi.core.title. Ad ogni sotto classe di Entity deve essere assegnata una istanza della classe Kind. Alla stessa Entity è assegnata l'istanza Kind per la sua stessa identificazione. L'istanza di ogni sotto classe di Entity dovrebbe essere associata ad uno o più istanze Mixin. 18

19 Al cuore del modello risiede la classe Resource. Ogni risorsa esposta attraverso OCCI è un'istanza della classe Resource o una sua sotto classe. Una risorsa può essere per esempio una virtual machin, un job in un sistema di smistamento di job, un utente, eccetera. La classe Risorsa contiene un numero di comuni attributi che le classi Resource domainspecific ereditano. La classe Resource è complementare alla classe Link, la quale associa un'istanza di Resource con le altre. La classe Link contiene inoltre un numero di comuni attributi che le classe Link domain-specific ereditano. 19

20 2.4 Modello Rendering HTTP OCCI Il modello centrale, descritto precedentemente, è libero di qualsiasi funzionalità di rendering e forma la base di OCCI. Basato su di esso, OCCI definisce un modello per il rendering serializzato. Il modello di rendering di default di OCCI è un rendering testuale ed usa il protocollo HTTP e implementa una a Resourse Oriented Architecture (ROA). L'architettura ROA usa il protocollo Representation State Transfer (Rest) per gestire le interazioni fra il client e il servizio; interazioni come l'ispezione e modificazione di un insieme di risorse relazionate fra loro e i loro stati. HTTP è un protocollo ideale da usare nei sistemi ROA dato che prevede sia un sistema per identificare in modo unico risorse individuali attraverso gli URL, sia la possibilità di eseguire semplici operazioni sulle risorse attraverso un insieme di metodi generali. Questi metodi HTTP implementano le operazioni relative alle risorse di Creazione (POST), Ricerca ( GET), Aggiornamento ( POST, PUT) e Cancellazione (DELETE). Ogni implementazione di OCCI deve, quindi, come minimo, supportare questi verbi. Ogni istanza di risorsa gestita in un'implementazione OCCI deve avere un unico identificatore memorizzato nell'attributo occi.core.id della classe Entity a cui fa riferimento. Ogni risorsa nel modello centrale OCCI sarà renderizzato come un univoco URI (per esempio ). Ogni risorsa può essere identificata in modo unico da un URI e ha almeno un istanza Category assegnata, che definisce il tipo e le operazioni che possono essere eseguite. Risorse dello stesso tipo ( ovvero che hanno la stessa istanza Category assegnata) possono essere trovate sotto un determinato percorso relativo al percorso root del provider del servizio ( per esempio tutti i dispositivi di storage apparariranno sotto il percorso /storage 20

21 sempre considerando che il nome del percorso storage è liberabemente definibile dal provider). Dato che Category può essere non solo usato per definire il tipo della risorsa, ma anche etichettare o raggruppare risorse, una risorsa può apparire su più di un percorso. La seguente URL /compute/123 /storage/discabc /database/tablexyz /nosql/entry_1 /my-linux-vms/123 // links to /compute/123 /my-datasets/discabc // links to /storage/discabc /my-datasets/tablexyz // links to /database/tablexyz /my-datasets/entry_1 // links to /nosql/entry_1 Questo sistema molto flessible permette al modello OCCI di poter essere usato per diversi casi d'uso. 21

22 2.5 Modello Infrastruttura OCCI Il modello Infrastruttura OCCI estende il modello centrale così che possa implementare Api per il modello architetturale Iaas. Queste Api permettono la creazione e la gestione di risorse tipiche di un servizio Iaas. Le principali classe definite all'interno del modello Infrastruttura sono : Compute: classe che rappresenta risorse associate a informazioni processate Network: classe che rappresenta una risorsa per l'interconnessione, ovvero una risorsa di networking di livello L2. Questa classe è completata da un Mixin IPNetwork. Storage: classe che rappresenta una risorsa che memorizza informazioni. A supportare queste classi di risorse vi sono le seguenti sotto classi della classe Link del modello centrale OCCI: NetworkInterface: connette un'istanza di Compute con una di Network. Questo è completato da un Mixin IPNewtorkInterface. StorageLink connette un'istanza Compute a una di Storage. 22

23 Ora si andranno ad analizzare più in dettaglio le classi elencante prima. La classe Network rappresenta un'entità di networking L2 ( per esempio uno switch virtuale). Può essere esteso usando il meccanismo di mixin ( o una sua sotto classe ) per supportare componenti di livello L3/L4 come TCP /IP. La classe Network eredità dalla classe basse Resource del modello centrale OCCI. Alla classe Network è assegnato l'istanza Kind infrastructure#network, Un'istanza Network deve La classe Storage rappresenta risorse che memorizzano informazioni in un dispositivo di memorizzazione dati, come per esempio hard disk. Storage eredita dalla classe base Resource del modello centrale OCCI. Alla classe Storage è assegnato l'istanza Kind In ordine di supportare risorse di livello L3/L4 (per esempio IP, TCP, ecc.) si definisce un mixin OCCI apposito, il mixin IPNetworking. La classe StorageLink rappresenta un collegamento fra un'istanza Resource a un'istanza Storage. Questo permette a un'istanza Storage di essere collegata a un'istanza Compute, con tuttie le operazioni richieste di basso livello gestite dall'implementazione OCCI. Storage eredita dalla classe base Link definita nel modello centrale OCCI. 23

24 Capitolo 3: Caso d uso Framework SLA@SOI Verrà ora presentato un caso d'uso in cui per la gestione di un framework SLA@SOI si farà uso del protocollo OCCI. In questo caso d'uso, ci sono due principali attori del caso d'uso. Il primo, e più improntante, è il gestore del servizio, l'entità che è responsabile per la realizzazione del servizio per il cliente. Rilevante per questo caso d'uso è che il gestore del servizio provvede servizi di database attraverso una preconfigurata virtual machine e che la localizione di queste virtual machine possono essere monitorate. Il framework SLA@SOI non fa nessun assunzione sul gestore del servizio, solo che ha un'interfaccia: La quale può creare, cercare, aggiornare e cancellare i servizi che gestisce Attraverso la quale le metriche per l'istanza del servizio possono essere elencate e ricercate. Il secondo attore è lo SLA Manager dello SLA@SOI framework. Questo è un'insieme di componenti sia generici che specifici, che gestiscono in modo automatizzato tutti i processi di intermediazione fra il cliente e i gestori dei servizi richiesti dal cliente. Una volta che lo SLA Manager è attivato dal client, per prima cosa esso negozierà con il gestore del servizio usando l'interfaccia query OCCI. L'interfaccia per le query di OCCI permette alle varie istanze di Resource di OCCI di essere ricercate per essere ispezionate e gestite, astraendo le risorse specifiche dei vari gestori dei servizi permettendo così allo SLA Manager di poter gestire più risorse differenti, appartenenti a gestori di servizi differenti. Usando questa estensione, inoltre, lo SLA Manager potrà verificare se la corrente richiesta del cliente potrà essere soddisfatta o no dal gestore del servizo. Una stabilito che la richiesta del cliente può essere soddisfatta dal servizio, il prossimo 24

25 passo potrà seguire due percorsi differenti. Il primo è che la richiesta per l'allocazione delle risorse per soddisfare le richiesta del servizio è fatta automaticamente o, il secondo, che la richiesta deve essere esplicitamente eseguita dal client. Dopo che la richiesta di allocazioni di risorse è stata eseguita in uno dei due modi, la seguente responsabilità dello SLA Manager sarà di chiamare le funzionalità richieste del gestore del servizio. Questo, ancora, è gestito attraverso le API di OCCI. Una richiesta OCCI dello SLA Manager è quindi inviata al gestore del servizio. Fino a quando la richiesta non è completata con successo, lo SLA Manager inizia comunque a monitorare il servizio richiesto, includendo la locazione della virtual machine del servizio. Per lo SLA Manager. il maggior vantaggio di scegliere di implementare OCCI come intermediario per interagire con il gestore del servizio è che, nel caso un determinato gestore non può soddisfare provvisoriamente la richiesta per il servizio di determinate risorse per insufficienza delle capacità o indisponibilità di macchine virtuali, lo SLA Manager può, con la necessaria logica implementata, andare a cercare il seguente provider di servizio registrato e richiedere di avere le rimanenti risorse di servizio, senza che alcun protocollo del gestore del servizio o Api cambi. 25

26 Conclusioni Il Cloud Computing è una tecnologia in continuo sviluppo. La sempre maggiore diffusione e fiducia che questa tecnologia sta avendo sia fra gli utenti, che le grandi compagnie informatiche, sta portando allo sviluppo di sempre più complessi servizi cloud e, di rimando, all aumento del numero dei provider di servizi cloud. In un futuro che si prospetta così eterogeneo, il bisogno di uno standard comune diviene sempre più una necessità obbligata. Così come accadde per Internet, anche per il Cloud Computing lo sviluppo di standard condivisi e aperti sarà l ulteriore passo per il suo affermarsi. Su questo percorso è nato OCCI. Riuscire ad essere un interfaccia fra diversi provider, anche se un obiettivo molto complesso da soddisfare appieno, è stata una sfida che OCCI ha raccolto ed è riuscito fino ad ora a rispettarla. Riuscendo a creare un astrazione delle varie risorse dei diversi servizi cloud, OCCI è riuscito a compiere il suo obiettivo, venendo ora usato da molteplici servizi cloud che raccolgono più provider all interno. Se diventerà davvero uno standard accettato da tutti, è ancora presto per dirlo. Di sicuro i grandi gruppo che ne appoggiano il progetto e lo sviluppo fanno ben sperare. Resta il fatto che sull Open Cloud ci sarà ancora tanto di che parlarne nei prossimi anni. 26