corso di studi in ingegneria informatica · 2018. 3. 12. · facoltà di ingegneria corso di studi...
Post on 21-Feb-2021
3 Views
Preview:
TRANSCRIPT
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”
top related