Configurazione di un testbed wireless

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori I Configurazione di un testbed wireless Anno Accademico 2011/2012 Candidato: Antonio Montieri matr. N

2

3 Indice Introduzione 5 Capitolo 1. Sistemi per l emulazione di rete basata su cluster Computer cluster Emulazione di rete Virtualizzazione Virtualizzazione completa Emulazione assistita Virtualizzazione a livello di sistema operativo Paravirtualizzazione Xen 12 Capitolo 2. Cenni su Neptune e VirtualMesh Neptune Architettura Creazione della rete virtuale Il concetto di esperimento in Neptune Descrittore del cluster Descrittore della topologia VirtualMesh Architettura Modello di simulazione Valutazioni ed estensioni Integrazione VirtualMesh in Neptune 20 Capitolo 3. OMF Panoramica Architettura Aggregate Manager Experiment Controller Resource Controller Struttura Servizi installati sul SO Server di scambio messaggi 25 III

4 3.3.3 Database Reti di collegamento Un caso d uso: la sperimentatrice Alice 26 Capitolo 4. Integrazione di Neptune con OMF Integrazione con OMF Primo livello di script Secondo livello di script Aggiornamento ad OMF Aggiornamento Resource Controller Aggiornamento Aggregate Manager/Experiment Controller Salvataggio delle immagini dei template 33 Conclusioni 34 Appendice A 35 Bibliografia 42 IV

5 Introduzione Al giorno d oggi Internet e, per estensione, le tecnologie di rete hanno invaso la nostra vita quotidiana e cambiato radicalmente il modo di comunicare e accedere a qualsiasi fonte di informazione. La loro massiccia e capillare diffusione e il conseguente aumento della loro complessità, tuttavia, hanno anche evidenziato diversi limiti che hanno spinto ricercatori e industrie a sviluppare nuove tecnologie. Uno dei principali problemi in questo senso è quello di trovare soluzioni a basso costo per affinare e testare nuovi protocolli di rete e che allo stesso tempo garantiscano un certo livello di flessibilità per valutare le performance in diverse situazioni e per diverse topologie di reti, eventualmente relative sia ad uno scenario wired che wireless. Una soluzione che ha riscontrato notevole successo è l emulazione di rete basata su cluster. Il progetto Neptune, sviluppato e implementato presso l Università degli Studi di Napoli Federico II [1], si inserisce nel contesto di queste soluzioni e ha lo scopo di fornire un architettura flessibile per l emulazione di reti, adoperando un cluster di macchine general purpose (x86), virtualizzazione delle risorse e approccio multi-user con accesso da remoto. In tal modo ogni nodo della rete è una macchina virtuale, basata su Xen, istanziata sull architettura cluster di workstations fisiche. Allo stato di sviluppo attuale Neptune è stato integrato con i framework VirtualMesh e OMF che permettono rispettivamente: di allargare il campo di test di Neptune a scenari di reti Mesh e MANET e di controllare e gestire esperimenti su testbed di rete. In particolare tramite Neptune e VirtualMesh si vanno a creare la rete di test (eventualmente wireless) e di controllo di cui OMF necessita per poter operare. In questo lavoro di tesi è stato effettuato un processo di aggiornamento e ingegnerizzazione del sistema software Neptune. In particolare è stato effettuato l aggiornamento del framework integrato OMF, portandolo alla versione 5.4. A tal fine è stato automatizzato il processo di integrazione dei due sistemi software, sfruttando i risultati di un precedente lavoro di tesi sviluppato presso questa Università [2] e apportando le dovute modifiche per il supporto alla nuova release di OMF. 5

6 Nello specifico in questo elaborato si tratteranno i seguenti argomenti, suddivisi in altrettanti capitoli: Aspetti generali dell emulazione di rete cluster-based, con riferimenti alla virtualizzazione delle macchine e alla soluzione adottata da Xen. Panoramica del sistema Neptune, cenni sul framework VirtualMesh e loro integrazione. Analisi dettagliata del framework per il controllo e la gestione dei testbed di rete OMF. Lavoro di aggiornamento e integrazione di Neptune e OMF. 6

7 Capitolo 1 Sistemi per l emulazione di rete basata su cluster 1.1 Computer Cluster Si definisce computer cluster, o più semplicemente cluster (dall inglese grappolo ) un insieme di computer connessi tramite una rete telematica ad alta velocità. Lo scopo principale di un cluster è quello di distribuire un elaborazione estremamente complessa tra le macchine componenti, fornendo al contempo all utente un astrazione che permette di considerare l insieme di macchine come un unica risorsa. Sostanzialmente viene sfruttata la possibilità di suddividere un problema complesso in sottoproblemi più semplici, che vengono risolti tramite elaborazione parallela dai componenti del cluster. Un architettura cluster dovrebbe garantire in sostanza il seguente insieme di servizi: Alto rendimento con costi contenuti rispetto ad un singolo calcolatore. Alta disponibilità e quindi maggiore tolleranza ai fallimenti. Bilanciamento del carico ed eliminazione dei colli di bottiglia con conseguente aumento prestazionale. Scalabilità e facilità di incremento per far fronte a maggiori richieste computazionali. A seconda degli scopi per i quali sono destinati, i cluster vengono solitamente classificati in tre categorie: Load Balancing cluster: sono utilizzati per la distribuzione automatica del carico tra le diverse macchine componenti, in maniera tale da schedulare nuove richieste di elaborazione verso le macchine più scariche. High Availability cluster: detti anche Fail-over, sono caratterizzati da un certo livello di ridondanza, che permette la continuazione dei servizi anche nel momento in cui un componente del cluster fallisce; in questo modo si elimina di fatto il problema del single point of failure che affligge un singolo elaboratore. High Performance Computing (HPC) cluster: costituiscono soluzioni ad alte prestazioni per il calcolo parallelo con costi molto più contenuti rispetto ai supercomputer. I componenti sono interconnessi con link ad alta velocità e vengono utilizzati protocolli di 7

8 rete a basso overhead per migliorare le prestazioni. Vengono impiegati perlopiù nei centri di elaborazione dati. Dopo aver definito cosa si intende per computer cluster, chiariamo il concetto di emulazione di rete. 1.2 Emulazione di rete Lo studio di un sistema reale, di cui una rete di calcolatori ne costituisce un esempio, può essere affrontato secondo tre diversi approcci: simulazione, emulazione e ambienti di testbed, ognuno caratterizzato da caratteristiche e peculiarità differenti. La simulazione è un processo di imitazione delle operazioni eseguite nel tempo da un sistema reale. In particolare rappresenta la trasposizione in termini logico-matematico-procedurali di un modello concettuale della realtà. Tale modello, comunemente riferito come modello matematico, viene definito come l insieme dei processi che hanno luogo nel sistema valutato, il cui insieme permette di definire le logiche di funzionamento del sistema stesso. I metodi di simulazione sono utilizzati per analizzare i più svariati sistemi nelle diverse branchie dell ingegneria e non solo (Es. Sistemi di elaborazione e comunicazione, sistemi naturali, militari, socio-economici, ecc.). Nell ambito delle reti la simulazione fornisce un ambiente ripetibile e controllato per l esecuzione di un esperimento, consentendo l utilizzo di strumenti di semplice configurazione per la progettazione e l implementazione di protocolli a diversi livelli di astrazione. Un ambiente di testbed è un infrastruttura di rete realizzata ad hoc per la valutazione e la verifica di una particolare applicazione distribuita. In tal modo si ottiene un ambiente di testing molto simile a quello in cui l applicazione lavorerà durante il suo normale funzionamento. Tutte le parti di un testbed sono realizzate con componenti reali. In questo modo si realizza un testing rigoroso, trasparente e replicabile dell applicazione, pagando con un costo economico più elevato, una minore scalabilità e flessibilità. L emulazione rappresenta una metodologia intermedia tra la simulazione e gli ambienti di testbed, che combina, quindi, sia elementi reali che astratti. Consente di analizzare il comportamento di un sistema reale attraverso un modello concettuale, ma permette altresì al sistema di interfacciarsi con il mondo esterno, eseguendo in tempo reale e fornendo un ambiente molto più vicino alla realtà rispetto a quello di una simulazione pura. A seconda delle risorse disponibili e dei requisiti di esperimento viene deciso quali elementi vengono implementati come reali e quali come parzialmente o totalmente simulati. Per quanto riguarda le reti, sovente la parte simulata riguarda l infrastruttura. Ad esempio è possibile valutare le prestazioni di una nuova applicazione o protocollo (reale) con diverse condizioni del canale trasmissivo (simulato). Come già accennato, la piattaforma Neptune oltre ad utilizzare un emulazione di rete basata su cluster, fonda il suo funzionamento sulla virtualizzazione delle risorse. Vediamo, dunque, cosa si intende per virtualizzazione, analizzando in particolare la soluzione offerta da Xen, il software utilizzato da Neptune per espletare questo compito. 8

9 1.3 Virtualizzazione Solitamente quando si ha a che fare con l emulazione di una rete si pensa ad ogni nodo, che fa parte dello scenario di emulazione, come ad un computer fisico all interno del testbed emulato. Una soluzione di questo tipo presenta degli svantaggi in termini di scalabilità nel momento in cui è necessario emulare una rete con un gran numero di nodi, che solitamente non sono disponibili fisicamente agli sperimentatori. Inoltre un buon numero di applicazioni, sottoposte a test, è sviluppato per macchine con capacità computazionali poco elevate (Es. Applicazioni per la telefonia cellulare) e quindi si può pensare di ripartire le risorse di un nodo reale tra più nodi virtuali su ognuno dei quali sarà eseguita un istanza del software sotto test. In effetti la virtualizzazione nasce negli anni 60 con un intento simile: partizionare l hardware molto costoso dei mainframe di grandi dimensioni per ottimizzarne l utilizzo. Al giorno d oggi i meccanismi di virtualizzazione vengono utilizzati nei più svariati campi della computer science, portando diversi vantaggi in termini di maggiore efficienza, affidabilità e sicurezza delle architetture hardware. Da un punto di vista generale le tecnologie di virtualizzazione puntano a disaccoppiare il funzionamento logico delle risorse hardware e software di un sistema di elaborazione dalla loro realizzazione fisica. Il disaccoppiamento è ottenuto introducendo tra le due viste della risorsa, la logica e la fisica, un livello di indirezione la cui realizzazione dipende dal tipo di virtualizzazione che si intende adottare. Il concetto di astrazione è un primo esempio di virtualizzazione. In Figura 1.1 questo caso l obiettivo è semplificare l uso di una risorsa nascondendo alcuni aspetti di dettagli relativi alla sua realizzazione. Si parla in questo caso di risorsa virtuale (oggetto astratto) e il livello di indirezione è costituito dalle operazioni (interfaccia) con le quali è possibile accedere alle risorse. Un diverso utilizzo del concetto di virtualizzazione, prevede l introduzione di un livello di indirezione, che si chiama Virtual Machine Monitor (VMM) o hypervisor il cui compito è quello di trasformare la singola interfaccia di macchina fisica in N interfacce virtuali. Ciascuna di queste interfacce (macchine virtuali) è una replica della macchina fisica, dotata quindi di tutte le istruzioni del processore (sia privilegiate che non privilegiate) e delle risorse del sistema (memoria, dispositivi di I/O). Su ogni macchina virtuale può essere eseguito un sistema operativo. Compito del VMM è quindi consentire la condivisione da parte di più macchine virtuali di una singola piattaforma hardware. Esso si pone come mediatore unico nelle interazioni tra le macchine virtuali e l hardware sottostante, garantendo un forte isolamento tra loro e la stabilità complessiva del sistema. 9

10 Attualmente sono disponibili diversi strumenti di virtualizzazione come Xen, VMware Workstation, Virtual PC e VirtualBox. Ognuno di essi offre una soluzione diversa per realizzare la virtualizzazione delle risorse (e ovviamente il VMM), nonché per risolvere le problematiche ad essa legate, che, come abbiamo già accennato, sono relative in particolare all isolamento tra gli ambienti virtuali e alla gestione delle contese delle risorse hardware. Al di là dei modi diversi in cui si può progettare un VMM, esso deve comunque soddisfare poche condizioni essenziali: fornire un ambiente per i programmi sostanzialmente identico a quello della macchina reale; garantire un elevata efficienza nell esecuzione dei programmi; possedere caratteristiche di elevata semplicità. Normalmente viene indicato con il termine host la piattaforma di base sulla quale si realizzano macchine virtuali, che comprende la macchina fisica, l eventuale sistema operativo e il VMM; si indica invece con il termine guest tutto ciò (applicazioni e sistema operativo) che ha a che fare con la macchina virtuale. Diamo ora un cenno alle categorie all interno delle quali possono essere raggruppate le tecniche di virtualizzazione: Virtualizzazione completa. Emulazione assistita. Virtualizzazione a livello di sistema operativo. Paravirtualizzazione Virtualizzazione completa La virtualizzazione completa (Full virtualization) prevede che l hardware virtuale esposto dal VMM sia funzionalmente identico a quello della sottostante macchina fisica. In questo modo è possibile installare dentro le macchine virtuali sistemi operativi standard non modificati (o non modificabili per ragioni di licenza) in un ambiente totalmente ricreato e isolato dal sistema operativo host. Tale ambiente è realizzato da un apposito software che si occupa di emulare l hardware necessario traducendo le istruzioni eseguite dal sistema operativo guest in qualcosa che il sistema operativo host sia in grado di eseguire. In particolare, all interno della macchina virtuale, tutte le istruzioni non privilegiate sono eseguite direttamente sul microprocessore del calcolatore (esecuzione diretta), mentre il VMM si fa carico solamente di intercettare le richieste di accesso privilegiato all hardware e ne emula il comportamento atteso. Per questo motivo, sebbene esistano anche emulatori di CPU differenti dall'architettura x86, questi tendono ad essere molto lenti poiché devono tradurre ogni istruzione verso l'architettura x86, eseguirla, e quindi tradurne il risultato verso l'architettura emulata. Tra i prodotti disponibili attualmente che adottano la virtualizzazione completa si possono annoverare: VirtualBox, VMware, Qemu ed Hercules. 10

11 1.3.2 Emulazione assistita L emulazione assistita (Hardware assisted virtualization) permette di ottenere un efficienza maggiore della virtualizzazione completa, grazie a speciali funzioni della CPU, consentendo l esecuzione direttamente in hardware di alcune chiamate della macchina virtuale. Intel e AMD attraverso le rispettive tecnologie VT-x e AMD-V hanno introdotto nei processori dell architettura x86 il supporto a tale tecnica di virtualizzazione. Una precisazione che occorre fare è che l'attuale virtualizzazione assistita si occupa di aiutare solamente le funzioni di CPU e memoria; tutte le funzionalità di I/O sono ancora emulate. Una curiosità: è conosciuta anche come Accelerated virtualization e con nomi diversi a seconda del produttore; ad esempio Xen la chiama Hardware Virtual Machine (HVM) Virtualizzazione a livello di sistema operativo La virtualizzazione a livello di sistema operativo è una tecnologia che si basa sull utilizzo di un sistema operativo, opportunamente modificato, che prevede un unico kernel in esecuzione, il quale gestisce più spazi utente multipli isolati (macchine virtuali dette containers). Oltre al meccanismo di isolamento, il kernel spesso provvede a un gestore delle risorse che limita l impatto di un container su un altro. Con tale approccio si ha un bassissimo overhead per la gestione della virtualizzazione, al prezzo di non poter istanziare macchine virtuali che eseguono sistemi operativi con kernel differenti sulla stessa macchina fisica. Ad esempio non è possibile avere due macchine virtuali, una Linux e un altra Windows, mentre è possibile avere installate due distribuzioni differenti di Linux, a patto che utilizzino la stessa versione del kernel. Esempi di prodotti che utilizzano la virtualizzazione a livello di sistema operativo sono: OpenVZ (Virtuozzo), Linux-VServer, Solaris Containers Paravirtualizzazione La paravirtualizzazione prevede che il VMM (hypervisor) esponga ad ogni macchina virtuale interfacce hardware simulate funzionalmente simili, ma non identiche, alle corrispondenti interfacce fisiche: piuttosto che emulare le periferiche hardware esistenti, il VMM espone una libreria di chiamate (Virtual Hardware API) che implementa una semplice astrazione delle periferiche. Occorre dunque modificare il kernel ed i driver dei sistemi operativi guest per renderli compatibili con la virtual hardware API del VMM utilizzato. La complicazione di dovere modificare i sistemi guest è però ripagata da una maggiore semplicità ed efficienza di esecuzione del VMM, che non deve preoccuparsi di intercettare in modo complicato accessi alle risorse hardware, ma si avvale della loro diretta collaborazione. Inoltre, dal momento che l interfaccia tra il sistema operativo guest e le applicazioni non viene assolutamente toccata, queste non devono essere in alcun modo modificate. 11

12 D altro canto la modifica del kernel dei sistemi guest risulta problematica nel caso di prodotti come Windows che, per motivi di licenza, non permettono tale operazione. Xen, ad esempio, permette l'installazione di sistemi operativi Linux con kernel modificato e driver personalizzati. Oltre al già citato Xen, un altro prodotto che si basa sulla paravirtualizzazione è il software KVM Xen Xen è un Virtual Machine Monitor nato come progetto del University of Cambridge Computer Laboratory; attualmente è sviluppato e rilasciato dalla Xen.org Community sotto la GNU General Public License (GPLv2). Può essere installato ed eseguito su diverse architetture quali x86-32, x86-64, IA-64, ARM e PowerPC 970. Questo sistema di virtualizzazione non è installabile su un sistema operativo già configurato, ma lo va a sostituire prendendo direttamente il controllo dell hardware della macchina: questo consente un consumo minimo di risorse ed elevate performance. Diamo ora un cenno all architettura di Xen, mostrata in figura 1.2. L hypervisor Xen è un sottile strato software che ha il ruolo di mettere in comunicazione l hardware dell host fisico con il sistema operativo delle macchine virtuali. Esso si colloca direttamente sopra l hardware della macchina fisica e gestisce tutte le problematiche di più basso livello (Es. Scheduling del processore, gestione della memoria e degli interrupt); inoltre controlla e gestisce l esecuzione delle macchine virtuali Figura 1.2 ed è il primo programma che viene eseguito al termine del boot loader. Non si occupa invece delle funzionalità di più alto livello (Es. Funzionalità di rete e I/O), che sono delegate a Domain 0. Il Domain 0 (Dom0 o Control Domain) è una virtual machine speciale con permessi privilegiati per accedere all hardware direttamente, gestire tutti gli accessi alle risorse di I/O e interagire con le altre virtual machines. Esso fornisce un interfaccia di controllo attraverso la quale è possibile operare sul sistema. È l unico domain che ha accesso diretto all hypervisor e senza il quale non è possibile di fatto eseguire altre macchine virtuali; per questo motivo è il primo che viene eseguito dal sistema. Con Domain U (DomU o Guest Domains) si indicano tutte le macchine virtuali diverse da Dom0, ognuna caratterizzata dal proprio sistema operativo e applicazioni. Xen supporta due tipologie di virtualizzazione per le DomU: paravirtualizzazione (PV guest) e hardware assisted virtualization 12

13 (HVM guest). Entrambe le tipologie di guest possono essere utilizzate allo stesso tempo su un sistema Xen. Buona parte del successo riscontrato da Xen è dovuto all utilizzo della paravirtualizzazione, che, come sappiamo, permette di ottenere un decadimento delle performance minimo rispetto all esecuzione non virtualizzata, ma necessita della modifica del kernel dei sistemi guest ed è per questo adatta solo a sistemi operativi open source. Inizialmente Xen supportava solo la paravirtualizzazione; successivamente grazie all introduzione nelle CPU host delle tecnologie Intel VT-x e AMD-V è stato aggiunto il supporto alla HVM. I sistemi HVM guest non necessitano di alcuna modifica al kernel o driver specifico e ciò significa che è possibile usare anche sistemi operativi proprietari (Es. Windows) come guest. Trattandosi comunque di una tecnologia di emulazione assistita (le richieste di operazioni di I/O sono intercettate dal Dom0 ed emulate dall hypervisor), le performance in questo caso sono solitamente inferiori rispetto alla paravirtualizzazione. In questo caso, per incrementare le prestazioni, Xen prevede l utilizzo di una tecnica chiamata PV on HVM. I sistemi HVM guest, infatti, possono utilizzare speciali drivers paravirtuali (riferiti come PVHVM o PV-on-HVM drivers) ottimizzati per gli ambienti HVM, che permettono di bypassare l emulazione delle operazioni di I/O (su disco e interfacce di rete) e garantiscono prestazioni in linea con quelle dei PV guest. Oltre ai vantaggi della paravirtualizzazione, le soluzioni adottate da Xen nel caso di sistemi HVM guest proprietari, rendono questo sistema ideale per l applicazione nell ambito dell emulazione di rete. 13

14 Capitolo 2 Cenni su Neptune e VirtualMesh 2.1 Neptune Neptune (Network Emulation for Protocol TUNing and Evaluation) è un progetto di un emulatore di rete flessibile, orientato al multiplexing delle risorse di calcolo e memorizzazione, adoperante l approccio cluster-based. È stato sviluppato presso l Università di Napoli Federico II [1] principalmente con lo scopo di valutare nuovi protocolli di rete. Esso basa il suo funzionamento sull utilizzo della paravirtualizzazione offerta da XEN, che permette di emulare complesse topologie di rete evitando di sfruttare hardware specifico e quindi consente a Neptune di essere installato su architetture general purpose (x86), garantendo al contempo bassi costi di implementazione ed elevate performance, grazie al basso overhead richiesto dal funzionamento di XEN. Neptune è facilmente utilizzabile attraverso un interfaccia web-based e garantisce la sicurezza delle sessioni di lavoro grazie all utilizzo di tecnologie di comunicazione basate su tunneling SSH (Secure SHell) Architettura L architettura di Neptune segue un approccio centralizzato alla gestione dell intero sistema. Uno dei nodi del cluster, detto Neptune Manager, offre i servizi fondamentali (Es. dns, dhcp, ecc.) e ospita il software di gestione della configurazione del sistema. Da un punto di vista logico è possibile immaginare un organizzazione a due livelli: uno formato dal Manager, che si occupa di realizzare i servizi di gestione del cluster e la comunicazione con l esterno, e l altro formato dai nodi dell infrastruttura di emulazione vera e propria Creazione della rete virtuale Come abbiamo già accennato, Neptune si avvale della paravirtualizzazione per realizzare l allocazione di topologie di rete, anche estremamente complesse, in maniera automatica. La definizione di una topologia consiste essenzialmente nel definire link bidirezionali che interconnettono macchine (nodi) virtuali gestite tramite l hypervisor Xen. Per la creazione dei nodi, 14

15 Neptune mantiene un repository di template, cioè modelli di macchine virtuali, che sono istanziati solo quando è necessario, realizzando una macchina virtuale in tutto e per tutto uguale al template. Ogni macchina fisica risulta quindi un mero contenitore per i nodi emulati che risiedono su di esse. Per quanto riguarda l emulazione dei link è necessario distinguere tra collegamenti wired e wireless. Nel caso wireless ci avvaliamo del supporto del framework VirtualMesh, descritto nel prossimo paragrafo. Viceversa Neptune ci permette di creare link wired, simulando i parametri caratteristici di ognuno di questi (Es. Bandwidth, delay, loss rate, ecc.) e realizzando ciascuna connessione con caratteristiche indipendenti dalle altre presenti sulla stessa LAN (link multiplexing). Nello specifico possono essere utilizzate due tecniche di link multiplexing: IP aliasing: la definizione del link avviene direttamente a livello IP. Sulla stessa interfaccia vengono gestiti più indirizzi IP, ciascuno rappresentante un end-point di un link. One Link Per Interface: ogni end-point di un link richiede un interfaccia dedicata. Ogni link, quindi, è modellato come una connessione diretta fra due interfacce di rete Il concetto di esperimento in Neptune Nella definizione di un esperimento in Neptune sono coinvolte due tipologie di attori: Amministratore: ha il compito di gestire la configurazione di ogni nodo fisico facente parte del cluster. Fra i compiti dell amministratore rientrano la scelta di quale esperimento allocare e la configurazione dei nodi virtuali sui nodi fisici. Utente: definisce ed esegue esperimenti. In figura 2.1 sono mostrate le interazioni dei due tipi di attori con il sistema durante la creazione e la successiva allocazione di un esperimento: Figura

16 Neptune definisce un esperimento come un insieme di quattro informazioni: identificativo univoco, nome del proprietario (creatore) dell esperimento, topologia e risorse possedute, stato. Soffermandoci su quest ultima informazione, lo stato rappresenta la storia dell esperimento e, nello specifico, questi può trovarsi in uno dei seguenti cinque possibili stati: Undefined: l esperimento è stato creato e gli sono stati associati un identificativo e un amministratore, ma nessuna informazione sulle risorse richieste. Defined: l esperimento è completamente definito, cioè contiene informazioni anche sulle risorse richieste. In questo stato la topologia è pronta ad essere realizzata sul cluster. Waiting: l esperimento è in attesa di allocazione sul cluster, o perché attende la liberazione di risorse sufficienti, oppure perché attende l autorizzazione per occupare quelle disponibili. Allocated: l esperimento ha acquisito tutte le risorse necessarie e le occupa materialmente, ma non avendo ancora realizzato la configurazione della topologia, non risulta operativo. Running: l esperimento è pronto per l utilizzo. Le risorse ottenute nello stato allocated ora sono opportunamente configurate per supportare la topologia dell esperimento Descrittore del cluster Dopo aver analizzato la gestione degli esperimenti in Neptune, vediamo come sono mantenute la informazioni relative alla composizione, in termini di macchine fisiche, del cluster e quindi dell infrastruttura di emulazione. Il cluster è una collezione di nodi fisici dei quali viene descritto, oltre alla composizione hardware, anche lo stato ; per stato si intende: indirizzi IP delle interfacce di rete, software installato, virtual machines istanziate sulla macchina. Il cluster descriptor è realizzato in XML (extensible Markup Language) e descrive i nodi fisici similmente a come il descrittore della topologia, analizzato nel prossimo paragrafo, fa con quelli virtuali Descrittore della topologia Neptune descrive in modo completo la configurazione di una particolare topologia di rete nel file topology.xml. Da un punto di vista logico, le topologie sono accomunabili ad un grafo, in cui però vanno tenute in considerazione le informazioni riguardanti i nodi coinvolti e i link che li collegano: I nodi portano informazioni sulla loro configurazione hardware e software. I link hanno associate informazioni riguardanti le proprietà che li caratterizzano. In figura 2.2 è mostrata la struttura del topology descriptor. Di particolare interesse risultano le modifiche, apportate a quest ultimo in una precedente tesi di questa Università [2], che aggiungono gli elementi Node_External_Parameter e manager_parameter, i quali introducono all interno di Neptune il concetto di gestore esterno del livello fisico e di collegamento per un interfaccia. Tramite tale concetto si generalizzano tutti quei casi nei quali si vogliono sfruttare le potenzialità di Neptune integrandolo con un framework esterno, quale, ad esempio, VirtualMesh, che ora andremo a descrivere. 16

17 Figura VirtualMesh VirtualMesh è un framework realizzato dall Università di Berna, con l obiettivo di fornire un architettura di testing per WMN (Wireless Mesh Network) e MANET (Mobile Ad-hoc NETwork). Il processo di sviluppo per tali reti solitamente viene suddiviso in due parti: valutazione tramite simulazione e testing di un prototipo reale della rete all interno di un testbed. Esso, infatti, risulta essere molto più complicato rispetto allo sviluppo di semplici reti d accesso wireless, dovendo tener conto di requisiti quali la mobilità degli utenti, il supporto per high-throughput applications e specifici meccanismi di autoconfigurazione e autoriparazione. Le difficoltà esposte rendono impossibile il testing completo di reti WMN e MANET solo tramite simulazione, ma allo stesso tempo risulta difficile da effettuare in un ambiente di testbed a causa del tempo richiesto, dei costi, che impongono limitazioni in termini di scalabilità e di isolamento, cosa che inevitabilmente incide sulla riproducibilità degli esperimenti, e dell impossibilità di effettuare test in mobilità. In tale contesto si cala VirtualMesh che cerca di combinare i punti di forza dei due approcci attraverso la completa emulazione dei livelli data-link e fisico dello stack di rete. Il meccanismo che sta alla base di VirtualMesh consiste nell intercettare e ridirigere il traffico verso un simulatore di rete, il quale si occupa di modellare l intera comunicazione wireless, inclusa la rappresentazione dei driver dei dispositivi, il livello MAC e il mezzo fisico, mentre i livelli superiori restano inalterati rispetto all implementazione di un testbed reale. Ciò consente di testare applicazioni all interno di uno stack di rete reale e al contempo garantisce un alto livello di scalabilità e controllo nella gestione della topologia, nonché nel valutare diversi scenari di mobilità. Grazie alla sua flessibilità, VirtualMesh è adatto ad un ampio insieme di domini di studio, tuttavia si è scelto di concentrarsi sull ambiente delle reti IEEE

18 2.2.1 Architettura In figura 2.3 è mostrata l architettura di VirtualMesh. Essa consiste in una o più macchine ospitanti il modello di simulazione (WlanModel) e i nodi facenti parte della rete wireless. Questi possono essere sia reali che virtualizzati, con il pieno supporto a diverse tecnologie di virtualizzazione, nonostante venga preferita, anche in questo caso, la paravirtualizzazione offerta da Xen. I nodi e il modello sono connessi tramite una rete di servizio Ethernet dedicata. Figura 2.3 Al fine di ridirigere il traffico wireless dai nodi al modello di simulazione, gli strumenti di emulazione creano delle VIF (Virtual wireless InterFace) che si vanno a sostituire alle interfacce wireless dei nodi (che potrebbero essere anche completamente assenti) in maniera del tutto trasparente alle applicazioni e al sistema operativo. Le VIF vengono create con l ausilio dei driver TUN/TAP (dispositivo di rete del kernel di Linux in grado di simulare periferiche virtuali) e gestite dal device daemon vifd. Tutta la gestione del traffico avviene nello spazio utente: le VIF intercettano le frame Ethernet provenienti dallo stack di rete del nodo sorgente e le inoltrano verso lo user space daemon PacketModeller, che le incapsula in nuovi pacchetti, contenenti informazioni necessarie al modello di simulazione, i quali vengono trasmessi sulla rete di servizio Ethernet verso il WlanModel. Dopo essere stati processati da quest ultimo, i pacchetti sono nuovamente incapsulati e trasmessi sulla rete di servizio verso il nodo di destinazione, dove vengono ricevuti tramite l interfaccia Ethernet dal PacketModeller, deincapsulati e attraverso la VIF iniettati nello stack di rete. La ridirezione del traffico è interamente trasparante ad applicazioni e stack. Per fornire una simulazione accurata, il WlanModel deve venire a conoscenza di una serie di parametri, statici e dinamici, che descrivono i nodi e la configurazione corrente delle loro interfacce wireless. I parametri statici (Es. Indirizzo IP e porto di ascolto del PacketModeller sull interfaccia Ethernet) vengono definiti all atto dell inizializzazione del nodo ed è compito del PacketModeller comunicarli al modello tramite un REGISTER message. Solo dopo la ricezione di un 18

19 acknowlegdment, trasmesso dal modello, il nodo può iniziare a trasmettere traffico wireless; nel caso in cui non venga ricevuto alcun ack entro dieci secondi, il REGISTER message viene ritrasmesso. Attraverso tale meccanismo, il WlanModel mantiene una rappresentazione interna (ProxyHost) dei nodi esterni. Viceversa i parametri dinamici (Es. Canale di comunicazione corrente e potenza trasmissiva) sono inseriti in ogni pacchetto generato dal PacketModeller (DATA packet) e sfruttati dal modello per calcolare il comportamento della simulazione Modello di simulazione Il modello di simulazione di VirtualMesh, detto WlanModel, è implementato nel simulatore di rete OMNeT++, un framework open-source modulare per lo sviluppo di simulazioni ad eventi discreti, basato sul linguaggio C++. Grazie alla sua struttura modulare, altamente flessibile, OMNeT++ può essere usato in diversi ambiti, e viene sfruttato da VirtualMesh per simulare qualsiasi tecnologia per il livello fisico implementata in OMNeT++ o in una delle sue estensioni. Di default è utilizzato lo stack IEEE del framework INET, che si occupa della modellazione delle funzionalità dei driver wireless, incluso l accesso al mezzo (CSMA/CA) e il meccanismo di prenotazione con scambio di frame RTS/CTS. Inoltre approfittando dei sofisticati modelli di mobilità supportati da OMNeT++, VirtualMesh può realizzare senza difficoltà scenari che si possono venire effettivamente a creare in una WMN o in una MANET. Il WlanModel consta di una serie di componenti, ognuno con un proprio ruolo all interno del modello di simulazione. Il PacketProxy e il crawsocketrtscheduler rappresentano l interfaccia tra i nodi esterni e il modello. I messaggi provenienti dal PacketModeller dei diversi nodi vengono dapprima schedulati dal crawsocketrtscheduler e quindi passati al PacketProxy. Se si tratta di un REGISTER message, le informazioni sul nodo vengono aggiunte al NodeManager, il quale è responsabile dell amministrazione dei nodi esterni all interno del WlanModel e associa a ognuno di questi un ProxyHost. Il NodeManager mantiene inoltre una tabella con tutti i parametri statici ricavati dai messaggi di registrazione. Se viceversa si tratta di un DATA packet, il PacketProxy controlla che il sender sia già registrato presso il NodeManager (e se non è così scarta il pacchetto immediatamente). Quindi estrae la frame Ethernet originale e i parametri dinamici e, aggiungendo le informazioni su mittente e destinatario ricavate dal NodeManager, crea una RAWEtherFrame, che viene inviata al WlanNIC del ProxyHost corrispondente al nodo sender esterno. Il WlanNIC è il modulo del WlanModel che implementa lo stack IEEE di INET in modalità ad-hoc (Ieee80211NicAdhoc), mentre il ProxyHost, non effettuando alcuna elaborazione sui messaggi ricevuti, funge da sola interfaccia per quest ultimo. Una volta ricevuta la RAWEtherFrame, il WlanNIC configura i suoi parametri wireless sulla base di quelli estratti da quest ultima, la quale viene elaborata attraverso lo stack Ieee80211NicAdhoc degli host simulati all interno della topologia di test, fintantoché non giunge al WlanNIC del ProxyHost destinatario, che la passa nuovamente al PacketProxy. A questo punto la frame Ethernet originaria è estratta ed inviata all interno di un DATA packet al PacketModeller del nodo esterno receiver. 19

20 2.2.3 Valutazioni ed estensioni Sono stati condotti diversi esperimenti [9] al fine di valutare funzionalità e performance di VirtualMesh. Un certo numero di applicazioni Linux (Es. SSH, SCP e trasferimento file con FTP) non hanno riscontrato alcun problema nel lavorare sulla rete emulata; tuttavia sono stati rilevati alcuni ritardi addizionali dovuti all intercettazione e alla ridirezione del traffico verso il modello di simulazione e all eventuale utilizzo della virtualizzazione, che risultano però trascurabili (al di sotto dei 0,5 ms), in particolare se ci si avvale della paravirtualizzazione. Un importante estensione di VirtualMesh, realizzata in una precedente tesi di questa Università [4], permette la creazione e l utilizzo di più interfacce wireless virtuali (multiradio). Nella versione ufficiale del framework tale funzionalità era prevista solo parzialmente, in quanto era possibile la creazione di più VIF, ma solo la prima poteva essere usata effettivamente. 2.4 Integrazione VirtualMesh in Neptune Allo stato di sviluppo attuale, Neptune è integrato con il framework VirtualMesh multiradio, grazie ai risultati del lavoro di un precedente tesista di questa facoltà [2]. Tale aggiunta ha consentito alla piattaforma di estendere le proprie funzionalità a scenari di rete wireless liberamente definibili. Come è stato già accennato nel paragrafo 2.1.5, la prima modifica necessaria da apportare è stato ridefinire il descrittore della topologia di Neptune, per introdurre il concetto di gestore esterno del livello fisico e di collegamento per un interfaccia di rete; ciò permette di inserire nel file topology..xml dei riferimenti ai parametri da settare in VirtualMesh, nello specifico nei campi Node_External_Parameter e manager_parameter. Al fine di generalizzare l intero processo di integrazione, sono stati definiti degli script parametrizzati per i client e dei frammenti di file di configurazione parametrizzati per il server di emulazione di VirtualMesh. I valori dei parametri succitati vengono determinati rispettivamente o dalla definizione della topologia dell esperimento o da stati interni del manager di Neptune (Es. Numerazione dei nodi e delle interfacce da servire). La sostituzione effettiva, quindi, avviene all atto di configurazione dell esperimento, cioè nel passaggio dallo stato allocated a running, che corrisponde alla pressione del tasto Enforce Topology dell interfaccia grafica di Neptune. I file appena descritti risiedono nella cartella di configurazione di Neptune relativa alla parte client/server dei manager esterni; in particolare i percorsi specifici sono i seguenti: /root/.emuplugin/externalmanager/configclient/nomewmodel /root/.emuplugin/externalmanager/configserver/nomewmodel Tale soluzione permette di poter usufruire dei servizi forniti da più manager esterni, anche nel medesimo esperimento, inserendo semplicemente nel campo manager_parameter del file di topologia riferimenti al nome del modello da voler utilizzare (ExternalManagerName) e l indirizzo IP del server di emulazione (ipserver). Queste ed altre informazioni (Es. Credenziali di accesso per la connessione SSH al nodo server) sono contenute nel file List.xml (vedi Appendice A), presente al percorso /root/.emuplugin/externalmanager/, il quale contiene una sezione per ogni manager 20

21 disponibile, che deve essere preventivamente dichiarato, prima di poter essere riferito nella topologia. Una volta sostituiti i valori dei parametri, il meccanismo restituisce degli output che si differenziano a seconda dell entità considerata. Nel caso client, sono degli script con valori reali che vengono lanciati automaticamente sulle macchine di turno tramite SSH (Secure SHell). Mentre nel caso server, viene generato un file di configurazione (NomeWmodel.ini), necessario per l avvio del servizio di emulazione, che viene inviato tramite SCP (Secure CoPy) nella directory di lavoro del nodo server. Quest ultimo deve fare ancora riferimento al file List.xml, che contiene informazioni relative ai parametri (Es. Nome del file.ini) e ai comandi da eseguire per avviare il servizio di emulazione. 21

22 Capitolo 3 OMF 3.1 Panoramica OMF (control and Management Framework) è un framework generico per controllare e gestire testbed di rete. È stato sviluppato originariamente per il testbed wireless ORBIT dal Winlab della Rutgers University, che dal 2008 collabora con il NICTA per estensioni e manutenzione. Attualmente può operare su testbed basati su differenti tecnologie; nello specifico in questo lavoro di tesi è stato utilizzato per gestire esperimenti su topologie di rete emulate. A tal scopo OMF mette a disposizione dello sperimentatore: Un DSL (Domain Specific Language), chiamato OEDL (OMF Experiment Description Language), che permette all utente di descrivere: o Le risorse necessarie per un esperimento e la loro configurazione. o Le applicazioni da usare in un esperimento e le misurazioni da acquisire da queste. o I differenti task da eseguire durante un esperimento e gli istanti di tempo o gli eventi che li innescano. Un set di strumenti software, che: o Accettano in ingresso l esperimento descritto precedentemente. o Inizializzano e impostano le risorse necessarie con le configurazioni e le applicazioni richieste dall esperimento. o Inviano i comandi alle risorse per eseguire effettivamente i tasks descritti in un esperimento agli istanti di tempo o agli eventi appropriati. o Acquisiscono dati di misura dalle applicazioni e/o dalle risorse. o Accedono ai dati sperimentali raccolti Figura 3.1 e li analizzano. 22

23 Come è stato già accennato in precedenza, OMF riceve in input uno script che descrive un esperimento utilizzando il linguaggio OEDL. Distribuisce e configura questo esperimento sui nodi della rete emulata basandosi sulla descrizione fornita dall utente, quindi ne inizializza e controlla l esecuzione. Mentre l esperimento è eseguito, i dati da analizzare vengono misurati e accumulati. In seguito possono essere memorizzati in un database per analisi successive o riutilizzati dalle funzioni di controllo di OMF per variare dinamicamente alcuni parametri di lavoro (figura 3.1). 3.2 Architettura L architettura di OMF segue un approccio di tipo distribuito; le tre entità fondamentali che operano in un testbed di rete gestito da OMF sono: Aggregate Manager Experiment Controller Resource Controller Aggregate Manager L Aggregate Manager (AM), come ci suggerisce il nome stesso, gestisce tutte le risorse all interno di un testbed e fornisce allo sperimentatore l accesso ad un sottoinsieme di queste, con la possibilità di imporre alcuni vincoli. La versione attuale dell AM esegue i seguenti tasks specifici: Gestisce lo Chassis Manager, il quale è un controllore usato per accendere o spegnere una risorsa. Ovviamente è presente solo nel caso di risorse reali e non emulate. Gestisce un database di informazioni per le risorse disponibili e tutte le informazioni relative al testbed. Avvia e ferma il software Frisbee, che distribuisce/salva le immagini degli Hard Disk dei dispositivi da/verso una repository di tali immagini. Gestisce il boot di un dispositivo (Es. Da remoto o da disco locale). Fornisce accesso remoto e permette query ad un qualsiasi database di misurazioni Experiment Controller L Experiment Controller (EC) è l entità software responsabile di dislocare, controllare ed organizzare un esperimento secondo le intenzioni e per conto dell utente. L EC prende in ingresso un Experiment Description e la elabora. Coopera con l Aggregate Manager del testbed per configurare le risorse sperimentali richieste in accordo con la descrizione; terminata la configurazione, l EC comunica con i Resource Controllers associati a ciascuna risorsa e invia a questi i comandi che realizzeranno effettivamente l esperimento. N.B. Un Experiment Description (ED) è uno script fornito in ingresso all Experiment Controller, scritto nel linguaggio OEDL, che elenca le risorse necessarie all esperimento e le azioni da compiere per portarlo a termine. 23

24 3.2.3 Resource Controller Il Resource Controller (RC) è un entità software che risiede in ognuna delle risorse disponibili nel testbed. Ogni istanza del RC attende i comandi impartiti dall Experiment Controller, li esegue e restituisce tutte le informazioni ottenute da tale esecuzione. Quindi un RC è responsabile di eseguire effettivamente i tasks dell esperimento direttamente su una risorsa. In aggiunta a questa funzione di controllo, il RC è attualmente responsabile di alcune funzioni di gestione della risorsa, quali, ad esempio, la ricezione e la scrittura dell immagine del disco nella memoria del dispositivo. Infine si ricorda che un altro componente essenziale di OMF è il linguaggio OEDL, un Domain Specific Language, derivato dal Ruby, usato per scrivere le Experiment Description che vengono poi elaborate dall Experiment Controller. 3.3 Struttura Figura 3.2 La Figura 3.2 mostra un esempio di struttura di un testbed gestito tramite OMF. Allo stato di sviluppo attuale è previsto un unico Aggregate Manager, uno o più Experiment Controller e un certo numero di nodi, su ognuno dei quali risiede un istanza del Resource Controller. Ovviamente il numero dei nodi coinvolti dipende dall esperimento e tutti i componenti del testbed possono essere sia reali che virtualizzati. L implementazione di tale struttura viene realizzata grazie ad un serie di elementi hardware e software che ora andremo ad analizzare. 24

25 3.3.1 Servizi installati sul SO OMF prevede l installazione sul SO di ogni macchina, reale o virtuale, di uno o più servizi. In genere l Aggregate Manager e l Experiment Controller sono ospitati sulla stessa macchina fisica e implementati come servizi autopartenti. Il Resource Controller risiede, invece, sui diversi nodi del testbed ed è anch esso un servizio autopartente. Le varie entità comunicano tramite Openfire Server di scambio messaggi Come abbiamo già accennato, al fine di gestire la comunicazione tra tutte le entità facenti parte del testbed, OMF utilizza il server di scambio messaggi Openfire; scritto in Java, si avvale di XMPP (extensible Messaging and Presence Protocol), un protocollo aperto ed estensibile di messaggistica istantanea e presenza basato su XML. Solitamente Openfire è installato sulla stessa macchina dell Aggregate Manager, il quale figura nel server XMPP con il ruolo di amministratore. Possiede un interfaccia Web per la configurazione iniziale e l amministrazione del server ed è dotato di un database interno in cui vengono mappati tutti i nodi d esperimento Database Un altro elemento fondamentale nell implementazione di OMF è un database MySQL contenente: Tutte le informazioni necessarie relative ai nodi, nello specifico: o Indirizzo IP e MAC della rete di controllo. o Informazioni sull hardware di ogni dispositivo (Es. Scheda madre, produttore). o ID univoco assegnato ad ogni dispositivo. o Posizione logica di ogni nodo, identificata dalle coordinate (X,Y,Z) di uno spazio virtuale a tre dimensioni. Informazioni relative al testbed, nello specifico: o Nome e ID del testbed. o Indirizzo IP della rete di controllo. o Indirizzo IP dei servizi ausiliari. Di norma il database viene popolato eseguendo query in modo manuale, ma in questo elaborato sono stati sfruttati degli script, che automatizzano la procedura, sviluppati in una precedente tesi [2] e opportunamente modificati per renderli compatibili con la versione 5.4 di OMF Reti di collegamento OMF può essere utilizzato per la gestione di esperimenti effettuati su topologie di rete di svariato tipo, sia wireless, che wired, ed è proprio questa flessibilità uno dei suoi punti di forza. La sua struttura, tuttavia, prevede la necessità di dover scambiare tra i dispositivi non solo informazioni relative all esperimento in corso, ma anche informazioni per mettere in comunicazione, gestire e sincronizzare le varie entità. Per rendere attuabile la gestione flessibile dell ambiente di test OMF utilizza perciò due reti: 25

26 Rete di Controllo (necessariamente wired). Rete di Esperimento (sia wired, che wireless) Un caso d uso: la sperimentatrice Alice Facendo ancora riferimento alla figura 3.2 consideriamo i passi e le interazioni da effettuare quando si effettua un esperimento con OMF: La sperimentatrice Alice avvia una nuova istanza dell Experiment Controller (EC) a cui passa l Experiment Description (ED) precedentemente composta. L EC interpreta l ED e invia all Aggregate Manager (AM) le richieste per l inizializzazione e la configurazione delle risorse necessarie ad Alice. I servizi dell AM inizializzano e configurano queste risorse. Quando le risorse sono pronte, l EC invia i comandi a tutti i Resource Controllers (RCs) risiedenti sui nodi (le risorse stesse). I RCs interpretano questi comandi ed eseguono le azioni. A questo punto l esperimento è in fase di running. Mentre l esperimento viene eseguito, possono essere comunicate le misurazioni da effettuare ed eventuali operazioni di filtraggio dei dati prima della memorizzazione. Al termine dell esperimento i dati sono memorizzati in un database e disponibili per l analisi dei risultati. Mentre Alice esegue il suo esperimento, OMF consente ad altri sperimentatori di operare in concorrenza, con il vincolo di usare set di risorse differenti e, nel caso di testbed wireless, anche canali separati per evitare interferenze. 26

27 Capitolo 4 Integrazione di Neptune con OMF 5.4 Il lavoro sviluppato in questo elaborato ha come punto di partenza la piattaforma wireless integrata composta da Neptune, VirtualMesh e OMF, messa a punto da un precedente tesista di questa facoltà [2]. Nel paragrafo 2.4 è stato già descritto il processo che ha consentito di estendere le funzionalità di Neptune a topologie di reti wireless grazie all integrazione con VirtualMesh. L apporto di OMF, viceversa, permette di poter gestire ed eseguire esperimenti su una rete definita ed istanziata tramite Neptune. Partendo da una siffatta piattaforma, si è provveduto ad aggiornare OMF alla versione 5.4, l ultima disponibile al momento della stesura, e a riconfigurare il sistema per adattarlo alla nuova release. Prima di descrivere le modifiche apportate, diamo un cenno alla soluzione adottata per la precedente integrazione con OMF Integrazione con OMF 5.3 I meccanismi implementati per l integrazione di Neptune con OMF 5.3 sono stati il frutto di una seconda iterazione del suddetto processo [2] [3], il quale ha fornito alla piattaforma trasparenza e completa automatizzazione per la creazione di un ambiente di lavoro per l esecuzione e il controllo di esperimenti su una topologia di rete allocata tramite Neptune. Similmente a quanto fatto con VirtualMesh, sono stati sfruttati una serie di script parametrizzati che vengono lanciati sulle macchine ospitanti le diverse entità di OMF (vedi par. 3.2). Inoltre, al fine di riconoscere questi nodi, è stato introdotto un meccanismo che consente al Manager di Neptune di effettuare un controllo sul suffisso nel nome del template, il quale deve terminare con _omfagr o _omfnode, se si tratta rispettivamente delle macchine installanti i servizi AM/EC o RC. In particolare, come mostrato in figura 4.1, è stato adottato un doppio livello di script, una soluzione che è stata prevista per mantenere la compatibilità con le eventuali successive versioni di OMF e che di conseguenza ha facilitato anche l aggiornamento alla versione 5.4 del framework Primo livello di script Gli script di primo livello risiedono nella sezione dedicata ad OMF della cartella di configurazione di Neptune; nello specifico il percorso è il seguente: /root/.emuplugin/omf. 27

28 Figura 4.1 Essi vengono attivati, così come accade per VirtualMesh, all atto del passaggio dell esperimento dallo stato allocated a running, cioè alla pressione del tasto Enforce Topology dell interfaccia grafica di Neptune. Il risultato è la sostituzione nel codice dei parametri con il nome della topologia ($TOPOLOGY) e l indirizzo IP del Manager di Neptune ($IPNEPTUNE) e il lancio dei file così ottenuti sui nodi OMF; inoltre, prima delle suddette operazioni, viene inviato tramite SCP, al solo AM/EC, il file topology.xml, che funge da input per la creazione degli script di secondo livello. Nelle tabelle 4.1 e 4.2 è riportata la struttura degli script di primo livello agm e node. Si noti che non è presente alcun riferimento alla versione di OMF in uso e per questo motivo non è stato necessario apportare alcuna modifica. Inoltre lo script node non esegue alcuna operazione sui nodi ospitanti i RCs; questa possibilità è riservata per sviluppi futuri. Viceversa lo script agm, eseguito sulla macchina ospitante l AM/EC, lancia una serie di comandi per la generazione e l esecuzione degli script di secondo livello (vedi par ). Uno dei comandi più interessanti da analizzare è xsltproc, un applicativo a riga di comando utilizzato per applicare fogli di stile XSLT (extensible Stylesheet Language Transformations) a documenti XML. Tali fogli di stile sono semplici file di testo con estensione.xsl e servono sostanzialmente per trasformare il documento XML, al quale sono applicati, in un altro documento. Nel nostro caso la trasformazione XSLT riceve in ingresso i fogli di stile e il file di topologia XML, copiato in precedenza sull AM/EC, e restituisce in output gli script di secondo livello, generati sulla base delle informazioni contenute in quest ultimo (Es. Identificativi dei nodi, indirizzi IP delle interfacce, nomi dei template OMF, ecc.). 28

29 Un altro comando sovente utilizzato negli script è sed, un editor di riga non interattivo presente di default in tutti i sistemi Linux. Esso modifica un testo ricevuto in input, dallo stdin o da un file, andando ad operare su determinate righe, individuate sulla base di un indirizzo passatogli come parametro. Questo può essere o esplicitamente un numero di riga, o più spesso ed è effettivamente così negli script, una verifica di occorrenza da individuare nel testo. Script agm ########################################################## #Parametri usabili in questo script #$IPNEPTUNE #$TOPOLOGY #################SEGUONO COMANDI##################### sleep 2 cd /script xsltproc conf_nodo.xsl $TOPOLOGY.topology.xml > conf_nodo.sh xsltproc conf_agm.xsl $TOPOLOGY.topology.xml > conf_agm.sh chmod +x conf_nodo.sh chmod +x conf_agm.sh sleep 2./conf_agm.sh > conf_agm.out./conf_nodo.sh > conf_nodo.out xsltproc query_db_wifi.xsl $TOPOLOGY.topology.xml > update_db.sql sed -i 's/[.][1-9]*[@]/.0/g' update_db.sql sed -i 's/@@[0-9]*[.][0-9]*[.][0-9]*[.]//g' update_db.sql sleep 2 mkdir /root/query chmod 777 /root/query cp update_db.sql /root/query/ mysql inventory < /root/query/update_db.sql rm r /root/query rm conf_agm.sh rm conf_nodo.sh rm update_db.sql Tabella 4.1 Script node ########################################################## #Parametri usabili in questo script #$IPNEPTUNE #$TOPOLOGY #################SEGUONO COMANDI##################### Tabella Secondo livello di script Gli script di secondo livello risiedono nella root del template della macchina ospitante l AM/EC, più precisamente al percorso /root/script. Come abbiamo già visto, essi vengono generati dinamicamente dagli script di primo livello tramite il comando xsltproc ed eventualmente 29

30 modificati con sed, lanciati ed infine rimossi dal sistema. Constano di tre file che hanno il compito di configurare: l AM/EC (conf_agm.sh), i RCs dei diversi nodi (conf_nodo.sh) e il database MySQL, chiamato inventory, di supporto ad OMF (query_db_wifi.sh). Nell Appendice A sono riportati i soli listati dei fogli di stile, dal momento che gli script dipendono fortemente dalla topologia considerata e di fatto costituiscono una mera controparte reale ed eseguibile dei file.xsl. Questi ultimi sono stati modificati per adattarli alla versione di OMF 5.4, andando fondamentalmente a sostituire i percorsi relativi a file e risorse presenti sui nodi, per riferirli alla nuova release. Le modifiche sono state facilitate dal sostanziale mantenimento della struttura di directory di OMF nel passaggio dalla versione 5.3 alla 5.4 e dalla presenza, già prevista precedentemente negli script, di una variabile xsl, denominata omfver, che è stata inizializzata al valore 5.4 e richiamata successivamente nel codice. Riassumiamo le operazioni effettuate dai tre fogli di stile: conf_agm.xsl: o Configura gli hostfile (/etc/hosts) su ogni nodo dell esperimento, in modo che il servizio Openfire possa riconoscerli. o Scrive il file di configurazione omf-expctl.yaml dell EC sulla base del file parametrizzato omf-expctl_default.yaml, sostituendo i valori reali relativi alla topologia attuale. o Avvia e configura Openfire. o Riavvia l AM per rendere effettivi i cambiamenti apportati. conf_nodo.xsl: o Scrive il file di configurazione omf-resctl.yaml del RC di ogni nodo sulla base del file parametrizzato omf-resctl_default.yaml, sostituendo i valori reali relativi alla topologia attuale. o Riavvia il RC, su tutti i nodi dell esperimento, per rendere effettivi i cambiamenti apportati. query_db_wifi.xsl: o Aggiorna il nome del testbed con l identificativo della topologia. o Aggiorna il timestamp di partenza del processo di inventario MySQL. o Elimina tutte le righe delle tabelle devices, locations, motherboards e nodes del database inventory. o Inserisce i valori relativi all esperimento attuale nelle tabelle devices, locations, motherboards e nodes, compresi i parametri relativi alla mobilità dei nodi, settati tramite VirtualMesh (nello specifico nella tabella locations). 30

31 4.2 Aggiornamento ad OMF 5.4 Nel precedente paragrafo sono già state descritte le modifiche apportate ai fogli di stile per adattarli alla versione 5.4 di OMF. Si vogliono ora analizzare le operazioni più significative effettuate per rendere operativa la nuova release. Il primo passo è istanziare una nuova topologia di rete tramite Neptune; basta avere a disposizione due nodi, uno che ospita l AM/EC e un secondo il RC, in modo da potervi successivamente accedere per procedere con l aggiornamento. I template a cui si è fatto riferimento sono quelli relativi ad OMF 5.3 e cioè ubuntu_mesh_omfagr (AM/EC) e voyage_mesh_omfnode (RC). Un piccolo accorgimento da tenere a mente in questa fase, è riservare per l AM/EC almeno 300 MB di RAM, in maniera tale da consentire il corretto funzionamento di tutti i processi. Una volta che i nodi risultano tutti allocati e la topologia configurata, cioè l esperimento Neptune si trova in stato di running, è possibile accedervi via SSH con il comando ssh root@<ip-nodo>, dove al posto di <ip-nodo> va sostituito l indirizzo IP locale assegnato da Neptune all interfaccia di controllo del nodo (eth0 di default). Da notare che questi risultano allocati sul server Apache che ospita Neptune (nel nostro caso all indirizzo IP ), al quale si accede ancora via SSH, previa autorizzazione, e dal quale è possibile poi collegarvisi. Tutte le sessioni SSH prevedono l utilizzo del metodo di autenticazione a chiave pubblica, per evitare la digitazione manuale di username e password da parte dell utente. Infatti esse sono impiegate non solo per l accesso ai nodi da parte del Manager di Neptune, ma anche all atto del lancio degli script di secondo livello da parte dell AM/EC sulle macchine RCs, i quali non prevedono interazioni con l utente. A questo punto quindi, il client SSH stabilisce una sessione remota cifrata tramite un interfaccia a riga di comando, attraverso la quale è possibile lanciare qualsivoglia comando sul nodo. Vediamolo più in dettaglio Aggiornamento Resource Controller Sul template ospitante il RC, denominato voyage_mesh_omfnode, risulta installato il sistema operativo Linux Voyage 0.7, una distribuzione derivata da Debian Squeeze e adattata per piattaforme x86 embedded. La prima operazione da effettuare è disinstallare la precedente versione del RC di OMF attraverso il comando dpkg -r omf-resctl-5.3, quindi è possibile procedere con l installazione della nuova release seguendo le istruzioni riportate nel sito di OMF [8] alla sezione OMF 5.4 Installation Guide. In particolare è necessario scaricare i pacchetti.deb necessari al servizio omf-resctl-5.4, dal repository di OMF, e tutte le dipendenze richieste e installarli con il comando dpkg i <nome-pacchetto>.deb. Anche se la procedura di installazione va a buon fine, inizialmente il servizio non riuscirà ad avviarsi, questo perché è necessario prima configurarlo. Di norma la configurazione andrebbe fatta a mano copiando il file di esempio /usr/share/doc/omf-resctl-5.4/examples/omf-resctl.nicta.yaml al percorso /etc/omf-resctl-5.4/omf-resctl.yaml ed editandolo per rispecchiare le caratteristiche del testbed. 31

32 In realtà nel nostro caso si è sfruttato un file di configurazione di default parametrizzato, denominato omf-resctl_default.yaml, già presente in precedenza e strutturato per OMF 5.3, il quale è stato modificato per renderlo aderente allo schema di configurazione della versione 5.4. Copiato questo file nella directory /etc/omf-resctl-5.4/ è compito degli script di secondo livello sostituire i valori reali ai parametri e creare il file omf-resctl.yaml. Quindi è possibile avviare il RC con il comando /etc/init.d/omf-resctl-5.4 restart, che viene comunque lanciato in automatico all istanziazione di una nuova topologia Aggiornamento Aggregate Manager/Experiment Controller I servizi relativi all AM e all EC sono ospitati sullo stesso template, denominato ubuntu_mesh_omfagr, il quale ha installato il sistema operativo Linux Ubuntu (Lucid Lynx). Il processo di aggiornamento è molto simile a quello effettuato sulla macchina RC, ci focalizzeremo quindi sulle poche differenze che sussistono tra i due. Come fatto in precedenza bisogna preliminarmente disinstallare le precedenti versioni dell AM e dell EC con il comando dpkg r omf-aggmgr-5.3 (omf-expctl-5.3) e procedere con l installazione della nuova release come indicato sul sito di OMF [8]. È necessario, quindi, scaricare i pacchetti.deb relativi ai servizi omf-aggmgr-5.4 e omf-expctl-5.4, ed eventualmente tutte le dipendenze, ed installarli con il comando dpkg i <nome-pacchetto>.deb. Anche questa volta i servizi non riusciranno ad avviarsi e si deve procedere con la configurazione. Partendo con l EC, il processo è del tutto analogo a quello descritto nel paragrafo precedente. Innanzitutto è stato modificato il file di configurazione di default parametrizzato omfexpctl_default.yaml, per renderlo compatibile con lo schema di configurazione di OMF 5.4, ed è stato poi copiato nella directory /etc/omf-expctl-5.4/, delegando agli script di secondo livello creare il file a valori reali omf-expctl.yaml che configura l EC. Per quanto riguarda l AM si è sfruttata la configurazione relativa alla versione 5.3, avendo dovuto far riferimento a tutta una serie di servizi ausiliari di cui questo necessita, che risultavano associati alla release precedente. Si è quindi importato il file di configurazione /etc/omf-aggmgr-5.3/omfaggmgr.yaml al percorso /etc/omf-aggmgr-5.4/omf-aggmgr.yaml e tutti quelli relativi ai servizi aggiuntivi disponibili dalla cartella /etc/omf-aggmgr-5.3/available a /etc/omf-aggmgr-5.4/available. Ciascuno di questi servizi è stato poi abilitato creando un link simbolico nella directory /etc/omfaggmgr-5.4/enabled con il comando ln s /etc/omf-aggmgr-5.4/available/<nome-servizio>.yaml. Terminata anche questa procedura si è passati a copiare i nuovi fogli di stile, adattati ad OMF 5.4, (vedi par e Appendice A) nella cartella /script della root del template AM/EC. Anche i servizi relativi all AM e all EC sono impostati come autopartenti sui nodi OMF facenti parte di una topologia Neptune. 32

33 4.2.3 Salvataggio delle immagini dei template L ultima fase del processo di aggiornamento consiste nel salvare le immagini dei template. In sostanza basta copiare i file.img di interesse dalla directory /home/neptune/neptunevms/ Experiments a /home/neptune/neptunevms/templates, rinominandoli in modo tale da distinguerli da quelli già presenti. Nello specifico sono stati denominati voyage_5_4_mesh_omfnode e ubuntu_5_4_mesh_omfagr, mantenendo il vincolo sui suffissi per il riconoscimento di appartenenza alla rete di controllo di OMF. Infine è necessario creare un file XML per ogni template, il quale funge da descrittore per quest ultimo. In Appendice A sono presenti i listati dei due file XML. 33

34 Conclusioni Lo sforzo di aggiornamento della piattaforma integrata Neptune, VirtualMesh e OMF, descritto nella trattazione, ci permette di avere a disposizione un ambiente, che combinando i vantaggi dei tre framework, fa della flessibilità, dell accessibilità e della capacità di adattamento a diversi scenari d emulazione i suoi maggiori punti di forza. Il passaggio dalla versione 5.3 alla 5.4 di OMF consente di mantenere il sistema aggiornato per supportare le nuove features e quelle in via di sviluppo dalla fervente community che sostiene il progetto, nonché le eventuali modifiche e aggiunte al linguaggio OEDL per la descrizione degli esperimenti. Infatti, grazie al mantenimento del doppio livello di script e ai meccanismi di automatizzazione per l integrazione con Neptune, anche successivi aggiornamenti potranno essere condotti in maniera relativamente agevole, evitando così l obsolescenza del sistema. In sostanza si ha, quindi, a disposizione un sistema di emulazione di rete che può coprire vasti scenari sperimentali, sia wired che wireless, facilmente aggiornabile ed estensibile anche a contesti emulativi differenti (Es. Reti cellulari, IEEE WiMax ecc.), tramite il supporto a manager esterni diversi da VirtualMesh. Il tutto supportato dal framework OMF, che offre una serie di strumenti per la descrizione e la gestione di esperimenti di diverso tipo sulla topologia allocata e per la successiva analisi dei risultati prodotti. 34

35 Appendice A Listati dei file citati nel testo A.1 Listati dei fogli di stile conf_agm.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="text" encoding="utf-8"/> <xsl:template match="/"> ###definizione della versione omf in uso### #########definizione hostnamexmpp########## ############!settare a mano!############### <xsl:variable name="omfver">5.4</xsl:variable> <xsl:variable name="hostnamexmpp">tk-virtual</xsl:variable> ########################################### ####definizione dominio dell'esperimento### <xsl:variable name="domexp"><xsl:value-of select="topology/@id"/></xsl:variable> ########################################### ########DEFINIZIONE VARIABILE AGM########## <xsl:variable name="ipagm"> <xsl:for-each select="topology/nodes/node"> <xsl:choose> <xsl:when test="contains(software_configuration/@template,'_omfagr')"> <xsl:value-of select = "network_interfaces/interface/ip/@address"/> </xsl:when> </xsl:choose> </xsl:for-each> </xsl:variable> ########################################### ########CONFIGURAZIONE HOSTFILE######### 35

36 ###AVVIENE su ogni nodo dell'exp######## #cancellare i precedenti contenuti <xsl:for-each select="topology/nodes/node"> <xsl:variable name="ipconnect"><xsl:value-of select="network_interfaces/interface/ip/@address"/> </xsl:variable> ssh root@<xsl:value-of select="$ipconnect"/> "rm /etc/hosts" ssh root@<xsl:value-of select="$ipconnect"/> "echo localhost >> /etc/hosts" <xsl:for-each select="//topology/nodes/node"> <xsl:variable name="ip"><xsl:value-of select="network_interfaces/interface/ip/@address"/></xsl:variable> <xsl:variable name="temp"><xsl:value-of select="software_configuration/@template"/></xsl:variable> <xsl:variable name="id"><xsl:value-of select="@id"/></xsl:variable> <xsl:if test="contains($temp,'_omfnode')"> ssh root@<xsl:value-of select="$ipconnect"/> "echo <xsl:value-of select="$ip"/><xsl:text> </xsl:text> <xsl:value-of select="$id"/> >> /etc/hosts" </xsl:if> <xsl:if test="contains($temp,'_omfagr')"> ssh root@<xsl:value-of select="$ipconnect"/> "echo <xsl:value-of select="$ip"/><xsl:text> </xsl:text> <xsl:value-of select="$hostnamexmpp"/> >> /etc/hosts" </xsl:if> </xsl:for-each> </xsl:for-each> ########CONFIGURAZIONE HOSTFILE######### #!/bin/bash # #questa riga serve a scrivere l'indirizzo esatto del server xmpp openfire nell 'aggregate manager ssh root@<xsl:value-of select="$ipagm"/> "rm /etc/omf-expctl-<xsl:value-of select="$omfver"/>/omfexpctl.yaml" ssh root@<xsl:value-of select="$ipagm"/> "sed -e 's/omf-console/<xsl:value-of select="$hostnamexmpp"/>/g' /etc/omf-expctl-<xsl:value-of select="$omfver"/>/omf-expctl_default.yaml > /etc/omf-expctl-<xsl:value-of select="$omfver"/>/omf-expctl.yaml" ##sostituire con il id esperimento ssh root@<xsl:value-of select="$ipagm"/> "sed -i 's/domain_default/<xsl:value-of select="$domexp"/>/g' /etc/omf-expctl-<xsl:value-of select="$omfver"/>/omf-expctl.yaml " #########Parte vecchia versione 5.2############ #ssh root@<xsl:value-of select="$ipagm"/> "sed -i 's/xmpp_address/<xsl:value-of select="$ipagm"/>/g'/etc/omf-expctl-5.2/nodehandler.yaml" #ssh root@<xsl:value-of select="$ipagm"/> "sed -i 's/xmpp_address/<xsl:value-of select="$ipagm"/>/g'/etc/omf-expctl-5.2/nodehandlerslave.yaml" ########################################### #############AVVIO OPENFIRE############# #questa riga modifica la proprietà xmpp.domain di openfire #ssh root@<xsl:value-of select="$ipagm"/> "rm /var/lib/openfire/embedded-db/openfire.script" 36

37 #ssh select="$ipagm"/> "sed -e 's/indirizzo_xmpp/<xsl:value-of select="$hostnamexmpp"/>/g' /var/lib/openfire/embedded-db/openfire_default.script > /var/lib/openfire/embedded-db/openfire.script" #avvio del servizio openfire sull'aggregate manager ssh select="$ipagm"/> "/etc/init.d/openfire start" #############AVVIO OPENFIRE############# ########CONFIGURAZIONE OPENFIRE######### <xsl:for-each select="topology/nodes/node"> <xsl:variable name="ip"><xsl:value-of <xsl:variable name="temp"><xsl:value-of <xsl:variable name="id"><xsl:value-of <xsl:if test="contains($temp,'_omfagr')"> ssh select="$ipagm"/> "omf_create_psnode-<xsl:value-of select="$omfver"/> <xsl:text> </xsl:text> <xsl:value-of select="$hostnamexmpp"/> mksys" </xsl:if> </xsl:for-each> <xsl:for-each select="topology/nodes/node"> <xsl:variable name="ip"><xsl:value-of <xsl:variable name="temp"><xsl:value-of <xsl:variable name="id"><xsl:value-of <xsl:if test="contains($temp,'_omfnode')"> ssh select="$ipagm"/> "omf_create_psnode-<xsl:value-of select="$omfver"/> <xsl:text> </xsl:text> <xsl:value-of select="$hostnamexmpp"/> mkslice default_slice <xsl:value-of select="$id"/>" </xsl:if> </xsl:for-each> ########CONFIGURAZIONE OPENFIRE######### ssh select="$ipagm"/> "/etc/init.d/omf-aggmgr-5.4 restart" </xsl:template> </xsl:stylesheet> conf_nodo.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="text" encoding="utf-8"/> <xsl:template match="/"> #!/bin/bash ########DEFINIZIONE VARIABILE AGM########## <xsl:variable name="ipagm"> <xsl:for-each select="topology/nodes/node"> <xsl:choose> 37

38 <xsl:when <xsl:value-of select = "network_interfaces/interface/ip/@address"/> </xsl:when> </xsl:choose> </xsl:for-each> </xsl:variable> ########################################### ####def. della ver. e dir di omf in uso#### #########definizione hostnamexmpp########## ############!settare a mano!############### <xsl:variable name="omfver">5.4</xsl:variable> <xsl:variable name="hostnamexmpp">tk-virtual</xsl:variable> <xsl:variable name="resctldir">/etc/omf-resctl-<xsl:value-of select="$omfver"/>/</xsl:variable> ########################################### ############CONFIGURAZIONE RC############## <xsl:for-each select="topology/nodes/node"> <xsl:variable name="id"><xsl:value-of select="@id"/></xsl:variable> <xsl:variable name="temp"><xsl:value-of select="software_configuration/@template"/></xsl:variable> <xsl:variable name="ip"><xsl:value-of select="network_interfaces/interface/ip/@address"/></xsl:variable> <xsl:if test="contains($temp,'_omfnode')"> #questa riga serve a scrivere l'indirizzo esatto del server xmpp openfire nel nodo ssh root@<xsl:value-of select="$ip"/> "rm <xsl:value-of select="$resctldir"/>/omf-resctl.yaml" ssh root@<xsl:value-of select="$ip"/> "sed -e 's/xmpp_address/<xsl:value-of select="$hostnamexmpp"/>/g' <xsl:value-of select="$resctldir"/>/omf-resctl_default.yaml > <xsl:value-of select="$resctldir"/>/omf-resctl.yaml" ssh root@<xsl:value-of select="$ip"/> "sed -i 's/node_id/<xsl:value-of select="$id" />/g' <xsl:value-of select="$resctldir"/>/omf-resctl.yaml" ssh root@<xsl:value-of select="$ip"/> "/etc/init.d/omf-resctl-<xsl:value-of select="$omfver"/> restart" #############################Parte vecchia versione 5.2#################################### #ssh root@<xsl:value-of select="$ip"/> "sed -i 's/xmpp_address/<xsl:value-of select="$ipagm"/>/g'/etc/omf-resctl-5.2/nodeagent.yaml" #ssh root@<xsl:value-of select="$ip"/> "/etc/init.d/omf-resctl-5.2 restart" ####################################################################################### </xsl:if> </xsl:for-each> ############CONFIGURAZIONE RC############## </xsl:template> </xsl:stylesheet> 38

39 query_db_wifi.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="text" encoding="utf-8"/> <xsl:template match="/"> ####definizione dominio dell esperimento### <xsl:variable name="domexp"><xsl:value-of ########################################### ########DEFINIZIONE VARIABILE AGM########## <xsl:variable name="ipagm"> <xsl:for-each select="topology/nodes/node"> <xsl:choose> <xsl:when <xsl:value-of select = "network_interfaces/interface/ip/@address"/> </xsl:when> </xsl:choose> </xsl:for-each> </xsl:variable> ########################################### UPDATE testbeds SET name='<xsl:value-of select="$domexp"/>' WHERE id='1'; UPDATE inventories SET opened= CURRENT_TIMESTAMP WHERE id='1'; TRUNCATE TABLE devices; TRUNCATE TABLE locations; TRUNCATE TABLE nodes; TRUNCATE TABLE motherboards; <xsl:for-each select="topology/nodes/node"> <xsl:variable name="id"><xsl:value-of select="@id"/></xsl:variable> <xsl:variable name="temp"><xsl:value-of select="software_configuration/@template"/></xsl:variable> <xsl:variable name="mac"><xsl:value-of select="network_interfaces/interface/@mac"/></xsl:variable> <xsl:variable name="eth"><xsl:value-of select="network_interfaces/interface/@name"/></xsl:variable> <xsl:variable name="ip"><xsl:value-of select="network_interfaces/interface/ip/@address"/></xsl:variable> <xsl:variable name="xparm"><xsl:value-of select="node_external_parameter/@parm1"/></xsl:variable> <xsl:variable name="yparm"><xsl:value-of select="node_external_parameter/@parm2"/></xsl:variable> <xsl:if test="contains($temp,'_omfagr')"> #############################PARTE VECCHIA VERSIONE 5.2######################### #update testbeds set control_ip= '<xsl:value-of select="$ip"/>@' where id ='1'; #update testbeds set oml_url= 'tcp:<xsl:value-of select="$ip"/>:3003' where id ='1'; #############################PARTE VECCHIA VERSIONE 5.2######################### </xsl:if> 39

40 <xsl:if test="contains($temp,'_omfnode')"> insert into devices select="$ip"/>', select="$ip"/>',1,'bus 00:01','<xsl:value-of select="$mac"/>','<xsl:value-of select="$eth"/>'); insert into locations select="$ip"/>', '<xsl:value-of select="$id"/>','<xsl:value-of select="$xparm"/>','<xsl:value-of select="$yparm"/>',0,null, NULL, NULL,'<xsl:value-of select="$ipagm"/>', <xsl:value-of select="position()"/>,1); insert into motherboards select="$ip"/>',1,null,null,null,null,null,null,1,null); insert into nodes select="$ip"/>','<xsl:value-of select="$ip"/>','<xsl:value-of select="$mac"/>',null,null,'<xsl:value-of select="$ip"/>',null,'/dev/xvda'); #############################PARTE VECCHIA VERSIONE 5.2######################### #insert into devices select="$ip"/>','1','1','1','','<xsl:value-of select="$mac"/>','<xsl:value-of select="$eth"/>'); #insert into locations select="$ip"/>','1','null','null','null','1','null'); #insert into nodes select="$ip"/>','<xsl:value-of select="$ip"/>','1'); #update testbeds set y_max=(select max(y) from locations) where id =1; #############################PARTE VECCHIA VERSIONE 5.2######################### </xsl:if> </xsl:for-each> </xsl:template> </xsl:stylesheet> A.2 Descrittori dei template ubuntu_5_4_mesh_omfagr.xml <vmtemplate id="ubuntu_5_4_mesh_omfagr"> <operative_system name="debian" password="virtual" username="root" version="5.0"/> <software_configuration> <sshserver port="22"/> </software_configuration> </vmtemplate> voyage_5_4_mesh_omfnode.xml <vmtemplate id="voyage_5_4_mesh_omfnode"> <operative_system name="debian" password="voyage" username="root" version="5.0"/> <software_configuration> <sshserver port="22"/> </software_configuration> </vmtemplate> 40

41 A.3 File List.xml List.xml <?xml version="1.0" encoding="utf-8" standalone="no"?> <ListExternalManager> <ExternalManager IP=" " Model="Wmodel3" Password="virtual" Port="22" Username="root"> <Parameter Exe_command="/wifi_mesh_conf/wlanmodel -u Cmdenv -f" Path_file="/wifi_mesh_conf/" Name_File="antonio1.ini"/> </ExternalManager> </ListExternalManager> 41

42 Bibliografia [1] Prof. Ing. Roberto Canonico, Ing. Roberto Bifulco 2010 Neptune Network Emulator [2] Marco Astronomo 2011 Un sistema per l emulazione di reti wireless multiradio [3] Giancarlo Gaudioso 2010 Un sistema per la gestione degli esperimenti su un testbed virtuale OMF [4] D. D Ambrosio 2010 Framework per l emulazione di reti wireless mesh multiradio [5] M. Boari, S. Balboni, Mondo Digitale Marzo 2007 Tecniche di virtualizzazione: teoria e pratica [6] Cnaponline 2009 Tecnologie di Virtualizzazione Tipi e Differenze erenze.htm [7] Xen.org Community 2012 Xen Overview [8] Winlab, Rutgers University 2012 OMF [9] Thomas Staub, Reto Gantenbein, Torsten Braun 2009 VirtualMesh: An Emulation Framework for Wireless Mesh Networks in OMNeT++ 42