UNIVERSITÀ DEGLI STUDI DI CATANIA DIPARTIMENTO DI MATEMATICA E INFORMATICA
Relazione Finale di Tirocinio A.A. 2015/2016
OpenStack e Neutron
Tutor didattico
Ing. Riccobene Salvatore
Sede Tirocinio
INFN – Istituto Nazionale di Fisica Nucleare
Tutor aziendale
Dott. Andronico Giuseppe
ALLIEVO:
Mergiotti Francesco
Matricola M01-000427
Sommario
1. Introduzione
2. Software Defined Network
3. OpenStack
3.1 Panoramica del framework
3.2 Project Name – Servizi
3.3 Struttura minimale OpenStack
3.4 Componenti – Nodi
4. Struttura e strumenti utilizzati
5. Caso d’uso
5.1 Implementazione del caso d’uso
5.1.1 Identity Service
5.1.2 Image Service
5.1.3 Compute Service
5.2 Networking - Neutron
5.2.1 Modul Layer 2 – ML2
5.2.2 Differenza tra VxLan e Gre
5.2.3 OpenVSwitch
5.3 Problematiche riscontrate
6. Conclusioni
1. Introduzione
Il tirocinio si è svolto all’interno della struttura degli INFN – Istituto Nazionale di Fisica
Nucleare Sezione Catania a stretto contatto col personale che lavora all’interno della
struttura.
Gli argomenti trattati durante il periodo di stage riguardano la progettazione e il sviluppo su
tecnologie in ambito Cloud Computing e riguardo il paradigma SDN – Software Defined
Network.
L’aspetto pratico dello stage riguarda l’installazione e la configurazione del framework
OpenStack. La release di riferimento è la Kilo. L’installazione e la successiva
configurazione ha portato dei problemi riguardanti il progetto Neutron all’interno della
release, che successivamente sono stati superati.
L’architettura di rete creata con OpenStack e gestita da Neutron, ha richiesto l’utilizzo di
protocolli L2 esterni al framework OpenStack: OpenVSwitch, ML2, GRE e VxLan.
Successivamente si è integrato il framework OpenDayLight con notevoli problemi di
comunicazione con la release Kilo.
2. Software Defined Network
Nell'architettura proposta dal paradigma SDN è importante come deve avvenire il controllo,
infatti esso deve essere disaccoppiato dall’hardware e posto in un controller software
logicamente centralizzato. Adottando questo tipo di controllo si elimina la presenza di
autonomous systems: i nodi della rete non decidono più in autonomia ma vengono controllati
da un’entità esterna.
Il piano di controllo, che contiene la funzione di instradamento, o routing, è disaccoppiato
dal piano di controllo dei dati, che invece rappresenta l’azione da compiere sul pacchetto in
arrivo. L'intelligenza della rete e lo stato della stessa sono centralizzate in un dispositivo
esterno (controller) e le strutture sottostanti al piano di trasporto vengono astratte dalle
applicazioni e dai servizi di rete.
Dal punto di vista funzionale, si identificano 3 livelli: l’infrastruttura di rete fisica, il piano di
controllo e le applicazioni.
Il controller comunica sia con le applicazioni che con l’infrastruttura di rete fisica tramite le
Northbound e le Southbound API.
Figura 1 Architettura SDN
3. OpenStack
3.1 Panoramica del framework
OpenStack è un progetto software open source, rilasciato sotto licenza Apache e gestito
dall’OpenStack Foundation, con lo scopo di fornire un’infrastruttura Cloud pubblica o
privata, altamente scalabile.
Figura 2 Struttura OpenStack - Release Kilo
Esso è nato come piattaforma software per l’amministrazione e la gestione di servizi IaaS
(Infrastructure-as-a-Service) in un contesto multi-tenant, inoltre dà la possibilità di gestire
un cluster di macchine fisiche che ospitano i server (denominati istances).
L’amministratore potrà quindi creare un’infrastruttura virtuale composta da istanze e
applicazioni di rete, come router, firewalls, WAN accelerator, ecc.
Le istances (server) possono essere implementati con tecnologie di virtualizzazione light
container, bare metal o high-performance computing (HPC).
KVM, VMWare, XenServer e Hyper-V sono scelte disponibili come HyperVisor.
OpenStack fornisce un’interfaccia utente via Web mediante una potente e flessibile
dashboard, che permette di controllare un cluster di hosting server eseguendo differenti
tipi di Hypervisors, di gestire lo storage e le infrastrutture virtuali di rete. La dashboard
permette inoltre ai client di istanziare velocemente e in modo trasparente risorse di
networking e computing mediante una infrastruttura virtuale di data center.
Parallelamente è possibile utilizzare anche la CLI (Command Line Interface), che permette
una maggiore libertà di sperimentazione e la possibilità di gestire ogni singolo dettaglio
dell'implementazione che verrà creata.
OpenStack ha un disegno architetturale aperto, modulare ed è programmato
principalmente in Python per una maggior flessibilità in fase di sviluppo e di
implementazione da parte degli sviluppatori.
Figura 3Panoramica erogazione dei servizi OpenStack
3.2 Project Name - Servizi
Gli attori principali hanno un codice (Project Name) che li identifica ed ognuno di essi, come
ho accennato in precedenza, svolge un ruolo ben specifico all’interno della configurazione
OpenStack.
Figura 4 Architettura Concettuale OpenStack
Ogni componente fornisce all’architettura di rete una serie di servizi inerenti al suo ruolo. La
lista che segue fornisce la descrizione di ogni progetto presente nella configurazione della
release Kilo:
• Dashboard – Horizon:
• Fornisce un’interfaccia web per poter interagire con i servizi di Openstack,
come la creazione di istanze, assegnamento di indirizzi IP e configurazione
del controllo di accesso.
Essa è utilizzabile per la gran parte di operazioni di base, ma non offre la
possibilità di eseguire in maniera esaustiva tutti i comandi disponibili da CLI.
• Compute Service – Nova
• L’architettura del servizio Compute è progettata per scalare orizzontalmente
su hardware standard senza particolari requisiti software o hardware vendor.
È stato progettato per gestire e automatizzare il pool di risorse del computer.
Utilizza un database (generalmente MySQL) per la memorizzazione degli
delle configurazioni e degli stati a run-time dell’infrastruttura, ad esempio quali
istanze sono attive, quali tipi di istanze sono in uso etc.
I servizi di Nova si suddividono in:
� nova-api: accetta e risponde alle richieste di computazione da parte
degli Utenti;
� nova-scheduler: prende in consegna una richiesta di creazione di una
macchina virtuale e determina su quale host fisico deve essere
eseguita;
� nova-compute: è il servizio principale che si occupa della creazione e
della terminazione delle istanze attraverso le API dell’Hypervisor;
� nova-console, nova-vncproxy, nova-consoleauth: sono invece i
servizio che si occupano dell’accesso alle console delle macchine
virtuali.
• Networking – Neutron:
• È il servizio che si occupa della gestione della rete e degli indirizzi IP dell’intera
infrastruttura OpenStack.
Neutron permette di creare avanzate tipologie di reti virtuali includendo servizi
come firewall, Load Balancers e virtual private networks (VPNs). Esso fornisce
inoltre le astrazioni di reti, subnets e router/switch.
Nella configurazione del Networking, nessuno eccetto Neutron, ha l’accesso
diretto all’’External Network, verso il mondo esterno.
All’interno di ogni progetto, gli utenti possono creare una o più reti private,
indipendentemente da come il proprio vicino di tenant abbia configurato la
propria rete e questo è possibile grazie all’utilizzo dei NameSpace di Linux.
La comunicazione dal mondo esterno verso le VMs, e viceversa, necessita,
ovviamente, di un router tra le reti. Esso dovrà essere connesso alla subnet
dell’internal network.
Attraverso l’utilizzo del programma che opera in L2, OpenVSwitch, esso mette
in collegamento (DataLink Layer) varie istances richieste dall’utente e le
assegna alla porta di bridge dell’OVS che ha appena creato. Successivamente
mappa gli indirizzi delle istances, collegate all’OVS, al CIDR di indirizzi pubblici
disponibili nell’infrastruttura OpenStack, così da poterle rendere raggiungibili
dall’esterno per fornire i servizi richiesti.
Neutron supporta i Security Groups: essi danno la possiblità di definire diversi
firewall in base ai gruppi. Ogni VM può far parte di uno o più SG e il Networking
applica delle regole a questi gruppi per bloccare o sbloccare porte, settare
intervalli di porte oppure gestire tipi di traffico per le VM.
• Identity Service – Keystone:
• Keystone è il servizio che si occupa di gestire l’aspetto dell’autenticazione e
dell’autorizzazione all’interno di OpenStack, inoltre funge anche da service
catalog.
Figura 5 Processo di Identificazione del progetto Keystone
Si occupa della validazione delle credenziali per gli utenti, validazione e
gestione dei token per l’autenticazione, gestisce il catalogo dei servizi con le
informazioni relative agli endpoint di ogni servizio ed infine le policy di
autorizzazione.
Quando un utente fa una richiesta a Keystone, se l’autenticazione dà esito
positivo, egli ottiene un token da utilizzare per poter effettuare le varie
operazioni o richieste.
Quando un servizio riceve una richiesta da parte di un utente o da un altro
servizio, effettua una chiamata a Keystone passandogli il token del
richiedente: se l’autenticazione risulta positiva, la richiesta può essere accolta
altrimenti rigettata.
• Image Service – Glance:
• Glance fornisce un servizio centrale per la tipologia IaaS. Esso si occupa di
immagazzinare e recuperare le immagini delle macchine virtuali all’interno di
OpenStack.
Glance include i seguenti componenti:
� glance-api: accetta chiamate API per l'individuazione, recupero e
memorizzazione delle immagini;
� glance-registry: immagazzina, processa, e recupera i metadati
(informazioni come ad esempio la dimensione e il tipo) relativi alle
immagini.
• Block Storage – Cinder:
• Il servizio di Block Storage aggiunge storage permanente per una macchina
virtuale. Cinder fornisce un'infrastruttura per la gestione dei volumi, e
interagisce con Compute per fornire i volumi alle istanze. Il servizio consente
inoltre la gestione degli snapshot di volume.
• Object Storage – Swift:
• Il servizio Swift, in maniera analoga al Cinder, gestisce via software grandi
quantità di spazio sul disco. Non solo offre un servizio di object storage ma
integra nativamente la funzionalità di Content Delivery Network, una replica
geografica con accesso al medesimo dato da punti differenti in base alla
latenza minore.
Ogni “oggetto” viene memorizzato utilizzando un path derivato dall'hash del
file e dal timestamp dell'operazione, così da assicurare che verrà servita
sempre l'ultima versione disponibile.
3.1 Struttura minimale OpenStack
L’architettura minimale OpenStack prevede un numero limitato di nodi suddivisi in base
alle funzionalità e ai servizi forniti. I componenti previsti dall’architettura di Kilo sono
sviluppati secondo i criteri di flessibilità, scalabilità ed elasticità, ed in modo indipendente
l’uno dall’altro.
Figura 6 Architettura Minimale OpenStack - Network Layout
3.2 Componenti – Nodi
All’interno dell’architettura concettuale della release Kilo di OpenStack sono presenti:
Controller Node, Network Node, Compute Node, Block Storage Node ed infine Object
Storage Node. Ogni nodo contiene una serie di servizi che possiamo vedere nella figura
sottostante:
Figura 7 Layout dei Servizi OpenStack
Controller Node: è il cuore di OpenStack, il nodo che orchestra e gestisce la maggior parte
dei servizi.
Network Node: è il nodo che si occupa di tutto ciò che concerne la rete dell’infrastruttura di
OpenStack.
Compute Node: è la macchina che esegue le istanze virtuali (almeno uno per installazione).
Object Storage Node: è il nodo a cui sono delegati i servizi di storage, intesi come volumi
logici da associare all’istanze.
Block Storage Node: è la macchina che conserva i dati in modo permanente,
indipendentemente dall’istanza.
Questi nodi comunicano tra di loro attraverso varie reti private così da aumentare l’efficienza
e ottimizzare la velocità di iterazione tra i vari servizi.
La rete di Management è dedicata ai servizi all’interno del Cloud, dunque viaggiano
esclusivamente richieste interne all’infrastruttura.
L’External Network è l’interfaccia di rete che fornisce connettività col mondo esterno ad ogni
nodo. Tale interfaccia è presente però solo sul Network Node.
La Tunnel Network è la rete che utilizza ogni nodo per poter comunicare con il resto del
mondo, attraverso tunnel GRE (di default), un protocollo L2 che vedremo più avanti.
4. Struttura e strumenti utilizzati
Prima di procedere con la configurazione di OpenStack e visionare il caso d’uso preso in
considerazione, diamo uno sguardo alla struttura a disposizione per la creazione
dell’infrastruttura e gli strumenti software da utilizzare.
La struttura è composta da un HyperVisor manager (XenGate) che fornisce la piattaforma
su cui poter creare i nodi necessari al caso d’uso. Inoltre sono presenti 4 Bare Metal
destinati all’utilizzo di calcolo computazionale.
Il networking è composto da due reti: la prima, che chiameremo Cloud Network e su cui
comunicano tutti i nodi, funge da rete di Management e da External Network, dato che ha
un accesso diretto al mondo esterno, la seconda rete, denominata Network 0, è utilizzata
per mettere in comunicazione i Compute Nodes ed il Network Node sulla rete di Tunnel e i
Compute con lo storage sulla Storage Network.
Per l’implementazione di tutti i nodi e la loro configurazione da remoto, ho utilizzato un
terminale, fornito dalla struttura, collegato direttamente alla Management Network (Cloud
Network) su cui è presente il sistema operativo Ubuntu 14.04.
Tutti i servizi e i moduli forniti da OpenStack sono stati installati su macchine virtuali aventi
CentOS 7 come sistema operativo.
5. Caso d’uso
Il caso d’uso implementato è quello di un piccolo data center aventi 3 cluster di compute dislocati in 3 network diverse.
Figura 8 Topologia di Rete del caso d'uso
Gli attori principali sono il Compute Node e il Network Node che forniscono i servizi principali.
Il cluster dei Compute è suddiviso in tre aree ognuna delle quali è composta da 3 compute.
Ogni sotto-cluster ha una rete dedicata mappata successivamente sul CIDR di indirizzi IP
pubblici disponibili.
Il caso d’uso descritto rappresenta, in piccolo, un data center che fornisce un servizio di
potenza di calcolo al richiedente e servizio di storage.
Un esempio pratico è quell’infrastruttura che fornisce maggiore potenza di calcolo ad un
gruppo di ricercatori che si trovano all’altro capo del campus, o all’altro capo del continente,
per poter accelerare gli esperimenti avendo a disposizione più macchine su cui operare.
5.1 Implementazione del caso d’uso
Il primo passo è preparare l’ambiente di sviluppo, quindi implementare i servizi necessari di
OpenStack – Release Kilo: il servizio di sincronizzazione, Network Time Protocol (NTP),
MySQl per la gestione dei database all’interno dell’infrastruttura, un servizio di Coda di
Messaggi per coordinare le operazioni e gestire le informazioni sugli status tra i servizi, si è
scelto RabbitMQ perché la maggior parte delle distribuzioni lo supporta. L’ immagine ISO
usata per la creazione delle istances e per le prove dell’ambiente è Cirros-0.3.4-x86_64.
Le due network della struttura su cui ho operato sono la Cloud Network con maschera
192.168.1.0/21 e la Network 0 con maschera 10.0.0.0/24
La rete Cloud l’ho suddivisa in due sotto reti: una dedicata alla Management e la seconda
alla rete External.
La tabella seguente descrive la parte del Network e l’assegnazione degli indirizzi IP di ogni
singolo nodo con il loro relativo host name:
Host Name Management Network External Network Tunnel Network
Controller 192.168.7.1
Network 192.168.7.2 Unnumbered 10.0.0.1
Cluster A
192.168.7.10
192.168.7.11
192.168.7.12
10.0.0.10
10.0.0.11
10.0.0.12
Cluster B
192.168.7.20
192.168.7.21
192.168.7.22
10.0.0.20
10.0.0.21
10.0.0.22
Cluster C
192.168.7.30
192.168.7.31
192.168.7.32
10.0.0.30
10.0.0.31
10.0.0.32
5.1.1 Identity Service
Il nome del progetto è Keystone è si occupa di autenticare e autorizzare gli utenti.
Nell’implementazione si è creato per ogni servizio un’entità all’interno del catalogo.
Per una maggiore semplicità si è deciso di usare un domain di default dove poter inserire i
progetti (tenants), users e roles.
Quindi si creano i progetti Admin, Service e Demo: il primo ha il ruolo di amministratore
all’interno dell’infrastruttura, il Service è quel progetto che contiene un utente unico per ogni
servizio aggiuntivo all’interno dell’ambiente, ed il Demo che rappresenta un utente regolare
senza i privilegi di amministratore.
Ecco la sequenza di comandi per la creazione del progetto Admin con i relativi user e ruoli:
Queste entità possono essere raggiunte attraverso gli endpoint: è un demone che il client
utilizza per comunicare con le API.
Di seguito è descritto il comando per creare l’endpoint del servizio Identity nel nodo
Controller.
Ogni progetto prevede la creazione del proprio database all’interno del servizio MySQL
presente nel nodo server (Controller).
$ openstack project create --description "Admin Project" admin $ openstack user create --password-prompt admin $ openstack role create admin $ openstack role add --project admin --user admin admin
$ openstack endpoint create --publicurl http://controller:5000/v2.0 --internalurl http://controller:5000/v2.0 --adminurl http://controller:35357/v2.0 --region RegionOne identity
5.1.2 Image Service
Il servizio di Image deve fornire, per l’appunto, le immagini virtuali per la creazione delle
istanze.
L’installazione prevede l’aggiunta del progetto Glance ed i relativi user, service, role ed
endpoint e le varie configurazioni del servizio.
La parte interessante è l’aggiunta delle immagini virtuali: avendo ottenuto il file .ISO (o altre
estensioni), si procede con l’upload in formato QCOW2 (formato di dischi supportato da
Image Service) e alla creazione della relativa voce all’interno del servizio Glance:
5.1.3 Compute Service
Dopo aver creato l’apposito database, aggiunto l’user Nova e settato il suo endpoint, si
procede con l’installazione dei servizi che compongono Nova, il tutto all’interno del
Controller Node.
Nel nodo Compute si implementa solamente il servizio nova-compute. La lista dei processi
apparirà così:
$ glance image-create --name "cirros-0.3.4-x86_64" --file /tmp/images/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --visibility public --progress
$ nova service-list Output: +----+------------------+------------+----------+---------+-------+ | Id | Binary | Host | Zone | Status | State | +----+------------------+------------+----------+---------+-------+ | 1 | nova-conductor | controller | internal | enabled | up | | 2 | nova-consoleauth | controller | internal | enabled | up | | 3 | nova-scheduler | controller | internal | enabled | up | | 4 | nova-cert | controller | internal | enabled | up | | 5 | nova-compute | compute1 | nova | enabled | up | | 6 | nova-compute | compute2 | nova | enabled | up | | 7 | nova-compute | compute3 | nova | enabled | up | +----+------------------+------------+----------+---------+-------+
5.2 Networking
All’interno del Controller Node vengono svolti i passi preliminari alla configurazioni, simili a
quelli del Compute Service, quindi creazione e popolamento del database dedicato,
creazione e inserimento dell’user Neutron. Successivamente si esegue l’installazione dei
componenti neutron-server, neutron-plugin-ml2, python-neutronclient.
Nella configurazione dei file inerenti a Neutron, vengono abilitati il plug-in Modular Layer 2,
il router service, l’overlapping degli indirizzi IP ed i security group.
Passando al settaggio del modulo ML2, si abilitano i vari type drivers:
- Flat: rete di collegamento standard.
- VLAN: rete virtuale che consente di separare host appartenenti allo stesso
dominio e connettere host separati fisicamente.
- GRE: protocollo di incapsulamento.
- VxLAN: tecnologia di virtualizzazione di rete che aumenta la scalabilità delle
singole VLAN.
Il Controller non necessita del meccanismo OpenVSwitch, poiché non deve manipolare
traffico di rete delle istanze.
Invece, nei nodi Compute e nel Network, il demone OVS deve essere presente, poiché
permette il collegamento in L2 tra le istanze.
La creazione delle reti l’ho eseguita da CLI utilizzando questa sequenza di comandi per la
rete privata:
In questa invece creo la rete pubblica, external:
$ neutron net-create private-network $ neutron subnet-create private-network TENANT_CIDR(PRIVATE NETWORK) \ --name private-subnet --dns-nameserver DNS --gateway TENANT_GATEWAY
$ neutron net-create external- network --router:external \ --provider:physical_network external --provider:network_type flat $ neutron subnet-create external-network EXTERNAL_NETWORK_CIDR \ --name external-subnet \ --allocation-pool start=FLOATING_IP_START, end=FLOATING_IP_END \ --disable-dhcp --gateway EXTERNAL_NETWORK_GATEWAY
Adesso si collegano le due reti creando un router virtuale:
5.2.1 Modul Layer 2 – ML2
È un framework che permette al Networking di Openstack di utilizzare simultaneamente le
tecnologie del livello 2 complesse e differenti nei vari data centers. (Vendor-Indipendent).
Questo plug-in usa il meccanismo dell’OpenVSwitch per costruire il framework di rete
virtuale per le istanze che ne necessitano.
I driver di ML2 implementano separatamente set di reti e meccanismi per l’accesso alle reti
di diverso tipo.
Questi meccaniscmi possono essere usati simultaneamente per l’accesso alle differenti
porte delle stesse reti.
Ci sono due tipi di driver: Type Drivers e Mechanism Drivers.
• Type Driver:
Ogni tipo di rete è gestita da un ML2 TypeDriver. Questo driver mantiene qualunque stato
della rete che serve e fornie un’allocazione per le reti dei tenant. L’ML2 plugin include i driver
per local, flat, vlan, gre e vxlan.
• Mechanism Driver:
Ogni meccanismo di networking è gestito da un Mechanism Driver. Esso è responsabile di
prendere le informazioni fornite dai TypeDrivers e garantisce la corretta applicazione dei
meccanismi specifici di rete che sono stati abilitati.
5.2.2 Differenza tra VxLAN e GRE
• Generic Routing Encapsulation – GRE
Protocollo che incapsula una vasta varietà di protocolli (fino a 20) di livello di rete dentro
all’interno di collegamenti point-to-point virtuali.
Fasi del protocollo GRE:
a. L’ host sorgente crea su una LAN un pacchetto, utilizzando un proprio protocollo
nativo e lo spedisce nella rete.
$ neutron router-create routerX $ neutron router-interface-add routerX private-subnet
$ neutron router-gateway-set routerX external- network
b. Il router di default, poiché il computer di destinazione non è locale, prende il pacchetto
e lo incapsula usando il carrier protocol per creare il tunnel GRE: in questo modo si
stabilisce una connessione virtuale punto a punto con un router presente all’altro
capo di Internet.
c. Quando giunge a destinazione, il pacchetto viene “spogliato” dell’header IP e lasciato
il protocollo nativo nella LAN di destinazione.
• VxLAN
È una tecnologia di virtualizzazione di rete che tenta di migliorare i problemi di scalabilità
associate alla stragrande parte del Cloud Computing.
Esso usa una tecnica di incapsulamento simile a quella della VLAN per incapsulare, in MAC-
base, i frame ethernet dentro i pacchetti UDP.
È un protocollo proposto per la creazione di un network virtuale su un L3. Una rete del
genere è una rete virtuale costruita al di sopra della rete esistente. Tale tecnologia permette
di scalare un ambiente cloud computing in maniera più semplice, mentre al livello logico si
potrà isolare le applicazioni cloud ed i tenant.
5.2.3 OpenVSwitch
Il servizio OVS fornisce un framework network virtual sottostante alle istanze. Il bridge
integrato br-int manipola il traffico del network interno tra le istanze con OVS. Il bridge
esterno br-ex invece si occupa del traffico dell’external network con gli OVS. L’external
bridge neccessità di una porta su un’interfaccia fisica di rete per fornire l’accesso al network
esterno alle istanze interne. In sostanza, questa porta connette il network virtuale e quello
fisico nell’ambiente in cui operiamo.
I comandi da CLI per istanziare OVS sono i seguenti:
$ ovs-vsctl add-br br-ex $ ovs-vsctl add-port br-ex INTERFACE_NAME
5.3 Problematiche riscontrate
Durante la configurazione di OpenStack ho riscontrato un problema riguardante il servizio
Identity, risolto attraverso la modifica dei ruoli e degli user presenti nel database
danneggiati durante le procedure successive alla configurazione del Compute.
Un problema più consistente si è presentato durante il collegamento dei Compute nodes
con la rete External, creata a DOC per ogni Cluster, per farli comunicare col mondo
esterno.
Il problema consisteva nel collegare ogni singolo nodo alla rete esterna mappando il suo
indirizzo privato, l’IP della rete Tunnel, in un indirizzo pubblico facente parte del CIDR di IP
messi a disposizione per il tunneling. Il caso pratico era quello del Cluster A, quindi con
indirizzi 10.0.0.10, 10.0.0.11 e 10.0.0.12, collegati all’interfaccia br-ex dell’OVS presente
nel Network Node precedentemente creato.
La soluzione che ho adottato in primis è stata di disabilitare il DHCP della rete External,
che sovrapponeva il mappaggio degli indirizzi privati eseguito da Neutron e quindi non
permettendo l’esecuzione del suo servizio.
In secondo piano ho rivisto la configurazione ed ho adottato il protocollo GRE piuttosto che
VxLAN per l’incapsulamento per evitare problemi con l’overbound della MTU nel frame
ethernet.
6. Conclusioni
OpenStack sta diventando una realtà sempre più concreta e una soluzione stabile,
economica e programmabile.
Attraverso lo studio, l’installazione e la configurazione di questo framework, sono emersi
parecchi aspetti positivi legati alla scalabilità, flessiblità e programmabilità di questo
framework.
Le reti attuali necessitano sicuramente di un upgrade per poter stare a passo con la
tecnologia software e con le esigenze del mercato.
La soluzione concreta del paradigma SDN, OpenStack, non solo è facile da gestire, ma è
anche in grado di integrare qualsiasi tipo di algoritmo, funzione o protocollo utile che possa
migliorare il suo utilizzo e i suoi servizi, il tutto in maniera semplice, veloce e dinamica.
