Università degli Studi di Napoli Federico II

Università degli Studi di Napoli Federico II Scuola Politecnica e delle Scienze di Base Area Didattica Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi sperimentale di Laurea Triennale Sviluppo di un Sistema di Cloud Computing Federato con supporto per la contestualizzazione Relatori Candidato Prof. Guido Russo Davide Michelino Dr. Silvio Pardi matr. 566/2723 Anno Accademico 2012-2013

Indice generale 1 Introduzione...8 2 Virtualizzazione...11 2.1 Cenni storici...11 2.2 Le tecnologie di virtualizzazione...12 2.2.1 KVM...14 3 Il Cloud Computing...15 3.1 I modelli implementativi...16 3.2 I modelli di servizio...18 3.2.1 Il paradigma IaaS...18 3.2.2 La virtualizzazione della piattaforma PaaS...20 3.2.3 Il concetto di Software as a Service SaaS...20 3.3 Lo Storage nel modello IaaS...21 3.3.1 L'object storage...21 3.3.2 Il block storage...22 3.3.3 Il File storage...22 4 OpenStack...23 4.1 OpenStack Compute (Nova)...24 4.2 OpenStack Object Storage (Swift)...25 4.3 OpenStack Image Service (Glance)...27 4.4 OpenStack Identity (Keystone)...28 4.5 OpenStack Networking (Nova-network)...30 4.6 OpenStack Block Storage (Nova-volume)...32 Davide Michelino 566/2723 Pagina 2 di 108

4.7 OpenStack Dashboard (Horizon)...33 5 Le Cloud Federate...35 6 Il Problema della Contestualizzazione...37 7 Implementazione di una strategia di contestualizzazione nelle cloud Federate...39 7.1 L'ambiente di lavoro...39 7.2 Implementazione di OpenStack...42 7.2.1 Advanced Messaging Queuing protocol...43 7.2.2 Il Keystone e le utenze...47 7.2.3 Il Networking...48 7.3 Interfacce OCCI...50 7.4 Integrazione dell'infrastruttura IaaS nel sistema federato tramite KeyStone voms compatibile...51 7.5 Design di una strategia di contestualizzazione tramite cloud-init...52 7.5.1 La sintassi di cloud-config...53 8 Testing...54 8.1 Observium...54 8.1.1 Preparazione dell'immagine...55 8.1.2 Configurazione di Observium...58 8.2 Il caso d'uso di contestualizzazione di Observium...58 9 Appendice...60 9.1 Configurazioni Nova...60 9.1.1 Nova.conf (nova-controller01)...60 9.1.2 nova-conf (cloud-computexx)...63 9.1.3 api-paste.conf (cloud-controller01)...65 Davide Michelino 566/2723 Pagina 3 di 108

9.1.4 dns-masq.conf (nova-controller01)...71 9.1.5 policy.json (nova-controller01)...71 9.2 Configurazione Glance...75 9.2.1 glance-api.conf (nova-controller01)...75 9.2.2 glance-cache.conf...87 9.2.3 glance-api-paste.ini (cloud-controller01)...90 9.2.4 glance-registry.conf (cloud-controller01)...93 9.2.5 glance-registry-paste.ini (cloud-controller01)...96 9.2.6 policy.json (cloud-controller01)...96 9.3 Configurazione Keystone...97 9.3.1 default_catalog.templates (cloud-controller01)...97 9.3.2 keystone.conf (cloud-controller01)...98 9.3.3 policy.json (cloud-controller01)...101 9.4 Horizon...102 9.4.1 local_settings (cloud-controller01)...102 9.5 nova-volume...105 9.5.1 targets.conf (cloud-volume01)...105 9.6 Keystone federato (supporto VOMS)...106 9.6.1 httpd-keystone-voms.conf (apache)...106 Bibliografia Link...108 Davide Michelino 566/2723 Pagina 4 di 108

Indice delle illustrazioni Illustrazione 1: Full Virtualization Hypervisors...11 Illustrazione 2: Cloud Computing...14 Illustrazione 3: Modelli Implementativi...15 Illustrazione 4: Lo Storage nel modello IaaS...20 Illustrazione 5: Schema concettuale di OpenStack...24 Illustrazione 6: OpenStack Object Storage...25 Illustrazione 7: Architettura di Swift...26 Illustrazione 8: Uno scenario di utenza multi-tenant...28 Illustrazione 9: Autenticazione sul Keystone utilizzando una coppia usernamepassword...30 Illustrazione 10: Un'implementazione di nova-network (FlatDHCPManager)...31 Illustrazione 11: Un'implementazione di nova-network (VlanManager multi-tenant)...32 Illustrazione 12: OpenStack Dashboard (Lista Immagini)...36 Illustrazione 13: OpenStack Dashboard (Elenco Istanze)...37 Illustrazione 14: Esempio di Organizzazione Virtuale (VO)...38 Illustrazione 15: Schema logico dell'implementazione di OpenStack...43 Illustrazione 16: Un Server DELL PowerEdge 1950 1U...43 Illustrazione 17: Un cestello Blade Dell PowerEdge 1955 con 10 server Blade...44 Illustrazione 18: Un server HP ProLiant DL100 G2 e un box da 12 hard disk...44 Illustrazione 19: Schema fisico dell'implementazione di OpenStack...45 Illustrazione 20: Come comunicano i servizi di OpenStack...52 Illustrazione 21: Schema dello scambio di un messaggio...52 Illustrazione 22: RabbitMQ: Direct Exchange...53 Illustrazione 23: RabbitMQ: Fanout Exchange...53 Davide Michelino 566/2723 Pagina 5 di 108

Illustrazione 24: RabbitMQ: Topic Exchange...53 Illustrazione 25: Schema di una chiamata rpc.call...54 Illustrazione 26: Schema di una chiamata rpc.cast...54 Illustrazione 27: Keystone: tenant-list...55 Illustrazione 28: Keystone: user-list...55 Illustrazione 29: Keystone: user-role-list...56 Illustrazione 30: Nova: network-list...56 Illustrazione 31: Schema del funzionamento delle OCCI...58 Illustrazione 32: Autenticazione sul Keystone utilizzando un certificato X.509...60 Illustrazione 33: Observium in esecuzione durante il caso d'uso descritto...69 Davide Michelino 566/2723 Pagina 6 di 108

1 Introduzione L'obiettivo di questo lavoro di tesi è la valutazione di una piattaforma per la creazione di un'infrastruttura di Cloud Computing di tipo IaaS per l'utilizzo di risorse hardware e software distribuite e virtualizzate, che possa affiancare l'attuale struttura di Grid computing. Nello specifico si è sperimentato il middleware OpenStack inserendolo all'interno di un contesto di tipo Virtual Organization permettendo la condivisione e l'uso razionale di risorse tra diverse comunità scientifiche tramite un sistema di autenticazione federata. Inoltre sono state sperimentate tecniche di contestualizzazione per la generazione di macchine virtuali personalizzate in base alle specifiche esigenze, già pronte e configurate alla prima esecuzione. L'installazione di test è stata effettuata nel datacenter dell'infn di Napoli, utilizzando 12 macchine fisiche, delle quali 10 sono state dedicate al calcolo computazionale, una ai servizi di storage e l'ultima per l'esecuzione di tutti i servizi necessari alla gestione della piattaforma di cloud computing. Per la gestione delle risorse virtuali si è deciso di utilizzare l'hypervisor KVM per il bassissimo overhead generato e le sue alte prestazioni, che garantiscono un'ottima implementazione di una Full Virtualization. Il presente lavoro di tesi analizza tutte le tecnologie sulle quali si basa un'infrastruttura di cloud computing. Partendo dal concetto di virtualizzazione verrà fatta una panoramica di quali tecniche permettono l'astrazione di un pool risorse fisiche in risorse logiche, che possono poi essere raggruppate in macchine virtuali; verrà spiegato che ruolo assumono gli hypervisor in quest'ambito e quali sono le tecniche implementative per la loro realizzazione, con un particolare sguardo ai principali vantaggi e svantaggi delle varie architetture di hypervisor. Successivamente verrà chiarito il concetto di Cloud Computing e che ruolo assume nell'attuale panorama del calcolo parallelo e distribuito con i necessari paragoni al Davide Michelino 566/2723 Pagina 7 di 108

grid computing; verranno descritti i vari modelli implementativi di una piattaforma di cloud computing, chiarendo i concetti di Public, Private, Community e Hybrid Cloud. Verranno poi analizzati i differenti modelli di servizio approfondendo le astrazioni che mettono a disposizione e le relazioni che esistono tra i modelli Infrastructure as a Service, Platform as a Service e Software as a Service, con particolare attenzione al modello di più basso livello IaaS e come si affianca alle implementazioni di storage distribuito (Object, Block e File Storage). Chiariti i concetti basilari che stanno alla base di una infrastruttura di Cloud Computing, verrà descritta la piattaforma OpenStack, software per l'implementazione di un'infrastruttura di tipo IaaS, descrivendone le esigenze che hanno contribuito alla creazione di tale progetto e come è strutturato l'intero software; verranno poi descritti tutti i servizi principali che compongono OpenStack: Compute Service, Object Storage, Block Storage, Image Service, Identity Service e la Dashboard. Dopo aver illustrato come è strutturato OpenStack, verranno descritti quali sono gli obiettivi e le esigenze di un sistema di cloud computing federato, l'utilità di condividere le risorse nell'ambito di una Virtual Organization e verrà descritto il progetto che ha dato vita alla Federated Cloud Task Force, gruppo coordinato dall'european Grid Infrastructure con l'obiettivo di creare un sistema di Cloud Computing federato nell'ambito della comunità scientifica europea. Verrà chiarito cosa si intende quando si parla di contestualizzazione nell'ambito di una macchina virtuale e quali metodi esistono per implementare tale tecnica. Nella parte finale del lavoro di tesi verrà descritto come è stata implementata l'infrastruttura di cloud computing, quali software e hardware sono stati utilizzati e come si è arrivati a mettere su un'infrastruttura di tipo Infrastructure as a Service federata con il supporto della contestualizzazione; verrà analizzato come funziona un sistema IaaS implementato con OpenStack, dettagliando e descrivendo le scelte implementative, dalla scelta del software per la gestione delle code dei messaggi, alla descrizione della topologia di rete dell'intera infrastruttura. Verrà prestata Davide Michelino 566/2723 Pagina 8 di 108

particole attenzione ai moduli utilizzati per implementare l'autenticazione federata e i software utilizzati per realizzare la contestualizzazione. Nell'ambito di un'infrastruttura IaaS in un contesto federato verrà analizzata l'esigenza di strumenti interoperabili, ovvero che possano comunicare con qualsiasi tipo di infrastruttura IaaS, indipendentemente dai software utilizzati; a tale scopo verrà presentata l'interfaccia OCCI (Open Cloud Computing Interface), descrivendone le origini, le sue funzioni e la sua implementazione e integrazione in OpenStack. Infine verrà descritto un caso d'uso sviluppato al fine di testare le tecniche di contestualizzazione nell'infrastruttura IaaS, dettagliando tutti i passi necessari per creare da zero un'immagine di un disco virtuale adatta ad essere eseguita su OpenStack sfruttando tutte le peculiarità di una piattaforma di Cloud Computing. Davide Michelino 566/2723 Pagina 9 di 108

2 Virtualizzazione 2.1 Cenni storici Con l'avvento di nuove tecnologie e l'aumento di anno in anno della potenza computazionale a disposizione di singole CPU, sin dalla metà degli anni '60 si è sentita l'esigenza di sperimentare tecniche che permettessero l'utilizzo efficiente della potenza di calcolo a disposizione. La necessità, spesso per adempiere a misure di sicurezza, di eseguire una singola applicazione su un'intera macchina, ha come conseguenza il suo sottoutilizzo sprecando risorse anche in quantità rilevante. La virtualizzazione delle risorse di una macchina è una delle tecniche che ottimizza il suo utilizzo, permettendo l'esecuzione di più sistemi operativi su un singolo elaboratore, ciascuno in un ambiente altamente isolato. Uno dei primi sistemi nell'ambito mainframe ad implementare una completa virtualizzazione fu il CP-40 della IBM rilasciato nel 1967, il sistema era capace di eseguire più istanze in contemporanea del sistema operativo CP/CMS. Per i decenni successivi la virtualizzazione fu appannaggio di sistemi mainframe e di cpu costruite ad hoc per tale scopo, in quanto processori basati su architetture general purpose come quelle x86 non offrivano la possibilità di eseguire istruzioni virtualizzate e l'implementazione software di tali istruzioni risultava computazionalmente dispendiosa. Nel 1999 VMWare rilascia il primo software in grado di gestire la virtualizzazione effettuata via software su architetture x86 con un overhead accettabile; nel 2003 invece nasce Xen, uno dei più influenti progetti nell'ambito del Software Libero. A seguito del crescente aumento dell'attenzione nell'informatica rispetto alla virtualizzazione, Intel decide di estendere il set di istruzioni dei propri processori x86, includendo delle istruzioni dedicate alla virtualizzazione: nel 2005 integra Davide Michelino 566/2723 Pagina 10 di 108

l'estensione Intel Virtualization Technology (IVT) sulle architetture IA-32 e EM64T; parallelamente AMD sviluppa ed integra le proprie istruzioni dedicate alla virtualizzazione sui processori da essa prodotti, denominando l'estensione AMD Virtualization (AMD-V), disponibili sia su architetture a 32bit che a 64bit. 2.2 Le tecnologie di virtualizzazione L'obiettivo delle tecnologie di virtualizzazione è astrarre tutte le componenti hardware di una macchina fisica al fine di renderle disponibili come risorse logiche a diverse istanze di sistemi operativi eseguiti parallelamente. La gestione dell'hardware e quindi delle relative componenti virtualizzate è demandata ad uno strato software chiamato Hypervisor posizionato ad uno dei livelli più bassi della pila delle componenti che formano un sistema virtualizzato. L'Hypervisor viene eseguito su una macchina fisica denominata host e il suo ruolo principale è intercettare e tradurre le chiamate di sistema effettuate dai sistemi operativi ospiti (guest), affinché vengano correttamente eseguite dalla CPU anche nel caso in cui esistano più guest in esecuzione in maniera concorrente. Esistono differenti implementazioni degli hypervisor, categorizzate a seconda della tipologia di virtualizzazione che rispettivamente gestiscono: 1. Full Virtualization: è la tipologia di virtualizzazione che permette ai sistemi Davide Michelino 566/2723 Pagina 11 di 108

operativi guest di essere eseguiti senza essere a conoscenza di trovarsi, in realtà, in un ambiente virtualizzato. Con questa tipologia di virtualizzazione, qualunque sistema operativo che funzionerebbe sull'hardware host, funzionerà nell'ambiente virtualizzato e sarà compito dell'hypervisor gestire e allocare le risorse ai singoli guest, fornendo una rappresentazione logica di tutte le periferiche e le componenti hardware. Questa tipologia di hypervisor può essere implementata in due modalità differenti: a) Native, chiamata anche Type 1 è l'implementazione dell'hypervisor direttamente sull'hardware host; è l'implementazione che offre le migliori prestazioni in quanto, permette ai guest di trovarsi solo un livello sopra l'hypervisor. Esempi di questo hypervisor sono VMWare ESX, Xen e KVM. b) Hosted, chiamata anche Type 2 è l'implementazione dell'hypervisor su un sistema operativo preesistente. In questa implementazione l'hypervisor per funzionare si basa sulle risorse messe a disposizione dal sistema operativo in esecuzione. Esempi di questo hypervisor sono VirtualBox e VMWare Server. 2. Para Virtualization: è la tipologia di virtualizzazione che necessita che il sistema operativo guest sia modificato in maniera opportuna. In tale tipologia l'hypervisor mette a disposizione ai sistemi operativi guest un'interfaccia software con la quale le macchine virtuali comunicano, utilizzando specifiche chiamate di sistema. Grazie a questa tecnica le macchine virtuali possono delegare l'hypervisor a eseguire determinate operazioni direttamente sull'hardware, evitando di eseguirle in un contesto virtuale, computazionalmente più costoso. Un esempio di questo hypervisor è Xen. 3. Virtualizzazione a livello di Sistema Operativo: tipologia che si distacca molto dalla precedenti, nella quale non viene implementato un vero e proprio hypervisor, ma il kernel del Sistema Operativo offre la possibilità di generare contesti multipli in user-space, altamente isolati fra di loro. Questo tipo di Davide Michelino 566/2723 Pagina 12 di 108

virtualizzazione non crea quasi alcun overhead, non dovendo virtualizzare alcun componente; ma è poco flessibile, in quanto tutte le istanze gireranno utilizzando il medesimo kernel. Esempi di tale tipologia di virtualizzazione sono, il meccanismo Linux-V Server incluso nel kernel Linux e OpenVZ. 2.2.1 KVM La schematizzazione spiegata nel paragrafo precedente, permette di definire a grandi linee il funzionamento degli hypervisor, ma non sempre è possibile associare un determinato hypervisor entro i confini di una singola categoria. Un esempio pratico è rappresentato da KVM (Kernel-based Virtual Machine) che è nato come modulo del kernel Linux e quindi, per quanto sia implementato come un hypervisor Type 1 necessita di un sistema operativo Linux-based per essere utilizzato, entrando nei confini della categoria Type 2. Per funzionare KVM utilizza un set di istruzioni aggiuntivo delle CPU x86 ma esistono versioni modificate per fornire servizi di virtualizzazione anche su architetture differenti, come i processori ARM, utilizzando tecniche simili alla paravirtualizzazione di XEN. Esistono inoltre porting del modulo di Linux anche per altri kernel e sistemi operativi Unix-like come FreeBSD e illumos. Davide Michelino 566/2723 Pagina 13 di 108

3 Il Cloud Computing Il termine Cloud Computing indica un insieme di tecniche e tecnologie informatiche che permettono l'accesso, tramite una rete, a risorse computazionali, siano esse di calcolo o di archiviazione; in genere tali risorse fanno parte di una rete eterogenea distribuita e messe a disposizione tramite tecniche di virtualizzazione. Lo scopo ultimo del Cloud Computing è astrarre tutta l'infrastruttura, sia di rete che degli elaboratori, esponendo pubblicamente delle API (Application Programming Interface), che si occuperanno di comunicare con i servizi che effettivamente orchestrano e gestiscono il cloud. Davide Michelino 566/2723 Pagina 14 di 108

3.1 I modelli implementativi L'insieme di risorse che costituiscono l'infrastruttura di Cloud Computing, possono essere messe a disposizione a diverse tipologie di utilizzatori e secondo diverse modalità di utilizzo, a seconda di tali caratteristiche si possono stabilire quattro differenti modelli implementativi di Cloud Computing: quale le risorse (come ad esempio intere macchine virtuali) o i servizi offerti (come ad esempio dello spazio di archiviazione), vengono resi disponibili pubblicamente su una rete (in genere su Internet) e il provider decide se l'accesso a tali risorse deve essere gratuito o è necessaria una sottoscrizione a pagamento. 2. Private Cloud: in questa implementazione di Cloud Computing un'intera infrastruttura viene fornita ad una singola organizzazione, che utilizzerà le risorse a disposizione secondo le proprie necessità. L'hardware necessario può risiedere all'interno della struttura dell'organizzazione o presso un provider esterno. Davide Michelino 566/2723 Pagina 15 di 108

3. Community Cloud: in questa implementazione di Cloud Computing, un'intera infrastruttura viene fornita ad una comunità formata da diverse organizzazioni che condividono obbiettivi o progetti, potendo utilizzare ognuno le risorse a disposizioni del cloud a seconda delle necessità. In questa implementazione la gestione dell'infrastruttura può essere delegata ad una o più delle organizzazioni o un terzo che si fa carico della manutenzione. 4. Hybrid Cloud: E' la composizione di due o più delle implementazioni di public, private o community Cloud, aumenta la flessibilità dell'intera infrastruttura utilizzando le peculiarità di ognuna di esse. Un esempio potrebbe essere l'utilizzo di una private cloud per l'esecuzione di un'applicazione, con il supporto delle risorse di una public cloud quando servono risorse aggiuntive; o semplicemente l'utilizzo di due private cloud messe in comunicazione tra loro. Davide Michelino 566/2723 Pagina 16 di 108

3.2 I modelli di servizio A seconda del livello di astrazione e dagli obiettivi che si desidera raggiungere nell'implementazione dell'infrastruttura, sono stati definiti diversi modelli architetturali, denominati modelli di servizio (service models). I tre principali modelli di servizio sono Infrastrucure as a Service (Iaas), Platform as a Service (PaaS) e Software as a Service (SaaS), dove IaaS rappresenta il livello di base e i livelli più alti si fondano sulle astrazioni fornite dai livelli sottostanti. 3.2.1 Il paradigma IaaS E' il modello di servizio basilare di un'infrastruttura di Cloud Computing, secondo il paradigma IaaS una o più macchine fisiche forniscono risorse computazionali all'infrastruttura di Cloud, formando un pool di macchine virtualizzate. In genere il Davide Michelino 566/2723 Pagina 17 di 108

fornitore di Cloud, mette a disposizione le risorse utilizzando un middleware che che si occuperà di gestirle e orchestrarle; mentre l'utilizzatore tramite delle interfacce, usufruirà delle risorse di cui necessita, creando la propria infrastruttura. Le risorse messe a disposizione dal fornitore sono prevalentemente risorse computazionali (computing) e di archiviazione (storage). I componenti principali che in genere formano un middleware per il paradigma IaaS sono: 1. Un servizio di Computing, che poggiandosi su un hypervisor, gestisce le risorse computazionali (CPU e RAM) allocate. 2. Un servizio di Networking, che gestisce e crea le interfacce di rete sulle singole macchine virtuali, il routing, l'eventuale nat da effettuare sulle connessioni e le vlan per configurazioni di networking più avanzate. 3. Un servizio di Storage per la gestione dello spazio di archiviazione. 4. Un servizio di API che fornisce le interfacce con le quali si comunica e si impartiscono comandi a tutta l'infrastruttura di cloud computing, in genere queste API sono di tipo RESTful su protocollo http(s). 5. Un servizio di Authentication, accounting e authorization che gestisce le utenze e i sistemi di autenticazione, assegnando specifici privilegi a singoli utenti o gruppi di utenti; curando quindi le politiche di accesso alle risorse. 6. Un servizio di Message queue che si occupa della gestione della coda dei messaggi che i singoli servizi si inviano per comunicare tra loro. 7. Un servizio di Metadata che si occupa della gestione delle informazioni che il middleware utilizza per tenere traccia delle risorse assegnate. 8. Un servizio di Image che si occupa della gestione delle immagini dei sistemi operativi che possono essere eseguiti sull'infrastruttura di Cloud Computing. Davide Michelino 566/2723 Pagina 18 di 108

3.2.2 La virtualizzazione della piattaforma PaaS Il modello di servizio Platform as a Service si posiziona ad un livello più alto di IaaS: sfruttando le astrazioni che quest'ultimo modello mette a disposizione, rende invisibile all'utilizzatore tutto quello che si trova al livello più basso. Il fornitore di servizi PaaS, mette a disposizione la possibilità di eseguire sulla propria infrastruttura Sistemi Operativi con relativi ambienti di sviluppo o applicativi già pronti, sgravando l'onere all'utilizzatore di preoccuparsi di quante risorse la propria piattaforma necessita. Sarà compito infatti dei servizi a livello più basso scalare l'infrastruttura a seconda delle effettive risorse che necessita la piattaforma in esecuzione. 3.2.3 Il concetto di Software as a Service SaaS Il modello Software as a Service astrae ulteriormente tutto quello che si trova sotto il livello dell'applicazione: il fornitore del servizio offre un piccolo client che permette di accedere all'applicazione, in genere accessibile addirittura da un web browser. L'utilizzatore accederà all'applicazione senza sapere che piattaforma, sistema operativo o librerie sono necessarie per l'esecuzione del software, né dovrà tener conto delle risorse computazionali necessarie per far funzionare l'applicazione, in quanto spetterà ai livelli sottostanti gestire e allocare le piattaforme e le risorse necessarie alla sua corretta esecuzione. In questo modo, sarà così possibile accedere alla propria applicazione da qualunque client capace di comunicare con la piattaforma di Cloud Computing. Davide Michelino 566/2723 Pagina 19 di 108

3.3 Lo Storage nel modello IaaS L'archiviazione e l'accesso ai dati rappresenta uno degli elementi critici di un'architettura di Cloud Computing secondo il modello Infrastracure as a Serivice. A seconda delle necessità si utilizzano diverse tipologie di storage e implementazioni di accesso ai dati, che possono essere suddivise in tre categorie principale: l'object storage, il block storage e il file storage. 3.3.1 L'object storage L'object storage è uno delle implementazioni tipiche nell'ambito del Cloud Computing. E' un modello strutturato per riuscire ad creare un sistema di storage replicato, distribuito e duttile a partire da apparati di archiviazione a basso costo. Il layer software che gestisce un object storage implementa da una parte, la gestione di un pool di device in maniera tale che possa essere esteso in qualunque momento, mantenendo l'integrità della replicazione dei dati e la proporzionalità del livello di distribuzione; mentre dall'altra parte implementa un'interfaccia per l'accesso ai file che astrae completamente i file system e nasconde la complessità architetturale del sistema. Davide Michelino 566/2723 Pagina 20 di 108

Nella tipica implementazione di object storage, il software rappresenta ogni singolo file come un oggetto, esponendoli tramite un'interfaccia RESTful su protocollo http(s) e sfrutta un servizio di authentication, accounting e authorization per gestire le credenziali e i permessi degli utenti e dei singoli servizi che necessitano accedere allo storage. Grazie alle caratteristiche che presenta, l'object storage si presta particolarmente per l'archiviazione delle immagini delle macchine virtuali e per l'implementazione di servizi di cdn (Content Delivery Network). 3.3.2 Il block storage Il block storage è l'implementazione che permette di creare dischi virtuali da legare alle singole macchine virtuali. Questa tipologia di storage permette di estendere la quantità di spazio di archiviazione che le macchine virtuali nell'infrastruttura di cloud computing hanno a disposizione, legando un numero arbitrario di dischi, secondo le specifiche necessità. Nelle classica implementazione di block storage, il software si occupa di creare un device logico a partire da risorse fisiche di storage a disposizione, che verrà visto dal sistema operativo come un classico dispositivo a blocchi e messo a disposizione utilizzando protocolli come iscsi o FibreChannel; sarà compito poi di chi amministra il sistema creare e gestire il file system del dispositivo a blocchi montato. 3.3.3 Il File storage Il file storage è il modello di uno storage di rete accessibile contemporaneamente da più postazioni; si può implementare sia utilizzando i classici file system distribuiti come NFS o CIFS, sia utilizzando software nati per lavorare in ambienti altamente distribuiti come GlusterFS. Davide Michelino 566/2723 Pagina 21 di 108

4 OpenStack OpenStack è un progetto che permette di implementare una infrastruttura di Cloud Computing secondo il modello di servizio Infrastracure as a Service. Il progetto è interamente rilasciato sotto i termini della licenza libera Apache License e viene attualmente mantenuto e supportato dalla OpenStack Foundation, un'entità no profit fondata nel settembre del 2012. Dalla nascita di OpenStack nel Luglio 2010 su iniziativa di Rackspace Hosting e della NASA, più di 150 aziende hanno contribuito al suo sviluppo, facendolo diventare uno dei progetti più influenti nel panorama del Cloud Computing. Il progetto viene concepito con il proposito di creare uno standard aperto a partire da una visione condivisa sulla filosofia circa le architetture di cloud computing e lo sviluppo comunitario e aperto. Tutto il software è sviluppato in Python seguendo un'architettura di tipo modulare, dove ogni componente è un software indipendente, sviluppato secondo le linee guida definite dalla OpenStack Foundation. Alcuni dei componenti erano software già esistenti precedentemente, che sono stati poi adattati e riscritti secondo le linee guide definite, per essere integrati in OpenStack. Tutti i moduli coprono i servizi principali che un'infrastruttura di tipo IaaS deve offrire, infatti attualmente l'intero progetto è formato da numerosi componenti che verranno dettagliati nei capitoli a seguire. Davide Michelino 566/2723 Pagina 22 di 108

Illustrazione 5: Schema concettuale di OpenStack 4.1 OpenStack Compute (Nova) OpenStack Compute è il servizio di OpenStack che permette di eseguire istanze multiple di macchine virtuali su tutti gli host che eseguono il servizio novacompute. Nova rappresenta uno dei servizi principali di un'architettura IaaS, e si occupa di allocare e di tener traccia delle risorse utilizzate e disponibili su tutta l'infrastruttura di cloud computing, indipendentemente dall'hypervisor che è in esecuzione al livello sottostante. Nella pratica quando nella coda dei messaggi arriva una richiesta di istanziazione di una macchina virtuale, nova si occuperà di comunicare con l'hypervisor, ordinandogli di allocare le risorse necessarie; analogamente funziona il meccanismo di rilascio delle risorse e la distruzione di una macchina virtuale. Nova nasce come progetto dei laboratori di ricerca della NASA, fu concepito con l'obiettivo di realizzare un software altamente scalabile, capace di supportare carichi di lavoro elevati, sviluppato seguendo un'architettura che fosse capace di continuare Davide Michelino 566/2723 Pagina 23 di 108

a funzionare in caso di errori e che seguisse un'implementazione conforme agli standard aperti, in modo che fosse interoperabile con differenti API. 4.2 OpenStack Object Storage (Swift) OpenStack Object Storage (Swift) è un servizio di OpenStack che fornisce una soluzione altamente scalabile e ridondante per l'archiviazione di file. Le componenti fondamentali di un'implementazione di Swift sono gli Object Server, ovvero le macchine che sono dedicate all'effettivo immagazzinamento dei dati, i quali verranno conservati in formato binario con dei metadati associati utilizzando gli attributi xattrs; questo necessita quindi l'utilizzo di un filesystem che supporta le estensioni xattrs, come ad esempio, ext3 o ext4. Ogni oggetto viene memorizzato utilizzando un path derivato dall'hash del file e dal timestamp dell'operazione, così da assicurare che verrà servita sempre l'ultima versione disponibile. Per assicurare Davide Michelino 566/2723 Pagina 24 di 108