Piattaforme di Cloud Computing Open Source: la proposta Eucalyptus

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Reti di Calcolatori Piattaforme di Cloud Computing Open Source: la proposta Eucalyptus Anno Accademico 2011/12 Candidato: Pierluca Nardone matr. N

2

3 Indice Introduzione 4 1.Cloud Computing Cosa si intende per Cloud Computing? Modelli di Cloud Computing Tipologie di Cloud Esigenza di Cloud Computing Open Source Una piattaforma Open Source di Cloud Computing: Eucalyptus Perché Eucalyptus Architettura Node Controller Cluster Controller Walrus Cloud Controller Funzionalità Istance Control Implementazione e Gestione degli SLA Virtual Networking Esperimenti effettuati su Eucalyptus Istance Throughput Network Performance Utilizzo di Eucalyptus Eucalyptus Enterprise 33 Conclusioni 35 Bibliografia 36

4 Introduzione I sistemi Cloud Computing forniscono un accesso a grandi quantità di dati e risorse, attraverso una varietà di interfacce e una gestione delle risorse dei sistemi di programmazione. Questi sistemi offrono un nuovo target alla programmazione per gli sviluppatori di applicazioni scalabili e nel giro di pochi anni hanno ottenuto popolarità. Tuttavia, la maggior parte dei sistemi che utilizzano il Cloud Computing sono proprietari, facendo affidamento su infrastrutture invisibili oppure non esplicitamente progettati per essere modificati da sistemi open source. Eucalyptus si propone come una piattaforma di Cloud Computing che sfrutta le funzionalità di un cloud privato con l'obiettivo di renderla disponibile al servizio della comunità. Esso può essere modificato, contribuendo al suo sviluppo e alla sua sicurezza, oppure si può imparare a comprendere la sua struttura e alla sua organizzazione, grazie al fatto che è possibile scaricare semplicemente il proprio codice sorgente. Esso nasce inizialmente come progetto di ricerca del Dipartimento di Informatica presso l'università della California, Santa Barbara nell'autunno del 2007 per poi divenire una vera e propria piattaforma open source nel 2009, grazie ad una serie di miglioramenti che l'hanno portato ad un processo di commercializzazione del progetto. 4

5 5

6 Capitolo 1 Cloud Computing 1.1 Cosa si intende per Cloud Computing? Non esiste un'unica definizione per definire il concetto di Cloud Computing. Secondo Gartner ( fondatore dell'omonima azienda che si occupa di IT), per Cloud Computing si dovrebbe intendere come : «A style of computing where scalable and elastic IT capabilities ara provided as a service to multiple costumers using Internet technlogies», mentre secondo il NIST [1] (National Institute of Standard and Technology, U.S.A.) : «Cloud Computing is a model for enablig ubitquitos, convenient, on-demand network acces to shared pool a configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction». In pratica è un servizio fornito su rete che ci permette di utilizzare risorse, sia hardware che software, contenute in una particolare struttura, alla quale vi si può accedere via Internet o tramite una rete locale. Tale struttura, definita proprio come un cloud (nuvola in inglese), gestisce una varietà di risorse, dati e servizi che vengono offerti grazie ad una serie di interfacce, con la consapevolezza che l'utente non può effettivamente percepire la posizione fisica di tutto il materiale utilizzato (macchine, reti, storage, sistemi operativi, ambienti di sviluppo, programmi applicativi etc.). Mettendo in comune risorse di calcolo e consentendo un accesso self-service, i cloud possono offrire i seguenti vantaggi : Self-Service Provisioning : ogni utente può richiedere delle risorse in base alle proprie esigenze, senza subire ritardi o complicazioni tipiche di un'acquisizione di una risorsa. Durante le operazioni di monitoraggio, di gestione e di espansione di un'infrastruttura cloud di base, viene supportata la personalizzazione e la valorizzazione delle esperienze dell'utente ; Scalabilità : vengono separate le esigenze degli utenti con i vincoli strutturali, quindi si può facilmente venire incontro ad un rapido aumento o diminuzione delle 6

7 richieste alle risorse ; Affidabilità e Fault-Tolerance : si possono raggiungere determinati livelli di affidabilità focalizzando l'attenzione sui punti critici dell'infrastruttura, ed inoltre è possibile rivalutare ed aggiornare tali livelli attraverso delle politiche che non coinvolgano in alcun modo gli utenti ; Ottimizzazione : viene massimizzato l'utilizzo e migliorata l'efficienza delle risorse strutturali, estendendo il ciclo di vita dell'infrastruttura ; Quality of Service (QoS) : viene rivalutata dinamicamente ogni singolo SLA (Service Level Agreement) associato ad utenti o gruppi di utenti, consentendo ad un'organizzazione o ad un'azienda di reagire ad eventuali cambiamenti senza coinvolgere l'utente e senza farlo mettere a conoscenza di esse ; API ben definite : l'utilizzo di una API standard ben definita evita il lock-in e garantisce l'interoperabilità con un numero elevato di tool e fornitori di servizi di cloud (provider) ; As-needed Availability : viene allineato il dispendio di risorse con l'utilizzo effettivo delle risorse, consentendo ad una azienda di pagare solo per ciò che è necessario. Figura 1. Cloud Computing Roles 7

8 1.2 Modelli di Cloud Computing Tra i tanti modelli esistenti di Cloud Computing è possibile definirne tre, che differiscono in base al livello di astrazione : Software as a Service (SaaS) : assicura l'accesso a collezioni di programmi applicativi software. I fornitori di servizi SaaS offrono agli utenti l'accesso agli applicativi specifici che vengono controllati ed eseguiti sulle infrastrutture di tali provider. Spesso tale modello viene definito anche Software on Demand. Attraverso un browser Web viene facilitata la comunicazione client/server e viene gestita la presentazione dei contenuti, mentre tutte le forme di elaborazioni vengono fatte eseguire da un data center composto dai server dedicati ad eseguire il software in questione. Quindi ogni utente può accedere alle proprie applicazioni indipendentemente dalla macchina che si sta utilizzando, e i dati, salvati su server remoti, vengono resi disponibili in qualsiasi momento. Platform as a Service (PaaS) : fornisce l'accesso ad un ambiente run-time scalabile, con strutture di calcolo e dati in esso incorporati. Gli utenti sono in grado di sviluppare ed eseguire le proprie applicazioni in esso tramite il fornitore dei servizi, che è responsabile del suo funzionamento. Il provider deve configurare appositamente l'hardware e il software necessari per l'esecuzione delle applicazioni, aggiornare la piattaforma e garantire la disponibilità delle risorse richieste dagli utenti. Essi possono disporre di risorse virtuali in quantità illimitata, poiché il provider configura il sistema in base al carico di lavoro corrente, ma non possono avere la possibilità né di sviluppare le applicazioni, né di effettuare operazioni di manutenzione su di esse. Infrastructure as a Service (IaaS) : fornisce l'accesso a collezioni di risorse hardware virtualizzate, comprese macchine, reti ed elementi di storage. Gli utenti possono assemblare dei cluster virtuali e sono i responsabili per l'installazione e la manutenzione dei propri software. Le risorse hardware vengono fornite in base alle richieste dell'utente, il quale ne avrà un completo controllo e una gestione autonoma. Oltre alle risorse necessarie per l'esecuzione di una macchina fisica 8

9 (SO, memoria, spazio su disco e connettività alla rete), vengono offerti anche dei servizi di supporto, come la gestione delle politiche di sicurezza e il monitoraggio. Le modalità con le quali vengono eseguite effettivamente le macchine virtuali vengono gestite dal provider, e non sono visibili all'utente finale, e ad esso gli verrà fornita sola un'istanza per poter accedere e usufruire ad una macchina virtuale. In pratica ogni provider IaaS mette a disposizione delle interfacce che consentono ad ogni utente di richiedere l'utilizzo delle istanze di cui ha bisogno, poi il sistema si occuperà di allocare le risorse, in un data center dedicato, e di effettuare tutte le operazioni necessarie per rendere la macchina virtuale accessibile tramite Internet. Figura 2. Modelli di astrazione di Cloud Computing 1.3 Tipologie di Cloud Sul mercato ci sono 3 tipologie di politiche di gestione delle strutture per il Cloud Computing. Esse sono le seguenti: On premise Cloud - Modello di Cloud privato alla quale gli utenti accedono alle risorse gestite da un'infrastruttura appartenente ad un'azienda. Nella gestione delle architetture, un Cloud privato è soggetto a misure di sicurezza fisica, elettronica e procedurale, attraverso meccanismi di firewall, e quindi offre un ottimo grado di protezione del codice e dei dati sensibili. 9

10 Public Cloud - Prevede l'accesso alle risorse di calcolo in maniera pubblica, cioè il provider consente ai client di rifornirsi di tutto il materiale desiderato servendosi di interfacce web. In questo caso il cloud offre un accesso a grandi pool di risorse scalabili a titolo temporaneo (rent), senza la necessità di investire capitali per delle infrastrutture data center. Hybrid Cloud - Non fa altro che combinare risorse provenienti da uno o più ambienti di cloud pubblici con quelli derivanti da uno o più cloud proprietari. 1.4 Esigenza di Cloud Computing Open Source Il Cloud Computing viene presentato come un fenomeno innovativo, con prospettive di crescita economica, ma vi sono tuttavia delle problematiche. La maggior parte delle piattaforme di Cloud Computing si fonda sull'impiego di tecnologie e strutture proprietarie, ed inoltre è necessario assicurare l'interoperabilità di dati e risorse tale, consentendo agli utenti la migrazione da un provider all'altro in modo efficace e a costi bassi: ma l'utilizzo di strutture private non consente di contribuire all'evoluzione e alla crescita della base software, dal momento che in tutte le diverse soluzioni presenti sul mercato (Amazon con Elastic Compute Cloud (EC2), Google con Google App Engine, Microsoft con Windows Azure, Salesforce con Force.com etc..) essa è parte integrante delle politiche di strategia, e dunque non è possibile pervenire al codice sorgente. Per questi motivi, la Commissione Europea [2] si è posto l'obiettivo di coinvolgere, in modo diretto ed effettivo, la comunità denominata Free/Libre and Open Source Software (FLOSS) nei processi di sviluppo delle tecnologie Cloud (con la consapevolezza che il 90% dei progetti avviati e portati a termine da esso saranno di utilizzo commerciale per imprese non europee). Quindi i servizi offerti dell'open Cloud Computing vengono definiti come servizi di Cloud Computing che facciano prevalentemente impiego di piattaforme e/o applicazioni FLOSS, nonché standard aperti ed interoperabili nell'elaborazione dei dati. Dunque, una questione sollevata intorno all'open cloud è legata alla standardizzazione, in cui si cerca di compattare le diverse interfacce tra cloud e sviluppatori in un'unica 10

11 Application Programming Interface (API), affinché la programmazione delle applicazioni miri ad un utilizzo massimo delle risorse, astraendo da essi il codice e altre informazioni aggiuntive e cercando di fare uso di un protocollo di comunicazione per rendere interoperabili elementi eterogenei di un cloud (server di elaborazione, switch, router, componenti di storage). L'Open Cloud Computing quindi potrebbe essere di fondamentale importanza in future infrastrutture delle amministrazioni pubbliche, senza dimenticare la sua forte valenza commerciale: da un lato vi sono modelli di business del tipo avdertising/free (nella quale i servizi vengono forniti gratuitamente a patto che l'utente consenta ad una eventuale visualizzazione di annunci pubblicitari) e dall'altro del tipo subscription/paid (i servizi vengono forniti dietro un pagamento periodico, mensile o annuale, in base al tempo dell'effettivo utilizzo delle risorse). I servizi di Open Cloud Computing presentano alcuni vantaggi dal punto di vista economico, sia per i provider, i quali possono risparmiare sui costi relativi all'acquisizione di diritti per l'utilizzo di applicazioni da fornire nel cloud in questione, che per gli utenti (azienda, amministratore o semplice utente privato), poiché tutto questo comporta una riduzione di tutte le spese ed i costi associati all'acquisto e all'uso di materiali e servizi ( Total Cost of Ownerhip, TCO). 11

12 Capitolo 2 Una piattaforma Open Source di Cloud Computing: Eucalyptus Eucalyptus [3] è una piattaforma di Cloud Computing di tipo IaaS costruito originariamente su un prodotto cloud open source e che supporta una struttura di un cloud on premise (divenendo un vero e proprio cloud ibrido). Utilizza infrastrutture già esistenti per creare servizi web scalabili e sicuri (elaborazioni, reti, sicurezza e storage) che è in grado di offrire IaaS. Si avvale di metodi di virtualizzazione software per creare pool di risorse, che sono scalabili dinamicamente in base alla quantità di carico di lavoro delle applicazioni. 2.1 Perchè Eucalyptus Eucalyptus presenta alcune caratteristiche che la rendono la più diffusa tra i cloud onpremise e sono i seguenti: Open Source: si possono apportare modifiche, contribuire al suo sviluppo, capire il suo interno, dal momento in cui è possibile pervenire al suo codice sorgente; Componibile: la struttura di Eucalyptus è modulare, le sue componenti hanno interfacce ben definite e quindi si possono ottenere strutture personalizzate; Flessibile: può essere installato su una configurazione minimale oppure su migliaia di cluster e registri, grazie al fatto che è possibile installare la piattaforma su di una infrastruttura già esistente; Hypervisor Agnostic: Eucalyptus è progettato per supportare facilmente gli hypervisor (conosciuti anche come VM manager). Attualmente è in grado di supportare i due hypervisor KVM e Xen, e nella versione Enterprise Edition supporta anche l'hypervisor proprietario VMWare. Tutte le caratteristiche appena descritte rendono Eucalyptus un vero e proprio Hybrid Cloud, che combina risorse tratte da molteplici cloud, sia privati che pubblici. Inoltre, esso 12

13 è compatibile con le API dei cloud più popolari e utilizzati sul mercato, e tra le varie concorrenti, quella che presenta più completezza ed efficienza è l'api derivante da Amazon Web Services (AWS). Il 22 marzo del 2012 AWS ed Eucalyptus hanno stipulato un accordo grazie alla quale i clienti possono trasferire in modo efficiente i carichi di lavoro tra i data center del cloud di Eucalyptus e quelli di AWS, utilizzando gli stessi strumenti di gestione e le stesse competenze di entrambi gli ambienti. Tale accordo prevede un sostegno da parte di AWS in modo da rendere compatibili le proprie API con chi utilizza Eucalyptus. Gli utenti possono dunque elaborare le proprie applicazioni nei data center esistenti che sono dunque compatibili con i più diffusi Web Services che Amazon mette a disposizione (comunemente proprietari), mentre le componenti open source di Eucalyptus comunicano tra loro attraverso servizi web che si servono di un livello di comunicazione attraverso un'interfaccia compatibile con Amazon. Figura 3. Interazione tra Eucalyptus e AWS 13

14 2.2 Architettura L'archittettura di Eucalyptus [4] è semplice, flessibile e modulare con una struttura di tipo gerarchica. In sostanza, il sistema da la possibilità agli utenti di inizializzare, controllare, accedere e terminare intere macchine virtuali, usando un'emulazione di Amazon Elastic Computing Cloud (EC2) e delle interfacce per le query. Generalmente, si sceglie di implementare ogni componente del sistema come un servizio web in modalita stand-alone. Questo comporta due vantaggi: 1) ogni servizio web mette a disposizione una API ben definita nel formato di un documento WSDL contenente le strutture dati input/output e le operazioni che esso può eseguire; 2) le caratteristiche dei web services esistenti possono essere considerate come politiche per la comunicazione sicura tra le varie componenti. Vi sono 4 componenti, ognuno con una propria interfaccia Web Service, che comprende la struttura del sistema Eucalyptus: Node Controller: controlla l'esecuzione, l'ispezione e la terminazione delle istanze delle macchine virtuali su l'host che esegue; Cluster Controller: raccoglie informazioni circa il piano di esecuzione della macchina virtuale su uno specifico node controller, ed inoltre gestisce l'istanza di rete virtuale; Storage Controller (Walrus): è un servizio di storage che prevede un meccanismo per la memorizzazione e per l'accesso, nella macchina virtuale, delle immagini e dati utente; Cloud Controller: è l'entry-point nel cloud per utenti ed amministratori. Interroga i gestori dei nodi per ottenere informazioni sulle risorse, prende decisioni per lo scheduling, ed esssi vengono lanciati in esecuzione a seconda delle richieste fatte dai cluster controllers. 14

15 Figura 4.Architettura di Eucalyptus Node Controller Un Node Controller (NC) esegue su ogni nodo che viene creato da un'istanza di macchina virtuale. Interroga e controlla il sistema software sui suoi nodi, rispondendo alle query di controllo richieste dal suo Cluster Controller. Esso prende le query per effettuare la ricerca delle risorse fisiche di un nodo, in modo da aver coscienza dello stato dell'istanza della macchina virtuale corrispondente ad esso. Dopodichè le informazioni ricevute vengono propagate verso il Cluster Controller, in risposta alle chiamate delle funzioni describeresources e describeinstances, ed esso controllerà le istanze della macchina virtuale su un nodo dalle richieste del NC runistances e terminalistances. Dopo aver verificato l'autorizzazione e dopo aver confermato la disponibilità delle risorse, il NC esegue la richiesta con il supporto dell'hypervisor. Per inizializzare un'istanza, il NC prende una copia di un nodo locale tra le istanze delle immagini dei file (kernel, sistema root, immagine disco RAM), oppure da un repository remoto di immagini o da una cache locale ; poi crea un nuovo end-point in una macchina virtuale di tipo overlay, e chiede all'hypervisor di lanciare l'istanza appena creata. Per terminare un'istanza, il NC si serve di nuovo dell'hypervisor per spegnere la macchina 15

16 virtuale, demolisce l'end-point della rete virtuale e, infine, ripulisce i file associati ad essi (il root file system non viene preservato dopo che le istanze sono terminate) Cluster Controller Un Cluster Controller (CC) esegue su un cluster front-end, o su qualunque macchina avente una connettività alla rete sia su i nodi NC in esecuzione che sulla macchina che esegue il Cloud Controller. Molte delle operazione del CC sono simili a quelle del NC. Esso ha tre funzioni primarie: 1) schedula le richieste che provengono da un'istanza in esecuzione per specificare i NC; 2) controlla le istanze della macchina virtuale overlay; 3) raccoglie e riporta informazioni circa il set dei NC. Quando riceve un set di istanze da eseguire, il CC contatta ogni componente NC attraverso un'operazione di describeresources ed invia la richiesta runistances al primo NC che possiede risorse libere e dunque disponibile ad ospitare l'istanza. Quando invece riceve una richiesta describeresources, riceve un elenco di caratteristiche che descrivono i requisiti di una risorsa richiesta da un'istanza, definendo uno specifico ''tipo'' di macchina virtuale. Dopodichè, il CC calcola quante istanze di uno specifico ''tipo" è in grado di eseguire simultaneamente della collezione di NC, e riporta tale valore al Cloud Controller Walrus Walrus è un servizio di memorizzazione dei dati che utilizza le tecnologie degli standard dei Web Services, ed è compatibile con l'interfaccia Simple Storage Service di Amazon (S3). Esso fornisce due tipi di funzionalità: 1) trasferimenti di flussi di dati da e verso il cloud, effettuati da gli utenti che hanno accesso ad Eucalyptus; 2) servizio di archiviazione per le immagini di macchine virtuali, grazie alla quale possono essere caricate su di esso filesystem root, immagini del kernel e disco RAM, elementi utili 16

17 per creare un'istanza di una macchina virtuale appartente ad un nodo ( l'accesso a tali risorse è possibile attraverso il nodo stesso). Gli utenti sfruttano gli strumenti messi a disposizione da S3 per inviare dati dentro e fuori Walrus, e il sistema condivide le credenziali tramite il database del Cloud Controller. Come avviene in S3, Walrus è un grado di supportare i trasferimenti di dati sia concorrenti che seriali. In supporto alla scalabilità, Walrus non prevede lock-in per le scritture su di un oggetto ma, tuttavia, gli utenti hanno la possibilità di salvare una copia coerente dell'oggetto nel caso di scritture sullo stessa risorsa : infatti, se viene rilevata una scrittura ad un oggetto, mentro vi è ancora in corso una scrittura precedente, viene invalidata quest'ultima. Walrus risponde con il checksum MD5 (Message Digest algorithm 5) dell'oggetto che viene memorizzato : una volta che la richiesta viene inoltrata, l'utente è stato autenticato come user di Eucalyptus e, una volta confrontate le liste di controllo d'accesso degli oggetti richiesti, le scritture e le letture vengono messi su di uno flusso dati HTTP. Walrus inoltre agisce come un servizio di gestione e memorizzazione di una macchina virtuale: le immagini del filesystem root, del kernel e della RAM vengono impacchettate e caricate attraverso l'utilizzo di tool dello standard EC2 previsti da Amazon: questi strumenti comprimono immagini, eseguono una crittografia di esse attraverso l'utilizzo delle credenziali dell'utente, e le dividono in tante parti che vengono poi descrittte in un file di descrizione delle immagini (denominato manifesto in EC2). Walrus infine ha il compito verificare e decifrare le immagini caricate dagli utenti: quando un NC richiede un'immagine da Walrus, esso invia una richiesta di download dell'immagine, autenticata tramite una serie interna di credenziali, poi le immagini vengono decifrate ed infine trasferite. Per un miglioramento delle prestazioni, dato che le immagini delle macchine virtuali sono spesso di grandi dimensioni, Walrus possiede una cache di immagini già decifrate, e l'invalidazione della cache viene eseguita dal momento in cui il manifesto delle immagini viene sovrascritto oppure tale operazione può essere eseguita periodicamente. 17

18 Walrus è stato progettato per essere modulare, in modo tale che i sottosistemi di autenticazione, di streaming e di storage possono essere personalizzati dagli sviluppatori in base alle loro esigenze Cloud Controller Il Cloud Controller (CLC) gestisce e mette a disposizione le risorse virtualizzate contenute in un cloud di Eucalyptus. Esso raggruppa una collezione di Web Services in tre tipi categorie, in base al loro ruolo : Resource Services : elaborano delle tecniche per le allocazioni delle risorse, consentono agli utenti di manipolare le proprietà delle macchine virtuali e delle reti, monitorano sia le componenti di sistema che le risorse virtuali. Data Services : governano dati persistenti di utente e di sistema e forniscono un ambiente configurabile in grado di formulare le proprietà di una richiesta di assegnazione alla risorsa ; Interface Services : presentano interfacce visibili agli utenti, gestiscono l'autenticazione e la traduzione del protocollo in uso, ed mette a disposizione tutti gli strumenti di gestione che il sistema è in grado di fornire. Il primo tipo di richieste, i Resource Services, hanno il compito di elaborare le richieste di controllo della macchina virtuale ed interagiscono con i CC per effettuare allocazione e deallocazione delle risorse fisiche. Viene mantenuta una rappresentazione di System's Resource State (SRS), attraverso la comunicazione con i CC in qualità di intermediari che interrogano lo stato del NC, e viene utilizzata per valutare la realizzabilità delle richieste utente, dunque rispettando gli SLA. SRS esegue in due fasi : all'arrivo delle richieste degli utenti, le informazioni nel SRS vengono invocate per prendere una decisione di controllo di ammissione, rispettando le aspettative del level service agreement specificato dall'utente; poi avviene la creazione della macchina virtuale, che consiste nella prenotazione di risorse nel SRS, a valle della richiesta per la creazione di macchine virtuali, seguita 18

19 dall'impegno delle risorse nel SRS in caso di successo o di un rollback in caso di errore SRS controlla lo stato di allocazione delle risorse ed è la fonte di authority per le modifiche delle proprietà delle richieste in esecuzione. Un'informazione SRS è fondamentale per il sistema delle regole, consentendo la formulazione di uno schema di SLA event-based. Un'applicazione SRS viene fatta lanciare dal suo evento corrispondente, ed una richiesta può essere modificata nel caso in cui fosse insoddisfacente. Mentre la rappresentazione del sistema non sempre riflette sulle risorse effettive, con un SRS la probabilità e la natura delle imprecisioni possono essere quantificate e considerate nella formulazione ed applicazione degli SLA. Inoltre, il controllo di ammissione e le metriche runtime di uno SLA lavorano a stretto contatto in modo da cooperare, garantendo alle risorse che non siano troppo soggette ad un pesante carico di lavoro e mantenendo una visione conservatrice circa la disponibilità delle risorse, riducendo così la possibilità di fallimenti. Il secondo gruppo, quello dei Data Services, gestisce la creazione, la modifica, l'interrogazione e la memorizzazione di un sistema stateful e di dati utenti. Gli utenti possono richiedere questi servizi per trovare informazioni sulle risorse disponibili (immagini e clusters) e manipolare parametri astratti, i quali sono applicabili ad una macchina virtuale. I Data Services interagiscono con i Resource Services per risolvere i riferimenti ai parametri utente (ad esempio, come le chiavi associate ad un'istanza della macchina virtuale). Tuttavia, tali servizi non sono dei parametri di configurazione statica : un utente ha la possibilità di essere abilitato a cambiare le regole di firewall che riguardano gli ingressi del traffico, e tali cambiamenti possono essere fatti offline e sono previsti come input ad una richiesta di allocazione alla risorsa, ma questi input possono essere manipolati mentre l'applicazione è in esecuzione. Dunque, i servizi che gestiscono il networking e i secutity group data persistence devono essere considerati come agenti di cambio per conto di una richiesta utente per poi modificare lo stato la collezione di macchine virtuali in esecuzione e la rete virtuale che la supporta. 19

20 Infine, gli Interface Services sono in grado di offrire un'interfaccia Web per utenti ed amministratori cloud, attraverso la quale i primi hanno la possibilità di iscriversi per accedere al cloud, scaricare le credenziali crittografiche, per un'interfaccia programmabile, ed interrogare il sistema circa le immagini di disco disponibili, mentre gli amministratori possono gestire gli account degli utenti, controllando la disponibilità delle componenti del sistema. La collezione di Interface Web Services annuncia gli entry point per le richieste utente attraverso l'utilizzo di una varietà di specifiche. Gli utenti generalmente si servono del protocollo EC2 SOAP oppure di quello EC2 Query per generare le richieste. Tali protocolli prevedono una varietà di tool conformi con le interfacce EC2 ed S3, in modo da operare senza apportare modifiche. L'obiettivo della progettazione delle chiavi, che viene raggiunto grazie agli Interface Services, è quello di isolare i tipi di dati di comunicazione interna dalle richieste di mapping, passando da protocolli disparati ad un protocollo system-internal indipendente. Di conseguenza, i servizi interni sono incoerenti con i dettagli delle interfacce che vengono utilizzate dagli utenti, ma sono capaci di simulare le funzionalità, la sintassi e la struttura delle primitive dell'interfaccia, conservando l'investimento esistente in strumenti e codice. 2.3 Funzionalità Web-based Cloud User Console - La console user di Eucalyptus offre un'interfaccia comprensibile agli utenti per il self-service provisioning e configura elaborazione, rete e risorse di storage. I team di sviluppo e test gestiscono in modo flessibile e sicuro le istanze virtuali utilizzando delle funzioni di gestione e di crittografia. Le istanze virtuali possono essere fermate e riprese attraverso l'utilizzo di funzionalità offerte da Elastic Block Storage (EBS). Disponibilità elevata per le componenti Cloud - Una failure nel sistema di un data center, purtroppo, è prevedibile ed inevitabile. In un cloud IaaS, le componenti vengono configurate come sistemi ridondanti elastici a molti tipi di failure. Viene effettuato un cambiamento di stato della macchina cloud alle normali condizioni di 20

21 elaborazione nella situazione in cui sarà presente una failure a livello hardware oppure software. Gestione Eterogenea degli Hypervisor - Costruisce e gestisce molti ambienti di hypervisor cluster in un cloud IaaS e gestisce gli ambienti virtuali già esistenti compatibili con AWS per i cloud ibridi di Eucalyptus. Un portale di gestione selfservice compatibile con Eucalyptus può gestire gli ambienti virtuali XEN, KVM e VMWare attraverso un vero e proprio pannello, ottenendo una maggiore efficienza e riduzione di costi. Gestione multipla di formati Machine Image - Esegue versioni diversificate di immagini di macchine virtuali Windows e Linux, grazie alla presenza di una libreria di denominata Eucalyptus Machine Images (EMIs). Dunque le Amazon Machine Images (AMIs) sono compatibili con i cloud Eucalyptus, e le VMware Images possono essere convertite per eseguire su cloud Eucalyptus, su Amazon AWS e su qualsiasi cloud pubblico compatibile con Amazon. Administrator Friendly Scriptable Architecture Rende flessibili, configurabili e copiabili gli ambienti di sviluppo aziendali, in modo da automatizzare le funzioni possibili in una piattaforma di gestione cloud. Le aziende, per gestire un cloud Eucalyptus, possono scegliere di integrare le API Web Services (con i loro sistemi di gestione di fornitura preferito) oppure di usufruire di un qualunque stack di gestione che sia compatibile con Amazon AWS. Tutte le funzionalità disponibili vengono messe a disposizione attraverso un'interfaccia di tipo friendly (amichevole) in modo da progettare un cloud che possa funzionare con gli strumenti di un sistema azienda preesistente. Gestione delle Risorse attraverso una Console - Il Dashboard di Eucalyptus fornisce agli amministratori cloud una console grafica per l'esecuzione di diverse attività di gestione di cloud, tra cui la gestione delle risorse virtuali e fisiche e la configurazione delle risorse cloud, provisioning, de-provisioning e il reporting. 21

22 2.4 Istance Control La creazione delle istanze della macchina virtuale in Eucalyptus viene gestita da un componente del CLC chiamato VMControl, che ha il compito di effettuare una semplice rappresentazione locale dello stato delle risorse di base, cioè il numero di istanze di ciascun CC che potrebbe potenzialmente creare. Quando bisogna effettuare la creazione di istanze, esso si coordina con gli servizi del CLC per risolvere i riferimenti alle richieste di immagini, coppie di chiavi, reti e gruppi di protezione. L'allocazione consiste quindi nel convalidare riferimenti a dei metadati, un'applicazione di un meccanismo che produce una 'pre-assegnazione', il che significa che per quanto sia interessata la componente VMControl, le risorse vengono localmente riservate. I messaggi vengono poi diffusi ai CC che vengono coinvolti per la ripartizione. Così ogni CC schedulerà una richiesta di istanza verso i suoi NC locali, ognuno dei quali creerà l'istanza della macchina virtuale stessa. 2.5 Implementazione e Gestione degli SLA I Service level agreements (SLAs) vengono implementati come estensioni al servizio di gestione dei messaggi ed è in grado di controllare, modificare e rifiutare un messaggio. In pratica, la VMControl controlla l'accesso alle risorse e applica, a livello di sistema o di utente, gli SLA. Le decisioni che egli prende richiedono dei dati sullo stato delle risorse, che vengono catturati attraverso un modello del sistema, ed anche informazioni riguardanti gli eventi di aggiornamento (una variazione al modello o informazioni su un guasto). Il VMControl si basa su un modello locale ai fini decisionali : per mantenere il modello in piedi, ogni CC viene passivamente interrogato in modo da ottenere lo stato della sua disponibilità per le istanze, le allocazioni, la rete virtuale e le immagini registrate. Le informazioni raccolte tramite polling sono trattate come ground truth e le richieste degli utenti vengono gestite con delle operazioni effettuate solo quando stanno operando sulle risorse. Tuttavia, il modello può diventare incoerente, e questa situazione si può verificare nel caso in cui il sistema sia costretto ad accettare un contratto di servizio che non può essere 22

23 soddisfatto in nessun modo, e ciò può accadere quando i messaggi vengono persi (ad esempio, a causa di partizione della rete) o viene modificato lo stato delle risorse (il periodo tra due eventi di polling può essere comunque pensato come una partizione della rete). Tuttavia, la perdita di messaggi può essere identificato ed inoltre può essere rilevato l'attimo in cui il modello è in uno stato non valido (dopo che il sistema recupera il messaggio e la ground truth può essere ispezionata). Di conseguenza, è possibile calcolare la probabilità che il modello sia corretto in un dato momento: basta implementare un semplice ma potente SLA iniziale che permette agli utenti di controllare l'alto livello di topologia di rete delle loro istanze. Mentre i provider in genere pensano a collezioni di macchine in termini di "cluster" o "pool", qui viene adottato il concetto più generale di "zone", attualmente utilizzato da Amazon EC2, ed indica un insieme logico di macchine che ha diverse componenti NC e un singolo componente CC. Eucalyptus consente agli utenti di specificare una configurazione delle zone al momento dell'esecuzione di un'istanza, e consente all'istanza di essere configurata per a risiedere all'interno di un singolo cluster o potenzialmente tra più cluster. Inoltre, Eucalyptus può adottare il concetto di zona con l'obiettivo di estendere il supporto ad ulteriori SLA, rispetto al trade-off esistente tra il numero delle risorse acquisite e la loro topologia relativa. Nell'implementazione, la configurazione di default delle zone in dotazione permette agli utenti di richiedere uno specifico cluster : quello più libero, ogni singolo cluster nel caso in cui nessun cluster non in grado di fornire il minimo richiesto, o più cluster. 2.6 Virtual Networking Uno degli obiettivi principali nella progettazione di una infrastruttura di Cloud Computing generalmente è quello della interconnessione tra le istanze delle VM. Una delle caratteristiche più interessanti di un sistema cloud deriva dal fatto che, sebbene le macchine fisiche sottostanti possono avere una topologia di rete complessa e restrittiva, può essere presentata all'utente una topologia di interconnessione che sia più semplice e 23

24 più configurabile attraverso il processo di virtualizzazione. Durante la progettazione di Eucalyptus, ci si è reso conto che la soluzione di rete di istanze VM deve affrontare la connettività, l'isolamento, e le prestazioni. Innanzitutto, le macchine virtuali che Eucalyptus controlla devono avere una connettività di rete tra di loro, ed almeno parzialmente ad Internet ( il termine parzialmente indica che almeno che un delle istanze VM, appartenente ad un set, debba essere esposta verso l'esterno, in modo che il proprietario di tale set di istanze possa accedere ed interagire ad esse). Poiché agli utenti è concesso un accesso alle loro macchine come super-computer per il provisioning alle macchine virtuali, essi possono sfruttare questo tipo di accesso per pervenire alle interfacce di rete sottostanti. Ma questa capacità può causare problemi di sicurezza, in quanto, senza alcun ostacolo, un'istanza utente della macchina virtuale può acquisire un indirizzo IP o un indirizzo MAC, e quindi causare interferenze nella rete del sistema, ed inoltre, se due istanze sono in esecuzione su una macchina fisica, un utente di una VM può avere la capacità di influenzare i pacchetti di rete appartenenti ad un altro utente. Così, in un cloud condiviso da diversi utenti, le macchine virtuali appartenenti ad un cloud devono essere in grado di comunicare tra loro, ma quelle appartenenti a locazioni separate devono essere isolate. Infine, uno dei primi motivi che le tecnologie di virtualizzazione stanno solo ora guadagnano popolarità è che l'overhead della virtualizzazione è diminuita significativamente dopo pochi anni, includendo il costo delle interfacce di rete virtualizzate. Ogni istanza controllata da Eucalyptus è formata due interfacce di rete virtuali: una "pubblica" e una privata. L'interfaccia pubblica ha il compito di gestire la comunicazione al di fuori di un dato insieme di istanze di macchine virtuali, o tra le istanze all'interno della stessa zona disponibile, come definiti dallo SLA ( ad esempio, in un ambiente che ha indirizzi IP pubblici disponibili, possono essere assegnati a delle istanze VM in fase di avvio, permettendo la comunicazione da e verso l'istanza). Negli ambienti in cui sono collegate le istanze ad una rete privata con un router che supporta la comunicazione esterna, attraverso la traduzione degli indirizzi di rete (NAT), l'interfaccia 24

25 pubblica può essere assegnata ad un indirizzo privato valido, dando accesso ai sistemi al di fuori della rete locale attraverso il NAT router abilitato. L' interfaccia privata dell'istanza, tuttavia, viene utilizzata solo per la comunicazione inter-vm nel caso in cui due istanze di macchine virtuali sono in esecuzione all'interno di distinte reti private (zone), ma hanno bisogno di comunicare l'uno con l'altro. All'interno di Eucalyptus, il Cluster Controller gestisce il set up ed effettua la rimozione delle interfacce di un'istanza della rete virtuale: esso può essere configurato per impostare l'interfaccia di rete pubblica in tre modi, corrispondenti ai tre ambienti comuni che supporta: 1) La prima configurazione istruisce Eucalyptus per effettuare un attach sull'interfaccia pubblica della VM direttamente ad un bridge software Ethernet collegato alla rete della macchina fisica reale, consentendo all'amministratore di gestire le richieste DHCP delle macchine virtuali allo stesso modo in cui si gestiscono le normali richieste DHCP di componenti non appartenti ad Eucalyptus; 2) La seconda consente ad un amministratore di definire tuple di indirizzi MAC e di indirizzi IP. In questo modo, ad ogni nuova istanza creata dal sistema viene assegnata una tupla MAC/IP disponibile, che verrà rilasciata quando tale istanza sarà terminata. In questo modo, le prestazioni della comunicazione inter-vm sono quasi native quando le VM sono in esecuzione sullo stesso cluster (qualsiasi riduzione delle prestazioni è imposto dalla implementazione dell'hypervisor sottostante), ma non è previsto un isolamento in una rete inter-vm.; 3) La terza gestisce e controlla completamente le reti VM, fornendo un isolamento dal traffico VM, la definizione di regole di ingresso (firewall configurabili) tra i set logici delle VM, e l'assegnazione dinamica di indirizzi IP pubblici per le macchine virtuali nella fase di inizializzazione o a run-time. In questo modo, gli utenti possono allegarsi alle macchine virtuali, in fase di avvio, verso una "rete" che prende il nome dato dall'utente arbitrariamente. Eucalyptus assegnerà ad ogni rete un unico tag per la rete locale virtuale (VLAN), come unica sottorete IP caratterizzata da una range specificato 25

26 dall'amministratore. Dunque ogni serie di macchine virtuali, all'interno di una determinata rete, viene isolata da macchine virtuali di una rete diversa tramite il subnetting IP. Il CC agisce come router tra le varie sottoreti VM, bloccando tutto il traffico IP tra le diverse reti di macchine virtuali. L'interfaccia privata è collegata attraverso un bridge di un sistema software Ethernet completamente virtuale denominata Virtual Distributed Ethernet (VDE), un'implementazione process-level del protocollo Ethernet. Una volta che una rete VDE viene creata, si possono realizzare delle connessioni a vere e proprie reti Ethernet, mediante un'interfaccia che fornisce una comunicazione a pacchetto Ethernet dal kernel di Linux per i processi in user-space. Quando viene fatto partire un sistema Eucalyptus, esso imposta una sovrapposizione di rete VDE, composto da uno switch VDE per CC e NC ed una componente per i numerosi processi della VDE. Se non ci sono firewall esistenti sulla rete fisica, la rete VDE sarà completamente collegata, cioè che ogni singolo nodo (visto come interruttore) è connesso a tutti gli altri nodi. In fase di esecuzione di un'istanza, il responsabile del controllo del NC in una macchina virtuale crea un nuovo bridge Ethernet, collegato allo switch VDE locale, e poi configura l'istanza per fissare la sua interfaccia privata per il nuovo bridge. Dal punto di vista delle prestazioni, tale soluzione presenta una velocità quasi nativa quando due macchine virtuali, appartenenti ad una data rete all'interno di un singolo cluster, comunicano uno con l'altro. Invece, quando macchine virtuali di reti diverse hanno bisogno di effettuare una comunicazione, la soluzione impone un hop extra attraverso il CC, che agisce come un router IP. In questo modo l'utente ha la possibilità di scegliere, in base alle sue specifiche esigenze applicative, tra prestazioni native senza restrizioni di comunicazione inter-vm, oppure subire un hop in più ed avere la possibilità di limitare la comunicazione inter-vm. Quando le macchine virtuali sono distribuiti in gruppi, viene fornito un meccanismo manuale per collegare il cluster di front-end tramite un tunnel. Qui, tutti i pacchetti Ethernet VLAN da un cluster vengono messi in un tunnel verso un altro cluster tramite una connessione TCP o UDP. La perfomance di comunicazione tra 26

27 macchine virtuali può essere determinata, principalmente, dalla velocità del collegamento WAN. Tuttavia, l'impatto sulle prestazioni di questo tunnel può essere notevole se il collegamento tra i cluster abbiano delle prestazioni sufficientemente elevate. 2.7 Esperimenti effettuati su Eucalyptus Il gruppo di ricerca che si è occupato della creazione ed evoluzione di Eucalyptus, ha effettuato alcuni esperimenti [5], con l'obiettivo di illustrare le sue caratteristiche prestazionali e di osservare le proprie funzionalità sotto un determinato numero di client. Gli utenti richiedono l'accesso verso l'eucalyptus Pubblic Cloud (EPC), il quale chiede le credenziali dal CLC attraverso la pagina web di iscrizione dell'utente. Le successive richieste di assegnazione cloud sono limitati a 4 istanze, che termineranno automaticamente dopo 6 ore. Inolre grazie ad un reverse firewall viene impedito alle istanze ospitate da EPC di effettuare connessioni di rete in indirizzi di rete esterni evitando da evitare "spam-bot" hosting involontarie. Solo una zona locale EPC è disponibile come SLA accessibile dall'esterno. Gli esperimenti che verranno descritti di seguito sono stati condotti con EPC, e ne viene misurata la performance in presenza di un carico di lavoro generato dai suoi utenti (dunque in modalità non dedicata) Instance Throughput Il primo esperimento è stato ideato per misurare le prestazioni delle operazioni di controllo di un'istanza di macchina virtuale. Dato che Eucalyptus ha un'interfaccia compatibile con l'ec2 di Amazon, si possono eseguire gli stessi esperimenti sia su Eucalyptus che su EC2. L'obiettivo principale che veniva posto era quello di verificare che le operazioni effettuate in EC2 siano le stesse compiute da Eucalyptus. Anche se in maniera meno rigorosa, tale confronto può fungere da un analisi volta ad indicare se l'implementazione è patologicamente inefficiente. Infatti, durante le prime fasi di progettazione di Eucalyptus vennero rilevati dei performance bug proprio attraverso il confronto con EC2. Poiché una 27

28 delle funzioni primarie di Eucalyptus è quella di controllare l'esecuzione delle istanze su un insieme di risorse, si pensò di mettere in atto un "instance throughput", un esperimento che consiste nella misurazione dei tempi che vanno dal momento in cui un utente desidera eseguire un insieme di istanze fino a quando le istanze vengono lanciate e rese disponibili per l'uso su rete. In particolare, viene calcolato il tempo che intercorre tra una richiesta di esecuzione delle istanze e quando si può dedurre che esse siano in fase di esecuzione. Per misurare lo stato di un'istanza, viene utilizzata una riga di comando della Amazon EC2 "EC2-describeinstances", in modo da interrogare il server cloud per ottenere informazioni sulle istanze di un utente e vengono stampati i risultati all'utente attraverso un terminale : ma prima di effettuare tale operazione, bisogna prendere in considerazione un timestamp e lanciare un'istanza o un insieme di istanze con il comando "EC2-runistance". Poi, viene effettuato ripetutamente il polling del server utilizzando appunto "EC2-describeistances" fino a quando l'istanza o l'insieme di istanze non parte e non entra nello stato di esecuzione, dopodiché viene preso un altro timestamp. La differenza tra due timestamp può costituire un'utile informazione per rappresentare il numero di secondi che passano tra una richiesta di creazione di un'istanza e quella successiva, e l'utente diventa consapevole del fatto che le istanze sono disponibili per l'uso. Ogni processo è caratterizzato da quattro variabili e i tempi vengono riportati nel giro di pochi secondi: 1) La prima variabile è il tipo di macchina virtuale, in cui vengono definiti il numero di core, la quantità della RAM e lo spazio su disco assegnato. 2) La seconda variabile è l'immagine stessa dell'istanza, la quale è controllabile caricando delle copie all'interno sia di EC2 che di EPC. 3) La terza rappresenta il numero di istanze contemporaneamente richiesti, che variano da uno a otto. 4) L'ultima variabile è, infine, il sistema cloud utilizzato: o Eucalyptus o Amazon EC2. 28

29 In Figura 5 vengono mostrati i risultati dell'esperimento dell'istance throughput, e rappresenta due grafici chei esaminano la grandezza e la varianza del tempo impiegato per la creazione di istanze in EC2 e in EPC. Ciascun punto rappresenta la percentuale di prove (asse Y) di creazione di istanze, nella quantità di tempo in secondi rappresentata dal punto corrispondente sull'asse X. In entrambe le situazioni (uno e otto prove contemporanee per la creazione di istanze), se i tempi di creazione si sovrappongono, tutti i quanti di tempo misurati in EPC sono inferiori a quelli di EC2. Ad esempio, nel caso di otto istanze, in EPC nel giro di circa 24 secondi vengono svolte il 98 % delle prove simultanee per la creazione delle istanze, mentre in EC2 solo il 75 %. Nel caso di un'istanza, la differenza è ancora più evidente, con il 98 % dei processi terminati in meno di 17 secondi in EPC contro il 32 % completato in EC2. Questo risultato indica che l'attuazione di Eucalyptus è relativamente efficiente: tuttavia, non indica che EPC ha una performance superiore ad EC2. EC2 sfrutta un ampio pool di risorse e, in quanto tale, dovrebbe quasi sicuramente comportare un sovraccarico misurabile delle prestazioni su una implementazione Eucalyptus, in esecuzione su un cluster di dimensioni più piccole. Allo stesso tempo, l'attuazione di EPC sembra confrontabile con quella di un sistema che viene emulato, indicando che la sua implementazione è relativamente performante. Tale supposizione viene ancor di più supportata dalla somiglianza esistente tra le due tipologie di servizi di Cloud Computing 29

30 dal punto di vista formale. Perciò per il momento non si è in grado di andare oltre questa osservazione, né trarre qualche conclusione o un'affermazione circa la somiglianza tra i due profili dal punto di vista delle prestazioni Network Performance Il secondo esperimento è volto a studiare le caratteristiche della rete e confrontarle con l'approccio di EC2. Poiché non si conosce la configurazione di rete e l'hardware impiegati da quest'ultimo, non è possibile confrontare i due sistemi in termini di dettaglio funzionale. Bisogna tener conto delle discrepanze piuttosto grandi in termini di perfomance esistenti in modo da essere interpretate come degli indicatori di una significativa differenza di approccio che si può percepire attuando un sistema Eucalyptus. L'esperimento è stato condotto tra due istanze lanciate contemporanemante, la prima che funge da server e l'altro come client. Entrambe vengono fatte partire da un'immagine disco di distribuzione Debian "etch" di Linux e in esso è stato installato uno strumento di misura delle prestazioni di rete "iperf". Oltre a "iperf", utilizzato per esperimenti in TCP e UDP, è stato anche utilizzato il ping per misurare la latenza round-trip (andata e ritorno) di un ICMP echo. Infine, vengono stabilite le condizioni del buffer TCP e la durata dell'esperimento in modo da saturare una interconnessione di rete dedicata nell'ordine del gigabit. 30

31 Per studiare in che modo la distanza fisica tra le macchine influisce sulle prestazioni della rete, l'esperimento è stato condotto sia tra le istanze all'interno di una zona disponibile che tra istanze situati in due zone diverse. Per EC2 ciò significa che il traffico di rete viaggia da una piattaforma Amazon all'altra. I risultati dell'esperimento sono presenti in Figura 6 : viene mostrato il throughput TCP e la latenza round-trip tra le due istanze, in EC2 e in EPC, all'interno di un'unica zona disponibile e tra zone diverse. Inoltre sono rappresentate la loro media aritmetica e gli intervalli di confidenza al 95%. All'interno di EC2, si osserva che la larghezza di banda all'interno di una zona singola supera la disponibilità in larghezza di banda tra le zone di un fattore circa 2, mentre all'interno di EPC il fattore è più vicino a 10. La ragione di questa differenza sta nel fatto che con la VDE la sovrapposizione di rete privata viene eseguita quasi interamente nello spazio utente. Un altro motivo per lo scarso rendimento della soluzione di rete privata può essere riconducibile dai risultati della latenza round-trip, che mostrano una varianza significativamente maggiore nel RTT per i pacchetti ICMP che viaggiano sulla rete VDE. Simile al risultato di banda, la latenza in alcuni casi risulta essere oltre 10 volte maggiore tra le zone di EPC all'interno di una singola zona, indicando nuovamente che la rete VDE impone un significativo degrado della performance di rete. In entrambi gli esperimenti, di larghezza di banda e latenza, Eucalyptus è in grado di fornire prestazioni native di rete quando non viene utilizzata alcuna VDE: grazie a questa scelta e grazie ad uno SLA in grado di specificare una ripartizione che non dovrebbe estendere troppi cluster, un utente è in grado di garantire che la sua struttura cloud avrà una velocità nativa di interconnessione al fronte di una possibile spesa in scalabilità. 2.8 Utilizzo di Eucalyptus Per installare la piattaforma Eucalyptus su un portatile che ho a disposizione, mi sono servito di una macchina virtuale, creata dal software VMWare, che opera con Ubuntu 12.04, un sistema operativo Linux scaricabile gratuitamente ed utile allo scopo. 31

32 Inizialmente, basta andare sul sito ufficiale di Eucalyptus ( nella sezione Download e seguire passo passo le istruzioni che vengono descritte nel manuale per l'installazione della piattaforma, nella versione dedicata al sistema operativo scelto. Di seguito vengono riportate le fasi principali: 1. Scaricare le chiavi pubbliche rilasciate da Eucalyptus ed aggiungerle alla lista di chiavi presenti nel sistema attraverso il comando: apt-key add c eucalyptus-release-key.pub 2. Creare il file denominato eucalyptus.list nella cartella etc/apt/sources.list.d e scrivere una riga di comando in esso in modo da scaricare i pacchetti di Eucalyptus (i comandi seguenti vengono eseguiti in modalità amministratore del sistema perché la directory non è accessibile agli utenti generici) : cd etc/apt/sources.list.d sudo touch eucalyptus.list sudo chmod a+rwx eucalyptus.list echo deb ubuntu precise main > eucalyptus.list 3. Eseguire la stessa procedura 2 per inserire euca2ools.list, per utilizzare sia Eucalyptus che EC2 4. Aggiornare la cartella attraverso la linea di comando: sudo apt-get update 5. Installare le componenti CLC, CC, SC e Walrus: sudo apt-get install eucalyptus-cloud eucalyptus-cc eucalyptus-sc eucalyptus-walrus 6. Infine, installare il pacchetto per il NC (andrebbe fatto su ogni macchina virtuale che si serve della piattaforma Eucalyptus creata): sudo apt-get install eucalyptus-nc. Dopo aver effettuato l'installazione, per poter usufruire di Eucalyptus, è necessario effettuare una configurazione della struttura cloud, in modo che possa essere in grado di gestire le immagini delle macchine virtuali che saranno contenute in esso. 32

33 Come si configura: 1. Assicurarsi che siano installati i pacchetti per il server front-end (CLC, CC, NC) 2. Digitare nella barra degli indirizzi di un qualunque browser in modo da eseguire un primo accesso ad Eucalyptus tramite interfaccia web, con un nome utente arbitrario e con la password provvisoria admin. 3. Effettuato il primo accesso, bisogna modificare la password, configurare un indirizzo di posta elettronica di riferimento ed infine impostare un URL di archiviazione. 4. Aggiungere un Cluster (se necessario più di uno): cliccare su Configuration e poi, sotto l'intestazione Clusters, fare clic su AddCluster. 5. Aggiungere nodi al nuovo Cluster creato attraverso l'istruzione: sudo euca_conf -addmade <host_del_nodo> (localhost se il CC risiede nella stessa macchina del CLC) 6. Ultima operazione è quella di ravviare Eucalyptus, in modo da confermare le modifiche apportate alla piattaforma: sudo /etc/init.d/eucalyptus-nc restart Dopo aver effettuato con successo la configurazione e fatto ripartire Eucalyptus, esso sarà finalmente in grado di ospitare le istanze di macchine virtuali al suo interno. Nonostante tale procedura sia stata eseguita con successo dal sottoscritto, avrei voluto realmente utilizzare Eucalyptus per scopi didattici ed illustrativi, ma ciò non è stato possibile poiché non avevo a disposizione altre macchine, ed inoltre le componenti costituenti la piattaforma di Cloud Computing, per poter essere utilizzate, richiedevano un SO a 64 bit, mentre quello utilizzato è a Eucalyptus Enterprise È la versione commerciale di Eucalyptus, basata su un prodotto Open Source con l'ausilio di alcune caratteristiche che consentono di implementare una o più piattaforme IaaS private. Eucalyptus Enterprise Edition è in grado di interfacciarsi con altri sistemi 33

34 commerciali, fornisce sistemi di autenticazione e di gestione delle tariffe, ed inoltre garantisce migliori prestazioni di I/O con il supporto per lo Storage Area Network. Tra gli hypervisor utilizzabili viene aggiunto il supporto a VMware e alla sua piattaforma vsphere. I clienti possono quindi sfruttare tutte le diverse tecnologie di virtualizzazione presenti nei loro data center, coordinandole tramite una singola piattaforma gestita da questa versione di Eucalyptus in maniera completamente trasparente all utente. È possibile eseguire sistemi guest sia in Linux che Windows (incluso il servizio di remote desktop, che non è supportato nella versione Open Source). Attraverso l integrazione con i sistemi di storage SAN (Storage Area Network), utilizzabile sia per le componenti di Walrus che per lo Storage delle EBS, consente di ottenere migliori prestazioni nell'i/o, e ciò è di fondamentale importanza per i tempi di risposta all'interno di un sistema. Inoltre è presente un sistema di gestione di gruppi e account utente personalizzabile, consentendo il controllo delle risorse di calcolo, storage e di rete assegnate a qualunque utente. Associato a questo servizio è presente un gestore di quote e di rendiconto, che si occupa di conteggiare le risorse assegnate da ciascun cluster agli utenti, e questa componente inoltre fornisce anche degli strumenti di analisi generale dello stato di un sistema. 34