UNIVERSIT DEGLI STUDI DI TRIESTE

FACOLT DI SCIENZE MATEMATICHE, FISICHE E NATURALI

CORSO DI LAUREA MAGISTRALE IN INFORMATICA CURRICULUM INGEGNERIA INFORMATICA

PROGETTO E REALIZZAZIONE DI UN SISTEMA PER LA GESTIONE ED IL MONITORAGGIO DI RISORSE VIRTUALI IN AMBIENTE CLOUD

Laureando: Giuseppe CHECHILE

Relatore: Prof. Eric MEDVET Correlatore: Ing. Livio TENZE

ANNO ACCADEMICO 2010-2011

Indice
Introduzione............................................................................................................................................................1 1 - Workflow scientifico.........................................................................................................................................3 2 - Cloud computing...............................................................................................................................................5 2.1 OpenNebula...............................................................................................................................................6 2.2 Amazon EC2..............................................................................................................................................8 2.3 Eucalyptus.................................................................................................................................................8 3 - Virtualizzazione e virtual machine manager....................................................................................................10 3.1 Kvm.........................................................................................................................................................11 3.2 Xen..........................................................................................................................................................11 4 - Analisi e progettazione....................................................................................................................................12 4.1 Requisiti...................................................................................................................................................12 4.2 Infrastruttura Cloud.................................................................................................................................14 4.3 Progettazione del sistema di monitoraggio e di controllo........................................................................16 4.4 EstecoSimpleCloud..................................................................................................................................18 4.5 MonitorEstecoCloud................................................................................................................................22 5 - Realizzazione..................................................................................................................................................28 5.1 Tecnologie utilizzate................................................................................................................................28 5.1.1 Jclouds.............................................................................................................................................29 5.1.2 Java OCA........................................................................................................................................29 5.1.3 Sigar................................................................................................................................................29 5.1.4 JMX.................................................................................................................................................30 5.2 EstecoSimpleCloud..................................................................................................................................30 5.3 MonitorEstecoCloud................................................................................................................................31 5.4 WebEstecoCloud......................................................................................................................................34 5.5 Infrastruttura del sistema di controllo e di monitoraggio.........................................................................39 6 - Interfaccia........................................................................................................................................................41 6.1 WebEstecoCloud......................................................................................................................................41 6.2 MonitorEstecoCloud................................................................................................................................45 7 - Configurazione del sistema.............................................................................................................................46 8 - Risultati e test..................................................................................................................................................49 8.1 Test period...............................................................................................................................................49 8.2 Test size...................................................................................................................................................51

8.3 Test scale.................................................................................................................................................52 8.4 Considerazioni.........................................................................................................................................53 9 - Conclusioni.....................................................................................................................................................54 Bibliografia...........................................................................................................................................................56

II

Indice delle figure

Figura 1: Diagramma dei casi d'uso del sistema...................................................................................................13 Figura 2: Schema del cloud multipiattaforma.......................................................................................................14 Figura 3: Schema dell'infrastruttura del cloud privato..........................................................................................15 Figura 4: Schema dei moduli del sistema di monitoraggio...................................................................................18 Figura 5: Schema delle classi SimpleCloud per il caso Amazon EC2...................................................................21 Figura 6: Schema del funzionamento di MonitorEstecoCloud..............................................................................24 Figura 7: Schema terminazione dei processi in esecuzione...................................................................................25 Figura 8: Schema delle classi di MonitorEstecoCloud..........................................................................................27 Figura 9: Operazione di aggiornamento della LinkedList di MonitorEstecoCloud...............................................32 Figura 10: Schema delle classi di MonitorEstecoCloud........................................................................................34 Figura 11: Schema delle pagine web di WebEstecoCloud....................................................................................34 Figura 12: Schema delle servlet Java di WebEstecoCloud....................................................................................36 Figura 13: Diagramma di flusso della gestione di richieste a GetMonitorInfo......................................................37 Figura 14: Esempi di richieste a GetMonitoInfo...................................................................................................38 Figura 15: Infrastruttura sistema complessivo......................................................................................................40 Figura 16: WebEstecoCloud form di login............................................................................................................41 Figura 17: WebEstecoCloud, vista sulle risorse della piattaforma OpenNebula...................................................42 Figura 18: WebEstecoCloud, dettaglio della pagina con informazioni ottenute da MonitorEstecoCloud.............43 Figura 19: WebEstecoCloud, grafico riassuntivo della pagina MonitorHistory....................................................44 Figura 20: WebEstecoCloud, informazioni di dettaglio della pagina MonitorHistory...........................................44

III

Introduzione
L'argomento trattato in questa tesi riguarda l'analisi di un sistema di cloud multipiattaforma, che offre un servizio di tipo Infrastructure as a Service, il progetto e la realizzazione di un sistema in grado di monitorare e di controllare l'infrastruttura. In un ambiente di questo tipo, vengono gestite delle virtual machine che hanno il compito di soddisfare le necessit degli utenti. Come risultato della tesi, stato prodotto un sistema in grado di eseguire operazioni su differenti piattaforme di cloud computing e di monitorare lo stato delle virtual machine create dagli utenti. Come interfaccia del sistema, stata messa a disposizione degli utenti un'applicazione web. Le motivazioni che stanno alla base di questo lavoro, risiedono nella necessit di ottenere un unico strumento in grado di eseguire operazioni su differenti piattaforme di cloud e di ottenere informazioni in merito alla situazione del sistema operativo in esecuzione sulle virtual machine create. Esistono differenti strumenti per il controllo ed il monitoraggio di un ambiente cloud, ma hanno il problema di offrire informazioni esclusivamente in merito alla piattaforma per i quali sono stati prodotti, oppure non forniscono una visione interna delle macchine virtuali create. Il lavoro svolto per lo svolgimento di questa tesi costituito da: Lo studio ed il test delle funzionalit offerte dalle diverse piattaforme di cloud computing. L'analisi del sistema esistente e definizione dei requisiti richiesti al sistema di controllo e monitoraggio. La progettazione e sviluppo del sistema di monitoraggio. Il test del sistema sviluppato.

Il lavoro di tesi stato svolto presso Esteco, che ha messo a disposizione l'infrastruttura e il software che compongono il sistema cloud, sul quale stato realizzato il sistema monitoraggio e di controllo. Nel primo capitolo, verr illustrato quello che stato il contesto di questo lavoro di tesi, descrivendo brevemente il concetto di workflow scientifico e le sue principali caratteristiche. All'interno del capitolo Cloud Computing, verr dato spazio al lato teorico del cloud computing e le diverse tipologie di cloud che attualmente vengono utilizzati. Il capitolo Virtualizzazione e virtual machine manager descrive le tecnologie che tipicamente stanno alla base di un'infrastruttura cloud che offre un servizio di tipo IaaS. Seguono i capitoli 4 e 5, all'interno dei quali sono state illustrate le problematiche trattate in questo lavoro di tesi

e la soluzione adattata dalla sua progettazione alla sua realizzazione. I capitoli Interfaccia e Configurazione del sistema descrivono il funzionamento del sistema di monitoraggio e di controllo, sia per quello che riguarda l'utilizzo che la configurazione necessaria al funzionamento. Nel capitolo 8, verranno presentati alcuni test effettuati sul particolare modulo del sistema riservato al monitoraggio di un sistema operativo in esecuzione sulle macchine virtuali del cloud.

1 Workflow scientifico
In questo capitolo si vuole descrivere brevemente il concetto di workflow scientifico [1] e di workflow management system, al fine di chiarire il contesto all'interno del quale si svolto il lavoro di tesi. In generale, si pu definire un workflow come lautomazione di un processo di produzione all'interno di un sistema, che pu essere ad esempio un'azienda. Durante questo processo, le informazioni o i processi operativi sono distribuiti tra gli utenti del sistema, considerato con la finalit di compiere una determinata azione in base a quanto specificato da un insieme di regole procedurali ben definite. Per workflow, si intende un flusso di lavoro formato da un' insieme di attivit legate tra loro attraverso diverse tipologie di interrelazioni, al fine di ottimizzare globalmente il lavoro svolto da tutte le attivit del sistema. Quindi, si pu dire che un workflow la definizione formale di un processo, utilizzata per la gestione e l'ottimizzazione di attivit generiche. Un workflow scientifico una specializzazione di workflow; si occupa dell'esecuzione di una successione di passi computazionali, inseriti in un flusso di esecuzione, al fine di ottenere i risultati di un esperimento scientifico. Un esempio di applicazione di un workflow scientifico riguarda la realizzazione di un modello di ala per un velivolo; questo problema deve sottostare ad una serie di vincoli imposti da leggi della fisica, inoltre esistono dei vincoli computazionali imposti da scelte di pianificazione del progetto, come il numero di punti che definiscono la struttura dell'ala e lo spazio di valori assegnabili alle variabili decisionali del problema. L'obbiettivo quello di dare la possibilit a vari operatori, anche distanti tra loro, di collaborare nella conduzione di esperimenti e di ricerche su vasta scala, attraverso l'utilizzo di applicazioni basate su sistemi distribuiti di risorse, come ad esempio insiemi di dati o risorse di calcolo. Ci sono diverse caratteristiche che differenziano un workflow scientifico da quello tradizionale: Una singola applicazione scientifica ha la possibilit di creare, a sua volta, un proprio flusso di lavoro. Gli utenti che eseguono il proprio workflow hanno la possibilit di visualizzarne i risultati in tempo reale, attraverso l'utilizzo di strumenti interattivi. La condivisione ed il riutilizzo del workflow tra gli utenti del sistema. Infatti, ha particolare importanza la riproducibilit scientifica degli esperimenti effettuati anche ad una grande distanza di tempo. Gli utenti hanno la possibilit di monitorare l'origine e la genuinit dei risultati dell'esecuzione e delle singole fasi che compongono il flusso di lavoro. I workflow scientifici, quindi, sono un mezzo attraverso il quale gli utenti possono definire modelli, progettare,

eseguire debug, riconfigurare e rieseguire la loro analisi e rielaborare i criteri di visualizzazione dei risultati. Essi inoltre permettono di tenere traccia dei vari passi seguiti per ottenere il risultato in base al metodo scientifico prescelto. Un workflow scientifico non si occupa soltanto dell'attivit di pianificazione del flusso di lavoro, ma comprende nella sua progettazione un metodo per ottenere una visione di ci che tipi di dati rappresentano e del modo in cui gli strumenti applicativi e le risorse distribuite dovrebbero essere messe a disposizione degli utenti. Tali informazioni permettono ad un utente di interpretare i risultati del loro flusso di lavoro e di quelli di altri utenti per ottenere un riscontro del risultato sperimentale. Un workflow management system permette di definire, di creare e di gestire l'esecuzione di workflow attraverso l'utilizzo di software in esecuzione allinterno di uno o pi motori di workflow. Un workflow manager si occupa di interpretare la definizione formale di un processo interno al flusso di lavoro, con l'obbiettivo di interagire con le componenti del sistema che prendono parte al processo, gestendone lo stato ed il coordinamento delle attivit. Tale definizione viene inserita come input del sistema e pu essere scritta in un linguaggio standard, come ad esempio XML, o in un linguaggio proprietario. Un workflow management system deve essere in grado di monitorare ed eseguire processi che compongono il wokflow; questa esecuzione pu essere automatica ed indipendente dall'utente che in questo modo occupa unicamente il ruolo di pianificatore del flusso di lavoro e di utilizzatore del risultato del calcolo.

2 Cloud computing
In questo capitolo si vuole dare spazio ad una breve descrizione di ci che si intende per cloud computing e delle piattaforme che offrono tale servizio utilizzate durante il lavoro di tesi. Il National Institute of Standards and Technology definisce il cloud computing [2] come un modello in grado di consentire l'accesso on-demand a risorse computazionali in modo semplice e da qualunque luogo. Tali risorse possono essere ottenute o rilasciate con rapidit, senza un particolare costo di gestione o d'interazione con il fornitore del servizio. In questo modello viene offerto un insieme eterogeneo di risorse, le cui caratteristiche, in genere, non sono note all'utilizzatore. Dal punto di vista delle risorse, il cloud computing introduce alcune novit [3] come: Una quantit potenzialmente infinit di risorse, ottenibili in base alle necessit. In questo modo non pi necessario fare una stima a lungo temine dell'impiego delle risorse da parte dell'utente. Gli utilizzatori di un sistema cloud possono affrontare un investimento in base alla disponibilit del momento e non in anticipo. Nel caso in cui una risorsa non venga pi utilizzata, l'utilizzatore del sistema pu decidere di rinunciare a mantenere attiva tale risorsa. La capacit offerta da un sistema cloud di aggiungere o rimuovere risorse in base alla necessit dell'utenza, prende il nome di elasticit. Un sistema di questo tipo, per la sua particolare natura, non viene tipicamente classificato in termini di capacit di risorse, come avviene per altri tipi di architettura, che offrono capacit computazionali. I modi pi convenzionali di classificare un servizio di cloud sono: lo stile del servizio offerto ed il tipo delle risorse, sia virtuali che reali, utilizzate per l'implementazione del sistema. Dal punto di vista dello stile del servizio, si possono distinguere tre tipologie fondamentali di cloud computing: Software as a Service (SaaS): consente l'utilizzo di software applicativo. L'installazione e l'amministrazione di tale software demandata al fornitore del servizio. Platform as a Service (PaaS): offre la possibilit di accesso ad un ambiente software per lo sviluppo o per l'esecuzione di servizi. L'ambiente ha tipicamente a disposizione una capacit computazionale scalabile ed un sistema di storage. Infrastructure as a Service (IaaS): fornisce risorse hardware virtualizzate in remoto. Le risorse vengono

rese disponibili in base alla necessit dellutilizzatore, che avr la possibilit di installare e configurare il proprio software. Dal punto di vista del tipo di risorse o dal tipo di accesso al servizio, il sistema cloud pu essere classificato nelle seguenti categorie: Privato: le risorse sono di propriet dellutilizzatore. In questo caso le risorse vengono distribuite in base alla necessit degli utenti. Non si fa uso di risorse esterne per offrire i servizi richiesti, in questo modo le risorse a disposizione degli utenti sono limitate a quelle in loro possesso. Pubblico: non ci sono risorse di propriet dellutilizzatore, tutte le richieste di servizi vengono soddisfatte dallesterno su richiesta. In questo caso non ci sono costi di manutenzione di risorse proprietarie ma esclusivamente un costo di utilizzo del servizio. Ibrido: caso in cui si utilizzano sia risorse di propriet sia risorse esterne. In questo modo possibile estendere le risorse a disposizione dellutente in base alle necessit, senza per dipendere interamente da risorse esterne. Lo scenario, allinterno del quale stato svolto il lavoro di tesi, composto da un cloud di tipo ibrido che offre un servizio IaaS, dove vengono create e gestite virtual machine preparate opportunamente sulla base delle necessit dellutente che ne fa richiesta. All'interno di questa tesi sono state prese in considerazione tre piattaforme che offrono un servizio di questo tipo: OpenNebula, Eucalyptus ed Amazon EC2.

2.1 OpenNebula
OpenNebula [4] un progetto open source che permette limplementazione di cloud ibride e private di tipo IaaS. OpenNebula consente di creare, posizionare e spostare dinamicamente delle macchine virtuali all'interno di un insieme di risorse hardware. Nella versione 3.0 OpenNebula permette l'utilizzo degli hypervisor di virtualizzazione Xen e Kvm. OpenNebula permette la creazione di virtual machine specificandone le risorse hardware come ad esempio CPU, memoria RAM ed interfacce di rete. Inoltre consente l'utilizzo di risorse predisposte precedentemente dall'utente, come le immagini di dischi virtuali e le virtual network. Le virtual machine, le virtual network e i dischi sono risorse che vengono definite da template specifici, dai quali vengono create le istanze che verranno inserite in un repository, come nel caso delle virtual network e dei dischi, oppure verrano effettivamente utilizzate, come le virtual machine. A differenza degli altri template, quello utilizzato per definire una virtual machine pu essere inserito in un repository e messo a disposizione di altri utenti per un utilizzo futuro. Questa caratteristica stata introdotta con la nuova versione 3.0. Un'immagine all'interno di OpenNebula rappresenta una risorsa, contenente dati o un sistema operativo, che pu

essere utilizzata come un disco da parte di una virtual machine. I dati all'interno di un'immagine possono essere salvati sovrascrivendo l'immagine originale o creandone una nuova. In OpenNebula una virtual machine viene definita in termini di: Risorse come la memoria e la CPU. Un insieme di Network Interface Controller (NIC), una per ogni virtual network. Un insieme di immagini di dischi. Uno state-file o un recovery-file, in modo da contenere l'immagine della memoria di una virtual machine in esecuzione e le informazioni dell'hypervisor. Una virtual machine pu essere caratterizzata, oltre che dalle risorse hardware e dal sistema operativo, da una serie di configurazioni specifiche; queste configurazioni possono essere effettuate attraverso una contestualizzazione della macchina virtuale. Ci sono due tipi di utilizzo della contestualizzazione in OpenNebula: Per l'assegnazione automatica di indirizzi ip; questo metodo prevede l'inserimento di uno script, che ottiene l'indirizzo ip dall'indirizzo mac e configura l'interfaccia di rete nel file system della virtual machine. Per il passaggio di file e configurazioni di carattere generale, questo metodo prevede l'utilizzo di una immagine ISO contenete i file necessari alla configurazione della virtual machine in fase di boot. Nel template che descrive la virtual machine possibile indicare il contenuto dell'immagine ISO, dire quale sar il device per accedere all'immagine e specificare parametri di configurazione che potranno essere utilizzati in seguito. L'infrastruttura sulla quale viene eseguito la piattaforma OpenNebula composta da computer fisici che prendono il nome di nodi. I nodi possono essere raggruppati in insiemi logici, definiti dall'amministratore del sistema, che prendono il nome di cluster. La piattaforma OpenNebula composta dalle seguenti componenti, che possono essere configurate o sostituite in base alle necessit: Il demone oned, che ha il compito di gestire i nodi del cluster, le virtual network, le virtual machine, gli utenti e l'image repository. I driver, si occupano di aspetti come il monitoraggio del sistema e la comunicazione con gli hypervisor per la virtualizzazione. Lo scheduler, che ha il compito di assegnare le istanze delle virtual machine ai nodi di un cluster. OpenNebula utilizza un match making scheduler, che implementa una politica di rank scheduling. L'obbiettivo quello di assegnare in modo conveniente le macchine in base alle risorse presenti nel

sistema; possibile specificare quali risorse tenere in considerazione e quale politica adottare per ogni template. Per quanto riguarda l'affidabilit, OpenNebula possiede un sistema di fault tolerance implementato attraverso l'hook manager, che permette di poter eseguire degli script in base al cambiamento dello stato di una determinata risorsa, come ad esempio un host o una VM. Questo strumento permette di automatizzare alcuni aspetti del sistema, come la gestione delle immagini temporanee.

2.2 Amazon EC2

Amazon EC2 [5] un provider di un servizio di cloud pubblico di tipo IaaS. Con Amazon Elastic Compute Cloud (Amazon EC2) possibile scegliere tra un vasto numero di immagini predefinite, che prendono il nome di Amazon Machine Image (AMI), per mezzo delle quali possibile creare le machine virtuali. Le AMI messe a disposizione dell'utente si differenziano per sistema operativo e pacchetti software, inoltre possibile scegliere tra diverse configurazioni, relative a memoria RAM, CPU, memoria di storage messa a disposizione dell'istanza che verr eseguita. Oltre a questo, Amazon permette di creare AMI personalizzate con il proprio software e le proprie configurazioni. Per ogni istanza EC2 possibile configurare una politica di sicurezza per l'accesso alla virtual machine ed un'interfaccia di rete per la connessione, per la quale possibile richiedere un indirizzo ip statico. Essendo un servizio che offre un tipo di cloud pubblica, le risorse utilizzate per l'infrastruttura cloud sono esterne. Grazie a questo, Amazon permette di creare macchine virtuali in un localit geografica selezionata tra le diverse Availability Zone messe a disposizione, indipendentemente dalla localit di appartenenza dell'utente. Alle virtual machine create da AMI predefinite possibile aggiungere un disco di storage persistente, in modo da mantenere, anche dopo la terminazione delle virtual machine, i risultati ottenuti dalla computazione. Questo servizio prende il nome di Amazon Elastic Block Store (EBS). Per quanto riguarda il costo del servizio, vengono addebitate le istanze EC2 in base alle prestazioni delle AMI selezionate con una tariffa basata sul tempo di utilizzo delle virtual machine; oltre a questo si aggiunge il costo di trasferimento dati, che viene calcolato in base alla quantit di dati trasmessi.

2.3 Eucalyptus
Eucalyptus [6] una piattaforma di cloud computing di tipo privato che offre un servizio IaaS. Per quanto riguarda il lavoro relativo a questa tesi, si fa riferimento esclusivamente al progetto Eucalyptus open source nella sua versione 2.0. Principale caratteristica di Eucaluptus la compatibilit con Amazon EC2 ed S3. Grazie a questa compatibilit,

pur essendo Eucalyptus una piattaforma esclusivamente privata, potrebbe essere utilizzato all'interno di un sistema di cloud ibrido. Infatti, la compatibilit EC2 potrebbe semplificare, dal punto di vista della gestione delle risorse, l'unificazione in un'unica entit logica del cloud pubblico di Amazon e di quello privato di Eucalyptus. In linea con quanto accade nel caso di Amazon EC2, possibile creare una virtual machine da un'Eucalyptus Machine Image (EMI) precedentemente creata dallutente. Nella versione utilizzata, Eucalyptus offre una compatibilit con gli hypervisor di virtualizzazione Xen e Kvm. Come Amazon, Eucalyptus mette a disposizione un servizio di Elastic Block Store (EBS), per rendere persistenti dati ai quali hanno accesso le virtual machine in esecuzione. Essendo una piattaforma che offre un servizio di cloud privato, possibile definire impostazioni relative alla locazione e alla condivisione di tali dischi di storage. A differenza di quanto accade con gli altri provider del servizio di cloud computing considerati, Eucalyptus non consente di rendere persistente il disco contenente il sistema operativo ma soltanto dischi di dati. Per quanto riguarda la connettivit alla rete delle virtual machine create, possibile utilizzare un server DHCP per l'assegnazione degli indirizzi ip. Inoltre, si possono configurare dei gruppi di sicurezza per limitare la connettivit delle virtual machine create. In tale modo si in grado di isolare i differenti gruppi all'interno della rete. Anche Eucalyptus offre la possibilit di scegliere fra diverse Availability Zone per il deploy delle diverse virtual machine, ma a differenza di Amazon queste zone non sono altro che i diversi cluster che compongono l'infrastruttura fisica sulla quale implementato il sistema cloud privato. Il sistema Eucalyptus stato preso in considerazione anche per la sua diffusione, che nell'ultimo periodo sembra per ridursi e per la stretta integrazione di questo tipo di infrastruttura cloud con la distribuzione Ubuntu.

3 Virtualizzazione e virtual machine manager

In questo capitolo si vogliono descrivere le tecnologie di virtualizzazione utilizzate nel lavoro di tesi e l'importanza della virtualizzazione nel cloud computing. Una virtual machine [7] un'implementazione software di una macchina in grado di eseguire programmi in modo simile ad una macchina reale. Quindi, ogni virtual machine possiede il proprio sistema operativo ed il proprio software applicativo, ma anche una serie di periferiche che simulano le funzionalit di quelle fisiche. La virtualizzazione hardware della CPU pu essere divisa nelle seguenti categorie, basate su diverse tecniche di simulazione: Full virtualization: in questo caso le istruzioni del kernel, che non possono essere virtualizzate, vengono tradotte in modo da poter essere eseguite dallo strato hardware simulato. Per quanto riguarda il software eseguito a livello utente, viene eseguito direttamente dal processore fisico sul quale viene eseguita la virtual machine; in questo modo possibile ottenere prestazioni rispetto alle altre tecniche di virtualizzazione. Paravirtualization: questo tipo di virtualizzazione richiede la modifica del kernel del sistema operativo, in modo da modificare tutte le istruzioni che non possono essere virtualizzate, sostituendole con chiamate ad un livello di virtualizzazzione dell'hypervisor. L'hypervisor fornisce un' interfaccia per la gestione di chiamate critiche di sistema, come ad esempio l'accesso alla memoria. Un hypervisor consente un'astrazione uniforme del livello fisico di una virtual machine, ha il compito di controllare l'hardware e di gestire le richieste dei sistemi operativi in esecuzione. Questa astrazione del livello fisico sottostante permette di poter eseguire la stessa virtual machine su diverse macchine fisiche su cui presente l'hypervisor. Secondo P. Goldberg esistono due tipi di hypervisor [8]: Tipo 1: l'hypervisor viene eseguito direttamente sull'hardware fisico della macchina sul quale installato. I sistemi operativi vengono eseguiti ad un livello superiore a quello in cui viene eseguito l'hypervisor. Tipo 2: questa tipologia di hypervisor si differenzia dal tipo 1 poich viene eseguita nell'ambiente di un sistema operativo. In questo caso si aggiunge un livello di esecuzione al sistema. Gli hypervisor di tipo 1 vengono eseguiti direttamente sull'hardware e fanno riferimento ad una full virtualization, mentre quelli di tipo 2 consentono una paravirtualization.

10

Per quanto riguarda la categoria di hypervisor di tipo 1, richiesta una tipologia di hardware specifico, che sia in grado di poter eseguire le istruzioni dell'hypervisor. L'architettura di processori x86 prevede estensioni per la virtualizzazione, come le tecnologie Intel Virtualization Technology (VT) [9] e AMD Virtualization (AMD-V) [10]. La virtualizzazione ci che sta alla base della capacit di poter creare o distruggere, in base al desiderio di un utente del sistema, risorse in un Cloud che offre uno stile di servizio IaaS. Nel caso di studio preso in considerazione, sono stati utilizzati gli hypervisor di virtualizzazione Kvm e Xen.

3.1 Kvm
Kernel-based Virtual Machine (KVM) [11] un progetto open source che offre un servizio di hypervisor di tipo 1 e permette una full virtualization di processori con architettura x86 provvisti delle estensioni per la virtualizzazione. Questo hypervisor composto da moduli del kernel specifici che permettono la virtualizzazione di tutta l'infrastruttura hardware e non solo del processore. Per il funzionamento di KVM necessario l'utilizzo di QEMU [12], un progetto open souce che offre uno strumento in grado di permettere l'emulazione e la virtualizzazione di componenti hardware. Grazie a QEMU possibile ottenere prestazioni di simulazione superiori rispetto ad altri strumenti grazie al fatto che si basa sul binary translation.

3.2 Xen
Xen [13] un hypervisor di tipo 1, in grado di offrire sia una full virtualization, per quanto riguarda l'Hardware Virtual Machine (Xen HVM), sia una paravirtualization (Xen PV). In un sistema Xen, l'hypervisor il livello pi basso, al di sopra del quale possono essere eseguite diverse virtual machine con diversi sistemi operativi. Il primo tra questi sistemi prende il nome di dom0, ha speciali privilegi di controllo e completo accesso all'hardware fisico. L'amministratore pu quindi gestire l'hypervisor attraverso il dom0, dal quale possibile eseguire e controllare altri domini a livello utente che prendo il nome di domU. Il dom0 deve essere un sistema operativo modificato in modo da consentire l'esecuzione dell'hypervisor. Per quanto riguarda i domU, possono essere sistemi operativi privi di modifiche oppure modificati, a seconda che si voglia utilizzare Xen rispettivamente per una virtualizzazione HVM o PV.

11

4 Analisi e progettazione
In questo capitolo si vogliono descrivere i requisiti del sistema di monitoraggio e controllo, l'organizzazione del sistema di cloud ed infine descrivere la progettazione dei moduli che andranno a comporre il sistema di monitoraggio e controllo.

4.1 Requisiti
Obbiettivo di questa tesi la progettazione e lo sviluppo di un sistema che permetta di creare, monitorare e di controllare delle virtual machine che vengono eseguite su di un sistema di cloud di tipo ibrido, che offre uno stile di servizio IaaS. Come anticipato nel capitolo Cloud computing, il sistema cloud preso in considerazione multipiattaforma, cio composto da diversi provider che offrono un servizio di cloud computing di stile IaaS; questo implica che i tipi di servizi e le modalit con cui questi servizi vengono offerti saranno diversi per ogni piattaforma presa in considerazione. Da un punto di vista generico, viene richiesto uno strumento che offra la possibilit ad un insieme di utenti di creare e controllare le proprie virtual machine, che vengono precedentemente preparate e configurate dall'amministratore del sistema cloud. Da questa prima considerazione di carattere generale emerge il fatto che diversi utenti avranno accesso ad un insieme di risorse virtuali a loro dedicate. Per questo motivo, necessario introdurre un sistema di autenticazione ed autorizzazione per lo strumento che si andr a sviluppare. Per quanto riguarda l'utilizzo del sistema di monitoraggio e di controllo, l'utente risulta essere l'unico attore umano del sistema, gli altri attori che possono essere considerati sono: la piattaforma di cloud computing e la macchina virtuale creata in ambiente cloud. Di seguito viene riportato il diagramma dei casi d'uso relativo al sistema da realizzare.

12

Sistema di monitoraggio e controllo

Visualizzazione VM disponibili Visualizzazione VM in esecuzione Creazione VM tra quelle disponibili Terminazione VM tra quelle in esecuzione Sospensione VM tra quelle in esecuzione Virtual machine Riattivazione VM tra quelle sospese Terminazione processo in esecuzione Visualizzazione risorse del sistema operativo

Piattaforma cloud computing

User

Figura 1: Diagramma dei casi d'uso del sistema

Per quanto riguarda il monitoraggio delle virtual machine, sono richieste le seguenti informazioni per ogni piattaforma di cloud: Lista delle virtual machine che possono essere create. Lista delle virtual machine che sono attualmente in esecuzione. Stato delle virtual machine che sono state create. Questa un'informazione che descrive la virtual machine esternamente dal punto di vista dell'hypervisor. Occupazione delle risorse delle virtual machine attualmente in esecuzione. Questa informazione descrive un aspetto interno alla virtual machine come l'occupazione della CPU e della memoria RAM. Lista dei processi in esecuzione sulle virtual machine attualmente in esecuzione. Occupazione risorse da parte di un processo in esecuzione su di una virtual machine.

Per quanto riguarda il controllo delle virtual machine, sono richieste le seguenti operazioni: Creazione di una virtual machine tra quelle disponibili. Spegnimento di una virtual machine attualmente in esecuzione. Sospensione di una virtual machine in esecuzione.

13

Riattivazione di una virtual machine in stato di sospensione. Terminazione di un processo in esecuzione sul sistema operativo di un virtual machine.

Un altro requisito dell'infrastruttura da sviluppare relativo al sistema operativo in esecuzione sulle virtual machine create in ambiente cloud. I sistemi operativi per cui richiesta la compatibilit sono: Linux. Microsoft Windows.

Si vuole sottolineare che i requisiti appena descritti, sia dal punto di vista del controllo sia dal punto di vista del monitoraggio, fanno riferimento ad aspetti interni, riguardanti elementi prevalentemente associati al sistema operativo in esecuzione sulle virtual machine create, ed esterni, che consistono in elementi caratteristici dell'hypervisor di virtualizzazione. La virtualizzazione di sistemi MAC-OS, sebbene sia tecnicamente possibile, risulta impossibile dal punti di vista legale: la licenza richiede che l'OS possa essere virtualizzato, ma deve essere eseguito du hardware prodotto dalla Apple [14].

4.2 Infrastruttura Cloud

Il sistema di cloud utilizzato nello svolgimento di questo lavoro di tesi composto da tre diverse piattaforme che offrono un servizio di cloud computing: OpenNebula, Eucalyptus ed Amazon. Tutte queste piattaforme sono accomunate dal fatto che offrono un servizio di stile IaaS, ma le piattaforme OpenNebula ed Eucalyptus utilizzano risorse hardware private, mentre vengono utilizzate le risorse pubbliche attraverso il servizio offerto dalla piattaforma Amazon. Per quanto detto, l'organizzazione complessiva del sistema cloud utilizzato risulta essere quella rappresentata nella seguente figura, dove le piattaforme di cloud privato sono rappresentate all'interno dell'azienda a sottolineare il fatto che fanno parte di risorse locali.
Esteco

EUCALYPTUS AMAZON

OPEN NEBULA

Figura 2: Schema del cloud multipiattaforma

14

Ogni piattaforma di cloud privato comprende un insieme di computer, ognuno dei quali rappresenta un nodo, sul quale vengono eseguite le virtual machine; queste risorse hardware fanno parte di un insieme logico che prende il nome di cluster. Tutti i nodi di un cluster devono avere connettivit con un singolo nodo dedicato al controllo, sul quale installata la vera e propria piattaforma di cloud; questo nodo viene comunemente chiamato frontend, in quanto rappresenta l'interfaccia del cloud privato con il quale si vuole interagire. Su ogni nodo che va a costituire il cloud privato multipiattafoma presente un sistema operativo Debian, in particolare stata utilizzata per l'installazione la release 6.0 (squeeze). Per quanto riguarda la presenza degli hypervisor di virtualizzazione nel sistema, la piattaforma OpenNebula utilizza un cluster con tre nodi su cui installato Xen ed uno in cui presente un unico nodo in cui installato KVM. La piattaforma Eucalyptus comprende invece un unico cluster (zone) composto da quattro nodi sui quali installato l'hypervisor Xen. La topologia delle due piattaforme di cloud computing privato rappresentata nella seguente figura.

EUCALYPTUS Switch eth0 euca-frontend 10.0.1.8 192.168.34.5 192.168.34.1 192.168.34.2 10.0.1.6 192.168.34.3 10.0.1.7 192.168.34.4

euca-xen01

euca-xen02

euca-xen03

euca-xen04 192.168.35.26

10.0.1.5

eth1

eth1

eth1 Switch

eth1

eth1

OPEN NEBULA Switch eth0 nebula-frontend 192.168.35.1 192.168.35.2 eth0 192.168.35.3 nebula-xen01 eth0 192.168.35.4 nebula-xen02 eth0 nebula-xen03 eth0 nebula-kvm01

Figura 3: Schema dell'infrastruttura del cloud privato

A differenza di quanto accade per la parte privata del cloud, in quella pubblica (che, nel caso preso in considerazione, consiste nel servizio offerto da Amazon) non possibile specificare i dettagli

15

10.0.1.9

sull'implementazione fisica dell'architettura; ci dovuto al fatto che l'amministratore della parte privata del sistema complessivo di cloud risulta essere un utente per la parte pubblica e, come detto in precedenza, l'utente finale di un sistema cloud ignora il modo in cui il sistema che offre il servizio sia strutturato internamente. Il servizio di cloud computing pubblico offerto da Amazon utilizza la virtualizzazione per la creazione delle risorse virtuali servendosi dell'hypervisor Xen.

4.3 Progettazione del sistema di monitoraggio e di controllo

Per il sistema di monitoraggio e di controllo stata scelta, come interfaccia, un'applicazione web; attraverso la quale, un utente autenticato avr la possibilit di ottenere le informazioni e di eseguire le operazioni specificate precedentemente nella definizione dei requisiti. Questa scelta stata fatta per rendere pi semplice all'utente l'utilizzo del sistema, in questo modo all'utente richiesto unicamente di disporre di un browser web e delle credenziali per l'accesso al sistema. In fase di progettazione del sistema, il primo problema sorge dal fatto che le piattaforme che offrono il servizio di cloud computing sono diverse l'una dall'altra, ci significa che gli strumenti per ottenere le informazioni ed il modo in cui queste informazioni ed i servizi vengono offerti sono differenti. Per questo motivo si deciso di sviluppare uno strumento che renda omogeneo il modo in cui vengono gestite le piattaforme, basato sul presupposto che ogni piattaforma offra lo stesso tipo di servizio. Lo strumento che si deciso di utilizzare per questo scopo una libreria che prende il nome di EstecoSimpleCloud; essa avr il compito di fornire un'interfaccia software omogenea che gestisca i metodi nativi offerti delle diverse piattaforme utilizzate, permettendo cos di agire su di un'unica entit logica che far riferimento ad una generica piattaforma. In questo modo possibile uniformare le informazioni e le funzionalit offerte da tutte le piattaforme utilizzate nel sistema di cloud. Un altro problema, a cui si gi fatto riferimento nei capitoli precedenti, relativo al fatto che le informazioni richieste per il monitoraggio delle macchine virtuali appartengono a livelli applicativi interni ed esterni alla virtual machine stessa. Infatti, per ottenere le informazioni riguardanti le risorse ed i processi in esecuzione su ogni singola virtual machine (applicazioni interne) del sistema cloud non sufficiente affidarsi alle piattaforme di cloud computing, che fanno riferimento alle informazioni fornite dall'hypervisor di virtualizzazione (livelli applicativi esterni). Per far fronte a ci, stato reso necessario introdurre un'applicazione che sia in grado di ottenere le informazioni richieste dal sistema operativo installato sulla virtual machine stessa e che permetta di interagire con i processi in esecuzione. L'introduzione di un sistema di questo tipo, che deve essere eseguito sul sistema operativo delle singole macchine virtuali, introduce l'ulteriore problema di dover ricevere ed inviare dati all'applicazione web utilizzata dall'utente. L'applicazione utilizzata a questo scopo prende il nome di MonitorEstecoCloud.

16

Tenendo conto delle considerazioni fatte fino a questo momento, si ottenuto che, dal punto di vista logico, il sistema complessivo che comprende il sistema di controllo e di monitoraggio e le entit del cloud ibrido risulta essere formato dai seguenti elementi: La piattaforma che offre il servizio di cloud computing. Questo elemento del sistema comprende la struttura di ci che permette di realizzare il cloud vero e proprio; ogni entit logica denominata piattaforma rende possibile la creazione di virtual machine in base ad un insieme di immagini preparate precedentemente dagli utenti del sistema o dal fornitore del servizio (come tipicamente avviene nel caso di cloud pubblico). Inoltre, ogni piattaforma rende disponibili le informazioni fornite dall'hypervisor di virtualizzazione sulle risorse hardware dei nodi del cluster e sullo stato delle virtual machine in esecuzione. La macchina virtuale. Questa entit la risorsa computazionale che viene messa a disposizione degli utenti; viene eseguita all'interno di una piattaforma, pi precisamente utilizzando uno degli hypervisor di virtualizzazione a disposizione. L'applicazione per il monitoraggio del sistema operativo. Questa applicazione in grado di ottenere informazioni relative alle risorse del sistema operativo presente su di una virtual machine e di controllarne i processi in esecuzione. Ogni sistema operativo di una virtual machine creata verr monitorato e controllato da questa applicazione, che a sua volta fornir le informazioni ed eseguir le operazioni sui processi richieste dall'applicazione web. Importante sottolineare il fatto che tale applicazione deve essere multipiattaforma, in quanto non esiste un unico tipo di sistema operativo che verr eseguito sulle virtual machine. L'applicazione web utilizzata dagli utenti del sistema. Questa componente svolge il compito d'interfaccia del sistema, raccoglie inoltre direttive e informazioni sia dalle piattaforme di cloud computing sia dai programmi di monitoraggio presenti sulle virtual machine create. Il sistema di monitoraggio e controllo composto da due delle entit appena descritte: l'applicazione web e l'applicazione per il monitoraggio del sistema operativo. Le altre due, gi individuate in fase di analisi, sono le entit con le quali il sistema dovr interagire per svolgere le funzionalit richieste. Di seguito viene rappresentata la struttura complessiva del sistema di monitoraggio e di controllo, composta dagli elementi appena descritti, inserita nello scenario del cloud ibrido. Nella figura possibile osservare il modo in cui un'unica applicazione web interagisce con il resto del sistema, ma il sistema prevede l'utilizzo di molteplici utenti, ognuno dei quali ha a disposizione un un terminale per l'accesso all'applicazione web.

17

Piattaforme Cloud
Piattaforma privata Hypervisor Virtual machine OS App. Monitor Virtual machine Virtual machine Virtual machine Hypervisor Hypervisor Virtual machine Virtual machine Piattaforma pubblica

Applicazione web

Figura 4: Schema dei moduli del sistema di monitoraggio

Le linee di collegamento presenti nella figura rappresentano uno scambio di informazioni tra i moduli che compongono il sistema complessivo. L'applicazione web comunica sia con le piattaforme di cloud che con ogni applicazione per il monitoraggio in esecuzione su ogni virtual machine; questa comunicazione necessaria sia per inviare i comandi di controllo sia per ottenere le informazioni in merito al sistema complessivo.

4.4 EstecoSimpleCloud
EstecoSimpleCloud una libreria che offre la possibilit ad un client di accedere alle diverse piattaforme di cloud attraverso un unico strumento omogeneo, basato su di un'astrazione logica dei servizi e delle risorse che tutte le piattaforme di cloud computing offrono per un servizio IaaS. Per quanto riguarda l'astrazione logica che descrive l'intera struttura cloud multipiattaforma, sono state definite le seguenti entit: Image: rappresentano le immagini di virtual machine che possono essere eseguite. Queste immagini contengono le informazioni necessarie alla creazione delle virtual machine, come ad esempio le caratteristiche delle risorse hardware della virtual machine stessa o i dischi virtuali che devono essere montati alla sua creazione. Instance: sono le virtual machine create da un'immagine ed attualmente in esecuzione su una delle piattaforme che costituiscono il sistema di cloud complessivo. A differenza di quanto accade per le image, che rappresentano delle risorse messe a disposizione dell'utente, le instance rappresentano entit

18

esistenti esclusivamente a runtime, come risultato di un'operazione di creazione da parte dell'utente del sistema. Un'istance definita da uno stato logico che definisce lo stato di esecuzione della virtual machine dal punto di vista della piattaforma sulla quale stata creata; ci sono diversi stati transizionali, attraverso i quali una virtual machine passa, ma gli stati stabili in cui un'instance pu trovarsi sono: Running: la virtual machine attualmente in esecuzione sulla piattaforma sulla quale stata creata a partire da un'immagine. Si vuole sottolineare che questo stato non ha nessun legame con tutto quello che in esecuzione sulla virtual machine, ad esempio, un'instance in stato running potrebbe non aver eseguito il boot del sistema operativo. Suspended: una virtual machine in esecuzione stata temporaneamente sospesa. Quando una virtual machine in questo stato non possibile per un utente accedervi, inoltre non possibile eseguire lo spegnimento della macchina ma soltanto l'operazione di riattivazione. Cloud: rappresenta la piattaforma di cloud computing. L'entit cloud comprende tutte le operazioni che sono state definite in fase di analisi che coinvolgono le diverse piattaforme; questa entit caratterizzata da un tipo, che viene utilizzato per rappresentare la specifica piattaforma sulla quale necessario eseguire le operazioni richieste dall'utente. Di seguito vengono riportate le classi utilizzate per descrivere queste tre entit all'interno della libreria EstecoSimpleCloud. SimpleCloudImage - id : String - description : String + SimpleCloudImage(id : String, description : String) + getId() : String + getDescription() : String + toString() : String

SimpleCloudInstance - id : String - image : SimpleCloudImage - status : String - ipAddresses : List<String> + SimpleCloudInstance(id : String, image : SimpleCloudImage, status : String, ipAddresses : List<String>) + getId() : String + getStatus() : String + getImage() : SimpleCloudImage + getIpAddresses() : List<String> + toString() : String

19

SimpleCloud - storage : SimpleStorageAccess - compute : SimpleComputeAccess - cloudtype : CloudType # auth : SimpleCloudAuth - jcloudsContext : ComputeServiceContext - oneContext : Client + SimpleCloud(type : CloudType, auth : SimpleCloudAuth) + createConnection() + releaseConnection() + getImages() : ArrayList<SimpleCloudImage> + getImageById(id : String) : SimpleCloudImage + getInstances() : ArrayList<SimpleCloudInstance> + getInstanceById(id : String) : SimpleCloudInstance + startInstance(image : SimpleCloudImage) : SimpleCloudInstance + terminateInstance(instance : SimpleCloudInstance) + suspendInstance(instance : SimpleCloudInstance) + resumeInstance(instance : SimpleCloudInstance) + printMetaData()

In merito alle operazioni che un utente pu effettuare nel sistema, queste sono state divise logicamente in due gruppi: Operazioni che agiscono sulle componenti dinamiche del sistema, ovvero tutte quelle risorse che esistono per un periodo limitato di tempo, come ad esempio le virtual machine in esecuzione. Operazioni che agiscono su componenti statiche che compongono il sistema di cloud. Per componente statica del sistema si intende una risorsa che parte integrante del sistema e viene messa a disposizione dell'utente; in questa categoria si trovano ad esempio le immagini utilizzate per creare le virtual machine. Per la rappresentazione di questa astrazione logica all'interno della libreria EstecoSimpleCloud, si scelto di utilizzare un'interfaccia per ognuno dei due gruppi di operazioni appena definite. Le due interfacce per la gestione delle risorse dinamiche e statiche sono rispettivamente SimpleComputeAccess e SimpleStorageAccess, che vengono rappresentare nelle tabelle seguenti. SimpleComputeAccess + getInstances() : ArrayList<SimpleCloudInstance> + getInstanceById(id : String) : SimpleCloudInstance + startInstance(image : SimpleCloudImage) : SimpleCloudInstance + terminateInstance(instance : SimpleCloudInstance) + suspendInstance(instance : SimpleCloudInstance) + resumeInstance(instance : SimpleCloudInstance) + printMetaData()

20

SimpleStorageAccess + getImages() : ArrayList<SimpleCloudImage> + getImageById(id : String) : SimpleCloudImage

Per poter interagire con le piattaforme che offrono il servizio di cloud computing, necessario creare una connessione autenticata: questa non una scelta di progettazione ma un vincolo imposto dalle piattaforme di cloud computing utilizzate nel sistema. Per la gestione della connessione del client con la singola piattaforma di cloud all'interno del sistema stata realizzata, per ognuna delle piattaforme, una classe astratta che definisce un attributo rappresentante il contesto della connessione ed un unico metodo per la creazione di tale connessione. Di seguito viene riportata la rappresentazione di una di queste classi astratte, in particolare quella che fa riferimento alla connessione con la piattaforma di Amazon. SimpleAbstractAmazonComponent # jcloudsContext : ComputeServiceContext + createConnection(obj : Object)

Per ogni piattaforma di cloud utilizzata nel sistema, viene utilizzata una classe che implementa le interfacce utilizzate per definire le operazioni dinamiche e per quelle statiche definite precedentemente. Inoltre questa classe estende la classe astratta che definisce la connessione del client con la piattaforma. Viene riportato in figura lo schema delle classi utilizzato prendendo come esempio la piattaforma Amazon per il cloud computing. Lo schema delle classi relativo alle altre piattaforme utilizzate all'interno del sistema del tutto analogo al caso preso in considerazione come esempio.

SimpleCloudAuth

SimpleComputeAccess

SimpleAbstractAmazonComponent

SimpleStorageAccess

SimpleAmazonCompute

SimpleAmazonStorage

SimpleCloud SimpleCloudInstance SimpleCloudImage

Figura 5: Schema delle classi SimpleCloud per il caso Amazon EC2

21

4.5 MonitorEstecoCloud
MonitorEstecoCloud un'agente con il compito di monitorare e controllare alcuni aspetti di quello che viene eseguito su una virtual machine creata all'interno del sistema cloud. Inoltre, MonitorEstecoCloud deve essere in grado di comunicare le informazioni ottenute e di ricevere i comandi di controllo dall'utente per mezzo dell'applicazione web WebEstecoCloud. Quest'applicazione per il monitoraggio ottiene le informazioni richieste dal sistema operativo sul quale viene eseguita ad un intervallo di tempo prefissato; questo periodo di tempo uno dei parametri definiti all'interno dell'applicazione. Ogni rilevamento effettuato viene rappresentato da un'entit logica, che contiene i dati ottenuti da un monitoraggio del sistema operativo e le informazioni relative al monitoraggio stesso. In particolare i dati che fanno parte di questa entit riguardano: Il nome, la versione e l'architettura del sistema operativo sul quale l'applicazione MonitorEstecoCloud in esecuzione. L'istante di tempo in cui stato realizzato il rilevamento. Questo l'unico dato che riguarda esclusivamente l'operazione di rilevamento vera e propria. Informazioni relative alla percentuale di utilizzo della CPU da parte di operazioni eseguite da processi utente e di sistema. Inoltre vengono riportati i tempi di attesa e di inattivit del processore. Dimensioni assolute e percentuali di occupazione della memoria RAM. La classe che rappresenta il singolo rilevamento la classe MachineSample. All'interno di questa classe sono contenuti gli attributi che descrivono gli elementi monitorati dall'applicazione come la CPU e la memoria; questi attributi sono rappresentati rispettivamente dalle classi CPUSample e MemorySample. Di seguito viene riportato lo schema descrittivo di queste classi. MachineSample - operatingSystem : String - time : Date - cpu : CPUSample - memory : MemorySample - processes : List<ProcessSample> + MachineSample(cpu : CPUSample, memory : MemorySample, processes : List<ProcessSample>) + getCpu() : CPUSample + getMemory() : MemorySample + getOperatingSystem() : String + getProcesses() : List<ProcessSample> + getTime() : Date + toString() : String

22

CPUSample - system : double - user : double - nice : double - wait : double - hardwareIRQ : double - softwareIRQ : double - steal : double - idle : double + CPUSample(user : double, system : double, nice : double, wait : double, hardwareIRQ : double, softwareIRQ : double, steal : double, idle : double) + getIdle() : double + getSystem() : double + getUser() : double + getWait() : double + getHardwareIRQ () : double + getSoftwareIRQ () : double + getSteal () : double + toString() : String

MemorySample - free : long - used : long - freePercent : double - usedPercent : double + MemorySample(free : long, freePercent : double, used : long, usedPercent : double) + getFree() : long + getUsed() : long + getFreePercent() : double + getUsedPercent() : double + toString() : String

Si scelto di creare un ulteriore elemento che raccolga in s le informazioni ottenute dai diversi rilevamenti di MonitorEstecoCloud. Per fare questo, ogni entit, rappresentante un singolo rilevamento, viene inserita all'interno di una coda a dimensione fissa di tipo First In First Out (FIFO); la dimensione di questa coda un attributo che caratterizza questa entit ed definita da un parametro interno all'applicazione. I dati contenuti in questa entit rappresentano lo storico degli aspetti del sistema operativo che sono di interesse per il monitoraggio. Per la precisione, il primo elemento della coda viene aggiornato ad ogni campionamento dell'agente di monitoraggio, mentre gli altri elementi vengono inseriti ad un periodo prefissato. Il modo in cui l'applicazione web WebEstecoCloud pu accedere a questa entit di storico di due tipi; il primo relativo alle informazioni riguardanti l'ultimo rilevamento in ordine di tempo, mentre il secondo prevede un

23

accesso all'intero storico dei rilevamenti. Attraverso le modalit appena descritte, vengono fornite all'utente le informazioni sullo stato del sistema operativo in esecuzione sulla virtual machine selezionata.
Sistema Operativo MonitorEstecoCloud Info OS Info OS Applicazione web Informazioni Sistema Operativo

Modulo per il monitoraggio

Info OS Info OS

Figura 6: Schema del funzionamento di MonitorEstecoCloud

Oltre al monitoraggio delle risorse del sistema operativo, l'applicazione deve essere in grado di monitorare l'insieme di processi in esecuzione e di terminarli su richiesta dell'utente. Per poter realizzare le operazioni desiderate si deciso di introdurre un'entit che rappresenti il singolo processo in esecuzione su un sistema operativo. Le informazioni contenute in questa entit che hanno il compito di descrivere il singolo processo in esecuzione riguardano: L'identificatore univoco del processo (PID) che viene assegnato dal sistema operativo al momento della sua creazione. Le informazioni relative al proprietario del processo. In particolare vengono utilizzati il nome utente e il gruppo di appartenenza dell'utente, che vengono definiti all'interno del sistema operativo. Lo stato in cui si trova il processo durante la sua esecuzione.. L'utilizzo della memoria da parte del processo. L'occupazione in percentuale del processore da parte del processo.

La classe utilizzata per la rappresentazione di un processo all'interno dell'applicazione MonitorEstecoCloud ProcessSample ed stata definita nel seguente modo:

24

ProcessSample - pid : long - name : String - user : String - group : String - state : char - memoryResident : long - memoryShared : long - memoryVirtual : long - cpu : double + ProcessSample(pid : long, name : String, user : String, group : String, state : char, memoryResident : long, memoryShared : long, memoryVirtual : long, cpu : double) + getPid() : long + getName() : String + getUser() : String + getGroup() : String + getState() : char + getMemoryResident() : long + getMemoryShared() : long + getMemoryVirtual() : long + getCpu() : double + toString() : String

La procedura di terminazione di uno dei processi del sistema operativo viene fatta partire remotamente dall'utente, attraverso l'utilizzo dell'applicazione web WebEstecoCloud. In particolare, il singolo processo da terminare viene identificato grazie al PID ad esso associato. Tale procedura viene rappresentata nella seguente figura, dove si vede come il comando di terminazione processo venga inoltrato all'applicazione MonitorEstecoCloud, che si occuper, a sua volta, di terminare effettivamente il processo.

Sistema Operativo MonitorEstecoCloud Processo Processo

Applicazione web

Processo

Figura 7: Schema terminazione dei processi in esecuzione

La classe principale che definisce l'entit principale dell'applicazione MonitorEstecoCloud prende il nome di Monitor; questa classe si occupa di controllare il monitoraggio del sistema operativo, che viene eseguito in modo

25

indipendente dal flusso di esecuzione principale e di fornire gli strumenti attraverso i quali viene effettuato l'accesso allo storico dei rilevamenti. In questo modo la lettura dello storico e la terminazione dei processi viene eseguita su richiesta dell'utente, mentre il processo per il monitoraggio continua ad aggiornare lo storico in modo automatico ad intervalli regolari di tempo. La classe Monitor stata definita nel modo seguente. Monitor - DEFAULT_PERIOD : int = 1000 - DEFAULT_SAMPLES_SCALE : int = 60000 - DEFAULT_PORT : int = 9999 - DEFAULT_ATTEMPTS : int = 5 - MAX_SAMPLES : int = 5 - samples : LinkedList<MachineSample> - sigarProxy : SigarProxy - period : int - attempts : int - samplesMaxSize : int - samplesScale : int + Monitor() + Monitor(period : int, attempts : int, samplesMaxSize : int, samplesScale : int) - addSample(sample : MachineSample) + getSample() : MachineSample + getSamples() : MachineSample[] + killProcess(pid : int) + start() + main(args : String[])

Tra gli attributi che compongono la classe Monitor, alcuni sono stati definiti come delle costanti; queste costanti rappresentano dei parametri per il funzionamento del componente che si occupa del monitoraggio all'interno dell'applicazione MonitorEstecoCloud. In particolare: DEFAULT_PERIOD: rappresenta tempo di attesa, espresso come numero di millisecondi, che passano tra un rilevamento ed un altro dei dati del sistema operativo. DEFAULT_ATTEMPTS: il numero massimo di tentativi di lettura di un dato relativo ad una risorsa da monitorare. Questo parametro necessario in quanto possibile che una delle risorse da monitorare non sia temporaneamente disponibile; importante sottolineare che questo fenomeno si presenta soltanto per alcune delle risorse interessate dal monitoraggio. Nel caso in cui una delle risorse non risulti accessibile, l'applicazione ritenta nuovamente di ottenere il dato fino a raggiungere un numero di tentativi pari al valore del parametro DEFAULT_ATTEMPTS. Il raggiungimento del numero massimo di tentativi, con conseguente fallimento della lettura del dato, stato considerato come informazione da inviare all'applicazione web. DEFAULT_PORT: il il valore associato alla porta utilizzata dall'applicazione di monitoraggio per la

26

comunicazione con l'applicazione web. DEFAULT_SAMPLES_SCALE: il numero che definisce il tempo di intervallo tra un campione del rilevamento ed un'altro, contenuto nello storico. MAX_SAMPLES: definisce la dimensione della coda FIFO contenente i rilevamenti effettuati. In questo caso ad esempio stato scelto di utilizzare uno storico contenente gli ultimi cinque rilevamenti del monitoratore. Come detto precedentemente, si scelto di demandare ad un'entit indipendente da Monitor l'esecuzione effettiva dell'operazione di monitoraggio. Questa scelta motivata dal fatto che tale operazione deve essere ripetuta ciclicamente ad intervalli regolari e non ha bisogno di conoscere lo stato di esecuzione delle altre componenti dell'applicazione. La classe che descrive questa entit MonitorThread definita come descritto nella seguente tabella. MonitorThread - sigarProxy : SigarProxy - period : int - attempts : int + MonitorThread(sigarProxy : SigarProxy, period : int, attempts : int) - getCPU() : CPUSample - getMemory() : MemorySample - getProcesses() : ArrayList<ProcessSample> + run()

Lo schema complessivo delle classi utilizzate nell'applicazione MeonitorEstecoCloud risulta essere quello riportato in figura.

Monitor

MachineSample

ProcessSample

MemorySample

CPUSample

Figura 8: Schema delle classi di MonitorEstecoCloud

27

5 Realizzazione
In questo capitolo vengono descritte in primo luogo le tecnologie che sono state utilizzate nella realizzazione del sistema per il controllo ed il monitoraggio del cloud; in secondo luogo viene descritto il modo in cui stata realizzata l'implementazione delle diverse componenti che costituiscono il sistema.

5.1 Tecnologie utilizzate

Come tecnologia che sta alla base della realizzazione di questo sistema di monitoraggio e di controllo, stata scelta Java. Questa scelta motivata dal fatto che il sistema complessivo da monitorare fortemente eterogeneo, sia per quello che riguarda le piattaforme che offrono il servizio di cloud, sia per quanto riguarda i sistemi operativi installati sulle virtual machine. La tecnologia Java offre una soluzione adatta a questo scenario, infatti sono state utilizzate delle API, compatibili con il linguaggio di programmazione Java, per mezzo delle le quali possibile interagire con ognuna delle piattaforme che offrono il servizio di cloud computing. Inoltre, utilizzando la tecnologia Java possibile realizzare un unico agente per il monitoraggio delle risorse dei diversi sistemi operativi in grado di essere eseguito su di una Java Virtual Machine (JVM). Per la realizzazione dell'applicazione web WebEstecoCloud sono state utilizzate le seguenti tecnologie: Java servlet [15]. JSP Standard Tag Library (JSTL) [16]. JQuery [17]. JQuery tools [18]. Javascript [19]. Server Glassfish 3.1.1 [20]. HTML 5 [19]. CSS3 [19].

Per quanto riguarda la libreria EstecoSimpleCloud e l'applicazione per il monitoraggio del sistema operativo installato sulle diverse virtual machine, sono state utilizzate le seguenti tecnologie ed API: Jclouds [21]. Java OCA [4]. Sigar [22]. Java Management Extensions (JMX) [23].

28

5.1.1 Jclouds
Nell'ambiente del cloud computing, esistono moltissimi progetti in grado di fornire una piattaforma che permetta di usufruire di un servizio di cloud di tipo IaaS. All'interno dell'insieme di questi progetti, vengono utilizzati strumenti d'interfaccia simili tra loro per funzionalit offerte, ma con differenze per quanto riguarda l'implementazione di tali strumenti. Jclouds offre un'interfaccia multipiattaforma in grado di aderire alle funzionalit offerte dai diversi provider di un servizio di cloud di tipo IaaS. Nella struttura di jclouds ci sono due diversi tipi di API legate tra loro: Il pacchetto di API che permette di utilizzare un'astrazione logica del sistema di cloud computing sia per quanto riguarda le operazioni che la struttura delle risorse. Le API che consentono l'accesso a funzionalit specifiche di un determinato provider del servizio di cloud. In particolare, queste API permettono l'implementazione delle funzionalit astratte offerte dalla libreria. Uno dei punti di forza di questa tecnologia la compatibilit con diversi provider. Infatti, jclouds compatibile con alcune delle pi importanti piattaforme di cloud computing che offrono uno stile di servizio IaaS, tra cui Amazon, GoGrid, Azure, vCloud e Rackspace. Per quanto riguarda il pacchetto di API per l'astrazione del cloud, jclouds introduce un'ulteriore divisione basata sulla funzionalit del servizio: Compute: permette il bootstrap delle macchine virtuali nel sistema cloud. Blobstore: permette la gestione di dati utilizzando di una struttura di accesso basata su coppie chiavevalore.

5.1.2 Java OCA

Java OpenNebula Cloud API (Java OCA) uno degli strumenti d'interfaccia offerti da OpenNebula. Basato sul linguaggio Java, stato progettato come un wrapper dell'API XML-RPC, che in grado di operare direttamente con il nucleo del sistema OpenNebula. Questo significa che per utilizzare Java OCA necessario conoscere la struttura dell'API XML-RPC e i formati XML utilizzati per la rappresentazione delle risorse di OpenNebula.

5.1.3 Sigar
Sistema Hyperic Information Gatherer (SIGAR) un'API open source multipiattaforma che permette di ottenere informazioni riguardanti il funzionamento di un sistema operativo. SIGAR compatibile con i sistemi Linux, FreeBSD, Windows, Solaris, AIX, HP-UX e Mac OSX. Utilizzando l'API SIGAR possibile ottenere informazioni su:

29

Risorse del sistema come memoria RAM, memoria di swap, e CPU. Utenti definiti all'interno del sistema operativo. File system. Interfaccia di rete sia dal punto di vista della configurazione che del carico.

Per quanto riguarda i diversi sistemi operativi, le informazioni sono del tutto simili dal punto di vista del significato, ma il modo in cui queste informazioni vengono fornite pu essere molto diverso. SIGAR offre un livello omogeneo di astrazione compatibile con tutti i sistemi operativi supportati, in questo modo si possono utilizzare gli stessi metodi per accedere alle informazioni di sistemi operativi diversi, in modo trasparente. SIGAR un'API implementata nel linguaggio di programmazione C, ma offre la possibilit di utilizzare altri linguaggi come Java, Perl e C#.

5.1.4 JMX
La tecnologia Java Management Extensions (JMX) parte della piattaforma Java a partire dal J2SE 5.0; offre un metodo standard per il controllo ed il monitoraggio di risorse quali dispositivi, applicazioni e servizi. In particolare, possibile utilizzare JMX per il monitoraggio ed il controllo di Java Virtual Machine (JVM). La tecnologia JMX caratterizzata dai seguenti componenti: Managed Beans (MBeans): oggetti Java di cui sono dotate le risorse da monitorare. Server Mbean: server che agisce da agente di controllo; ogni risorsa, per essere monitorata, deve essere registrata in un server MBean. JMX agent: uno strumento che permette di controllare le risorse conformi alla specifica; sono composti da un server MBean, all'interno del quale gli MBean sono registrati, e da una serie di servizi, che hanno il compito di gestire gli MBean. In questo modo i JMX agent possono controllare le risorse per il monitoraggio anche da applicazioni remote. JMX connector: permette di accedere ad un JMX agent attraverso applicazioni remote; possibile configurare il protocollo di comunicazione e il sistema di autenticazione utilizzato dal JMX connector senza per modificare il modo in cui si accede ai dati.

5.2 EstecoSimpleCloud
La libreria EstecoSimpleCloud, che fornisce uno strumento per il controllo del cloud ibrido multipiattaforma, stata realizzata utilizzando la tecnologia Java. Per ogni piattaforma stata realizzata una classe che implementa le interfacce SimpleComputeAccess e SimpleStorageAccess facendo uso delle API jcloud, per il controllo di Amazon EC2 ed Eucalyptus, e Java OCA, per il controllo di OpenNebula.

30

Alcuni aspetti della piattaforma astratta di cloud, definita da EstecoSimpleCloud, non sono stati effettivamente implementati per ognuna delle piattaforme. Questo dovuto al fatto che non tutte le piattaforme di cloud prese in considerazione offrono le funzionalit definite in fase di analisi. A differenza di quanto accade per le altre piattaforme, Eucalyptus non supporta la sospensione delle virtual machine in esecuzione; per questo motivo non sono stati implementati i metodi che fanno riferimento alle funzionalit di sospensione e riattivazione delle virtual machine. La connessione creata per l'interazione con OpenNebula non prevede una chiusura da parte del client; questa situazione non viene rispecchiata nell'astrazione logica del concetto di connessione utilizzata nella libreria EstecoSimpleCloud, quindi il metodo per la chiusura della connessione con OpenNebula non esegue alcuna operazione.

5.3 MonitorEstecoCloud
MonitorEstecoCloud l'agente utilizzato per il monitoraggio ed il controllo di ci che viene eseguito all'interno di una virtual machine. Per la realizzazione di questa applicazione stata utilizzata la tecnologia Java; per l'implementazione delle funzionalit definite in fase di progettazione sono stati utilizzati l'API Sigar, per il monitoraggio e la terminazione dei processi in esecuzione, e la tecnologia JMX, per la comunicazione tra MonitorEstecoCloud e WebEstecoCloud. Lo storico, all'interno del quale vengono inseriti i campioni forniti dal processo per il monitoraggio, stato implementato utilizzando la classe LinkedList. La LinkedList contiene il dato relativo all'ultimo rilevament o ed i dati degli ultimi campioni, il cui numero definito da MAX_SAMPLES e rilevati ad una distanza temporale specificata da DEFAULT_SAMPLES_FRQ. L'inserimento dei dati all'interno della LinkedList stato realizzato nel modo descritto nella seguente figura.

31

Utlimo rilevamento storico0 storico1 storico2

I II III IV Rimuovi primo campione della lista No

Arrivo di un nuovo rilevamento da memorizzare

La lista vuota?

Inserisci campione nella lista

Nuovo rilevamento e Caso 1: e a meno di x millisecondi da b Inserisci campione al primo posto della lista Inserisci campione nella lista

a b c d

I II III IV

e b c d e e

I II III No IV I II III IV

L'istante del S primo campione a pi di x millisecondi dal secondo?

La lista piena?

Rimuovi ultimo campione della lista

No Inserisci campione nella lista

Caso 2: e a pi di x millisecondi da b

b c

Figura 9: Operazione di aggiornamento della LinkedList di MonitorEstecoCloud

Facendo riferimento alla figura, si sottolinea come venga inserito due volte il campione nella lista nel caso in cui questa risulti vuota; questo dovuto al fatto che il primo elemento della lista rappresenta l'ultimo campione rilevato dall'agente di monitoraggio, mentre il secondo rappresenta il primo elemento dello storico. La tecnologia JMX stata inserita nella realizzazione di MonitorEstecoCloud utilizzando un MBean dinamico per le classi che descrivono le risorse del sistema operativo sulle quali effettuare il monitoraggio o il controllo. Questa scelta permette di mettere in comunicazione WebEstecoCloud e MonitorEstecoCloud senza avere la necessit da parte dell'applicazione web di conoscere le classi utilizzate dall'applicazione di monitoraggio; infatti le classi utilizzate da MonitorEstecoCloud vengono sostituite da una classe generica che ne mantiene le funzionalit. Il risultato che l'applicazione web pu accedere ai metodi di MonitorEstecoCloud senza conoscere il modo in cui le classi di tale applicazione sono state realizzate. La scelta di utilizzare MBean dinamico motivata dalla volont di non duplicare le classi utilizzate per la rappresentazione delle componenti da monitorare o controllare, che altrimenti sarebbero dovute essere inserite sia in WebEstecoCloud sia in MonitorEstecoCloud. Per quanto riguarda il connettore utilizzato la comunicazione remota del server MBean, stato utilizzato JMX Messagging Protocol (JMXMP) connector, che un connettore generico conforme alla specifica. Questo connettore basa il suo protocollo di comunicazione su TCP e l'object wrapping sulla serializzazione Java. Per quanto riguarda la sicurezza, il connettore fa riferimento alle tecnologie Java Secure Socket Extension (JSSE),

32

Java Authentication and Authorization Service (JAAS) e Simple Authentication and Security Layer (SASL). Per implementare il sistema appena descritto, necessario definire le classi alle quali l'applicazione remota dovr avere accesso come implementazioni d'interfacce, inoltre necessario includere un'annotation per il costruttore di tali classi. Tale annotation ha il compito di definire il nome parametri del costruttore, utilizzati successivamente dalle classi generiche che implementano le funzionalit della classe che viene esportata dal server MBean. Prendendo ad esempio la classe ProcessSample, il costruttore sar dotato della seguente annotation:
@ConstructorProperties({"pid", "name", "user", "group", "state", "memoryResident", "memoryShared", "memoryVirtual", "cpu"})

Per evitare problemi d'inconsistenza dei dati di rilevamento, i metodi della classe Monitor che permettono di accedere al contenuto dello storico sono stati sincronizzati. A differenza delle altre classi che compongono MonitorEstecoCloud la classe Monitor non pubblica sul server MBean tutti i suoi metodi pubblici, ma solo quelli per l'accesso allo storico dei rilevamenti e per la terminazione di un processo in esecuzione. Per fare ci la classe Monitor implementa la seguente interfaccia: MonitorMXBean + getSample() : MachineSample + getSamples() : MachineSample[] + killProcess(pid : int)

Con questa scelta non viene reso accessibile il metodo start() da remoto, cos facendo si demandato al processo principale il compito di far partire il monitoraggio del sistema. Lo schema complessivo delle classi utilizzate per l'implementazione dell'applicazione MonitorEstecoCloud risulta essere quello riportato in figura.

33

MonitorMXBean

MachineSampleMXBean

Monitor

MachineSample

ProcessSample

MemorySample

CPUSample

ProcessSampleMXBean

MemorySampleMXBean

CPUSampleMXBean

Figura 10: Schema delle classi di MonitorEstecoCloud

5.4 WebEstecoCloud
WebEstecoCloud l'applicazione web che, messa a disposizione degli utenti, permette di ottenere informazioni ed eseguire le operazioni richieste dai requisiti stabiliti in fase di analisi. L'applicazione web stata realizzata utilizzando le tecnologie Java servlet, HTML 5 e CSS3. Ogni pagina contenuta in quest'applicazione stata realizzata utilizzando la tecnologia Java Server Pages, le automazioni e le funzionalit sono state realizzate utilizzando degli script in linguaggio Javascript. Per quanto riguarda il server sul quale l'applicazione web viene eseguita, stato utilizzato un server Glassfish v3.1.1. Nella figura seguente viene riportata l'organizzazione delle pagine web dell'applicazione.
indexCloud

paneCloud

partialImages

monitorInfo

partialVMs

monitorHistory

Figura 11: Schema delle pagine web di WebEstecoCloud

La pagina indexCloud la pagina principale di WebEstecoCloud. All'interno di questa pagina presente un link per ogni piattaforma di cloud utilizzata nel sistema; questi link fanno riferimento alla pagina parziale paneCloud, che consiste in un tab contente dati relativi ad una singola piattaforma; per la realizzazione della struttura di

34

questo tab stata utilizzata la componente jQuery Tabs della libreria jQuery TOOLS, mentre i dati che contiene vengono ottenuti dinamicamente in base al parametro cloudType inserito nella richiesta alla pagina stessa. Le pagine partialImages e partialVMs sono pagine parziali inserite all'interno di paneCloud, contengono rispettivamente i dati delle immagini delle virtual machine e i dati delle virtual machine in esecuzione sulla piattaforma a cui paneCloud fa riferimento. Il caricamento dei dati inseriti in queste pagine viene eseguito dinamicamente al momento della creazione di una connessione con la piattaforma desiderata. Attraverso una selezione sul contenuto di dati della pagina parziale partialVMs possibile accedere alla pagina monitorInfo, che ha il compito di fornire le informazioni riguardanti il sistema operativo della singola virtual machine e da la possibilit di terminare i processi in esecuzione. Inoltre, dalla pagina monitorInfo possibile accedere alla pagina monitorHistory contenente i dati relativi all'utilizzo del processore e della memoria nel tempo. L'accesso all'applicazione WebEstecoCloud stata limitata introducendo un sistema di autenticazione ed autorizzazione; tutte le risorse dell'applicazione sono ristrette ai soli utenti autenticati. Inoltre la connessione con ogni singola piattaforma prevede l'inserimento di una coppia di chiavi per l'autenticazione; queste chiavi devono essere inserite nel sistema attraverso un form di autenticazione della pagina parziale paneCloud. La connessione con una singola piattaforma mantenuta attraverso l'utilizzo delle sessioni, in questo modo possibile operare simultaneamente sulle diverse piattaforme creando una sola connessione per piattaforma. Le operazioni descritte fino ad ora sono state realizzate grazie all'utilizzo di Java servlet. Le servlet utilizzate dall'applicazione web sono: Connect: quando viene fatta una richiesta a questa servlet si crea una connessione con la piattaforma alla quale paneCloud sta facendo riferimento; viene aperta una sessione per tale connessione e aggiunto un parametro di stato per segnalare che la connessione con la piattaforma corrente aperta. Disconnect: utilizzata per la chiusura della connessione con la piattaforma alla quale paneCloud. Inoltre, viene terminata la sessione che mantiene lo stato di connesso alla piattaforma. GetImages: fornisce la lista delle virtual machine che possono essere create. Viene inoltrata una richiesta alla piattaforma sulla quale l'utente sta agendo; il contenuto della risposta viene inserito in una richiesta per la pagina partialImages. GetVMs: questa servlet ottiene la lista delle virtual machine attualmente in funzione sulla piattaforma considerata. I dati relativi alle virtual machine vengono ottenuti dalla piattaforma di cloud computing e inoltrati alla pagina partialVMs. GetMonitorInfo: viene utilizzata per ottenere i dati relativi alle risorse del sistema operativo e i processi in esecuzione. Viene aperta una connessione con l'applicazione MonitorEstecoCloud in esecuzione sulla

35

virtual machine selezionata, i dati ottenuti vengono inoltrati alla pagina monitorInfo. GetMonitorHistory: utilizzata per ottenere i dati sull'occupazione percentuale di processore e memoria complessivi dallo storico contenuto in MonitorEstecoCloud. StartImage: inoltra la richiesta alla piattaforma considerata per la creazione di una virtual machine tra quelle messe a disposizione. SuspendInstance: viene fatta la richiesta di sospensione di una virtual machine in esecuzione alla piattaforma su cui stata creata. ResumeInstance: servlet che ha il compito di riattivare una virtual machine in sospensione. Viene inviata una richiesta alla piattaforma di cloud sulla quale stata creata la virtual machine. StopInstance: viene inviata una richiesta di terminazione di una virtual machine alla piattaforma di cloud di appartenenza. TermProcess: implementa l'operazione di terminazione di un processo in esecuzione su un sistema operativo di una delle virtual machine. La richiesta viene effettuata attraverso la pagina monitorInfo. Nella seguente figura vengono descritti i collegamenti ed il modo in cui le servlet vengono utilizzate ed inserite nella realizzazione di WebEstecoCloud.

Connect indexCloud Disconnect

paneCloud

ResumeInstance

StopInstance GetVMs GetImages SuspendInstance partialVMs partialImages

GetMonitorInfo

StartImage

monitorHistory

GetMonitorHistory

monitorInfo

TermProcess

Figura 12: Schema delle servlet Java di WebEstecoCloud

I dati ottenuti dall'elaborazione delle servlet GetImages e GetVMs vengono inoltrati come parametri assieme alla richiesta delle pagine partilaImages e parialVMs. I dati vengono utilizzati per la realizzazione delle pagine JSP mediante l'utilizzo del tag aggiunti della libreria JSTL; in particolare i dati vengono inviati sotto forma di Java

36

collection alla pagina, che utilizza delle iterazioni sugli elementi di queste collection per la costruzione delle tabelle contenenti i dati delle immagini e delle virtual machine in esecuzione. Le pagine JSP parziali GetImages e GetVMs vengono ottenute attraverso richieste Ajax implementate grazie all'utilizzo della libreria jQuery. Infatti, all'interno della pagina paneCloud sono definite due tabelle vuote che verranno completate con le pagine parziali GetImages e GetVMs. La visibilit degli elementi all'interno della pagina paneCloud condizionata al fatto che l'utente correntemente autenticato abbia aperto una connessione con la piattaforma selezionata. Quando un utente del sistema richiede le informazioni sullo stato delle risorse del sistema operativo, tali richieste non vengono direttamente inoltrate all'agente per il monitoraggio in esecuzione sulla virtual machine, ma vengono servite utilizzando dei dati inseriti precedentemente in un buffer contenuto in GetMonitorInfo. Infatti, l'applicazione web l'unica a contattare direttamente gli agenti in esecuzione sulle virtual machine per ottenere le informazioni rilevate. I dati ottenuti da MonitorEstecoCloud hanno un determinato tempo di validit specificato dall'attributo SAMPLE_LIFETIME inserito all'interno di GetMonitorInfo. Di seguito viene riportato il digramma di flusso che definisce il modo in cui vengono servite le richieste di informazioni in merito al sistema operativo di una virtual machine identificata dal proprio indirizzo IP.

Arrivo nuova richiesta per info(IP)

Info(IP) sono nel buffer?

No

Richiesta info(IP) al monitoratore(IP)

Aggiornamento del buffer

S
Info(IP) sono scadute?

No
Restituzione info(IP) ottenute dal buffer

Figura 13: Diagramma di flusso della gestione di richieste a GetMonitorInfo

Facendo riferimento alla figura, si pu osservare come il campione, contenente le informazioni di una determinata virtual machine, venga inserito nel buffer soltanto al momento in cui arriva una richiesta da parte di un utente del sistema. Allo stesso modo, viene eseguito parallelamente un processo in grado di valutare se un campione inserito nel buffer scaduto o meno, in caso il suo tempo di validit sia scaduto viene eliminato dal

37

buffer. Di seguito sono riportati alcuni esempi di funzionamento teorici di come vengono servite le richieste all'utente.

CASO 1: periodo della richiesta = 4, tempo di vita delle informazioni = 3

t=0 1 2 3 4 5 6 7 8 9 CASO 2: periodo della richiesta = 2, tempo di vita delle informazioni = 3

10

11

12

13

t=0

10

11

12

13

CASO 3: richieste aperiodiche, tempo di vita delle informazioni = 3

t=0

10

11

12

13

Figura 14: Esempi di richieste a GetMonitoInfo

Come si pu osservare in figura i casi 1 e 2 fanno riferimento a richieste periodiche a GetMonitorInfo, mentre l'esempio del caso 3 prende in considerazione delle richieste aperiodiche. Tutte le richieste sono state inoltrate per la medesima virtual machine; queste sono rappresentate in figura da una freccia verso il basso. Si vuole sottolineare il fatto che le richieste arrivate durante il periodo di validit del campione (rappresentate in rosso nella figura) non corrispondono ad una richiesta a MonitorEstecoCloud, il dato richiesto viene prelevato dal buffer e risulta identico a quello restituito all'ultima richiesta per la quale stato contattato l'agente per il monitoraggio (rappresentata in nero nella figura). Nel caso 1 le richieste hanno un periodo superiore al tempo di vita del campione ottenuto da MonitoEstecoCloud; ad ogni richiesta viene restituito da GetMonitoInfo un nuovo campione, questo significa che il periodo con il quale viene osservato un valore diverso dal precedente pari a quello delle richieste. A differenza del caso 1, l'esempio del caso 2 vede un periodo di arrivo delle richieste inferiore a quello del tempo di vita del campione; in questa situazione viene restituito un campione nuovo ad ogni seconda richiesta da parte del client. In generale, si pu affermare che, in caso di richieste periodiche da parte di un client a GetMonitorInfo, il periodo con il quale vengono ottenuti nuovi campioni dall'agente MonitorEstecoCloud dato dalla seguente relazione

38

LIFETIME REQ REQ

con LIFETIME il tempo di vita di un campione nel buffer e REQ il periodo di arrivo delle richieste a GetMonitorInfo. Per quanto riguarda il caso di richieste aperiodiche, valgono le medesime considerazioni fatte per il caso di richieste periodiche; come si vede nell'esempio al caso 3, le richieste in arrivo all'interno del periodo di validit del campione vengono gestite senza fare richiesta all'agente MonitoEstecoCloud. Fissando il parametro SAMPLE_LIFETIME con un valore di poco superiore al periodo di campionamento di MonitorEstecoCloud, possibile restituire informazioni sul sistema operativo di una virtual machine con una frequenza che si avvicina a quella dell'effettivo campionamento del monitoratore. Introducendo un buffer per i campioni ottenuti da MonitorEstecoCloud si ridotto il numero di volte in cui vengono effettuate le richieste all'agente di monitoraggio: con una configurazione come quella appena suggerita, vengono eliminate tutte le richieste inutili al monitoratore, cio quelle richieste che non possono avere un valore diverso da quella precedente, in quanto pi frequenti del periodo di campionamento. La limitazione delle richieste all'agente di monitoraggio importante anche dal punto di vista delle risorse che la gestione di tali richieste comporta. Infatti, la quantit di risorse utilizzate da MonitorEstecoCloud aumenta, sia dal punto di vista della memoria sia da quello del processore, in modo direttamente proporzionale al numero di richieste da gestire. La medesima soluzione stata adottata anche per l'accesso a GetMonitorHistory, utilizzata per ottenere informazioni dallo storico di MonitorEstecoCloud.

5.5 Infrastruttura del sistema di controllo e di monitoraggio

Il sistema di monitoraggio e di controllo che stato realizzato prevede l'utilizzo di un server web Oracle GlassFish 3.1.1 sul quale poter eseguire l'applicazione WebEstecoCloud. Il server utilizzato stato installato sulla macchina denominata research05, appartenente alla rete interna di Esteco; tale server ha la possibilit di comunicare con i nodi che compongono le piattaforme di cloud computing OpenNebula ed Eucalyptus. Inoltre, la macchina research05 ha accesso ad internet per essere in grado di comunicare con la piattaforma pubblica Amazon EC2. Nella figura seguente viene riportata quella che viene ad essere l'infrastruttura complessiva del cloud e del sistema di monitoraggio.

39

ESTECO
EUCALYPTUS OPEN NEBULA

nebula-xen02 nebula-frontend

euca-xen02 euca-frontend

nebula-kvm01

nebula-xen01

nebula-xen03

euca-xen01

euca-xen03

euca-xen04

AMAZON EC2

Figura 15: Infrastruttura sistema complessivo

Gli utenti del sistema possono inviare richieste utilizzando un browser dal proprio terminale interno ad Esteco; tali richieste verranno elaborate dall'applicazione WebEstecoCloud, che a sua volta utilizzer le funzionalit offerte da EstecoSimpleCloud o da MonitorEstecoCloud a seconda che sia necessario ottenere le informazioni da una delle piattaforme di cloud computing o da una delle virtual machine in esecuzione sul cloud. Le richieste inoltrate da WebEstecoCloud ad una delle piattaforme di cloud privato, prevedono esclusivamente una comunicazione con il nodo di frontend della piattaforma: euca-frontend, nel caso di Eucalyptus, e nebulafrontend, nel caso di OpenNebula. Per quanto riguarda le richieste effettuate alla piattaforma Amazon, la richiesta viene invece inviata ad uno dei nodi preposti per il controllo e l'interazione con l'utente. Le virtual machine che vengono create nel sistema di cloud possono essere effettivamente eseguite utilizzando risorse esterne, attraverso l'infrastruttura di Amazon, o risorse interne, facendo uso di uno dei nodi che compongono OpenNebula ed Eucalyptus diversi dal frontend. Nel caso in cui vengano richieste le informazioni relative all'utilizzo delle risorse del sistema operativo di una delle virtual machine, le richieste da parte di WebEstecoCloud vengono effettuate direttamente alla virtual machine presa in considerazione.

40

Server GassFish 3.1.1

research05

6 Interfaccia
In questo capitolo si descrive il modo in cui l'applicazione sviluppata per il monitoraggio ed il controllo utilizzabile da un utente del sistema. Prima si descriver l'interfaccia utente, che consiste nell'applicazione web WebEstecoCloud; successivamente si descrive il modo in cui possibile eseguire il programma per il monitoraggio MonitorEstecoCloud.

6.1 WebEstecoCloud
Per accedere a WebEstecoCloud un utente deve autenticarsi inserendo il proprio user name e la password. Una volta autenticato, l'utente ha la possibilit di creare una connessione su una delle piattaforme, scelta attraverso la selezione di uno dei tab rappresentanti la singola piattaforma; la connessione pu essere effettuata attraverso il seguente form, all'interno del quale dovranno essere inserite le credenziali di autenticazione per l'accesso alla singola piattaforma di cloud computing.

Figura 16: WebEstecoCloud form di login

Una volta creata la connessione con la piattaforma desiderata, l'utente ha la possibilit di visualizzare la lista delle virtual machine che possono essere create sul cloud e quelle che attualmente sono in esecuzione. Le informazioni rappresentate dal sistema per le virtual machine che possono essere create sono: ID: l'identificatore univoco assegnato dalla piattaforma sulla quale stata creata l'immagine. DESCRIPTION: la descrizione testuale dell'immagine della virtual machine contenente informazioni specificate in fase di creazione o definite dal provider. Le virtual machine in esecuzione invece sono definite da: ID: l'identificatore della virtual machine univoco assegnato dalla piattaforma sulla quale stata creata. IMAGE: contiene la descrizione testuale dell'immagine da cui stata creata la virtual machine.

41

STATUS: lo stato di esecuzione nel quale si trova la virtual machine. IP: l'insieme di indirizzi ip assegnati alle interfacce di rete della virtual machine.

Figura 17: WebEstecoCloud, vista sulle risorse della piattaforma OpenNebula

Facendo riferimento alla figura, si pu vedere come l'utente pu effettuare le operazioni selezionando la virtual machine attraverso il relativo checkbox e scegliendo l'operazione desiderata; per quanto riguarda le macchine virtuali da eseguire possibile esclusivamente inizializzarle attraverso il bottone Start, mentre per le macchine virtuali che attualmente sono in esecuzione possibile scegliere una tra le operazioni inserite nell'elemento Select. Una volta scelta, l'operazione verr eseguita su ognuna delle macchine virtuali selezionate. Inoltre possibile effettuare un aggiornamento manuale del contenuto della pagina contente le informazioni sulle virtual machine attraverso il bottone Update. Selezionando l'operazione Monitor per una delle virtual machine in esecuzione, verr aperta una nuova finestra contenente le informazioni sulle risorse del sistema operativo in esecuzione. Il contenuto di questa pagina viene automaticamente aggiornato ad intervalli di tempo regolari. Nella pagina di monitoraggio sono inseriti il nome del sistema operativo, l'indirizzo ip dell'interfaccia di rete, l'istante dell'ultimo rilevamento, i dati relativi all'occupazione della CPU, della memoria e ai processi in esecuzione, in particolare il singolo processo definito dalle seguenti attributi: PID: identificatore del processo assegnato dal sistema operativo. NAME: nome del processo. USER: nome dell'utente del sistema operativo proprietario del processo.

42

GROUP: gruppo definito sul sistema operativo a cui USER appartiene. STATE: stato del processo. MEMORY: occupazione della memoria resident. CPU: stima dell'occupazione della CPU del processo.

Inoltre, possibile effettuare l'operazione di terminazione di uno dei processi attraverso il pulsante TERM relativo al singolo processo.

Figura 18: WebEstecoCloud, dettaglio della pagina con informazioni ottenute da MonitorEstecoCloud

Un utente pu aprire connessioni con ognuna delle piattaforme che compongono il sistema complessivo. La chiusura di una connessione possibile attraverso l'utilizzo del bottone Disconnect presente in una delle tabs relative ad una piattaforma con la quale stata aperta una connessione. Dalla pagina MonitorInfo possibile accedere ad alcune delle informazioni contenute nello storico di MonitorEstecoCloud attraverso la pressione del pulsante History, posizionato nella parte superiore della pagina; tali informazioni vengono visualizzate nella pagina MonitorHistory attraverso due grafici che riportano l'utilizzo della memoria e della CPU espressa in valori percentuali.

43

Figura 19: WebEstecoCloud, grafico riassuntivo della pagina MonitorHistory

Inoltre, possibile visualizzare i dettagli di ogni campione contenuto nello storico, selezionando un elemento del grafico riportato in figura. I dettagli verranno visualizzati al di sotto del grafico appena descritto, nella figura seguente riportato un esempio della rappresentazione delle informazioni di dettaglio contenute in un campione dello storico.

Figura 20: WebEstecoCloud, informazioni di dettaglio della pagina MonitorHistory

Facendo riferimento alla figura, si pu vedere come le informazioni dettagliate relative al sistema operativo e all'utilizzo delle sue risorse sia stato inserito all'interno di una textarea, visualizzata nella parte superiore della

44

figura. Per quanto riguarda le informazioni relative ai processi in esecuzione, stata riportata una tabella simile a quella utilizzata nella pagina MonitorInfo.

6.2 MonitorEstecoCloud
L'applicazione MonitorEsecoCloud pu essere eseguita definendo i seguenti parametri preceduti da -: period: definisce il tempo di attesa tra una scansione e l'altra del monitoratore. Il valore del tempo di attesa espresso in millisecondi. Valore di default pari a 1000. size: definisce la dimensione dello storico all'interno del quale vengono inseriti i campioni rilevati dal monitor. Valore di default pari a 50. scale: definisce la scala dei campioni dello storico. Il valore del parametro rappresenta il tempo, espresso in millisecondi, che passa tra l'istante di rilevamento di un campione ed il successivo. Valore di default pari a 60000. port: specifica la porta sulla quale potranno essere ricevute le richieste del client remoto. Valore di default pari a 9999. Un esempio di esecuzione:
java -jar MonitorEstecoCloud.jar -port 9999 -period 10000 -size 50 -scale 10000

In questo caso viene eseguito un MonitorEstecoCloud in ascolto sulla porta 9999, con un periodo di campionamento pari a 10 secondi e con uno storico da 50 elementi con una scala temporale di 10 secondi.

45

7 Configurazione del sistema

In questo capitolo vengono descritte le impostazioni e le configurazioni necessarie al funzionamento del sistema di monitoraggio; sono incluse le configurazioni delle piattaforme di cloud computing e delle immagini utilizzate per la creazione delle virtual machine. Ogni virtual machine che viene creata necessita di essere connessa alla rete. Poich ogni virtual machine creata da un'unica immagine, necessario che la configurazione dell'interfaccia di rete avvenga in modo dinamico al momento della creazione dell'immagine. Per fare questo sono stati utilizzati due metodi: script di contestualizzazione che configurano l'interfaccia di rete in base a parametri inseriti al momento delle creazione della virtual machine. Server DHCP interno alla piattaforma di cloud. Se si desidera monitorare il sistema operativo di ogni virtual machine necessario che nel sistema sia presente una copia dello Java Runtime Environment. Inoltre, allo startup di ogni sistema operativo necessario che venga eseguita in modo automatico l'applicazione Java MonitorEstecoCloud. Per fare in modo che sia possibile effettuare lo spegnimento delle virtual machine necessario verificare che sia installato ACPD e che sia abilitata la possibilit di spegnimento anche nel caso in cui non sia stato effettuato il login da parte dell'utente. Per la configurazione e la realizzazione degli automatismi necessari al funzionamento del sistema di monitoraggio e di controllo sono stati utilizzati: script di Shell, per i sistemi operativi Linux [24]. Script di Powershell, per i sistemi operativi Microsoft Windows [25].

Di seguito viene riportato a titolo di esempio lo script in PowerShell utilizzato per la contestualizzazione delle virtual machine Microsoft Windows create sulla piattaforma di cloud computing OpenNebula.
function getContext($file){ $context = @{} switch -regex -file $file { '(.+)="(.+)"' { $name,$value = $matches[1..2] $context[$name] = $value } }

46

return $context } function configureNetwork($context) { $Nics = Get-WMIObject Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -eq "TRUE" -and ($_.MACAddress)} foreach ($nic in $Nics){ $nic.ReleaseDHCPLease() $nic.EnableStatic($context["IP"],$context["NETMASK"]) $nic.SetGateways($context["GATEWAY"]) $DNSServers = $context["NS"],$context["NS"] $nic.SetDNSServerSearchOrder($DNSServers) $nic.SetDynamicDNSRegistration("FALSE") } } if( -not(Test-Path "C:\context\")){ New-Item "C:\context\" -type directory } $cont = 0 while ( $cont -le 1) { $Nics = Get-WMIObject Win32_NetworkAdapterConfiguration | where {$_.IPEnabled -eq "TRUE" -and ($_.MACAddress)} foreach ($nic in $Nics){ $cont = $cont + 1 } echo $cont } if( -not(Test-Path "C:\context\contextualized") -and(Test-Path "D:\context.sh") ){ $context = @{} $context = getContext('D:\context.sh') configureNetwork($context) echo "contextualized" |Out-File ("C:\context\contextualized") }

In questo esempio si pu vedere come il file di contestualizzazione creato da OpenNebula venga utilizzato per ottenere le variabili per la configurazione dell'interfaccia di rete. La funzione getContext($file) si occupa appunti di leggere il valore degli attributi specificati nel template della virtual machine; tali valori vengono utilizzati dalla funzione function configureNetwork($context) per la configurazione dell'interfaccia di rete. Da sottolineare il fatto che la contestualizzazione viene effettuata soltanto al primo boot del sistema dopo la

47

creazione della virtual machine. Infatti, prima di eseguire la configurazione dell'interfaccia di rete viene testata l'esistenza di un file creato dalla contestualizzazione stessa; nel caso in cui questo file esista, la contestualizzazione non viene effettuata. Nel caso di un sistema operativo Linux in esecuzione su una virtual machine di OpenNebula si procede in modo analogo utilizzando uno script Shell Linux.

48

8 Risultati e test
In questo capitolo vengono presentati i risultati di alcune sperimentazioni effettuate con la finalit di ottenere una visione delle prestazioni e dei limiti dell'agente di monitoraggio MonitorEstecoCloud. Inoltre, tali esperienze sono servite per la scelta dei valori di alcune dei parametri di funzionamento dell'applicazione. I test sono stati effettuati con la finalit di misurare l'occupazione delle risorse come il processore e la memoria RAM da parte dell'agente di monitoraggio MonitorEstecoCloud. Le diverse misurazioni sono state effettuate al variare del periodo di campionamento, della dimensione dello storico e della scala temporale relativa ai campioni inseriti nello storico. Per ogni test sono stati definite le seguenti grandezze: Period: rappresenta il tempo che passa tra una misurazione e l'altra di MonitorEstecoCloud. Il valore espresso in millisecondi. Scale: rappresenta il tempo che separa due campioni consecutivi all'interno dello storico contenuto nell'agente di monitoraggio. Il valore di questo parametro espresso in millisecondi. Size: definisce la quantit di campioni inseriti all'interno dello storico. Per ogni test effettuato, l'occupazione delle risorse da parte del processo associato all'agente di monitoraggio stato osservato, con un periodo di 10 secondi, per un tempo totale di almeno 40 minuti dal momento dell'inizio di esecuzione dell'agente di monitoraggio; il periodo di osservazione per ogni test stato scelto tenendo in considerazione il raggiungimento dei valori riscontrati da osservazioni effettuate a molto tempo dall'inizio di esecuzione del monitoratore, quindi riconducibili ad un caso in cui l'occupazione delle risorse si sia stabilizzata. Per quanto riguarda lo scenario all'interno del quale sono stati svolti i test, il processo stato eseguito in ambiente Linux Ubuntu 11.10, installato su di un computer con processore Intel Core 2 Duo T9400 e 4GB di RAM.

8.1 Test period

In questo test stato variato unicamente il parametro period: Test period period size scale TestPrd0 100 50 10000 TestPrd1 1000 50 10000 TestPrd2 10000 50 10000

49

Nei grafici seguenti vengono riportati l'utilizzo di memoria RAM e CPU del processo associato all'agente di monitoraggio, con periodo di campionamento di 0.1s, 1s e 10s.

Da questo test si evince che il periodo con il quale l'agente per il monitoraggio ottiene le informazioni del sistema operativo, sul quale in esecuzione, non influenza l'occupazione della memoria a regime. Invece non si pu dire altrettanto per quanto riguarda l'occupazione del processore, infatti si nota come nel caso del test con periodo pari a 0.1s, l'occupazione della CPU oscilla tra il 15% ed il 30%. Nella seguente tabella vengono riportati i valori medi dell'utilizzo della CPU espressi in percentuale. Test period CPU (%) TestPrd0 22.13 TestPrd1 3.21 TestPrd2 0.60

Utilizzando i valori riportati in tabella, si pu tracciare l'andamento della crescita dell'utilizzo del processore in funzione del parametro period.

50

Dai dati ottenuti si pu quindi concludere che un valore accettabile per il parametro period di MonitorEstecoCloud deve essere superiore a 1000, il che garantisce in queste condizioni un utilizzo mediamente inferiore al 3.5% della CPU.

8.2 Test size

In questo test stato variato unicamente il parametro size: Test size period size scale TestSize0 1000 50 10000 TestSize1 1000 100 10000 TestSize2 1000 200 10000 TestSize3 1000 400 10000 TestSize4 1000 800 10000

Di seguito sono riportati i grafici sull'utilizzo di memoria RAM e CPU del processo associato all'agente di monitoraggio, con uno storico composto da 50, 100, 200, 400 e 800 elementi. Il periodo di osservazione di 240 minuti, con un campionamento di 10 secondi per un totale di 1440 campioni; questo dovuto al fatto che per poter apprezzare il consumo della memoria RAM si dovuto aspettare un periodo di stabilizzazione a seguito del riempimento dello storico.

Nel grafico, le linee tratteggiate fanno riferimento all'istante in cui lo storico raggiunge una dimensione pari al numero massimo di campioni da memorizzare. Nella seguente tabella vengono riportati i valori medi misurati relativi al raggiungimento della stabilit dell'utilizzo della memoria RAM. Test size Utilizzo (MB) TestSize0 32.96 TestSize1 34.58 TestSize2 37.60 TestSize3 41.78 TestSize4 48.20

51

Utilizzando i valori riportati in tabella, si pu tracciare l'andamento della crescita del consumo della memoria in funzione del parametro size.

In questo test si pu vedere come all'incremento del numero di campioni contenuti nello storico, corrisponda un aumento dell'occupazione della memoria RAM. Per quanto riguarda l'utilizzo del processore non sono state riscontrate differenze significative al variare del parametro size di MonitorEstecoCloud. Si pu concludere che la scelta del parametro size risulta vincolante dal punto di vista del consumo di risorse. Infatti, stato riscontrato un aumento dell'utilizzo della memoria RAM da parte del processo associato all'agente per il monitoraggio; questo aumento tale da influenzare in modo significativo il complessivo utilizzo della memoria.

8.3 Test scale

In questo test stato variato unicamente il parametro scale: Test scale period size scale TestScl0 1000 50 1000 TestScl1 1000 50 10000 TestScl2 1000 50 100000

Nei seguenti grafici si possono osservare l'utilizzo di memoria RAM e di CPU del processo associato all'agente di monitoraggio, con periodo di aggiornamento dello storico di 1s, 10s e 100s.

52

In questo test si pu notare come il valore associato al parametro scale non influenzi l'utilizzo a regime del processo associato all'agente di monitoraggio, sia per quanto riguarda l'utilizzo della memoria RAM sia per quanto riguarda l'utilizzo del processore. Tuttavia, possibile osservare come l'utilizzo della memoria si stabilizzi pi velocemente quanto pi piccolo il periodo di aggiornamento dello storico, questo dovuto al fatto che con un periodo di aggiornamento minore lo storico viene riempito pi velocemente, stabilizzando quindi il consumo complessivo del processo. Si pu concludere che non ci sono vincoli al valore associato al parametro scale di MonitorEstecoCloud.

8.4 Considerazioni
Un aspetto importante per l'agente di monitoraggio del sistema operativo l'occupazione delle risorse del sistema stesso. Infatti, non sarebbe accettabile un monitoratore che influenzi in modo significativo le capacit di una virtual machine sia dal punto di vista della memoria sia da quello del processore. Dai test effettuati sull'agente di monitoraggio MonitorEstecoCloud si pu concludere che, per mantenere la quantit di risorse utilizzate dal processo a livelli accettabili, devono essere introdotti dei vincoli sui valori assegnati ai parametri period e size. Per quanto detto, il periodo di campionamento delle risorse del sistema operativo deve essere superiore ad un secondo al fine di limitare l'utilizzo del processore da parte del processo; questa limitazione non risulta essere particolarmente negativa dal punto di vista pratico, infatti un periodo di campionamento di un secondo pi che accettabile per il funzionamento del sistema di monitoraggio. Per quanto riguarda il parametro size, la limitazione sembrerebbe essere il valore 400; questa limitazione per risulta essere di molto superiore alle reali necessit per il funzionamento dell'agente di monitoraggio. Quindi si pu affermare che, per uno scenario reale, la dimensione dello storico non risulta essere un parametro particolarmente vincolante.

53

9 Conclusioni
Alla fine del lavoro svolto, stato prodotto un sistema in grado di soddisfare tutti i requisiti definiti in fase di analisi. Allo stato attuale il sistema in esecuzione ed in grado di interagire con le piattaforme di cloud compunting coinvolte per la creazione ed il rilascio delle risorse e di monitorare virtual machine in esecuzione. Per quanto riguarda la compatibilit, il sistema di monitoraggio risulta essere compatibile con tre piattaforme di cloud computing: Eucalyptus. OpenNebula. Amazon EC2.

Inoltre, il sistema consente l'utilizzo di sistemi operativi Linux e Microsoft Windows, che potranno essere eseguiti sulle virtual machine create attraverso le risorse di cloud; pi precisamente sono stati utilizzati in fase di realizzazione i seguenti sistemi operativi: Ubuntu 9.04. Ubuntu 11.10. Microsoft Windows Xp SP3. Microsoft Windows 7.

Per il sistema di monitoraggio e di controllo sono stati realizzate complessivamente: 5 Java Server Page. 11 Java Servlet. 25 Java Class. 5 script (nei linguaggi Linux Shell Scripting e Microsoft PowerShell).

Uno degli aspetti che hanno caratterizzato questo lavoro rappresentato dalla diversa tipologia d i tutti quegli elementi che hanno preso parte al sistema. Infatti, per i funzionamento del sistema stata necessaria l'interazione con soluzioni web, con sistemi che offrono un servizio di cloud computing, con hypervisor di virtualizzazione e con aspetti legati al funzionamento del sistema operativo. Inoltre, per quanto riguarda il servizio di cloud computing, il sistema di virtualizzazione ed il sistema operativo sono state utilizzate differenti piattaforme, rendendo il contesto all'interno del quale stato svolto il lavoro di tesi ancora pi vasto. Lo sviluppo di questo sistema potrebbe riguardare l'estensione della compatibilit del sistema, includendo nuove piattaforme di cloud computing, prendendo in considerazione ad esempio le soluzioni offerte da VMware, o

54

consentendo l'utilizzo di altri sistemi operativi oltre a quelli Microsoft e Linux. Oltre ad un'estensione della compatibilit, potrebbero essere aggiunte nuove funzionalit ad ognuno del moduli che compongono il sistema, come ad esempio l'inserimento di un'entit che faccia riferimento all'infrastruttura fisica del cloud privato in EstecoSimpleCloud o l'inserimento della funzionalit di monitoraggio delle interfacce di rete in MonitorEstecoCloud.

55

Bibliografia
[1] : Jia Yu, Rajkumar Buyya; A Taxonomy of Workflow Management Systems for Grid Computing; 2005. [2] : Peter Mell, Timothy Grance; The NIST Definition of CloudComputing; 2011. [3] : Michael Armbrust, Armando Fox, Rean Grifth, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, Matei Zaharia; Above the Clouds: A Berkeley View of Cloud Computing; 2009. [4] : OpenNebula; OpenNebula 3.0 Guides; http://www.opennebula.org/documentation:archives:rel3.0. [5] : Amazon Web Services; Amazon Elastic Compute Cloud (Amazon EC2); http://aws.amazon.com/ec2/. [6] : Eucalyptus; Eucalyptus Dacumentation; http://open.eucalyptus.com/wiki. [7] : Kirill Kolyshkin; Virtualization in Linux; 2006. [8] : Robert P. Goldberg; Architectural Principles for Virtual Computer Systems; 1973. [9] : Intel; Intel Virtualization Technology; http://www.intel.com/content/www/us/en/virtualization/intelvirtualization-transforms-it.html. [10] : AMD; AMD Virtualization Technology; http://sites.amd.com/uk/business/itsolutions/virtualization/Pages/amd-v.aspx. [11] : KVM; KVM Documentation; http://www.linux-kvm.org/page/Main_Page. [12] : QEMU; QEMU Manual; http://wiki.qemu.org/Manual. [13] : Xen; Xen Documentation; http://wiki.xen.org/wiki/Xen_Overview. [14] : Apple; Software License Agreement for MAC OS X; http://images.apple.com/legal/sla/docs/macosx107.pdf. [15] : Oracle; Oracle Technology Network for Java Developers; http://www.oracle.com/technetwork/java/index.html. [16] : Oracle; JavaServer Pages Standard Tag Library; http://www.oracle.com/technetwork/java/jstl137486.html. [17] : jQuery; jQuery Dacumentation; http://docs.jquery.com/Main_Page. [18] : jQuery TOOLS; jQuery TOOLS Dacumentation; http://flowplayer.org/tools/documentation/index.html. [19] : w3schools; HTML Tutorials; http://www.w3schools.com/. [20] : Oracle; Oracle GlassFish Server; http://www.oracle.com/us/products/middleware/applicationserver/oracle-glassfish-server/index.html. [21] : jClouds; jClouds Documentation; http://www.jclouds.org/documentation/. [22] : Hyperic; SIGAR Documentation; http://support.hyperic.com/display/SIGAR/Home. [23] : Oracle; Java Management Extensions (JMX) Technology;

56

http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html. [24] : Mendel Cooper; Advanced Bash-Scripting Guide; 2011. [25] : Microsoft; Scripting with Windows PowerShell; http://technet.microsoft.com/enus/scriptcenter/dd742419.

57

Ringraziamenti

Il primo ringraziamento va all'azienda Esteco, che mi ha permesso di svolgere questo lavoro di tesi, in particolare un ringraziamento a Livio che mi ha seguito in questo periodo dedicandomi molto del suo tempo prezioso.

Un ringraziamento doveroso va al professor Medvet, sempre disponibile per consigli e chiarimenti durante lo svolgimento del lavoro.

Un ultimo ringraziamento va alla mia famiglia che mi sempre stata vicino e mi ha permesso di raggiungere questo importante obbiettivo.

58