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 11.1 Progetto Monroe . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Capitolo 2 Software Defined Networking 42.1 OpenVSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Capitolo 3 Nodo Monroe 63.1 Bios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . . 8

Capitolo 4 Docker 94.1 Gestione dei permessi in Docker . . . . . . . . . . . . . . . . . . 104.2 Sicurezza in Docker . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Modalita di rete Docker . . . . . . . . . . . . . . . . . . . . . . 11

Capitolo 5 Infrastruttura Virtuale 135.1 Container OpenVSwitch . . . . . . . . . . . . . . . . . . . . . . 155.2 Container Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Container D-ITG . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Evoluzione delle performance su reti mobili [1] . . . . . . . . . 11.2 Architettura del progetto Monroe [2] . . . . . . . . . . . . . . 22.1 Architettura di una rete SDN [3] . . . . . . . . . . . . . . . . 42.2 Principio di funzionamento di OpenVSwitch [4] . . . . . . . . 53.1 Architettura di un Nodo Monroe [2] . . . . . . . . . . . . . . . 63.2 CoreBoot Bios in Virtual Machine . . . . . . . . . . . . . . . . 73.3 Tinycore in Virtual Machine . . . . . . . . . . . . . . . . . . . 84.1 Docker Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Docker:Modalita Bridge [5] . . . . . . . . . . . . . . . . . . . . 124.3 Docker:Modalita Overlay [5] . . . . . . . . . . . . . . . . . . . 125.1 Tipologie di Deployment considerate . . . . . . . . . . . . . . 135.2 Tipologie di Deployment considerate . . . . . . . . . . . . . . 145.3 OpenVSwich Container . . . . . . . . . . . . . . . . . . . . . . 155.4 Ryu Container . . . . . . . . . . . . . . . . . . . . . . . . . . 165.5 ITGSend Container . . . . . . . . . . . . . . . . . . . . . . . . 166.1 Confronto di banda in Upload . . . . . . . . . . . . . . . . . . 196.2 Confronto con 2 Flussi in Upload . . . . . . . . . . . . . . . . 206.3 Confronto con 2 Flussi Poissoniani in Upload . . . . . . . . . . 21

iii

IntroduzioneCapitolo 1

Introduzione

La misura della banda disponibile e uno dei piu importanti e rilevanti am-

biti di ricerca nell’area del monitoraggio di rete. Questa, infatti, e importante

per numerose applicazioni che richiedono una stima di tale valore per adattare

il proprio comportamento. Il caso piu noto e quello delle applicazioni di

video-streaming, che utilizzano differenti tecniche per variare la risoluzione a

fronte della banda disponibile. Questa misura, e 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 e fondamentale per la verifica dei Service Level Agreements. In

contesti di ricerca e 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 quantita di dati.

Una delle piu importanti piattaforme e 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 e dovuta alla sua rapida diffusione e all’avvento di

nuove tecnologie 4G, che prevedono, in teoria, il raggiungimento di velocita

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 universita:

• Simula Research Laboratory

• Politecnico Torino

• IMDEA Networks

• Karlstad University

• Celerway Communications

• Nextworks

• Telenor.

Il progetto e sponsorizzato dall’Unione Europea. L’obiettivo del progettoMonroe e di costruire una piattaforma aperta e flessibile per il deployment diesperimenti di misura su reti mobili e wireless con il supporto a tecnologieMulti-Homed. Il progetto punta a creare un paradigma EaaS (Experimentsas a Service) per gli utilizzatori del servizio, con l’obiettivo di facilitare lagestione e la manutenzione del sistema e di renderlo di immediato utilizzo [9].

1https://www.monroe-project.eu

2

Introduzione

Gli utilizzatori del progetto sono sia dagli utenti del consorzio Monroe, siamembri esterni, tra cui l’Universita Federico II. E’ importante al fine di coor-dinare i vari esperimenti attivi in esecuzione sui diversi nodi di misura, trovareuna metodologia per permettere ai suddetti di eseguire contemporaneamentesenza che cio influenzi il risultato delle loro misure. In questa tesi si vuolepresentare un setup basato su tecnologia SDN per i nodi Monroe, che potraessere utile alla risoluzione del sopraccitato problema.

3

Software Defined NetworkingCapitolo 2

Software Defined Networking

Il paradigma emergente del Software Defined Networking, si pone l’o-

biettivo 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. E bene

notare che il controller, nonostante porti alla centralizzazione dell’intelligenza

della rete, deve essere adeguatamente distribuito su piu entita fisiche, per

evitare un Single Point of Faliure e per garantire ai dispositivi di rete, la

stessa affidabilita 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. E 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 e una delle implementazioni piu utilizzate e famose di switchSDN software. Il suo successo e dovuto alla scarsa disponibilita iniziale eall’elevato costo di switch hardware OpenFlow. OpenVSwitch e formato dadue 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 illustratoin Figura 2.2

Figura 2.2: Principio di funzionamento di OpenVSwitch [4]

All’arrivo di un pacchetto, il modulo kernel provvede ad intercettarlo econtrolla nella propria tabella all’interno del kernel se vi e una regola perprocessarlo. Se il modulo kernel non trova una regola adatta, provvede altrasferimento del pacchetto, attraverso una netlink socket, al demone inuserspace, che successivamente controlla nella propria tabella se vi sono regoleper il processamento. Se anche in userspace la regola non e presente allora ildemone in userspace interroga il controller [4].

5

Nodo MonroeCapitolo 3

Nodo Monroe

Il nodo Hardware Monroe e equipaggiato con una APU1D4 . L’APU1D4

e 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 e stato testato in diverse condizioni di umidita e temperatura.

In particolare e stato rilevato che i Modem Usb MiFi si spegnevano al

superamento della temperatura di 55◦C e di una percentuale di umidita

relativa del 60%. La restante parte dei dispositivi ha funzionato regolarmente

durante uno stress test con temperatura di 70◦C e umidita 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’instabilita di alcuni

dispositivi connessi via USB [11].

La sezione di alimentazione risulta critca anche a causa di continui cicli di

on/off a cui e soggetto il nodo, e alla indisponibilita di un’alimentazione a

220V AC.

3.1 Bios

Nella prima fase dello sviluppo del nostro setup, si e 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 e

deciso di emulare il sistema attraverso il software di virtualizzazione QEMU.

La board e fornita con CoreBoot, un bios opensource, dunque si e scelto di

ricompilare ed emulare anche quest’ultimo.

CoreBoot e un firmware opensource per dispositivi embedded e PC che offre

un’esperienza di avvio veloce e affidabile [12].

Si e 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 e possibile usare per questo scopo sono numerosi, inclusa la

possibilita di inserire l’intero kernel Linux come payload. Nel nostro caso si e

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 e deciso di

focalizzarsi sull’OS di default del produttore della APU. Si e successivamen-

te 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 e 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 diOpenVSwitch, pertanto si e reso necessario compilare quest’ultimo dai sorgenti.Durante la compilazione ci si e resi conto che per il corretto funzionamentodi OpenVSwitch e necessario caricare alcuni moduli kernel, e per la correttacompilazione era necessaria una versione di GCC piu recente.Successivamente siamo stati informati dai membri del progetto Monroe che ilsistema operativo ufficiale scelto per la board e Debian Jessie con Kernel 4.6prelevato dai repository debian backport.Gli esperimenti, inoltre, potranno essere eseguiti tramite macchina virtuale ocontainer Docker. Allo stato attuale solo l’implementazione dei container epronta all’uso,di conseguenza si e deciso di focalizzarsi su un setup container-based.

8

DockerCapitolo 4

Docker

Un container software e 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, e necessario emulare l’intero sistema opera-

tivo ospite, incluso il kernel. Cio, 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, poiche 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 e 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 pro-

getti piu seguiti su GitHub [14]. E 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 e 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’u-

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

te distribuibili attraverso repository privati o pubblici,quale il DockerHub.

4.1 Gestione dei permessi in Docker

Di base, Docker esegue i container in modalita non privilegiata. Questa

impostazione non permette, ad esempio di modificare gli indirizzi ip dell’inter-

faccia di rete, caricare moduli kernel o eseguire il demone Docker all’interno

di Docker. Una modo per eseguire questa tipologia di operazioni e l’utiliz-

zo dei container in modalita 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 possibilita di scegliere se quest’ultimo puo

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

nel 2.2, che hanno modificato la precedente situazione in cui vi erano due

uniche modalita di esecuzione di processi, o con UID 0 privilegiata o con

UID diverso da 0 in modalita non privilegiata. Le capabilities provvedono

alla separazione dei vari privilegi fornendo un ulteriore livello di astrazione

10

Docker

e sicurezza al sistema. E 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 piu 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 Modalita 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 piu granulare dei container. Si

possono creare sia reti bridge che reti overlay, inoltre e possibile realizzare

plugin di rete proprietari. Le reti Bridge sono simili alla rete docker0, nella

loro creazione e possibile specificare il range di indirizzi assegnati,il default

gateway e se la rete e interna o esterna. Le reti Bridge sono di tipo Natted,

pertanto per esporre un servizio all’esterno e necessario “pubblicare” la porta.

1https://github.com/docker/docker/releases/tag/v1.9.0

11

Docker

Figura 4.2: Docker:Modalita Bridge [5]

La modalita 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:Modalita Overlay [5]

E possibile implementare un’ulteriore modalita di rete SDN attraversol’ausilio di OpenVSwitch. Per realizzare cio, e necessario utilizzare la modalitadi rete none e successivamente collegare i container docker allo switch SDN.Per il collegamento dei container allo switch e possibile utilizzare l’estensioneovs-docker2 attraverso il comando:ovs-docker add-port ovs-br1 eth0 containern –ipaddress=192.168.1.33/24eth0 e l’interfaccia di rete che verra associata all’interno del container, contai-nern e il nome del container e 192.168.1.33/24 e l’indirizzo ip con la netmaskassociata.

2https://github.com/openvswitch/ovs/blob/master/utilities/ovs-docker

12

Infrastruttura VirtualeCapitolo 5

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

VSwitch sul sistema host fisico e 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 e 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, rappresen-

ta un compromesso tra la flessibilita 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 e

eseguito all’interno di un container Docker e tutti i container sono intercon-

nessi 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 e possibile lanciare i vari container docker associandoli

ad un bridge attraverso la specifica –net nomerete

Docker, per scelte implementative, allo stato attuale permette l’associa-

zione di una sola rete all’avvio del container. Per associare ulteriori reti

e necessario, dopo aver eseguito il comando run, digitare da terminale il

seguente comando:

docker network connect nomerete nomecontainer

Si e 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 e stato necessario, a causa della richiesta

del caricamento di alcuni moduli kernel, montare all’interno del container in

modalita 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

priorita)

• NET ADMIN (per permettere la modifica degli indirizzi ip delle inter-

faccie)

Nel DockerFile ritroviamo le istruzioni che provvedono a scaricare OpenV-

Switch 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 e 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 e 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 modalita e topologie di rete. Nel nostro caso, e stato utilizzato un

semplice script di esempio per l’implementazione di uno switch Layer 2 con

autoapprendimento.1

Il container con Ryu necessita solamente del privilegio di NET ADMIN,

che come gia specificato, e 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 e necessario fornirgli uno script Python contenente

la configurazione desiderata.

5.3 Container D-ITG

Sono dei semplici container con D-ITG configurati in modalita sender ereceiver.

Figura 5.5: ITGSend Container

1https://github.com/osrg/ryu/blob/master/ryu/app/simple switch.py

16

Analisi delle prestazioni di rete di DockerCapitolo 6

Analisi delle prestazioni di rete di Docker

E stato realizzato uno scenario di test per effettuare delle misure di achie-

vable 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 e 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 SenderCPU: Intel T3300 Intel Q8300RAM: 2 GB DDR3 4GB DDR3NET: Atheros AR8131 Realtek 8111C

Tabella 6.1: Specifiche Hardware

Sul Sender sono stati instanziati i tool nelle 3 modalita descritte, mentre

il Receiver e stato posto in modalita nativa emulando di fatto il server di

misura, come previsto dall’architettura finale.

Per effettuare la misura di achievable throughput si e 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 Gene-

rator) e una piattaforma per la generazione di traffico sintetico e trace-based,

multipiattaforma e distribuita[20]. Il traffico di congestione e stato generato

con i parametri riporatati in tabella 6.2

Native Docker FullDockerPacket Size 1470 Byte 1470 Byte 1470 Byte

InterPacket Time Richiesto 300805 pkt/s 300805 pkt/s 300805 pkt/sInterPacket Time Ottenuto 32620 pkt/s 28407 pkt/s 24501 pkt/s

BitRate Richiesto 3.537 Gb/s 3.537 Gb/s 3.537 Gb/sBitRate Medio Ottenuto 383.6 Mb/s 334.1 Mb/s 288.1 Mb/s

Duration 10s 10s 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 computa-

zione, le quali hanno influenzato pesantemente il comportamento di D-ITG.

Si e riscontrato, inoltre,il seguente comportamento anomalo: forzando il

rate al valore ottenuto empiricamente in ricezione, quest’ultimo diminuiva

ulteriormente. Si e dunque deciso di effettuare le misure in modo da mas-

simizzare i tassi di ricezione. L’intero esperimento, attraverso l’ausilio di

script di automatizzazione appositamente creati, e 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 e possibile notare dai BoxPlot in Figura 6.1, la modalita nativa

risulta essere, come da previsioni, quella con migliori prestazioni. La modalita

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.

1http://www.gnuplot.info/

18

Analisi delle prestazioni di rete di Docker

Figura 6.1: Confronto di banda in Upload

F1 Native F1 Docker F1 FullDockerPacket Size 1470 Byte 1470 Byte 1470 Byte

IPT Richiesto 75080 pkt/s 70080 pkt/s 50080 pkt/sIPT Ottenuto 5143 pkt/s 5529 pkt/s 4814 pkt/s

BitRate Richiesto 882.9 Mb/s 824.1 Mb/s 588.9 Mb/sBitRate Medio Ottenuto 60.48 Mb/s 65.02 Mb/s 56.61 Mb/s

Duration 10 s 10 s 10 s

F2 Native F2 Docker F2 FullDockerPacket Size 1470 Byte 1470 Byte 1470 Byte

IPT Richiesto 75080 pkt/s 70080 pkt/s 50080 pkt/sIPT Ottenuto 4986 pkt/s 5282 pkt/s 5027 pkt/s

BitRate Richiesto 882.9 Mb/s 824.1 Mb/s 588.9 Mb/sBitRate Medio Ottenuto 58.64 Mb/s 62.12 Mb/s 59.12 Mb/s

Duration 10 s 10 s 10 s

Tabella 6.3: Parametri dei due Flussi

E stato realizzato un altro esperimento con due flussi da due contai-

ner(processi nel caso nativo) diversi con i parametri riportati in Tabella 6.3

Si e 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. E stata valutata la possibilita di utilizzare

un’interfaccia di rete solo per il signaling, tuttavia tale opzione e stata scartata

poiche essa non e prevista per i nodi reali, di contro sara possibile tramite

SDN rendere prioritario il traffico di signaling, ottenendo cosi migliori risultati.

Ci si e dunque posti su rate piu “conservativi” in modo da ottenere risultati

significativi. L’esperimento di generazione e 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. E 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. E

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

F1 Native F1 Docker F1 FullDockerPacket Size 1470 Byte 1470 Byte 1470 Byte

IPT Richiesto 75080 pkt/s 70080 pkt/s 50080 pkt/sIPT Ottenuto 5538 pkt/s 5235 pkt/s 5450 pkt/s

BitRate Richiesto 882.9 Mb/s 824.1 Mb/s 588.9 Mb/sBitRate Medio Ottenuto 65.12 Mb/s 61.57 Mb/s 64.09 Mb/s

Duration 10 s 10 s 10 s

F2 Native F2 Docker F2 FullDockerPacket Size 1470 Byte 1470 Byte 1470 Byte

IPT Richiesto 75080 pkt/s 70080 pkt/s 50080 pkt/sIPT Ottenuto 5630 pkt/s 5662 pkt/s 4635 pkt/s

BitRate Richiesto 882.9 Mb/s 824.1 Mb/s 588.9 Mb/sBitRate Medio Ottenuto 66.21 Mb/s 66.58 Mb/s 54.51 Mb/s

Duration 10 s 10 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 decisa-mente variabile, che tende ad assestarsi solo nel caso FullDocker.

21

ConclusioniCapitolo 7

Conclusioni e Sviluppi Futuri

In questo lavoro si e visto come produrre un setup di base con OpenV-

Switch e Docker per gestire il traffico dei nodi Monroe. Abbiamo analizzato

ed illustrato parte della tecnologia Docker e il nuovo paradigma Software

Defined Networking.

E 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 piu nel dettaglio le due

modalita container-based.

E stato infine valutato l’impatto sulle prestazioni di rete dovuto all’approccio

container-based mettendolo in relazione ad una configurazione nativa, otte-

nendo alcuni risultati significativi riguardo alle prestazioni.

Come sviluppi futuri si individuano diverse possibilita:

• 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 e 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 risultera 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: Acomprehensive survey. Proceedings of the IEEE, 103(1):14–76, Jan 2015.

[4] H. Y. Pan and S. Y. Wang. Optimizing the sdn control-planeperformance of the openvswitch software switch. In 2015 IEEESymposium 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. Bandwidthestimation: metrics, measurement techniques, and tools. IEEE Network,17(6):27–35, Nov 2003.

[7] Manish Jain and Constantinos Dovrolis. Ten fallacies and pitfalls onend-to-end available bandwidth estimation. In Proceedings of the 4thACM SIGCOMM Conference on Internet Measurement, IMC ’04, pages272–277, New York, NY, USA, 2004. ACM.

[8] Antonio Pescape. Large scale plataforms. University Lecture, 2016.

[9] Andra Lutu Min Xie and Ozgu Alay. Report on use cases. Technicalreport, 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. SIGCOMMComput. Commun. Rev., 38(2):69–74, March 2008.

[11] Hansen Thomas Hirsch Kristian Evensen Jonas Werme Tobias LogrenDely Roberto Monno Vincenzo Mancuso Anna Brunstrom Ozgu AlayAndra 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 networkingcontrollers. In Telecommunication in Modern Satellite, Cable andBroadcasting Services (TELSIKS), 2015 12th International Conferenceon, pages 223–226, Oct 2015.

[20] Alessio Botta, Alberto Dainotti, and Antonio Pescape. A tool for thegeneration of realistic network workload for emerging networkingscenarios. Computer Networks, 56(15):3531–3547, 2012.