piattaforme di cloud computing open source: la proposta ... · introduzione 4 1.cloud computing 6...

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. N46000521

Indice

Introduzione 4

1.Cloud Computing 6

1.1 Cosa si intende per Cloud Computing? 61.2 Modelli di Cloud Computing 81.3 Tipologie di Cloud 91.4 Esigenza di Cloud Computing Open Source 10

2. Una piattaforma Open Source di Cloud Computing: Eucalyptus 12

2.1 Perché Eucalyptus 122.2 Architettura 14 2.2.1 Node Controller 15 2.2.2 Cluster Controller 16 2.2.3 Walrus 16 2.2.4 Cloud Controller 182.3 Funzionalità 202.4 Istance Control 222.5 Implementazione e Gestione degli SLA 222.6 Virtual Networking 23

2.7 Esperimenti effettuati su Eucalyptus 27 2.7.1 Istance Throughput 27 2.7.2 Network Performance 302.8 Utilizzo di Eucalyptus 312.9 Eucalyptus Enterprise 33

Conclusioni 35Bibliografia 36

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


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


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


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


(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


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


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


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

premise 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


è 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


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


Figura 4.Architettura di Eucalyptus

2.2.1 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


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).

2.2.2 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.

2.2.3 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


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


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.

2.2.4 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


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


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


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

service 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


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


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


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


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


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


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).

2.7.1 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


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


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


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.

2.7.2 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


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


Inizialmente, basta andare sul sito ufficiale di Eucalyptus (http://www.eucalyptus.com)

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 c1240596-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 http://download.eucalyptus.com/software/eucalyptus/3.1/

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

http://www.eucalyptus.com/


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 “https://front-

end:8443”, 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 32.

2.9 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


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

Conclusioni

Lo sviluppo e la crescita di Eucalyptus sono dovuti grazie alla vasta gamma di customers

che ne hanno contribuito ( come NASA, Sony, Puma, il NIST, Electronic Arts Inc. etc.) , ed

ora si sta sviluppando un ulteriore modifica alla versione 3.1, vale a dire la versione 3.2,

che aggiunge delle nuove funzionalità atte ad incrementare la sicurezza e la gestione delle

risorse, semplificare il suo utilizzo attraverso nuove interfacce ed espandere le modalità di

storage.

Sfruttare e contribuire al miglioramento di tale piattaforma di Cloud Computing, volta a

rispondere alle esigenze dei propri utenti (client o adminstrator), in un contesto sia

aziendale che di una comunità Open Source, e gli utenti stessi ne sono i fautori, credo che

sia un'ottima politica di progettazione evolutiva per questa sistema cloud. Col senno di

poi, si potrebbe dunque raggiungere l'obiettivo di potenziare questa piattaforma di Open

Cloud Computing man mano che, in futuro, aumentano gli user che richiedono servizi

all'interno di essa.

35

Bibliografia

[1] P. Mell, T. Grance. “The NIST Definition of Cloud Computing”. NIST,

Gaithersburg, Maryland, Gennaio 2011.

[2] R. Alma, P. Bodenham, M. Gambarella, I. Sigsmondi. “Il futuro delle infrastrutture

multimediali: l'open cloud computing”

[3] Cloud Computer Software from Eucalyptus – http://www.eucalyptus.com

[4] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Orbetelli, S. Soman, L. Youseff, D.

Zagorodnov. “The Eucalyptus Cloud-Computing Open-Source system”. In 9th IEEE/ACM

International Symposium on Cluster Computing and the Grid, University of California,

Santa Barbara.

[5] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Orbetelli, S. Soman, L. Youseff, D.

Zagorodnov. “Eucalyptus : A Technical Report on an Elastic Utility Computing

Architecture. Linking Your Programs to Useful Systems” . UCSB Computer Science

Technical Report Number 2008-10. University of California, Santa Barbara.

36

piattaforme di cloud computing open source: la proposta ... · introduzione 4 1.cloud computing 6...

Documents