Facoltà di Ingegneria · III Indice Introduzione 5 Capitolo 1. Cloud computing 7 1.1 Principali...

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.

III

Indice

Introduzione 5

Capitolo 1. Cloud computing 7

1.1 Principali caratteristiche 8

1.2 Architettura e principali attori 9

1.3 Modelli di servizio 11

1.3.1 Software as a Service 11

1.3.2 Platform as a Service 12

1.3.3 Infrastructure as a Service 13

1.3.4 Hardware as a Service 13

1.3.5 Data as a Service 14

1.4 Modelli di distribuzione 15

1.4.1 Public Cloud 15

1.4.2 Private Cloud 16

1.4.3 Community Cloud 16

1.4.4 Hybrid Cloud 16

Capitolo 2. OpenStack 17

2.1 Storia di OpenStack 18

2.2 Progetti di OpenStack 20

2.2.1 OpenStack Dashboard (“ Horizon”) 21

2.2.2 OpenStack Compute ( “Nova”) 21

2.2.3 OpenStack Networking (“Neutron”) 22

2.2.4 OpenStack Object Storage (“Swift”) 23

2.2.5 OpenStack Block Storage (code-name Cinder) 23

2.2.6 OpenStack Identity (“Keystone”) 24

2.2.7 OpenStack Image Service (“Glance”) 26

2.2.8 OpenStack Telemetry (“Ceilometer”) 27

2.2.9 OpenStack Orchestration (“Heat”) 28

Capitolo 3. Gestione della rete 30

3.1 Nova Network 30

IV

3.1.1 Flat Network 32

3.1.2 FlatDHCP Network 34

3.1.3 Vlan Network 35

3.2 Openstack Networking( “Neutron”) 36

3.2.1 Componenti 36

3.2.2 Plug-in 38

3.2.3 Architettura 39

3.2.4 Casi d’uso 41

3.2.5 Namespaces 45

3.2.6 FWaaS 46

Conclusioni 48

Bibliografia 49

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

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.


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 on-

demand 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”


8

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”.

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.

Fig. 1.1 Cloud Computing


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-per-

use. 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,


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).


11

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

Fig.1.2 Principali attori del cloud computing


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 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.


13

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.

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.

Fig.1.3 Modello SPI


14

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-per-

use. 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.


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.

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.


16

Capitolo 2

OpenStack

OpenStack è un progetto di cloud computing open source, rilasciato sotto licenza Apache5,

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.


17

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ì

Fig.2.1 Modello generale di OpenStack


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 2013.

In Fig. 2.2 si riportano tutte le release rilasciate negli anni.

Fig.2.2 Release di OpenStack


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


20

2.2.1 OpenStack Dashboard (“ Horizon”)

OpenStack Dashboard fornisce agli amministratori e agli utenti un interfaccia grafica self-

service 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.2 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.


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 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.


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.

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.5 OpenStack Block Storage (code-name Cinder)

OpenStack Block storage, inizialmente componente di Nova chiamato nova-volume,


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 iSCSI7 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 back-

end. 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.6 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

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.


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


25

ruolo. Un utente può assumere diversi ruoli in differenti tenants nonché assumere

molteplici ruoli all’interno di uno stesso tenant .

2.2.7 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 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.


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.


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.8 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.



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.

2.2.9 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


28

l’auto-scaling di alcuni elementi infrastrutturali.


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.

.


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


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


31

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 .

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.

Fig. 3.1 Modello All-in-one


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.

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.2 Multiple nodes whit a single adapters

Fig. 3.3 Multiple nodes and multiple adapters


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


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.


35

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.

Fig. 3.4 Modalità Vlan Network


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.


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.


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.

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.

Fig. 3.5 Plug-in supportati con relative compatibilità


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.


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.

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.

Fig. 3.6 Connetività di rete per gli host fisici


41

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.7 Single Flat Network

Fig. 3.8 Multiple Flat Network


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.

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.

Fig. 3.9 Mixed Flat and Private Network


43

Fig. 3.11 Per-tenant Routers 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.10 Provider Router with Private Networks


44

Fig. 3.12 Namespaces

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.

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.


45

Fig. 3.13 Relazioni tra le varie entità

3.2.6 FWaaS

Uno dei principali servizi introdotti nella release Havana è FWaaS, acronimo di firewall-

as-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.

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


46

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.


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.

48

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

https://www.wikipedia.org/

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

http://www.hspi.it/files/Cloud%20Computing%20Reference%20Architecture.pdf

http://docs.openstack.org/admin-guide-cloud/content/ch_getting-started-with-openstack.html

http://docs.openstack.org/admin-guide-cloud/content/ch_getting-started-with-openstack.html

https://wiki.openstack.org/wiki/ReleaseNotes/Havana

http://docs.openstack.org/training-guides/content/module002-ch001-networking-in-openstack.html

http://docs.openstack.org/training-guides/content/module002-ch001-networking-in-openstack.html

http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/

http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/

http://www.mirantis.com/blog/openstack-networking-vlanmanager/

Facoltà di Ingegneria · III Indice Introduzione 5 Capitolo 1. Cloud computing 7 1.1 Principali...

Documents

Transcript of Facoltà di Ingegneria · III Indice Introduzione 5 Capitolo 1. Cloud computing 7 1.1 Principali...