Elaborato Polito Mariano N46001001

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. N46001001
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.
Indice
Introduzione
5
Capitolo 1. Cloud computing
7
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.4
1.4.1
1.4.2
1.4.3
1.4.4
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
8
9
11
11
12
13
13
14
15
15
16
16
16
Capitolo 2. OpenStack
2.1
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
2.2.9
17
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”)
18
20
21
21
22
23
23
24
26
27
28
Capitolo 3. Gestione della rete
3.1
30
Nova Network
30
III
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
Flat Network
FlatDHCP Network
Vlan Network
Openstack Networking( “Neutron”)
Componenti
Plug-in
Architettura
Casi d’uso
Namespaces
FWaaS
32
34
35
36
36
38
39
41
45
46
Conclusioni
Bibliografia
48
49
IV
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
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
Il cloud computing nasce per ridurre e contenere i costi dell’IT1 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”.
Fig. 1.1 Cloud Computing
1.1 Principali Caratteristiche
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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)
1.3.1 Software as a Service
Software as a Service (SaaS) è un modello di distribuzione del software in cui le
11
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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 ASP2. 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;
1.3.2 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
Esempi di questo modello sono: Google AppEngine, Microsoft Azure e Force.com.
1.3.3 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 virtualizzazione3.
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
firewalls4).
Esempi di questo modello sono: GoGrid,Felixscale,Joyent, Amazon's EC2, Eucalyptus,
OpenStack.
Fig.1.3 Modello SPI
1.3.4 Hardware as a Service
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
dopodiché i server/sistemi del fornitore di HaaS forniscono all’utente l’elaborazione di
tali dati.
Un esempio di modello HaaS: Lanchpad.
1.3.5 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
1.4.1 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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.
1.4.3 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.
1.4.4 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
Fig.2.1 Modello generale di OpenStack
2.1 Storia di OpenStack
OpenStasck è stato lanciato per la prima volta il 19 luglio 2010. 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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 2013.
In Fig. 2.2 si riportano tutte le release rilasciate negli anni.
18
Fig.2.2 Release di OpenStack
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
2.2.1OpenStack 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.
2.2.2OpenStack 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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 AMPQ6, 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.
2.2.3 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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.
2.2.4 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).
2.2.5OpenStack Block Storage (code-name Cinder)
OpenStack Block storage, inizialmente componente di Nova chiamato nova-volume,
22
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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 iSCSI7 che utilizza LVM8 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.
2.2.6OpenStack 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
LDAP9.
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 email 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
ruolo. Un utente può assumere diversi ruoli in differenti tenants nonché assumere
molteplici ruoli all’interno di uno stesso tenant .
2.2.7OpenStack 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 REST10.
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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.
2.2.8OpenStack 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
 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.
2.2.9OpenStack 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
maniera autonoma e comportarsi da gateway per la rete pubblica per tutte le
macchine che ospita.
3.1.1 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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.
3.2.1 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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à
3.2.3 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
 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
3.2.4 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
Fig. 3.10 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. 3.11 Per-tenant Routers with Private Networks
43
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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. 3.12.
Fig. 3.12 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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. 3.13 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 3.14
45
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
Fig. 3.14 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
Analisi del sistema di gestione di rete nella piattaforma di cloud computing OpenStack
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
Bibliografia
[1]
https://www.wikipedia.org - Wikipedia
[2]
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf - The NIST
Definition of Cloud Computing
[3]
http://www.hspi.it/files/Cloud%20Computing%20Reference%20Architecture.pdf –
Cloud Computing Reference Architecture
[4]
http://docs.openstack.org/admin-guide-cloud/content//ch_getting-started-with-
openstack.html – Documentazione OpenStack
[5]
https://wiki.openstack.org/wiki/ReleaseNotes/Havana - OpenStack Release Havana
Notes
[6]
http://docs.openstack.org/training-guides/content/module002-ch001-networking-in-
openstack.html - Networking in Openstack
[7]
http://www.mirantis.com/blog/openstack-networking-flatmanager-and-
flatdhcpmanager/ - OpenStack Networking – FlatManager and FlatDHCPManager
[8]
http://www.mirantis.com/blog/openstack-networking-vlanmanager/
-
OpenStack
Networking – FlatManager and FlatDHCPManager
48

Download Report