Un sistema per la gestione degli esperimenti su un testbed virtuale OMF

Transcript

1 Universita degli Studi di Napoli Federico II Facolta di Ingegneria CORSO DI STUDI IN Ingegneria Informatica Tesi di Laurea Specialistica Classe delle lauree specialistiche in Ingegneria Informatica Classe n.35/s RELATORE CANDIDATO Ch.mo Prof Roberto Canonico Giancarlo Gaudioso Matr. 885/234 Correlatore Ing. Roberto Bifulco Ing. Giovanni Di Stasi ANNO ACCADEMICO 2009/2010

2 Tesi di Laurea Specialistica Classe delle lauree specialistiche in Ingegneria Informatica Classe n.35/s Relatore Ch.mo prof. Roberto Canonico Correlatori Ing. Roberto Bifulco, Ing. Giovanni Di Stasi Candidato Giancarlo Gaudioso matr. 885/234 Anno Accademico 2009/2010

3 Indice 1 Sistemi di emulazione cluster-based Cluster Virtualizzazione Virtualizzazione Completa Emulazione Assistita Paravirtualizzazione Emulazione Emulazione di Reti Neptune Scopo Architettura Struttura Implementazione Rete Virtuale Definizione Esperimento Dipendenze Descrittore Del Cluster Stati Di Un Esperimento Descrittore Topologia Come si usa I

4 INDICE 3 OMF Scopo Architettura Aggregate Manager Experiment Controller Resource Controller Struttura Servizi installati Gestione dei collegamenti Server di scambio messaggi Database Flusso tipico di un esperimento Come si usa Neptune come substrato di OMF Processo di Integrazione Creazione dei template di macchine virtuali Struttura dello script di configurazione Script di configurazione Esperimento Dimostrativo Conclusioni e Sviluppi futuri 54 A Installazione Xen 55 A.1 Installazione e configurazione di xend e configurazione bridge. 55 A.2 Creazione macchine virtuali (domu) A.3 Creazione Macchina Virtuale B Installazione Omf 61 B.1 MySql e PhpMyAdmin B.2 Aggregate Manager II

5 INDICE B.3 Experiment Controller B.4 XMPP B.5 Resource Controller C Script Di Configurazione 67 C.1 topology.xml C.2 conf agm.xsl C.3 conf nodo.xsl C.4 query db.xsl C.5 totale.sh Bibliografia 73 III

6 Elenco delle figure 2.1 Architettura Neptune Esperimento in Neptune Descrittore Cluster Neptune Stato Esperimento Neptune Accesso Neptune Esperimento in OMF Architettura di OMF Struttura di OMF Layout suggerito Ciclo di vita di un esperimento in OMF Login in Neptune Definizione topologia Creazione topologia Allocazione Virtual Machines Avvio Virtual Machines Lancio dello script di configurazione Lancio dell esperimento A.1 Output Xen A.2 Xm List IV

7 ELENCO DELLE FIGURE B.1 Installazione MySql B.2 Configurazione My Sql B.3 Amministrazione Openfire V

8 Introduzione In questo lavoro di tesi é stato affrontato il problema dell integrazione fra due piattaforme software: Neptune ed OMF. Neptune, acronimo di Network Emulation for Protocol TUNing and Evaluation, é un progetto che ha l obiettivo di realizzare un emulatore di rete flessibile, orientato al multiplexing delle risorse di calcolo e di memorizzazione, sviluppato presso l Universita di Napoli Federico II [6]. E in grado di istanziare una topologia di rete, i cui nodi sono macchine virtuali basate su Xen, creata a discrezione dell utente, in cui é possibile definire in modo preciso le caratteristiche di ogni link. Incorpora un meccanismo di gestione di architetture cluster che si occupa della dislocazione delle macchine virtuali da istanziare sui singoli elementi dell infrastruttura. Questa capacitá offerta dal software mette in condizione l utente del sistema di poter ricreare, reti di complessitá elevata e di caratterizzare molte tipologie di canale trasmissivo. La gestione della distribuzione fisica delle virtual machines é completamente trasparente all utente finale ed al software applicativo installato sui nodi. OMF é l acronimo di Object Management Framework ed é un framework generico per controllare e gestire testbed di rete. É stato inzialmente sviluppato presso la Rutgers University[7], e il suo sviluppo attuale avviene entro il progetto TEMPO presso NICTA (Australia) in stretta collaborazione con gli autori. Rispetto a Neptune non ha la capacitá di istanziare una topologia di rete. Essendo pensato per ambienti di testbed, si suppone che la rete di 1

9 ELENCO DELLE FIGURE test sia giá stata approntata e che sia necessario solo gestire i nodi in modo da eseguire le sperimentazioni necessarie. OMF, puó, al piú, gestire via software le interfacce dei dispositivi, fermo restando che sia giá operativa una rete di controllo attraverso cui scambiare con i nodi dei messaggi di comando. L integrazione di questi due strumenti va a creare una piattaforma di emulazione che permette, da un lato, di poter definire una qualunque topologia di rete, dall altro, di eseguire esperimenti in modo flessibile. Il sistema cosí descritto, potrebbe sembrare un ambiente completamente simulato, ma Neptune, avendo la capacitá di creare topologie che si inseriscono in reti reali, puó dare origine a sistemi che, a seconda dell opportunitá, possono essere costituiti da tutti nodi virtuali, o da un misto fra macchine e link virtuali e nodi e link fisici. Operando come substrato, l azione compiuta da Neptune é invisibile al livello superiore, e quindi ad OMF, che a sua volta puó gestire, in completa trasparenza, reti costituite da nodi virtuali, reali, o reti miste. Il passo di integrazione é consistito, fondamentalmente, nel far creare a Neptune i nodi e la rete di controllo di cui OMF necessita per poter operare. 2

10 Capitolo 1 Sistemi di emulazione cluster-based 1.1 Cluster Un cluster é un insieme di computer connessi tramite una rete telematica ad alta velocitá. Lo scopo di un cluster é quello di distribuire una elaborazione molto complessa tra i vari computer che lo compongono. In sostanza, un problema che richiede molte elaborazioni per essere risolto, viene scomposto in sottoproblemi separati i quali vengono affrontati in parallelo. I cluster, a seconda dello scopo per cui sono destinati, si possono suddividere in quattro categorie principali: ˆ Load Balancing clusters. Utilizzati per la distribuzione automatica del carico di elaborazione. Il servizio elaborativo offerto dal gruppo di macchine viene visto dall utente come una entitá singola di grande capacitá di calcolo. ˆ High Availability clusters. Sono pensati principalmente per garantire la disponibilitá di servizi critici. A differenza dei precedenti, sono caratterizzati dalla ridondanza delle apparecchiature che li compongono, eliminando, cosí il single point of failure. ˆ Compute clusters. Sono destinati ad ospitare servizi caratterizzati 3

11 1.2. VIRTUALIZZAZIONE da un grande flusso di scambio dati, come database o servizi Web. Sono caratterizzati, da un forte interscambio dati fra le singole componenti che sono connesse fra loro da link ad alta velocitá. ˆ Grid computing clusters. All estremo opposto rispetto ai compute clusters si trovano i grid computing clusters. I nodi sono dislocati anche a grande distanza l uno dall altro e tipicamente sono eterogenei fra loro. Sono utili per elaborazioni che non hanno bisogno di condividere dati comuni. Fra le applicazioni che meglio si adattano ad essere implementate su cluster c é la virtualizzazione di risorse. 1.2 Virtualizzazione Con il termine Virtualizzazione viene indicata la tecnica che suddivide le risorse di un unitá elaborativa in diversi ambienti di esecuzione utilizzando varie tecniche di astrazione hardware e software in modo da separare l interfaccia logica dal computer fisico. La virtualizzazione, quindi, nasconde le caratteristiche di una piattaforma di elaborazione all utente finale, mostrandogli una piattaforma astratta necessaria alle sue esigenze. Si fa risalire la nascita di tale approccio agli anni 60 del secolo scorso. Alle origini, la virtualizzazione era una tecnica per ottimizzare l uso di risorse informatiche molto costose e relativamente rare. Mentre oggi, l attuale proliferare di server e PC ha fatto sorgere la necessitá di gestire e utilizzare in modo piú efficiente queste risorse. La virtualizzazione delle infrastrutture é oggi una forte tendenza di settore, ed il concetto di virtualizzazione é diffuso ormai giá da alcuni anni, perché consente alle aziende di utilizzare in maniera piú efficiente le risorse hardware e di ridurre i costi di gestione delle infrastrutture IT. Negli ultimi anni é diventata la linea guida anche per lo sviluppo 4

12 1.2. VIRTUALIZZAZIONE di nuovi processori nell ottica del risparmio energetico e nella necessitá di aumentare le misure di sicurezza. La stessa Intel ha contribuito al progetto Xen introducendo il supporto per la sua tecnologia VT-X 1 che se viene eseguito su sistemi dotati di questa caratteristica permette a Xen di creare delle macchine virtuali che consentono ai sistemi operativi ivi installati di girare senza modifiche. Una tecnologia simile, denominata AMD-V 2, sviluppata da AMD consente di ottenere lo stesso risultato con sistemi basati su processori AMD. Sono attualmente disponibili diversi strumenti di virtualizzazione come Xen, VMware Workstation, Virtual PC, e VirtualBox. La macchina virtuale nasce proprio dalla necessitá di disporre di un ambiente di lavoro dotato elevati standard di sicurezza per l elaborazione. Quando si opta per la virtualizzazione delle risorse, bisogna tener conto dell insorgenza di nuove problematiche. Una delle principali é l isolamento fra gli ambienti virtuali e la gestione delle contese delle risorse hardware. I principali produttori di questo tipo di software hanno affrontato il problema con metodi differenti. Le soluzioni trovate hanno privilegiato aspetti diversi. Alcuni hanno optato per la massima compatibilitá con i sistemi operativi giá presenti, altri hanno puntato all isolamento fra gli ambienti virtuali, altri ancora hanno puntato ad azzerare le differenze di prestazioni fra ambiente reale e virtuale. Le tecniche di virtualizzazione si possono raggruppare in tre grandi categorie: ˆ Virtualizzazione Completa; ˆ Emulazione assistita; ˆ Paravirtualizzazione; 1 Intel Virtualization Technology 2 AMD Virtualization 5

13 1.2. VIRTUALIZZAZIONE Virtualizzazione Completa La Virtualizzazione Completa, consente l esecuzione di sistemi operativi non modificati (o non modificabili per ragioni di licenza) in un ambiente totalmente ricreato ed isolato dal sistema operativo che lo ospita; tale ambiente é realizzato da un apposito software che si occupa di emulare l hardware necessario traducendo le istruzioni eseguite dal sistema ospite in qualcosa che il sistema operativo ospitante sia in grado di eseguire. Come é possibile intuire, la traduzione di ogni singola istruzione é molto onerosa a livello di potenza di calcolo, per ovviare a ció é necessario eseguire la maggior parte delle istruzioni in modo nativo. Sebbene quindi esistano emulatori di CPU differenti dall architettura x86, come ad esempio Qemu che é in grado di emulare ARM, Alpha, MIPS, SPARC o Hercules, questi emulatori tendono ad essere molto lenti poiché devono tradurre ogni istruzione verso l architettura x86, eseguirla, e quindi tradurne il risultato verso l architettura emulata. Imponendo, quindi, un limite sull architettura virtualizzata (x86 virtualizza solo x86), é possibile velocizzare notevolmente l esecuzione dei sistemi guest mappando direttamente memoria e CPU(per quanto riguarda le istruzioni accessibili). Questo limite rende per impossibile virtualizzare sistemi x86 64 se il sistema operativo di base é i386, ció succede perché l architettura i386 prevede l esecuzione di codice in due modalitá: ˆ Real Mode dove ogni processo ha completo accesso a tutto l hardware; ˆ Protected Mode in vengono creati diversi livelli di protezione che possono essere immaginati come anelli concentrici sempre piú restrittivi man mano che si procede verso l esterno. Tra i prodotti disponibili attualmente che adottano la virtualizzazione completa si possono annoverare: Virtualbox, VMWare, qemu, Hercules 6

14 1.2. VIRTUALIZZAZIONE Emulazione Assistita L Emulazione assistita é conosciuta anche come Accelerated Virtualization o con nomi diversi a seconda del produttore. Xen la chiama Hardware Virtual Machine. La piú importante conseguenza di questo supporto in hardware é il superamento del limite della Full Virtualization: grazie a queste estensioni é infatti possibile avere come guest sistemi x86 64 nonostante il sistema ospitante sia i386. Occorre precisare che l attuale virtualizzazione assistita si occupa di aiutare solamente funzioni di CPU e memoria; tutte le funzionalitá di I/O sono ancora emulate Paravirtualizzazione La Paravirtualizzazione é una tecnica in cui il sistema operativo virtualizzato riesce a comunicare direttamente con il motore di virtualizzazione chiamato hypervisor. Questo comporta la necessitá di modificare il kernel del sistema operativo da virtualizzare risultando problematico nel caso di prodotti come Windows che, per motivi di licenza, non permettono tale modifica. Esempi di questa tecnica sono costituiti da Xen o KVM. Xen, infatti, 3 permette l installazione di sistemi operativi Linux con kernel modificato e driver personalizzati. Il vantaggio nell usare la paravirtualizzazione consiste nella maggior velocitá di esecuzione delle applicazioni utente. Il software di virtualizzazione Xen é considerato un riferimento Xen Xen é un monitor di macchine virtuali Open Source rilasciato sotto licenza GPL per piattaforma x86 e compatibili (al momento sono in corso dei port per x86-64 e per IA-64) sviluppato presso il Computer Laboratory dell Universitá di Cambridge. Contrariamente ad altri software di virtualizzazione, Xen non 3 XEN-monitor di macchine virtuali Open Source 7

15 1.3. EMULAZIONE mira a creare un emulazione dell hardware di un generico computer x86, ma piuttosto a regolare e controllare l accesso alle risorse fisiche della macchina da parte delle varie istanze delle macchine virtuali. Questo tipo di approccio consente di ottenere un decadimento delle prestazioni minimo rispetto all esecuzione non-virtualizzata, poiché le istruzioni provenienti dalle macchine virtuali vengono eseguite quasi tutte direttamente sul processore, senza l intervento di un sistema operativo che si ponga tra la macchina virtuale e le risorse fisiche. Xen é sostanzialmente un sottile strato software posto sopra l hardware. Il basso decadimento di prestazioni che l introduzione di Xen comporta, lo rende ideale per essere applicato nell ambito dell emulazione di sistemi telematici. 1.3 Emulazione L emulazione, insieme alla simulazione e agli ambienti di testbed, é uno dei possibili approcci allo studio di un sistema reale. Queste tre tecniche hanno come scopo quello di riprodurre il comportamento e le caratteristiche del sistema in esame. Ognuna di esse pone l accento su un particolare aspetto privilegiando alcune funzionalitá piuttosto che altre. La simulazione é un processo di imitazione delle operazioni eseguite nel tempo da un sistema reale. Rappresenta infatti la trasposizione, in termini logico-matematica- procedurali, di un modello concettuale della realtá. La simulazione é utilizzata per l analisi di sistemi di elaborazione e comunicazione ed in generale in tutte le branche dell ingegneria. Un ambiente di testbed consiste in una infrastruttura di rete costruita appositamente per la valutazione e la verifica di una particolare applicazione distribuita. In tal modo si ottiene un ambiente di testing molto vicino a quello in cui si troverá ad operare l applicazione durante il suo normale funzionamento. Tutte le parti che compongono il testbed sono realizzate utiliz- 8

16 1.3. EMULAZIONE zando componenti reali. Tali caratteristiche consentono un testing rigoroso, trasparente e replicabile dell applicazione. Un emulatore nel senso piú generale possibile duplica le funzioni di un determinato sistema su un secondo sistema differente dal primo. Rappresenta dunque un approccio ibrido che combina elementi reali con elementi astratti. A seconda dei requisiti dell esperimento si stabilisce quali elementi debbano essere implementati realmente e quali debbano essere trattati con un certo livello di astrazione. L emulazione consente di analizzare il comportamento di un sistema reale attraverso un modello concettuale ma permette altresí di interfacciare il sistema con il mondo esterno. Nel caso trattato in questo lavoro di tesi, l emulazione riguarda le reti Emulazione di Reti L emulazione di una rete rappresenta dunque un approccio ibrido che combina elementi reali (come hosts e implementazioni di protocolli) con elementi sintetici, astratti o simulati di una rete (come link, nodi intermedi e traffico di background). In relazione ai requisiti dell esperimento e alle risorse disponibili vengono definiti quali elementi sono reali e quali sono parzialmente o pienamente simulati. In sostanza con il termine emulazione ci si riferisce alla capacitá di inserire un simulatore all interno di una rete reale. Di conseguenza essa fornisce un ambiente che é piú vicino alla realtá rispetto a quello offerto dalla simulazione ed é un valido strumento per la valutazione delle prestazioni e delle funzioni di componenti reali sotto varie condizioni di funzionamento. Poiché l obiettivo dell emulazione é far coesistere e cooperare elementi reali con elementi simulati, é necessario che questi ultimi siano capaci di interagire con i componenti di rete e le applicazioni reali.per ció che riguarda le reti, l emulazione, riguarda la parte infrastrutturale. E, infatti, utile replicare, ad esempio, il comportamento di un particolare tipo di 9

17 1.3. EMULAZIONE canale trasmissivo al fine di testarne le prestazioni o per lo sviluppo di nuovi protocolli. Fra i piú conosciuti emulatori di rete é possibile nominare: ˆ DummyNet DummyNet é uno strumento pensato inizialmente per testare protocolli di rete e puó essere utilizzato anche per la gestione dell ampiezza di banda. E capace di simulare o di forzare l accodamento, le limitazioni di banda, il ritardo, la perdita di pacchetti, e gli effetti multipath. Puó operare sia su workstations che su routers o bridge di rete. Dummynet lavora intercettando i pacchetti nello stack protocollare e passandoli attraverso uno o piú oggetti chiamati queues o pipes che simulano gli effetti dovuti alle limitazioni di banda, ai ritardi di propagazione, coda a lunghezza finita o perdite di pacchetti. E stato realizzato dall Universitá di Pisa ˆ NetEm NetEm, similmente a DummyNet, é un software opensource che consente di parametrizzare in modo completo un nodo o un link di rete. É, quindi, in grado di applicare discipline di traffico, imporre duplicazione o corruzione di pacchetti. Puó, inoltre, imporre valori di delay, packet loss, jitter, bandwidth, ad un collegamento. Anch esso é eseguibile su sistemi Linux. Una piattaforma che si inserisce in questa tipologia di emulatori é Neptune. Uno strumento, invece, che attualmente, fonde gestione delle macchine fisiche e gestione degli esperimenti é Emulab. Emulab Emulab nasce presso l Universitá dello Utah e vanta svariate installazioni presso Universitá e altri Enti di Ricerca. Questa soluzione fornisce un accesso integrato ad un vasto range di ambienti sperimentali: dalla simulazione 10

18 1.3. EMULAZIONE all emulazione fino al testbed su reti in larga scala, unendo tutti questi ambienti sotto una singola interfaccia utente, integrandoli in un unica struttura, sforzandosi di preservare il controllo e la semplicitá d uso della simulazione, senza sacrificare il realismo dell emulazione e della sperimentazione su reti reali. Tale struttura fornisce astrazioni, servizi e gestione delle etichette comuni a tutti, come l allocazione e la designazione dei nomi da dare a nodi e link. Emulab maschera molte delle eterogeneitá dei differenti approcci, mappando le astrazioni all interno di meccanismi di etichettamento e gestione dei domini. L Emulab emulation testbed consta di tre sub-testbed (interoperanti tra di loro qualora fosse necessario), e ciascuno di essi provvede ad un diverso obiettivo di ricerca: ˆ Mobile wireless (robotic testbed) ˆ Fixed wireless (per i test su reti wireless) ˆ Emulab classic Emulab classic é uno strumento di emulazione di reti di tipo time-shared e space-shared che raggiunge nuovi livelli in termini di semplicitá di utilizzo. Diverse centinaia di PC in rack, organizzati in maniera opportuna dal punto di vista della sicurezza, dotati di strumenti web user-friendly, e guidati da script ns-compatibili oppure Java GUI,permettono di effettuare configurazione e controllo delle macchine e dei link a livello hardware. A livello utente puó essere definita la perdita dei pacchetti, il ritardo, la banda e la dimensione delle code. Anche il sistema operativo puó essere completamente rimpiazzato in sicurezza da immagini personalizzate costruite opportunamente dai vari sperimentatori. Come accennato in precedenza, in Emulab una topologia di rete puó essere definita inglobando nodi reali (macchine fisiche del cluster) e nodi virtuali realizzati sul cluster. Per definire i link che collegano tali nodi Emulab adopera un architettura basata su Virtual LAN (VLAN). VLAN é una tecnologia che adopera hardware specifico per realizzare domini 11

19 1.3. EMULAZIONE di broadcast separati fra i nodi, come se questi risiedessero sulla stessa LAN. Accanto alla rete virtuale vi é una specifica rete di controllo che permette agli utenti del sistema di accedere da remoto ai nodi della topologia da loro definiti. Idealmente tale rete dovrebbe essere trasparente ai nodi della topologia, per quanto, per vincoli tecnici non ancora superati, ogni nodo é di fatto a conoscenza della presenza di questa ulteriore rete. Diverse centinaia di PC in rack, organizzati in maniera opportuna dal punto di vista della sicurezza, dotati di strumenti web user-friendly, e guidati da script ns-compatibili oppure Java GUI, permettono di effettuare configurazione e controllo delle macchine e dei link a livello hardware. A livello utente pu ó essere definita la perdita dei pacchetti, il ritardo, la banda e la dimensione delle code. Anche il sistema operativo puó essere completamente rimpiazzato in sicurezza da immagini personalizzate costruite opportunamente dai vari sperimentatori. Come accennato in precedenza, in Emulab una topologia di rete puó essere definita inglobando nodi reali (macchine fisiche del cluster) e nodi virtuali realizzati sul cluster. Per definire i link che collegano tali nodi, Emulab adopera un architettura basata su Virtual LAN (VLAN). VLAN é una tecnologia che adopera hardware specifico per realizzare domini di broadcast separati fra i nodi, come se questi risiedessero sulla stessa LAN. Accanto alla rete virtuale vié una specifica rete di controllo che permette agli utenti del sistema di accedere da remoto ai nodi della topologia da loro definiti. Idealmente tale rete dovrebbe essere trasparente ai nodi della topologia, per quanto, per vincoli tecnici non ancora superati, ogni nodo é, di fatto, a conoscenza della presenza di questa ulteriore rete. 12

20 Capitolo 2 Neptune 2.1 Scopo Neptune (Network Emulation for Protocol Tuning and Evaluation) é un sistema per l emulazione di topologie di reti finalizzato, principalmente, alla valutazione di nuovi protocolli di comunicazione. Tale progetto é stato realizzato dall Universitá Federico II di Napoli[6]. Gli obiettivi di questo progetto sono: ˆ Basso costo di implementazione: conseguito attraverso l uso di componenti hardware general purpose e strumenti software open source; ˆ Completo isolamento tra i diversi nodi emulati: ottenuto attraverso l uso della paravirtualizzazione offerta da XEN; ˆ Utilizzo efficace ed efficiente delle risorse disponibili: realizzato attraverso l uso di algoritmi per l allocazione delle risorse; ˆ Semplicitá d uso: AJAX; grazie al livello di interazione delle applicazioni 13

21 2.2. ARCHITETTURA ˆ Elevate performance: derivate dal basso overhead richiesto dal funzionamento di XEN; ˆ Sicurezza: conseguita attraverso l uso di tecnologie di comunicazione basate su tunneling SSH 1. Neptune consente l emulazione concorrente di diversi esperimenti in completo isolamento tra loro, l allocazione delle topologie di rete avviene in modo automatico. Alcune scelte progettuali fatte sono state inspirate dal sistema Emulab 2, mentre l emulazione di complesse topologie di reti stata adottata la tecnica della paravitualizzazione attraverso l hypervisor XEN. La comunicazione tra il sistema Neptune e l hypervisor XEN avviene attraverso la libreria LibVirt, uno strato software che offre un livello di astrazione per la comunicazione con diversi tipi di hypervisor. 2.2 Architettura L organizzazione di Neptune segue un approccio centralizzato alla gestione dell intero sistema. Uno dei nodi del cluster, che definiremo Neptune Manager fornisce i servizi fondamentali (dhcp, dns, ecc..) ed ospita il software di gestione della configurazione del sistema. Da un punto di vista possiamo immaginare due livelli all interno del cluster: un livello su cui risiede il Manager, che é responsabile della realizzazione dei servizi di gestione del cluster e della comunicazione con l esterno; ed un livello su cui risiedono tutti gli altri nodi, che rappresenta l infrastruttura di emulazione vera e propria (Figura 2.1). 1 Secure Shell- Permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host 2 Emulab - Sistema per l emulazione cluster based 14

22 2.3. STRUTTURA Figura 2.1: Architettura Neptune 2.3 Struttura Implementazione Rete Virtuale La realizzazione della rete virtuale consiste nella realizzazione di un certo numero di link bidirezionali fra determinati nodi. I nodi in questione sono macchine virtuali, gestite da hypervisor di diverse tecnologie, che risiedono su computer organizzati in un cluster, in cui la connettivitá é garantita da una rete LAN dove simulare i link fra i nodi con le relative proprietá (bandwidth, delay, loss rate, ecc.). E possibile adoperare sostanzialmente due tecniche di link multiplexing: ˆ IP aliasing: prevede che la definizione del link avvenga interamente al 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 Definizione Esperimento Nella definizione di un esperimento sono definiti, due tipi di attori: ˆ Amministratore: ha il compito di gestire la configurazione di ogni nodo fisico facente parte del cluster; ˆ Utente: definisce ed esegue esperimenti. In (Figura 2.2) É riportato uno schema di esecuzione di un esperimento. 15

23 2.3. STRUTTURA Figura 2.2: Esperimento in Neptune Dipendenze Neptune richiede sistema operativo Linux, la versione GWT dipendenza dalle seguenti librerie: e la ˆ GWT Drag-and-Drop 2.5.6; ˆ GWTLib 1.2; ˆ gwt-canvas 0.4.0; ˆ gwt-mosaic Le seguenti librerie Java: ˆ libvirt 0.2.1; ˆ trilead-ssh2 build GWT - Google Web Toolkit 16

24 2.3. STRUTTURA Figura 2.3: Descrittore Cluster Neptune Descrittore Del Cluster Il cluster descriptor (Figura 2.3) ha il compito di descrivere la composizione, in termini di macchine fisiche, del cluster. Di ciascuna macchina sará descritta la composizione hardware, si descrive inoltre per ogni macchina, l Ip delle interfacce di rete, il software installato e le virtual machine instanziate sulla macchina. 17

25 2.3. STRUTTURA Figura 2.4: Stato Esperimento Neptune Stati Di Un Esperimento Un esperimento puó trovarsi nei seguenti stati: ˆ Undefined: esperimento creato e ad esso sono stati associati un nome identificativo ed un amministratore, ma non le informazioni sulle risorse richieste; ˆ Defined: l esperimento é stato definito in tutte le sue parti, contiene anche le informazioni sulle risorse richieste; ˆ Waiting: l esperimento é in attesa di allocazione sul cluster; ˆ Running: l esperimento é pronto per l utilizzo. L ambiente di emulazione é totalmente configurato e funzionante. In (Figura 2.4) sono riportati i stati possibili in cui puó trovarsi un esperimento e le possibili transizioni. 18

26 2.3. STRUTTURA Descrittore Topologia Neptune, per descrivere la topologia, utilizza il file topology descriptor.xml che descrive in modo completo la configurazione di una particolare topologia. Di seguito viene riportata una topologia di rete descritta da Neptune costituita da 2 nodi ed un link. <?xml version="1.0" encoding="utf-8" standalone="no"?> <topology id="18apr_1"> <nodes> <node id="0"> <description/> <name/> <cpu amount="0" clock="0" name="" type=""/> <ram dimension="256"/> <hd dimension="2.0"/> <network_interfaces> <interface MAC="7E:8F:F2:23:6D:8B" name="eth0" type=""> <interface_binding type="hif"/> <ip address=" " subnetmask=" " type="control" version="4"/> </interface> <interface MAC="96:5B:1B:13:01:F1" name="eth1" type=""> <interface_binding type="bridge"/> <ip address=" " subnetmask=" " type="topology" version="4"/> </interface> </network_interfaces> <operative_system name="debian" password="antoxps" username="root" version="5.0"/> <software_configuration template="debian5_omfagr"> <sshserver port="22"/> <software name="omf-nodehandler" type="omf-software" version="5.1"/> <software name="omf-aggregatemanager" type="omf-software" version="5.1"/> </software_configuration> </node> <node id="1"> <description/> <name/> <cpu amount="0" clock="0" name="" type=""/> <ram dimension="256"/> <hd dimension="2.0"/> <network_interfaces> <interface MAC="BE:C9:87:21:DE:BF" name="eth0" type=""> <interface_binding type="hif"/> 19

27 2.4. COME SI USA <ip address=" " subnetmask=" " type="control" version="4"/> </interface> <interface MAC="9E:6B:61:7C:5B:A8" name="eth1" type=""> <interface_binding type="bridge"/> <ip address=" " subnetmask=" " type="topology" version="4"/> </interface> </network_interfaces> <operative_system name="debian" password="antoxps" username="root" version="5.0"/> <software_configuration template="debian5_omfnode"> <sshserver port="22"/> <software name="omf-nodemanager" type="omf-software" version="5.3"/> </software_configuration> </node> </nodes> <links> <link id="link0" type="fullduplex"> <end_point nodeid="0" type="source"> <multiplexing tech="olpi"/> <interface name="eth1"/> </end_point> <end_point nodeid="1" type="destination"> <multiplexing tech="olpi"/> <interface name="eth1"/> </end_point> <property name="bandwidth" value="100kbps"/> <property name="delay" value="0ms"/> <property name="loss" value="0.0%"/> <property name="duplicate" value="0.0%"/> <property name="corrupt" value="0.0%"/> </link> </links> </topology> 2.4 Come si usa Il sistema é accessibile attraverso una interfaccia web-based, molto interattiva, realizzata in tecnologia AJAX(Figura 2.5) Gli utenti del sistema sono divisi in due categorie: ˆ Amministratori; 20

28 2.4. COME SI USA Figura 2.5: Accesso Neptune ˆ Utenti semplici; L amministratore ha il completo accesso a tutte le funzionalitá del programma, si occupa della creazione e gestione degli utenti del sistema. É tenuto a creare nuovi esperimenti per gli utenti che ne fanno richiesta. Deve decidere come e quando allocare un esperimento. Ha il pieno controllo delle macchine fisiche e si occupa della loro amministrazione. Il sistema gli consente di monitorare le performances dei vari nodi. Inoltre puó controllare l avanzamento del processo di allocazione delle topologie ed eventualmente correggere eventuali malfunzionamenti. Fornisce agli utenti dei templates di topologie per semplificare il procedimento di definizione dei nuovi esperimenti. Ha piena visione dello stato del cluster e della dislocazione dei nodi virtuali sulle macchine fisiche. L utente ha il compito di descrivere le topologie di rete da emulare e quindi fare richiesta per la loro allocazione sul cluster. Inoltre puó decidere se condividere il proprio esperimento con altri utenti. La definizione di un esperimento implica la descrizione della topologia di rete. 21

29 2.4. COME SI USA Quest operazione, per le topologie di piccole dimensioni, pu avvenire attraverso l uso di un interfaccia grafica. Per la descrizione di grosse topologie é conveniente descrivere la rete attraverso un file XML. Ad ogni utente viene data la possibilitá di visionare solo gli esperimentidi suo intereresse, e non vedere gli esperimenti creati da altri utenti. 22

30 Capitolo 3 OMF 3.1 Scopo OMF 1 [7] é un framework generico per controllare e gestire testbed di rete. Nel lavoro di tesi che é stato svolto, é stato utilizzato per la gestione di esperimenti su topologie di rete emulate. OMF, come detto, costituisce un ambiente di lavoro che, in generale, mette a disposizione : ˆ Un linguaggio spefico del dominio applicativo, detto OEDL 2, che permette all utente di descrivere: Le risorse necessarie per un esperimento e la loro configurazione. Le applicazioni da usare in un esperimento e le misure da acquisire da esse. I diversi task da compiere durante un esperimento, il tempo e gli eventi che le generano. ˆ Un insieme di strumenti software, che: Accetta come ingresso l esperimento descritto in precedenza. 1 OMF- Object Management Framework 2 OEDL- OMF Experiment Description Language 23

31 3.1. SCOPO Figura 3.1: Esperimento in OMF Inizializza ed imposta le risorse necessarie con le configurazioni e le applicazioni con cui svolgere gli esperimenti. Invia i comandi alle risorse per eseguire effettivamente gli esperimenti all istante o all evento appropriato. Acquisisce dati di misura provenienti dalle applicazioni e/o dalle risorse. OMF ha in ingresso uno script che descrive un esperimento utilizzando il linguaggio OEDL. Disloca e configura questo esperimento sui nodi della rete emulata descritta dall utente e ne inizializza e controlla l esecuzione. Mentre l esperimento viene eseguito, i dati sensibili vengono misurati e accumulati. 24

32 3.2. ARCHITETTURA I valori acquisiti vengono memorizzati in un database per analisi successive, oppure, possono essere riutilizzati direttamente da OMF nel corso dell esperimento per variare dinamicamente alcuni parametri di lavoro. OMF ha come utilizzatori, due tipi di figure: ˆ Lo Sperimentatore, il quale, ha a disposizione un insieme di strumenti per descrivere ed impostare gli esperimenti, eseguirli e acquisirne i risultati. ˆ L operatore ha, invece, a disposizione un gruppo di servizi per gestire in modo efficiente le risorse reali o emulate a disposizione ( resettare i nodi, acquisire informazioni sullo loro stato, installare nuovi sistemi operativi ). É importante notare che gli strumenti software di OMF non sono studiati per una piattaforma hardware specifica, nonostante ció, é stato installato e configurato su una molteplicitá di sistemi basati su differenti tipi di tecnologie. 3.2 Architettura L architettura di OMF segue un approccio di tipo distribuito. In un generico testbed di OMF sono coinvolte tre entitá: ˆ Aggregate Manager ˆ Experiment Controller ˆ Resource Controller Aggregate Manager L Aggregate Manager gestisce tutte le risorse presenti nel testbed, fornisce allo sperimentatore l accesso ad un sottoinsieme di queste risorse con la possibi- 25

33 3.2. ARCHITETTURA litá di imporre delle restrizioni. La versione attuale dell Aggregate Manager svolge, in particolare, le seguenti attivitá: ˆ Gestisce lo Chassis Manager che é un controllore usato per l accensione e lo spegnimento di una risorsa. Ovviamente,é presente solo nel caso in cui la risorsa é reale e non emulata. ˆ Gestisce un database di informazioni per le risorse disponibili e tutte le informazioni relative al testbed. ˆ Avvia o ferma il software Frisbee che distribuisce/salva le immagini degli Hard Disk (o delle eeprom) dei dispositivi da/per una repository di tali immagini. Anche questa mansione é maggiormente orientata piú ai testbed fisici che a quelli emulati. ˆ Puó gestire il boot remoto dei dispositivi. ˆ Fornisce accesso remoto e permette query ad un possibile database di misurazioni. Chassis Manager É costituito da una scheda elettronica integrata o integrabile nella mainboard del nodo che gestisce l alimentazione del dispositivo. É un componente che comunica via Ethernet con l Aggregate Manager. Frisbee É un sistema per salvare, trasferire ed installare immagini complete di Hard Disk. É pensato per operare in un contesto di rete LAN e permette di inviare via Ethernet in modo simultaneo le immagini dei dischi a tutti i client interessati. Frisbee é, inoltre, dotato di una tecnica di compressione che aumenta notevolmente la velocitá di trasferimento dei dati. 26

34 3.2. ARCHITETTURA Experiment Controller L Experiment Controller é l entitá software responsabile di dislocare, controllare ed organizzare l esperimento secondo le intenzioni dell utilizzatore. Accetta in ingresso ed elabora l Experiment Description. Coopera con l Aggregate Manager del testbed per configurare le risorse sperimentali in accordo con la descrizione, una volta che le risorse sono configurate l Experiment Controller comunica con il Resource Controller (Descritto di seguito) ed invia i comandi che effettivamente realizzeranno l esperimento. Experiment Description É uno script fornito in ingresso all Experiment Controller che elenca le risorse necessarie all esperimento e l insieme di azioni da svolgere per realizzarlo Resource Controller Il Resource Controller é l entitá che risiede in ognuna delle risorse disponibili del testbed. Ogni istanza di esso attende i comandi emanati dall Experiment Controller, li esegue, e restituisce tutte le informazioni che pervengono dall esecuzione del comando. In sintesi, il Resource Controller é responsabile dell esecuzione dei comandi di esperimento inviati ad una risorsa. In aggiunta a questa funzione di controllo, é attualmente responsabile di alcune funzioni di gestione della risorsa, come la ricezione e la scrittura dell immagine del disco nella memoria del dispositivo controllato. In aggiunta a queste tre entitá fondamentali, non bisogna tralasciare un altro componente essenziale al sistema: l OEDL. Questa sigla sta per OMF Experiment Description Language. É il linguaggio attraverso cui viene descritto l esperimento di OMF,é un linguaggio di alto livello basato sul linguaggio Ruby[15]. É un Domain-Specific Language con tutti i costrutti necessari per lo svolgimento degli esperimenti. Lo script definito in questo linguaggio é 27

35 3.3. STRUTTURA Figura 3.2: Architettura di OMF elaborato dall Experiment Controller e contiene la definizione della topologia e le azioni da compiere sui nodi. 3.3 Struttura La struttura di lavoro di OMF é essenzialmente composta da: ˆ Un Aggregate Manager ˆ Uno o piú Experiment Controller ˆ Una pluralitá di nodi L Aggregate Manager e gli Experiment Controller hanno una funzione di gestione, monitoraggio, e raccolta dati provenienti dai nodi. I nodi sono, invece, oggetto dell azione di OMF. Su ognuno di essi risiede l entitá detta 28

36 3.3. STRUTTURA Figura 3.3: Struttura di OMF Resource Controller, che, come detto in precedenza, gestisce il nodo sia per ció che riguarda il download dell immagine disco che per l esecuzione dei comandi emanati dall Experiment Controller. L Aggregate Manager, allo stato attuale di OMF, é sempre unico, mentre gli Experiment Controller possono essere piú d uno, il numero dei nodi dipende dall esperimento e tutti questi elementi possono essere reali o virtualizzati. Una visione globale si puó avere dalla Figura 3.3: Il compito svolto da OMF per mettere a disposizione dello sperimentatore un ambiente flessibile di testing, si riassume, schematicamente nelle seguenti azioni: ˆ Istanziare una rete di controllo che permette di collegare le entit ị gestione e quelle di sperimentazione. 29

37 3.3. STRUTTURA ˆ Scambiare messaggi espressi in formato comune a tutti gli elementi per svolgere tutte le attivitá, sia di gestione che di sperimentazione. ˆ Conoscere tutti i nodi di sperimentazione disponibili e le loro caratteristiche. ˆ Mappare tutti i nodi assegnando un ordinamento logico e poterli assegnare agli esperimenti. ˆ Erogare i comandi necessari seguendo una tempificazione dettata dallo script di esperimento. ˆ Ricevere i messaggi di ritorno dai nodi relativi a compiti di gestione o di acquisizione risultati. Queste caratteristiche vengono implementate utilizzando diversi elementi software: ˆ Servizi sul S.O. di ogni entitá coinvolta. ˆ Un database. ˆ Un server di messaggistica. ˆ Un linguaggio di scripting appositamente adattato Servizi installati OMF prevede su ogni macchina, reale o virtuale, l installazione di uno o piú servizi,come illustrato prima. In genere, l Aggregate Manager e l Experiment Controller sono ospitati sulla stessa macchina, e dal punto di vista implementativo, sono costituiti da due servizi impostati come autopartenti che comunicano tramite Openfire[?, openfire] Il primo, inoltre, accede anche al database per il recupero 30

38 3.3. STRUTTURA Figura 3.4: Layout suggerito delle informazioni sui nodi. Il Resource Controller risiede su ognuno dei nodi e comunica attraverso Openfire, anch esso é un servizio impostato come autopartente Gestione dei collegamenti L ambiente naturale di lavoro di OMF sono le reti telematiche sia cablate che wireless. Essendo studiato principalmente per ambienti di testbded, in cui i nodi e i collegamenti sono entitá reali, le potenzialitá sono concentrate nella gestione flessibile dell ambiente di test. Grazie, infatti, all OEDL e facilmente allestibile un esperimento fra nodi di prova. Per rendere attuabile questa potenzialitá, OMF utilizza due reti (Figura 3.4): ˆ Rete di Controllo ˆ Rete di Esperimento 31

39 3.3. STRUTTURA Come si vede dalla figura, esistono le due reti, quella di controllo é di tipo cablato, quella di esperimento é di tipo wireless Server di scambio messaggi OMF utilizza, per mettere in comunicazione tutte le entitá coinvolte, un server di messaggistica istantanea chiamato Openfire. Questo server, scritto in Java, utilizza il protocollo XMPP 3. Ha il compito di gestire tutta la messaggistica che viaggia tra gli apparati di gestione e i nodi. É dotato di un database interno in cui vengono mappati tutti i nodi di esperimento. Risiede, attualmente sulla macchina che ospita l Aggregate Manager ed ha un interfaccia Web di configurazione, la sua configurazione viene fatta solo una volta all atto dell installazione. In particolare, il software dell Aggregate Manager figura nel server XMPP con il ruolo di amministratore Database OMF ha tra i suoi elementi fondamentali un database MYSQL che contiene: ˆ Tutte le informazioni necessarie relative ai nodi, nella fattispecie: Indirizzo IP e MAC della rete di controllo Informazioni relative allo hardware del dispositivo, includenti il tipo di scheda madre, il produttore ed altre informazioni di supporto ID univoco assegnato ad ogni dispositivo La posizione logica di ogni nodo, identificata dalle tre coordinate X, Y, Z. 4 3 XMPP- É l abbreviazione di Extensible Messaging and Presence Protocol (XMPP). É un insieme di protocolli aperti di messaggistica istantanea e presenza basato su XML 4 Ogni nodo, infatti, viene inteso come punto in uno spazio a tre dimensioni. I nodi, sono quindi, disposti in una griglia virtuale ed identificati da un ID 32

40 3.3. STRUTTURA ˆ Informazioni relative al testbed/emulazione, ossia: Nome ed ID del testbed IP della rete di controllo Indirizzi IP dei servizi ausiliari Il database, va popolato, attualmente, in modo manuale eseguendo le query riguardanti i nodi aggiungendo tutti i dati necessari. In questo lavoro di tesi, la fase di popolamento del database é stata automatizzata attraverso appositi script. Nella sua installazione, é prevista anche l aggiunta di PHPMyAdmin per facilitare l inserimento dei dati Flusso tipico di un esperimento Qui viene descritto l andamento tipico di un esperimento in OMF. ˆ L utente compone uno script di esperimento e lo passa all Experiment Controller. ˆ L Experiment Controller interpreta lo script ed invia le richieste all Aggregate Manager per la configurazione delle risorse necessarie. ˆ I servizi dell Aggregate Manager inizializzano e configurano queste risorse. ˆ Quando le risorse sono pronte, l Experiment Controller invia i comandi al Resource Controller di ogni nodo. ˆ Il Resource Controller interpreta i comandi ed esegue le azioni. ˆ L esperimento é attualmente in fase di Running ˆ Durante la fase di esecuzione vengono eventualmente comunicate le misurazioni necessarie. 33

41 3.4. COME SI USA ˆ Al termine dell esperimento sono disponibili i dati per l analisi dei risultati. 3.4 Come si usa In questa sezione viene descritto il ciclo di vita di un esperimento svolto con OMF. I passi base da compiere per portare a termine un esperimento sono essenzialmente quattro: 1. Sviluppo o adattamento del software da valutare: Questa fase consiste nello sviluppo del software da provare sulla rete emulata, quest ultimo puó essere un applicativo sviluppato in un qualsiasi linguaggio di programmazione, oppure, si puó utilizzare un tool giá pronto pensato specificamente per l analisi di parametri di interesse. 2. Sviluppo dell esperimento: La seconda fase consiste,invece, nello sviluppare una Application Definition e successivamente una Experiment Description. L Application Definition puó essere vista come un interfaccia che rende le entitá costituenti OMF capaci di interagire e sovraintendere con l applicativo definito in precedenza. Questa interazione puó consistere nel passaggio di parametri, nell acquisizione di misurazioni o nell accesso agli archivi che contengono il software da testare. L Experiment Description, invece, elenca le risorse necessarie richieste dall esperimento, che, come detto, possono essere costituite da nodi e link fisici o emulati, e le azioni da compiere su di esse al fine di realizzare l esperimento. É uno schedulatore di eventi che definisce quali azioni compiere sui nodi e quando farlo. 3. Esecuzione dell esperimento: Avviando l entitá software preposta all esecuzione, parte il coordinamento dei nodi e del software sperimentale su di essi. 34

42 3.4. COME SI USA Figura 3.5: Ciclo di vita di un esperimento in OMF 4. Accesso ed analisi dei risultati: In questo quarto passo, si puó accedere alle misure raccolte durante l esecuzione dell esperimento ed analizzarle. Per fare ció, nella fase precedente, devono essere stati definiti dei parametri sottoposti a misurazione. 35

43 Capitolo 4 Neptune come substrato di OMF Introduzione Dopo aver descritto separatamente Neptune ed OMF, in questo capitolo viene descritta l integrazione di queste due piattaforme. 4.1 Processo di Integrazione Il processo di integrazione, come anticipato, é consistito nel fornire ad OMF una rete precedentemente istanziata tramite Neptune e nell automatizzare la configurazione di OMF cosí da creare un ambiente di lavoro pronto all esecuzione di un esperimento. L automatizzazione della configurazione avviene eseguendo uno script creato appositamente. Quindi, l utente del sistema integrato ha il solo compito di: ˆ Creare una topologia di rete con Neptune ˆ Fornire la descrizione della topologia allo script di configurazione ˆ Eseguire lo script di configurazione ˆ Lanciare l esperimento 36

44 4.1. PROCESSO DI INTEGRAZIONE Dal lato operativo, invece, il processo di integrazione ha seguito queste fasi: 1. Creare due template di macchine virtuali: ˆ Template Aggregate Manager + Experiment Controller ˆ Template Nodo 2. Installare su ogni template i servizi OMF necessari. 3. Creare uno script che, partendo dalla descrizione topologica, e agendo sui file di configurazione e sul database, rende il sistema pronto all esecuzione dell esperimento Creazione dei template di macchine virtuali Per impostare i due template di macchina virtuale, ne é stato sfruttato uno basato su Debian 5.0 Lenny[1] reperibile sul sito ufficiale di Neptune[6] che ha giá ricevuto le modifiche al kernel necessarie per essere virtualizzato con Xen[2]. L immagine Debian destinata ad ospitare l Aggregate Manager ha dovuto subire un espansione preventiva, in quanto lo spazio richiesto dal software era superiore a quello disponibile ed inoltre, sono state variate alcuni file per poterla rendere accessibile tramite la console di Xen. Di seguito é esposta la procedura di espansione di un file immagine e poi vengono riportati i passi di modifica ai file. Procedura di espansione di un immagine Xen I passi necessari per l espansione di un immagine Xen sono i seguenti: 1. Assicurarsi che l immagine non si utilizzata da Xen 2. Aggiungere lo spazio necessario con il comando: 37

45 4.1. PROCESSO DI INTEGRAZIONE dd if=/dev/zero bs=1024k count=1024 >> nome_file_immagine 3. Forzare un controllo sul filesystem: e2fsck -f nome_file_immagine 4. Espandere il filesystem: resize2fs nome_file_immagine Modifica dei file per l abilitazione della console Xen Per effettuare le modifiche é stato necessario montare l immagine in loop ed accedere a due file. Di seguito é spiegata la procedura: 1. Montare in loop il file immagine: 12 ˆ losetup /dev/loop0 nome file immagine ˆ kpartx -av /dev/loop0 ˆ mount /dev/mapper/loop0p1 /mnt/ 2. Nella directory /mnt/ é accessibile l immagine montata. Modificare il file al percorso /boot/grub/menu.lst aggiungendo alla riga kernel la dicitura console=hvc0 xencons=tty. 3. Modificare il file al percorso /etc/inittab decommentando la riga 1: tty1 1 Accertarsi con il comando losetup /dev/loop0 che la periferica loop0 sia libera, altrimenti scegliere una delle successive 2 Il programma kpartx potrebbe non essere disponibile sulla macchina su cui si stanno eseguendo le modifiche, nel qual caso, installarlo con il comando apt-get install kpartx 38

46 4.1. PROCESSO DI INTEGRAZIONE Preparazione del Template Aggregate Manager Dopo aver effettuato le modifiche descritte sopra, avviare con Xen l immagine cosí approntata. Nel nostro caso, sia AM 3 che EC 4 verranno ospitati sulla stessa macchina virtuale. Bisogna, ora, eseguire l installazione di OMF come indicato sul sito ufficiale all indirizzo: Guide 52 e come riportato in Appendice B. In particolare B.2 per l Aggregate Manager e B.3 per l Experiment Controller. Una volta ultimata l installazione con le varianti esposte nelle appendici, deve essere effettuata un operazione di sostituzione simbolica per rendere i file di configurazione del template indipendenti dal particolare indirizzo IP che verrá assegnato da Neptune. Questi stringhe servono, in seguito, nella fase di lancio dello script di configurazione automatica che, tramite il comando sed di Linux opererá la sostituzione con l indirizzo IP del server XMPP. Le stringhe che verranno sostituite sono: XMPP ADDRESS e INDIRIZZO XMPP. La sostituzione va effettuata nei seguenti file: ˆ /etc/omf-aggmgr-5.2/available/cmcstub.yaml alla riga inventory url: IP:5052/inventory sostituire inventory url: ˆ /etc/omf-expctl-5.2/nodehandler.yaml alla sezione :communicator:, alla voce :server: indirizzo IP sostituire :server: XMPP ADDRESS ˆ /etc/omf-expctl-5.2/nodehandlerslave.yaml alla sezione :xmpp-server: 3 AM- Aggregate Manager 4 EC- Experiment Controller 39

47 4.1. PROCESSO DI INTEGRAZIONE alla voce host: sostituire host: indirizzo IP XMPP ADDRESS ˆ /usr/share/openfire/embedded-db/openfire.script alla voce INSERT INTO OFPROPERTY VALUES( xmpp.domain, indirizzo IP ) sostituire INSERT INTO OFPROPERTY VALUES( xmpp.domain, INDIRIZZO XMPP ) Attenzione! Non usare mai il tasto TAB per le spaziature poiché non é supportato dall interprete Yaml. Usare sempre la barra spaziatrice. É, poi, necessario disabilitare l avvio automatico dei servizio Openfire. In ultimo, bisogna collegarsi al database inventory (eventualmente con PhpMyAdmin[12])ed eliminare tutte le righe dalle tabelle: ˆ devices ˆ locations ˆ nodes Preparazione del Template Nodo Nel template Nodo é necessario disabilitare dalla partenza automatica il servizio omf-resctl-5.2. Bisogna, poi, effettuare la sostituzione simbolica con la stringa XMPP ADDRESS nel file /etc/omf-resctl-5.2/nodagent.yaml; alla voce xmpp server: indirizzo IP sostituire xmpp server: INDIRIZZO XMPP Attenzione! Non usare mai il tasto TAB per le spaziature poiché non é supportato dall interprete Yaml. Usare sempre la barra spaziatrice. 40

48 4.1. PROCESSO DI INTEGRAZIONE Struttura dello script di configurazione Oltre alla preparazione dei template di Virtual Machines, é stato necessario strutturare uno script di configurazione che rende automatico tutto il processo di settaggio dei parametri e di avvio dei servizi di OMF. Lo script (v. Appendice??) creato é un normale script in ambiente Linux che svolge quattro tipi di operazioni: ˆ Richiama altri script ausiliari ˆ Esegue operazioni di parsing xml con xsltproc ˆ Effettua sostituzioni simboliche con sed ˆ Istanzia sessioni ssh ed scp Opera sul file topology.xml (v. Appendice C.1) che é il descrittore della topologia di rete eleborato da Neptune. Puó essere localizzato su una qualsiasi macchina che comunica con la rete di controllo di OMF, oppure puó risiedere sull Aggregate Manager. Per poter svolgere tutte le operazioni previste, si avvale di quattro file in formato xsl, i quali, agendo sul file di topologia, tramite il programma xsltproc, estraggono di volta in volta tutte le informazioni di configurazione necessarie. Xsltproc, XSLT, XML Xsltproc é un applicativo a riga di comando per applicare fogli di stile XSLT a documenti XML. XSLT 5 é il linguaggio di trasformazione dell XML; deriva direttamente dal linguaggio XSL, infatti i file di questo formato sono essenzialmente file di testo, contengono elementi ed attributi ed hanno l estensione.xsl. L obiettivo principale per cui l XSLT é stato creato é rendere possibile 5 XSLT- extensible Stylesheet Language Transformations 41

49 4.1. PROCESSO DI INTEGRAZIONE la trasformazione di un documento XML in un altro documento. Per generare una trasformazione XSLT occorrono due file: il documento da trasformare (in XML) ed un documento contenente il foglio di stile XSL, che fornisce la semantica per la trasformazione. Il foglio di stile XSLT vede un documento XML come una serie di nodi strutturati ad albero. É formato da un insieme di modelli (template) che contengono le regole di trasformazione dei tag del documento XML. SED Il comando sed é uno dei comandi standard del sistema operativo Linux ed é un editor di riga non interattivo. Riceve un testo come input, o dallo stdin o da un file, esegue alcune operazioni sulle righe specificate, una alla volta, quindi invia il risultato allo stdout o in un file. Negli script di shell, sed é, di solito, una delle molte componenti di una pipe. Sed determina le righe dell input, su cui deve operare, tramite un indirizzo che gli é stato passato. Questo indirizzo puó essere rappresentato sia da un numero di riga sia da una verifica d occorrenza, tipicamente, nello script composto per la configurazione di OMF, vengono effettuate molteplici verifiche di occorrenza. SSH ed SCP Tutte le comunicazioni che avvengono fra lo script e le macchine da configurare avvengono tramite il protocollo SSH 6 che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host. Il client SSH ha una interfaccia a linea di comando simile a quella di telnet e rlogin, ma l intera comunicazione (ovvero sia l autenticazione che la sessione di lavoro) avviene in maniera cifrata. Esistono principalmente due metodi di autenticazione per controllare l accesso ad un server ssh: 6 SSH- Secure SHell 42

50 4.2. SCRIPT DI CONFIGURAZIONE ˆ Username/Password fornite dall utente via terminale. ˆ Chiave pubblica scelto poiché non richiede la digitazione manuale. La procedura con chiave pubblica é illustrata di seguito: 1. Generazione delle 2 chiavi: pubblica e privata nella cartella /root/.ssh/ con il comando: ssh-keygen -t rsa Collegamento in ssh sulla machina remota e copia della chiave pubblica con il comando: scp id ras.pub root@<ip REMOTO>:/root/.ssh/ 3. Collegamento in ssh sulla machina remota ed esecuzione del comando: cat id rsa.pub >> authorized keys Sul template Aggregate Manager sono presenti entrambe le chiavi generate, mentre sul template Nodo é presente solo la chiave pubblica, ció perché l A.M. deve collegarsi ai nodi, quindi ha bisogno per autenticarsi, della chiave privata, mentre i nodi, essendo sempre server ssh necessitano solo di quella pubblica. Inoltre, sull A.M. deve esserci anche la chiave pubblica perché anch esso é destinatario dei comandi generati dallo script. La chiave privata deve, quindi, in ogni caso, essere presente sulla macchina da cui é eseguito lo script che ha bisogno di autenticarsi presso l A.M. ed i nodi. 4.2 Script di configurazione Dopo aver descritto tutti gli elementi che lo compongono, di seguito sono elencati tutti i passi eseguiti dallo script: 1. Configurazione dei file nell Aggregate Manager e nei nodi con i comandi: 43

51 4.2. SCRIPT DI CONFIGURAZIONE xsltproc conf agm.xsl topology.xml > conf agm.sh xsltproc conf nodo.xsl topology.xml > conf nodo.sh che generano due script ausiliari a partire dagli stylesheet conf agm.xsl e conf nodo.xsl 2. Impostazione dei permessi ed esecuzione degli script generati dinamicamente: chmod +x conf agm.sh chmod +x conf nodo.sh./conf agm.sh./conf nodo.sh É essenziale configurare prima l A.M. (dove risiede il server XMPP) e poi i nodi. 3. Generazione delle query sul database dell A.M. per il popolamento con le informazioni sui nodi: xsltproc query db.xsl topology.xml > update db.sql 4. Sostituzione di alcuni caratteri nelle query appena generate per una corretta esecuzione: sed -i s/[.][1-9]*[@]/.0/g update db.sql sed -i s/@@[0-9]*[.][0-9]*[.][0-9]*[.]//g update db.sql 5. Accesso in ssh sulla macchina AGM creando la directory /query con permessi stabiliti. ssh root@$1 mkdir query chmod 777 query (Notare nel comando l espressione $1 che costituisce un parametro per lo script da passare tramite riga di comando) 6. Copia sulla macchina AGM remota del file.sql generato precedentemente ed aggiornamento del database: scp update db.sql root@$1:/root/query/ 44

52 4.2. SCRIPT DI CONFIGURAZIONE ssh mysql inventory < /root/query/update db.sql ssh rm -r /root/query/ 7. Popolamento del database interno di Openfire[13]: xsltproc create sysnode.xsl topology.xml > create sysnode.sh chmod +x create sysnode.sh./create sysnode.sh 8. Rimozione dei file di ausilio: rm conf agm.sh rm conf nodo.sh rm update db.sql rm create sysnode.sh Esperimento Dimostrativo Come prova della buona funzionalitá dello script é stato realizzato un esperimento dimostrativo. In questa sezione viene mostrato tutto il processo, sintetizzato alla sezione 4.1. Costruzione della topologia La topologia é costituita da un A.M. e da due nodi, il file completo é visibile in appendice C.1. Per realizzare la topologia é necessario: ˆ Effettuare il login in Neptune (Figura 4.1) ˆ Creare un nuovo esperimento (Figura 4.2) ˆ Definire una topologia ed effettuare il deployment dell esperimento(figura 4.3) ˆ Effettuare l allocazione e avviare le macchine virtuali (Figura 4.4) 45

53 4.2. SCRIPT DI CONFIGURAZIONE Figura 4.1: Login in Neptune Figura 4.2: Definizione topologia ˆ Copiare dall XML Editor la descrizione della rete e salvarla in un file topology.xml che verrá analizzato dallo script (Figura 4.5) Figura 4.3: Creazione topologia 46

54 4.2. SCRIPT DI CONFIGURAZIONE Figura 4.4: Allocazione Virtual Machines Figura 4.5: Avvio Virtual Machines Esperimento in OEDL L esperimento che viene eseguito é un semplice ping reciproco fra i due nodi, coordinato dall A.M., descritto in OEDL, e mostrato di seguito: #------DEFINIZIONE DELLE AZIONI DA ESEGUIRE SUI NODI----- defapplication( nodo24, dumpapp1 ) { app app.shortdescription = Ping verso il nodo25 app.path= ping c 3 } defapplication( nodo25, dumpapp2 ) { app app.shortdescription = Ping verso il nodo24 app.path= ping c 3 } 47

55 4.2. SCRIPT DI CONFIGURAZIONE #------ASSOCIAZIONE DEI NODI AI GRUPPI info( gruppo uno ) defgroup( uno, [1,1]) { node node.addapplication( nodo24 ) } info( gruppo due ) defgroup( due, [1,2]) { node node.addapplication( nodo25 ) } #------COMANDI DI ESECUZIONE DELL ESPERIMENTO whenallinstalled() { node } wait 5 allgroups.startapplications wait 30 Experiment.done Questo script é formulato in un linguaggio derivato da Ruby ed adattato all occorrenza, é stato redatto con l editor a riga comando nano, presente in tutte le distribuzioni Debian Linux ed ha estensione.rb. La guida ufficiale del linguaggio OEDL 7 si trova all indirizzo: Experiment Controller API. Lo script é composto di tre parti messe in evidenza dai commenti. Nella prima, vengono definite le applicazioni da far eseguire sui nodi in cui é specificato il nome, il comando che dev essere eseguito sul nodo ed altre informazioni di supporto. É essenziale notare che OMF richiama un eseguibile sulla macchina-nodo, non lo definisce ex-novo. Nella seconda, le applicazioni vengono assegnate ai nodi raccolti in due gruppi. Infine, avviene l avvio su tutti i nodi degli applicativi definiti prima. 7 OEDL- OMF Experiment Description Language 48

56 4.2. SCRIPT DI CONFIGURAZIONE Figura 4.6: Lancio dello script di configurazione Lancio dell esperimento Da una quarta macchina, con indirizzo IP viene lanciato lo script con il comando:./totale.sh visibile in Figura 4.6 Il risultato del lancio dello script si puó vedere in Figura 4.7, in cui si evicono tutte le fasi del processo: ˆ Configurazione dell A.M. ed avvio di Openfire. ˆ Configurazione e riavvio dei R.C. sui due nodi. ˆ Popolamento del database dell A.M. con la query update db.sql. ˆ Collegamento dei nodi al server XMPP per la ricezione dei comandi. 49

57 4.2. SCRIPT DI CONFIGURAZIONE Figura 4.7: Lancio dell esperimento Ora, non resta che collegarsi all Aggregate Manager ed eseguire l esperimento con il comando: omf exec exp4.rb Il risultato dell esperimento é un file formato XML reperibile sull Aggregate Manager nella cartella /tmp/ e viene riportato di seguito: <context> <log/> <experiment> <properties> <property name= resetdelay id= value= 210 > <history value= 210 ts= 11:57:45 /> </property> <property name= resettries id= value= 1 > <history value= 1 ts= 11:57:45 /> </property> </properties> <status> DONE </status> <load> exp3.rb </load> <id> sandbox2\_2010\_04\_14\_11\_57\_34 </id> </experiment> <nodes> <node name= n_1_1 x= 1 y= 1 id= n\_1\_1 > <status value= UP > <history value= POWERED\_ON ts= 11:57:45 /> <history value= UP ts= 11:57:45 /> 50

58 4.2. SCRIPT DI CONFIGURAZIONE </status> <image> Unknown </image> <heartbeat/> <properties/> <groups> <group> uno </group> </groups> <apps> <app name= nodo24 > <status value= DONE.OK > <history value= INSTALLED.OK ts= 11:57:45 /> <history value= STARTED ts= 11:58:20 /> <history value= DONE.OK ts= 11:58:22 /> </status> <properties/> <appdef href= nodo24 /> <envlist/> <io> <out> <line ts= 11:58:20 > PING ( ) 56(84) bytes of data. </line> <line ts= 11:58:20 > 64 bytes from : icmp_seq=1 ttl=64 time=3.90 ms </line> <line ts= 11:58:21 > 64 bytes from : icmp_seq=2 ttl=64 time=0.248 ms </line> <line ts= 11:58:22 > 64 bytes from : icmp_seq=3 ttl=64 time=0.255 ms </line> <line ts= 11:58:22 > </line> <line ts= 11:58:22 > ping statistics --- </line> <line ts= 11:58:22 > 3 packets transmitted, 3 received, 0\% packet loss, time 2008ms </line> <line ts= 11:58:22 > rtt min/avg/max/mdev = 0.248/1.469/3.905/1.722 ms </line> </out> </io> </app> 51

59 4.2. SCRIPT DI CONFIGURAZIONE </apps> </node> <node name= n_1_2 x= 1 y= 2 id= n\_1\_2 > <status value= UP > <history value= POWERED_ON ts= 11:57:45 /> <history value= UP ts= 11:57:45 /> </status> <image> Unknown </image> <heartbeat/> <properties/> <groups> <group> due </group> </groups> <apps> <app name= nodo25 > <status value= DONE.OK > <history value= INSTALLED.OK ts= 11:57:45 /> <history value= STARTED ts= 11:58:20 /> <history value= DONE.OK ts= 11:58:22 /> </status> <properties/> <appdef href= nodo25 /> <envlist/> <io> <out> <line ts= 11:58:20 > PING ( ) 56(84) bytes of data. </line> <line ts= 11:58:20 > 64 bytes from : icmp_seq=1 ttl=64 time=0.536 ms </line> <line ts= 11:58:21 > 64 bytes from : icmp_seq=2 ttl=64 time=0.312 ms </line> <line ts= 11:58:22 > 64 bytes from : icmp_seq=3 ttl=64 time=0.571 ms </line> Analisi del file di risultato Il file XML contenente il risultato dell esperimento porta in sé tutte le informazioni raccolte dal testbed virtuale. É possibile notare il nome dell e- 52

60 4.2. SCRIPT DI CONFIGURAZIONE sperimento, il timestamp, l orario di inizio e quello di completamento. E inoltre, possibile vedere l attivitá generata dai nodi, contrassegnati con la loro posizione logica espressa in coordinate cartesiane, il loro stato e tutti i messaggi scambiati. In particolare, per ogni esecuzione del ping, é visibile la risposta della shell. 53

61 Capitolo 5 Conclusioni e Sviluppi futuri L integrazione fra OMF e Neptune permette un notevole passo in avanti per l esecuzione di esperimenti su testbed virtuali. Completandosi a vicenda, le due piattaforme mettono a disposizione dell utilizzatore uno strumento che, grazie alla capacitá di Neptune di poter istanziare topologie di reti anche molto complesse con link personalizzabili e alla capacitá di OMF di poter coordinare facilmente tali topologie, é in grado di coprire una vasta casistica sperimentale. Dato che, Neptune puó creare reti virtuali in grado di integrarsi in maniera trasparente ad OMF con contesti reali, le potenzialitá vanno oltre l ambito virtualizzato ma abbracciano anche la possibilitá di integrare componentistica reale. Il lavoro di tesi qui descritto costituisce un inizio di integrazione, infatti, nonostante la consistente automatizzazione del processo, restano ancora ampi margini di sviluppo, come, ad esempio, un integrazione diretta del processo in Neptune ma anche un miglioramento complessivo della fruibilitá di OMF. Nel capitolo riguardante l integrazione dei due strumenti e nelle appendici sono state mostrate molteplici procedure di installazione corredate di una lunga serie di accorgimenti e variazioni necessarie ad ottenere un sicuro funzionamento delle singole entitá coinvolte. 54

62 Appendice A Installazione Xen Premettiamo che tutte le installazioni illustrate nei capitoli successivi sono state fatte mediante terminale root su una versione Debian Lenny A.1 Installazione e configurazione di xend e configurazione bridge Come prima cosa se nella macchina é presente exim4 effettuare un remove con il seguente comando: apt-get remove exim4 Controllare il kernel Xen disponibile, digitando: apt-cache search xen-linux-system- Verranno allora elencati i kernel disponibili, nel nostro caso abbiamo ottenuto: xen-linux-system xen-686 Abbiamo quindi digitato: apt-get install xen-linux-system xen-686 Con il comando: apt-get install xen-tools 55

63 A.1. INSTALLAZIONE E CONFIGURAZIONE DI XEND E CONFIGURAZIONE BRIDGE abbiamo installato una serie di script che automatizzano gran parte delle operazioni necessarie alla creazione delle macchine virtuali. 56

64 A.2. CREAZIONE MACCHINE VIRTUALI (DOMU) Configurare /etc/xend-config.sxp decommentando le seguenti righe se non lo sono. (network-script network-bridge) (vif-script vif-bridge) il secondo lo script di creazione dell interfaccia collegata al bridge. Riavviare il demone per rendere effettive le modifiche, con il comando: /etc/init.d/xend restart A.2 Creazione macchine virtuali (domu) Prima di creare la macchina virtuale é necessario modificare il file xentools.conf al path: /etc/xen-tools/ Le variazioni sono: ˆ Configurare l utilizzo di lvm per creare la macchina con: lvm = xen-lvm ˆ Selezionare deboostrap come metodo di installazione per le nostre macchine virtuali con: deboostrap = 1 ˆ Scegliere la dimensione dell hard disk della macchina virtuale: size=10gb ˆ Definire la memoria utilizzabile della macchina virtuale: 57

65 A.2. CREAZIONE MACCHINE VIRTUALI (DOMU) memory = 512Mb ˆ Dimensionare la partizione di swap: swap = 512Mb ˆ Definire il tipo di filesystem: fs = ext3 ˆ Scegliere la distribuzione da installare: dist = etch ˆ Configurare la rete: gateway = x.x.x.x netmask = x.x.x.x ˆ Riportare la versione corretta del kernel: kernel = /boot/vmlinuz xen-686 initrd = /boot/initrd.img xen-686 ˆ Per creare macchine con architettura a 64bit specificare: arch=amd64 ˆ Infine specificare il mirror da cui verrá scaricata la distribuzione: mirror = 58

66 A.3. CREAZIONE MACCHINA VIRTUALE A.3 Creazione Macchina Virtuale Per la creazione della macchina virtuale viene utilizzato il file modificato nel paragrafo precedente xen-tools.conf dal comando: xen-create-image --ip x.x.x.x --hostname prova Questo comando creerá anche il file /etc/xen/prova.cfg con tutte le caratteristiche della macchina realizzata(figura A.1). Se si vuole creare una macchina virtuale senza editare il file xen-tools.conf lo si puó fare direttamente con il comando: xen-create-image --ip x.x.x.x --hostname=prova1 --size=4gb --dist=lenny --memory=512m --ide --dhcp --dir=prove che crea una macchina con le caratteristiche editate nella directory prove. Prima di avviare la macchina creata, dobbiamo aggiungere al file di configurazione della macchina, che sará al path: etc/xen/prova1.cfg la seguente riga: extra = console=hvc0 xencons=tty per evitare lo stallo della macchina e l utilizzo di Pygrub. 1 Dopo aver creato una macchina virtuale possiamo gestirla utilizzando i seguenti comandi: ˆ xm list: elenca tutte le macchine presente nel dom0; ˆ xm console domain: accede alla console del dominio; ˆ xm shutdown domain: spegne il dominio scelto; ˆ xm reset domain : resetta il dominio scelto; ˆ xm help : help dei comandi xm possibili. 1 PyGRUB un bootloader ispirato a grub, ma scritto in python che consente a Xen di avviare la macchina virtuale. 59

67 A.3. CREAZIONE MACCHINA VIRTUALE Figura A.1: Output Xen Figura A.2: Xm List 60