Piattaforme di cloud computing open source: la proposta OpenStack

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Piattaforme di cloud computing open source: la proposta OpenStack Anno Accademico 2011/2012 Candidato: DAVIDE RUSSO matr. N46/000005

2 Ai miei genitori, che mi hanno dato la possibilità di seguire la strada che ho scelto. Ai miei nonni, che hanno sempre creduto in me. Agli Amici, che in questi anni mi hanno accompagnato durante il percorso. Ad maiora!

3 Indice Introduzione 4 Capitolo 1. OpenStack Una definizione di Cloud Computing I servizi in OpenStack Folsom 9 Capitolo 2. Architettura e Componenti I Componenti Compute ( Nova ) Identity ( Keystone ) Block Storage ( Cinder ) Image Service ( Glance ) Dashboard ( Horizon ) Object Store ( Swift ) Network ( Quantum ) L Architettura Architettura concettuale Architettura logica 32 Capitolo 3. Utilizzo della piattaforma 34 Conclusioni e sviluppi futuri 39 Bibliografia 41 III

4 Introduzione Negli ultimi venti anni si è assistito ad una elevata crescita da parte di piccole, medie e grandi aziende nell'adozione di Tecnologie dell'informazione e della Comunicazione 1 a supporto del business, e delle attività aziendali che potessero trarre vantaggio, in termini di tempi e costi, da una infrastruttura informatica. Se è vero, comunque, che l'information Technology rappresenta oggigiorno un valore aggiunto imprescindibile per qualsiasi azienda, tuttavia la sua adozione introduce problematiche relative alla complessità della sua gestione legate, ad esempio, alla configurazione, installazione e manutenzione dei data centers, nonché della network aziendale, ed inoltre può portare (caso non infrequente) ad un uso inefficiente delle risorse acquisite: basti pensare, a tal proposito, all utilizzo non ottimale di un elevata potenza di calcolo o di una rete pensata per supportare una mole significativa di traffico, dovuto al fatto che tali disponibilità hardware e software risultano realmente sfruttate soltanto quando effettivamente utilizzate. Si è, quindi, optato per soluzioni in grado di garantire i benefici di una comune risorsa IT, ma attribuendo particolare importanza ai concetti di flessibilità e snellimento, mirati a ridurre sia i costi che i tempi necessari a rendere il tutto operativo, relativi alle attività di manutenzione, e puntando all efficienza nell utilizzo dell infrastruttura stessa. 1 ICT (Information and Communication Technology): spesso denominato anche IT, rappresenta l insieme di metodologie, criteri e risorse integrate di telecomunicazione e dei sistemi per il trattamento automatico dell informazione adattate e pensate per il supporto ad un target specifico (business aziendale, ambito formativo e didattico, enti pubblici). 4

5 In quest ottica si comprende intuitivamente come si sia naturalmente giunti all idea di ridurre la complessità di gestione semplicemente disinteressandosi dell effettivo apparato tecnologico richiesto, per focalizzarsi, invece, prettamente sulle funzionalità da esso erogate, introducendo quindi il concetto di servizio su richiesta. Nasce sulla base di tali considerazioni un nuovo modo di pensare all ICT, denominato Cloud Computing; e in particolare si delinea, in questo contesto, una nuova figura : il Cloud Provider. Il motivo che porta alla nascita di questo nuovo ruolo è l esigenza di separare la gestione dell infrastruttura (demandata, per l appunto, ad un provider), dal suo utilizzo e dalla possibilità di beneficiare dei suoi servizi (che rimane, invece, l interesse principale dell azienda o del privato che ne fa richiesta). L attenzione si sposta, a questo punto, sulla descrizione degli aspetti chiave del cloud computing e del providing, quindi sulle tipologie dei servizi offerti e sulle modalità di distribuzione. Si analizzerà nel dettaglio, nel corso dell elaborato, il progetto OpenStack, pensato come soluzione open source e community-maintained 2, distribuito come Infrastructure as a Service (IaaS). 2 Community-maintained: letteralmente mantenuto dalla comunità, spesso utilizzato per riferirsi ad un progetto al cui sviluppo si può liberamente partecipare, assistito ed affiancato da incontri e discussioni riguardo i suoi aspetti implementativi, le problematiche da affrontare e i progetti futuri, trattati in conferenze appositamente organizzate. 5

6 Capitolo 1 OpenStack Nello scenario dell emergente fenomeno del cloud computing, OpenStack si pone come una soluzione open source di tecnologie progettate per garantire un servizio di computing altamente scalabile. Il progetto nasce nel 2010 dalla collaborazione di Rackspace Cloud e NASA e risulta attualmente alla sua sesta release, denominata Folsom ( ). Una comunità, a cui hanno preso parte numerose organizzazioni, supporta il progetto partecipando attivamente allo sviluppo e promuovendone la distribuzione e l adozione negli ambienti dove il cloud rappresenta una valida alternativa al tradizionale metodo di gestione delle risorse IT. Per analizzare nel dettaglio l architettura e i servizi offerti da OpenStack può risultare utile definire preventivamente le peculiarità e gli aspetti che caratterizzano in modo generale un servizio di cloud, per descrivere poi come questi siano implementati nel particolare dalla nostra proposta d interesse. 1.1 Una definizione di Cloud Computing Nel paragrafo introduttivo si è osservato, in modo conciso, quali siano le motivazioni che hanno condotto all affermarsi del cloud computing. E lecito a questo punto chiedersi con quali criteri venga disciplinata l acquisizione o il rilascio di una risorsa cloud, ovvero come questa sia effettivamente distribuita. 6

7 Stando alla definizione del NIST (National Institute of Standards and Technology), il cloud computing è un modello atto a consentire, in modo conveniente e su richiesta, un accesso, tramite la rete, ad un pool condiviso di risorse di calcolo configurabili, e prevede cinque caratteristiche essenziali, tre modelli di servizio e quattro modalità di distribuzione. Per quanto riguarda le caratteristiche che ineccepibilmente deve mostrare un cloud inquadriamo i seguenti punti: On-demand self-service: ogni cliente deve poter far uso delle risorse a disposizione in modo del tutto autonomo e indipendente da eventuali interazioni col provider. Network access: la disponibilità delle risorse deve essere garantita attraverso la rete, e queste ultime accedute tramite meccanismi standard per garantire l eterogeneità client-side. Resource pooling: le risorse del provider sono messe a disposizione di più utenti contemporaneamente secondo il modello multi-tenant, con disponibilità fisiche e virtuali dinamicamente assegnate e rilasciate in base alle richieste. Rapid elasticity: il processo di acquisizione e rilascio di una risorsa deve essere rapido e non deve porre al consumatore particolari vincoli sul numero delle risorse acquisibili. Measured service: deve essere previsto un sistema per il controllo e il monitoraggio del servizio al fine di poterne ottimizzare la gestione. I modelli di servizio previsti in dipendenza dalle esigenze del cliente risultano invece: SaaS: Software as a Service. Le risorse messe a disposizione dal provider sono rappresentate da una collezione di applicativi software eseguiti su un infrastruttura cloud. A tali applicazioni il cliente può accedere tramite apposite interfacce e questo modello prevede che l utente non possa controllare il sistema operativo o la rete, ma soltanto impostare una serie limitata di opzioni sulla propria applicazione. 7

8 PaaS: Platform as a Service. Le risorse messe a disposizione dal provider sono rappresentate da una piattaforma per lo sviluppo e l esecuzione di applicazioni acquisite o create dal cliente, tramite linguaggi di programmazione, librerie e strumenti a supporto dello sviluppo software forniti dalla sottostante infrastruttura cloud. L utente non ha il controllo sul sistema operativo, sulla rete o sui servizi di storage. IaaS: Infrastructure as a Service. Le risorse messe a disposizione dal provider sono rappresentate da un infrastruttura pensata per garantire al cliente la possibilità di usufruire di servizi di storage, networking, sviluppare ed eseguire sia software di sistema che applicativo, senza particolari vincoli, nonché di gestire i componenti aggiuntivi di rete (es. firewall). Sulle modalità di distribuzione del cloud si distinguono quattro modelli: Private cloud: l infrastruttura viene fornita ad uso esclusivo di una singola organizzazione, quindi con possibilità di accesso ai servizi da essa erogata ai soli utenti che ne fanno parte. Public cloud: l infrastruttura viene fornita ad uso pubblico, di proprietà e gestione affidata a specifiche organizzazioni, come ad esempio compagnie di cloud services. Hybrid cloud: l infrastruttura prevede un tipo di accesso ibrido, può essere vista come l unione di un cloud privato e di uno pubblico ottenuta tramite meccanismi di integrazione standard o proprietari. Community cloud: l infrastruttura risulta condivisa tra diverse organizzazioni, rappresentanti di una comunità che lavora ad uno scopo comune. 8

9 1.2 I servizi in OpenStack Folsom OpenStack è un sistema operativo cloud sviluppato per garantire modalità di distribuzione sia pubbliche che private, tramite un insieme di progetti open source. Nell ultima release ( Folsom ), si possono identificare sette progetti principali, ottenendo così che negli ultimi due anni OpenStack ha visto una continua crescita sia nel numero dei componenti che della stessa comunità partecipante 3. I componenti previsti dall architettura di Folsom sono sviluppati secondo i criteri di flessibilità, scalabilità ed elasticità, ed in modo indipendente l uno dall altro, affidando la interazione tra di essi all utilizzo di apposite API. Questi sono denominati: Swift, Glance, Nova, Horizon, Keystone, Quantum e Cinder, e risultano funzionalmente divisi nei servizi di compute, networking e storage, acceduti eventualmente tramite una dashboard. Guardando ai soli servizi, dunque, e senza ancora scendere nel dettaglio della descrizione e dell interazione dei moduli, OpenStack Folsom può essere visto come un infrastruttura di cloud efficacemente descritta dalla seguente figura: 3 Nella prima release di OpenStack, denominata Austin ( ), comparivano due soli progetti ufficiali (Nova e Swift). Inoltre, ad oggi, risulta l adesione al progetto di oltre 6000 membri di 87 paesi, e centinaia di aziende, tra cui AMD, Intel, Cisco e IBM. 9

10 Dallo schema è possibile osservare come l utente possa interagire con i servizi di OpenStack tramite la dashboard, oppure in modo diretto utilizzando le API. Descriviamo le funzionalità di ognuno dei componenti elencati, tra i quali compaiono due nuovi progetti rispetto alla versione precedente 4, Quantum e Cinder, anche se è da precisare che nascono distinguendosi da funzionalità originariamente inglobate in Nova: Swift : (Object Store) E il sistema adibito all immagazzinamento e al recupero degli objects (files). Tra i servizi garantiti assumono particolare rilevanza i meccanismi di failover e ridondanza delle informazioni. Glance: (Image Service) Modulo introdotto con lo scopo di fornire un repository o catalogo delle immagini di macchina virtuale successivamente utilizzate nel servizio di Compute. Nova: (Compute) Fornisce gli strumenti per la gestione della nuvola, tra cui la creazione di istanze di server virtuali su richiesta e la configurazione di rete. Assieme a Swift costituisce uno dei componenti di maggiore importanza, e risulta di notevole complessità di implementazione. Horizon: (Dashboard) Rappresenta una interfaccia grafica (GUI) web-based sviluppata per usufruire, via browser, dei servizi del cloud. Tramite tale interfaccia è possibile effettuare la maggior parte delle comuni operazioni, come ad esempio lanciare un istanza di macchina virtuale e configurare i servizi di rete. Keystone: (Identity) Si occupa della gestione di utenti, risorse, servizi e delle operazioni di autenticazione di un utente ai servizi cloud. Quantum: (Network) Introdotto nella release Folsom, nasce con lo scopo di permettere ad un utente di configurare e creare una propria rete ( Network connectivity as a service ) alla quale collegare più dispositivi che utilizzino i servizi forniti da OpenStack (es. Nova). 4 La precedente release Essex è stata rilasciata il , con aggiornamenti a cadenza bimestrale fino al mese di ottobre. 10

11 Cinder: (Block Storage) Componente nato dal servizio di block storage originariamente integrato in Nova (nova-volume), come Quantum viene introdotto in Folsom. Prevede la gestione (creazione, assegnazione e rilascio), tramite dashboard o APIs, di volumi persistenti di storage, utilizzati nelle istanze di compute. La release OpenStack Folsom è stata sviluppata grazie all ausilio di oltre 330 partecipanti (un aumento del 65% rispetto ad Essex), e oltre ad introdurre i servizi di Networking e, individualmente, il Block Storage, migliora in termini di performance e semplicità di utilizzo quelli precedentemente offerti, tramite l introduzione di nuove funzionalità e l ottimizzazione di quelle preesistenti. Riportando alcuni esempi, tra le diverse modifiche apportate al progetto Nova si può citare config drive, introdotta con lo scopo di identificare e tener traccia dei metadati per descrivere la attuale configurazione di rete, e può risultare utile per aggirare, alla sessione successiva dell istanza, il DHCP per l ottenimento di un indirizzo IP. Per quanto riguarda Swift (Object Storage), Folsom prevede un meccanismo di connessione a server StatsD 5 per migliorare l attività di diagnostica e monitoraggio dei cluster, grazie allo scambio in tempo reale di informazioni sullo stato del sistema. Le novità, in particolare quelle relative al servizio di networking, sono state sviluppate facendo leva sulla estensibilità e sulla possibilità di integrare soluzioni proposte da terzi, grazie ad un architettura a plug-in: Quantum, infatti, prevede il supporto a progetti esterni, come il sistema operativo di rete open source Open vswitch, o l emergente framework Software Defined Networking (SDN). 5 StatsD è un applicazione (demone) eseguita con lo scopo di ricevere pacchetti UDP (restando in ascolto sul porto), estrarne il contenuto (metrics data, parametri ed indicatori di analisi statistiche come conteggi o timer), e riportare un grafico dei risultati periodicamente per garantire un basso overhead. 11

12 Capitolo 2 Architettura e componenti Come accennato nel primo capitolo, OpenStack è un infrastruttura che può essere logicamente e funzionalmente suddivisa in un insieme di servizi ed un insieme di componenti che cooperano e concorrono a formare un architettura altamente scalabile, flessibile, sicura e improntata all integrazione di progetti esterni, fornendo dunque la possibilità di personalizzare la piattaforma secondo le proprie esigenze e le proprie disponibilità. I principi fondamentali che stanno alla base dello sviluppo di OpenStack sono: un architettura service-oriented, per una suddivisione logica e concettuale delle entità software e hardware coinvolte, che prevede l interazione tra differenti moduli i sette progetti introdotti - a mezzo di apposite interfacce; minimizzare la dipendenza tra i processi, al fine di rendere il sistema nel complesso meno sensibile a guasti e malfunzionamenti, evitando l effetto valanga degli errori; prevedere meccanismi di diagnostica e monitoraggio, per ridurre la complessità nell intercettare gli errori; utilizzare protocolli di comunicazione standard per supportare l interazione con soluzioni sviluppate da terzi. Sarà analizzato, nel corso del secondo capitolo, il ruolo di ogni componente, e descritta dal punto di vista dei moduli l architettura di OpenStack. 12

13 2.1 I componenti Si è visto come OpenStack sia costituito da un insieme di progetti principali (Nova, Swift, Keystone, Horizon, Glance, Quantum e Cinder) che realizzano i servizi di Compute (Nova), Networking (Quantum) e Storage (Cinder e Swift), acceduti tramite una Dashboard (Horizon), che si basano sulle funzionalità condivise di Identity (Keystone) e di Image Management (Glance). Questi presentano singolarmente un ciclo di vita e un attività di sviluppo quasi del tutto individuale ed indipendente, e la OpenStack community li gestisce in termini di progettazione, documentazione e implementazione in maniera slegata tra loro, attribuendo, ad ognuno di essi, un vero e proprio ruolo di componente chiave per l architettura nel complesso. Di seguito saranno affrontati nel dettaglio i ruoli, i processi e le attività svolte dai progetti di cui sopra Compute ( Nova ) OpenStack Compute è il componente che fornisce gli strumenti utili alla gestione della infrastruttura, in termini di configurazione di rete, amministrazione delle istanze correnti di macchina virtuale e setting delle funzionalità di servizio e di controllo della piattaforma. Il progetto che implementa tale insieme di attività è denominato Nova e presenta analogie con l Elastic Compute Cloud (EC2) di Amazon Web Services. Compute è stato progettato per espletare un servizio a diverse tipologie di consumatori, ad ognuno dei quali, in generale, può essere assegnato un diverso ruolo, inteso come insieme di operazioni che lo specifico utente può eseguire. Nella configurazione di default l unico utente abilitato alla modifica dei permessi è l amministratore del sistema, accedendo al file policy.json, e apportando i dovuti cambiamenti al ruolo d interesse. 13

14 Da questo punto di vista sussiste l analogia con l EC2 di Amazon, ma Nova introduce la possibilità di gestire i tenants, blocchi di risorse associate a gruppi di utenti, proprietari di una VLAN, di istanze e volumi persistenti di storage condivisi tra gli utenti di uno stesso gruppo, ma in modo del tutto slegato dalle richieste degli altri tenants. La tecnologia di virtualizzazione adottata per motivi legati ai costi dell hardware e all inefficienza dovuta al sottoutilizzo dei server 6 - è alla base dei servizi offerti da Compute, ed in particolare, dovendo il servizio provvedere ad istanziare più sessioni di macchina virtuale su un unico server fisico, Nova trova nell hypervisor 7 l elemento chiave per la propria attività. Tra gli hypervisor supportati da Compute si citano Xen (progetto open source della Citrix), VMWare ESX e KVM (Kernel-based Virtual Machine). Un utente del servizio di OpenStack Compute, per accedere alle disponibilità di cui necessita, dovrà, in primis, selezionare un immagine (di macchina virtuale) come ambiente di lavoro. Un immagine è un modello che rappresenta lo stato di una macchina virtuale, ovvero che ne descrive il file system. Al concetto di immagine si associa naturalmente quello di istanza, come copia di un immagine dinamicamente allocata ed individuale. Per ogni utente che avrà selezionato una data immagine, dunque, sarà effettivamente presente la corrispondente istanza, le cui eventuali modifiche (apportate quindi al suo stato) non saranno visibili agli altri utenti, che continueranno invece a lavorare sulle proprie copie, in ambiente locale. 6 Per questioni di sicurezza e praticità, i server oltre a supportare un unico sistema operativo, prevedono l esecuzione di un unica applicazione, abbattendo la capacità di utilizzo dell intera rete di calcolo. 7 Hypervisor, noto anche come virtual machine manager, è il componente adibito alla creazione e al controllo di istanze multiple di macchine virtuali all interno di un unico sistema operativo ospitante, e che in maniera dinamica alloca le risorse richieste su un singolo server fisico. 14

15 Al momento del lancio di un istanza è richiesto di selezionare un insieme di risorse virtuali note come flavors, che rappresentano le esigenze del cliente in termini di CPU virtuali, RAM disponibile e quantità di spazio per l ephemeral storage 8. La selezione è prevista su un insieme di flavors di default o personalizzabili dagli amministratori del sistema. Il servizio di OpenStack Compute viene erogato tramite l interazione e la cooperazione di numerosi processi, tra i quali: nova-api, incaricato di intercettare e servire le chiamate alle API da parte di un utente. Risulta compatibile, oltre che con le API di OpenStack Compute, con le interfacce messe a disposizione dall EC2 (AWS). nova-compute, processo che comunica direttamente con l hypervisor installato sul server fisico per le operazioni di creazione e terminazione di un istanza. nova-schedule, schedula le richieste di creazione di un istanza di macchina virtuale valutando a quale server fisico richiederne l allocazione. nova-network, estrae dalla coda e manipola i processi di attività in rete secondo le politiche scelte dal proprietario della VLAN. Prevede che operazioni come il bridging o l instradamento possano essere gestite da soluzioni software esterne ad OpenStack, ed in Folsom le funzionalità del nova-network vengono inglobate in Quantum. OpenStack Compute prevede, per ogni istanza, l utilizzo di due tipologie di storage: Ephemeral Storage: associato ad una singola istanza, viene dimensionato e configurato al momento del lancio della stessa. I dati presenti al suo interno vengono persi all atto della cancellazione dell istanza, quindi un reboot del sistema operativo virtuale non provoca effetti di perdita delle informazioni. Solitamente i 8 L ephemeral storage è una risorsa di memorizzazione che estende il concetto di storage persistente, prevedendo similarità con quest ultimo, ma con una profonda differenza legata alla sua durata. Risulta, infatti, un vero e proprio servizio di memorizzazione fintantoché l istanza su cui lavora rimane attiva. Nel momento in cui questa viene cancellata, il servizio viene interrotto e le modifiche apportate (su directory o files modificati, creati e cancellati) perse. Si contrappone al persistent storage, il quale conserva i dati indipendentemente dal ciclo di vita delle istanze. Nova prevede entrambe le modalità di memorizzazione. 15

16 volumi di memorizzazione richiesti includono il root file system dell immagine, ma è possibile gestire un dispositivo di ephemeral storage aggiuntivo non formattato né partizionato, di capienza variabile (di default dai 20GB ai 160GB), alla cui inizializzazione provvederà l apposito meccanismo di riconoscimento e gestione previsto dal sistema operativo supportato dall istanza corrente (non è quindi un operazione gestita direttamente dal servizio di Compute). Volume Storage: indipendente dalla particolare istanza che lo utilizza, fornisce un servizio di memorizzazione persistente dei dati. Alla creazione di un volume storage, che non prevede limiti di spazio, è richiesto che il blocco venga collegato ad un istanza che dovrà provvedere alla sua formattazione e al partizionamento. In seguito alla fase di inizializzazione, si potrà utilizzare il blocco come un disco rigido esterno, collegabile, volta per volta, ad una sola istanza. I volumi persistenti di storage, infatti, non prevedono meccanismi per gli accessi concorrenti tra istanze multiple, per ottenere i quali bisogna rifarsi invece a file system appositamente sviluppati, come NFS, o file system utilizzati per i clusters (es. GlusterFS). E possibile configurare un blocco affinché realizzi un istanza permanente virtuale, facendo in modo che il volume di storage monti il root file system dell immagine d interesse. In questo modo sarà possibile comunque usufruire di blocchi di ephemeral storage, ma non potranno riferirsi al file system dell istanza, che sarà invece gestito dal blocco persistente. Il processo che gestisce l assegnazione e la creazione di volumi persistenti è nova-volume che in Folsom risulta integrato nel progetto Cinder. 16

17 2.1.2 Identity ( Keystone ) Keystone è il nome assegnato al progetto di OpenStack Identity Management, il quale assolve i compiti di gestione dell utente, per tenere traccia degli utenti del sistema e delle operazioni che questi possono compiere, e di gestione dei servizi disponibili, disciplinandone gli accessi tramite meccanismi di autenticazione utente basati su token. Per quanto riguarda la gestione utente (user management), Keystone si fonda su tre concetti portanti, già incontrati, ma che saranno ridefiniti con validità nell ambito dell Identity Service: User: rappresentazione digitale di una persona o di un sistema che utilizza i servizi di OpenStack. Tenant: collezione di risorse condivise (es. CPUs, RAM, storage) tra utenti di un medesimo gruppo, organizzazione o progetto. Role: ruolo che un utente assume in un preciso momento della sua attività che definisce il set di operazioni che questi può compiere e dei servizi che può richiedere. Ogni utente - caratterizzato da diverse informazioni, come username, password ed indirizzo - per richiedere un servizio all infrastruttura, deve specificare il tenant di appartenenza, al momento del login, posponendo il project_id 9 alle proprie credenziali di accesso. Il servizio di gestione utente erogato da Keystone associa ad ogni utente un tenant ed un ruolo, prevedendo la possibilità, all interno di uno stesso tenant, di assegnare molteplici ruoli ad un singolo utente o di fargli assumere differenti ruoli in differenti tenants. 9 Nelle precedenti release di OpenStack veniva adoperato il termine progetto anziché quello di tenant, e per mantenere la compatibilità con le terminologie già introdotte, anche in Folsom viene utilizzata la keyword project_id, dove ID rappresenta l identificativo del tenant a cui ci si vuole riferire. 17

18 La gestione dei servizi (service management) si fonda, invece, sui concetti di servizio, come disponibilità erogata dall infrastruttura di OpenStack che fornisce un meccanismo attraverso il quale un utente può accedere alle risorse di cui necessita (APIs), e di endpoint, ossia un indirizzo di rete (solitamente un URL) al quale riferirsi per accedere ad una particolare risorsa. Keystone provvederà, in tal senso, a fornire all utente del sistema un catalogo dei servizi disponibili e, alla richiesta di accesso ad un particolare servizio, il corrispondente endpoint. Il sistema Keystone è token-based, ossia utilizza come strumento per l assegnazione delle risorse un token, una stringa alfanumerica associata ad uno specifico utente. Al momento dell autenticazione di quest ultimo, quindi, il modulo di Identity Management provvederà a fornirgli un token che verrà utilizzato come chiave d accesso alle risorse di cui può disporre. L amministratore del sistema, dopo aver configurato Identity tramite il file keystone.conf, e averlo quindi reso operativo, potrà gestire utenti, ruoli, tenants e servizi del sistema, tramite le apposite procedure di creazione, modifica, cancellazione ed ulteriori comandi riportati di seguito. Nel dettaglio delle operazioni eseguibili sugli utenti si avrà: user-create, che avrà come argomenti il nome, la password, l indirizzo , il tenant originario (opzionale, di default al valore None) e l attributo enabled che indica se renderlo attivo o meno all interno del sistema (anch esso opzionale e settato di default a True). user-delete, comando che avrà come unico argomento il nome dell utente da cancellare. user-list, utilizzato per ottenere la lista degli utenti presenti nel sistema, e opzionalmente può essere specificato il tenant d interesse tramite l argomento tenant_id. 18

19 user-update- /user-update-password, comandi per l aggiornamento delle informazioni in cui bisogna specificare, oltre al nome dell utente, rispettivamente, il nuovo indirizzo e la nuova password. user-enabled/user-disabled per l abilitazione e la disabilitazione dell utente specificato nell argomento. La gestione dei ruoli prevede invece: role-create, comando per la creazione di un ruolo specificandone il nome come argomento. role-delete, comando per la cancellazione di un ruolo specificandone l id come argomento. role-list/role-get, utilizzati per la lista dei ruoli presenti o per ottenere le informazioni di un determinato ruolo. add-user-role/remove-user-role, per aggiungere o rimuovere un utente da un ruolo nel contesto di un particolare tenant (role_id, user_id, tenant_id). La gestione dei tenants prevede: tenant-create, specificandone il nome e opzionalmente la descrizione e l attributo enabled. tenant-delete, rimozione di un tenant immettendone l id come argomento. tenant-enable/tenant-disable, ancora una volta indicando nell argomento del comando l id del tenant d interesse. 19

20 E per finire, i servizi sono gestiti tramite i seguenti comandi: service-create, comando per la creazione di un servizio, specificandone il nome (es. Swift), il tipo (es. Image) e la descrizione. service-delete, permette tramite il service_id di rimuovere un servizio dal sistema. service-list/service-get, restituisce la lista dei servizi o le informazioni del servizio il cui id viene specificato nella get Block Storage ( Cinder ) Il servizio OpenStack Block Storage, come già specificato nel capitolo precedente, è fornito e sviluppato come componente indipendente soltanto a partire da Folsom, mentre originariamente era garantito dal processo nova-volume di OpenStack Compute. In Folsom, dunque, per motivi di compatibilità con le precedenti release, risulta la coesistenza di due processi equivalenti, ma dalla prossima release ( Grizzly, ) nova-volume verrà completamente rimosso da Nova, per lasciare il posto al nuovo componente di block storage, il quale ne ingloberà tutta la logica di gestione. Il progetto, denominato Cinder, provvede alla gestione di volumi persistenti di storage per le istanze di macchina virtuale, tramite un processo (il cinder-api) che accetta le richieste di storage e le inoltra al cinder-volume, task adibito alla comunicazione diretta con un database per compiere la specifica operazione di lettura o scrittura. Uno scheduler (cinder-scheduler), che agisce su una coda delle richieste di allocazione di un volume storage, provvede a determinare su quale nodo creare il nuovo blocco richiesto, affinché si migliori l efficienza nella distribuzione degli accessi bilanciando il carico. 20

21 La seguente immagine mostra uno schema rappresentativo della struttura di Cinder: Nel caso d uso di allocazione di un volume persistente di storage, dunque, il processo cinder-api riceverà la richiesta dal client. Tramite l utilizzo dell Advanced Message Queuing Protocol (AMQP, adoperato nelle architetture message-oriented), il cinder-api comunicherà al cinder-scheduler di operare, in modo tale da valutare dinamicamente il nodo migliore sul quale allocare la risorsa. Sarà, infine, compito del cinder-volume servire la richiesta occupandosi dell interazione con un database sql e provvedendo all esecuzione dell azione richiesta (in questo caso la scrittura) tramite l Internet Small Computer Systems Interface (iscsi, alias Internet SCSI), un protocollo per l invio di comandi su rete a dispositivi remoti di storage. Cinder risulta composto dai tre servizi principali sopra descritti, da un database (Cinder DB) e da una coda di richieste. Cinder, inoltre, prevede la possibilità di comunicare con differenti dispositivi di storage, e nasce in effetti anche per fornire un livello di astrazione tale da separare le richieste dal particolare supporto di memorizzazione. 21

22 Piattaforme di cloud computing open source: la proposta OpenStack E attualmente compatibile con sistemi IBM come Storwize V7000 e XIV Storage System, e con tecnologie di storage di SolidFire, NetApp, SheepDog ed altri Image Service ( Glance ) OpenStack Image Service, il cui progetto prende il nome di Glance, è il componente progettato per fornire agli utenti della piattaforma OpenStack i servizi di creazione, ricerca e aggiornamento di un immagine all interno del sistema. L immagine rappresenta un modello di macchina virtuale, inteso come insieme di dati e metadati utili a descriverne lo stato, al quale più utenti possono accedere procedendo, per ognuno di essi, alla creazione e all allocazione della rispettiva istanza. Risulta, quindi, il componente adibito a fornire all utente della piattaforma un catalogo delle immagini disponibili, e nei comuni scenari di utilizzo della piattaforma si pone come strato intermedio tra il Compute - che gestisce le attività all interno della nuvola, e comunica (tramite scambio di messaggi) con gli altri componenti di OpenStack per servire l operazione richiesta e l Object Storage, utilizzato per il salvataggio ed il retrieving degli stessi objetcs (files) dell immagine. Da ricordare, comunque, che l Image Service può essere acceduto direttamente dall utente tramite le APIs, e non necessariamente tramite il Compute. Glance prevede un insieme di meccanismi di accesso compatibili con differenti sistemi back-end per lo storage delle immagini. Infatti, oltre all OpenStack Object Storage (Swift), gli store di back-end ai quali l Image Service è in grado di interfacciarsi sono il sistema di storage proprio di Amazon Web Services (AWS) denominato S3, la memorizzazione su file system, che risulta lo store predefinito nella configurazione di default, ed inoltre tramite APIs progettate secondo un architettura di tipo REST 10, Glance garantisce operazioni di ricerca delle immagini, quindi a sola lettura, tramite il protocollo HTTP. 10 REST (Representational State Transfer) rappresenta un insieme di principi per la progettazione di architetture pensate per sistemi distribuiti ipertesto, che si basa sull accessibilità via WEB di ogni risorsa richiesta e sulla comunicazione tramite interfacce standard (es. HTTP) di una sua rappresentazione. 22

23 La struttura interna di Glance si può immaginare come suggerito dalla figura di seguito: Glance risulta costituito fondamentalmente da tre servizi: Glance API server, task che accetta le richieste di lettura o scrittura di immagini e opera come canale di comunicazione tra i client, il server di storage delle immagini e quello dei metadati. Store Adapter, servizio che slega la richiesta dal particolare store. Fondamentale per permettere a Glance di interagire con differenti sistemi di back-end, inglobando e facendosi carico della traduzione della richiesta utente nella comunicazione diretta con lo specifico store. Registry Server, servizio per il trattamento dei metadati di un immagine. E responsabile delle operazioni di gestione quali salvataggio, modifica e ricerca di informazioni sullo stato dell immagine, come type, size, data di creazione, etc, all interno di un database SQL. 23

24 Inoltre Glance supporta il caching delle informazioni, dunque oltre alle macro-attività descritte, prevede meccanismi e funzionalità per la replicazione, controlli di consistenza e aggiornamento dei dati Dashboard ( Horizon ) Horizon è il nome attribuito al progetto di OpenStack Dashboard. Nella versione iniziale la Dashboard prevedeva il supporto al solo Compute, ma col tempo, grazie soprattutto ad una crescita nelle partecipazioni allo sviluppo, è stato pensato ed implementato il supporto agli altri componenti di OpenStack (Object Storage, Network, etc.) con l aggiunta, quindi, di nuove APIs e ulteriori strumenti per lo scambio di informazioni. Horizon è una applicazione web sviluppata su Django, un framework Python open source, con un architettura ispirata al pattern Model-View-Controller (MVC), per scindere la business logic dal livello di presentazione, come spesso accade nell implementazione delle interfacce grafiche. Alla base dello sviluppo di Horizon si possono individuare diversi punti chiave, tra cui: il supporto esteso a tutti i componenti OpenStack, reso possibile grazie a tre tipologie di dashboards (User dashboard, System dashboard e Settings dashboard) che coprono l interazione con tutti i componenti dell infrastruttura - Horizon implementa, a questo proposito, un insieme di APIs pensate per garantire al programmatore un punto di riferimento per la comunicazione con l intera infrastruttura, comunicando effettivamente col solo componente di Dashboard e non richiedendo al programmatore stesso la conoscenza dei singoli componenti e della loro struttura interna. possibilità di espandere le funzionalità integrando nella dashboard principale differenti sotto-componenti, ognuno dei quali adibito ad un preciso compito, come ad esempio prevedere la possibilità di inserimento di un pannello per una attività di monitoraggio. 24

25 progettare l interfaccia in modo user-friendly, quindi presupponendo sia una facilità ed intuitività nel suo utilizzo, sia un aspetto, dal punto di vista grafico, che ne incentivi l utilizzo. un sistema granulare con moduli il cui codice è scritto in modo da renderlo facilmente leggibile e manutenibile. progettare le interfacce tenendo in considerazione i problemi legati all inconsistenza delle informazioni. Horizon, quindi, rappresenta il punto d incontro di tutti i componenti OpenStack, e nasce per semplificare il lavoro di gestione ed utilizzo dell infrastruttura cloud sia all utente che all amministratore del sistema Object Store ( Swift ) L OpenStack Object Store, il cui progetto prende il nome di Swift, rappresenta uno dei componenti principali della piattaforma, che assieme al Compute compare fin dalla prima release (OpenStack Austin). Ha subìto nel corso degli ultimi anni continui miglioramenti ed ha visto diverse rivisitazioni al progetto originale, mirate a garantire un servizio sempre più sicuro ed affidabile. Swift è il componente di OpenStack su cui si basa l intera piattaforma per lo storage degli oggetti: si consideri infatti che tali oggetti (objects) non solo costituiscono parte dei files utilizzati all interno di un ambiente di lavoro (ossia di un istanza), ma rappresentano anche l istanza stessa, intendendo con essa i files di sistema, di configurazione e i metadati utili a descriverne lo stato. L architettura di Swift è altamente distribuita per evitare i problemi di inconsistenza, malfunzionamenti e inagibilità del servizio nel caso di problemi ai server - che altrimenti sarebbero centralizzati - in una data zona. Prevede, quindi, un insieme di meccanismi per 25

26 la replicazione e la ridondanza delle informazioni. In particolare, OpenStack Object Store risulta costituito da un Proxy Server che intercetta le chiamate alle API o la richiesta di servizio tramite protocollo HTTP e sarà il componente che direttamente riceverà l oggetto da caricare, da un Object Server adibito alla gestione degli oggetti sui nodi di storage, da un Container Server il quale implementa il concetto di appartenenza di un gruppo di files ad uno specifico contenitore e provvederà quindi alla gestione di tali associazioni, ed infine da un Account Server che si occupa degli account definiti all interno del servizio. Si può schematizzare l architettura di Swift come segue: Proxy Server: componente adibito alla comunicazione sia tra i diversi server che con l utente stesso, responsabile di intercettare una richiesta, trovare la locazione fisica di account, container e object servers interessati - tramite una particolare associazione denominata Ring - e inoltrarla, nonché di gestire eventuali errori dovuti ad un fail del metodo invocato (es. gestire il codice di errore di ritorno di una PUT). Inoltre le APIs disponibili per Swift prevedono una comunicazione diretta soltanto col Proxy Server, al 26

27 quale saranno inviati gli stessi objects da o per l object server, a seconda che l operazione sia in lettura o scrittura. Object Server: rappresenta il componente che si occupa di eseguire la specifica operazione richiesta sul file, ad esempio il retrieving, la modifica o la cancellazione sul dispositivo locale di storage. Ogni oggetto è memorizzato in base ad un path ottenuto tramite una funzione hash applicata al nome e al timestamp (quindi una eventuale modifica genererà un path differente), e viene trattato come un file binario con i metadati specificati negli attributi estesi del file, e una volta cancellato è demarcato dall estensione.ts (tombstone). Container Server: si occupa di gestire liste di oggetti, non conoscendo la dislocazione fisica di ognuno di essi, ma sapendo soltanto quali oggetti appartengano ad uno specifico contenitore, salvando tali informazioni all interno di un database sql. Account Server: simile, per finalità, al container server, con la differenza che si occupa di gestire gli account definiti all interno del servizio di object storage. Vi è, inoltre, un insieme di processi eseguiti su ogni nodo con lo scopo di replicare le informazioni e mantenerle consistenti, in cui ogni processo controlla i dati locali confrontandoli con quelli di ogni altro nodo per verificare che siano aggiornati o eventualmente siano stati cancellati, processi eseguiti per bufferizzare le operazioni di update o scrittura non riuscite (per carico eccessivo, o malfunzionamenti) e processi per controllare l integrità dei dati. 27

28 2.1.7 Network ( Quantum ) Il progetto Quantum definisce il componente che in OpenStack provvede a fornire «network connectivity as a service» ai dispositivi collegati alla piattaforma. Quantum viene introdotto nella release Folsom e ingloba le attività del processo nova-network, estendendone le funzionalità e scindendo, quindi, la logica di gestione delle attività di rete dal componente di Compute. L obiettivo di Quantum è quello di permettere ad un utente di creare e configurare una propria (o più di una) rete a cui collegare i dispositivi che utilizzano i servizi di OpenStack, offrendo la possibilità di personalizzarla sfruttando soluzioni esterne alla piattaforma stessa. L architettura di Quantum, infatti, è a plug-in, ossia progettata per integrare un numero e una tipologia di meccanismi non prestabiliti per configurare le attività di rete, lasciando piena libertà all amministratore ad esempio sul bridging, sull instradamento e sulla gestione di componenti aggiuntivi quali firewalls, a seconda del tipo di plug-in utilizzato. La struttura di Quantum può essere descritta tramite la seguente figura: 28

29 Distinguiamo differenti componenti: Quantum server: è il processo principale, un demone Python incaricato di fornire le APIs ed intercettarne le relative chiamate, inoltrandole allo specifico plugin. Quantum agents e plugin: i più comuni sono i plugin-agent, dipendenti dal vendor e dalle particolari tecnologie disponibili, il dhcp-agent che fornisce un servizio DHCP alle reti dei tenant ed L3-agent incaricato dell instradamento per fornire accesso alla rete fisica esterna. Queue e database: una coda di messaggi è utilizzata in molte configurazioni di Quantum e permette al quantum-server di comunicare con i diversi agents, inoltre i plugins utilizzano un database per salvare lo stato della rete e la configurazione. Il servizio di OpenStack Networking fornisce le astrazioni di rete, sottorete e porti, e permette ad ogni tenant di poter gestire più sottoreti e i relativi blocchi di indirizzi IP indipendentemente dalle richieste degli altri tenants. In quest ottica, un plugin di Quantum è una specifica implementazione delle network APIs di OpenStack. Tra i plugin attualmente utilizzati in Quantum ricordiamo Open vswitch, Cisco, Linux Bridge, Nicira NVP, Ryu, NEC OpenFlow. Il progetto Quantum, quindi, nasce separandosi dal processo nova-network per permettere agli utenti del sistema di avere una maggiore libertà e rendere più elastici sia il lavoro di configurazione che il controllo sulle attività di rete. 29

30 2.2 L Architettura OpenStack prevede l interazione di moduli software progettati per fornire uno o più servizi a qualunque componente ne faccia richiesta, tramite le apposite interfacce o protocolli standard, secondo i criteri e le metodologie proprie di un architettura orientata ai servizi. Ognuno di essi incapsula un insieme di funzionalità, congruentemente con quanto descritto nel paragrafo precedente, realizzate in modo tale da gestire efficientemente le richieste e garantire l espletamento del servizio anche in presenza di un elevato numero di nodi connessi. Nel dettaglio di quali e quante interazioni avvengano all interno di uno scenario comune di utilizzo dell infrastruttura si può operare una suddivisione nel descrivere l architettura di OpenStack, mirata a carpirne l interoperabilità e le dipendenze prima dal punto di vista dei componenti (architettura concettuale), poi dal punto di vista dei processi e delle specifiche attività di ognuno di essi (architettura logica). 30

31 2.2.1 Architettura concettuale Per una descrizione concettuale dell architettura di OpenStack bisogna rifarsi al tipo di servizi che un singolo modulo (Compute, Identity, Network, etc.) richiede per poter eseguire la propria attività. In questo senso possiamo rifarci alla seguente figura: Osserviamo che, in accordo a quanto già descritto nelle funzionalità dei moduli: Compute prevede alla gestione (ricerca, creazione e aggiornamento) delle immagini di macchina virtuale facendo uso dei servizi messi a disposizione dall Image Service. Network comunica col Compute per fornire gli strumenti utili alla creazione e configurazione di una rete virtuale. Il Block Storage viene utilizzato dal Compute per la gestione dei volumi di storage e l interfacciamento al particolare supporto di memorizzazione. L Image Service utilizza lo stesso Object Storage per la memorizzazione dei files di configurazione di un immagine di macchina virtuale. La Dashboard utilizza le APIs proprie dei singoli componenti per fornire un interfaccia grafica, sia per un utente che per un amministratore del sistema (può sfruttare, a seconda dei casi, differenti APIs). 31

32 Tutti i componenti si basano sul servizio di autenticazione dell Identity Service. E importante notare comunque che, in quanto modello concettuale, una tale rappresentazione fornisce uno schema semplificato, che non tiene conto delle singole attività o di un particolare servizio richiesto, ma sufficientemente utile ed efficace per dare un idea di quali siano le dipendenze e delle comunicazioni tra moduli necessarie a gestire il cloud Architettura logica Uno schema di architettura più dettagliato che, oltre a mostrare i ruoli dei processi, metta in relazione l infrastruttura di OpenStack sia con l utente finale che con le particolari scelte tecnologiche a supporto del servizio di cloud (hypervisors, storage devices, plug-in, etc.) è rappresentato dall architettura logica mostrata in figura: 32

33 Si nota da subito un insieme di collegamenti più fitto e articolato rispetto allo schema concettuale, che risulta utile a comprendere in che modo la singola attività fornisca un servizio al componente cui essa afferisce. Si può osservare, infatti, il canale di comunicazione HTTP tra lo swift-proxy e l utente finale, in accordo con la modalità di retrieving a sola lettura degli oggetti previsto dall Object Storage, il supporto del processo nova-api alle interfacce EC2, per integrare nativamente il servizio di AWS nell infrastrutura OpenStack, o la comunicazione con uno specifico hypervisor demandata al nova-compute. L architettura logica considera quindi l interazione tra i processi di ogni componente di OpenStack e mostra come le dipendenze siano distribuite non più a livello di moduli, ma di attività (processi). 33

34 Capitolo 3 Utilizzo della piattaforma Per utilizzare l infrastruttura di cloud computing offerta da OpenStack è possibile, in ambiente Linux (Ubuntu 12.04), scaricare ed eseguire una serie di script (DevStack) adibiti al download dei package, alla loro installazione e alla configurazione sulla macchina. In questo modo è possibile installare i componenti di OpenStack (Compute, Networking, Storage, Identity) e configurarli in modo tale da riuscire a garantire un corretto funzionamento server-side. La comunità che contribuisce allo sviluppo di OpenStack inoltre rende possibile a qualsiasi utente provare la piattaforma, mettendo a disposizione un insieme di server di capacità ridotte e pensati per garantire un utilizzo minimale della stessa. In particolare, sarà possibile scegliere i flavor dell ambiente di lavoro, al momento del lancio di un istanza, da un insieme limitato di possibili opzioni, se non è addirittura prevista un unica scelta. Le limitazioni imposte, riguardano, inoltre, la capacità dei volume storage, la durata della loro stessa persistenza, e dunque delle modifiche apportate a specifici files od objects, ed in generale con differenze sul tipo di vincoli a seconda delle disponibilità. Per provare la piattaforma, infatti, si può far riferimento al progetto TryStack appositamente pensato, che sfruttando macchine server con architetture ARM e x86 sulle quali è installata e configurata la release Essex, quindi la penultima versione, permette di avere accesso, tramite il componente di Dashboard Horizon, alle funzionalità più comuni, quali, ad esempio, il lancio di un istanza o la creazione di un volume di storage. 34

35 Sfruttando la versione di OpenStack messa a disposizione dal progetto TryStack, verrà di seguito riportata una descrizione dei servizi offerti, mirata a mostrare come si presenti Horizon. Sarà presa in considerazione la piattaforma su un architettura ARM. Alla pagina di accesso alla piattaforma, disponibile all URL: quello che vedremo sarà il pannello di login riportato in figura: E possibile ottenere le credenziali di accesso seguendo una semplice procedura di iscrizione ed attendendo la convalida e l accettazione della richiesta tramite una di risposta contenente lo User Name e la Password generati. 35

36 Una volta effettuata l operazione di login, avremo accesso all effettivo pannello di dashboard che permette la gestione della nuvola. Si potrà osservare, sulla sinistra, la colonna contenente il quadro delle attività di Manage Compute contenente Overview, Instances & Volumes, Images & Snapshots, Access & Security. Ritroveremo come pagina iniziale il pannello di Overview che fornisce la possibilità di supervisionare le istanze correnti, e per ognuna di esse il numero di CPUs virtuali, la capacità del volume storage e il tempo di attività. E possibile, inoltre, selezionare mese ed anno per osservarne l utilizzo ed eventualmente scaricare un resoconto (Download CSV Summary) tramite il file usage.csv. Nella schermata corrente, non avendo ancora creato ed avviato un istanza, il pannello di overview risulta quindi vuoto. 36

37 Andiamo adesso ad occuparci di creare e lanciare un istanza, partendo dalle immagini di macchina virtuali disponibili sui server andando alla voce Images & Snapshots. Qui troveremo l insieme delle immagini a disposizione, gli snapshots effettuati su un istanza e quelli di volume: Vediamo che è disponibile una sola immagine di macchina virtuale (Ubuntu 12.04), il cui stato è attivo ed essendo pubblica è selezionabile per lanciarne un istanza. Tramite la funzionalità Launch, la dashboard comunicherà al componente di compute, configurato sul server su cui è installata la piattaforma, di allocare una nuova istanza, la quale sarà quindi successivamente accessibile alla voce Instances & Volumes, e visibile nel pannello di overview. 37

38 Lanciando una nuova istanza bisognerà inserire un nome per identificarla, una descrizione e scegliere un flavor, ma nel nostro caso c è una sola opzione, dunque è una scelta obbligatoria comprendente 4 vcpus, 150GB come capacità del disco rigido e 3584MB di RAM. Dopo una breve attesa dovuta alla creazione e allocazione dell istanza, e assegnazione di un indirizzo IP, saremo automaticamente portati alla voce Instances & Volumes per la consultazione dello stato dell istanza appena creata e la possibilità di eseguire una molteplicità di operazioni su di essa, come l interruzione, la sospensione, il riavvio, la terminazione, effettuarne una snapshot etc. Sarà possibile, allo stesso modo, creare un volume aggiuntivo di storage, specificandone il nome, una descrizione e la capacità desiderata. Nell ultima voce Access & Security si potrà allocare un insieme di IP per il progetto (ossia l attività) corrente, creare keypairs utilizzate nella crittografia RSA e gestire Security Groups. 38

39 Conclusioni e sviluppi futuri La piattaforma OpenStack nasce come servizio di cloud computing che, secondo metodologie e criteri progettati e realizzati da esperti in diversi campi afferenti al settore dell Informazione (sistemi informativi, reti di calcolatori, programmazione, architettura di sistemi distribuiti, sviluppo software), grazie al fatto di essere un progetto sostenuto da una comunità alla quale partecipano numerose aziende note nei diversi settori, riesce a garantire un insieme di caratteristiche, quali la sicurezza, l affidabilità e la scalabilità ad un livello tale da rendere l intera infrastruttura un punto di incontro per differenti problematiche legate alla gestione delle risorse IT e portandola a rappresentare una soluzione valida per qualsiasi azienda abbia la necessità di investire in un servizio di cloud. La sua natura di progetto open-source, inoltre, ne facilita il supporto tecnico, la reperibilità di documentazione ed in generale la risoluzione di uno specifico problema, dando la possibilità ad ogni utente e amministratore del sistema di poter usufruire di numerosi blog, archivi di articoli tecnici, forum, newsletter e punti di discussione anche non ufficiali, che naturalmente sorgono e si diffondono qualora vi sia la trasparenza di un prodotto opensource. La comunità che partecipa attivamente allo sviluppo della piattaforma è in costante aumento, ed OpenStack risulta già ampiamente utilizzato in aziende del calibro di Rackspace Cloud ed Hewlett-Packard (HP Cloud Services). 39

40 Il successo nelle adozioni da parte di piccole e grandi aziende è dovuto dunque anche all essere un progetto completamente accessibile, in continua crescita e il cui sviluppo è focalizzato sulle problematiche maggiormente poste in evidenza nei meeting organizzati dalla comunità. In quest ottica, OpenStack viene incontro alle esigenze più comuni di un servizio di cloud providing, ad esempio ampliando l insieme di back-end di storage, o supportando un numero sempre maggiore di plugins, hypervisors, e ulteriori tecnologie a supporto del progetto, per rendere la piattaforma adattabile a differenti scenari e disponibilità hardware e software. Il progetto OpenStack è giunto attualmente alla sua sesta release, e la settima, denominata Grizzly, è prevista per aprile Grizzly prevede l introduzione di due progetti emergenti: un componente adibito al monitoraggio dell intera nuvola (il cui progetto prende, per l appunto, il nome di Ceilometer) per la convergenza in un unico modulo di tutti i dati ottenuti da misurazioni e statistiche sull utilizzo della piattaforma, ed un progetto denominato Heat di cloud orchestration, nato per fornire un implementazione di OpenStack basata sul modello di AWS CloudFormation. 40

41 Bibliografia [1] [2] OpenStack Compute: Administration Manual, 18/12/2012. [3] [4] [5] [6] [7] [8] [9] 41