Elaborato Sommese Raffaele N46002132

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori
An SDN-based setup for active
measurements in mobile networks
Anno Accademico 2015/2016
Candidato:
Raffaele Sommese
matr. N46002132
A mia Madre e mio Padre
A Te che ci sei e ci sei sempre stata
Agli Amici di sempre
Indice
Capitolo 1 Introduzione
1.1 Progetto Monroe . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
Capitolo 2 Software Defined Networking
2.1 OpenVSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
Capitolo 3 Nodo Monroe
3.1 Bios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . .
6
7
8
Capitolo 4 Docker
9
4.1 Gestione dei permessi in Docker . . . . . . . . . . . . . . . . . . 10
4.2 Sicurezza in Docker . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Modalità di rete Docker . . . . . . . . . . . . . . . . . . . . . . 11
Capitolo 5 Infrastruttura Virtuale
5.1 Container OpenVSwitch . . . . . . . . . . . . . . . . . . . . . .
5.2 Container Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Container D-ITG . . . . . . . . . . . . . . . . . . . . . . . . . .
13
15
15
16
Capitolo 6 Analisi delle prestazioni di rete di Docker
17
Capitolo 7 Conclusioni e Sviluppi Futuri
22
Bibliografia
23
ii
Elenco delle figure
1.1
1.2
2.1
2.2
3.1
3.2
3.3
4.1
4.2
4.3
5.1
5.2
5.3
5.4
5.5
6.1
6.2
6.3
Evoluzione delle performance su reti mobili [1] .
Architettura del progetto Monroe [2] . . . . . .
Architettura di una rete SDN [3] . . . . . . . .
Principio di funzionamento di OpenVSwitch [4]
Architettura di un Nodo Monroe [2] . . . . . . .
CoreBoot Bios in Virtual Machine . . . . . . . .
Tinycore in Virtual Machine . . . . . . . . . . .
Docker Engine . . . . . . . . . . . . . . . . . . .
Docker:Modalità Bridge [5] . . . . . . . . . . . .
Docker:Modalità Overlay [5] . . . . . . . . . . .
Tipologie di Deployment considerate . . . . . .
Tipologie di Deployment considerate . . . . . .
OpenVSwich Container . . . . . . . . . . . . . .
Ryu Container . . . . . . . . . . . . . . . . . .
ITGSend Container . . . . . . . . . . . . . . . .
Confronto di banda in Upload . . . . . . . . . .
Confronto con 2 Flussi in Upload . . . . . . . .
Confronto con 2 Flussi Poissoniani in Upload . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
4
5
6
7
8
9
12
12
13
14
15
16
16
19
20
21
Capitolo 1
Introduzione
Introduzione
La misura della banda disponibile è uno dei più importanti e rilevanti ambiti di ricerca nell’area del monitoraggio di rete. Questa, infatti, è importante
per numerose applicazioni che richiedono una stima di tale valore per adattare
il proprio comportamento. Il caso più noto è quello delle applicazioni di
video-streaming, che utilizzano differenti tecniche per variare la risoluzione a
fronte della banda disponibile. Questa misura, è importante anche, nel nuovo
paradigma delle Content Delivery Networks, per effettuare una scelta ottima
del server da cui l’utente possa prelevare i contenuti [6, 7]. Inoltre, questo
tipo di misure è fondamentale per la verifica dei Service Level Agreements. In
contesti di ricerca è utile avere a disposizione delle piattaforme su larga scala,
che permettano ai ricercatori di avere accesso a numerosi dispositivi distribuiti
su reti geografiche. Queste piattaforme sono utili per testare nuovi approcci
e metodologie applicabili sulla rete, e per raccogliere grosse quantità di dati.
Una delle più importanti piattaforme è PlanetLab, una rete di ricerca globale
che fornisce ai ricercatori un accesso remoto per eseguire esperimenti su reti
distribuite [8]. L’importanza crescente del monitoraggio delle prestazioni di
Figura 1.1: Evoluzione delle performance su reti mobili [1]
internet su reti mobili è dovuta alla sua rapida diffusione e all’avvento di
nuove tecnologie 4G, che prevedono, in teoria, il raggiungimento di velocità
di 100 MByte/s [1].
1
Introduzione
1.1 Progetto Monroe
Figura 1.2: Architettura del progetto Monroe [2]
Il progetto Monroe1 nasce dalla collaborazione tra vari istituti di ricerca
ed università:
• Simula Research Laboratory
• Politecnico Torino
• IMDEA Networks
• Karlstad University
• Celerway Communications
• Nextworks
• Telenor.
Il progetto è sponsorizzato dall’Unione Europea. L’obiettivo del progetto
Monroe è di costruire una piattaforma aperta e flessibile per il deployment di
esperimenti di misura su reti mobili e wireless con il supporto a tecnologie
Multi-Homed. Il progetto punta a creare un paradigma EaaS (Experiments
as a Service) per gli utilizzatori del servizio, con l’obiettivo di facilitare la
gestione e la manutenzione del sistema e di renderlo di immediato utilizzo [9].
1
https://www.monroe-project.eu
2
Introduzione
Gli utilizzatori del progetto sono sia dagli utenti del consorzio Monroe, sia
membri esterni, tra cui l’Università Federico II. E’ importante al fine di coordinare i vari esperimenti attivi in esecuzione sui diversi nodi di misura, trovare
una metodologia per permettere ai suddetti di eseguire contemporaneamente
senza che ciò influenzi il risultato delle loro misure. In questa tesi si vuole
presentare un setup basato su tecnologia SDN per i nodi Monroe, che potrà
essere utile alla risoluzione del sopraccitato problema.
3
Capitolo 2
Software Defined Networking
Software Defined Networking
Il paradigma emergente del Software Defined Networking, si pone l’obiettivo di superare la classica e complessa gestione delle infrastrutture di
rete decentralizzata, separando la logica di controllo definita come control
plane, dalla logica di forwarding del traffico definita come data plane. Da
questa separazione, i dispositivi di rete assumono il semplice ruolo di store
and forward, mentre la logica di gestione viene demandata ad un controller
centralizzato, o in alternativa ad un Network Operating System. Questa
gestione centralizzata permette di ottenere un maggior controllo sulle policy
di rete e sul deployment di eventuali aggiornamenti o riconfigurazioni. È bene
notare che il controller, nonostante porti alla centralizzazione dell’intelligenza
della rete, deve essere adeguatamente distribuito su più entità fisiche, per
evitare un Single Point of Faliure e per garantire ai dispositivi di rete, la
stessa affidabilità dei quelli gestiti con un approccio decentralizzato[3].
Figura 2.1: Architettura di una rete SDN [3]
In Figura 2.1 sono presentati tutti i componenti sopra descritti. È bene notare
che l’interscambio di informazioni tra il control plane e il data plane avviene
attraverso OpenFlow, un protocollo di comunicazione sviluppato per reti SDN
[10].
2.1 OpenVSwitch
OpenVSwitch è una delle implementazioni più utilizzate e famose di switch
SDN software. Il suo successo è dovuto alla scarsa disponibilità iniziale e
all’elevato costo di switch hardware OpenFlow. OpenVSwitch è formato da
due componenti principali: un demone user-space e un modulo kernel.
4
Software Defined Networking
I pacchetti in arrivo su un bridge OpenVSwitch vengono gestiti come illustrato
in Figura 2.2
Figura 2.2: Principio di funzionamento di OpenVSwitch [4]
All’arrivo di un pacchetto, il modulo kernel provvede ad intercettarlo e
controlla nella propria tabella all’interno del kernel se vi è una regola per
processarlo. Se il modulo kernel non trova una regola adatta, provvede al
trasferimento del pacchetto, attraverso una netlink socket, al demone in
userspace, che successivamente controlla nella propria tabella se vi sono regole
per il processamento. Se anche in userspace la regola non è presente allora il
demone in userspace interroga il controller [4].
5
Capitolo 3
Nodo Monroe
Nodo Monroe
Il nodo Hardware Monroe è equipaggiato con una APU1D4 . L’APU1D4
è una small form-factor board avente le seguenti caratteristiche hardware:
• CPU:AMD T40E 1 Ghz Dual Core 64 bit
• RAM: 4GB DDR-1066
• 2 miniPCI-E Slot
• 3 Ethernet Gigabit
Il nodo include anche:
• Wifi:Compex WLE600VX 802.11ac/b/g/n Dual-Band mPCIe
• GPS:Sierra Wireless MC7304 LTE mPCIe
• SSD:SSD M-Sata 16GB MLC Phison
• USB Hub:Yepkit YKUSH
• 3 USB Modem:ZTE MF910 MiFi
• Antenne
Figura 3.1: Architettura di un Nodo Monroe [2]
I Nodi Monroe sono installati su alcuni autobus urbani ed extraurbani, e
l’hardware scelto è stato testato in diverse condizioni di umidità e temperatura.
In particolare è stato rilevato che i Modem Usb MiFi si spegnevano al
superamento della temperatura di 55◦C e di una percentuale di umidità
relativa del 60%. La restante parte dei dispositivi ha funzionato regolarmente
durante uno stress test con temperatura di 70◦C e umidità relativa del 60%
6
Nodo Monroe
e in un un caso d’utilizzo reale, tra Bergen e Sogndal, ad una temperatura
di -10◦C. Sono sorte alcune complicazioni riguardo l’alimentazione, in un
caso reale, su alcuni bus a Torino, che hanno portato all’instabilità di alcuni
dispositivi connessi via USB [11].
La sezione di alimentazione risulta critca anche a causa di continui cicli di
on/off a cui è soggetto il nodo, e alla indisponibilità di un’alimentazione a
220V AC.
3.1 Bios
Nella prima fase dello sviluppo del nostro setup, si è reso necessario
replicare in virtuale il sistema fisico, per testare i vari approcci senza il
supporto dell’hardware reale, non ancora disponibile. Per fare questo si è
deciso di emulare il sistema attraverso il software di virtualizzazione QEMU.
La board è fornita con CoreBoot, un bios opensource, dunque si è scelto di
ricompilare ed emulare anche quest’ultimo.
CoreBoot è un firmware opensource per dispositivi embedded e PC che offre
un’esperienza di avvio veloce e affidabile [12].
Si è reso necessario adattare la configurazione di CoreBoot, in accordo al
tutorial presente sulla wiki ufficiale, con alcuni accorgimenti, a causa della
documentazione non aggiornata. CoreBoot necessita di un “second stage
payload” al fine di caricare il sistema operativo e/o un boot manager. I
payload che è possibile usare per questo scopo sono numerosi, inclusa la
possibilità di inserire l’intero kernel Linux come payload. Nel nostro caso si è
scelto di utilizzare SEABios, un bios a 16-bit x86 che supporta vari bootloader,
e che viene utilizzato in genere come Bios principale in QEMU. A tal fine, lo
abbiamo compilato e incluso nell’immagine personalizzata di CoreBoot.
Figura 3.2: CoreBoot Bios in Virtual Machine
7
Nodo Monroe
3.2 Sistema Operativo
Inizialmente non erano disponibili molte informazioni circa il sistema
operativo installato sui nodi Monroe, quindi in prima analisi si è deciso di
focalizzarsi sull’OS di default del produttore della APU. Si è successivamente proceduto a sviluppare un setup completo di TinyCore 5.2 utilizzando
l’immagine ufficiale fornita da PC-Engine. Dopo aver ottenuto un setup
del sistema virtualizzato completo e stabile si è passati all’installazione di
OpenVSwitch,una piattaforma Open-Source per la creazione di bridge SDN
software.
Figura 3.3: Tinycore in Virtual Machine
Nei repository ufficiali di TinyCore Linux non era presente il pacchetto di
OpenVSwitch, pertanto si è reso necessario compilare quest’ultimo dai sorgenti.
Durante la compilazione ci si è resi conto che per il corretto funzionamento
di OpenVSwitch è necessario caricare alcuni moduli kernel, e per la corretta
compilazione era necessaria una versione di GCC più recente.
Successivamente siamo stati informati dai membri del progetto Monroe che il
sistema operativo ufficiale scelto per la board è Debian Jessie con Kernel 4.6
prelevato dai repository debian backport.
Gli esperimenti, inoltre, potranno essere eseguiti tramite macchina virtuale o
container Docker. Allo stato attuale solo l’implementazione dei container è
pronta all’uso,di conseguenza si è deciso di focalizzarsi su un setup containerbased.
8
Capitolo 4
Docker
Docker
Un container software è molto simile ad una macchina virtuale, ma a
differenza di quest’ultima risulta essere meno gravoso sulle risorse del sistema.
In una macchina virtuale, infatti, è necessario emulare l’intero sistema operativo ospite, incluso il kernel. Ciò, in uno scenario di deployment di numerose
applicazioni in diverse macchine virtuali, porta ad un overhead significativo.
I container, invece, utilizzano le primitive previste dal kernel Linux per la
virtualizzazione dei namespace e la gestione delle risorse attraverso cgroups,
condividendo di fatto il kernel sottostante. Inoltre i container rappresentano
un’astrazione del sistema operativo di riferimento specificato, poiché essi
emulano soltanto le differenze rispetto al sistema base. Questi punti di forza
hanno portato alla rapida diffusione dei container software in vari campi
dell’ICT, facendo emergere il nuovo paradigma del Container as a Service [13].
Docker è un gestore di container nato come progetto dell’azienda dotCloud.
Figura 4.1: Docker Engine
Nel 2013 viene rilasciato come software opensource, diventando uno dei progetti più seguiti su GitHub [14]. È scritto in linguaggio Go ed inizialmente
utilizzava le librerie LXC, ma dalla versione 0.9, utilizza una propria libreria:
libcontainer. Le immagini pubbliche di Docker vengono raccolte all’interno di
un repository detto Docker Hub, ed alcune di esse vengono certificate come
9
Docker
immagini ufficiali. Per creare una nuova immagine di Docker è necessario
produrre uno speciale file di testo: il DockerFile.
In questo file va indicata l’immagine base a cui si fa riferimento e le modifiche
che si vogliono apportare ad essa, compresa l’inclusione di eventuali file dell’utente. Successivamente,il container viene compilato producendo un’immagine
che include le differenze rispetto all’immagine base. Ogni immagine Docker,
infatti, rappresenta un livello read-only che, messo su uno stack, concorre
alla realizzazione il filesystem reale del container. Il Docker storage driver si
occupa della gestione di questi layer [15]. Quando il container viene avviato,
viene creato un ulteriore layer read-write contenente le modifiche temporanee.
Questa strategia di gestione permette di ottenere immagini leggere e facilmente distribuibili attraverso repository privati o pubblici,quale il DockerHub.
4.1 Gestione dei permessi in Docker
Di base, Docker esegue i container in modalità non privilegiata. Questa
impostazione non permette, ad esempio di modificare gli indirizzi ip dell’interfaccia di rete, caricare moduli kernel o eseguire il demone Docker all’interno
di Docker. Una modo per eseguire questa tipologia di operazioni è l’utilizzo dei container in modalità privilegiata. Questa impostazione, tuttavia,
mina pesantemente i principi di isolamento dell’approccio container-based.
Esistono comunque delle opzioni messe a disposizione per permettere un
tuning migliore dei privilegi concessi al container. Ad esempio, si possono
fornire i privilegi di accesso ad un determinato dispositivo tramite l’opzione
–device=/dev/snd:/dev/snd con la possibilità di scegliere se quest’ultimo può
essere acceduto in lettura, scrittura ed esecuzione. Docker permette inoltre
attraverso le opzioni –cap-add e –cap-drop di aggiungere ulteriori permessi o
di rimuovere i permessi non necessari [16].
I permessi associabili fanno parte delle Linux capabilities introdotte nel Kernel 2.2, che hanno modificato la precedente situazione in cui vi erano due
uniche modalità di esecuzione di processi, o con UID 0 privilegiata o con
UID diverso da 0 in modalità non privilegiata. Le capabilities provvedono
alla separazione dei vari privilegi fornendo un ulteriore livello di astrazione
10
Docker
e sicurezza al sistema. È possibile ritrovare una lista completa delle Linux
capabilities all’interno del manuale ufficiale [17].
4.2 Sicurezza in Docker
L’utilizzo dei container permette di semplificare le operazioni di gestione e
mantenere al contempo un alto livello di sicurezza, solo se vengono adottate le
stesse politiche di sicurezza di uso comune per gli altri processi (ovvero l’uso di
utenti non privilegiati per evitare escalation, configurazioni delle applicazioni
sicure ecc...). I problemi principali dell’approccio container sono causati dalla
condivisione del Kernel della macchina host, portando a possibili attacchi di
tipo Denial of Service (Kernel-Panic nei casi più gravi) [18]. Inoltre se forniamo
al container i privilegi per l’accesso a device e sottosistemi Kernel ”vitali”, essi
risultano essere attaccabili, permettendo eventualmente un controllo completo
del sistema.
4.3 Modalità di rete Docker
Durante la fase di installazione Docker crea tre interfacce di rete: una
rete bridge collegata all’interfaccia docker0 all’interno dell’host e utilizzata
come rete di default in tutti i container ove non specificato; una rete host che
aggiunge il container allo stack di rete dell’host permettendogli l’accesso a
tutte le interfacce; una rete none che rappresenta una rete riservata al singolo
container contenente solo l’interfaccia di loopback. Docker permette, dalla
versione 1.8 in via sperimentale e stabilmente dalla 1.9.01 ,anche la creazione
di reti definite dall’utente per una gestione più granulare dei container. Si
possono creare sia reti bridge che reti overlay, inoltre è possibile realizzare
plugin di rete proprietari. Le reti Bridge sono simili alla rete docker0, nella
loro creazione è possibile specificare il range di indirizzi assegnati,il default
gateway e se la rete è interna o esterna. Le reti Bridge sono di tipo Natted,
pertanto per esporre un servizio all’esterno è necessario “pubblicare” la porta.
1
https://github.com/docker/docker/releases/tag/v1.9.0
11
Docker
Figura 4.2: Docker:Modalità Bridge [5]
La modalità di rete Overlay permette la creazione di reti multi-host
implementando una logica SDN-Like. Infatti, questa tipologia di reti richiede
la presenza di un Key-Value store centralizzato che mantiene le informazioni
circa la topologia di rete distribuita [5].
Figura 4.3: Docker:Modalità Overlay [5]
È possibile implementare un’ulteriore modalità di rete SDN attraverso
l’ausilio di OpenVSwitch. Per realizzare ciò, è necessario utilizzare la modalità
di rete none e successivamente collegare i container docker allo switch SDN.
Per il collegamento dei container allo switch è possibile utilizzare l’estensione
ovs-docker2 attraverso il comando:
ovs-docker add-port ovs-br1 eth0 containern –ipaddress=192.168.1.33/24
eth0 è l’interfaccia di rete che verrà associata all’interno del container, containern è il nome del container e 192.168.1.33/24 è l’indirizzo ip con la netmask
associata.
2
https://github.com/openvswitch/ovs/blob/master/utilities/ovs-docker
12
Capitolo 5
Infrastruttura Virtuale
Infrastruttura Virtuale
Sono state valutate varie soluzioni possibili per lo sviluppo di una prima
infrastruttura di test:
(a) Docker
(b) Full VM
Figura 5.1: Tipologie di Deployment considerate
Nell’approccio evidenziato in Figura 5.1b, utile nel caso si voglia mantenere
una totale indipendenza dal sistema sottostante, si provvede a instanziare una
macchina virtuale sul nodo fisico, attraverso l’uso di strumenti quali Vagrant e
VirtualBox. All’interno della macchina virtuale si esegue OpenVSwitch e due
ulteriori Virtual Machine, o in alternativa dei container Docker, contenenti i
vari tool degli esperimenti. Inoltre, si collegano le interfacce delle macchine
virtuali ad OpenVSwitch in modo da poterne gestire il traffico. Di contro,
questa soluzione introduce un alto overhead dovuto alla virtualizzazione.
Nel secondo approccio, esposto in Figura 5.1a, con il deployment di OpenVSwitch sul sistema host fisico è possibile eseguire all’interno di container
Docker (lo scenario attualmente in uso nel nodo Monroe) gli esperimenti, e
collegare le interfacce dei container attraverso l’estensione ovs-docker allo
switch SDN. L’approccio in Figura 5.2a è simile al caso precedente ma si
basa sull’utilizzo di virtual machine. Eventualmente i due approcci proposti
possono essere combinati in modo da poter gestire il traffico totale del nodo.
L’approccio evidenziato in Figura 5.2b, attualmente implementato, rappresenta un compromesso tra la flessibilità d’uso garantita dalle macchine virtuali e
le scarse modifiche richieste al sistema operativo host,imposte nelle fasi iniziali
13
Infrastruttura Virtuale
(a) VM
(b) Full Docker
Figura 5.2: Tipologie di Deployment considerate
del progetto. In questa tipologia di implementazione anche OpenVSwitch è
eseguito all’interno di un container Docker e tutti i container sono interconnessi tra di loro attraverso delle bridge network,le quali possono essere create
tramite il comando:
docker network create –driver bridge –subnet 192.168.50.0/29 link1
dove link1 rappresenta il nome della rete e 192.168.50.0/29 la rete da creare.
Successivamente è possibile lanciare i vari container docker associandoli
ad un bridge attraverso la specifica –net nomerete
Docker, per scelte implementative, allo stato attuale permette l’associazione di una sola rete all’avvio del container. Per associare ulteriori reti
è necessario, dopo aver eseguito il comando run, digitare da terminale il
seguente comando:
docker network connect nomerete nomecontainer
Si è dunque proceduto a realizzare un primo setup, come in Figura 5.2b,
contenente i seguenti container:
1. OpenVSwitch
2. Ryu SDN-Controller
3. D-ITG Sender Mode
4. D-ITG Receiver Mode
14
Infrastruttura Virtuale
5.1 Container OpenVSwitch
Per il container con OpenVSwitch è stato necessario, a causa della richiesta
del caricamento di alcuni moduli kernel, montare all’interno del container in
modalità read-only il path /lib/modules/ contenente i moduli del kernel in
esecuzione sul sistema fisico. E’ stato inoltre necessario lanciare il container
con i seguenti privilegi:
• SYS MODULE (per il caricamento dei moduli kernel)
• SYS NICE (per permettere ad OpenVSwitch di modificare la propria
priorità)
• NET ADMIN (per permettere la modifica degli indirizzi ip delle interfaccie)
Nel DockerFile ritroviamo le istruzioni che provvedono a scaricare OpenVSwitch ed i net-tools dai repository ufficiali di Debian. All’avvio il container
attende 5 secondi, per permettere l’aggancio asincrono delle altre interfacce di
rete, di seguito avvia OpenVSwitch e aggiunge al bridge tutte le interfacce di
rete eth. Successivamente imposta il controller a cui desidera sottoscriversi.
Figura 5.3: OpenVSwich Container
5.2 Container Ryu
Il controller nelle reti SDN è uno dei componenti fondamentali per il
corretto funzionamento della rete. Per tale motivo la scelta di un buon
controller, che sia flessibile ed adatto ai propri scopi risulta essere di vitale
importanza. In letteratura sono presenti molte comparazioni tra le prestazioni
dei vari controller SDN [19]. Nel nostro caso è stato utilizzato Ryu, un
15
Infrastruttura Virtuale
Figura 5.4: Ryu Container
controller SDN scritto in Python, che supporta differenti versioni di OpenFlow.
Ryu permette di realizzare, attraverso script Python eseguiti dal RyuManager,
differenti modalità e topologie di rete. Nel nostro caso, è stato utilizzato un
semplice script di esempio per l’implementazione di uno switch Layer 2 con
autoapprendimento.1
Il container con Ryu necessità solamente del privilegio di NET ADMIN,
che come già specificato, è necessario per permettere la modifica degli indirizzi
ip delle interfacce. Nel DockerFile ritroviamo le istruzioni che provvedono a
scaricare Ryu dai sorgenti e compilarlo. Successivamente Ryu viene avviato
attraverso ryu-manager ed è necessario fornirgli uno script Python contenente
la configurazione desiderata.
5.3 Container D-ITG
Sono dei semplici container con D-ITG configurati in modalità sender e
receiver.
Figura 5.5: ITGSend Container
1
https://github.com/osrg/ryu/blob/master/ryu/app/simple switch.py
16
Analisi delle prestazioni di rete di Docker
Capitolo 6
Analisi delle prestazioni di rete di Docker
È stato realizzato uno scenario di test per effettuare delle misure di achievable throughput in upload, analizzando come questa possa essere influenzata
dalla virtualizzazione offerta dal container Docker. Sono state confrontate le
prestazioni native, sia con le prestazioni di un container con OpenVSwitch
nel sistema operativo host, attraverso il plugin ovs-docker, come illustrato
precedentemente in Figura 5.1a, sia con lo scenario con OpenVSwitch in
container, anch’esso illustrato precedentemente in Figura 5.2b. In particolare
l’intero scenario è stato messo in opera su due PC fisici connessi tra loro
back-to-back con cavo Ethernet CAT5E con specifiche riportate in Tabella 6.1
Receiver
CPU:
Intel T3300
RAM:
2 GB DDR3
NET: Atheros AR8131
Sender
Intel Q8300
4GB DDR3
Realtek 8111C
Tabella 6.1: Specifiche Hardware
Sul Sender sono stati instanziati i tool nelle 3 modalità descritte, mentre
il Receiver è stato posto in modalità nativa emulando di fatto il server di
misura, come previsto dall’architettura finale.
Per effettuare la misura di achievable throughput si è provveduto a saturare
il link attraverso D-ITG con traffico UDP aumentando il rate di trasmissione
fino alla comparsa di packet loss. D-ITG (Distributed Internet Traffic Generator) è una piattaforma per la generazione di traffico sintetico e trace-based,
multipiattaforma e distribuita[20]. Il traffico di congestione è stato generato
con i parametri riporatati in tabella 6.2
Packet Size
InterPacket Time Richiesto
InterPacket Time Ottenuto
BitRate Richiesto
BitRate Medio Ottenuto
Duration
Native
1470 Byte
300805 pkt/s
32620 pkt/s
3.537 Gb/s
383.6 Mb/s
10s
Docker
1470 Byte
300805 pkt/s
28407 pkt/s
3.537 Gb/s
334.1 Mb/s
10s
FullDocker
1470 Byte
300805 pkt/s
24501 pkt/s
3.537 Gb/s
288.1 Mb/s
10s
Tabella 6.2: Parametri di generazione
17
Analisi delle prestazioni di rete di Docker
La differenza notevole tra il BitRate e l’Inter Packet Time richiesto e quello
ottenuto sono dovute alle scarse performance in termini di rete e di computazione, le quali hanno influenzato pesantemente il comportamento di D-ITG.
Si è riscontrato, inoltre,il seguente comportamento anomalo: forzando il
rate al valore ottenuto empiricamente in ricezione, quest’ultimo diminuiva
ulteriormente. Si è dunque deciso di effettuare le misure in modo da massimizzare i tassi di ricezione. L’intero esperimento, attraverso l’ausilio di
script di automatizzazione appositamente creati, è stato ripetuto 100 volte, e
i dati sono stati successivamente estratti e compattati tramite alcune utility
di manipolazione testi quali grep,sed e awk. Infine, essi sono stati plottati
sotto forma di BoxPlot attraverso l’utilizzo di GnuPlot1 , un tool free di tipo
command line che fornisce strumenti per automatizzare la creazione e l’export
in immagini di vari grafici. Il BoxPlot utilizzato nel nostro esempio mostra i
seguenti dati:
• Massimo
• 75% Percentile
• Mediana
• 25% Percentile
• Minimo
Come è possibile notare dai BoxPlot in Figura 6.1, la modalità nativa
risulta essere, come da previsioni, quella con migliori prestazioni. La modalità
con OpenVSwitch incluso nel sistema e il container agganciato riesce a fornirci
comunque prestazioni accettabili rispetto a quella nativa.
Le prestazioni peggiori sono state ottenute nella nostra configurazione
FullDocker, sviluppata in base ai vincoli imposti dal progetto Monroe. In
particolare, in quest ultimo scenario, la rete host viene connessa a docker
tramite un bridge che realizza una Network Address Translation che limita
ulteriormente le prestazioni.
1
http://www.gnuplot.info/
18
Analisi delle prestazioni di rete di Docker
Figura 6.1: Confronto di banda in Upload
Packet Size
IPT Richiesto
IPT Ottenuto
BitRate Richiesto
BitRate Medio Ottenuto
Duration
Packet Size
IPT Richiesto
IPT Ottenuto
BitRate Richiesto
BitRate Medio Ottenuto
Duration
F1 Native
1470 Byte
75080 pkt/s
5143 pkt/s
882.9 Mb/s
60.48 Mb/s
10 s
F2 Native
1470 Byte
75080 pkt/s
4986 pkt/s
882.9 Mb/s
58.64 Mb/s
10 s
F1 Docker
1470 Byte
70080 pkt/s
5529 pkt/s
824.1 Mb/s
65.02 Mb/s
10 s
F2 Docker
1470 Byte
70080 pkt/s
5282 pkt/s
824.1 Mb/s
62.12 Mb/s
10 s
F1 FullDocker
1470 Byte
50080 pkt/s
4814 pkt/s
588.9 Mb/s
56.61 Mb/s
10 s
F2 FullDocker
1470 Byte
50080 pkt/s
5027 pkt/s
588.9 Mb/s
59.12 Mb/s
10 s
Tabella 6.3: Parametri dei due Flussi
È stato realizzato un altro esperimento con due flussi da due container(processi nel caso nativo) diversi con i parametri riportati in Tabella 6.3
Si è notato che l’aumento della saturazione del link dettata dai rate imposti,
19
Analisi delle prestazioni di rete di Docker
portava il traffico di signaling TCP di D-ITG ad essere scartato e soggetto
a numerose ritrasmissioni che falsavano la misura. Le mancate trasmissioni
del traffico di signaling TCP spesso portavano l’esecuzione della generazione
dei due flussi in mutua esclusione. È stata valutata la possibilità di utilizzare
un’interfaccia di rete solo per il signaling, tuttavia tale opzione è stata scartata
poiché essa non è prevista per i nodi reali, di contro sarà possibile tramite
SDN rendere prioritario il traffico di signaling, ottenendo cosi migliori risultati.
Ci si è dunque posti su rate più “conservativi” in modo da ottenere risultati
significativi. L’esperimento di generazione è stato ripetuto per 100 volte.
Figura 6.2: Confronto con 2 Flussi in Upload
In Figura 6.2 sono riportati i due flussi per il caso nativo, Docker e
FullDocker descritti precedentemente. È possibile notare che i flussi tendono
a ripartirsi equamente, presentando minore dispersione nel caso FullDocker.
La mediana, inoltre, tende ad essere simile per tutti i flussi considerati. È
stato infine condotto un ulteriore esperimento con due flussi poissoniani i cui
parametri sono riportati in Tabella 6.4
20
Analisi delle prestazioni di rete di Docker
Packet Size
IPT Richiesto
IPT Ottenuto
BitRate Richiesto
BitRate Medio Ottenuto
Duration
Packet Size
IPT Richiesto
IPT Ottenuto
BitRate Richiesto
BitRate Medio Ottenuto
Duration
F1 Native
1470 Byte
75080 pkt/s
5538 pkt/s
882.9 Mb/s
65.12 Mb/s
10 s
F2 Native
1470 Byte
75080 pkt/s
5630 pkt/s
882.9 Mb/s
66.21 Mb/s
10 s
F1 Docker
1470 Byte
70080 pkt/s
5235 pkt/s
824.1 Mb/s
61.57 Mb/s
10 s
F2 Docker
1470 Byte
70080 pkt/s
5662 pkt/s
824.1 Mb/s
66.58 Mb/s
10 s
F1 FullDocker
1470 Byte
50080 pkt/s
5450 pkt/s
588.9 Mb/s
64.09 Mb/s
10 s
F2 FullDocker
1470 Byte
50080 pkt/s
4635 pkt/s
588.9 Mb/s
54.51 Mb/s
10 s
Tabella 6.4: Parametri dei due Flussi Poissoniani
Figura 6.3: Confronto con 2 Flussi Poissoniani in Upload
Dal BoxPlot dei risultati in Figura 6.3 emerge un comportamento decisamente variabile, che tende ad assestarsi solo nel caso FullDocker.
21
Capitolo 7
Conclusioni e Sviluppi Futuri
Conclusioni
In questo lavoro si è visto come produrre un setup di base con OpenVSwitch e Docker per gestire il traffico dei nodi Monroe. Abbiamo analizzato
ed illustrato parte della tecnologia Docker e il nuovo paradigma Software
Defined Networking.
È stato inoltre descritto l’hardware del nodo Monroe su cui verranno installati
gli esperimenti. Successivamente abbiamo valutato le varie implementazioni
possibili per un setup per i nodi Monroe, analizzando più nel dettaglio le due
modalità container-based.
È stato infine valutato l’impatto sulle prestazioni di rete dovuto all’approccio
container-based mettendolo in relazione ad una configurazione nativa, ottenendo alcuni risultati significativi riguardo alle prestazioni.
Come sviluppi futuri si individuano diverse possibilità:
• La scrittura di un’opportuna configurazione per il controller Ryu capace
di gestire in maniera equa i flussi di traffico provenienti dai vari container,
a differenza del caso attuale in cui è stato utilizzato un semplice script
di esempio.
• La realizzazione e l’implementazione del container contenente i tool per
la misura della banda disponibile ed effettuare misurazioni e valutazioni
in tal senso.
Inoltre, quando l’hardware risulterà essere disponibile, l’intero setup
descritto in questo lavoro dovra essere testato e validato.
22
Bibliografia
[1] N. P. Singh. The theoretical and real world of 4g technologies. Int. J.
Mob. Netw. Des. Innov., 5(2):97–118, March 2013.
[2] First monroe open call. https://www.monroe-project.eu/wp-content/
uploads/2015/12/call announcement v2.pdf.
[3] D. Kreutz, F. M. V. Ramos, P. E. Verı́ssimo, C. E. Rothenberg,
S. Azodolmolky, and S. Uhlig. Software-defined networking: A
comprehensive survey. Proceedings of the IEEE, 103(1):14–76, Jan 2015.
[4] H. Y. Pan and S. Y. Wang. Optimizing the sdn control-plane
performance of the openvswitch software switch. In 2015 IEEE
Symposium on Computers and Communication (ISCC), pages 403–408,
July 2015.
[5] Understand docker container networks. https:
//docs.docker.com/engine/userguide/networking/dockernetworks/.
[6] R. Prasad, C. Dovrolis, M. Murray, and K. Claffy. Bandwidth
estimation: metrics, measurement techniques, and tools. IEEE Network,
17(6):27–35, Nov 2003.
[7] Manish Jain and Constantinos Dovrolis. Ten fallacies and pitfalls on
end-to-end available bandwidth estimation. In Proceedings of the 4th
ACM SIGCOMM Conference on Internet Measurement, IMC ’04, pages
272–277, New York, NY, USA, 2004. ACM.
[8] Antonio Pescapé. Large scale plataforms. University Lecture, 2016.
[9] Andra Lutu Min Xie and Ozgu Alay. Report on use cases. Technical
report, MONROE, 09 2015.
[10] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar,
Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner.
Openflow: Enabling innovation in campus networks. SIGCOMM
Comput. Commun. Rev., 38(2):69–74, March 2008.
[11] Hansen Thomas Hirsch Kristian Evensen Jonas Werme Tobias Logren
Dely Roberto Monno Vincenzo Mancuso Anna Brunstrom Ozgu Alay
Andra Lutu, Audun Fosselie. Report on Hardware Design and Selection.
Technical report, MONROE, 03 2016.
[12] coreboot: fast and flexible open source firmware.
https://www.coreboot.org/.
[13] C. Anderson. Docker [software engineering]. IEEE Software,
32(3):102–c3, May 2015.
[14] Docker: Automated and consistent software deployments.
https://www.infoq.com/news/2013/03/Docker.
[15] Understand images, containers, and storage drivers. https://docs.docker.
com/engine/userguide/storagedriver/imagesandcontainers/.
[16] Runtime privilege and linux capabilities. https://docs.docker.com/
engine/reference/run/#runtime-privilege-and-linux-capabilities.
[17] capabilities - overview of linux capabilities.
http://linux.die.net/man/7/capabilities.
[18] Are docker containers really secure?.
https://opensource.com/business/14/7/docker-security-selinux.
[19] A. L. Stancu, S. Halunga, A. Vulpe, G. Suciu, O. Fratu, and E. C.
Popovici. A comparison between several software defined networking
controllers. In Telecommunication in Modern Satellite, Cable and
Broadcasting Services (TELSIKS), 2015 12th International Conference
on, pages 223–226, Oct 2015.
[20] Alessio Botta, Alberto Dainotti, and Antonio Pescapè. A tool for the
generation of realistic network workload for emerging networking
scenarios. Computer Networks, 56(15):3531–3547, 2012.