Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica

Analisi delle prestazioni di una piattaforma Open Source per Cloud Computing Anno Accademico 2011-2012 Relatore: Ch.mo Prof. Domenico Cotroneo Correlatori: Ch.mo Ing. Flavio Frattini Ch.mo Ing. Vittorio Manetti

Candidato: Danilo Maccariello matr. 885/498

III

Indice Introduzione 5 Capitolo 1. Cloud Computing 8 1.1 Cos’è il Cloud Computing 8 1.2 Livelli del Cloud Computing 9 1.2.1 Modelli di Servizio Cloud Computing 11 1.2.2 Software as a Service 11 1.2.3 Platform as a Service 12 1.2.4 Infrastructure as a Service 13 1.3 Modelli di Deployment: Public, Private e Hybrid Clouds 14 Capitolo 2. CloudStack 17 2.1 Caratteristiche Generali 17 2.2 Architettura di CloudStack 18 2.3 Network Overview 19 2.3.1 Basic Network 20 2.3.2 Advanced Network 21 2.4 System VM 23 2.5 Hypervisor Kernel-Based Virtual Machine (KVM) 24 2.6 CloudStack API 26 2.6.1 Come usare le API CloudStack 26 2.7 Installazione CloudStack 28 Capitolo 3. Design of Experiment 31 3.1 Identificazione e formulazione del problema 31 3.2 Testbed 32 3.3 Scelta dei fattori e dei livelli 33 3.4 Scelta del Piano Sperimentale 34 3.5 Esecuzione sperimentale 36 3.6 Regressione lineare 38 3.7 Allocazione della variazione 39 3.8 ANOVA 41 3.9 Analisi dei risultati 43

IV

Conclusioni e sviluppi futuri 47 Appendice A. Dettagli installazione CloudStack 49 A.1 Requisiti di sistema 49 A.2 Preparazione sistema operativo 50 A.3 Installazione Management Server 51 A.4 Installazione e configurazione del DataBase 52 A.5 Preparazione NFS Shares 54 A.6 Installazione CloudStack Agent su un KVM Host 57 A.7 Provisioning Infrastructure 58 Appendice B. Derivazione partizione Sum of Square Total (SST) 62 Bibliografia 64

5

Introduzione

Nonostante la diffusione che ha avuto il Cloud Computing negli ultimi anni, darne una

definizione univoca è ancora difficile.

Fonti autorevoli considerano il termine privo di significato e sono stati fortemente contrari

al suo utilizzo [2]. Tuttavia, la mancanza di un preciso significato dell’espressione “Cloud

Computing” è significativa e ne costituisce un punto di forza, consentendo di includere in

essa sia gli aspetti tecnico-implementativi che di utilizzo.

Il Cloud Computing ha il potenziale per trasformare una grande parte del settore IT.

Infatti, si eliminano tutti i problemi delle aziende tradizionali le cui applicazioni sono da

sempre molto complicate e costose ed è necessario un intero team di esperti per installarle,

configurarle, testarle, eseguirle, proteggerle e aggiornarle. Con il Cloud Computing non si

richiede al cliente di gestire hardware e software, ma ad occuparsene è un fornitore

esperto. L'infrastruttura condivisa offre un funzionamento simile a quello dei servizi

pubblici: l'utente paga solo le funzionalità necessarie, gli aggiornamenti sono automatici e

la scalabilità verso l'alto o verso il basso è semplice.

Il calcolo scientifico richiede un numero sempre crescente di risorse per ottenere risultati

in un arco di tempo ragionevole. Negli ultimi dieci anni solo i più grandi progetti di

ricerca sono stati in grado di permettersi costosi supercomputer mentre altri progetti sono

stati costretti a optare per più economiche risorse. A tale scopo il Cloud Computing

propone un'alternativa in cui le risorse non sono più ospitate dalle strutture di calcolo del

ricercatore, ma in leasing da grandi centri dati solo quando necessario.

Il Cloud Computing si basa sui risultati di vari settori di ricerca, come la Service-Oriented-

Architecture (SOA), Grid Computing e la tecnologia di virtualizzazione. La

virtualizzazione delle risorse è al centro della maggior parte delle architetture Cloud e

6

consente un’astrazione delle risorse fisiche, costituite da server, Data Stores e network.

Ad esempio è possibile generare dinamicamente una determinata piattaforma per una

specifica applicazione solo quando è necessario.

Le applicazioni basate sul Cloud sono operative in pochi giorni e sono accessibili da un

qualsiasi browser. Ecco perché Big Vendors e Users sono sempre più interessati alla

tecnologia del Cloud Computing e, quindi, diventa cruciale la valutazione delle prestazioni

e l’identificazione dei principali problemi di performance durante l’utilizzo di questa

tecnologia.

L’obiettivo di questo lavoro di tesi è la valutazione delle prestazioni di una piattaforma

open source per il Cloud Computing di tipo Infrastructure as a Service (si veda paragrafo

1.2.4). L’installazione della piattaforma è stata eseguita presso il SESM a Giugliano, un

centro di ricerca e sviluppo precompetitivo di aziende Finmeccanica SELEX Sistemi

Integrati e SELEX Galileo, attivo nel campo della difesa, gestione del traffico aereo e

logistica di grandi apparati. La sperimentazione è avvenuta sulla piattaforma Open Source

CloudStack utilizzata da un gran numero di Service Providers e da molte aziende dato che

offre servizi di Cloud Public, servizi di Cloud Privato e Ibrido. Le istanze di CloudStack

girano su una Infrastruttura fisica utilizzando il software Open Source di virtualizzazione

KVM (si veda paragrafo 2.5).

In questo elaborato focalizzeremo la valutazione delle prestazioni sui tempi necessari per

l’acquisizione delle risorse fisiche per ottenere il deploy di una Virtual Machine.

Effettueremo la rilevazione dei tempi attraverso un software scritto in JAVA,

prepareremo attraverso un Piano Fattoriale Completo con Replicazione dei dati consistenti

sui quali eseguiremo un’analisi statistica che ci permetterà di determinare se un fattore ha

un effetto significativo o se la differenza osservata è semplicemente dovuta a variazioni

causali causate da errori di misura e parametri che non sono stati controllati.

Inserire il titolo della tesi di laurea come intestazione

7

8

Capitolo 1 Cloud Computing

In questo capitolo viene introdotto il paradigma del Cloud Computing (paragrafo 1.1) e

illustrate le classificazioni dei servizi di Cloud in base al servizio offerto (paragrafo 1.2) e

dalla prospettiva amministrativa/organizzativa (paragrafo 1.3). La prima classificazione è

orientata verso le caratteristiche funzionali, mentre la prospettiva organizzativa opera una

distinzione in base al grado di separazione tra utenti e fornitori dei servizi.

1.1 Cos’è il Cloud Computing

Anche se non c'è una definizione standard di Cloud Computing, i suoi concetti di base così

come i suoi obiettivi generali sono indiscussi: il Cloud Computing utilizza la

virtualizzazione e il Web moderno per fornire dinamicamente le risorse e servizi di vario

genere. Questi servizi dovrebbero essere disponibili in modo affidabile e scalabile in modo

che i consumatori possano utilizzarli esplicitamente su richiesta o semplicemente come e

quando richiesto. Dal punto di vista del Provider Cloud, ciò implica di solito un multi-

tenant e un uso basato su modello di fatturazione. Quindi, possiamo asserire che il Cloud

Computing utilizza risorse virtualizzate di calcolo, di Storage e tecnologie web moderne,

inoltre offre network-centric, infrastrutture IT, piattaforme e applicazioni come servizi on-

demand. Questi servizi sono fatturati su base utilizzo e questa definizione non specifica se

i servizi sono forniti da un sistema distribuito o un singolo server ad alte prestazioni, ad

esempio un mainframe. Questo è in contrasto con il Grid Computing che utilizza sempre

un sistema distribuito.

Di solito, i servizi Cloud possono anche contare su una infrastruttura distribuita, ma la loro

9

gestione è tipicamente determinata in una zona centrale (e di proprietà).

Questa è un'altra differenza tra Cloud Computing e Grid Computing in cui i nodi sono di

solito distribuiti e autonomi.

Un altro fattore determinante per il Cloud Computing è il suo impatto economico. Grazie

al suo stretto orientamento ai servizi e all'utilizzo di standard Web e Internet, il Cloud

Computing è ben posizionato per vari tipi di applicazioni.

Una definizione spesso citata del Cloud Computing è stata data dal National Institute of

Standards and Technology (NIST) negli Stati Uniti. Si specificano cinque caratteristiche

essenziali, tre modelli di servizio differenti, e quattro modelli di deployment diversi. Le

caratteristiche essenziali sono:

• On-demand self-service: i servizi possono essere forniti unilateralmente e su

richiesta per i consumatori senza richiedere l'interazione umana.

• Broad Network Access: i servizi sono disponibili in rete in tempo reale attraverso

meccanismi standard.

• Messa in comune delle risorse: le risorse sono messe in comune per consentire la

messa a disposizione di servizi a più utenti (modello multi-tenant).

• Elasticità: per il consumatore, le risorse sembrano essere illimitate.

• Servizio di misura: i servizi sfruttano una capacità di misurazione quantitativa e

qualitativa in modo che la fatturazione in base all'utilizzo e validazione della

qualità del servizio sia possibile.

1.2 Livelli del Cloud Computing

Nella descrizione di sistemi di calcolo locali (PS, workstation, server) si è soliti utilizzare

una rappresentazione a tre livelli. Più in basso, c’è il livello hardware “fisico” con i suoi

processori, chip di memoria, unità di disco, schede di rete ed altri components che

prendono il nome di Infrastruttura. In secondo luogo, nello strato intermedio, si dispone di

un sistema operativo (ad esempio Microsoft Windows) che interagisce con l'hardware e

fornisce un ambiente coerente per il software in esecuzione e in via di sviluppo

(utilizzando Visual Basic o Microsoft Access, per esempio), se lo si desidera possiamo

chiamare questo strato piattaforma. E, infine, in alto, ci sono applicazioni di terze parti che

è possibile utilizzare nel nostro lavoro e che possiamo chiamare software.

10

Figura 1.1 – Un semplice modello di piramide a tre livelli.[2]

Questo modello a tre livelli può essere applicato anche al Cloud Computing, ma ci sono

alcune differenze fondamentali:

• Le applicazioni software non sono applicazioni desktop sono web-based in modo

che possano essere utilizzate in qualsiasi browser web e su qualsiasi sistema

operativo.

• Le piattaforme sono costruite appositamente su ambienti di sviluppo software che

sono ospitati su Internet piuttosto che sul vostro computer desktop in modo che per

creare, testare e distribuire applicazioni web tutto ciò che serve è un browser web.

• Elementi di infrastruttura (server, Storage, larghezza di banda, la potenza di

elaborazione, ecc.) sono forniti da un terzo, ma è possibile accedere e utilizzare

queste risorse di calcolo come se fossero installati sulla propria rete aziendale.

11

1.2.1 Modelli di Servizio Cloud Computing

Diversi tipi di Cloud Computing vengono forniti “come un servizio” (dall’inglese as a

Service) per i consumatori, e la maggior parte di essi rientrano in una o più delle tre

categorie: Software as a Service, Platform as a Service e Infrastructure as a Service.

Capacità di calcolo sono in affitto e le risorse hardware o software non sono acquistate a

titolo definitivo da parte del consumatore.

1.2.2 Software as a Service

Applicazioni software che rispondono direttamente all'utente finale appartengono al livello

della SaaS. Questo modello consente di liberare i clienti dalla necessità di installare il

software in locale e quindi di fornire le risorse necessarie agli stessi. Vista dal punto di

vista dell'architettura Cloud, l'offerta SaaS può essere sviluppata e gestita dal fornitore

sulla base di un PaaS o IaaS che offre.

Tabella 1.1 – Software as a Service : offerte e tools

Organizzazione Servizi Cloud Descrizione

Adobe Photoshop Express Online image processing

Google Google Docs OnLine office application

Google Google Maps API Servizio per l’integrazione di mappe

e geo-information

Google OpenSocial Interfaccia di programmazione

generica per l'integrazione dei social

network nelle applicazioni

OpenIDFoundation OpenID Sistema distribuito per la gestione

dell’user identity

Microsoft Windows Live Online office applications

Salesforce

Salesforce.com

Extensible CRM system

12

Tra le offerte SaaS, si possono distinguere i servizi applicativi, le cui funzionalità si

basano principalmente su un unica, semplice applicazione, e vere e proprie, applicazioni

complesse. Gli utenti finali possono accedere direttamente ad alcuni dei servizi applicativi,

come ad esempio Google Maps.

Altri servizi sono forniti come componenti, per esempio, OpenID per l’user management o

OpenSocial per l’integrazione dei social network nelle applicazioni. Altre SaaS offerte e

tools in Tabella 1.1.

1.2.3 Platform as a Service

I servizi Cloud forniti sullo strato PaaS di solito non sono destinati ai semplici utenti, ma

piuttosto agli sviluppatori. Si tratta di ambienti di programmazione e di ambienti di

esecuzione in cui il software proprietario scritto in un linguaggio di programmazione

specifico può essere eseguito.

Esempi tipici di questi ambienti di programmazione sono Django Framework o Sun

Caroline. Si estendono linguaggi di programmazione esistenti, ad esempio, con l'aggiunta

di librerie e di classi. Ben noti esempi di ambienti di esecuzione cloud-based sono Google

App Engine, Azure di Microsoft o Smart Joyent. Google App Engine supporta la

creazione e l'esecuzione di applicazioni Web scritte in Python o Java.

Un esempio di come i servizi provenienti da diversi strati architetturali interagiscono o

sono costruiti uno sopra l'altro, è l’ambiente di programmazione AppScale, una re-

implementazione open source di Google App Engine. AppScale implementa le

funzionalità utilizzando il servizio di infrastruttura di Eucalypto.

L'intercambiabilità delle parti della pila sopra descritta, che è dovuta alla re-

implementazione in progetti open source, non solo favorisce alternative tecniche, ma

potrebbe, in alcuni casi, impedire agli utenti di diventare troppo dipendenti da un

particolare fornitore. Tabella 1.2 mostra e descrive ulteriori offerte e tools PaaS.

13

Organizzazione

Servizi Cloud Descrizione

Google App Engine Ambiente d’esecuzione scalabile

per le Web applications

Microsoft Azure Ambiente per Programmare e

Eseguire applicazioni Windows

Microsoft Windows SkyDrive Piattaforma per la sincronizzazione

dei dati tra terminali eterogenei

NetSuite SuiteFlex Business Process Development

Tool di NetSuite

Salesforce Force.com Sviluppo e gestione di Salesforce

“CRM extensions”

Sun Project Caroline Sviluppo e gestione di applicazioni

Web Distribuite

Zoho Zoho Creator Sviluppo e gestione di applicazioni

Web Database-Based

Facebook Facebook Platform Ambiente per applicazioni di

Facebook Social Network

Tabella 1.2 – Platform as a Service : offerte e tools.

1.2.4 Infrastructure as a Service

Lo strato IaaS offre agli utenti una visione astratta dell'hardware cioè computer, sistemi di

memoria di massa, reti, ecc. Questo è ottenuto fornendo un'interfaccia utente per la

gestione di un numero di risorse con il resource sun-layer (RS ). Esso consente agli utenti

di assegnare un sottoinsieme di risorse per il loro uso. Funzioni tipiche disponibili

dall'interfaccia utente includono la creazione o la rimozione di immagini del sistema

operativo, scalando capacità richieste, o definire le topologie di rete. Inoltre, l'interfaccia

14

fornisce le funzionalità necessarie per le operazioni, quali l'avvio e l'arresto di istanze del

sistema operativo.

I sistemi IaaS includono tipicamente alcune o tutte le seguenti caratteristiche:

• una scelta di macchine virtuali già pronte con preinstallati i sistemi operativi, tra

cui numerose versioni di Windows, Linux e Solaris;

• una scelta di Appliance virtuali - macchine virtuali con gruppi specifici di software

preinstallato;

• possibilità di memorizzare copie di dati particolari in luoghi diversi in tutto il

mondo per effettuare il download dei dati il più velocemente possibile;

• strumenti software per eseguire calcoli complessi con grandi array di server

virtuali che lavorano in parallelo sullo stesso problema;

• capacità di aumentare o diminuire manualmente le risorse di calcolo assegnate

mediante un browser Web con le nuove esigenze;

• la capacità di scalare automaticamente le risorse di calcolo in risposta ad aumenti e

diminuzioni di utilizzo delle applicazioni.

La capacità elastica di sistemi IaaS rende possibile il Computing on-demand, ma sono i

bassi costi e il modello pay-per-use che li rendono attraenti per le imprese. La Tabella 1.3

mostra e descrive ulteriori offerte e tools IaaS.

1.3 Modelli di Deployment: Public, Private e Hybrid Clouds

Un Public Cloud (chiamato anche “Cloud esterno”) comprende tutte le offerte di Cloud in

cui i Providers e i potenziali utenti non fanno parte della stessa unità organizzativa. I

fornitori rendono la loro nuvola accessibile al pubblico e di solito offrono un portale Web

self-service in cui gli utenti possono specificare la portata desiderata dei servizi. I servizi

sono fatturati sulla base delle risorse effettivamente utilizzate nel periodo corrispondente.

In contrasto con questo modello, i Providers e gli utilizzatori di un cosiddetto Private

Cloud (indicato anche come “Cloud interno” o “IntraCloud”) appartengono alla stessa

unità organizzativa.

La ragione principale per cui un Private Cloud sarebbe preferibile ad un Public Cloud di

solito è la sicurezza infatti trattano informazioni sensibili, come ad esempio i piani di

progettazione o i dati di produzione, che si suppone, essere meglio protetti e le misure di

15

regolamentazione, ad esempio per quanto riguarda i dati personali sulla salute, che in

questo modo possono essere meglio rispettate.

Quindi i servizi in un Private Cloud operano sulle risorse appartenenti all'organizzazione,

alcuni sviluppatori cercano di realizzare le interfacce utilizzando la stessa tecnologia del

Public Cloud.

Organizzazione Servizi Cloud Descrizione

Amazon Elastic Compute Cloud (EC2)

Virtual servers

Cloud.com CloudStack Open source IaaS

University of

Chicago

Nimbus Open source IaaS

Openflow OpenFlow Local network simulation

OpenNebula

Project

OpenNebula Open source IaaS

Eucalyptus

Systems

Eucalyptus Open source IaaS

The Openstack Cloud

Software

OpenStack Open Source IaaS

Joyent BingoDisk Mass storage

Amazon Simple Storage Service (S3) Mass storage

Tabella 1.3 – Infrastructure as a Service: offerte e tools.

L'obiettivo è assicurarsi che gli strumenti che sono disponibili nel Public Cloud possano

essere utilizzati anche nel Private Cloud, e inoltre mantenere la porta aperta per poter

scalare le applicazioni che sono state sviluppate per il Private Cloud per un uso successivo

nel Public Cloud.

Scenari in cui ci sono sia servizi del Public Cloud e sia servizi del Private Cloud, sono

16

indicati come Hybrid Cloud. Con un Hybrid Cloud, alcune funzionalità sono di solito

trasferite al Public Cloud, mentre il normale funzionamento si basa su risorse private

dell'organizzazione. Secondo le considerazioni di sicurezza di cui sopra, i cambiamenti

devono essere tali che soltanto funzioni o dati non critici vengono trasferiti.

La Figura 1.2 mostra come i tre tipi, cioè Public Cloud, Private Cloud e Hybrid Cloud

sono posizionati l'uno rispetto all'altro.

Infine con il Community Cloud abbiamo un’infrastruttura per l'uso esclusivo da parte di

una determinata comunità di consumatori, da parte delle organizzazioni che hanno

condiviso ad esempio la missione, i requisiti di sicurezza, la politica e le misure di

regolamentazione. Esso può essere di proprietà, gestito da una o più delle organizzazioni

della comunità, da un terzo o da una combinazione di essi.

Figura 1.2 – Public Cloud, Private Cloud e Hybrid Cloud

17

Capitolo 2 CloudStack

In questo capitolo descriveremo la piattaforma di Cloud Computing Open Source

CloudStack. Le caratteristiche generali della piattaforma sono descritte al paragrafo 2.1 e

l’architettura al 2.2. Sono quindi illustrati i tipi di rete che è possibile creare (Basic e

Advanced), che CloudStack mette a disposizione e descriveremo le Virtual Machine di

sistema che CloudStack utilizza per il Management interno.

Inoltre essendo una Piattaforma di tipo Cloud Computing utilizzerà un Hypervisor, quindi

alla fine del capitolo descriveremo KVM (Kernel-Based Virtual Machine) uno degli

Hypervisor supportati da CloudStack.

2.1 Caratteristiche Generali

CloudStack è una piattaforma software Open Source di tipo IaaS in gradi di creare

infrastrutture pubbliche, private e ibride. CloudStack gestisce la rete, lo Storage e i nodi di

calcolo che costituiscono un’infrastruttura Cloud.

Gli utenti tipici sono fornitori di servizi e le imprese.

Con CloudStack è possibile:

• configurare un servizio on-demand. I fornitori di servizi possono vendere istanze di

macchine virtuali, volumi di archiviazione e configurazioni di rete.

• creare un Cloud privato per l’utilizzo da parte dei dipendenti e la gestione delle

macchine virtuali come se fossero macchine fisiche.

18

CloudStack lavora con una varietà di Hypervisor (KVM, VMware, vSphere e Citrix

XenServer) ed è in grado di gestire decine di migliaia di server installati in più data center

geograficamente distribuiti. CloudStack configura automaticamente la messa in rete di

ogni macchina virtuale Guest e le impostazioni di archiviazione, gestisce internamente un

pool di Appliance virtuali per sostenere la stessa nuvola e che offrono servizi come

firewall, Routing, DHCP, accesso VPN, desktop remoto e Storage. L'ampio uso di

Appliance virtuali semplifica notevolmente l'installazione, la configurazione e la gestione

continua di una distribuzione Cloud.

Offre un Administrator WEB-interface utilizzata per il Provisioning e la gestione del

Cloud e una User WEB-interface è utilizzata per l’esecuzione di macchine virtuali e

gestione dei Templates. La User WEB-interface può essere personalizzata in modo da

riflettere il fornitore del servizio.

Inoltre fornisce API che consentono l’accesso a tutte le funzionalità di gestione

disponibili.

2.2 Architettura di CloudStack

Un’installazione di CloudStack si compone di due parti il Management Server e la Cloud

Infrastructure che viene gestita. Un’installazione base consiste di una macchina dove

verrà installato il Management Server e una macchina dove verrà installato l’Agent e

l’Hypervisor.

Figura 2.1 – Installazione base CloudStack.

19

Quando si imposta e gestisce un Cloud sono messe a disposizione delle risorse, come

Host, dispositivi di Storage, ed indirizzi IP. Il Management Server si occupa del

management di tali risorse.

Il Management Server:

• Fornisce le WEB-interface per l'amministratore e gli utenti finali.

• Fornisce le API per la piattaforma CloudStack.

• Gestisce l'assegnazione di indirizzi IP pubblici e privati.

• Gestisce Snapshot, Templates e immagini ISO, possibilmente replicandole sui

Data Center.

• Fornisce un unico punto di configurazione per il Cloud.

Come suggerisce il nome, il Management Server è lì per gestire qualcosa - una o più zone

(tipicamente, Data Center), contenenti i computer Host in cui macchine virtuali Guest

verranno eseguite. L'infrastruttura Cloud è organizzata come segue:

• Zona: In genere, una Zona è equivalente a un Data Center unico. Una Zona è

costituita da uno o più Pods e Storage secondario.

• Pod: un Pod di solito include un layer-2 switch e uno o più Cluster.

• Cluster: Un Cluster è costituito da uno o più Host e Storage Primario.

• Host: un singolo nodo di calcolo all'interno di un Cluster.

• Primary Storage: è associato ad un Cluster, e memorizza i volumi del disco per

tutte le macchine virtuali in esecuzione su Host nello stesso Cluster.

• Secondary Storage: è associato ad una Zona, memorizza i Templates, le immagini

ISO, e gli Snapshots del volume del disco.

Figura 2.2 – Organizzazione CloudStack. [4]

20

2.3 Network Overview

CloudStack offre due tipi di Network: Basic e Advanced. Basic Network prevede una rete

unica condivisa. L’isolamento è garantito attraverso i Security-Group (filtraggio indirizzi

IP). Tutti i Guests assegnati ad una zona condividono una singola rete.

L’Advanced Network offre invece la massima flessibilità ma richiede più passaggi di

configurazione.

Ciascuna Zona può essere Basic o Advanced, una volta che si effettua la scelta per una

zona questa resterà tale per l’intero ciclo di vita.

2.3.1 Basic Network

Quando la Basic Network viene utilizzata, ci può essere una sola rete fisica nella zona.

Tale rete fisica svolge tre tipi di traffico:

• Guest: quando gli utenti finali eseguono VMs, queste generano traffico guest. Ogni

Pod in una Zona di tipo Basic è un Broadcast Domain, e quindi ogni Pod ha un

diverso intervallo di indirizzi IP per la rete Guest. L’amministratore deve

configurare l’intervallo di indirizzi IP per ogni Pod.

• Management: quando le risorse interne di CloudStack comunicano tra loro, generano

Management Traffic. Ciò include la comunicazione tra Host, macchine virtuali (VM

di sistema utilizzate da CloudStack per diverse attività), e qualsiasi altro componente

che comunica direttamente con il Management Server di CloudStack. È necessario

configurare l'intervallo di indirizzi IP per le macchine virtuali di sistema.

• Storage: il traffico tra i server di Primary e Secondary Storage.

In una Basic Network, la configurazione della rete fisica è abbastanza semplice. Avremo

solo bisogno di configurare una rete ospite per trasportare il traffico generato da macchine

virtuali guest. Quando la Basic Network viene utilizzata, CloudStack assegnerà gli

indirizzi IP prendendoli dal CIDR del Pod. L’amministratore deve aggiungere un

intervallo di indirizzi IP nel Pod per tale scopo.

21

Figura 2.3 – Basic Network.

2.3.2 Advanced Network

Quando viene utilizzata l’ Advanced Network, ci possono essere più reti fisiche nella

Zona. Ogni rete fisica può portare uno o più tipi di traffico. I tipi di traffico in una

Advanced Network sono:

• Guest: quando gli utenti eseguono macchine virtuali, generano traffico ospite. Le

Guest VM comunicano tra loro attraverso una rete che può essere definita come

guest network. Questa rete può essere isolata o condivisa. In una guest network

isolata, l'amministratore deve prenotare un range di VLAN per fornire l'isolamento

per la rete. In una guest network condivisa, tutte le macchine virtuali guest

condividono una singola rete. In questo caso, è possibile fornire l'isolamento

utilizzando tecniche di isolamento di tipo Layer-3, come ad esempio i Security

Group.

• Management: quando le risorse interne comunicano tra loro generano traffico di

tipo Management. Ciò include la comunicazione tra Host, macchine virtuali (VM

di sistema utilizzate da CloudStack per diverse attività nel Cloud), e qualsiasi altro

componente che comunica direttamente con il Management Server di CloudStack.

È necessario configurare l'intervallo di indirizzi IP per le macchine virtuali di

sistema da utilizzare.

• Public: Traffico pubblico viene generato quando le macchine virtuali nel Cloud

accedono a Internet. IPs accessibili al pubblico devono essere assegnati per questo

22

scopo. Gli utenti finali possono utilizzare l'interfaccia utente CloudStack per

acquisire questi IP e per implementare NAT tra la rete ospite e la rete pubblica.

• Storage: Il traffico tra i server di Primary e Secondary Storage.

Quando viene utilizzata un’Advanced Network l'amministratore può creare reti aggiuntive

per l'utilizzo da parte degli ospiti. Queste reti possono estendersi nella zona e essere a

disposizione di tutti gli account, oppure possono essere definite nell'ambito di un unico

account, nel qual caso solo l'account denominato può creare gli ospiti che si attaccano a

queste reti.

CloudStack mette a disposizione un indirizzo IP pubblico per ogni account da utilizzare

come indirizzo IP sorgente NAT. Gli utenti possono richiedere ulteriori indirizzi IP

pubblici. L’amministratore deve configurare uno o più intervalli di indirizzi IP Pubblici

per tale scopo.

Figura 2.4 – Advanced Network.

23

2.4 System VM

CloudStack utilizza diversi tipi di macchine virtuali di sistema per eseguire le attività nel

Cloud. Tuttavia, l'amministratore dovrebbe essere a conoscenza di queste e del loro ruolo

per contribuire a problemi di debug. Le System VM sono:

Ø Console Proxy VM: è un tipo di macchina virtuale di sistema che ha il ruolo di

presentare tramite interfaccia utente web il Desktop remoto di una Guest VM.

Dall’User Interface cliccando sull'icona di una console viene visualizzata una nuova

finestra. Il codice AJAX viene scaricato da quella finestra dall'indirizzo IP pubblico

della Console Proxy VM. Infatti c'è esattamente un indirizzo IP pubblico assegnato

alla Console Proxy VM e quindi la Console Proxy si connette alla porta VNC della

VM richiesta. Quindi non c’è alcuna necessità di abilitare VNC all’interno di una

Guest VM.

Ø Virtual Router: è uno dei fornitori di servizi di uso più frequente in CloudStack.

L'utente finale non ha accesso diretto al router virtuale. Gli utenti possono eseguire

il ping del router virtuale e intraprendere azioni che incidono su di esso (ad esempio

impostando il Port Forwarding), ma gli utenti non hanno un accesso di tipo SSH.

Non esiste un meccanismo per l'amministratore per accedere al router virtuale, ma

possono essere riavviati dagli amministratori, questo interromperà l'accesso del

pubblico alla rete e ad altri servizi.

Un test fondamentale per il debug dei problemi di rete è quello di tentare di eseguire

il ping verso il router virtuale da una macchina virtuale Guest.

Ø Secondary Storage VM: fornisce un processo in Background che si occupa di una

serie di attività di archiviazione secondarie: il download di un nuovo template per

una Zona, la copia di template tra le zone, e lo snapshot backup.

L'amministratore può accedere alla Secondary Storage VM, se necessario.

24

2.5 Hypervisor Kernel-Based Virtual Machine (KVM)

Prima di aggiungere un Host alla configurazione CloudStack, è necessario installare un

Hypervisor sull'Host. CloudStack è in grado di gestire gli Host che eseguono macchine

virtuali su una varietà di Hypervisor tra cui KVM.

La virtualizzazione ha fatto molti progressi negli ultimi dieci anni, soprattutto a causa

dello sviluppo di una miriade di Open-Source Hypervisor. Questo progresso ha quasi

eliminato le barriere tra sistemi operativi e ha aumentato notevolmente l'utilizzo di server

potenti, portando un beneficio immediato alle aziende. Due degli approcci più comuni per

software di virtualizzazione sono Full Virtualization e Paravirtualization.

In Full-Virtualization, un livello, comunemente chiamato Hypervisor o Monitor della

macchina virtuale, esiste tra i sistemi operativi virtualizzati e l'Hardware. Questo strato fa

un Multiplexing delle risorse di sistema tra le concorrenti istanze del sistema operativo.

La Paravirtualization è diversa in quanto l'Hypervisor funziona in modo più cooperativo,

perché ogni sistema operativo Guest è consapevole del fatto che è in esecuzione in un

ambiente virtualizzato.

Entrambi gli approcci hanno vantaggi e svantaggi. Il vantaggio principale del metodo di

Paravirtualization è che permette la virtualizzazione più veloce possibile ed è basata su

Software, a costo di non supportare sistemi operativi proprietari. Approcci di Full-

Virtualization, ovviamente, non hanno questa limitazione, tuttavia, sistemi di Full-

Virtualization sono pezzi molto complessi di software.

VMware, una soluzione di virtualizzazione commerciale, è un esempio di Full-

Virtualization. La Paravirtualization è fornita da Xen, User-Mode Linux (UML) e altri.

Con l'introduzione di virtualizzazione basata su Hardware, queste linee sono sfocate. Con

l'avvento di Intel VT e AMD SVM, la scrittura di un Hypervisor è diventata molto più

facile, ed è ora possibile godere dei vantaggi della Full-Virtualization, mantenendo la

complessità dell'Hypervisor al minimo.

KVM è un relativamente nuovo e semplice, ma potente, Virtualization Engine, che ha

trovato la sua strada nel Kernel di Linux. Poiché utilizza la virtualizzazione basata su

Hardware non richiede modifiche ai sistemi operativi Guest, e, quindi, è in grado di

supportare qualsiasi piattaforma, dato che viene distribuito su un processore supportato.

Gli sviluppatori KVM hanno messo a punto un metodo che ha trasformato il Kernel di

Linux in un Hypervisor. Ciò è stato possibile attraverso un metodo minimamente invasivo

25

attraverso lo sviluppo di KVM come modulo del Kernel. L'integrazione della funzionalità

di Hypervisor in un Linux Kernel come modulo caricabile è in grado di semplificare la

gestione e migliorare le prestazioni di ambienti virtualizzati.

Secondo questo modello, ogni macchina virtuale è un processo regolare Linux.

Tradizionalmente, un normale processo di Linux ha due modalità di esecuzione: Kernel e

utente. La modalità utente è la modalità di default per le applicazioni, e un'applicazione va

in modalità Kernel quando si richiede un servizio dal Kernel, come la scrittura sul disco

rigido. KVM aggiunge una terza modalità, la modalità Guest. Processi in modalità Guest

sono processi che vengono eseguiti all'interno della macchina virtuale. La modalità Guest,

proprio come la modalità normale (non virtualizzata), ha il suo Kernel e il suo spazio

utente.

KVM fa uso di virtualizzazione Hardware per virtualizzare gli stati del processore, e la

gestione della memoria per la macchina virtuale viene gestita all'interno del Kernel.

L’I/O nella versione corrente viene gestito nello spazio utente, principalmente attraverso

QEMU.

2.6 CloudStack API

Le API CloudStack sono API di basso livello che sono state utilizzate per implementare

l’interfaccia utente.

La maggior parte delle chiamate API CloudStack sono asincrone e la chiamata ritornerà

immediatamente un identificativo del processo (ID). Questo ID può essere utilizzato per

determinare in seguito lo stato del lavoro.

Le API sono basate su architettura REST e consentono agli sviluppatori di creare soluzioni

per la gestione e integrazioni di sistemi. Supportano Post/Get e restituiscono risposte sia in

XML che in JSON.

Le API di CloudStack supportano tre tipi di accesso:

• Root Admin. L’accesso a tutte le funzionalità del Cloud tra cui sia la gestione delle

risorse virtuali che fisiche.

• Domain Admin. L’accesso alle sole risorse virtuali del Cloud che appartengono al

dominio dell’amministratore.

• User. L’accesso alle sole funzioni che consentono la gestione di istanze virtuali

dell’utente come Storage e Network.

26

2.6.1 Come usare le API CloudStack

Descriveremo come usare le API di CloudStack con riferimento particolare all’API

deployVirtualMachine che crea e automaticamente avvia una Virtual Machine con un

Service Offering, un Disk Offering ed un Template.

La richiesta risulterà composta dai seguenti campi:

Ø CloudPlatform API URL: entry point del servizio WEB API.

Ø Command: Il comando del servizio Web che tu vuoi eseguire.

Ø Parameters: Si specificano i parametri per il comando.

Nel nostro caso avremo una GETRequest del tipo:

1. http://ManagementSeverIP:8080/client/api

2. ?command=deployVirtualMachine

3. &serviceOfferingId=1

4. &diskOfferingId=1

5. &templateId=2

6. &zoneId=4

7. &hostId=5

8. &apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ

9. &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D

La prima riga è la CloudPlatform API URL. La seconda fa riferimento al Command che si

vuole eseguire, nel nostro caso stiamo lanciando un Deploy di una Virtual Machine,

preceduto da un (?) che serve a separarlo dalla CloudPlatform API URL. Le righe 3-7

rappresentano i Parameters per il dato Command. Ogni singolo Parameter è formato dalla

coppia (campo=valore) ed è preceduto da una (&). Alla riga 8 abbiamo la user API Key

che identifica univocamente l’account mentre alla riga 9 la signature che serve ad

autenticare l’user account per l’utilizzo delle API.

27

Per ottenere la Signature occorre avere una API Key e una Secret Key fornita

dall’amministratore della CloudPlatform. Per capire meglio come otteniamo la Signature

dividiamo la nostra richiesta in:

• Base URL: URL del Management Server.

http://ManagementServerIP:8080

• API Path: Path all’API Servlet che processa la richiesta. /client/api?

• Command String: comprende i Parameters e la API Key che identifica l’account.

La signature si ottiene:

1. Per ogni coppia campo-valore nel Command String effettuare una URL encode dato

che faranno parte di una GETRequest-HTTP.

2. Rendere minuscolo ciascun carattere della Command String e ordinare

alfabeticamente i campi in essa contenuti.

3. Con la Command String ottenuta eseguire HMAC SHA-1 hashing algorithm con la

Secret Key associata all’account e fornita dall’amministratore di CloudStack ed

effettuare sulla stringa ottenuta un Base 64 encoding.

Inviata la GetRequest, si ottiene una risposta in formato XML che salveremo in un file e

da cui tramite un parser otterremo il valore del tag JobId che identifica univocamente il

processo di deploy VM.

Con JobId, è possibile controllare periodicamente lo stato del processo di deploy

chiamando l’API queryAsyncJobResult. L’API restituirà nel tag JobStatus tre possibili

valori interi:

Ø 0 - Processo in corso. Quindi continueremo a interrogare periodicamente per

eventuali cambi di stato.

Ø 1 - Processo completato con successo.

Ø 2 – Processo non completato con successo e avremo un tag con il codice di errore.

28

2.7 Installazione CloudStack

L’installazione è stata eseguita presso il SESM a Giugliano, un centro di ricerca e sviluppo

precompetitivo di aziende Finmeccanica SELEX Sistemi Integrati e SELEX Galileo,

attivo nel campo della difesa, gestione del traffico aereo e logistica di grandi apparati.

La macchina su cui verrà eseguito il Management Server sarà utilizzata anche per fornire

Storage primario e secondario tramite NFS. Ciascun Host deve soddisfare determinati

requisiti di sistema (Appendice A.1). Il Sistema Operativo scelto è CentOS 6, ed è stato

opportunamente preparato ad ospitare il Management Server (Appandice A.2).

Effettueremo la procedura per l’installazione del Management Server e di MySQL sulla

stesso server, dopo aver scarico il Management Server di CloudStack sull’Host in cui

verrà eseguito (dettagli Appendice A.3).

CloudStack ha bisogno di un posto per ospitare Storage primario e secondario. Entrambi

possono essere NFS Shares, quindi imposteremo le NFS Shares prima di aggiungere

l'archiviazione di CloudStack. In genere si utilizza un server separato per NFS Shares, ma

è possibile utilizzare il nodo di Management Server anche come server NFS (Appendice

A.5).

Salveremo nel Secondary Storage un Template che viene utilizzato per le System VM di

CloudStack. Tenendo presente che il mio Hypervisor è KVM, quindi sul Management

Server lanceremo:

# /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary -u http://download.cloud.com/templates/acton/acton-systemvm- 02062012.qcow2.bz2 -h kvm -F

Prima di poter aggiungere un host al Cloud, è necessario installare un software

Hypervisor. KVM è incluso con una varietà di sistemi operativi basati su Linux compreso

CentOS da noi scelto. All'interno di un cluster, tutti gli host KVM devono avere in

esecuzione lo stesso sistema operativo. Ogni host KVM deve avere il CloudStack Agent

installato su di esso.

Di default, CloudStack utilizzerà il dispositivo che viene utilizzato per la route predefinita.

Questo dispositivo viene collegato ad un Bridge creato da CloudStack. Visto che il nostro

29

sistema dispone di più schede di rete creeremo un bridge e collegheremo la scheda di rete

prescelta al bridge.

L'Host Agent deve essere impostato per l'utilizzo di NTP. Tutti gli Host nello stesso Pod

devono avere lo stesso tempo. Per la configurazione di NTP seguiremo la stessa procedura

eseguita sul Management Server (Appendice A.2).

Dopo che il Management Server è installato e in esecuzione, è necessario aggiungere le

risorse di calcolo. Per fare questo bisogna accedere all’interfaccia utente di CloudStack e

eseguire una procedura per il Provisioning dell’infrastruttura.

Alla fine della procedura avremo la struttura in Figura 2.5. Abbiamo Scelto l’Advanced

Zone Configuration (Figura 2.6) quindi dopo aver effettuato il login sulla UI di

CloudStack e aver scelto Advanced nella sezione Add Zone eseguiremo tutti passi

descritti in Appendice A.7.

Figura 2.5 – Conceptual View of My Structure

30

Figura 2.6 – Configurazione Advanced

31

Capitolo 3 Design of Experiment

L’obiettivo di questo lavoro di tesi è la valutazione di una piattaforma di Cloud dal punto

di vista dei tempi necessari per eseguire le operazioni volte a fornire il servizio.

In altri termini, non ci preoccuperemo di analizzare i tempi per eseguire applicazioni

utente (come fatto in altri lavori quali [8][9]), bensì del tempo che la piattaforma open

source sotto esame impiega per elaborare una richiesta, individuare le risorse disponibili

per soddisfare la richiesta e, quindi, per rendere disponibile la risorsa al richiedente.

Tale studio è effettuato relativamente alla piattaforma CloudStack (Capitolo 2).

Per effettuare tali valutazioni, gli esperimenti sono stati pianificati secondo l’approccio

tipico del Design of Experiment (DoE) [7]. Il DoE è uno strumento estremamente potente

e trasversale, copre vari campi di indagine tecnico-scientifica, e comprende tecniche di

manipolazione dei risultati sperimentali nate per condurre ad un miglioramento del

sistema. Con il DoE cercheremo di dare un approccio statistico per ricavare conclusioni

sensate dai dati, dato che questi sono soggetti ad errori, quindi la metodologia statistica

rappresenta nel nostro caso di studio l’unico approccio oggettivo all’analisi.

3.1 Identificazione e formulazione del problema

Analizzeremo il Deployment Time di una Virtual Machine relativo alla piattaforma Open

Source CloudStack.

Il Deployment Time è il tempo che intercorre tra t0 e t3 (Figura 3.1), che indicano

rispettivamente l’istante “Arrivo Richiesta Utente” e l’istante finale “Risorsa Disponibile

32

all’Utente”. Il Deployment Time comprende oltre al tempo di provisioning (Provisioning

Time, t3-t2) anche il tempo di scheduling (Scheduling Time, t2-t1) e il tempo di

elaborazione (Elaboration Time, t1-t0).

Il tempo di elaborazione è il tempo che impiega il Management Server per elaborare la

richiesta ed intercorre tra l’istante t0 “Arrivo Richiesta Utente” e l’istante t1 “Inizio

Scheduling”.

Il tempo di scheduling è il tempo che impiega il Management Server per scegliere l’Agent

con le risorse fisiche sufficienti a ospitare la VM Guest ed intercorre tra l’istante t1 “Inizio

Scheduling” e l’istante t2 “Arrivo Richiesta Deploy all’Agent”.

Mentre il tempo di provisioning è il tempo che intercorre tra l’istante t2 “Arrivo Richiesta

Deploy all’Agent” e l’istante t3 “Risorsa Disponibile all’Utente”.

Figura 3.1 – Deployment Time.

3.2 Testbed

L’installazione è stata eseguita presso il SESM a Giugliano, un centro di ricerca e sviluppo

precompetitivo di aziende Finmeccanica SELEX Sistemi Integrati e SELEX Galileo,

attivo nel campo della difesa, gestione del traffico aereo e logistica di grandi apparati.

La sperimentazione è avvenuta sulla piattaforma Open Source CloudStack installata su

alcuni nodi del cluster del SESM. I nodi a nostra disposizione sono 6, quindi la nostra

infrastruttura avrà un Management Server e cinque Agent.

Ø Management Server: il nodo che ospiterà il Management Server ha una CPU Intel

Core2 Duo 6300 1,86GHZ, 2GiB di RAM, un Hard Disk da 500GiB e come

sistema operativo CentOS 6 64 bit.

Ø Agent: i restanti cinque nodi hanno tutti 2 CPU QuadCore con una frequenza di

2,5 GHz, 8GiB di RAM, un HD da 32 GiB, come sistema operativo CentOS 6 64

bit e hypervisor KVM.

33

Ø Primary Storage: che è associato ad un cluster e memorizza i volumi del disco per

tutte le macchine virtuali in esecuzione su host nello stesso cluster. Sarà

configurato sul Management Server.

Ø Secondary Storage: è associato ad una Zona, memorizza i templates, le immagini

ISO, e gli snapshots del volume del disco. Sarà configurato sul Management

Server.

Abbiamo effettuato un’installazione con un unico Management Server dato che abbiamo

solo 5 Agent da gestire e come scenario di Networking l’Advanced per avere una

maggiore flessibilità nella definizione delle reti Guest.

3.3 Scelta dei fattori e dei livelli

La scelta dei fattori e dei livelli ad essi associati è uno step fondamentale del Design of

Experiment. Nel nostro caso prenderemo in considerazione quattro fattori a ciascuno dei

quali sono associati due livelli.

Ø Service Offering – forniscono una scelta della CPU, numero di CPU, dimensione

della RAM e altre scelte. CloudStack mette a disposizione due Service Offering di

default Small Service Offering (CPU da 500MHz e 512Mb di RAM) e Medium

Service Offering (CPU da 1GHz e 1Gb di RAM) che noi prenderemo come livelli da

associare a questo fattore.

Ø Data Storage – in CloudStack abbiamo un Primary Storage che è associato con un

cluster e memorizza i Data Storage per tutte le macchine virtuali in esecuzione su

host del cluster. I due livelli associati a questo fattore saranno la presenza o meno

del Data Storage.

Ø VMs – molto importante e sicuramente da prendere in considerazione è anche il

numero di VM che sono già in esecuzione sull’Agent scelto per il deployment della

VM. I due livelli associati a questo fattore saranno agent senza VM in esecuzione (0

VM) e agent con 5 VM in esecuzione (5 VMs).  

34

Ø Scheduling –   con questo fattore si prende in considerazione lo Scheduling

dell’Agent sul quale fare il deploy della VM. I due livelli associati a questo fattore

saranno la presenza o meno dello Scheduling.  

Fattori Livelli

Service Offering Small Medium

Data Storage No Si

VMs 0 VM 5 VM

Scheduling No Si

Tabella 3.1 – Fattori e Livelli.

3.4 Scelta del Piano Sperimentale

Come piano sperimentale si è scelto il Piano Fattoriale Completo con Replicazione. Sono

quindi considerate tutte le possibili combinazioni dei fattori a tutti i livelli, così da tenere

conto delle interazioni tra essi. Ripetendo ciascun esperimento r volte otterremo 24r

osservazioni. Questa scelta è motivata dal fatto che tramite il Piano Fattoriale Completo

non è possibile quantificare l’errore dell’esperimento (errore associato alla combinazione

fattore-livello), cosa invece possibile replicando l’esperimento.

Introduciamo quattro variabili per indicare fattori e livelli: xA , xB , xC e xD :

Indicate con yij le riposte degli esperimenti, si ottiene il seguente modello di regressione

lineare:

35

yij = q0 + qAxA + qBxB + qCxC + qDxD + qABxAxB + qACxAxC + qADxAxD + qBCxBxC + qBDxBxD + qCDxCxD + qABCxAxBxC + qACDxAxCxD + qABDxAxBxD + qBCDxBxCxD + qABCDxAxBxCxD + eij

[3.1]

La corrispondenza tra fattori, livelli e risposte è mostrata in Tabella 3.1. Inoltre la [3.1] ci

mostra che il parametro q non è altro che la combinazione lineare delle risposte, questi

parametri sono detti contrasti, dividendo le q per 16 ottengo gli effetti di ciascun fattore e

delle interazioni tra essi.

La e rappresenta l’errore ed è dato dalla differenza tra la risposta media e il valore

misurato nell’esperimento i-esimo alla j-esima replicazione ( yij ). La somma degli errori

deve essere zero. Questo modello assume che gli effetti dei fattori, le loro interazioni e gli

errori sono additivi.

Num I Service

Offering

(A)

Data

Storage

(B)

VMs

(C)

Scheduling

(D)

AB AC AD BC BD CD ABC ACD ABD BCD ABCD

1 1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1 -1 -1 1

2 1 1 -1 -1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1

3 1 -1 1 -1 -1 -1 1 1 -1 -1 1 1 -1 1 1 -1

4 1 1 1 -1 -1 1 -1 -1 -1 -1 1 -1 1 -1 1 1

5 1 -1 -1 1 -1 1 -1 1 1 1 -1 1 1 -1 1 -1

6 1 1 -1 1 -1 -1 1 -1 1 1 -1 -1 -1 1 1 1

7 1 -1 1 1 -1 -1 -1 1 -1 -1 -1 -1 1 1 -1 1

8 1 1 1 1 -1 1 1 -1 -1 -1 -1 1 -1 -1 -1 -1

9 1 -1 -1 -1 1 1 1 -1 -1 -1 -1 -1 1 1 1 -1

10 1 1 -1 -1 1 -1 -1 1 -1 -1 -1 1 -1 -1 1 1

11 1 -1 1 -1 1 -1 1 -1 1 1 -1 1 1 -1 -1 1

12 1 1 1 -1 1 1 -1 1 1 1 -1 -1 -1 1 -1 -1

13 1 -1 -1 1 1 1 -1 -1 -1 -1 1 1 -1 1 -1 1

14 1 1 -1 1 1 -1 1 1 -1 -1 1 -1 1 -1 -1 -1

15 1 -1 1 1 1 -1 -1 -1 1 1 1 -1 -1 -1 1 -1

Tabella 3.2 – Piano Fattoriale Completo con Replicazione

36

Per un Piano Fattoriale Completo con Replicazione 24 r abbiamo la tabella segno Tabella

3.2. La prima colonna della Tabella 3.2 viene etichettata “I” e consiste di tutti 1. Le

colonne successive A, B, C, D contengono tutte le combinazioni possibili di -1 e 1.

La colonna AB è il prodotto delle colonne A e B e allo stesso modo otteniamo le restanti

colonne (AC, AD,…,ABCD).

La Tabella 3.2 sarà completata con la colonna Media (Y) (Tabella 3.4), dove elenchiamo

le medie aritmetiche (essendo un Piano Fattoriale Completo con Replicazione) delle

replicazioni per ciascuna osservazione e la colonna Var (Varianza) che fornisce una

misura di quando siano vari i valori delle acquisizioni dei tempi.

3.5 Esecuzione sperimentale

Per la rilevazione dei tempi sfrutteremo le API di CloudStack in particolare l’API

deployVirtualMachine (vedi Paragrafo 2.6.1), scrivendo un’applicazione in Java che

sottometterà una richiesta GET-http con un associato Command e determinati Parameters

e attenderà una risposta in XML.

Avviando un timer nel momento in cui la GetRequest all’API deployVirtualMachine sarà

inviata e stoppandolo quando il tag jobStatus (vedi paragrafo 2.6.1) ci informerà che il

processo è completato otterremo il Deployment Time.

Il Provisionig Time verrà isolato aggiungendo opportuni parametri alla richiesta in modo

da rendere insignificante il tempo di elaborazione e specificando o meno hostid (agent di

destinazione per il deploy della VM) in modo da considerare o meno il tempo di

scheduling.

In Tabella 3.3 abbiamo la corrispondenza tra fattori-livelli del DoE e campo-valore dei

Parameters della GetRequest-http.

I tempi sono stati valutati seguendo il Piano Fattoriale Completo con Replicazioni e i

risultati degli esperimenti sono visibili in Tabella 3.4 nelle colonne Media e Var che

indicano rispettivamente la media aritmetica e la varianza che fornisce una misura di

quando siano vari i valori delle acquisizioni dei tempi.

37

Fattori/Campi Livelli/Valori Service Offering/ serviceOfferinId Small/ID Small Medium/ID Medium

Data Storage/ diskOfferingId No/Non specifico ID

Disk Offering

Si/Specifico ID Disk

Offering

VMs 0 VMs 5 VMs

Scheduling / hostId No/Specifico ID Host Si/Non specifico ID Host

Tabella 3.3 – Corrispondenza Fattori-Livelli/Campi-Valori

# I Service

Offering

(A)

Data

Storage

(B)

VMs

(C)

Scheduling

(D)

A

B

A

C

A

D

B

C

B

D

C

D

A

B

C

A

C

D

A

B

D

B

C

D

A

B

C

D

Media

(Y)

Var

1 1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1 -1 -1 1 107,9441 0,1068

2 1 1 -1 -1 -1 -1 -1 -1 1 1 1 1 1 1 -1 -1 108,2159 0,1142

3 1 -1 1 -1 -1 -1 1 1 -1 -1 1 1 -1 1 1 -1 109,5562 0,4384

4 1 1 1 -1 -1 1 -1 -1 -1 -1 1 -1 1 -1 1 1 1098694 0,3336

5 1 -1 -1 1 -1 1 -1 1 1 1 -1 1 1 -1 1 -1 16,8016 0,1328

6 1 1 -1 1 -1 -1 1 -1 1 1 -1 -1 -1 1 1 1 16,8870 0,1523

7 1 -1 1 1 -1 -1 -1 1 -1 -1 -1 -1 1 1 -1 1 17,3560 0,0911

8 1 1 1 1 -1 1 1 -1 -1 -1 -1 1 -1 -1 -1 -1 17,5356 0,0854

9 1 -1 -1 -1 1 1 1 -1 -1 -1 -1 -1 1 1 1 -1 108,9044 0,3451

10 1 1 -1 -1 1 -1 -1 1 -1 -1 -1 1 -1 -1 1 1 109,5033 0,2001

11 1 -1 1 -1 1 -1 1 -1 1 1 -1 1 1 -1 -1 1 109,9153 0,2740

12 1 1 1 -1 1 1 -1 1 1 1 -1 -1 -1 1 -1 -1 110,2613 0,3983

13 1 -1 -1 1 1 1 -1 -1 -1 -1 1 1 -1 1 -1 1 16,9264 0,1066

14 1 1 -1 1 1 -1 1 1 -1 -1 1 -1 1 -1 -1 -1 16,9895 0,0728

15 1 -1 1 1 1 -1 -1 -1 1 1 1 -1 -1 -1 1 -1 17,4061 0,1515

16 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17,5714 0,1260

Tabella 3.4 –Risultati (in secondi) del Piano Fattoriale Completo Con Replicazione

38

3.6 Regressione lineare

Un piano sperimentale 24r (r=10) è stato utilizzato perché abbiamo 4 fattori, 2 livelli e

ciascuna delle 16 osservazioni è ripetuta r volte.

Il modello di regressione lineare è dato dall’equazione [3.1], dove e è l’errore sperimentale

e le q sono i contrasti. Per analizzare un piano sperimentale 24r si utilizza la tabella segno

illustrata in Tabella 3.4, alla quale sono stati aggiunti i risultati delle osservazioni. In

Tabella 3.4 abbiamo le colonne segno l’elemento di ciascuna colonna è moltiplicato per il

corrispondente Media (Y) e poi sommati come in [3.2], dividendo poi il risultato ottenuto

per 16 otteniamo gli effetti.

A titolo esemplificativo, la seguente equazione [3.2] mostra il calcolo di qA :

qA = −mediaY1+mediaY2 −mediaY3 +mediaY4 −mediaY5 +mediaY6 −mediaY7 +mediaY8 −

mediaY9 +mediaY10 −mediaY11+mediaY12 −mediaY13 +mediaY14 −mediaY15 +mediaY16 [3.2]

Gli altri effetti si ottengono in modo analogo.

La e in [3.1] rappresenta l’errore ed è dato dalla differenza tra la risposta media e il valore

misurato nell’esperimento i-esimo alla j-esima replicazione ( yij ).

eij = yij −mediaYi [3.3]

La somma degli errori deve essere zero.

La Somma dei Quadrati degli Errori (SSE), che può essere utilizzata per stimare la

varianza degli errori, è data da:

SSE = eij2

j=1

r

∑i=1

24

∑ = 22.5604 [3.4]

39

3.7 Allocazione della variazione

L’allocazione della variazione consente di determinare la percentuale di variazione

espressa da ciascun fattore, cosa utile per decidere se un fattore ha un impatto significativo

sulla risposta.

La Variazione Totale o Somma Totale dei Quadrati è data dall’equazione [3.5]. La

mediaYtot denota la media di tutte le repliche di tutti gli esperimenti.

La SST può essere divisa in più parti [3.6] (derivazione equazione [3.6] in Appendice B)

dove ogni SS (Somma dei Quadrati) sono le variazioni dei fattori e delle interazioni tra

essi mentre SSE è la variazione attribuita agli errori.

Nell’equazione [3.7] (derivazione Appendice B) la SS0 rappresenta la Somma dei

Quadrati delle medie ed è ottenuta elevando al quadrato entrambi i termini dell'equazione

[B.2] mentre SSY è la somma dei quadrati di tutte le risposte yij .

SST = (yiji, j∑ −mediaYtot )

2 [3.5]

SST = 24rqA2 + 24rqB + 2

4rqC...+ eij2

i, j∑ = SSA+ SSB+ SSC...+ SSE [3.6]

SSY = SS0+ SSA+ SSB+ SSC +...SSABCD+ SSE [3.7]

Avendo 16 osservazioni e 10 replicazioni, le Somme dei Quadrati sono calcolate come

segue:

SS0 =160*q20 =160*63,22772=639639.1691

SSA =160*q2A =160*0.12652=2.5594

SSB =160*q2B =160*0.45622=33.2980

SSC =160*q2C =160*(-46.0435)2 = 339201.0373

SSD =160*0.20702 = 6.8551

SSAB =160*(-0.0009)2 = 0.0001

SSAC =160*(-0.0648)2 = 0.6714

SSAD =160*0.02022 = 0.0653

40

SSBC =160*(-0.1731)2 = 4.7954

SSBD =160*(-0.1024)2 =1.6772

SSCD =160*(-0.1678)2 = 4.5075

SSABC =160*0.02552 = 0.1040

SSACD =160*(-0.0248)2 = 0.0982

SSABD =160*(-0.0179)2 = 0.0512

SSBCD =160*0.08472 =1.1482

SSABCD =160*0.01892 = 0.0571 SSY = SS0+ SSA+ SSB+ SSC +...SSABCD+ SSE = 978918.6548

SST = SSY − SS0 = 978918.6548-639639.1691=339279.4857

SSE = SSY − SS0− SSA− SSB− SSC −...− SSABCD = 22.5604

Noto SST, l’equazione [3.6] consente di determinare il grado di influenza sulle variazioni

dei fattori e delle interazioni tra essi.

SSASST

=2.5594

339279.4857= 7.5437E-06

SSBSST

=33.2980

339279.4857= 9.8143E-05

SSCSST

=339201.0373339279.4857

= 0.9998

SSDSST

=6.8551

339279.4857= 2.0205E-05

SSABSST

=0.0001

339279.4857= 4.1777E-10

SSACSST

=0.6714

339279.4857=1.9788E-06

41

SSADSST

=0.0653

339279.4857=1.9240E-07

SSBCSST

=4.7954

339279.4857=1.4134E-05

SSBDSST

=1.6772

339279.4857= 4.9434E-06

SSCDSST

=4.5075

339279.4857=1.3285E-05

SSABCSST

=0.1040

339279.4857= 3.0640E-07

SSACDSST

=0.0982

339279.4857= 2.8947E-07

SSABDSST

=0.0512

339279.4857=1.5089E-07

SSBCDSST

=1.1482

339279.4857= 3.3841E-06

SSABCDSST

=0.0571

339279.4857=1.6816E-07

SSESST

=22.5604

339279.4857= 6.6495E-05

3.8 ANOVA

L’allocazione della variazione nonostante sia molto utile nella pratica è un approccio

informale secondo il quale qualsiasi fattore che spiega un'alta percentuale di variazione è

42

considerato importante. Per determinare se un fattore e la sua interazione con gli altri

fattori abbia significanza statistica sulla varianza è possibile utilizzare il metodo ANOVA

(Analysis of Variance).

ANOVA prende in considerazione le somme dei quadrati (SSA, SSB, SSE ecc.)

precedentemente calcolate e può essere utilizzato per controllare se SSA è

significativamente maggiore di SSE.

A ciascuna somma dei quadrari è associato un grado di libertà (GdL) corrispondente al

numero di valori indipendenti necessari per calcolarle. Per ogni fattore i GdL sono pari al

numero di livelli-1, per le interazioni è dato dal prodotto dei GdL di ciascun fattore

(Esempio: GdLA= 2-1, GdLB= 2-1, GdLAB= 1x1 = 1) mentre per l’errore GdLE = 24(r-

1).

Consideriamo i rapporti:

[3.14]

[3.15]

che esprimono rispettivamente il quadrato medio di A (Mean Square of A) e il quadrato

medio dell’errore E (Mean Square of E). Si considera ora il rapporto esiste, per

ogni combinazione di gradi di libertà del numeratore (GdLA=

GdLB=GdLC=GdLD=GdLAB=…=GdLABCD=1) e del denominatore (GdLE =

= 16*9=144), e per ogni livello di attendibilità (α), una particolare curva statistica

(distribuzione di F[α , GdLA, GdLE]) che ci consente di stabilire se il rapporto ottenuto è

superiore ad un certo valore soglia (e noi dobbiamo scegliere il livello di attendibilità che

vogliamo tenere in considerazione) per cui il fattore considerato viene assunto

significativo per la variazione.

La Tabella 3.5 mostra i risultati del metodo ANOVA.

MSA = SSAGdLA

MSE = SSEGdLE

MSAMSE

24(r −1)

43

Somma quadrati GdL %variazione Mean Square F-Calcolata F-Tab

SST=339279,4857 159 100%

SSA=2.5594 1 0.0007% MSA=2.5594 MSA/MSE=16.3365 6.8142

SSB=33.2980 1 0.01% MSB=33.2980% MSB/MSE=212.5364

SSC=339201.0373 1 99.98% MSC=339201.0373 MSC/MSE=2165072.0887

SSD=6.8551 1 0.002% MSD=6.8551 MSD/MSE=43.7550

SSAB=0.0001 1 0.00000004% MSAB=0.0001 MSAB/MSE=0.0009

SSAC=0.6714 1 0.0002 MSAC=0.6714 MSAC/MSE=4.2852

SSAD=0.0653 1 0.00002% MSAD=0.0653 MSAD/MSE=0.4167

SSBC=4.7954 1 0.001% MSBC=4.7954 MSBC/MSE/30.6087

SSBD=1.6772 1 0.0005% MSBD=1.6772 MSBD/MSE=10.7054

SSCD=4.5075 1 0.001% MSCD=4.5075 MSCD/MSE=28.7704

SSABC=0.1040 1 0.00003% MSABC=0.1040 MSABC/MSE=0.6635

SSACD=0.0982 1 0.00003% MSACD=0.0982 MSACD/MSE=0.6269

SSABD=0.0512 1 0.00002% MSABD=0.0512 MSABD/MSE=0.3267

SSBCD=1.1482 1 0.0003% MSBCD=1.1482 MSBCD/MSE=7.3286

SSABCD=0.0570 1 0.00002% MSABCD=0.0570 MSABCD/MSE=0.3642

Tabella 3.5 – Risultati ANOVA

3.9 Analisi dei risultati

L’allocazione della variazione ha consentito di separare gli effetti dei vari fattori che

possono influenzare le prestazioni e di determinare se un fattore ha un effetto significativo,

44

ovvero se la differenza osservata è semplicemente dovuta a variazioni casuali causate da

errori di misura o da parametri che non sono stati controllati.

Dai risultati ottenuti si osserva che il numero di Virtual Machine presenti sull’host fisico

sul quale verrà effettuato il deploy di una nuova istanza di VM influenza per il 99.98% la

variazione. È evidente in Tabella 3.4 come i tempi subiscano una notevole riduzione nel

momento in cui si effettua il deploy su Host Fisici dove già sono presenti VM Running.

Dalla Tabella 3.5 possiamo osservare le percentuali di variazioni dei restanti fattori e

relative interazioni notando che sono confrontabili con la variazione di errore.

Quindi, possiamo concludere che l’Allocazione della Variazione non ci permette di capire

se i restanti fattori e le relative interazioni influenzino effettivamente i tempi osservati.

Figura 3.2 – Risultato Allocazione Variazione

L’allocazione della variazione, nonostante sia molto utile nella pratica, è un approccio

informale, secondo il quale qualsiasi fattore che spiega un'alta percentuale di variazione è

considerato importante. Per distinguere quest’importanza dal significato statistico

analizzeremo i risultati del metodo ANOVA in Tabella 3.5 confrontando il valore critico

ottenuto con un livello di attendibilità del 99% “F-Tab”, che nel nostro caso di studio è

uguale per tutti i fattori e interazioni (vedi Paragrafo 3.8), con “F-Calcolata”.

Anche dall’analisi dei risultati di ANOVA, il numero di macchine virtuali (fattore C) già

instanziate risulta essere il fattore che maggiormente influenza il tempo di deploy (F-

Calcolata=2165072.0887 >> F-Tab=6.8142). Questo può essere spiegato dal fatto che

CloudStack nel momento in cui effettua il deploy della prima VM crea anche una Virtual

45

Network, precedentemente configurata dall’amministratore, che consente il multi-tenancy

su una singola rete fisica. Inoltre nella creazione della Virtual Network è compreso il

deploy di una System VM (il Virtual Router Figura 2.5).

Procedendo con l’analisi osserviamo che il secondo, il terzo e il quarto fattore sono

rispettivamente il fattore riguardante la presenza o meno del Data Storage (fattore B “Data

Storage” F-Calcolata=212.5360 > F-Tab=6.8142), il fattore riguardante lo Scheduling

(fattore D “Scheduling” F-Calcolata=43.7550 > F-Tab=6.8142) e il fattore riguardante il

numero core, frequenza processore, RAM (fattore A “Service Offering” F-

Calcolata=16.3365 > F-Tab=6.8142). Questi fattori hanno un F-Calcolata nell’ordine

delle decine quindi anche influenzando significativamente i tempi che stiamo

considerando il loro effetto è imparagonabile con quello del fattore C “VMs” (Figura

3.3). Molto probabilmente avremo avuto delle F-Calcolate di ordine maggiore se avessimo

avuto una infrastruttura con più Agent in modo da aumentare il tempo di scheduling

oppure due Service Offering con differenze più significative riguardo il numero di core,

frequenza processore e RAM.

Figura 3.3 – Risultati ANOVA

Inoltre avendo nella nostra analisi considerato un Piano Fattoriale Completo con

Replicazione abbiamo considerato tutte le possibili combinazioni dei fattori a tutti i

livelli, e abbiamo tenuto conto delle interazioni tra essi.

46

Dai risultati di ANOVA osserviamo che la maggior parte delle interazioni hanno una F-

Calcolata < F-Tab.

Tuttavia si può sottolineare che c’è un’interazione significativa tra la richiesta di storage

ed il numero di macchine virtuali (Interazione B-C, F-Calcolata= 30.6087 > F-Tab=

6.8142) e tra il numero di macchine virtuali e l’esecuzione dello scheduling (Interazione

C-D, F-Calcolata = 28.77047 > F-Tab = 6.8142).

Insomma il fattore B “Data Storage” e il fattore D “Scheduling” influiscono poco, ma il

loro effetto è più evidente quando ci sono già VM Running. Comportamento che ci

aspettavamo sia perché le risorse fisiche a disposizione sono di meno, sia perché i decimi

di secondo necessari per allocare un Data Storage o eseguire lo Scheduling hanno un peso

maggiore sui 16 secondi di deploy quando ci sono VMs Running, ma poco peso sui 108

secondi dell’altro caso.

I restanti casi non hanno significato statistico, quindi non hanno un’influenza sui tempi

che stiamo considerando e le differenze osservate su questi sono semplicemente dovute a

variazioni casuali causate da errori di misura o da parametri che non sono stati

opportunamente controllati o non controllati affatto, dato che il Design of Experiment qui

introdotto comprende solo una piccola quantità di parametri riguardanti una Infrastructure

as a Service.

Parametro non opportunamente controllato potrebbe essere l’Elaboration Time che

abbiamo cercato di rendere insignificante specificando più Parameters possibili nella

GetRequest (vedi paragrafo 3.5), ma dubitiamo date le caratteristiche Hardware del

Management Server che questo parametro possa aver influenzato significativamente i

tempi da noi osservati.

Mentre i parametri non controllati potrebbero essere il tasso di perdita di dati dovuto alle

Virtual Network oppure il Throughput che misura i dati trasferiti attraverso la connessione

di rete per un periodo di tempo che ci può mostrare la differenza di banda tra la

piattaforma e i server web tradizionali o ancora il Round-Trip time che occorre ai dati

oggetto del trattamento per raggiungere l’host e ritornare all’utente.

47

Conclusioni e sviluppi futuri

In questo lavoro di tesi sono stati illustrati la progettazione, l’esecuzione e l’analisi dei

risultati di una campagna sperimentale basata sull’approccio ingegneristico come descritto

in [7].

L’analisi dei tempi necessari per eseguire le operazioni volte a fornire il servizio

(Deployment Time, Elaboration Time, Scheduling Time e Provisioning Time vedi

peragrafo 3.1) ha mostrato che la presenza di altre macchine virtuali su un server è

fondamentale e questo è spiegato dal fatto che CloudStack nel momento in cui effettua il

deploy della prima VM crea anche una Virtual Network con relativo Virtual Router

(System VM), precedentemente configurata dall’amministratore, che consente il multi-

tenancy su una singola rete fisica.

Questo però non è un limite, dato che è poco probabile che una piattaforma IaaS non abbia

macchine virtuali Running, quindi sicuramente i casi in cui dovremo aspettare 16 secondi

di deploy quando ci sono VMs running, saranno molto superiori rispetto ai casi di 108

secondi.

I restanti fattori oggetti dello studio quali fattore B “Data Storage”, fattore D “Scheduling”

e fattore A “Service Offering” non hanno un’influenza paragonabile a quella del fattore C

“VMs” avendo sui tempi considerati un effetto dell’ordine dei decimi di secondo, effetto

che per quanto riguarda il fattore B “Data Storage” e il fattore D “Scheduling” sembra

evidenziarsi quando nel Cloud già sono presenti Virtual Machine Running.

Si potrebbe pensare di evidenziare gli effetti sui tempi osservati considerando “Service

Offering” con differenze più significative riguardo il numero di core, frequenza processore

e RAM oppure aumentando il numero degli Agent facenti parte dell’IaaS o ancora avendo

in questo DoE considerato solo una minima parte dei parametri appartenenti all’IaaS si

potrebbero considerare altri parametri.

48

Ad esempio, potremmo pensare che il Deployment Time sia influenzato anche dal tasso di

perdita di dati dovuto alle Virtual Network, dalla differenza di banda tra la piattaforma e i

server web tradizionali, o ancora dal Round-Trip time che occorre ai dati oggetto del

trattamento per raggiungere l’host e ritornare all’utente.

Si può quindi estendere questo lavoro inserendo nuovi fattori tra i parametri non

considerati, nonché considerando una Performance Analysis di ulteriori servizi offerti da

CloudStack come il Deploy di una Virtual Network.

Inoltre, estendere la valutazione ad altre piattaforme open source per il Cloud Computing

consentirebbe di confrontare i risultati ottenuti e determinare come scelte di design e

implementazione influiscono sul tempo necessario alla fornitura del servizio.

49

Appendice A Dettagli installazione CloudStack

A.1 Requisiti di sistema

La macchina dove sarà installato il Management Server deve soddisfare i seguenti

requisiti.

• Sistema Operativo: RHEL 6.2+64-bit, CentOS 6.2+64-bit (anche RHEL e CentOS

5.4-5.x 64-bit), Ubuntu 10.04 LTS.

• CPU a 64 bit x86 (risultati più core in prestazioni migliori).

• 2 GB di memoria (4 GB consigliati).

• 250 GB di HD (500 GB consigliati).

• Almeno 1 scheda di rete.

• Indirizzo IP allocato staticamente.

• Nome di dominio completo come restituito dal comando hostname

Mentre ciascun Host deve avere i seguenti requisiti:

• Deve essere a 64 bit e deve supportare HVM (Intel-VT o AMD-V attivato).

• CPU a 64 bit x86 (più core prestazioni migliori).

• Virtualizzazione Supporto hardware necessario.

• 4 GB di memoria.

• 30 GB di disco locale.

• Almeno 1 scheda di rete.

• Indirizzo IP assegnato staticamente.

50

• Hypervisor aggiornato all’ultima versione.

• Quando si distribuisce CloudStack, l'hypervisor di accoglienza non deve avere

macchine virtuali già in esecuzione.

A.2 Preparazione Sistema Operativo

Il Sistema Operativo scelto è CentOS 6, ed è stato opportunamente preparato ad ospitare il

Management Server:

1. Accediamo sistema operativo come root.

2. Verifichiamo la presenza di un nome host valido.

# hostname –fqdn

3. Impostiamo SELinux per avere permessi di default.

a) Verifichiamo se SELinux è installato sul tuo computer. In caso contrario, è

possibile passare al punto 4. In CentOS, SELinux viene installato e attivato di

default. Verifichiamo questo con:

# rpm -qa | grep selinux

b) Impostiamo la variabile SELINUX in /etc/selinux/config in "permissive".

Questo assicura che l'impostazione permissive viene mantenuta dopo un

riavvio del sistema. In CentOS:

# vi /etc/selinux/config

c) Quindi impostiamo SELinux a permissive immediatamente, senza dover

riavviare il sistema. In CentOS:

# setenforce permissive

51

4. Ci assicuriamo che il server di gestione abbia l'accesso a Internet.

# ping www.google.com

5. Attiviamo NTP per la sincronizzazione del tempo.

a) Installiamo NTP

# yum install ntp

b) Modifichiamo il file di configurazione NTP per puntare al server NTP.

# vi /etc/ntp.conf

È possibile utilizzare i server NTP fornite da Citrix:

0.xenserver.pool.ntp.org

1.xenserver.pool.ntp.org 2.xenserver.pool.ntp.org 3.xenserver.pool.ntp.org

c) Riavviamo il client NTP.

# service ntpd restart

d) Ci assicuriamo che NTP si attivi automaticamente al riavvio. # chkconfig ntpd on

A.3 Installazione Management Server

Di seguito i dettagli dell’installazione del Management Server:

1. Installiamo i pacchetti CloudStack. Abbiamo un file sotto forma di "CloudStack-

VERSION-N-OSVERSION.tar.gz". Decomprimiamo il file e quindi eseguiamo lo

script install.sh al suo interno:

52

# tar xzf CloudStack-VERSION-N-OSVERSION.tar.gz # cd CloudStack-VERSION-N-OSVERSION # ./install.sh

2. Scegliamo M per installare il software del Management Server.

3. Quando l'installazione è terminata, eseguiamo i seguenti comandi per avviare i

servizi essenziali.

# service rpcbind start # service nfs start # chkconfig nfs on # chkconfig rpcbind on

4. Continuiamo con l’Installazione e configurazione del database.

A.4 Installazione e configurazione del DataBase

Di seguito i dettagli dell’installazione e configurazione del DataBase MySQL:

1. Sullo stesso computer in cui è installato il server di gestione CloudStack,

rieseguiamo install.sh.

# ./install.sh

2. Scegliamo D per installare il server MySQL dal repo della distribuzione.

3. Modifichiamo la configurazione di MySQL e inseriamo le seguenti righe nella

sezione [mysqld]. È possibile inserire queste righe al di sotto della linea di datadir. Il

parametro max_connections deve essere impostato a 350 moltiplicato per il numero

di Management Server. La nostra installazione presuppone un Management Server.

innodb_rollback_on_timeout=1

innodb_lock_wait_timeout=600

53

max_connections=350

log-bin=mysql-bin

binlog-format = 'ROW'

4. Riavviamo il servizio di MySQL, quindi richiamo MySQL come utente root. Su

CentOS:

# service mysqld restart

# mysql -u root

5. Best Practice: Su CentOS, MySQL non imposta una password di root di default. E’

fortemente raccomandato di impostare una password di root come precauzione di

sicurezza. Eseguiamo i seguenti comandi per immettere la nostra password di root.

mysql> SET PASSWORD = PASSWORD('password');

D'ora in poi, avviamo MySQL con mysql-p in modo che ci chiederà la password.

6. Per concedere i privilegi di accesso agli utenti remoti, effettueremo le seguenti

operazioni.

a) Eseguiamo i seguenti comandi dal prompt di MySQL: mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH

GRANT OPTION;

mysql> exit

b) Riavviamo il servizio MySQL # service mysqld restart

c) Apriamo la porta del server MySQL (3306) nel firewall per consentire ai client

remoti di connettersi. # iptables -I INPUT -p tcp --dport 3306 -j ACCEPT

d) Modifichiamo il file /etc/sysconfig/iptables e aggiungiamo la seguente riga

all'inizio dell’INPUT chain

54

-A INPUT -p tcp --dport 3306 -j ACCEPT

7. Impostiamo il database. Il comando seguente crea l'utente cloud sul database.

• In dbpassword, specifichiamo la password da assegnare all'utente cloud. Si

può scegliere di non fornire la password.

• Nel deploy-as, specifichiamo la username e password dell'utente che sta

effettuando il deploying. Nel comando seguente, effettueremo il deploying

come root e creo l'utente cloud.

#cloud-setup-databases cloud:<password>@localhost --

deploy-as=root:<password>

8. Ora che il database è impostato, completiamo la configurazione del sistema

operativo per il Management Server. Questo comando creerà iptables, sudoers, e

avvierà il Management Server.

# cloud-setup-management

9. Preparazione NFS Shares

A.5 Preparazione NFS Shares

Dettagli preparazione NFS Shares:

1. Sull'host del Management Server, creiamo due directory che utilizzeremo per lo

storage primario e secondario. Per esempio:

# mkdir -p /export/primary

# mkdir -p /export/secondary

2. Per configurare le nuove directory come NFS exports, modifichiamo /etc/export.

55

# vi /etc/exports

Inseriamo la seguente linea:

/export *(rw,async,no_root_squash)

3. Export la /export directory.

# exportfs –a

4. Modifichiamo il file /etc/sysconfig/nfs file e decommentiamo le seguenti righe.

LOCKD_TCPPORT=32803

LOCKD_UDPPORT=32769

MOUNTD_PORT=892

RQUOTAD_PORT=875

STATD_PORT=662

STATD_OUTGOING_PORT=2020

5. Modifichiamo il file /etc/sysconfig/iptables e aggiungiamo le seguenti righe all'inizio

della INPUT chain.

-A INPUT -m state --state NEW -p udp --dport 111 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 111 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 2049 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 32803 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 32769 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 892 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 892 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 875 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 875 -j ACCEPT

-A INPUT -m state --state NEW -p tcp --dport 662 -j ACCEPT

-A INPUT -m state --state NEW -p udp --dport 662 -j ACCEPT

56

6. Eseguiamo i seguenti comandi.

# service iptables restart

# service iptables save

7. Dato che tra client e server viene utilizzata la comunicazione NFS v4, aggiungiamo

il dominio al file /etc/idmapd.conf sia sul hypervisor host che sul Management

Server.

# vi /etc/idmapd.conf

Rimuoviamo il carattere # all'inizio della riga Domain in idmapd.conf e sostituiamo

il valore nel file con il tuo dominio.

Domain = cloudstack.com

8. Riavviamo l'host di Management Server.

Due NFS Shares chiamate /export/primary e /export/secondary sono ora configurate.

9. Eseguiamo il test per essere sicuri che i passaggi precedenti hanno avuto successo.

a) Log In nell’Hypervisor Host.

b) Ci assicuriamo che NFS e rpcbind sono in esecuzione.

# service rpcbind start

# service nfs start

# chkconfig nfs on

# chkconfig rpcbind on

# reboot

c) Accediamo nuovamente all’hypervisor host e cerchiamo di montare le

directory /export:

# mkdir /primarymount

57

# mount -t nfs <management-server name>:/export/primary

/primarymount

# umount /primarymount

# mkdir /secondarymount

# mount -t nfs <management-server-

name>:/export/secondary /secondarymount

# umount /secondarymount

A.6 Installazione CloudStack Agent su un KVM Host

Installiamo il CloudStack Agent su ciascun host con Sistema Operativo CentOS, che ha

già incluso l’Hypervisor KVM, utilizzando la procedura seguente:

1. Accediamo all'host KVM come utente root.

2. Verifichiamo la presenza di un nome host valido.

# hostname –fqdn

3. Rimuoviamo qemu-kvm. CloudStack fornisce una versione modificata.

# yum erase qemu-kvm

4. Installiamo i pacchetti CloudStack. Abbiamo un file sotto forma di "CloudStack-

VERSION-N-OSVERSION.tar.gz". Decomprimiamo il file e quindi eseguiamo lo

script install.sh al suo interno:

# tar xzf CloudStack-VERSION-N-OSVERSION.tar.gz

# cd CloudStack-VERSION-N-OSVERSION

# ./install.sh

5. Scegliamo "A" per installare il software Agent.

58

6. Quando l'installazione dell'agente è finita, eseguo il login all'host come root ed

eseguiamo i seguenti comandi per avviare i servizi essenziali (i comandi potrebbero

essere diversi a seconda del sistema operativo):

# service rpcbind start

# service nfs start

# chkconfig nfs on

# chkconfig rpcbind on

7. Sull'host KVM, modifichiamo il file /etc/libvirt/qemu.conf e ci assicuriamo che la

riga "vnc_listen = 0.0.0.0" non sia commentata. Rimuoviamo il commento dalla riga

e riavviamo /etc/init.d/libvirtd.

# vi /etc/libvirt/qemu.conf

# /etc/init.d/libvirtd restart

8. Se tra client e server viene utilizzata la comunicazione NFS v4, aggiungiamo il

dominio al file /etc/idmapd.conf come già fatto sull'host del Management Server.

# vi /etc/idmapd.conf

A.7 Provisioning Infrastruttura

1. Verrà chiesto di inserire i seguenti dettagli.

• Name. Un nome per la zona.

• DNS 1 e 2. Si tratta di server DNS per l'utilizzo da macchine virtuali guest nella

zona. Questi server DNS saranno accessibili dalla Public Network che si

configurerà più avanti. Gli indirizzi IP pubblici per la zona devono avere una

route verso il server DNS inserito qui.

• Internal DNS 1 e Internal DNS 2. Questi sono i server DNS per l'utilizzo da

parte delle System VM nella zona (si tratta di macchine virtuali utilizzate da

CloudStack come router, Proxy virtuali e per l’archiviazione secondaria).

Questi server DNS saranno accessibili tramite l'interfaccia di rete associata al

59

Management Traffic delle System VM. Gli indirizzi IP privati da dare ai Pods

devono avere una route verso il server DNS interno inserito qui.

• Guest CIDR. Questo è il CIDR che descrive gli indirizzi IP in uso nelle reti

virtuali Guest in questa zona. Per esempio, nel nostro caso 10.1.1.0/24. Buona

pratica è impostare CIDRs diversi per diverse zone. In questo modo sarà più

facile configurare il VPN tra reti in zone diverse.

• Hypervisor. Scegliere l'hypervisor per il primo cluster nella zona. È possibile

aggiungere i cluster con diversi hypervisor più tardi, dopo aver aggiunto la

zona.

• Public. Una Public Zone è a disposizione di tutti gli utenti. Una zona che non è

pubblica sarà assegnata a un particolare dominio. Solo agli utenti di tale

dominio sarà permesso di creare macchine virtuali Guest in questa zona.

2. Scegliere quali tipi di traffico verranno gestiti da ciascuna rete fisica. I tipi di

traffico sono Management, Public, Guest, e Storage.

3. Configurare il range di IP per il Public Internet Traffic. Se lo si desidera, è

possibile ripetere questo passaggio per aggiungere altri intervalli di indirizzi IP

pubblici.

• Gateway. Il gateway in uso per questi indirizzi IP nel nostro caso

192.168.80.1.

• Netmask. Associata con questo IP range 255.255.255.0.

• VLAN. La VLAN che verrà utilizzato per il traffico pubblico nel nostro caso

(Untagged).

• Start IP/End IP. Un intervallo di indirizzi IP che si presume siano accessibili

da Internet e sarà assegnato per l'accesso alle reti Guest. Nel nostro caso non

avendo a disposizione veri Indirizzi Pubblici useremo come tali un range di

cinque indirizzi della subnet 192.168.80.x (192.168.80.121-125).

60

4. In una nuova zona, CloudStack aggiunge il primo Pod per noi. È sempre possibile

aggiungerne altri in un secondo momento. Per configurare il Pod, immetteremo

quanto segue:

• Pod Name. Un nome per il Pod.

• Reserved System Gayeway. Il gateway per gli hosts nel Pod nel nostro caso

192.168.80.1, infatti gli host fisici stanno sulla subnet 192.168.80.X.

• Reserved System Netmask. Nel nostro caso 255.255.255.0

• Start/End Reserved System IP. Il range IP della rete di Management che

CloudStack utilizza per gestire le VM di sistema, nel nostro caso

192.168.80.131-135.

5. Specifichiamo un range di VLAN per il Guest Traffic.

6. In un nuovo pod, CloudStack aggiunge il primo cluster per noi. È sempre possibile

aggiungere altri cluster in un secondo momento. Per configurare il primo cluster

abbiamo inserito:

• Hypervisor. Immettere il tipo di Hypervisor che tutti gli Host del Cluster

devono utilizzare, nel nostro caso KVM.

• Cluster Name. Il nome del Cluster.

7. In un nuovo cluster, CloudStack aggiunge il primo Host per noi. È sempre possibile

aggiungere altri in un secondo momento. Per inserire un Host specifico:

• Host Name. L’indirizzo IP dell’Host.

• Username. La username di root.

• Password. La password per la username specificata.

8. In un nuovo cluster, CloudStack aggiunge il primo server di Primary Storage per

noi. È sempre possibile aggiungere più server in seguito. Per aggiungere un

Primary Storage bisogna specificare:

61

• Name. Un nome per il Primary Storage.

• Protocol. Nel nostro caso avendo scelto NFS dovremo inserire:

Ø Server. IP dell’ Host dove è stato configurato NFS nel nostro caso l’IP

del Management Server.

Ø Path. Exported Path del server NFS.

9. In una nuova zona, CloudStack aggiunge il primo Secondary Storage per noi. Ma

se ne possono aggiungere altri in un secondo momento. Per il Secondary Storage

siamo vincolati a scegliere come protocollo NFS, per un corretto inserimento

specifichiamo:

• NFS Server. Indirizzo IP dell’Host dove è stato configurato NFS nel nostro

caso l’IP del Management Server.

• Path. Exported Path del server NFS.

62

Appendice B Derivazione partizione Sum of Square Total (SST)

Il modello per 22 r design è:

yij = q0 + qAxAi + qBxBi + qCxCi + qDxDi + qABxAixBi + qACxAixCi + qADxAixDi + qBCxBixCi + qBDxBixDi + qCDxCixDi + qABCxAixBixCi +qACDxAixCixDi + qABDxAixBixDi + qBCDxBixCixDi + qABCDxAixBixCixDi + eij

[B.1]

Ora riscriviamo la [B.1] come:

yij = q0i, j∑

i, j∑ + qAxAi +

i, j∑ qBxBi +...+

i, j∑ qABCDxAi

i, j∑ xBixCixDi + eij

i, j∑ [B.2]

Dove con l’indice i ci si riferisce alle osservazioni mentre con l’indice j alle replicazioni.

Inoltre dato che i termini della [B.2] dove compaiono le x sono tutti nulli e sapendo che la

somma degli errori è anch’essa nulla otteniamo:

yij = q0 = 24

i, j∑

i, j∑ rq0 [B.3]

Quindi la mediaYtot sarà:

63

mediaYtot =124r

yiji, j∑ =

124r

24rq0 = q0 [B.4]

La Variazione Totale (SST) sarà:

SST = (yij −mediaYtot )i, j∑

2= yij

2

i, j∑ − mediaYtot

2

i, j∑ = yij

2

i, j∑ − q0

2

i, j∑ = SSY − SS0 [B.5]

Dove SS0 rappresenta la Somma dei Quadrati delle medie, elevando al quadrato entrambi

i termini dell'equazione (B.2) e ignorando il prodotto incrociato dei termini (perché

aggiungerebbe zero), si ha:

yij2 = q0

2

i, j∑

i, j∑ + qA

2xAi2 +

i, j∑ qB

2xBi2 +...+

i, j∑ q2ABCDx

2Ai

i, j∑ x2Bix

2Cix

2Di + e2ij

i, j∑ [B.6]

I termini di questa equazione corrispondono a diverse Somme dei Quadrati:

SSY = SS0+ SSA+ SSB+ SSC +...SSABCD+ SSE [B.7]

SST = SSY − SS0 = SSA+ SSB+ SSC +...SSABCD+ SSE [B.8]

64

Bibliografia [1] Dr Mark I Williams “A Quick Start Guide to Cloud Computing” 2010

[2] Baun, Kunze, Nimis, Taim “Cloud Computing: Web-Based Dinamin IT” Services” 2011

[3] Buyya, Broberg, Goscinski “Cloud Computing Principles and Paradigms” 2011

[4] “CloudStack Administration Guide” Version 3.0.2

[5] http://www.linux-kvm.org

[6] “CloudStack Install Guide” Version 3.0.2

[7] Raj Jain “Art of Computer Systems Performance Analysis Techniques For

Experimental Design Measurements Simulation And Modeling”

[8] University of Innsbruck, Austria & Delft University of Technology, The Netherlands “A

Performance Analysis of EC2 Cloud Computing Services for Scientific Computing”

[9] A paper written under the guidance of Prof. Raj Jain “Performance Analysis based

on two Leading Cloud Computing Platforms: Google App Engine and Amazon Web

Service”