Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di calcolatori I Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack Anno Accademico 2012/2013 Candidato: Mariano Polito matr. N

2 Ai miei genitori che mi hanno costruito questo percorso. A mia sorella che mi ha sostenuto nel percorrerlo. A Tania che mi ha indirizzato su di esso. A mia nonna che sarà luce nei miei prossimi passi. Al mio miglior compagno di studi da sempre, nonché fratello gemello.

3 Indice Introduzione 5 Capitolo 1. Cloud computing Principali caratteristiche Architettura e principali attori Modelli di servizio Software as a Service Platform as a Service Infrastructure as a Service Hardware as a Service Data as a Service Modelli di distribuzione Public Cloud Private Cloud Community Cloud Hybrid Cloud 16 Capitolo 2. OpenStack Storia di OpenStack Progetti di OpenStack OpenStack Dashboard ( Horizon ) OpenStack Compute ( Nova ) OpenStack Networking ( Neutron ) OpenStack Object Storage ( Swift ) OpenStack Block Storage (code-name Cinder) OpenStack Identity ( Keystone ) OpenStack Image Service ( Glance ) OpenStack Telemetry ( Ceilometer ) OpenStack Orchestration ( Heat ) 28 Capitolo 3. Gestione della rete Nova Network 30 III

4 3.1.1 Flat Network FlatDHCP Network Vlan Network Openstack Networking( Neutron ) Componenti Plug-in Architettura Casi d uso Namespaces FWaaS 46 Conclusioni 48 Bibliografia 49 IV

5 Introduzione L evoluzione delle tecnologie informatiche e dei mezzi di comunicazione è inarrestabile e ogni giorno vengono messi a disposizione degli utenti nuovi strumenti e soluzioni sempre più sofisticate e integrate con la rete Internet, che consentono di soddisfare crescenti esigenze di informatizzazione e di comunicazione. In tale scenario risulta rilevante il concetto di cloud computing ovvero un modello che offre risorse e servizi accessibili mediante la rete. Anche se il termine cloud computing risulta d uso frequente negli ultimi anni, esso è stato introdotto negli anni 60 quando la tecnologia dominante dell epoca risiedeva nei vecchi mainframe, da John McCarthy affermando che il metodo time-sharing avrebbe condotto ad un futuro dove la potenza dei calcolatori e delle applicazioni sarebbe stata venduta secondo il modello economico della utilità, come per l acqua e l elettricità. Il cloud computing, porta quindi ad un nuovo concetto di rete, che oltre a garantire l instradamento di pacchetti, sia in grado di scegliere la risorsa disponibile più adatta al contesto d utilizzo in modo da fornire all utente finale ciò che vuole nel migliore dei modi. Uno dei principali progetti nati per offrire quanto su descritto è OpenStack, un progetto di cloud computing open source lanciato nel 2010, che negli ultimi anni ha fatto della rete uno dei principali oggetti di studio, offrendo sempre di più la rete come un servizio, ovvero gestibile dinamicamente dall utente. Il primo capitolo di questo elaborato introdurrà quelli che sono gli aspetti più importanti 5

6 per il cloud computing, dopodiché nel secondo capitolo verrà introdotto il progetto OpenStack fornendo una panoramica della sua architettura e dei suoi componenti. Infine, nel terzo e ultimo capitolo, verrà trattato la gestione della rete all interno di OpenStack. 6

7 Capitolo 1 Cloud Computing Il cloud computing è un nuovo paradigma informatico, in base al quale si ha la possibilità di usufruire di un accesso conveniente e su richiesta a risorse computazionali condivise (ad esempio reti, server, memoria di massa, applicazioni e servizi), secondo una modalità tale da non richiedere la conoscenza della locazione fisica e della configurazione del sistema che fornisce il servizio in questione da parte dell'utente finale. Il modello si basa sul concetto di pay-per-use, ovvero si possono utilizzare tutte le applicazioni che risiedono nella nuvola pagando l effettivo utilizzo. Una definizione standard del cloud computing è fornita dal NIST: Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [2] Il cloud computing è un modello abilitante, tramite la rete, un accesso comodo ed ondemand ad un pool condiviso di risorse di calcolo configurabili (ad esempio reti, server, memoria, applicazioni e servizi) che possono essere velocemente ottenute e rilasciate con minimo sforzo di gestione o di interazione con il fornitore di servizi 7

8 Il cloud computing nasce per ridurre e contenere i costi dell IT 1 migliorando i servizi. Quest ultimi sono indipendenti dalla piattaforma e possono essere pubblicati oppure si possono comporre ottenendo applicazioni distribuite. L'applicazione così ottenuta diventa a sua volta un servizio disponibile sulla rete. Quindi si mettono a disposizione online risorse che possono essere risorse software nonché risorse hardware(cpu,dischi fissi). Tale caratteristica del cloud computing è indicata con l espressione XaaS acronimo di X as a service. 1.1 Principali Caratteristiche Fig. 1.1 Cloud Computing Secondo la definizione standard fornita dal NIST il modello presenta cinque caratteristiche essenziali: On-demand self-service (Self-service su richiesta): il cliente deve poter utilizzare il servizio su richiesta in base alle sue necessità e nel momento in cui lo ritiene opportuno, senza richiedere interazione umana con alcun fornitore del servizio. 1 L'IT, acronimo di Information Technology, indica l'uso della tecnologia nella gestione e nel trattamento dell'informazione, specie nelle grandi organizzazioni. 8

9 Broad network access (Ampio accesso in rete): i servizi sono presenti in rete accessibili e utilizzabili in qualsiasi momento attraverso piattaforme eterogenee (telefoni mobili, tablet, laptops e workstations) secondo meccanismi standard. Resource pooling (Condivisione delle risorse): le risorse di servizio del fornitore sono raccolte per servire molteplici consumatori utilizzando un modello condiviso, il modello multi-tenant, con le diverse risorse fisiche e virtuali assegnate e riassegnate dinamicamente in base alla domanda. L utente generalmente non ha controllo o conoscenza dell esatta ubicazione delle risorse fornite, ma può essere in grado di specificare la posizione ad un livello superiore di astrazione (ad esempio, paese, stato o data center). Rapid elasticity (Elasticità rapida): le risorse possono essere acquisite e rilasciate elasticamente, in alcuni casi anche automaticamente. Al consumatore, le risorse disponibili spesso appaiono illimitate e disponibili in qualsiasi quantità, in qualsiasi momento. L'illusione di infinite risorse di calcolo disponibili on-demand, elimina la necessità per gli utenti di pianificare sulle necessità di calcolo, evitando così di sottodimensionarle/sovradimensionarle. Measured service (Servizio misurato): i sistemi cloud controllano ed ottimizzano automaticamente l uso delle risorse, basandosi su un modello tariffario pay-peruse. L utilizzo delle risorse può essere monitorato, controllato e segnalato, fornendo trasparenza sia per il fornitore che per l utilizzatore del servizio. 1.2 Architettura e principali attori Il sistema del cloud computing può essere suddiviso in due macro parti: il frontend e il backend. Entrambi sono connessi tra di loro attraverso la rete, solitamente Internet. Il frontend è ciò che l'utente vede e con cui interagisce e accede al cloud, il backend è invece il cloud vero e proprio, quindi composto da tutti quei dispositivi come computer, 9

10 server e dispositivi di memorizzazione dei dati. Analizzando i principali attori, nel cloud computing è possibile individuare cinque ruoli principali: Il cloud provider (o cloud service provider): è il soggetto responsabile di rendere il servizio utilizzabile alle terze parti. Il cloud consumer (o cloud service consumer): è il principale soggetto che utilizza i servizi di cloud computing. Può essere una persona od organizzazione che ha una relazione di business con uno o più cloud provider Il cloud broker è il soggetto che gestisce l impiego, le prestazioni e l erogazione dei servizi cloud e cura le relazioni tra cloud provider e cloud consumer. Il cloud auditor è il soggetto che può eseguire un esame sui controlli effettuati sui servizi con il fine di esprimere un parere: può valutare i servizi erogati da un cloud provider come ad esempio i controlli per la sicurezza, l impatto sulla privacy e sulle prestazioni. Il cloud carrier agisce come un intermediario che fornisce connettività e trasporto di servizi cloud tra il cloud consumer e il cloud provider; permette l accesso al cloud consumer attraverso le reti e i dispositivi di accesso (come computer desktop, computer portatili, smartphone e altri dispositivi internet mobile). 10

11 Fig.1.2 Principali attori del cloud computing 1.3 Modelli di servizio Il cloud computing offe vari modelli di servizio, che determinano come il servizio viene erogato. Tra i modelli si distinguono tre principali quali: Software as a Service (SaaS) Platform as a Service (PaaS) Infrastructure as a Service (IaaS) Conosciuti anche come modello SPI. A questi tre modelli principali vengono integrati dei secondari quali: Data as a Service (DaaS) Hardware as a Service (HaaS) Software as a Service Software as a Service (SaaS) è un modello di distribuzione del software in cui le 11

12 applicazioni sono ospitate da un fornitore o cloud provider e resi disponibili ai clienti attraverso una rete, in genere Internet. Il termine SaaS è diventato il termine di riferimento, rimpiazzando il precedente modello ASP 2. La differenza sostanziale tra i due è che nel modello ASP il provider acquista il software dal produttore e lo rende disponibile online a differenza del modello SaaS in cui il software viene distribuito dal produttore stesso o da una terza parte in stretta relazione con il produttore. Inoltre, nel modello ASP le applicazioni distribuite spesso sono fruibili in modalità client/server o con interfaccia utente a carattere, adattate solo successivamente per l'utilizzo remoto. Nel modello SaaS, viceversa, entrano in gioco applicazioni nuove, nate e sviluppate per essere fruite tramite un browser e quindi che risultano native nel mondo web. In questo modello il consumatore non controlla server, sistemi operativi, rete memoria, ma può configurare delle opzioni per le applicazioni a lui destinate. Esempi di questo modello sono: Oracle, IBM, Microsoft, SalesForce e Google Apps; Platform as a Service Platform as a Service è un modello che offre delle piattaforme di elaborazione, che permettono all utente di creare applicazioni attraverso linguaggi di programmazione, librerie, servizi e strumenti supportati dal fornitore. La piattaforma è vista come un servizio che esporta tool e API per lo sviluppo della propria applicazione e l utente che sceglie un servizio è quindi uno sviluppatore. Lo sviluppo può venire effettuato in modalità on-line o in modalità off-line. In quest'ultimo caso lo sviluppatore dopo aver effettuato il download di una parte della piattaforma, potranno sviluppare il software all'interno della propria infrastruttura. Dopodiché effettua l'upload mediante sincronizzazione nella piattaforma pubblica. In questo modello il consumatore non controlla rete, server, sistemi operativi, memoria, ma ha il controllo sulle applicazioni ed eventualmente sulle configurazioni dell ambiente che le ospita. 2 ASP, acronimo di application service provider è un modello architetturale per l'erogazione di servizi informatici che prevede una spinta remotizzazione elaborativa ed applicativa. 12

13 Esempi di questo modello sono: Google AppEngine, Microsoft Azure e Force.com Infrastructure as a Service Infrastructure as a Service è un modello che offre come suggerisce il nome l infrastruttura come servizio,ovvero offre al consumatore capacità di CPU, storage, network e altre risorse fondamentali utilizzando la tecnica di virtualizzazione 3. In particolare si creano delle Virtual Machines indipendenti chiamate anche istanze che vengono gestite dall hypervisor,che ridimensionano i servizi a seconda dei requisiti del cliente. In questo modello il consumatore controlla sistemi operativi, memoria, applicazioni ed eventualmente, in modo limitato, alcuni componenti di rete (esempio firewalls 4 ). Esempi di questo modello sono: GoGrid,Felixscale,Joyent, Amazon's EC2, Eucalyptus, OpenStack Hardware as a Service Fig.1.3 Modello SPI Hardware as a Service è un modello che offre ai clienti l hardware come servizio,ovvero il cliente invia i dati al provider insieme alle istruzioni su come dovrebbe essere elaborati, 3 In informatica il termine virtualizzazione si riferisce alla possibilità di astrarre le componenti hardware, cioè fisiche, degli elaboratori al fine di renderle disponibili al software in forma di risorsa virtuale. 4 Il firewall è un apparato di rete hardware o software che filtra i pacchetti entranti ed uscenti da una rete, per contribuire alla sicurezza della stessa. 13

14 dopodiché i server/sistemi del fornitore di HaaS forniscono all utente l elaborazione di tali dati. Un esempio di modello HaaS: Lanchpad Data as a Service Data as a Service è un modello in cui i dati rappresentano il servizio, ovvero il fornitore offre spazio all utente per memorizzare i dati online. I dati possono essere di diversi formati e sono disponibili come se fossero presenti nel disco locale del computer. Alcuni esempi di modello DaaS: Amazon S3, Google BigTable, Apache HBase. 1.4 Modelli di distribuzione Il cloud computing ( riferendoci sempre alla definizione fornita dal NIST) presenta quattro modelli di distribuzione: Public Cloud Private Cloud Hybrid Cloud Community Cloud Public Cloud Un modello di distribuzione in cui il cloud provider rende disponibili le risorse attraverso dei servizi pubblici accessibili attraverso internet generalmente con un modello pay-peruse. Tra i principali benefici di questo modello vi è l abbattimento dei costi per l investimento iniziale e una distribuzione in genere molto più veloce e con maggiore scalabilità. Tuttavia tale modello presenta il problema della sicurezza e della privacy dei dati, in quanto l utente perde il controllo degli stessi affidandoli a terze parti per la loro gestione. 14

15 1.4.2 Private Cloud I cloud privati chiamati anche nuvola aziendale sono progettati per l uso esclusivo per un unica organizzazione, gestiti internamente oppure ospitati esternamente da terze parti. Tale modello fornisce servizi di hosting ad un numero limitato di persone dietro un firewall. Il punto di forza di questo modello riguarda principalmente la sicurezza e la riservatezza poiché solamente gli utenti dell'organizzazione hanno accesso al cloud privato. Tuttavia in tale modello non si è più indipendenti dalla costruzione e manutenzione di una nuova infrastruttura di computing, infatti la creazione di un cloud privato significa investimenti significativi e non può essere paragonato alle economie ottenute con il cloud pubblico Community Cloud Il community cloud è un modello in cui le infrastrutture sono condivise tra diverse organizzazioni di una specifica comunità con interessi comuni (ad esempio missione, requisiti di sicurezza, vincoli di condotta e di conformità), può essere gestita internamente da una o più organizzazioni della comunità o da terze parti. I costi sono ripartiti su un minor numero di utenti di un cloud pubblico ma più di un cloud privato Hybrid Cloud Come suggerisce il nome stesso, il cloud ibrido è costituito da due o più cloud, privati, community o pubblici per offrire i benefici dei vari modelli, restando tuttavia entità uniche, ovvero ognuna mantiene la propria identità nonostante venga unita assieme alle altre. In tale modello l organizzazione gestisce alcune risorse in-house ed altre fornite esternamente. Generalmente un azienda può eseguire un applicazione inizialmente su un cloud privato e affidarsi a un cloud pubblico durante i picchi di utilizzo. Passo fondamentale di tale modello è l analisi sulla distribuzione dei carichi elaborativi, fra i diversi cloud. 15

16 Capitolo 2 OpenStack OpenStack è un progetto di cloud computing open source, rilasciato sotto licenza Apache 5, per tutti i tipi di cloud, che mira ad essere semplice da implementare, altamente scalabile e ricco di funzionalità. Fornisce un infrastruttura come servizio (IaaS), ogni servizio offre un API che ne facilita l integrazione. Quindi a seconda dell esigenza dell utente è possibile installare alcuni o tutti i servizi. La crescita di tale progetto è dovuta alla grande comunità di sviluppatori che partecipano, infatti ad oggi più di 200 aziende aderiscono al progetto tra cui: IBM, Intel, Oracle, Cisco, Dell. Tutto il software è sviluppato principalmente in Python seguendo un'architettura di tipo modulare, dove ogni componente è un software indipendente, sviluppato secondo le linee guida definite dalla OpenStack Foundation. La tecnologia consiste in una serie di progetti interconnessi che controllano grandi insiemi di risorse computazionali, la conservazione, e le risorse di rete, presenti in tutto il data center, il tutto gestito attraverso una dashboard che fornisce agli amministratori un controllo e che consente loro di allocare risorse, oppure attraverso delle API specifiche di ogni servizio. 5 Licenza Apache: è una licenza di software libero scritta dalla Apache Software Foundation(ASF) che obbliga gli utenti a preservare l'informativa di diritto d'autore e d'esclusione di responsabilità nelle versioni modificate. 16

17 Fig.2.1 Modello generale di OpenStack 2.1 Storia di OpenStack OpenStasck è stato lanciato per la prima volta il 19 luglio Fino ad allora, l'unica possibilità di avere un servizio della stessa portata era affidarsi ad Amazon e al suo Elastic Compute Cloud (EC2). La paternità di tale progetto è sia della NASA sia dell'azienda di hosting Rackspace grazie alla collaborazione delle due iniziata nell estate del 2010, quando Joshua McKenty, consulente della NASA, scrisse nel suo blog il seguente post: Launched Nova. Apache-Licensed Cloud Computing, in Python. It s live, it s buggy, it s beta. Check it out. Lanciato Nova. Apache-Licensed Cloud Computing, in Python. È vivo, è pieno di bug, è beta. Date un occhiata Tale post suscitò l attenzione di Rick Clark della Rockspace, che in quel periodo stava lavorando anche lui all interno della compagnia per lo sviluppo di un applicazione open source, per costruire piattaforme di cloud computing. Così gli esecutivi di Rackspace chiesero di poter vedere il lavoro della NASA, preoccupati per una concorrenza così 17

18 importante che andava nella loro stessa direzione e grazie a Jim Curry, vice presidente di corporate development di Rackspace e figlio di un ingegnere della NASA, ci fu un colloquio con il team della NASA. In questo colloquio scoprirono increduli che tra i due progetti più che una somiglianza esisteva una vera e propria identità: avevano usato gli stessi strumenti, le stesse scelte di linguaggio. Così decisero di fondere i due team e andare avanti nello stesso progetto. I due codici per quanto simili erano complementari: la NASA aveva creato il server virtuale Nova e Rackspace aveva creato Swift, uno storage, quindi l uno era una specie di Amazon EC2, mentre l altro era il suo Simple Storage Service (S3). A fine colloquio i due team decisero che avrebbero unito i due codici in un solo progetto open source, che si sarebbe chiamato OpenStack. La primissima versione di OpenStack denominata Austin è stata rilasciata nell ottobre 2010, dopodiché la comunità di sviluppo rilasciava nuove versioni ogni tre mesi. Dalla release Diablo il ciclo di rilascio passò dai tre ai sei mesi, arrivando all attuale release Havana, rilasciata nell ottobre In Fig. 2.2 si riportano tutte le release rilasciate negli anni. Fig.2.2 Release di OpenStack 18

19 2.2 Progetti di Openstack Come precedentemente affermato OpenStack ha un architettura di tipo modulare, che consiste in una serie di progetti interconnessi ognuno dei quali fornisce ulteriori funzionalità. Le relazioni tra i vari progetti vengono descritte attraverso l architettura concettuale mostrata in Fig.3.2. Facendo riferimento alla release attuale, ovvero Havana, vi sono ben nove progetti quali: OpenStack Compute (code-name Nova) integrato dalla release Austin OpenStack Networking (code-name Neutron) - integrato dalla release Folsom OpenStack Object Storage (code-name Swift) - integrato dalla release Austin OpenStack Block Storage (code-name Cinder) - integrato dalla release Folsom OpenStack Identity (code-name Keystone) - integrato dalla release Essex OpenStack Image Service (code-name Glance) - integrato dalla release Bexar OpenStack Dashboard (code-name Horizon) - integrato dalla release Essex OpenStack Telemetry (code-name Ceilometer) - integrato dalla release Havana OpenStack Orchestration (code-name Heat) - integrato dalla release Havana Fig.2.3 Architettura concettuale 19

20 2.2.1 OpenStack Dashboard ( Horizon ) OpenStack Dashboard fornisce agli amministratori e agli utenti un interfaccia grafica selfservice web-based per interagire con i servizi di OpenStack, ad esempio, lanciare un istanza di macchina virtuale, configurare i controlli di accesso, configurare la rete. Il design estensibile rende facile da collegare ed esporre prodotti e servizi di terze parti. Agli amministratori offre la visione complessiva sulla dimensione e sullo stato del cloud, permettendo loro di creare utenti e progetti, assegnare gli utenti ai progetti e fissare un limite alle risorse utilizzabili per un dato progetto. Per usufruire delle funzionalità degli amministratori è necessario una connettività attraverso le Admin API, che non sono accessibili dai normali utenti. Inoltre Horzion fornisce supporto per i nuovi servizi introdotti nell ultima release Havana, in particolare per OpenStack Orchestration fornisce supporto per la generazione di forme dinamiche supportate da Heat template, e per OpenStack Telemetry fornisce un supporto iniziale agli amministratori in modo che possono interrogare il cloud per capire meglio come il sistema sta funzionando e come il sistema deve essere utilizzato OpenStack Compute ( Nova ) Il servizio OpenStack Compute è la parte principale di un sistema IaaS, usato per ospitare e gestire un sistema di cloud computing. In particolare gestisce il ciclo di vita delle istanze delle risorse virtuali nell ambiente OpenStack. Tra le principali responsabilità troviamo la creazione, schedulazione e distruzione delle macchine su richiesta. La virtualizzazione è alla base dei servizi offerti da OpenStack Compute, configurando i driver che interagiscono con i meccanismi di virtualizzazione del sistema operativo che gira sul particolare host e utilizzando le API per interagire con gli hypervisor. Esempi di hypervisor supportati sono: KVM, Xen-based e VMware. 20

21 Tra i principali componenti troviamo: nova-api: intercetta e risponde alle chiamate API dell utente. Supporta l'api OpenStack Compute, l'api di Amazon EC2, e una speciale API Admin per gli utenti privilegiati che permette di eseguire azioni amministrative. nova-compute: crea e termina le istanze di macchine virtuali comunicando, tramite delle API, con l hypervisor ( per esempio XenAPI per XenServer/XCP, libvirt per KVM or QEMU, VMwareAPI per VMware). nova-scheduler: prende una richiesta di istanza di macchina virtuale dalla coda determinando a quale server fisico assegnare l istanza. nova-conductor: gestisce le interazioni tra nova-compute e il database, per evitare gli accessi diretti al database da parte del nova-compute. nova-network: molto simile al nova-compute estrae le attività di networking dalla coda, svolgendo funzioni per manipolare la rete. queue: componente centrale per lo scambio di messaggi, di solito è implementata con RabbitMQ, ma potrebbe essere implementata da qualsiasi altro sistema di messaggistica che implementa AMPQ 6, come Apache Qpid or Zero MQ. Sql-database: mantiene i tipi di istanze che sono disponibili per l uso, l istanze in uso nonché reti e progetti disponibili. Tra i database ampiamente utilizzati vi sono: sqlite3, MySQL e PostgreSQL OpenStack Networking ( Neutron ) OpenStack Networking permette di gestire la rete come un servizio(network as a Service) tra le varie interfacce dei dispositivi, interagendo con gli altri servizi di OpenStack, di solito Openstack Compute. Fornisce delle API agli utenti per creare le interfacce di rete e collegarsi alla stesse. Openstack Networking è altamente configurabile grazie alla sua architettura plug-in che 6 AMPQ: acronimo di Advanced Message Queuing Protocol è un protocollo standard di rete orientato allo scambio di messaggi. 21

22 permette di ospitare diversi software e apparecchiature di rete, di conseguenza l architettura e l implementazione variano dinamicamente. Tale componente sarà oggetto di studio nel prossimo capitolo OpenStack Object Storage ( Swift ) Si tratta di un sistema di storage a lungo termine per memorizzare petabyte di dati che possono essere recuperati e aggiornati, tramite delle API. Risulta altamente fault tolerant grazie alla sua architettura altamente distribuita che permette la ridondanza dei dati e una maggiore scalabilità. Gli oggetti sono scritti su hardware multipli e il software si occupa della replicazione e dell integrità dei dati, in particolare OpenStack Object Storage esegue la manutenzione dei dati attraverso un certo numero di processi. Tra i principali componenti vi sono: swift-proxy-server: intercetta le richieste, tramite le OpenStack Object API oppure attraverso il protocollo HTTP, per caricare file, modificare i metadati o creare contenitori( liste di oggetti). Per migliorare le prestazioni può opzionalmente usare una cache (memcache). swift-account-server: gestisce gli account definiti all interno del servizio di OpenStack Object Storage, in particolare ogni account viene salvato all interno di un database sql è ad esso viene associato la lista di contenitori per quell account. swift-container-server: simile all account server, gestisce i contenitori all interno del servizio OpenStack Object Storage, in particolare tiene traccia di quali oggetti appartengono al contenitore salvando queste informazioni nel database. swift-object-server: si occupa di gestire gli oggetti reali, come i file, sul particolare nodo di storage (ad esempio l esecuzione dell operazione di modifica) OpenStack Block Storage (code-name Cinder) OpenStack Block storage, inizialmente componente di Nova chiamato nova-volume, 22

23 fornisce lo storage di volumi persistenti per le istanze di macchine in esecuzione. Presenta un architettura pluggabile, che facilita la creazione e la gestione dei dispositivi. L implementazione del servizio di default è una soluzione iscsi 7 che utilizza LVM 8 di linux. OpenStack Block Storage implementa multiple-storage back end, introdotta nella release Grizzly, consente la creazione di diverse soluzioni di storage che servono la stessa configurazione Openstack Compute, in sostanza si istanzia un cinder-volume per ogni backend. Una novità introdotta nella release Havana è la funzione Migrate volume che introduce di migrare volume tra i back-end, ovvero si crea un volume di storage e si copia in maniera trasparente i dati dall originale al nuovo. Tra i componenti principali troviamo: cinder-api: accetta le richieste API dell utente e le invia al cinder-volume. cinder-volume: elabora le richieste di scrittura o lettura di volumi di storage interagendo con altri processi (es. cinder-scheduler) attraverso una coda di messaggi. cinder-scheduler: come nova-scheduler, sceglie il miglior nodo al su cui creare il volume di storage. Tra le varie piattaforme di storage supportate troviamo: Ceph, NetApp, Nexenta, SolidFire, e Zadara OpenStack Identity ( Keystone ) OpenStack Identity Service fornisce un servizio di autenticazione e autorizzazione agli altri servizi di OpenStack e può integrarsi con i servizi di directory back-end esistenti, come LDAP 9. 7 iscsi: acronimo di Internet Small Computer System Interface è un protocollo che permette di inviare comandi a dispositivi di memoria SCSI fisicamente collegati a server e/o altri dispositivi remoti 8 LVM: acronimo logical volume manager gestisce i dispositivi di archiviazione di massa in Linux 9 LDAP: acronimo di Lightweight Directory Access Protocol è un protocollo standard per l'interrogazione e la modifica dei servizi di directory come un elenco aziendale di o una rubrica telefonica o più in generale qualsiasi raggruppamento di informazioni che può essere espresso come record di dati ed organizzato in modo gerarchico. 23

24 Tale servizio svolge due funzioni principali: Gestione degli utenti: tiene traccia degli utenti e delle autorizzazioni associate agli stessi, ovvero quali tipi di operazioni possono compiere. Gestione dei servizi: offre un catalogo dei servizi, disponibili attraverso gli endpoint. Basandosi sui seguenti componenti: User: rappresentazione digitale di un utente, un sistema o un servizio che utilizza un servizio. Credentials: dati utilizzati dall utente per autenticarsi (username e password, username e API key, token di autenticazione fornito da OpenStack Identity Service). Authentication: l atto di verifica dell identità di un utente. OpenStack Identity Service conferma la richiesta in arrivo, convalidando le credenziali fornite dall utente. In risposta a queste credenziali, OpenStack Identity Service emette un token di autenticazione per l'utente, che l'utente fornisce in richieste successive. Token: una stringa alfanumerica arbitraria che viene utilizzata dall utente per accedere alle risorse di cui può disporre. Il token può essere revocato in qualsiasi momento e ha una durata limitata. Tenant: collezione di risorse condivise tra utenti di un medesimo gruppo progetto o organizzazione. Service: rappresenta un servizio di OpenStack, come OpeStack Compute (Nova), OpeStack Object Storage (Swift), oppure OpeStack Image Service (Glance), fornendo uno o più endpoint attraverso il quale l utente può accedere alle risorse e effettuare le operazioni. Endpoint: Un indirizzo di rete accessibile, di solito descritto da un URL, da cui si accede a un servizio. Role: proprietà assunta da un utente che serve a definire le operazioni che esso può svolgere e i servizi che può richiedere. Un ruolo quindi comprende un insieme di diritti e privilegi, questi ultimi vengono ereditati dagli utenti che assumono quel 24

25 ruolo. Un utente può assumere diversi ruoli in differenti tenants nonché assumere molteplici ruoli all interno di uno stesso tenant OpenStack Image Service ( Glance ) OpeStack Image Service fornisce agli utenti servizi di ricerca, recupero e registrazione delle immagini delle macchine virtuali. Il servizio comprende API che permette all'utente di interrogare metadati dell'immagine e recuperare l'immagine attraverso un interfaccia di tipo REST 10. Tra le principali novità introdotte nella release Havana vi è, sia la possibilità di memorizzare le immagini in locazioni multiple favorendo, un consumo efficiente dell immagini e la possibilità di usare immagini di backup, sia la possibilità di associare delle proprietà alle immagini, che possono essere di due tipi: Core Properties (specificate all interno dell image schema), Meta Properties(coppie arbitrarie chiave/valore che sono associate all immagini), limitando gli utenti che possono effettuare operazioni CRUD sulle immagini in base al ruolo che essi assumono. La prima delle precedenti funzionalità è chiamata Multiple Image, mentre la seconda Property Protections. Le immagini delle VMs, che possono essere di vari formarti(es. Raw, VHD, OVF, VMDK) possono essere memorizzati su diversi sistemi di memorizzazione tra cui: File-system: archivia, cancella e recupera immagini dalla directory di un file-system specificato nel file di configurazione. S3: elimina o recupera le immagini utilizzando il sistema di storage proprio di Amazon Web Services (AWS). HTTP: recupera le immagini attraverso il protocollo HTTP, tratta le immagini in sola lettura. Swift: utilizza il servizio Openstack Object storage per la memorizzazione e il 10 REST: acronimo di Representational State Transfer si riferisce ad un insieme di principi di architetture di rete, i quali delineano come le risorse sono definite e indirizzate. 25

26 recupero delle immagini. Sheepdog(introdotto nella nuova realese): le immagini vengono memorizzate utilizzando il sistema di storage distribuito Sheepdog. Cinder (introdotto nella nuova realese): Openstack Cinder può essere usato come block-storage dall Image Service. GridFS( introdotto nella nuova realese): utilizza il file system distribuito di GridFS per lo storage delle immagini. Tra i principali componenti vi sono: glance-api: accetta le richieste API e collabora con gli altri componenti per caricare, recuperare, ricercare o eliminare le immagini. glance-registry: archivia e recupera i metadati relativi alle immagini dal database (i più usati sono: MySQL or SQlite). store-adapter: slega la richiesta dal particolare store, per poter interagire con diversi sitemi di storage OpenStack Telemetry ( Ceilometer ) OpenStack Telemetry, introdotto nella release Havana, è un servizio che tiene traccia di ciò che sta succedendo nel cluster OpenStack, valutando i dati di utilizzo e le prestazioni di tutti i servizi distribuiti in OpenStack. Quindi questa potente funzionalità offre visibilità e comprensione sull uso del cloud, consentendo agli operatori di visualizzare le metriche a livello globale o a livello delle singole risorse impiegate. I dati possono essere raccolti attraverso le notifiche inviate dai servizi o attraverso un meccanismo di polling. Inoltre il servizio permette la configurazione dei tipi per i dati raccolti in modo da soddisfare le varie esigenze operative. OpenStack Telemetry si basa principalmente sullo scambio di messaggi trasmessi tra i vari componenti, attraverso il bus di messaggistica standard di OpenStack, tra i principali vi sono quelli di notifica e quelli di misurazione dei dati. Tra i principali componenti vi sono: 26

27 ceilometer-agent-compute: funziona su ogni nodo di calcolo ed effettua sondaggi per ricavare le statistiche di utilizzo delle risorse relative alle istanze. ceilometer-agent-central: eseguito su un server di gestione centrale, effettua statistiche sull utilizzo delle risorse che non sono visibili,ovvero non sono legate a istanze. ceilometer-collector: gira su uno o più server di gestione centrale per monitorare le code di messaggi, i messaggi di notifica vengono elaborati e trasformati in messaggi di misura, tali messaggi vengono poi salvati nell archivio di OpenStack Telemetry. ceilometer-alarm-notifier: eseguito su uno o più server di gestione centrale consente di settare allarmi sulla base di una soglia stabilita su insieme di campioni, ceilometer-api: un server API che consente l accesso all archivio per accedere ai dati. archivio dati: un database capace di, gestire scritture contemporanee da uno o più istanze del collettore e leggere i dati dal server API OpenStack Orchestration ( Heat ) Il servizio OpenStack Orchestration, servizio introdotto nella release Havana, offre un orchestrazione template-based agli sviluppatori di applicazioni per descrivere e automatizzare l implementazione di infrastrutture. I modelli consentono di creare la maggior parte dei tipi di risorse di OpenStack come istanze, floating IP, volumi, utenti e cosi via; quindi permette di specificare le configurazioni di elaborazione, storage e di rete, nonché attività di post-distribuzione per automatizzare il provisioning completo di infrastrutture. In particolare tale servizio orchestra molteplici applicazioni utilizzando il formato nativo HOT(Heat Orchestration Template), oppure utilizzando il template di AWS CloudFormation. Inoltre, attraverso l integrazione con altri servizi, si possono ottenere funzionalità più avanzate; per esempio attraverso l integrazione con OpenStack Telemetry si può effettuare 27

28 l auto-scaling di alcuni elementi infrastrutturali. Tra i principali componenti vi sono: heat-command-line: un interfaccia a riga di comando (CLI) che comunica con l heat-api per eseguire le API AWS CloudFormation. Bisogna ricordare che per usare tale servizio si può interagire direttamente tramite le API REST. heat-api: elabora le richieste API inviandole all heat-engine mediante una RPC. heat-api-cfn: fornisce un AWS Query API che è compatibile con AWS CloudFormation ed elabora le richieste API inviandole all heat-engine mediante una RPC. heat-engine: fornisce gli eventi richiesti dagli utenti se si verifica una chiamata API e orchestra il lancio dei modelli.. 28

29 Capitolo 3 Gestione della rete Uno degli aspetti più importanti del progetto OpenStack riguarda la gestione della rete, che è diventato uno dei principali oggetti di studio nelle ultime release. Originariamente la gestione della rete era affidata al servizio Openstack Compute, in particolare al componente nova-network; tuttavia tale modo di gestire la rete risulta troppo limitativo in quanto non permette una configurazione dinamica e personalizzabile della rete da parte dell utente e non vi è possibilità di includere all interno del componente Nova le nuove tecnologie emergenti(sdn,qos). Per ovviare a tale limitazioni nella release Folsom si è introdotto il progetto Quantum, rinominato Neutron nell ultima release Havana, che permette di gestire la rete offrendola come un servizio quindi implementando il cosiddetto NaaS (network as a Service), offrendo un architettura basata sul concetto di plug-in che permette di interfacciarsi con tecnologie già esistenti e con quelle future. 3.1 Nova-Network Nova-network permette di gestire la rete estraendo dalla coda le attività richieste, fornendo reti virtuali per consentire ai nodi di interagire tra loro e con la rete pubblica. In particolare per ogni istanza di macchina virtuale creata OpenStack Compute assegna un indirizzo IP privato e il componente nova-network fornisce loro connettività. Attualmente Compute con nova-network supporta solo Linux Bridge, per connettere le 29

30 interfacce virtuali alla rete esterna attraverso le interfacce fisiche. Un importante distinzione fornita all interno del servizio OpenStack Compute riguarda gli indirizzi che vengono assegnati alle istanze di macchine virtuali, in particolare si parla di : fixed IPs: sono indirizzi assegnati all atto della creazione dell istanza, tale indirizzo rimane lo stesso fin quando l istanza non viene esplicitamente terminata. floating IPs: sono indirizzi che vengono associati dinamicamente alle istanze, quindi possono essere disassociati da un istanza e associati ad un'altra in qualsiasi momento. Nova-network supporta tre tipologie di configurazioni di rete, realizzate in diversi tipi di Network manager : Flat Network Manager Flat DHCP Network Manager VLAN Network Manager Tutti e tre tipi di network manager configurano la rete utilizzando i driver di rete (per esempio il driver Linux L3 che si avvale di iptables, route e altri servizi di gestione della rete). I driver non sono legati alla particolare tipologia di configurazione, bensì vengono utilizzati gli stessi driver per qualsiasi tipologia di configurazione. Inoltre essi, la maggior parte delle volte, vengono inizializzati(creano bridges e cosi via) solo quando si istanzia la prima VM sul particolare nodo. Un altro aspetto importante che vale per tutte le tipologie di configurazioni di rete riguarda la modalità con la quale esse operano, in particolare vi sono due modalità: Single Host: un singolo servizio nova-network fornisce un default gateway per le macchine virtuali e ospita un singolo DHCP server (dnsmasq). Multiple Host: ogni nodo compute gestisce un proprio servizio nova-network, ogni nodo, quindi, potrà comportarsi da NAT, gestire un proprio server DHCP in 30

31 maniera autonoma e comportarsi da gateway per la rete pubblica per tutte le macchine che ospita Flat Network Il tipo di configurazione Flat fornisce un set primitivo di operazioni, il suo ruolo si riduce nel collegare l istanza al bridge (tipicamente chiamato br100), precisamente in questa modalità tutte le istanze sono collegate allo stesso bridge che viene configurato manualmente dall amministratore di rete. Alle istanze di macchine virtuali viene assegnato un indirizzo IP fixed preso da un pool di indirizzi disponibili per la subnet specificata dall amministratore di rete. FlatNetworking utilizza interfacce ethernet configurate come bridge per consentire il traffico della rete tra i vari nodi, in particolare esistono due modalità quali: single adapters oppure multiple adapters. Il più semplice e comune modello di installazione è il cosidetto All-in-one dove si utilizza una modalità single node in cui è presente un unica interfaccia di rete. Fig. 3.1 Modello All-in-one Ad esso si affianca un ulteriore scenario che riguarda il caso in cui vi è sempre un'unica interfaccia ma si utilizza una modalità multi node. 31

32 In questa scenario se un macchina virtuale invia traffico verso la rete pubblica, lo invia prima al suo gateway predefinito, dopodiché l host su cui è configurato nova-network agisce come router inviando il traffico verso internet, tutto ciò funziona a patto che venga settata la modalità promiscua a causa dell unica interfaccia presente. Fig. 3.2 Multiple nodes whit a single adapters Il caso più comune e quello raccomandato da OpenStack è quello in cui si ha una modalità multi-node in cui sono presenti almeno due interfacce, dedicando un interfaccia al bridge e l altra dedicandola al traffico di managment della rete. In questo scenario se una macchina virtuale invia traffico destinato alla rete pubblica, lo invia prima al nodo su cui è configurato nova-network che agirà come router inviando il traffico sulla seconda interfaccia che è stata configurata appositamente. Fig. 3.3 Multiple nodes and multiple adapters 32

33 3.1.2 FlatDHCP Network Come il modello di configurazione Flat Network, anche il modello Flat DHCP collega le istanze tutte allo stesso bridge, assegnando loro un indirizzo IP preso dal pool di indirizzi della subnet configurata dall amministratore di rete, con la differenza che tale indirizzo viene assegnato alle istanze tramite la procedura DHCPDISCOVER inviata al dhcp locale. Quando si utilizza la modalità multi-host, ad ogni compute node viene fornito un indirizzo IP privato dal pool di indirizzi, dopodiché viene lanciato un server DHCP (dnsmasq), che si mette in ascolto sul bridge, che a sua volta lavorerà come gateway di dafault per tutte le istanze in esecuzione su quel nodo. Una delle particolari differenze da non trascurare riguarda la modalità che si utilizza in quanto se si utilizza una modalità multi-host si ha la necessità di assegnare un indirizzo diverso al bridge per ogni nodo, nel caso contrario ciò non è necessario. Per garantire lo stesso indirizzo IP alle istanze nel tempo, FlatDHCPManager crea un file statico in cui inserisce tutti i vari lease per ogni nodo, basandosi sui dati delle varie istanze(mac,ip, NOME-HOST) che si trovano all interno del database di Nova. Fig. 3.4 Modalità FlatDHCP Network in modalità multi-host 33

34 3.1.3 Vlan Network La gestione della rete secondo le due modalità precedentemente discusse presenta delle limitazioni, in quanto il pool di indirizzi è condiviso tra i vari tenant e inoltre tutte le istanze condividono un singolo dominio di broadcast di livello 2 della pila ISO/OSI. Per risolvere tale problematiche si può utilizzare la modalità VLAN Network, che risulta il modalità di default per Openstack Compute. In questo modello il Compute crea una VLAN e un bridge per ogni progetto, quest ultimo ottiene un intervallo di indirizzi privati che sono accessibili solo all interno della VLAN. Per permettere agli utenti di accedere alle istanze del proprio progetto si deve creare una speciale istanza di VPN chiamata cloudpipe, dopodiché sarà compito di OpenStack Compute generare un certificato e una chiave per l accesso alla VPN, fornendo un segmento di rete privata per ciascun istanza del progetto, a cui si può accedere tramite una connessione VPN dedicata alla connessione ad Internet. Con il modello di configurazione VLAN Network un server DHCP viene avviato per ogni VLAN assegnando alle istanze di macchine virtuali gli indirizzi presi tra quelli disponibili all interno della sottorete. Queste ultime vengono specificate dall amministratore di rete e assegnate dinamicamente ad un progetto quando richiesto. Una condizione molto importante per questo tipo di modalità riguarda, gli switch di rete che devono supportare il VLAN tagging (802.1Q), che consente ai dispositivi di condividere lo stesso dominio di broadcast di livello 2 solo nel caso in cui le frame che trasmettono contengono lo stesso Vlan ID (VID), quest ultimo viene inserito con ulteriori 4 byte nelle frame ethernet. In conclusione possiamo affermare che il modello VLAN Network è un ottimo modello per la gestione della rete in quanto fornisce un ottima scalabilità di livello 2 e l isolamento tra i vari tenant, tuttavia anch esso soffre di alcune problematiche. Per esempio non è possibile avere due differenti tenant in due differenti domini di broadcast di livello 2 che usano lo stesso schema di indirizzamento; un ulteriore problematica riguarda la dimensione del campo VID in quanto essendo 4 byte si possono avere al massimo 4096 VLAN e ciò può essere un problema per sistemi cloud di grandi dimensioni. 34

35 Fig. 3.4 Modalità Vlan Network 3.2 Openstack Networking( Neutron ) OpenStack Networking, il cui progetto prende il nome di Neutron (ex Quantum), fornisce agli operatori la possibilità di sfruttare tecnologie di rete differenti per gestire la propria rete all interno del cloud. In particolare OpenStack Networking è un servizio di rete virtuale che fornisce delle API per definire la connettività della rete e l indirizzamento IP nel cloud che viene usato dagli altri servizi di Openstack, come Openstack Compute Componenti Per descrivere le risorse di rete le API di Openstack Networking si basano su un modello semplice costituito dai seguenti componenti: Network: dominio di rete isolata di livello 2, strettamente analogo alla VLAN nel dominio delle reti fisiche. Più specificamente è un dominio di broadcast riservato al tenant che l ha creato oppure può essere condiviso se esplicitamente configurato. Esso rappresenta l elemento fondamentale per il modello in quanto sia i port che le subnet sono assegnate ad una specifica network. 35

36 Subnet: è un blocco di indirizzi IP di versione 4 o 6 con uno stato di configurazione associato. In pratica si tratta di un pool di indirizzi da cui OpenStack è in grado di assegnare gli indirizzi IP alle macchine virtuali. Ogni subnet è associata ad una rete ed è specificata da un Classless Inter-Domain Routing (CIDR). Un tenant può opzionalmente configurare per una particolare subnet, un gatway, la lista di name sever (DNS); le istanze di macchine virtuali su questa subnet erediteranno automaticamente la configurazione. Port: è un punto di connessione per collegare un singolo dispositivo, come la Network Interface Controller (NIC) di un server virtuale ad una rete virtuale. Un istanza di macchina virtuale può collegare un adattatore di rete ad una rete virtuale attraverso un port. Quando un port viene creato esso riceve un indirizzo IP fixed di una delle subnet disegnate, in particolare tale indirizzo può essere uno specifico indirizzo presente nel pool assegnato dall utente su richiesta, oppure un indirizzo disponibile assegnato da Neutron. Oltre ad assegnare indirizzi IP al particolare port, OpenStack permette anche di assegnare uno specifico indirizzo MAC. Grazie a questo modello quindi è possibile configurare ricche topologie di reti attraverso la creazione di networks e subnets, permettendo agli altri servizi di OpenStack di interagire con esse, per esempio il collegamento di dispositivi virtuali alle porte di una specifica rete svolto dal servizio Openstack Compute. OpenStack Networking inoltre fornisce ad ogni tenant la possibilità di avere più reti private e di far scegliere agli stessi tenant lo schema di indirizzamento IP consentendo la sovrapposizione con quelli usati dagli altri tenant presenti nel sistema. Così facendo OpenStack Networking consente l utilizzo del cloud networking in casi d uso avanzati come la costruzione di applicazioni web multi-tiered oppure di eseguire la migrazione di VM, senza cambiare indirizzo IP, da una rete a un altra. 36

37 3.2.2 Plug-in L'API Neutron espone l'interfaccia del servizio di rete virtuale per gli utenti e altri servizi, ma l'effettiva implementazione di tali servizi di rete risiede in un plug-in che fornisce isolate reti virtuali ai tenants e altri servizi come la gestione degli indirizzi. OpenStack Networking introduce il concetto di un plug-in, che è una implementazione back-end della API OpenStack Networking. Un plug-in può utilizzare una varietà di tecnologie per attuare le richieste API. Alcuni plug-in di Openstack Networking possono utilizzare i concetti usati nel modello di gestione di rete attraverso il servizio OpenStack Compute (VLANS,e IP tables), tuttavia questi sono in genere sufficienti per le reti piccole e semplici, ma non per casi d uso più avanzati, quindi ad essi si affiancheranno altri plug-in che fanno uso di tecnologie più avanzate quali L2-in-L3 tunneling o OpenFlow. L'architettura plug-in quindi offre una grande flessibilità di personalizzare le funzionalità della rete all amministratore del cloud. I plug-in possono avere proprietà differenti per requisiti hardware, caratteristiche, prestazioni o dimensioni, quindi grazie alla grande quantità di plug-in offerti, l amministratore del cloud può valutare tra le varie opzioni per decidere la giusta tecnologia di rete. Nell ultima release Havana è stato introdotto un nuovo plug-in ML2, acronimo di modular layer 2 è un framework che permette ad OpenStack Networking di utilizzare contemporaneamente la varietà di tecnologie di rete di livello 2 che si trovano in complessi data centers del mondo reale. Attualmente collabora con gli esistenti gli agenti di livello 2 di Open vswitch, Linux Bridge, e Hyper-v, ed è destinato a deprecare e sostituire i plug-in monolitici associati a tali agenti. Infatti dalla prossima release Icehouse Open vswitch, Linux Bridge verranno rimossi in quanto essi faranno parte di ML2 sottoforma di meccanismi driver. ML2 plug-in quindi è destinato a semplificare notevolmente l aggiunta di un supporto per le nuove tecnologie di livello 2, richiedendo meno sforzo iniziale e continuo di quanto sarebbe necessario per aggiungere un nuovo plug-in monolitico. 37

38 In Fig.3.5 si possono notare tutti l insieme dei plug-in attualmente utilizzabili in Neutron con la relativa compatibilità ai driver di Compute. Fig. 3.5 Plug-in supportati con relative compatibilità Architettura Come gli altri servizi di OpenStack anche OpenStack Networking spesso si avvale di diversi processi distribuiti su una vari host. Il processo principale di OpenStack Networking è neutron-server, un demone scritto in Pyton che espone le OpenStack Networking API e passa le richieste degli utenti al plug-in configurato, per ulteriori elaborazioni. Oltre al processo principale OpeStack Networking prevede agenti aggiuntivi quali: plug-in agent (neutron-*-agent): esegue su ogni hypervisor per la configurazione locale degli switch virtuali, l agente che viene eseguito dipende dal plug-in che si utilizza, inoltre alcuni plug-in non richiedono alcun agente. dhcp agent (neutron-dhcp-agent): fornisce servizi DHCP. l3 agent (neutron-l3-agent): fornisce l instradamento L3/NAT per fornire l accesso alla rete esterna alle macchine virtuali. 38

39 l3 metering agent (neutron-metering-agent): fornisce le misurazioni del traffico di livello 3. Questi agenti interagiscono con il processo principale (neutron-server) attraverso la coda di messaggi per esempio RabbitMQ o Qpid, oppure attraverso le standard API Networking. Inoltre questo servizio consente agli amministratori del cloud di eseguire uno o più servizi su uno o più dispositivi fisici. Quindi l amministratore del cloud può eseguire tutti i demoni di servizio su un singolo host per una fase di valutazione, in alternativa però l amministratore può eseguire ogni servizio su un proprio host fisico e in alcuni casi può replicare i servizi tra più host per effettuare ridondanza. Un architettura standard include un cloud controller host, un network gateway host e una serie di hypervisor che eseguono le macchine virtuali. Il cloud controller e il network gateway possono essere sullo stesso host, tuttavia se si vuole evitare la contesa della CPU da parte di neutron-l3-agent e gli altri servizi di OpenStack che inoltrano i pacchetti quando utilizzano macchine virtuali per inviare traffico per/da Internet, viene utilizzato un network gateway dedicato. Per implementare un architettura del genere OpenStack Networking offe più reti quali : Management network: fornisce una comunicazione interna tra i componenti di OpenStack. Gli indirizzi IP all interno su questa rete sono raggiungibili solo all interno del data center. Data network: fornisce una connettività tra le varie istanze di macchine virtuali, consentendo uno scambio di dati tra esse. I requisiti sugli indirizzi IP in questa rete dipendono dal plug-in utilizzato. External network: fornisce alle macchine virtuali una connettività ad internet. In questa rete chiunque su Internet può raggiungere gli indirizzi IP. 39

40 API network: fornisce ai tenant tutte le API OpenStack, tra cui l API Networking. Gli indirizzi IP su questa rete sono raggiungibili da chiunque su Internet. Fig. 3.6 Connetività di rete per gli host fisici Casi d uso Tra i principali scenari di OpenStack Networking vi sono: Single Flat Network: Rappresenta il caso più semplice di utilizzo, in cui vi è una sola subnet per tutti i tenant, detta Shared Network, visibile attraverso le API Networking. In particolare le macchine virtuali hanno una sola interfaccia di rete e ricevono un indirizzo IP fixed dalla subnet associata a quella rete. Praticamente si mappano i modelli FlatManager e FlatDHCPManager forniti da Openstack Compute. Tale scenario è anche conosciuto come provider network, poichè si mappa la shared network su una rete fisica già esistente, consentendo di raggiungere il mondo esterno alle macchine virtuali utilizzando un ruoter fisico come gateway. 40

41 Fig. 3.7 Single Flat Network Multiple Flat Network: Questo caso di utilizzo è molto simile al precedente (Single Flat Network), con la differenza che vi sono più shared network per i tenant visibili attraverso le API Networking, e ogni tenant può scegliere una o più shared network da utilizzare. Fig. 3.8 Multiple Flat Network 41

42 Mixed Flat and Private Network: In questo caso d uso vi sono una o più shared network per tutti i tenant, in cui questi ultimi hanno la possibilità di definire una rete virtuale privata ad uso esclusivo. Inoltre in tale scenario le macchine virtuali possono avere più interfacce su una qualsiasi delle shared network e/o una qualsiasi rete privata. Ciò consente la creazione di topologie mult-tier e inoltre permette di fornire servizi quali NAT o load balancer attraveso una macchina virtuale che agisce come gateway. Fig. 3.9 Mixed Flat and Private Network Provider Router with Private Networks : Questo caso d uso permette ad ogni tenant di collegarsi con le loro reti private al mondo esterno attraverso un router creato e gestito dall amministratore. Al router viene assegnato un indirizzo IP che verrà utilizzato come gateway_ip per la subnet external network, quindi un default router per il traffico Internet. Il router fornisce connettività di livello 3 tra le reti private, il che significa che si possono mettere in comunicazione le VM di tenants differenti. Inoltre poiché vi è un solo router in questo caso d uso non vi è possibilità di utilizzare IP sovrapposti. 42

43 Fig Provider Router with Private Networks Per-tenant Routers with Private Networks: Uno scenario più avanzato in cui ogni tenant riceve almeno un router a cui si associa un uplink e un floating IP presi dalla External Network, e può crearne altri accedendo alle API Networking. L accesso alla rete esterna avviene mediante SNAT o IP floating, inoltre poiché ci sono più router, più subnet possono essere sovrapposte senza entrare in conflitto ovvero è possibile l overlap degli indirizzi IP. Con tale scenario è possibile definire applicazioni multi-tier separando i livelli di rete tramite i routers. Fig Per-tenant Routers with Private Networks 43

44 3.2.5 Namespaces Uno dei concetti fondamentali in Openstack Networking è il concetto di namespaces, in quanto esso si pongono come una delle migliori soluzioni per la sicurezza per ogni tenant all interno della rete. Infatti con i namspaces il traffico di rete e le varie interfacce sono completamente isolate tra i vari tenants come si può notare dalla Fig Fig Namespaces Uno dei principali vantaggi offerti dai namespaces è quello di poter creare indirizzi IP sovrapposti, fornendo così all utente piena libertà, creando subnet senza alcun timore che si può verificare un conflitto. Se il Kernel non supporta i namespaces si avranno le seguenti limitazioni in Neutron: Neutron-l3-agent è limitato a fornire un unico router virtuale per ogni compute node. Per ogni neutron-l3-agent è necessario configurare Universally Unique ID (UUID) che identifica univocamente l istanza di router che ospita. Ciò rende impraticabile la configurazione self-service. neutron-l3-agent and neutron-dhcp-agent devono essere eseguiti su host diversi in quanto non vi è alcun isolamento tra gli indirizzi IP creati dai due agenti. Quindi un utente manipolando le tabelle di routing può avere accesso ad un'altra rete. 44

45 3.2.6 FWaaS Uno dei principali servizi introdotti nella release Havana è FWaaS, acronimo di firewallas-a-service, che consente la creazione di una o più istanze logiche di firewall ai tenants. Il firewall logico non è altro che un istanza del modello Firewall Policy ovvero un modello in cui vi è un elenco ordinato di regole firewall e può essere creato sia dai tenants sia dagli amministratori. Quindi quando si creano delle regole firewall esse non vengono applicate direttamente al firewall virtuale, ma vengono aggiunte al Firewall Policy, dopodiché il Firewall Policy riapplica tali regole per avere effetto. Questo processo in due fasi consente di effettuare controllare il Firewall Policy dopo che le regole sono state inserite e prima che esse vengono applicate. Fig Relazioni tra le varie entità Grazie a tale servizio è possibile definire zone di sicurezza, ovvero un insieme di risorse che sono soggette ad una stessa serie di regole firewall(es. definire le regole di accesso per un singolo nodo di destinazione). Quindi un aggiunta o una modifica di una regola in una zona di sicurezza, provoca la modifica su tutti i nodi e firewall nella zona. Un tipico scenario in cui risulta utile definire zone di sicurezza può essere un data center multiple tenants, definendo l accessibilità attraverso un insieme di regole, ovvero attraverso il firewall esterno o perimetrale si stabilisce chi da fuori può raggiungere i tenants. Un possibile modello di funzionamento è rappresentato in Figura

46 Fig Modello FWaaS Il FWaaS L3 Agent fornisce l interfaccia tra il plug-in e il Driver. L agente estrae le specifiche per il driver dal plug-in gestendo le seguenti API: create_firewall() update_firewall() delete_firewall() L agente processa queste richieste API, elaborando in primo luogo le informazioni richieste al Driver (es namespaces), dopodiché inizia la relativa azione del Driver. Una volta completata l azione il Driver restituisce il risultato, dopodiché l agente passa le informazioni sullo stato al Plug-in. 46

47 Conclusioni Dal lavoro svolto in questo elaborato si può notare quanto la rete rappresenti il principale fattore per il cloud computing, in quanto con essa si riesce ad abilitare l accesso ai vari servizi del cloud, garantendo flessibilità, scalabilità, dinamismo e sicurezza di accesso. In particolare si è visto la gestione della rete all interno della piattaforma OpenStack, presentando quello che è stato il primo e unico modo di gestirla per poi passare allo studio di quello che è stato una vera e propria rivoluzione per la gestione della rete, ovvero lo studio del servizio OpenStack Networking ( Neutron ). Dallo studio è emerso che le gestione attraverso il componente nova-network porta ad una serie di limitazioni, in quanto esso rappresenta un processo monolitico che rende complicato l inclusione delle ultime e avanzate tecnologie di rete. Dallo studio di OpenStack Networking ( Neutron ), si possono notare i componenti, l architettura e le varie funzionalità offerte, notando come l architettura a plug-in sia il vero punto di forza di tale servizio. Grazie a Neutron, nato come progetto sperimentale nella release Folsom, si possono eliminare le principali limitazioni presenti in nova-network. Nell attuale release Havana, OpenStack Networking è diventato parte fondamentale di OpenStack e dalla prossima release Icehouse si potrebbe assistere alla deprecazione del componente nova-network in favore di Neutron. 47

48 Bibliografia [1] - Wikipedia [2] - The NIST Definition of Cloud Computing [3] Cloud Computing Reference Architecture [4] Documentazione OpenStack [5] - OpenStack Release Havana Notes [6] - Networking in Openstack [7] - OpenStack Networking FlatManager and FlatDHCPManager [8] - OpenStack Networking FlatManager and FlatDHCPManager 48