Virtualization Benchmarking

Transcript

Università degli Studi di Salerno
Laurea Magistrale in Informatica
Corso di Sistemi Operativi II
Virtualization Benchmarking
Professore
Giuseppe Cattaneo
Studenti
Ada Mancuso
Francesco Raia
Carmine Spagnuolo
Anno Accademico 2011-2012
Chapter 1
Abstract
La tecnologia di virtualizzazione venne sviluppata per la prima volta negli
anni ’60 per partizionare l’hardware dei mainframe di grandi dimensioni e
ottimizzarne l’utilizzo.
Gli attuali computer basati sull’architettura x86 ripropongono gli stessi problemi di rigidità e sottoutilizzo che caratterizzavano i mainframe negli anni ’60.
Per risolvere le innumerevoli problematiche associate alla piattaforma x86,
tra cui il sottoutilizzo delle risorse, negli anni ’90 VMware ha inventato la
Full Virtualization, affrontando molti ostacoli e diventando leader mondiale
nel campo della virtualizzazione Enterprise al fianco di Xen Hypervisor, che
invece risolve differentemente i problemi legati alla virtualizzazione introducendo un nuovo approccio, la Paravirtualization.
Dopo aver descritto in maniera coincisa ed esauriente le due tecniche e le
differenze che intercorrono tra esse, il nostro lavoro mira a misurare e confrontare le performance dei due hypervisor sulla base di un lavoro precedentemente effettuato su Xen Hypervisor e VMware Workstation. Più precisamente i test saranno effettuati su una singola macchina configurata in tre
differenti modi:
• VMware ESXi 3.5 che esegue CentOs 6.1
• XEN 4.1 Hypervisor hosted su Ubuntu Server 12.4 che esegue CentOs
6.1
• VMware Player 3.1.6 hosted su Ubuntu Server 12.4 che esegue CentOs
6.1
i
CHAPTER 1. ABSTRACT
ii
Grazie a questi test verrà effettuato il confronto fra tre tecniche di virtualizzazione, rispettivamente Full Virtualization, Paravirtualization, e Hosted
Full Virtualization. Nel seguito di questo lavoro verrano spiegate le tecniche
e le problematiche legate ad ognuna di essa.
La configurazione hardware scelta mira a valutare i sistemi di virtualizzazione
in uno scenario quanto più reale possibile, come ad esempio la consolidazione
di più server di una piccola azienda in un unico server per motivazioni
legate al risparmio energetico. L’omogeneità dell’hardware ospitante e della
macchina virtuale ospitata ci garantiscono che i risultati dei test dipendano
unicamente dalle performance degli hypervisor, scopo del nostro lavoro.
Contents
1 Abstract
i
2 Introduzione
2.1 Inquadramento Storico . . . . . . . . . . . . . . . . . . .
2.2 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Vantaggi e Svantaggi . . . . . . . . . . . . . . . . . . . .
2.3.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Svantaggi . . . . . . . . . . . . . . . . . . . . . .
2.4 Tassonomia . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Terminologia . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Sfide della virtualizzazione . . . . . . . . . . . . . . . . .
2.6.1 Virtualizzazione della CPU . . . . . . . . . . . . .
2.7 Hardware-assisted Virtualization . . . . . . . . . . . . . .
2.7.1 Problemi legati alla virtualizzazione software-only
2.7.2 Intel Virtualization Technology (Intel VT) . . . .
2.7.3 AMD Virtualization Technology (AMD-V) . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3
6
7
7
8
9
9
10
11
13
13
14
15
3 Full Virtualization e VMware
3.1 Introduzione . . . . . . . . . . . . . . .
3.2 Full Virtualization . . . . . . . . . . .
3.2.1 Virtualizzazione della CPU . . .
3.2.2 Virtualizzazione della memoria
3.3 Virtualizzazione dei dispositivi di I/O .
3.4 VMware vSphere . . . . . . . . . . . .
3.4.1 ESX e ESXi . . . . . . . . . . .
3.5 VMware Player . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
21
23
24
25
28
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
CONTENTS
4 Para Virtualization e Xen
4.1 Introduzione . . . . . . . . . . . . . . . .
4.2 La Filosofia di Xen . . . . . . . . . . . .
4.3 L’architettura di Xen . . . . . . . . . . .
4.3.1 Domain 0(privileged) . . . . . . .
4.3.2 Domain U(nprivileged) . . . . . .
4.3.3 Configurazioni dell’hypervisor . .
4.4 Comunicazione tra domini . . . . . . . .
4.5 Gestione della Memoria . . . . . . . . . .
4.5.1 Flusso di Gestione . . . . . . . .
4.5.2 Split Driver Monitor: I/O RIngs .
4.6 Virtualizzazione della CPU . . . . . . . .
4.7 Virtual Machine Scheduling . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Testing
5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Installazione VMware ESXi 3.5 . . . . . . .
5.1.2 Installazione Xen 4.1, Ubuntu hosted . . . .
5.1.3 Installazione VMware Player,Ubuntu hosted
5.2 Test . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Roy Longbottom’s PC Benchmark . . . . .
5.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Relative Performance . . . . . . . . . . . . .
5.3.2 Cuncurrent Performance . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
36
36
39
40
43
44
45
45
47
48
.
.
.
.
.
.
.
.
.
51
52
53
54
59
60
60
67
68
86
6 Conclusioni
115
Bibliografia
119
Chapter 2
Introduzione
In informatica il termine virtualizzazione si riferisce all’astrazione di risorse
computazionali. Lo scopo della virtualizzazione è migliorare l’utilizzo delle
risorse, fornendo una piattaforma integrata ed unificata per utenti e applicazioni caratterizzata dall’aggregazione di risorse autonome ed eterogenee [1].
In sintesi gli obiettivi della virtualizzazione di risorse sono:
Astrazione Semplificare le risorse virtualizzate rimuovendone i dettagli
Replica Creare istanze multiple di una risorsa per semplificarne la gestione
o l’allocazione
Isolamento Separare l’utilizzo delle risorse da parte dei client
La virtualizzazione al giorno d’oggi è ovunque, basti pensare a software come
la Java Virtual Machine (JVM), ai sistemi di storage di rete che offrono
all’utente uno spazio logico mappato su un insieme di dispositivi di memorizzazione eterogenei, o ai meccanismi di memoria virtuale che utilizzano tutti
i sistemi operativi per avvalersi di uno spazio di memoria centrale maggiore
di quello fisicamente disponibile utilizzando spazio di memoria secondario;
tutte queste applicazioni hanno un fattore comune, semplificare l’utilizzo
delle risorse, creare astrazione, e migliorarne l’utilizzo.
Parlare di virtualizzazione in generale è troppo dispersivo, per cui nel seguito del capitolo verrà mostrata una tassonomia e verrano approfonditi i
rami dell’albero tassonomico che risultano utili alla comprensione del nostro
lavoro.
2
CHAPTER 2. INTRODUZIONE
2.1
3
Inquadramento Storico
La virtualizzazione venne implementata per la prima volta da IBM con
System/360 Model 67 (S/360-67) negli anni ’60 come metodo per partizionare in maniera logica i computer mainframe in macchine virtuali separate; grazie a ciò i mainframe erano in grado di implementare il multitasking.
Poiché i mainframe all’epoca erano risorse costose, il loro partizionamento
rappresentava un modo per valorizzare l’investimento.
Negli anni ’70 notiamo il diffondersi di questa tecnologia; di particolare rilievo
è CP/CMS (Control Program/Cambridge Monitor System), un
sistema operativo time-sharing, allora sinonimo di virtualizzazione e OpenVMS (Open Virtual Memory System), un sistema operativo multiuser, multiprocessing, basato su virtual memory, progettato per l’utilizzo in
time-sharing, processi batch e transazioni real-time.
La virtualizzazione venne accantonata negli anni ’80 e ’90 quando le applicazioni client-server e gli economici server e desktop x86 hanno dato vita
all’elaborazione distribuita. L’ampia diffusione di Windows e la nascita di
Linux come sistemi operativi server fecero sı̀ che negli anni ’90 i sistemi
x86 si imponessero come standard di settore. L’adozione sempre più vasta
e articolata di server e desktop x86 ha comportato nuove sfide operative e
infrastrutturali per i reparti IT, tra cui:
Bassi livelli di utilizzo dell’infrastruttura: secondo quanto riportato dalla
società di indagini di mercato IDC (International Data Corporation)
i server x86 sono utilizzati in media soltanto al 10-15% della loro capacità complessiva. Per evitare che eventuali problemi di sicurezza di
un’applicazione influiscano sulla disponibilità di un’altra nello stesso
server, le aziende di norma eseguono una sola applicazione per server.
Aumento dei costi dell’infrastruttura fisica: i costi operativi per il supporto di un’infrastruttura fisica in continua crescita sono notevolmente
aumentati. La maggioranza delle infrastrutture di elaborazione deve
rimanere sempre operativa, pertanto i costi di alimentazione, di raffreddamento e di impianto non variano in rapporto ai livelli di utilizzo.
Aumento dei costi di gestione IT: il grado di formazione ed esperienza
specialistica del personale incaricato della gestione infrastrutturale e i
costi ad esso associati sono aumentati progressivamente con l’incremento
4
della complessità degli ambienti informatici. Le organizzazioni impiegano una quantità sproporzionata di risorse e tempo per attività manuali correlate alla manutenzione dei server e pertanto necessitano di più
personale per il completamento di queste attività.
Failover e disaster recovery insufficienti: le organizzazioni sono sempre
più penalizzate dai tempi di inattività delle applicazioni server missioncritical e dall’inaccessibilità dei desktop importanti. La minaccia di
attacchi alla sicurezza, disastri naturali, pandemie e terrorismo ha accresciuto l’importanza di una corretta pianificazione della business continuity, sia per i server che per i desktop aziendali.
Manutenzione impegnativa dei desktop degli utenti finali: la gestione
e la protezione dei desktop aziendali presenta non pochi problemi. Il
controllo di un ambiente desktop distribuito e l’applicazione di criteri
di gestione, accesso e sicurezza che non compromettano l’efficienza operativa degli utenti sono attività complesse e costose. Per eliminare
i rischi per la sicurezza, è necessario installare costantemente patch e
upgrade negli ambienti desktop.
Nel 1985 l’AT&T 6300 annunncia Simultask e successivamente Merge, un
monitor di macchina virtuale sviluppato da Computing Corporation Locus,
che permettava l’esecuzione di un sistema operativo Intel 8086 guest, sotto
un host con sistema operativo Unix System V Release 2. Anche se il prodotto
è stato commercializzato con Microsoft MS-DOS come sistema operativo ospitato, effettivamente la macchina virtuale poteva ospitare qualsiasi sistema
operativo o software standalone scritto per architetture 8086.
Successivamente Locus ha sviluppato una linea di prodotti del genere chiamata Merge.
Nel 1997 è stata rilasciata la prima versione di Virtual PC per Macintosh,
sviluppata da Connectix, mentre nel 2001 è stata rilasciata la prima release
per sistemi Windows; i sistemi operativi ospitati erano Windows, OS/2, Red
Hat Linux.
Non appena è diventata chiara l’importanza della virtualizzazione nel mercato enterprise, Microsoft acquistò Virtual PC e Virtual Server nel 2003:
questi prodotti sono ora conosciuti come Windows Virtual PC.
Nel 1999, VMware ha introdotto la virtualizzazione nei sistemi x86 allo scopo
di risolvere efficacemente molte delle problematiche prima citate e trasformare i sistemi x86 in un’infrastruttura hardware generica e condivisa che
5
garantisse la mobilità, il completo isolamento e la libertà di scegliere il sistema operativo degli ambienti applicativi.
Sfide e ostacoli della virtualizzazione dei sistemi x86 Diversamente
dai mainframe, le macchine x86 non sono progettate per il supporto completo della virtualizzazione e VMware ha dovuto superare notevoli ostacoli
per riuscire a creare macchine virtuali dai computer x86.
La funzione fondamentale della maggior parte delle CPU nei mainframe e
nei computer è costituita dall’esecuzione di una sequenza di istruzioni memorizzate (ad esempio, un programma software). Nei processori x86, sono
presenti 17 istruzioni specifiche che creano problemi nel momento in cui vengono virtualizzate provocando la visualizzazione di un avviso, la chiusura
dell’applicazione o addirittura l’arresto del sistema. Di conseguenza, queste
17 istruzioni costituivano inizialmente un grosso ostacolo all’implementazione
della virtualizzazione nei computer x86.
Per gestire le istruzioni problematiche nell’architettura x86, VMware ha
sviluppato una tecnica di virtualizzazione adattiva che ”blocca” tali istruzioni
nel momento in cui vengono generate e le converte in istruzioni virtualizzabili, senza intervenire sull’esecuzione di tutte le altre istruzioni sicure. Come
risultato, viene creata una macchina virtuale ad elevate prestazioni che corrisponde esattamente all’hardware host e che mantiene la totale compatibilità
software. Grazie all’utilizzo pionieristico di questa tecnica, oggi VMware è il
leader indiscusso nelle tecnologie di virtualizzazione.
In concomitanza con VMware, negli anni 2000 FreeBSD 4.0 viene rilasciato, includendo l’implementazione inziale di FreeBSD jails, e IBM annuncia
z/VM per macchine virtuali a 64 bit con architettura z/Architecture.
E’ il 2001 quando VMware crea il primo software di virtualizzazione di server
x86.
Nel 2003 si ha la prima release del primo hypervisor open-source x86 XEN.
Attualmente la comunità di XEN ha all’attivo 250 contribuenti tra cui IBM,
HP, Intel, VA Linux, AMD, Red Hat, Novell, Fujitsu, Bull, SGI, . . . .
Nel 2005 VMware rilascia VMware Player free, allo scopo di consentire al
mercato di massa di eseguire macchine virtuali ”preconfezionate”, mentre la
Sun rilascia il sistema operativo Solaris 10, includendo Solaris Zones, per
virtualizzare sistemi x86/x64 e SPARC.
Nel 2006, dopo l’acquisizione da parte di EMC di VMware, viene rilasci-
6
ato VMware Server, successore della linea di prodotti GSX Server. VMware
Server può creare, editare ed eseguire macchine virtuali. E’ caratterizzato
da un’architettura client/server e consente di effettuare l’accesso remoto alle
macchine virtuali; inoltre può eseguire le macchine virtuali create da Microsoft Virtual PC. VMware distribuisce questo prodotto in licenza free per
promuovere la transizione a VMware ESX Server. Nello stesso anno VMware
è vincitore del Virtualization Appliance Contest e Microsoft Virtual PC 2006
è rilasciato in licenza free.
Nel 2007 viene rilasciato VirtualBox Open Source Edition (OSE), il primo
virtualizzatore professionale per PC sotto licenza GNU.
Nel 2008 VMware rilascia VMware Workstation 6.5b, il primo hypervisor
capace di abilitare le DirectX 9 su una macchina virtuale Windows XP.
2.2
Motivazioni
Le motivazioni che hanno portato alla nascita della virtualizzazione vanno sicuramente ricercate nella storia. Principalmente vi era la necessità, da parte
dei possessori di grandi centri di calcolo, allora mainframe, di utilizzare efficientemente le risorse a disposizione. Attualmente però esistono molteplici
motivi che spingono ad utilizzare la virtualizzazione. Prima di elencare le
motivazioni è necessario innanzitutto effettuare una distinzione fra virtualizzazone in ambiente desktop e virtualizzazione in ambiente enterprise o più
semplicemente virtualizzazione di server.
Desktop Virtualization La virtualizzazione di desktop è un’implementazione
software di una piattaforma, consistente di CPU, memoria, dispositivi di I/O
virtualizzati, che viene eseguita al di sopra di un sistema operativo come
un’applicazione utente. Gli scopi di questa virtualizzazione sono certamente
l’altissima portabilità, poichè tali macchine virtuali (VM) sono dei file che
possono essere eseguiti su qualsiasi macchina avvalendosi di un virtualizzatore, e la risoluzione di problemi di compatibilità: ad esempio se si ha la
necessità di utilizzare un’applicazione non compatibile con il sistema operativo usato si installa una VM compatibile con l’applicazione e senza sforzi si
esegue l’applicazione contemporaneamente all’esecuzione del sistema operativo. E’ chiaro quindi che lo scopo di tali software non è tanto garantire un
efficiente utilizzo delle risorse quanto risolvere problemi di compatibilità.
7
Server Virtualization La virtualizzazione dei server, come visto in precedenza, nasce fin dagli anni ’60 dalla necessità di utilizzare efficacemente le
risorse dei grossi calcolatori a disposizione nei centri di calcolo. Grazie a un
layer software chiamato hypervisor che compete sulle risorse hardware del
server, è possibile suddividere la macchina fisica in molteplici VMs, eseguirle
concorrentemente ed utilizzarle per fornire servizi.
2.3
2.3.1
Vantaggi e Svantaggi
Vantaggi
Flessibilità: è possibile eseguire più di un sistema operativo contemporaneamente, migrare VMs da un computer ad un altro, interagire con
l’hypervisor tramite i comandi pause, play, resume, o modificare le
specifiche hardware di una VM
Disponibilità: nello scenario della virtualizzazione di server, è possibile
spostare dinamicamente o ”a caldo” VMs, in caso di problemi di manutenzione o allo scopo di bilanciare il carico, con un periodo di downitime minimo, generalmente pochi secondi, un tempo impercettibile
all’utente, e continuare a garantire il servizio
Scalabilità: è semplice aggiungere nodi, rimuoverne e spostarne per bilanciare il carico
Utilizzo dell’hardware: l’utilizzo delle risorse a disposizione aumenta visibilmente portando ad un risparmio economico ed energetico in quanto
la richiesta di hardware diminuisce sensibilmente
Sicurezza: ogni VM è eseguita dall’hypervisor in una sandbox. Tale grado
di isolamento favorisce l’utilizzo delle VMs per il testing di applicazioni
e l’utilizzo delle stesse in ambito server come singoli workload, garantendo che eventuali falle di sicurezza in una VM non causino danni alle
altre VMs
Costi: si riducono i costi di hardware, poichè si consolidano i server in
un’unica infrastruttura governata dall’hypervisor che assegna efficientemente le risorse alle VMs, i costi di personale, poichè da una singola postazione è possibile gestire centinaia di VMs, i costi di energia,
8
poichè tali tecnologie di virtualizzazione hanno come principali scopi
il risparmio energetico dovuto ad un efficiente utilizzo delle risorse, i
costi di spazio, . . . .
Adattabilità al Workload: i cambiamenti del workload possono essere gestiti
in maniera adattiva dall’infrastruttura grazie alla semplicità con cui si
crea, si spegne, si migra una VM all’interno dell’infrastruttura
Bilanciamento del carico: al variare del carico sulle VM si applicano politiche
di bilanciamento, ad esempio spostando le macchine meno cariche su
un singolo server e lasciando un’unica macchina molto carica su un altro server o creando più macchine virtuali per gestire picchi di carico
generati dalle richieste ad un servizio
Applicazioni Legacy: compatibilità con applicazioni scritte per differenti
piattaforme senza la necessità di installare nativamente nuovi sistemi
operativi
2.3.2
Svantaggi
Overhead: è presente un certo overhead legato alla virtualizzazione della
CPU, alle tecniche di virtualizzazione della memoria, alla gestione dei
dispositivi di I/0
Costi dell’infrastruttura: prima di virtualizzare un’infrastruttura è necessario valutare bene i costi legati alle licenze dell’infrastruttura (nel
caso di virtualizzatori commerciali come VMware) e ai sistemi operativi delle macchine virtuali; per una piccola azienda non sempre la
virtualizzazione è la scelta migliore, dal punto di vista economico
Gestione: prima di virtualizzare è importante progettare l’infrastruttura
che ospiterà le macchine virtuali; gli hypervisor moderni hanno un numero di funzionalità impressionanti che utilizzate erroneamente possono minare la scalabilità, la sicurezza e anche le performance; anche
se il personale si riduce quantitativamente è necessario che sia elevato
qualitativamente per un ottimale gestione dell’infrastruttura
2.4
9
Tassonomia
Alla radice dell’albero tassonomico che si intende tracciare vi è la virtualizzazione, che a sua volta si suddivide in System-Level e Process-Level. Per
System-Level Virtualization si intende l’implementazione software di una piattaforma, ossia della CPU, della memoria, dei dispositvi; per Process-Level
Virtualization si intende un processo eseguito sul sistema operativo ospitante
che astrae i dettagli hardware e implementativi della piattaforma e nasce
all’avvio del processo e termina quando il processo muore. I software analizzati in questo lavoro si occupano di System-Level Virtualization, più precisamente di Native Virtualization e Hosted Virtualization. Alla prima categoria appartengono i software di virtualizzazione che operano direttamente
sull’hardware della macchina, senza la presenza di un sistema operativo sottostante, sono dotati di un microkernel e gestiscono le risorse della macchina;
alla seconda categoria appartengono i più comuni software di virtualizzazione
eseguiti sul sistema operativo sottostante come applicazioni utente. E’ cruciale delineare la differenza fra due tipologie di software erratamente considerate affini:
Emulazione Implementazione software di una macchina, con CPU, memoria, periferiche di I/O con un instruction set differente da quello della
macchina ospitante; in sintesi quando si emula una piattaforma si effettuano tre operazioni: read-decode-execute, cioè lettura dell’istruzione,
decodifica nel set di istruzioni della macchina ospitante ed esecuzione.
E’ un processo che genera molto overhead ma ciò nonostante è ampiamente utilizzato per motivi di compatibilità con vecchie piattaforme e
a scopo di sviluppo.
Virtualizzazione Implementazione software di una macchina, con CPU,
memoria, periferiche di I/O avente un instruction set compatibile con
quello della macchina ospitante; ciò non esclude il fatto che ci possa
essere overhead legato alla traduzione di particolari istruzioni, e tale
overhead è strettamente dipendente dal tipo di tecnica di virtualizzazione che si utilizza.
2.5
Terminologia
A seguire vi è la terminologia utilizzata d’ora in avanti.
10
Macchina Virtuale (VM) Insieme di componenti hardware e periferiche
implementate via software, che consente l’esecuzione di un sistema operativo e più applicazioni eseguite su di esse
Guest OS Sistema operativo in esecuzione sulla VM
Host OS Sistema operativo che esegue la VM
Virtual Machine Monitor (VMM) Software di virtualizzazione appartenente ad una VM che compete sulle risorse fisiche allocate al sistema
ospitante
Hypervisor Strato di virtualizzazione sul quale sono eseguite le VMs, che
supervisiona i VMM. Può essere classificato ulteriormente in Hypervisor bare-metal o nativo quando è eseguito nativamente sull’hardware
e ne possiede il controllo diretto e privilegiato, e in Hypervisor hosted
o ospitato quando è eseguito sull’Host OS come un’applicazione utente.
2.6
Sfide della virtualizzazione
Tutti i comuni approcci alla virtualizzazione discendono da una serie di requisiti e linee guida tracciati da due scienziati Gerald J. Popek e Robert P.
Goldberg nel paper Formal Requirements for Virtualizable Third Generation Architectures [10]. In questo lavoro dettano le condizioni sufficienti ad
un’architettura per supportare efficientemente la virtualizzazione:
Equivalenza Il comportamento esibito dal Guest OS deve essere del tutto
equivalente a quello dell’Host OS; in poche parole il Guest OS è virtualizationunaware
Controllo risorse Il VMM deve avere completo controllo di tutte le risorse
hardware/software del nodo Host; questo lascia intendere che il VMM
debba avere un accesso privilegiato alla macchina Host
Efficienza Una percentuale significativa delle istruzioni del Guest OS deve
essere eseguita senza intervento del VMM; un eccessivo controllo da
parte del VMM sarebbe causa di intollerabile overhead
2.6.1
11
Virtualizzazione della CPU
Il termine x86 si riferisce ad una famiglia di instruction set architectures,
un insieme di istruzioni che descrive quegli aspetti dell’architettura di una
calcolatore che sono visibili al programmatore, tra cui i tipi di dati nativi, le
istruzioni, i registri, le modalità di indirizzamento, l’architettura della memoria, la gestione degli interrupt e delle eccezioni, e l’eventuale I/O esterno,
basata sul processore Intel 8086. L’architettura x86, come si può osservare
in figura 2.6.1, è suddivisa in Ring di privilegio:
1. Ring 0: il sistema operativo è eseguito in questo ring, il più privilegiato, poichè necessita dell’accesso diretto alla memoria, alla CPU e in
generale all’hardware della macchina;
2. Ring 1, Ring 2: poco utilizzati, generalmente dai dispositivi
3. Ring 3: in tale ring vengono eseguite tutte le operazioni utente
Figure 2.1: Ring di privilegio nell’architettura x86
I processori basati sull’8086 hanno quindi due modalità operative fondamentali: user mode (ring 3) e kernel mode (ring 0). Il ring 3 è caratterizzato da
12
uno spazio d’indirizzamento di memoria segmentato in 20 bit e dalla mancanza di protezione della memoria e di multitasking a livello hardware. Le
applicazioni vengono eseguite in questa modalità e possono usare l’hardware
attraverso le system call. Il ring 0 espande la memoria fisica indirizzabile,
fornendo la protezione della memoria per evitare che i programmi si possano
dannegiare tra loro. E’ possibile eseguire le istruzioni di CPU, incluse quelle
privilegiate (interruzioni, gestione di memoria, I/O). Queste due modalità
sono basate sull’assunzione che la memoria è divisa in pagine prima che
un’istruzione privilegiata venga eseguita, la CPU controlla se la pagina da
cui si origina l’istruzione abbia il giusto codice a 2 bit (”00” per il kernel
mode e ”11” per lo user mode). Virtualizzare un architettura x86 significa
posizionare uno strato software sotto il sistema operativo, che si trova nel
Ring 0, per creare e gestire le macchine virtuali che utilizzano le risorse
dell’Host OS. I problemi legati alla virtualizzazione della CPU sorgono dalla
presenza di un sottoinsieme di istruzioni particolarmente ostiche:
Istruzioni Privilegiate Istruzioni che necessitano dei privilegi del Ring 0
e se non eseguite con i dovuti privilegi scatenano un’eccezione
Istruzioni Sensibili Istruzioni che necessitano dei privilegi del Ring 0, tuttavia se non eseguite con tali privilegi non scatenano un’eccezione ma
modificano la semantica dell’azione
Il set di istruzioni dell’architettura x86 contiene 17 istruzioni privilegiate. Le
conseguenze legate all’esecuzione, a livello utente, di tali istruzioni sono la
possibile perdita del controllo della CPU o l’interruzione fatale dell’esecuzione
del sistema operativo. La soluzione più semplice è ”trap-and-emulate”: si catturano le istruzioni quando esse generano un’eccezione a causa di mancanza
di privilegio e si emulano; questo approccio non è purtroppo applicabile alle
istruzioni x86 poichè in caso di istruzioni sensibili non è possibile individuare
con il meccanismo delle eccezioni le istruzioni ostiche. La prima soluzione a
questo problema è stata introdotta nel 1999 da VMware, è chiamata Binary
Translation e si basa su un modulo software che traduce il codice binario che
il kernel di un Guest OS vuole eseguire al momento. Anche se causa di un
forte overhead, è una soluzione relativamente semplice e soprattutto garantisce la portabilità dell’ambiente virtuale. Una soluzione di differente natura
è quella adottata da Xen Hypervisor, chiamata Paravirtualization: in questa
tecnica la traduzione del codice non avviene a runtime ma staticamente attraverso modifiche del sistema operativo. E’ evidente che le prestazioni, in
13
termini di overhead legato alla traduzione, offerte da questa tecninca sono
molto migliori di quelle offerte da VMware; tuttavia il prezzo da pagare è
l’assenza di portabilità e semplicità di installazione. Entrambe le tecniche
verranno ampiamente descritte nel seguito di questo lavoro.
2.7
2.7.1
Hardware-assisted Virtualization
Problemi legati alla virtualizzazione software-only
Tra il 2005 e il 2006 i due principali produttori di processori, Intel e AMD,
hanno lavorato indipendentemente per modificare l’architettura dei processori, allo scopo di affrontare e risolvere alcuni problemi legati alla virtualizzazione software.
Ring aliasing Si verifica quando un software viene eseguito ad un livello di
privilegio diverso da quello per il quale è stato scritto.
Address-space compression Il Guest OS si aspetta di avere accesso a
tutto lo spazio indirizzabile virtuale del processore ma in realtà l’hypervisor
deve riservarsi una porzione dello spazio indirizzabile del Guest per
memorizzare le strutture dati e le istruzioni e deve implementare meccanismi di sicurezza per evitare l’accesso del Guest OS a tale porzione
di memoria riservata.
Non-faulting access to privileged state La protezione ”privilege-based”
evita che software senza alcun diritto di privilegio acceda alla CPU,
generando un eccezione, che consente all’hypervisor di emulare l’istruzione
richiesta; tuttavia è stato mostrato che esistono istruzioni sensibili che
non generano eccezioni quando sono eseguite senza i privilegi sufficienti.
Adverse impact on guest system calls L’esecuzione di una system call
da parte di un Guest OS crea un impatto negativo sulle prestazioni del
sistema operativo, infatti la traduzione binaria di una system call può
contenere un numero di istruzioni macchina fino a dieci volte maggiore
quello di una system call ”nativa”.
Interrupt virtualization L’architettura x86 fornisce meccanismi per il mascheramento delle interruzioni (interrupt masking) quando il sistema operativo non è pronto per gestirle: più precisamente utilizza l’interrupt
14
flag (IF) nel registro EFLAGS per controllare il mascheramento delle
interruzioni. L’hypervisor dovrebbe gestire le interruzioni e negare al
software virtualizzato il controllo del mascheramento.
Frequent access to privileged resources L’hypervisor dovrebbe prevenire
l’accesso del Guest OS a risorse privilegiate generando fault ad ogni tentativo di accesso; se la frequenza dei fault è eccessiva le performance
del sistema possono essere compromesse.
Addressing Virtualization L’hypervisor fornisce dei meccanismi d’indirizzamento,
come la shadow page table che introduce ulteriore overhead poichè si
ha un doppio livello di memoria virtuale, quella virtuale del Guest OS
virtualizzata mappata sulla memoria virtuale dell’Host OS.
In sintesi la virtualizzazione software-only richiede hypervisor molto complessi e difficili da progettare, e costosi computazionalmente parlando.
2.7.2
Intel Virtualization Technology (Intel VT)
Intel introduce la tecnologia di virtualizzazione hardware-assisted nel 2005
in due modelli di Pentium 4, e prese il nome di Intel VT-x o Vanderpool.
Questa tecnologia offre una nuova archiettura sulla quale il sistema operativo virtualizzato può essere eseguito con i privilegi adeguati, elimimando la
necessità di binary translation e relativo overhead, semplificando la progettazione dell’hypervisor. L’Intel Virtualization Technology consiste di tre tipi
di tecnologie:
1. VT-x: introduce all’architettura due nuove forme di funzionamento
della CPU: VMX root operation, destinata all’uso da parte dell’hypervisor,
e VMX non root operation, corrispondente ad un ambiente x86 alternativo controllato dall’hypervisor e progettato per supportare una
macchina virtuale. Entrambe le modalità hanno tutti e quattro i livelli di privilegio, permettendo al software Guest di essere eseguito al
ring 0. Le principali funzionalità offerte da questa tecnologia sono: x86
CPU virtualization, VT FlexMigration per facilitare la migrazione di
macchine virtuali da un ambiente all’altro, VT Extended Page Tables,
grazie alla quale si introduce un nuovo indirizzamento della memoria,
VT Virtual Processor ID per migliorare le prestazioni della macchina
virtuale.
15
2. VT-d: assistenza hardware per le operazioni di I/O; poichè su un
server possono coesistere molteplici VM (quindi molteplici Guest OS),
il movimento di dati in ingresso e in uscita dal sistema (traffico di I/O)
aumenta e diventa complesso da gestire: Intel VT-d ha l’obiettivo di
risolvere questo problema riducendo il coinvolgimento dell’hypervisor,
più precisamente consentendo all’hypervisor di assegnare specifici dispositivi di I/O a specifici Guest OS. Ogni dispositivo ha quindi un’area
di memoria del sistema dedicata, che può essere acceduta dal dispositivo e dal Guest OS a cui il dispositivo è associato.
3. VT-c: supporto hardware che collega il singolo server alla rete del data
center, all’infrastruttura di memoria ed ad altri dispositivi esterni.
2.7.3
AMD Virtualization Technology (AMD-V)
Quasi contemporaneamente ad Intel, AMD ha introdotto nel 2006 la propria
tecnologie di virtualizzazione chiamata AMD-V o anche SVM - Secure
Virtual Machine, o Pacifica nei processori Dual-Core della serie Opteron.
Questa tecnologia ha lo scopo di migliorare le performance e la sicurezza
della virtualizzazione attraverso estensioni hardware all’architettura del sistema x86, proprio come Intel VT. Fra le principali funzionalità offerte abbiamo: l’estensione al set di istruzioni x86 per consentire all’hypervisor di
creare più efficientemente le macchine virtuali, Taggled TLB per facilitare
il context-switch da una macchina virtuale ad un’altra, Nested Paging per
l’ottimizzazione della memoria virtualizzata, AMD-V Extended Migration,
che consente all’hypervisor di facilitare la migrazione in tempo reale di macchine virtuali tra processori AMD di diverse generazioni, AMD-Vi per fornire
supporto ai problemi legati al traffico I/O.
Chapter 3
Full Virtualization e VMware
3.1
Introduzione
VMware Inc. è una società per azioni sussidiaria della EMC Corporation
con quartiere generale a Palo Alto, California, che si occupa di sviluppare
software per la realizzazione di macchine virtuali per sistemi x86. La società
fu fondata nel 1998 da Diane Greene (CEO fino al 2008), Mendel Rosenblum, Scott Devine, Edward Wang, Edouard Bugnion ed acquisita nel 2004
da EMC Corporation. Nel 2007 Intel entra nel capitale azionario di VMware
Inc acquisendone il 2,5% con 218 milioni di dollari e nello stesso anno Cisco
Systems ha annunciato l’acquisto dell’1,6% delle azioni di VMware Inc. per
150 milioni di dollari e ha annunciato la nascita di accordi di collaborazione
con VMware Inc. Nel 2008 VMware acquisisce Thinstall, società leader nella
pacchetizzazione delle applicazioni. Il portfolio di virtualizzazione di VMware
comprende programmi di virtualizzazione desktop e programmi di virtualizzazione enterprise, ulteriormente classificabili in commerciali e freeware.
1. Desktop Virtualization
VMware Workstation E’ un software commerciale che consente di
eseguire, creare, editare macchine virtuali; è disponibile per Windows, GNU/Linux e Mac OS X (VMware Fusion). Fra le caratteristiche salienti vi è il supporto per l’accelerazione hardware 3D con
Microsoft Direct3D API, il supporto per shader model e OpenGL
2.1, e dall’ultima versione (VMware Workstation 8) il supporto
per architettura x86-64 con Intel VT.
16
CHAPTER 3. FULL VIRTUALIZATION E VMWARE
17
VMware Player E’ un software freeware, componente del software
commerciale appena citato, rilasciato nel 2005 che esegue macchine virtuali e dall’ultima versione (VMware Player 3) ne consente anche la creazione.
2. Enterprise Virtualization
VMware Server E’ un software per la virtualizzazione di server, successore dei prodotti GSX Server della EMC Corporation che consente di creare, editare, macchine virtuali installate su una macchina
server e implementa i meccanismi di comunicazione e gestione da
remoto di queste tramite un’architettura client/server. E’ stato
reso freeware per promuovere il passaggio a ESX Server e nel
2010 VMware ha annunciato l’interruzione del supporto a VMware
Server.
VMware vSphere E’ una vasta suite di prodotti per la virtualizzazione di server: più precisamente è composta da ESX e ESXi,
software per la migrazione, software per la gestione centralizzata
dell’infrastruttura, software per la gestione delle repliche e tanto
altro. ESX e ESXi sono hypervisor di tipo bare-metal e sono distribuiti in licenza freeware insieme a vSphere Client, il client per
accedere alle macchine virtuali, mentre il resto della componentistica è commerciale.
Lo scopo di questo lavoro è stato valutare le perfomance di due tecniche
di virtualizzazione, Full Virtualization e Paravirtualization; per analizzare in maniera esaustiva la tecnica di Full Virtualization si è scelto
di utilizzare VMware ESXi come esempio di hypervisor bare-metal e
VMware Player come esempio di hypervisor hosted.
3.2
3.2.1
Full Virtualization
La tecnica di Full Virtualization, adottata da VMware per i suoi prodotti
di virtualizzazione, consiste nell’implementazione dell’intero hardware, cioè
BIOS, CPU, RAM, dischi, schede di rete, presentato poi al Guest OS come
risorse fisiche vere e proprie. VMware nel 1999 propone, come soluzione alle
18
Figure 3.1: Full Virtualization
problematiche sorte dalla virtualizzazione della CPU, la tecnica di Binary
Translation. Questa soluzione si basa su un traduttore Binary Translator
(BT) che traduce il codice binario che il kernel di un Guest OS vuole eseguire
in nuove sequenze di istruzioni che hanno lo stesso effetto sull’hardware virtuale, e memorizza tali sequenze in una cache, Translator Cache (TC), per
ottimizzarne l’esecuzione in caso di utilizzi futuri. Le applicazioni utente
non sono trattate dal BT poichè quest’ultimo assume che il codice utente sia
sicuro e quindi vengono eseguite direttamente sulla CPU virtuale. Il funzionamento di questa tecnica è illustrato in figura 3.1.
Per illustrare più dettagliatamente il processo di traduzione si mostra il
seguente esempio: si consideri una funzione isPrime() che prende in input
un intero e verifica se è un numero primo o meno.
int isPrime(int a)
{
for(int i=2; i<a; i++)
if (a%i == 0) return 0;
return 1;
}
19
Quello che segue è il codice assembler della funzione per un’architettura
x64:
isPrime:
mov %ecx, %edi
mov %esi, $2
cmp %esi, %ecx
jge prime
nexti:
mov %eax, %ecx
cdq
idiv %esi
test %edx, %edx
jz notPrime
inc %esi
cmp %esi %ecx
jl nexti
prime:
mov %eax, $1
ret
notPrime: xor %eax, %eax
ret
;
;
;
;
;
;
;
;
;
;
;
;
;
%ecx = %edi (a)
i = 2
is i >= a?
jump if yes
set %eax = a
sign-extend
a % i
is remainder zero?
jump if yes
i++
is i >= a?
jump if no
return value in %eax
; %eax = 0
Si invoca isPrime(49) Si osservi che in realtà il codice in input al BT non è
quello sovrastante ma la sua rappresentazione binaria. Il traduttore legge la
memoria all’indirizzo indicato dal Guest OS, classificando i byte come prefissi, codici operativi o operandi, per produrre gli intermediate representation
objects (IR objects): ogni oggetto IR rappresenta un’istruzione del Guest OS.
Il BT accumula gli oggetti IR in un’unità di traduzione Traslation Unit (TU),
che corrisponde in genere ad un blocco base. Ad esempio:
isPrime:
mov
mov
cmp
jge
%ecx, %edi
%esi, $2
%esi, %ecx
prime
In fase di traduzione la maggior parte del codice resta invariato, ad esempio
le prime tre istruzioni del TU mostrato, mentre la quarta istruzione deve
essere modificata.
isPrime:
mov %ecx, %edi
mov %esi, $2
cmp %esi, %ecx
20
jge [takenAddr] ; JCC
jmp [fallthrAddr]
Si noti che l’istruzione jge è cambiata in due istruzioni translator-invoking,
che producono un compiled code fragment (CCF) e l’insieme dei CCF costituisce il codice tradotto; dal momento che 49 non è un numero primo, il TU
che restituisce il valore 1 nella funzione non viene tradotto ma viene tradotto
unicamente il TU che restituisce il valore 0. Di seguito è mostrato il codice
presente nella TC:
isPrime’: mov
mov
cmp
jge
%ecx, %edi
%esi, $2
%esi, %ecx
[takenAddr]
mov %eax, %ecx
cdq
idiv %esi
test %edx, %edx
jz notPrime’
inc %esi
cmp %esi %ecx
jl nexti’
jmp [fallthrAddr3]
notPrime: xor %eax, %eax
pop %r11
mov %gs:0xff39eb8(%rip), %rex
movzx %ecx, %r11b
jmp %gs:0xfc7dde0((*%rex)
; JCC
; fall-thru into next CCF
nexti’:
; JCC
; JCC
; RET
; spill %rex
Sostituire il codice privilegiato con codice più sicuro è molto meno costoso
dell’approccio trap-and-emulate, tuttavia l’overhead legato a questo tipo di
virtualizzazione non è sempre basso e il BT non può catturare completamente molte funzioni, come le system call, gli interrupt, gli accessi all’I/O e
in generale la gestione alla memoria. E’ stato già osservato che il kernel ha
l’accesso privilegiato alle istruzioni della CPU che altri processi non hanno per
cui quando un processo utente richiede al kernel di svolgere un’operazione
privilegiata causa un’eccezione e il kernel subentra. Allo stesso tempo lo
scheduler, un programma del kernel che ordina temporalmente le richieste
21
al kernel, utilizza l’interruzione timer per assicurarsi che nessun processo
tenti di avere il controllo della CPU per troppo tempo. Quando si esegue
una system call l’applicazione utente richiede il servizio al kernel attraverso le
istruzioni SYSENTER e SYSEXIT. Quando un Guest OS invoca una system
call si verifica il seguente problema: il Guest OS è posto in un ring di privilegio diverso sal ring 0, generalmente ring 1 o ring 3, e si invia una SYSENTER
a una pagina con privilegio 0 dove ci si aspetta di trovare il sistema operativo
ma vi è l’hypervisor, che a sua volta deve emulare la system call, tradurre il
codice e cedere il controllo al codice kernel che è eseguito nel ring 1 o ring
3. Lo stesso problema sorge una volta che il codice tradotto è stato eseguito
dal Guest OS: si invia una SYSEXIT per ritornare all’applicazione utente a
una pagina con privilegio 0 ed è perciò necessario nuovamente l’intervento
dell’hypervisor. Risulta evidente che una system call provoca un forte overhead, con un impatto fino a 10 volte maggiore di quello su una macchina
fisica [2]. Grazie a questa tecnica VMware può virtualizzare ogni sistema
operativo x86 utilizzando una combinazione di Binary Translation e tecniche di esecuzione diretta. Ogni VMM compete sulle risorse fisiche allocate
a una macchina virtuale, incluso BIOS, dispositivi di I/O e gestione della
memoria. Lo strato di virtualizzazione, composto da questa combinazione di
traduzione binaria ed esecuzione diretta, astrae completamente il Guest OS
dall’hardware sottostante; il Guest OS non è consapevole di essere virtualizzato e non richiede alcuna modifica. La Full Virtualization è l’unica tecnica
che non richiede supporto hardware o del sistema operativo per virtualizzare
istruzioni privilegiate, l’hypervisor traduce tutte le istruzioni del sistema operativo on the fly e memorizza in cache i risultati per utilizzi futuri. La Full
Virtualization offre il miglior livello di isolamento e sicurezza per le macchine
virtuali, semplifica la migrazione e la portabilità poichè la stessa istanza del
Guest OS può essere eseguita in modo virtualizzato o nativamente [9].
3.2.2
Virtualizzazione della memoria
La gestione della memoria assegnata alle macchine virtuali è un aspetto cruciale. Si ricorda che i moderni sistemi operativi utilizzano la tecnica di memoria virtuale, grazie alla quale è possibile simulare uno spazio di memoria centrale maggiore di quello fisicamente presente o disponibile, avvalendosi di dispositivi di memoria secondaria, generalmente le unità a disco. In un sistema
dotato di memoria virtuale la CPU e i programmi si riferiscono alla memoria
centrale con indirizzi logici o virtuali, tradotti successivamente in indirizzi
22
fisici reali da un’unità apposita, la Memory Management Unit (MMU). La
MMU svolge le seguenti funzioni:
1. Traduzione dell’indirizzo logico in indirizzo fisico
2. Controllo della presenza in RAM dell’indirizzo fisico tradotto
3. Se l’indirizzo tradotto non è in RAM generazione di un page fault,
eccezione che forza il sistema operativo a caricare la pagina di memoria
dalla memoria secondaria alla RAM
Quando si utilizza la memoria paginata la memoria viene divisa in pagine di
stessa grandezza, i programmi non hanno necessità di conoscere l’organizzazione
della memoria poichè la gestione delle pagine è completamente gestita dalla
MMU attraverso un complesso sistema di registri associativi. Se il numero
delle pagine è elevato, nel caso in cui si utilizzano pagine di piccola dimensione o la memoria virtuale da emulare è vasta, il meccanismo di gestione
delle pagine utilizzato dal MMU potrebbe diventare troppo complesso rallentando sensibilmente l’accesso alla memoria. Il Guest OS non ha accesso
alla tabella delle pagine reali, ma accede ad una tabella delle pagine che si
trova su una MMU virtualizzata, chiamata shadow page table. Questa tabella
da l’illusione al Guest OS di poter tradurre i propri indirizzi virtuali in indirizzi fisici, ma in realtà è l’hypervisor che in the shadow gestisce la reale
traduzione di indirizzi logici virtuali virtualizzati in indirizzi fisici e quindi
ha accesso alla MMU reale. Quando si utilizza questa tecnica detta shadow
paging ogni volta che il Guest OS effettua una modifica ad una pagina è compito della MMU virtuale ”catturare” la modifica e scrivere il cambiamento
sulla shadow page table. In sintesi, come si può notare in figura 3.2 c’è un
livello aggiuntivo di address translation quando è in esecuzione il Guest OS:
1. guest page tables (gPT): versioni ”ombra” delle tabelle delle pagine,
sulle quali scrive il Guest OS
2. shadow page tables (sPT): non visibili al Guest OS e utilizzate per
effettuare la traduzione di indirizzi quando è attivo il Guest OS
E’ compito dell’hypervisor garantire la coerenza tra le sPT e le gPT attraverso due tecniche:
1. write-protecting: ogni tentativo di modifica di una gPT da parte del
Guest OS genera un’eccezione di page fault, alla quale subentra l’hypervisor
che emula l’operazione richiesta
23
Figure 3.2: Shadow Paging
2. Virtual TLB: il Guest OS modifica la gPT senza l’intervento dell’hypervisor
fino a quando non prova ad accedere ad un indirizzo della gPT e avviene
un page fault poichè la traduzione non è presente nella sPT e a questo
punto subentra l’hypervisor che controlla la gPT per aggiungere la
traduzione mancante nella sPT ed eseguire l’operazione richiesta
Entrambe le tecniche sono causa di un grande numero di eccezioni di page
fault di tipo guest-induced o hypervisor-induced con un conseguente impatto
negativo sulle performance del sistema. Si consideri un sistema multiprocessore: la stessa istanza di una gPT può essere utilizzata per l’address translation da più processori per cui o si condivide la gPT fra i processori generando
overhead di controllo o si replica la gPT sui processori generando overhead
legato alla memorizzazione. Il risultato è che nelle applicazioni in cui si utilizza frequentemente la memoria questo tipo di gestione della memoria è la
causa principale di pessime performance dei sistemi virtualizzati.
3.3
Virtualizzazione dei dispositivi di I/O
Ogni macchina virtuale ha a disposizione un insieme predefinito di base di
periferiche virtuali emulate, come Floppy, DVDROM, tastiera, periferiche
USB, controller IDE e SCSI, scheda video, scheda di rete Etherent, scheda
audio, ecc . . . . La virtualizzazione di un dispositivo di I/O comporta la gestione del routing delle richieste di I/O tra i dispositivi virtuali e l’hardware
fisico condiviso. Quando un dispositivo comunica con il sistema operativo i
dati vengono scritti in un’area di memoria chiamata memory mapped I/O.
Più precisamente quando il sistema operativo invia dati ad una periferica
24
trasferisce i dati dalla memoria della CPU alla memoria del dispostivo, in
fase di ricezione invece il dispositivo invia i dati nell’area di memoria dedicata all’I/O e il sistema operativo li trasferisce nella memoria della CPU. In
un ambiente virtualizzato il Guest OS ha l’illusione di scrivere i dati da inviare al dispositivo nell’area di memoria dedicata ma è necessario l’intervento
dell’hypervisor che mappa l’area di memory mapped I/O virtuale in quella
fisica. La comunicazione tra una periferica fisica di rete e quella virtuale è
composta dai seguenti passi:
1. La periferica fisica utilizza Direct Memory Access (DMA) per scrivere
i pacchetti in un buffer gestito dall’hypervisor
2. La periferica fisica avvisa l’hypervisor attraverso un interrupt non appena terminata la copia dei dati
3. L’hypervisor esamina i pacchetti in cerca della destinazione (la macchina
virtuale), e copia i pacchetti nel buffer della macchina virtuale destinataria
4. La periferica virtuale avvisa il sistema operativo della macchina virtuale
a cui appartiene che sono stati ricevuti i dati
3.4
VMware vSphere
VMware vSphere o VMware Infrastructure è una suite di programmi e funzionalità fornite da VMware per la virtualizzazione di un’infrastruttura. I
principali prodotti offerti sono:
1. ESX e ESXi: hypervisor bare-metal, descritti nella prossima sezione
2. Virtual Simmetric Multi-Processing (vSMP): consente di utilizzare più
processori fisici, sfrutta la tecnologia Intel Hyper-Threading per eseguire contemporaneamente due thread su una CPU
3. Virtual Machine File System (VMFS): gestisce lo storage dell’architettura
che può essere locale, cioè le macchine virtuali sono memorizzate sul
disco del Server, o logicamente centralizzato tramite l’utilizzo di Storage
Area Network (SAN) o Network Attached Storage (NAS), che richiede
l’implementazione di un file system concorrente
25
4. vCenter: tool per la gestione centralizzata dell’intera infrastruttura,
obbligatorio per usufruire di altri prodotti come Fault Tolerance, DRS,
vMotion, Storage vMotion
5. vMotion: consente la migrazione dinamica di macchine virtuali e ha
come requisiti di utilizzo un’architettura di storage centralizzata, una
rete ad alte prestazioni e la medesima configurazione di rete su tutte le
macchine
6. Distributed Resource Scheduler (DSR): ottimizza l’utilizzo delle risorse
tra i vari Server ESX seguendo delle regole definite dall’amministratore
7. High Availability (HA): fornisce fault tolerance combinando meccanismi di bilanciamento del carico, migrazioni di macchine virtuali e monitoraggio delle risorse dei Server ESX anche se non garantisce l’assenza
di brevi periodi di disservizio
8. Fault Tolerance (FT): garantisce l’assenza di periodi di disservizio grazie a meccanismi di replica dei Server ESX
3.4.1
ESX e ESXi
VMware ESX è una componente di vSphere disponibile in due versioni ESX e
ESXi. Sono entrambi hypervisor bare-metal, eseguiti direttamente sull’hardware
del server senza la necessità di un sistema operativo sottostante, partizionano
il server fisico in multiple macchine virtuali isolate e portabili. Ogni macchina
virtuale comprende processori, memoria, interfaccia di rete, storage e BIOS.
Version release history
1. 2001 VMware ESX Server 1.0
5. 2006 VMware Infrastructure 3.0 con VMware ESX 3.0
6. 2007 VMware ESX 3.5 ESXi Edition
26
Figure 3.3: Architettura di VMware ESX
7. 2009 VMware vSphere 4.0 con VMware ESXi 4.0
8. 2011 VMware ESXi
Architettura In contrasto con altri prodotti VMware, VMware ESX è
eseguito direttamente sull’hardware della macchina e non al di sopra di un
sistema operativo, quindi include un proprio kernel. Prima della versione 5.0
veniva utilizzato un kernel Linux chiamato service console, che a runtime è
considerato come la prima macchina virtuale in esecuzione. Il vmkernel è un
microkernel che implementa le astrazioni necessarie per allocare l’hardware
disponibile a multipli workload (macchine virtuali) isolati l’uno dall’altro,
come si può osservare in figura 3.3. Gli elementi chiave dell’architettura
sono:
1. Layer di virtualizzazione, che offre un ambiente virtuale al di sopra
delle risorse fisiche che controlla
2. Manager delle risorse, che abilita il partizionamento e l’allocazione di
CPU, memoria, banda di rete e banda di disco a ogni macchina virtuale
3. Device Driver
ESX implementa hardware virtualization; il Guest OS e le applicazioni da
esso eseguite non possono direttamente determinare quale specifica risorsa
27
sottostante stanno usando, come la specifica CPU in un’architettura multiprocessore, la locazione di memoria fisica su cui è mappata una certa pagina
di memoria. La virtualizzazione della CPU alterna l’esecuzione diretta di
istruzioni non privilegiate alla tecnica di traduzione binaria. Il vmkernel
controlla CPU e memoria in modo diretto utilizzando la tecnica scan-beforeexecution (SBE) per gestire le istruzioni privilegiate e utilizza la System
Resource Allocation Table (SRAT) per tracciare la memoria allocata. Le
macchine virtuali non possono comunicare fra loro e scambiare dati se non
tramite i tradizionali protocolli di rete utilizzati per la comunicazione di macchine fisiche distinte. Questo isolamento consente a molti utenti di costruire
firewall interni o altri ambienti di isolamento di rete, consentendo ad alcune
macchine di uscire all’esterno della rete, ed ad altre di rimanere connesse
all’interno di reti virtuali attraverso altre macchine virtuali. Le funzioni
di gestione del sistema e le interfacce sono implementate nella service console. Queste includono HTTP, SNMP, funzioni per l’autenticazione. La service console è installata come prima componente ed è usata per il bootstrap
dell’installazione di ESX Server e per la configurazione, per il boot del sistema e per avviare l’esecuzione del layer di virtualizzazione e il gestore delle
risorse. La service console è implementata utilizzando una distribuzione di
Linux modificata. L’accesso alle altre componenti hardware viene effettuato
tramite l’utilizzo dei moduli utilizzati nel kernel Linux. Il vmkernel utilizza
i seguenti device drivers:
1. net/e100
2. net/e1000
3. net/e1000e
4. net/bnx2
5. net/tg3
6. net/forcedeth
7. net/pcnet32
8. block/cciss
9. scsi/adp94xx
28
10. scsi/aic7xxx
11. scsi/aic79xx
12. scsi/ips
13. scsi/lpfcdd-v732
14. scsi/megaraid2
15. scsi/mptscsi 2xx
16. scsi/qla2200-v7.07
17. scsi/megaraid sas
18. scsi/qla4010
19. scsi/qla4022
20. scsi/vmkiscsi
21. scsi/aacraid esx30
22. scsi/lpfcdd-v7xx
23. scsi/qla2200-v7xx
La service console fornisce un API che consente di controllare le macchine
virtuali e l’allocazione delle risorse. L’amministratore può accedere alla console in locale o in remoto poichè nella service console è in esecuzione un
Web Server. Con il passaggio a ESXi è stata eliminata la service console,
migrando una serie di funzionalità eseguite tradizionalemnte in locale dalla
linea di comando verso tool di gestione remota dell’infrastruttura [11].
3.5
VMware Player
VMware Player è un software distribuito in licenza free per la desktop virtualization. VMware è un hypervisor di tipo Hosted, cioè eseguito al top di
un Host OS come un’applicazione utente. Le funzionalità offerte da questo
prodotto sono:
29
1. Eseguire e creare macchine virtuali su un Host OS Windows o Linux
2. Eseguire macchine virtuali senza investire in software di virtualizzazione,
in sicurezza, flessibilità e portabilità
3. Utilizzo di dispositivi della macchina Host, come CD e DVD
Rilasciato per la prima volta nel 2001 in versione 1.0 ha subito negli anni dei
forti cambiamenti tra i quali il supporto alle librerie DirectX, le shared folders
tra Host OS e Guest OS, miglioramenti all’interfaccia grafica e dall’ultima
versione, la 3.0 è possibile creare macchine virtuali. VMware Player si installa
come una normale applicazione sul sistema operativo. Quando viene eseguito, la porzione di applicazione VMApp utilizza un driver caricato nell’Host
OS, VMDriver per eseguire il monitor VMM direttamente sull’hardware.
Da questo momento in poi il processore fisico sta eseguendo sia l’ambiente
dell’Host OS sia l’ambiente del Guest OS ed esegue continuamente contextswitch tra i due ambienti grazie al VMDriver. Si ricorda che la virtualizzazione della CPU è compito del VMM che combina esecuzione diretta
di codice sicuro e traduzione binaria. L’architettura hosted del sistema,
mostrata in figura 3.4 è un potente modo per garantire compatibilità con
la vasta gamma di hardware disponibile ai giorni nostri e creare un livello di
astrazione fra l’hardware fisico e l’implementazione software di questo: per
esempio un programma scritto per riprodurre CD-ROM audio funzionerà
sia con dispositivi CD-ROM IDE che SCSI poichè i sistemi operativi offrono un’interfaccia astratta del dispositivo CD-ROM. VMware Player, come
VMware Workstation, si avvale di questa generalità offerta dai sistemi operativi per garantire la compatibilità con intere classi di hardware senza necessitare di speciali driver.
30
Figure 3.4: Architettura Hosted di VMware Player e VMware Workstation
Chapter 4
Para Virtualization e Xen
4.1
Introduzione
L’hypervisor Xen [22], [21] è stato creato da Keir Fraser e Ian Pratt, come
parte del progetto di ricerca XenoServer presso l’università di Cambrige alla
fine degli anni ’90. Nel 2004 viene fondato XenSource Inc. che converte Xen
Hypervisor da tool di ricerca a prodotto competitivo per l’enterprise computing con l’immediato rilascio di Xen 1.0 seguito da Xen 2.0. Nel 2005 Xen
Hypervisor nella versione 2.0 è stato utilizzato da Red Hat, Novell e SUN.
Nel 2006 Microsoft e VMware adottano anche loro il concetto di paravirtualizzazione introdotto finora solo dalla comunità di Xen. Nel 2007 XenServer è
stato acquisito dalla Citrix Systems una società fondata da Ed Jacobucci un
ex sviluppatore della IBM, acquisizione di cruciale importanza per il progetto
Xen. Nel 2010 è nato Xen 4.0 e nel 2011 il kernel linux 2.6.37 è stato il primo
a permettere il boot di Xen come Dom 0 out-of-the-box. Nel kernel linux
3.x è stato aggiunto il totale supporto a Xen Dom 0 e Dom U consentendo
alla maggior parte delle distribuzioni Linux di introdurre Xen.
La comunity di Xen attualmente ha all’attivo circa 250 contribuenti, come
in figura 4.1 e tra i più attivi abbiamo IBM, HP, INTEL, VA LINUX, AMD,
RED HAT, NOVELL, FUJITSU, BULL ed SGI. I vantaggi di avere una community cosı̀ ampia rende i tempi di commercializzazione di nuovo hardware
e di nuove feature molto rapidi e il supporto di una community open-source
permette anche un rapido sviluppo, un minor numero di bug e aggiornamenti
molto rapidi.
L’hypervisor Xen a differenza della soluzione di Vmware ESX adotta un
31
CHAPTER 4. PARA VIRTUALIZATION E XEN
32
Figure 4.1: Contribuenti di Xen
approccio filosoficamente differente alla virtualizzazione. In Xen la tecnologia utilizzata per la virtualizzazione viene definita paravirtualizzazione. La
paravirtualizzazione lavora introducendo una porzione di software molto piccola e compatta che viene eseguita direttamente sull’hardware fornendo i vari
servizi ai sistemi operativi virtualizzati. In essa la principale differenza con
la Full Virtualization è la presenza di un sistema operativo che deve ospitare
l’hypervisor, infatti nella paravirtualizzazione Xen è un semplice core che utilizza tutte le risorse fornite dal sistema operativo ospitante al fine di eseguire
e quindi suddividere l’utilizzo delle risorse con altri sistemi operativi.
4.2
La Filosofia di Xen
Il primo concetto che deve essere chiarito per approciare la paravirtualizzazione è quello delle istruzioni privilegiate, che sono di fondamentale importanza in essa. Esistono vari livelli di esecuzione di istruzioni e ora analizzeremo quelle per le piattaforme x86, in figura 4.2, e x86-64, in figura 4.3.
Nelle piattaforme x86 esistono quattro livelli di esecuzione delle istruzioni,
chiamati Ring e numerati da 0 a 3 (lato sinistro figura 4.2). Il primo è il ring
33
Figure 4.2: Piattaforme x86
0 nel quale vengono eseguite istruzioni con massimo privilegio ossia quelle
del kernel del sistema operativo, il secondo e il terzo non sono utilizzati, il
quarto è il livello con il quale vengono eseguite le istruzioni delle applicazioni.
Nelle piattaforme x86-64 il numero di ring è stato ridotto da 4 a 2 (lato sinistro figura 4.3), abbiamo quindi solo il ring 0 dove si posiziona il kernel e il
ring 3 dove risiedono le applicazioni. In generale quando una applicazione in
esecuzione sul ring 4 necessita di eseguire istruzioni privilegiate richiede al
kernel del sistema operativo la loro esecuzione.
Nella Full Virtualization il Guest-OS può eseguire le istruzioni privilegiate,
invence con Xen e quindi con la paravirtualizzazione solo l’hypervisor può
eseguire tutte le istruzioni privilegiate, si trova sul ring 0, mentre il sistema operativo virtualizzato è collocato sul ring 1(lato destro figura 4.2).
L’hypervisor, che adesso si trova sul ring 0, è però in esecuzione sull’HostOS, anche esso in esecuzione sul ring 0, che provvede a fornirgli i driver per
l’hardware, il kernel e lo spazio utente. Avere un hypervisor incorporato nel
sistema operativo rende possibile una sua implementazione quanto più piccola
e semplice possibile, evitando di inserire nell’hypervisor codice come quello
dei driver. Nelle piattaforme x86-64 Xen viene modificato per posizionare il
Kernel dei sistemi virtualizzati a ring 3 e il Guest-OS con l’hypervisor a ring
34
Figure 4.3: Piattaforme x86-64
0. In questa situazione Xen utilizza i meccanismi di protezione delle pagine
per isolare i diversi sistemi operativi virtualizzati.
Il secondo concetto di fondamentale importanza nella paravirtualizzazione
riguarda il ruolo delle system call. L’hypervisor espone un insieme di API,
chiamate Hyper Call, che consentono a sistemi operativi virtualizzati di
interfacciarsi con l’hardware. In figura 4.4 possiamo vedere come nei sistemi
operativi nativi (parte sinistra della figura) le applicazioni sul ring 3 possono
eseguire istruzioni privilegiate utilizzando le normali system call che vengono eseguite a ring 0 dal kernel; in Xen le applicazioni chiedono l’esecuzione
di istruzioni privilegiate all’hypervisor che si trova su ring 0 e questo eseguirà l’istruzione sul kernel, ottenendo l’eventuale risultato e restituendolo
all’applicazione (parte destra della figura).
In figura 4.5 mostriamo il quadro generale delle differenze architetturali tra
le due piattaforme di virtualizzazione in analisi. Nella figura la parte destra
mostra l’astrazione della virtualizzazione fornita dalla Full Virtualization in
VMware ESX, mentre quella sinistra l’astrazione di Xen. In Xen come possiamo vedere dalla figura il Dom 0 rappresenta il livello di astrazione nella
paravirtualizzazione, mentre nella Full Virtualization abbiamo ESX.
Figure 4.4: System Call e Hypercall
35
36
Figure 4.5: Full Vs Para - Virtualization
4.3
L’architettura di Xen
Per definire meglio l’architettura di Xen approfondiamo adesso il concetto di
Dom0 e DomU per Xen.
4.3.1
Domain 0(privileged)
Dato che Xen non include alcun driver di periferica nè un’interfaccia utente,
questi vengono tutti forniti dal sistema operativo e dallo spazio utente in
esecuzione nel guest-Dom0. Il sistema operativo in esecuzione sul Dom0 ha
il compito di gestire i diversi dispositivi hardware e dato che la maggior parte
dell’hardware non ha il supporto nativo per i diversi sistemi operativi virtualizzati, sarà il sistema operativo in esecuzione sul Dom0 a fornire l’accesso
all’hardware per i sistemi ospitati.
Sul Dom0 vi sono diversi processi che hanno il compito sia di gestire che
controllare le macchine virtuali in esecuzione (figura 4.6:
• xend: è un programma server scritto in Python che riceve i comandi di
gestione delle macchine virtuali e ne restituisce l’esito; le richieste sono
37
Figure 4.6: Processi di gestione e controllo di Xen
inviate dal processo client Xm attraverso un’interfaccia XML RPC;
• xenstored: back-end storage, memorizza i sistemi in esecuzione su
dom U e inoltre mantiene un registro degli eventi che intercorrono tra
il Domain 0 e gli altri Domani U;
• xm: è il tool a riga di comando attraverso il quale si inviano i domandi
a xend
Per fare un esempio mostriamo come un pacchetto TCP inviato da una
macchina virtuale, sfrutta l’architettura del sistema di virtualizzazione. In
figura 4.7 l’applicazione in esecuzione, un sistema operativo a DomU, vuole
inviare un pacchetto TCP e lo aggiunge allo stack TCP/IP. Lo Split Device Drive (che rappresenta l’interfaccia di rete e sarà descritto in seguito)
inserirà questo pacchetto su un segmento di memoria condivisa di Xen, il
quale provvederà a trasferirlo allo Split Device Driver del sistema operativo
in esecuzione a Dom0 che provvederà all’instradamento sul reale driver e
quindi all’interfaccia di rete fisica. Analizziamo le caratteristiche delle tre
componenti coinvolte nell’esempio per l’instradamento del pacchetto TCP:
• Split Driver: progettato per essere il più semplice possibile, rappresenta la controparte virtuale del real driver alle macchine virtuali in
Figure 4.7: Esempio di pacchetto TCP in Xen
38
39
esecuzione sul domU e ha il compito di spostare i dati dal DomU al
Dom0 utilizzando di solito il buffer ad anello della memoria condivisa;
• Real Driver: sono presenti nel sistema operativo in esecuzione sul
Dom0 e non sono considerati una vera e propria parte di Xen dato che
questo è sprovvisto di driver;
• Multiplexer: nell’esempio appena vista era lo stesso protocollo TCP
ad effettuare l’operazione di multiplexing dei pacchetti, in altri casi è
Xen stesso a dover offrire il sistema di multiplexing per gestire i dati
dei vari DomU.
4.3.2
Domain U(nprivileged)
Ai sistemi operativi in esecuzione sul DomU non è permesso effettuare system
call direttamente sull’hardware, infatti implementa gli Split Device Driver che
vanno a sotituire i Real Driver per ogni categoria di dispositivi. Tali argomentazioni chiariscono la principale differenza tra paravirtualizzazione e virtualizzazione piena, infatti paravirtualizzare un Guest-OS destinato all’esecuzione
sul DomU comporta modfiche al kernel, non solo per consentire l’utilizzo delle
hypercall ma anche per la codifica degli Split Device Driver.
In Xen inoltre possiamo avere un numero arbitrario di sistemi operativi in
esecuzione sul DomU; nel lavoro [21] sono stati eseguiti test per valutare il
massimo supporto in termini di sistemi virtualizzabili conteporaneamente in
Xen, ed i risultati hanno mostrato che esiste la possibilità di eseguire fino
a 100 domini contemporaneamente. Xen fornisce la possibilità di migrare i
vari sistemi operativi in esecuzione se essi utilizzano configurazioni di storage
che consentono la migrazione (NFS, iSCSI).
Anche se Xen viene utilizzato solo come strumento per la valutazione delle
differenze prestazionali tra para e full virtualization, esso offre la possibilità
di virtualizzare sistemi proprietari, come Windows Xp, ovvero non modificabili, utilizzando l’Hardware Virtual Machine (HVM). La differenza tra le
due modalità di virtualizzazione in Xen è la fase di avvio di un Host, nella
versione para la fase di boot avviene in modalità protetta con pagine di
memoria condivise con l’hypervisor, mentre nell’HVM la fase di boot è reale
e ottiene le informazioni da un bios emulato e non si utilizzano le hypercall
ma i tradizionali meccanismi della Full Virtualization.
40
Figure 4.8: Configurazione 1
4.3.3
Configurazioni dell’hypervisor
Ci sono diverse modalità di configurazione di Xen e dei sistemi virtualizzati.
La prima madalità, in figura 4.8, è chiaramente la più semplice: abbiamo un
sistema operativo in esecuzione sul Dom0, il quale controlla tutto l’hardware
e offre le funzionalità necessarie all’hypervisor il quale a sua volta gestisce e
controlla i sistemi operativi in esecuzione a DomU. In questa configurazione
se un driver in esecuzione sul Dom0 dovesse contere un bug potrebbe mandare
in crash tutto il kernel del Dom0. La soluzione a questo problema è la seconda
configurazione possibile, mostrata in figura 4.9: è possibile osservare come i
driver siano stati isolati in un dominio a parte il quale esporta lo Split Device
Driver; questo dominio deve essere un sistema in grado di gestire gli specifici
driver. Sempre in questa configurazione viene presentato anche un esempio
di un sistema operativo virtualizzato da Xen in HVM che non utilizza gli
Split Device Driver ma l’emulazione dei Device drivers da parte del Dom0.
L’ultima configurazione viene utilizzata sui cluster, come da figura 4.10. I
41
42
43
vantaggi di una simile configurazione riguardano la distribuzione del carico,
la possibilità di consolidare i server in un unico Host e la migrazione dei
nodi, in modo del tutto trasparente grazie al disaccoppiamento tra block
device driver. Questa configurazione però forza l’esecuzione solo su NFS e
permette l’utilizzo di un singolo router che gestisce il traffico esterno.
4.4
Comunicazione tra domini
Xen per permettere la cominicazione tra i diversi domini utilizza il meccanismo della memoria condivisa; si noti che qualsiasi altro meccanismo di
comunicazione inter-processo(pipes, message queue) può essere sviluppato
con la memoria condivisa.
A seguito di diversi esperimenti si è visto come il trasferimento di pagine
non sia affatto efficiente; le prime implementazioni del driver del dispositivo
di rete, per esempio, utilizzando il meccanismo di trasferimento per spostare
buffer di pacchetti tra domini, risultavano particolarmente lente. Xen quindi
gestisce direttamente la memoria senza farne alcuna astrazione, infatti le
nuove versioni di Xen Hypervisor adottano un’operazione Copia-Driven:
dal momento che l’hypervisor ha tutta la memoria fisica già mappata con
questa operazione è possibile effettuare la copia dei dati tra i domini senza
dover modificare le tabelle delle pagine.
In Xen viene utilizzato lo stesso approccio dei sistemi microkernel con la differenza che, mentre l’approccio microkernel utilizza un meccanismo base di
scambio di messaggi in cui ogni messaggio ha un header che identifica i processi mittente e destinazione (alto livello di astrazione e trasparenza per le
comunicazioni in ambiente network), Xen utilizza un meccanismo più a basso
livello dove la memoria può essere condivisa a livello pagina utilizzando identificativi per le pagine memoriazzati in una tabella detta Grant-Table.
L’interfaccia di Xen espone l’hypercall grant table op per poter utilizzare il
meccanismo di condivisione delle pagine presente in grant table.h. Questa
hypercall richiede tre parametri: il tipo di operazione da eseguire, un array
di strutture contenente le operazioni e il numero di operazioni da eseguire.
44
Figure 4.11: Spazio degli Indirizzi
4.5
Gestione della Memoria
Da quando Xen supporta sia la para virtualizzazione che l’HVM, utilizza due
approcci differenti per la gestione della memoria. Per la para virtualizzazione
la gestione della memoria è strettamente legata alla piattaforma sulla quale
è in esecuzione Xen, invece per l’HVM si tratta di un sistema di gestione
molto simile all’esecuzione dei sistemi non virtualizzati.
Xen opera in due modalità: nella prima i Guest-OS sono i responsabili
dell’allocazione e della gestione della tabella delle pagine hardware, coinvolgendo minimamente l’hypervisor che non farà altro che garantire l’isolamento
tra le macchine virtuali; nella seconda Xen occupa una porzione ben definita
dello spazio degli indirizzi. Nella figura 4.11 possiamo vedere il posizionamento di Xen nei sistemi x86 senza Physical Address Extention (PAE -36 bit
di indirizzamento), nei sistemi x86 con PAE e negli x86-64. Nel Xen si posiziona nella parte superiore dello spazio di indirizzamento di 4 GB occupando
64 MB, nel secondo caso abbiamo che Xen si posiziona nella parte superiore
dello spazio di indirizzamento utilizzando 168 MB; nel caso dell’architettura
a 64 bit viene utilizzato un blocco di indirizzamento di grandezza variabile a
partire dal 48-esimo bit.
4.5.1
45
Flusso di Gestione
I Guest-OS che necessitano di una nuova pagina di memoria oltre quelle già
utilizzate, ad esempio quando si sta creando un nuovo processo, non fanno
altro che allocare questa nuova pagina ed inizializzarla nella propria zona
di memoria per poi notificarla a Xen. A questo punto il Guest-OS rinuncia
a tutti i privilegi di scrittura su quella pagina di memoria ed ogni futuro
aggiornamento dovrà essere sempre validato e permesso da Xen. Qusto meccanismo limita il numero di aggiornamenti e permette al sistema operativo di
mappare solo le pagine che possiede e ne impedisce la mappatura in scrittura,
infatti il sistema operativo che vuole effettuare una modifica può effettuarla
solo se rispetta i vincoli imposti dall’hypervisor ossia:
1. I segmenti devono avere un livello di privilegio inferiore a Xen;
2. I segmenti non devono riguardare l’area di memoria riservata a Xen.
L’assegnamento della memoria fisica per un DomU avviene in fase di avvio
del sistema dove, la memoria viene partizionata staticamente tra i vari domini
in funzione di un determinato limite massimo e garantendo cosı̀ l’isolamento
tra le macchine virtuali. Se la richiesta di memoria da parte di un DomU
aumenta, Xen si trova in una situazione di ”Memoria Insufficiente” e può
quindi richiedere altre pagine di memoria da poter assegnare ai DomU, fino
al raggiungimento del limite massimo definito nella fase di avvio; nel caso
in cui un DomU sta utilizzando poche risorse si troverà in una situazione di
”Memoria in Eccesso” rilasciando a Xen le pagine di memoria inutilizzate.
Molti sistemi operativi presuppongono che la memoria sia costituita da blocchi continui ma dato che Xen non garantisce che la regione della memoria
sia efettivamente contigua, saranno gli Host OS a dare ”l’illusione” che lo sia
(figura 4.12).
4.5.2
Split Driver Monitor: I/O RIngs
Xen frappone un’ulteriore protezione tra i Guest-OS e gli I/O device presentando però la necessita di un meccanismo per il trasferimento dei dati tra
i due con il minor overhead possibile, si deve quindi minimizzare il lavoro
per demultiplexare i dati verso uno specifico dominio quando viene ricevuto
un interrupt da un device e per evitare interferenze sui buffer condivisi, la
46
Figure 4.12: Mappatura della Memoria
memoria impegnata dai dispositivi deve essere fornita da i domini stessi ove
possibile (gli I/O buffer sono protetti durante il trasferimento dei dati). Nella
figura 4.13 possiamo osservare l’architettura di gestione della comunicazione
tra i Guest-OS e gli I/O device con una coda circolare di descriptor assegnati
da un dominio ma accessibili soltanto da Xen. I descriptor non contengono
direttamente i dati e gli I/O buffer vengono allocati out-of-band (al di fuori
del canale di comunicazione stabilito) dal Guest-OS e fanno indirettamente
riferimento agli I/O descriptor.
L’accesso ad ogni anello è permesso da due coppie di puntatori produttore/consumatore, infatti i domini inseriscono le loro richieste su un anello
facendo avanzare il puntatore delle richieste del produttore, nel contempo
Xen rimuove queste richieste per poterle soddisfare facendo avanzare il puntatore associato alla richiesta del consumatore. Le risposte vengono inserite
da Xen come produttore e vengono rimosse dal Guest-OS come consumatore.
Non è necessario che le richieste siano soddisfatte nell’ordine in cui sono state
inserite, in quanto il Guest-OS associa un indentificatore unico alla richiesta,
che viene conservato anche nella relativa risposta; questo meccanismo permette a Xen di riordinare le operazioni di I/O senza ambiguità in base alla
priorità dello scheduling che si sta utilizzando.
Questo tipo di struttura è sufficientemente astratta per poter supportare le
più diverse tipologie di device e il disaccoppiamento tra la produzione di
richieste e la produzione delle risposte dalle controparti permette ad ogni
dominio di diminuire la latenza e i requisiti di throughput:
47
Figure 4.13: I/O Rings
• Request: un dominio può accodare entry multiple prima di invocare
l’hypercall per avvertire Xen;
• Response: un dominio può differire la consegna di un evento di notifica
specificando un numero minimo di response;
4.6
La virtualizzazioen della CPU presenta diverse implicazioni per i sistemi
operativi guest, principalmente l’inserimento di un hypervisor al di sotto
del sistema operativo viola il principio per cui il sistema operativo deve essere eseguito con il privilegio maggiore. Come abbiamo detto precedentemente il Guest-OS deve essere eseguito con privilegi inferiori per proteggere
l’hypervisor da loro comportamenti inaspettati e per garantire l’isolamento
tra le macchine virtuali.
Qualsiasi sistema operativo che opera solamente sul ring 0 può essere modificato per lavorare sul ring 1 e quindi essere paravirtualizzato (o virtualizzato)
con Xen, ma a questo punto non può più eseguire direttamente le istruzioni
privilegiate nonostante resti comunque isolato dalle applicazioni che lavo-
48
rano invece sul ring 3. Le piattaforme x86 permettono questa modifica dato
che supportano i quattro distinti livelli di privilegio. I sistemi operativi che
cercano di eseguire operazione privilegiate quindi falliscono per insufficienza
di privilegi e l’unico modo per permettere ad un sistema operativo guest
l’esecuzione di queste operazioni è quello di ottenere la validazione da Xen,
parliamo quindi di istruzioni paravirtualizzate.
Oltre alle istruzioni abbiamo anche le eccezioni virtualizzate, infatti i memory fault e le trap sono virtualizzate da Xen tramite una tabella che descrive
la modalità di gestione di ognuna di esse. Un’altra importante differenza
tra sistemi virtualizzati e i sistemi nativi riguarda la gestione degli errori di
pagina (page fault). Normalmente viene letto il registro CR2 per recuperare
l’indirizzo della pagina che ha causato l’errore, invece il sistema operativo
guest eseguito sul ring 1 non ha accesso a tale registro quindi Xen scrive
l’informazione in un zona diversa dove il sistema operativo guest può reperire
questo dato.
Questa tecnica permette di trattare gli errori di pagina in modo efficiente,
senza penalizzare le prestazioni dato che i page fault si verificano con elevata
frequenza.
4.7
Virtual Machine Scheduling
Xen deve assicurare che ad ogni host venga assegnato un determinato tempo
di CPU cercando di ottenere un buon compromesso tra un’esecuzione equa
dei domini ed un elevato throughput complessivo cosı̀ come avviene nei sistemi multitasking; deve inoltre poter fornire virtual server in varie forme di
contratto che infatti rappresenta uno dei principali vincoli nella progettazione
del meccanismo di scheduling delle macchine virtuali.
In Xen abbiamo quattro meccanismi di scheduling delle macchine virtuali:
1. Borrowed Virtual Time (BVT): questo algoritmo è work-conservative,
ossia alloca e occupa tutti i processori fisici disponibili, ed è dotato di
un sistema di ripresa immediata di un DomU nel momento in cui questo
riceve un’evento di notifica. Questa tecnica consente di assegnare ad
ogni sistema operativo guest un determinato Virtual-Time-Slot in base
ad un peso relativo.
2. Simple Earliest Deadline First (SEDF): questo algoritmo supporta sia l’allocazione work-conservative sia l’allocazione non work-
49
conservative, è quindi possibile assegnare non più del 50% della CPU ad
un determinato DomU e la macchina virtuale non supererà mai quella
soglia anche se non ci sono altri sistemi operativi guest in esecuzione
sull’host fisico. Come nel BVM, è possibile assegnare delle priorità tra
le varie macchine virtuali utilizzando il concetto di slice e period (ad
esempio possiamo avere 20 ms di slice su 100 ms di period).
3. Credit Scheduler (CS): anche questo algoritmo supporta l’allocazione
work-conservative e non work-conservative ma per garantire diversi livelli di priorità tra macchine virtuali utilizza il concetto di weight e di
cap
• il weight è parametro proporzionale, ad esempio un DomU che ha
un weight di 512 riceve un tempo di CPU doppio rispetto ad un
DomU che ha weight di 256 (quota di default);
• il cap è un parametro opzionale e fissa la quota massima che un
DomU è in grado di utilizzare, ad esempio 400 corrisponde al
valore di utilizzo di 4 CPU, 100 per utilizzo di 1 CPU e 50 per
metà CPU (di default è 0 e significa che non sono imposti limiti
di utilizzo);
4. Nuovo Scheduler: Xen mette a disposizione un’interfaccia astratta
per definire un nuovo scheduler, struttura (figura 4.14), che consente
di indirizzare le proprie funzioni di scheduling. Una volta che l’utente
ha implementato il proprio scheduler e ne ha definito la sua struttura, è necessario editare il file /xen/common/schedule.c nel quale
sono dichiarati gli scheduler come extern struct; eseguiti questi passi
bisognerà aggiungere la risorsa al Makefile per poter ricompilare i sorgenti di Xen e riavviarlo utilizzando come input il nome dello scheduler.
Figure 4.14: Struct Scheduler
50
Chapter 5
Testing
Per poter suddividere le ampie risorse di un computer moderno il sistema
più utilizzato é la virtualizzazione, argomento ampiamente discusso e approfondito in letteratura. I diversi lavori già realizzati mostrano confronti tra
vari sistemi di virtualizzazione cercando sempre di mettere in competizione
due o più concorrenti simili a livello tecnologico. Questa scelta è ovviamente
corretta, ma cosa succede se non si ha a disposizione hardware di ultimissima generazione e quindi si vuole consolidare un’infrastruttura al fine di
massimizzarne l’uso? Le scelte che abbiamo fatto si basano tutte su una
domanda: qual è il migliore sistema di virtualizzazione in uno scenario reale?
Lo scopo del benchmarking delle performance non è quello di trovare bug,
ma è quello di impegnarsi in un processo controllato di valutazione e analisi
di indici di performance del software. Idealmente, il software in prova è già
abbastanza stabile e quindi la fase di analisi può procedere senza alcun intralcio. Il primo passo per la valutazione è quello di definire gli obiettivi dei test
che si vogliono eseguire. Per il nostro lavoro non avendo a disposizione gli
strumenti tipicamente utilizzati nei test di sistemi operativi (come ad esempio la suite http://www.spec.org/), si è scelto di realizzare una valutazione
sulle macchine virtuali con alcuni software di benchmark che mirano a fornire
un quadro generale delle performance di una macchina virtuale in esecuzione
su un sistema di virtualizzazione. Gli indici di riferimento utilizzati per la
valutazione riguardano le prestazioni di CPU, memoria e disco.
I sistemi di virtualizzazione scelti considerano i due principali approcci,
ovvero l’Hardware Virtualization (HV) e Paravirtualization (PV). In una
51
CHAPTER 5. TESTING
52
prima fase di test si è tenuta in considerazione l’Hardware Virtualization
con l’hypervisor ESXi e la Paravirtualization con Xen; dopo una prima valutazione dei dati raccolti, al fine di ottenere un quadro della situazione
più realistico e per aggiungere un ambiente poco considerato in letteratura
ma comunque molto utilizzato, si è scelto di introdurre anche un terzo sistema di virtualizzazione che si va a posizionare al livello delle applicazioni
ossia VMware Player. Come già mostrato la PV a differenza dell’HV necessita di un sistema ospite, questa differenza rendeva i dati ottenuti non confrontabili, quindi é stato necessario aggiungere un terzo termine di paragone
dato dall’HV hosted virtualizzation che filosoficamente si avvicina maggiormente alla PV.
Abbiamo selezionato due tipologie principali di test: Relative Performace
e Cuncurrent Performace. La prima mira a valutare i tre sistemi secondo gli
indici precedentemente enunciati, la seconda ripete i test precedentemente
effettuati considerando però una loro esecuzione in parallelo su due distinte
macchine virtuali in esecuzione sul sistema. Sia per le Relative Performance
che per le Cuncurrent Performance si è scelto di utilizzare CentOs 6.1 come
sistema virtualizzato, data la disponibilità del kernel 2.6.32-220.el6.i686 per
Xen. Le macchine virtuali sono state create con 20 Gb di storage, 1 Gb
di RAM e 1 VCPU. I benchmark utilizzati sono disponibili gratuitamente al
download sul sito di Roy LongBottom http://www.roylongbottom.org.uk/
uno dei massimi esponenti nelle consulenze sulle performance di sistemi.
Nelle numerose suite di benchmark disponibili sono state selezionate: classic
benchmark, memory benchmark e Burn-In and Reliability Testing Apps;
tutte e tre le suite vengono utilizzate nelle due tipologie di test sopra descritte.
5.1
Hardware
Dopo una prima ricerca di un’infrastruttura in grado di supportare tutti i
sistemi di virtualizzazione scelti, si è passato alla ricerca di una infrastruttura in grado di supportare ESXi visti i numerosi problemi di compatibilità
dell’hypervisor, problema non riscontrato negli altri due sistemi di virtualizzazione.
Per poter avvicinare i risultati dei benchmark ad uno scenario quanto il più
reale possibile ed a causa dei vincoli imposti dal limitato hardware a disposizione, si è scelto il migliore compromesso tra garanzie di esecuzione di
CHAPTER 5. TESTING
53
test concorrenti e probabilità di trovare un hardware simile in un’azienda di
piccole/medie dimensioni. Oltre a queste motivazioni, le scelte dell’hardware
sono state vincolate anche dalla letteratura: ad esempio in [21] viene mostrato
un confronto tra Xen, VMware Workstaion, User mode Linux e l’hardware
utilizzato era un server Dell 2650 dual processor 2.4 GHz Xeon con 2Gb di
RAM.
Per questo lavoro abbiamo aggiornato l’hardware usato in [21] con un più
recente IBM E-Server X-Series dual processor 2.4 GHz Xeon con HyperThreding, 3Gb di RAM e 2 dischi SCSI da 36.4 GB l’uno a 15000 rpm.
Gran parte di questo lavoro dovrebbe riguardare l’installazione e configurazione dei tre sistemi di virtualizzazione, ma lo scopo principale è l’analisi
dei risultati dei benchmark effettuati, quindi presentiamo solo una breve introduzione all’installazione e configurazione dei tre sistemi. I problemi riscontrati non sono stati solo quelli dettati dalla compatibilità con ESXi, ma una
volta scelta una macchina che lo supportasse, sono sorte diverse problematiche legate alla configurazione sia di Xen che di VMware player, aspetti
trattati nel dettaglio nei tre paragrafi di installazione dei sistemi.
5.1.1
Installazione VMware ESXi 3.5
L’hardware scelto offre il pieno supporto per l’installazione dell’hypervisor
ESXi di VMware. L’utilizzo di hardware di vecchia generazione ha imposto
un vincolo sulla versione da utilizzare, in questo caso la 3.5; hardware più
recente avrebbe consentito l’utilizzo delle ultime versioni di ESXi.
Il primo passo da eseguire è la registrazione sul sito di VMware http:
//www.VMware.com/it/, dal momento che l’hypervisor viene fornito in licenza gratuita mentre tutti gli strumenti di gestione come vSphere sono in licenza gratuita solo per 60 giorni. A questo punto è possibile eseguire il download della versione di ESXi desiderata in formato immagine .iso, scegliendo
quindi la masterizzazione su supporto o l’avvio dell’installazione da dispositivo usb, se supportato dallo specifico hardware.
L’installazione del server VMware ESXi è una semplice procedura guidata
senza nessuna configurazione possibile, solo in fase di post installazione è
possibile configurare le interfacce di rete, la password di sistema e le restanti
impostazioni.
L’ultimo passo è l’installazione del client di gestione remota vSphere. L’unica
reale limitazione del software di gestione è la presenza di una versione disponibile unicamente per il sistema operativo Microsoft Windows. L’installazione
CHAPTER 5. TESTING
54
del software di gestione non richiede alcuna configurazione tranne quella per
la creazione della connessione con il server (indirizzo ip , nome utente, password).
Una volta avviato il client di gestione è possibile inserire all’interno del data
stored di ESXi una risorsa condivisa tra le macchine virtuali, con tale procedura si può caricare un file immagine .iso di un qualsiasi sistema operativo
supportato. Successivamente, tramite un’interfaccia grafica molto intuitiva si
possono seguire gli ultimi semplici passi al fine di installare un sistema operativo, procedura analoga ad un’installazione su hardware reale. Per i nostri
scopi sono state eseguite due installazioni di CentOs 6.1 a 32bit avvenute
senza problemi, anche se la seconda installazione si sarebbe potuta evitare
utilizzando la funzione di clonazione delle macchine virtuali del server ESXi,
che però non è disponibile nelle versioni con licenza gratuita. Di seguito
troviamo i riferimenti ad alcuni screenshot di vSphere in esecuzione su un
sistema operativo Windows 7 64 bit:
• Summary Virtual Machine 5.1.1
• Performance Virtual Machine 5.1.1
• Grafici di esecuzione due Virtual Machine su ESXi 5.1.1
Come è possibile notare l’ambiente fornito consente una gestione molto semplificata ed intuitiva delle macchine virtuali, astraendo al massimo la complessità del sistema con un’applicazione che in versione completa consente
funzionalità avanzate con il minimo sforzo.
5.1.2
Installazione Xen 4.1, Ubuntu hosted
La procedura per l’installazione dell’hypervisor Xen è ben più complessa
come del resto la filosofia che c’è dietro. Il primo passo è la scelta del sistema
operativo host per Xen e la relativa versione da utilizzare, scelta che non
rappresenta un grosso problema dato che dal kernel 2.6.x di Linux è possibile
utilizzare una qualsiasi distribuzione Linux per l’installazione a Dom0 level.
Per motivi di supporto da parte di un’ampia community open-source abbiamo scelto la versione di Linux Ubuntu server 12.04 LT.
Durante l’installazione del sistema è possibile scegliere di installare da subito
anche il kernel per Xen 4.1 in versione 3.2.0-23, dato che si sta utilizzando
la versione server di Ubuntu. Per consentire una configurazione semplice del
CHAPTER 5. TESTING
55
Figure 5.1: Summary Virtual Machine ESXi
sistema si consiglia l’installazione di gnome unity (un ambiente grafico per
Ubuntu) con l’esecuzione del comando :sudo apt-get install ubuntu-desktop.
A questo punto l’ambiente dispone di una interfaccia grafica e della possibilità di avviare il sistema operativo col kernel Xen a Dom0 level, infatti il
bootloader utilizzato da questa versione di Ubuntu Server è il Grub 2.0 che
essendo autoconfigurante al secondo riavvio permette già la selezione del kernel di Xen, anche se quest’ultimo però non avvia realmente il demone ”xend ”
di Xen.
Il prossimo passo è la reale configurazione di Xen per la sua corretta esecuzione, é necessario quindi modifcare il file di configurazione di Xen
:/ect/xen/xend-coinfig.sxp e decommentando le seguenti linee:
• (xend-unix-server yes: abilita l’esecuzione del server in Dom0 (modificare il parametro da no a yes).
• (xend-unix-path /var/lib/xend/xend-socket): abilita la comunicazione con l’hypervisor.
• (network-script network-bridge): script necessari alla configurazione
network di xen.
CHAPTER 5. TESTING
56
Figure 5.2: Performance Virtual Machine ESXi
• (vif-script vif-bridge): script necessari alla configurazione network di xen.
Una volta modificato il file è possibile riavviare il demone di Xen xend
stop/start. Per facilitare l’installazione e la gestione dell’hypervisor è possibile installare le librerie libvirt e virt-manager mostrate in figura 5.1.2.
Quest’ultima consente di comunicare con l’hypervisor per poterlo monitorare e installare le nuove macchine virtuali; in questo lavoro non è stato
possibile utilizzare virt-manager per installare le macchine virtuali, dato che
l’hardware disponibile supporta solo la paravirtualizzazione e quindi il tool
non consentiva l’installazione da un disco virtuale/reale. L’installazione di
un sistema operativo guest in paravirtualizzazione necessita di alcuni passi
prima di poter essere eseguita. La prima cosa da fare è quella di reperire
il kernel per il sistema operativo che si vuole installare con supporto per la
paravirtualizzazione, nel nostro caso è stato possibile eseguire il download dei
due file necessari initial ram disk (initrd.img) e il file linux kernel bootable
compresso(vmlinuz) con i comandi:
wget http://mirror.centos.org/centos/6/os/i386/images/pxeboot/initrd.img
/boot/xen-initrd.img
CHAPTER 5. TESTING
57
Figure 5.3: Esecuzione Virtual Machine ESXi
wget http://mirror.centos.org/centos/6/os/i386/images/pxeboot/initrd.img
/boot/xen-vmlinuz. A questo punto è possibile creare il disco che verrà utilizzato dalla macchina virtuale tramite la creazione di un file immagine con il
comando:dd if=/dev/zero of=/srv/xen/tua-machine.img oflag=direct
bs=1M count=2048 il quale crea un file inizializzato a zero di dimensione 2
Gb. È ora possibile creare un file necessario all’avvio dell’installazione del
sistema che chiameremo centos-make, in questo può essere definito il kernel di
avvio della macchina virtuale la dimensione della RAM, il numero di vCPU,
il disco da utilizzare e le interfacce di rete ed ulteriori parametri. Per i nostri
scopi il file utilizzato è mostrato nel seguente listato:
kernel = "/boot/xen-vmlinuz"
ramdisk = "/boot/xen-initrd"
name = "centos01"
memory = "1024"
disk = [ ’file:/srv/xen/tua-machine.img,xvda,w’, ]
vif = [ ’bridge=br0’, ]
vcpus=1
CHAPTER 5. TESTING
58
Figure 5.4: VIrtual Machine Manager for Xen and KVM
on_reboot = ’destroy’
on_crash = ’destroy’
Una volta creato il file è possibile avviare la macchina virtuale tramite il
comando: xm create centos-make; l’hypervisor a questo punto avvia una
nuova macchina virtuale con identificativo ”centos01” ed é quindi possibile
avviare la console di installazione con il comando: xm console centos01.
Adesso la console della macchina virtuale presenterà l’avvio del gestore di installazione di CentOS Anaconda ed è quindi possibile procedere all’installazione
classica di CentOS nella modalità testuale o nella modalità vnc, entrambe
utilizzando l’installazione network di CentOS dal mirror:
http://mirror.centos.org/centos/6/os/i386/.
Una volta installato il sistema per avviare la macchina virtuale, si deve
modificare il file precedentemente creato ”centos-make” in ”centos-boot” inserendo una nuova linea bootloader="/usr/bin/pygrub" che all’avvio della
macchina virtuale carica il bootloader per l’esecuzione normale del sistema
operativo; inoltre bisogna modificare
on_reboot = ’destroy’ on_crash = ’destroy’
in
on_reboot = ’restart’ on_crash = ’restart’
CHAPTER 5. TESTING
59
che consente l’utilizzo classico della macchina virtuale.
Seguiti questi passi si può riavviare la macchina virtuale con il comando
xm create centos-boot e caricare la console con il comando xm console
centos01. Normalmente tutto dovrebbe funzionare, ma nel nostro caso il
bridge network non funzionava in modo del tutto automatico come da documentazione di xen, è stato quindi necessario ad ogni avvio della macchina virtuale cambiare il mac address con quello assegnato dall’hypervisor alla specifica macchina virtuale. Per eseguire questa configurazione, si deve innanzitutto verificare questo indirizzo con il comando xm network-list centos01,
il quale visualizza tutte le interfacce di rete virtuali assegnate alla macchina
virtuale CentOS e relativi mac address. Visualizzato il mac address é quindi
possibile impostarlo nella macchina virtuale; nel caso di CentOS ciò è possibile editando il file in /etc/sysconfig/network-scripts/ifcfg-eth0 che
si presenta come:
DEVICE="eth0"
BOOTPROTO="dhcp"
HWDDR="mac address asseganto dall’hypervisor"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPADDR=indirizzo ip
NETMASK=maschera ip
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
Una volta impostato il mac address corretto bisogna riavviare il gestore
delle interfacce di rete con la sequenza di comandi: /etc/init.d/network
stop e /etc/init.d/network start. Un vantaggio di Xen è che una possibile soluzione alla duplicazione di una macchina virtuale è quella di copiare
il disco immagine e duplicare il file di avvio cambiando l’identificativo della
macchina virtuale e il disco che si vuole utilizzare.
5.1.3
Installazione VMware Player,Ubuntu hosted
Per l’installazione di VMware Player, previa registrazione sul sito di VMware,
è necessario scaricare l’installer della versione che si vuole utilizzare. Per
questo lavoro non è stato possibile utilizzare l’ultima versione 4.x per limitazioni sull’hardware disponibile, è stata quindi utilizzata la versione 3.1.6. A
CHAPTER 5. TESTING
60
seguire una serie di problematiche affrontate: una volta installato il pacchetto
come un normale eseguibile l’applicazione non si avviava mostrando l’errore
”Unable to build kernel module” e per ovviare a questo problema é stata
necessaria l’esecuzione di una patch disponibile in rete per la versione 3.1.5,
che ha comportato la modifica del file contenente lo script modificando la
versione in 3.1.6. Una volta eseguita la patch tutto funziona normalmente ed
è possibile installare le macchine virtuali con una comoda interfaccia grafica.
Anche in questo caso è stato possibile effettuare la clonazione della macchina
eseguendo la copia del file tua-macchina.vmk in tua-macchina2.vmk, l’unico
problema rilevato è stato nell’esecuzione parallela delle macchine virtuali, infatti VMware Player in esecuzione su Linux non consente di eseguire più
macchine virtuali e per fare ciò abbiamo avviato una seconda istanza del
player da un secondo utente.
5.2
5.2.1
Test
Roy Longbottom’s PC Benchmark
Per effettuale il testing dei sistemi di virtualizzazione è stata utilizzata Roy
Longbottom’s PC Benchmark Collection http://www.roylongbottom.org.
uk/, una suite gratuita di test per valutare le performance di CPU, cache,
memoria, dischi, grafica in diversi ambienti (Windows e Linux). Gli applicativi sono disponibili in formati compressi zip o tar.gz e possono essere
eseguiti senza necessità di installazione (click-and-go). I risultati dei test
sono memorizzati in file log di testo. Tra le diverse suite di benchmark sono
state scelte:
1. Classic Benchmarks
2. Memory Benchmark
3. Burn-In and Reliability Testing Apps
5.2.1.1
Classic Benchmarks
Sono i primi programmi usati per misurare le performance relative di macchine. Questa suite è composta da:
• Livermore Kernels (Livermore Loops)
CHAPTER 5. TESTING
61
• Whetstone Benchmark
• Dhrystone Benchmarks 1.1 e 2.1
• Linpack Benchmark
Livermore Kernels (Livermore Loops) Il benchmark Livermore loops,
creato da Framcis H. McMahon, è stato progettato per computer paralleli
che effettuavano calcolo scientifico al Lawrence Livermore National Laboratory. Pubblicato nel 1986 in Livermore fortran kernels: A computer test of
numerical performance range, fu inizialmente scritto in Fortran ed in seguito
è stato effettuato il porting in altri linguaggi di programmazione. Inizialmente comprendeva 14 kernel di applicazioni numeriche che sono state poi
portate a 24 negli anni ’80 e le performance vengono misurate in milioni di
operazioni in virgola mobile per secondo o MFLOPS.
Il programma inoltre controlla l’accuratezza dei risultati ottenuti e per evitare
di effettuare un confronto su una singola serie di risultati, i 24 kernel vengono eseguiti 3 volte con intervalli differenti di do loop per produrre vettori
di risultati corti, medi e lunghi. Ogni loop effettua le seguenti operazioni
matematiche:
1. frammeto di idrodinamica
2. gradiente coniugato di Cholesky incompleto
3. prodotto interno
4. soluzione di fasci di sistemi lineare
5. soluzione di sistemi lineari tridiagonali
6. equazioni di ricorrenza
7. equazioni di stato frammento
8. direzione di integrazione alternata implicita
9. integrare i predittori
10. differenziare i predittori
11. prima somma
CHAPTER 5. TESTING
62
12. prima differenza
13. particella 2-D in una cella
14. particella 1-D in una cella
15. Fortran casuale
16. ricerca Monte Carlo
17. computazione implicita condizionale
18. frammento di idrodinamica esplicito in 2-D
19. trasporto di coordinate discrete
20. trasporto matrice-matrice
21. distribuzione di Planckian
22. frammento di idrodinamica implicito in 2-D
23. ricerca del minimo di un array
Dai risultati emerche che la media geometrica potrebbe essere utilizzata come
valore di riferimento per le performance ma nel test non viene utilizzata solo
la media geometrica ma sono utilizzate la media geometrica, armonica e
aritmetica con l’aggiunta di un risultato minimo e massimo.
Whetstone E’ un benchmark sintetico per valutare le performance di computer ed é stato presentato in [17]. Implementato inizialmente in Algol60 nel
1972 al National Physical Laboratory, il benchmark misura la potenza computazionale in unità di kilo-Whetstone Instructions Per Second (kWIPS),
successivamente cambiate in Millions of Whetstone Instructions Per Second
(MWIPS). Il benchmark Whetstone si concentra principalmente sul testing
dell’aritmetica floating-point. Abbiamo nove parametri risultanti che cercano
di riassumere le performance generali di un sistema:
1. MWIPS, milioni di istruzioni whetstone per secondo.
2. MFLOP1, test su operazioni floating point.
CHAPTER 5. TESTING
63
5. COSMOPS, test sul calcolo delle funzioni seno, coseno, etc.
6. EXPMOPS, test sul calcolo di espressioni, radici quadrate etc.
7. FIXPMOPS, test su operazioni fixed point.
8. IFMOPS, test su operazioni if-then-else.
9. EQMOPS, test su operazioni di assegnamento.
Tutta la suite è pre-compilata in C/C++ ed è disponibile in una prima
versione ottimizzata e in una seconda versione non ottimizzata e nel nostro
lavoro vengono considerate entrambe le versioni della suite.
Dhrystone Presentato in [19], sviluppato nel 1984 da Reinhold P. Weicker,
in un primo momento implementato in ADA, è diventato un benchmark
rappresentativo per la valutazione delle performance di CPU. Il programma
è caratterizzato da una varietà di costrutti comuni: chiamate a procedure,
referenziazioni di puntatori, assegnamenti.
Dalla versione 1.1 il programma è stato invece implementato in C per Unix
a cura di Rick Richardson. L’output del benchmark è misurato in numero di
Dhrystones per secondo, cioè il numero di iterazioni al secondo del loop della
main. La differenza fra Dhrystone e Whetstone, benchè sono entrambi dei
programmi di benchmark sintentici, è che il primo non effettua operazioni in
floating point. I risultati del test sono quattro parametri, tutti espressi in
MIPS:
1. Dhry 1 OPT, operazioni dhrystone in versione 1.1 con codice precompilato ottimizzato.
2. Dhry 1 NoOPT, operazioni dhrystone in versione 1.1 con codice precompilato non ottimizzato.
3. Dhry 2 OPT, operazioni dhrystone in versione 2.1 con codice precompilato ottimizzato.
4. Dhry 2 NoOPT, operazioni dhrystone in versione 2.1 con codice precompilato non ottimizzato.
CHAPTER 5. TESTING
64
Linpack Linpack, presentato in [18], è una libreria software sviluppata per
eseguire operazioni di algebra lineare, basata su BLAS (Basic Linear Algebra Subprograms), scritta inizialmente in Fortran da Jack Dongarra,
Jim Bunch, Cleve Moler, e Gilbert Stewart e successivamente riscritta in C.
L’ultima versione standard in C utilizza matrici di 100x100 in doppia precisione, ma esistono anche versioni con matrici di grandezza diversa.
I Benchmark Linpack sono utilizzati per valutare le perfomance dei computer nelle operazioni in floating point, più precisamente questi test misurano
quanto rapidamente un computer risolve un sistema di equazioni lineari di
classe N del tipo Ax = b.
Risolvendo questo sistema con l’eliminazione di Gauss con pivoting sono
necessari 32 N β + 2N 2 operazioni in virgola mobile. I risultati di questi benchmark sono espressi in operazioni in virgola mobile per secondo FLOPS.
Anche in questa suite sono presenti due versioni pre-compilate, una senza
ottimizzazione e una ottimizzata, entrambe considerate per questo lavoro.
5.2.1.2
Memory Benchmark
La suite Memory Benchmark comprende tre applicazioni che mirano a valutare le performance della memoria di un sistema. Nei prossimi paragrafi
analizzeremo i componenti della suite:
• RandMem
• SSEfu
• BusSpeed
RandMem Il RandMem benchmark esegue otto test per valutare la velocità di trasferimento in MBps dalla cache e dalla memoria. Vengono utilizzati dati la cui taglia viene incrementata a partire da 4 Kb fino a 1048576
Kb e, impiegando indirizzi in serie e random, vengono effettuate operazioni
di read e read/write per interi di 32 bit floating. Lo scopo di questo test è
mostrare quanto è lento l’accesso alla memoria in maniera casuale. La velocità può essere considerevolmente influenzata dalla lettura e scrittura di
dati a raffica, dove la maggior parte di questi è ridondante. I risultati forniti
sono suddivisi in due classi, la prima utilizza valori Integer la seconda utilizza valori Double/Integer. A loro volta queste due classi si suddividono in
accesso seriale e casuale.
CHAPTER 5. TESTING
65
SSEfu Questo benchmark misura la velocità dalla cache e dalla RAM in
precisione singola e doppia dello streaming di dati, utilizzando dati di diverse
dimensioni che vanno da 4 Kb a 1048576 Kb. Utilizza istruzioni SSE(SP)
e SSE2(DP) insieme al codice compilato C che produce vecchie istruzioni
x87 a 32bit. Per eseguire la valutazione delle prestazioni della memoria in
Mb/s,questo benchmark utilizza tre operazioni particolari al fine di minimizzare l’overhead di accesso alla memoria, che sono:
1. s = s + x[m] ∗ y[m]
2. x[m] = x[m] + y[m]
3. (s + x[m])?y[m] una volta utilizzando l’operatore di moltiplicazione(*)
e una volta l’operatore di addizione(+)
Le tre operazioni definiscono tre classi di risultati, nelle prime due abbiamo tre risultati SSE2, SEE e Sng1 che rappresentano istruzioni SEE, SEE2
e l’ultimo Sng1 rappresenta l’esecuzione dell’istruzione dal compilatore C.
Nell’ultima *SSE e +SEE rappresentano l’operazione con istruzioni SSE alternando l’operatore.
BusSpeed Questo benchmark è progettato per identificare la lettura dei
dati a raffica su un bus a 32bit, utilizzando interi di 32bit. Il programma
inizia leggendo una word per poi leggere i dati successivi incrementando il
registro di 32 words, l’incremento viene ridotto a 16 words per poi dimezzarsi
per ogni test fin quando tutti i dati non vengono letti, l’ultima fase legge tutti
i dati utilizzando le istruzioni SSE.
I risultati prodotti dal benchmark sono strettamente legati alle operazioni che
vengono eseguite infatti abbiamo sette parametri per nove dimensioni differenti in taglia da 6Kb a 393210Kb, che sono: Inc32wds, Inc16wds, Inc8wds,
Inc4wds, Inc2wds, ReadAll e l’ultimo 128bSSE2, esattamente come per i
passi dell’algoritmo precedentemente descritto.
5.2.1.3
Burn-In and Reliability Testing Apps
È un benchmark progettato per sistemi Linux, che comprende una serie di
stress Test della CPU, della cache, della RAM, dei Bus, dei Dischi e di altri
device utilizzando processi ad alta velocità per incrementare le temperature
e varia l’ordine dei bit dei dati per investigare su possibili fault dei pattern
CHAPTER 5. TESTING
66
conosciuti. I dati letti e i risultati dei calcoli vengono anche ricontrollati per
assicurare la correttezza e la consistenza dei valori.
I test utilizzati della suite sono:
• BurninSSE
• DriveStress
• IntBurn32
• Livermore Loops
BurninSSE Il testo BurninSSE è basato sul benchmark OpenMP (un set
di procedure e software che esegue processi paralleli su dati in memoria condivisa), dove il programma compilato senza le direttive OpenMP viene eseguito
molto velocemente a causa del compilatore GCC che genera codice ottimizzato tramite istruzioni SSE. Le operazioni aritmetiche eseguite sono nella
forma x[i] = (x[i] + a) ∗ b − (x[i] + c) ∗ d + (x[i] + e) ∗ f con 2, 8 o 32 operazioni
per data word. L’esecuzione dei test avviene in 4 passi, in ognuno del quale
si eseguono delle operazioni sulla memoria condivisa e si calcola un rate in
MFLOPS.
DriveStress Questo benchmark scrive 4 file utilizzando 164 blocchi di 64
KB(10.25 MB) e ogni blocco contiene un unico pattern di dati. Il file viene
quindi letto per due minuti in modo casuale, con un controllo sui dati e
sull’ID del file per verificarne la correttezza. Con i moderni dischi la velocità
di trasferimento dei dati viene mantenuta costante leggendo dal buffer del
disco ed infine ogni blocco viene letto ripetutamente da un file per un secondo
a velocità massima del bus buffer (che è soggetto all’overhead per la grandezza
del blocco). Per mantenere il trasferimento dei dati molto veloce il controllo
sulla correttezza dei dati viene eseguito ogni 20 passi. I risultati espressi
sono di due classi la prima, che riguarda la scrittura dei file viene valutata in
secondi mentre la seconda, ovvero l’operazione di lettura in cui viene valutato
il numero di volte che si riesce a leggere un file a tempo fissato.
IntBurn32 Il benchmark IntBurn32 consiste in 12 test di aggiunta e sottrazione di differenti pattern di dati, i primi sei alternano scrittura e lettura
di dati mentre gli ultimi sei sono in sola lettura. Ogni risultato viene controllato per essere sicuro della correttezza del calcolo. Facendo uso della cache
CHAPTER 5. TESTING
67
le performance dipendono dalla velocità dellla CPU. I risultati sono espressi
in MB/s per ognuno dei 12 test.
Livermore Loops , la suite livermore loops può essere utilizzata per eseguire test di burn-in, dato che i parametri d’esecuzione dei 24 kernel, di
cui abbiamo parlato nel paragrafo Livermore Kernels, sono modificabili e
ogni risultato dei test viene controllato per verificarne la correttezza. I 24
kernels vengono eseguiti tre volte, 5 secondi per test per un tempo totale
di esecuzione di circa 6 minuti. Questo becnhmark è stato utilizzato come
burn-in/reliability test dopo che, a causa di un tempo di esecuzione molto
lungo e un logging di tutti gli errori che si sono verificati, ha causato il crash
di sistema durante l’esecuzione di un overclock di un Pentium pro. I risultati
come per Livermore Kernels sono quattro espressi in MFLOPS per 24 loops
e sono: valore massimo e minimo, media aritmetica, geometrica e armonica.
5.3
Risultati
I prossimi paragrafi mostrano i risultati ottenuti nella fase di benchmarking.
L’analisi delle performance dei tre sistemi di virtualizzazione si suddivide
in due classi principali: Relative Performance e Cuncurrent Performance,
rispettivamente l’analisi delle prestazioni di una singola virtual machine e
l’analisi delle prestazioni dell’esecuzione concorrente di due virtual machine.
In entrambe le classi sono presentate tre tipologie di test, precedentemente
descritte, che mirano a valutare gli aspetti più rilevanti dell’esecuzione di un
sistema operativo in una macchina virtuale.
Nella prima fase è stato testato l’hypervisor ESXi successivamente Xen, dopo
queste prime due fasi si è scelto di introdurre nei test il terzo sistema di virtualizzazione VMware Player. Come sarà mostrato nei successivi paragrafi
l’hypervisor ESXi mantiene risultati stabili in tutte le tipologie, a differenza
di Xen e VMware Player che variano le loro performance per certi aspetti in
modo sorprendente.
Per ogni sistema è stato prima eseguito Relative Performance e successivamente Cuncurrent Performance; ogni macchina virtuale monta il sistema
operativo CentOs 6.1 con 1 GB di RAM, 1 vCPU e 20 GB di storage ed
un virtual network per il recupero dei file di benchmarking. Oltre ai risultati di benchmarking dei tre sistemi siamo riusciti anche a trarre delle valutazioni per quanto concerne l’installazione e l’utilizzo dei sistemi. I sis-
CHAPTER 5. TESTING
68
temi differiscono per installazione, gestione, tecnologia di virtualizzazione
adottata. Le maggiori differenze sorgono tra Xen e ESXi in quanto ESXi
vince in termini di semplicà d’uso e tempi di operatività. Nel Relative
Performance dove viene utilizzata la suite Classic Benchmark Xen mostra
migliori performance nell’utilizzo della CPU e della cache in situazioni di
codice pre-compilato ottimizzato, anche se non si nota un forte divario tra
le varie piattaforme tranne che per l’ottima gestione della cache ottenuta da
VMware Player. Le prestazioni migliori di Xen, per quanto riguarda Classic
Benchmark, diminuiscono nell’esecuzione concorrente di due macchine virtuali; ESXi riesce a garantire una stabilità in termini di performance straordinaria, mentre Xen inizia a non avere performance stabili su entrambe le
macchine e in tutte le situazioni. La seconda parte dei benchmark, Memory Benchmark, sia per Relative che per Cuncurrent Performance mostra un
miglioramento nella velocità di gestione del bus da parte di VMware Player
per alcune dimensioni di file utilizzati e un’ottima gestione della memoria da
parte di Xen. L’ultima parte del benchmark Burn-In and Reliability Testing
Apps, mette in mostra la gestione dell’I/O da parte di VMware Player per
quanto riguarda l’operazione di lettura e l’elevata instabilità in tutti e tre i
sistemi nell’operazione di scrittura.
5.3.1
Relative Performance
In questa sezione presentiamo i risultati ottenuti dalla fase di benchmarking di una singola macchina virtuale sui tre sistemi di virtualizzazione. Sono
mostrate le tre suite di bechmark descritte in precedenza. Lo scopo di questa
classe di benchmarking è quello di valutare ogni sistema di virtualizzazione
in situazioni di carico su una singola macchina, cercando di valutarne aspetti
come la gestione della CPU, cache, memoria e disco.
L’importanza del test di esecuzione di una singola macchina virtuale è dovuta
al fatto che è direttamente confrontabile con le prestazioni attese da un sistema operativo in esecuzione nativa, quindi con l’esecuzione di tale benchmark è possibile ottenere risultati che riescono ad esprimere l’overhead introdotto dal sistema di virtualizzazione alle prestazioni di un sistema operativo.
Nei successivi paragrafi analizzeremo i tre benchmark nel dettaglio.
CHAPTER 5. TESTING
69
Figure 5.5: Livermore Kernels (Livermore Loops)
5.3.1.1
Classic Benchmark
Questa suite comprende quattro benchmark. Nel primo benchmark, Livermore Kernels, in figura 5.5, vengono mostrati cinque valori per le due serie di test la prima con un codice C/C++ non ottimizzato la seconda con
una versione ottimizzata. I cinque valori mostrano i risultati ottenuti per
ogni sistema di virtualizzazione, i valori espressi in MFLOPS evidenziano le
migliori performance di Xen sia per il parametro che indica il valore massimo
che quello minimo e anche nei tre risultati dettati dalle medie aritmetiche,
geometriche e armoniche Xen riesce a mantenere risultati migliori. Nella versione con ottimizzazione il valore massimo indica un incremento nell’ordine
del 10% rispetto a ESXi e VMware Player, ciò dovuto al fatto che i calcoli eseguiti nel benchmark non necessitano di interazione con il kernel del sistema
in esecuzione a Dom level 0.
Il secondo benchmark in figura 5.6 è Whetstone Benchmark: il grafico
è suddiviso in due parti sull’asse delle ascisse, la prima per codice compilato ottimizzato e la seconda senza. Entrambe hanno 9 valori descritti nella
sezione di questo benchmark, si è scelto di utilizzare delle linee nel grafico per
mostrare meglio l’andamento dei risultati dei tre sistemi di virtualizzazione
CHAPTER 5. TESTING
70
Figure 5.6: Whetstone Benchmark
su ogni valore. Come si evince dal grafico, a prescindere dal valore stesso dei
risultati di ogni sistema, questi seguono un andamento del tutto simile per
ogni valore, anche se VMware Player ottiene migliori risultati.
Nel benchmark Dhrystone l’ottimizzazione della compilazione gioca un
ruolo fondamentale nelle performance stesse del sistema operativo in esecuzione in macchina virtuale. I risultati ottenuti dai tre sistemi sono alquanto
sovrapponibili come in figura 5.7. Nella versione 1.1 e 2.1 del benchmark
senza ottimizzazione del codice eseguito si hanno risultati migliori per ESXi
a causa dell’esecuzione di istruzioni quasi nativa da parte delle macchine
virtuali, mentre risultati quasi identici per quanto riguarda Xen e VMware
Player. Nelle altre due esecuzioni, quelle con ottimizzazione del codice, otteniamo migliori risultati per Xen nella versione 1.1 e una situazione simile
alla versione non ottimizzata per la versione 2.1 che differisce dalla 1.1 per
una migliore gestione dell’ottimizzazione, la quale riesce a normalizzare nuovamente i risultati.
CHAPTER 5. TESTING
Figure 5.7: Dhrystone Benchmarks
71
CHAPTER 5. TESTING
72
Figure 5.8: Linpack Benchmark
L’ultimo benchmark Linpack Benchmark in figura 5.8, viene presentato
in due versioni quella con codice ottimizzato e quella senza ottimizzazione,
in entrambe le situazioni ESXi mostra risultati migliori soprattutto nella
versione con codice ottimizzato.
5.3.1.2
Memory Benchmark
Questa sezione mira a fornire un quadro generale per quanto concerne la
gestione della memoria da parte dei tre sistemi di virtualizzazione in esame
utilizzando tre benchmark. Il primo benchmark è RandMem suddiviso in
quattro tipologie. La prima mostrata nel grafico 5.9 mostra i risulati ottenuti
nell’esecuzione di read e read/write sequenziali per blocchi di grandezza che
vanno da 4 Kb a 1048576 Kb. Possiamo osservare che, per blocchi di dimensione piccola da 6 Kb a 3072 Kb, Xen e VMware Player si comportano meglio
CHAPTER 5. TESTING
73
di ESXi, anche se per queste dimensioni dei blocchi le prestazioni migliori si
alternano tra i due sistemi. Per blocchi di dimensione più grande a partire da
6144 Kb abbiamo che le prestazioni di ESXi migliorano superando di poco
quelle di Xen e VMware player.
La figura 5.10 mostra i riusltati ottenuti nell’accesso causuale alla memoria.
Anche in questo grafico si ha una operazione di read e read/write ma su blocchi di dati selezionati casualmente. Nelle prime due dimensioni dei blocchi
prese in esame, ovvero di 6 Kb e 12 Kb, Xen ottiene i migliori risultati mentre
per i blocchi successivi si hanno migliori prestazioni da parte di ESXi e dal
blocco di memoria di dimensione 384 Kb si hanno prestazioni sovrapponibili.
Gli utlimi due grafici di RandMem mostrano i risultati ottenuti nella serie
di test che eseguono le operazioni di read e read/write su blocchi sequenziali
e casuali, alternado valori interi e double. La figura 5.11 mostra il grafico di
read e read/write seriale dove ESXi ha prestazioni migliori per tutti i blocchi
di dati. Il secondo grafico in figura 5.12 mostra che in read e read/write random ESXi ha le prestazioni migliori per i blocchi di dati di grandezza da 12
Kb a 384 Kb, nel blocco di grandezza 6 Kb Xen ha prestazioni leggermente
superiori, mentre per i blocchi di grandezza da 768 Kb in poi i dati sono
sovrapponibili.
Il secondo benchmark di questa classe è SSEfu mostrato in figura 5.38,
nel quale presentiamo una suddivisione per i risultati di operazioni SSE in
singola precisione e SSE2 in doppia precisione con un tempo fissato per ogni
test di 0,1 secondi. Il grafico è suddiviso ulteriormente in tre sezioni che
rispettivamente mostrano i risultati delle tre funzioni utilizzate per l’accesso
alla memoria da parte del programma di benchmark. In tutti i casi Xen e
VMware Player hanno migliori risultati rispetto a ESXi, anche se tra i due in
generale è più performante Xen per quanto concerne l’accesso alla memoria.
L’ultima suite di benchmark di questa classe è BusSpeed che si occupa di
misurare la velocità di gestione dei bus di memoria. Il benchmark legge 32,
16, 8, 4, 2 words e infine legge tutto il contenuto del bus e ripete la lettura
dell’intero bus utilizzando operazioni SSE2. Date queste operazioni mostriamo sette grafici 5.14,5.15,5.16,5.17,5.18,5.19, 5.20 che confrontano le singole
operazioni tra i tre sistemi di virtualizzazione: in ogni grafico l’asse delle
ascisse rappresenta la dimensione del blocco in Kb che è di 6, 24, 96, 384,
768, 1536, 16380, 131070 e sul’asse delle ordinate i Mb/s. I grafici mostrano
un andamento dei tre sistemi del tutto sovrapponibile tranne per il valore
di 386 Kb nel quale VMware Player per qualche motivo riesce a raggiungere
prestazioni migliori rispetto a Xen e ESXi.
CHAPTER 5. TESTING
Figure 5.9: RandMem Integer Serial
74
CHAPTER 5. TESTING
Figure 5.10: RandMem Integer Random
75
CHAPTER 5. TESTING
Figure 5.11: RandMem Integer/Double Serial
76
CHAPTER 5. TESTING
Figure 5.12: RandMem Integer/Double Random
77
CHAPTER 5. TESTING
78
Figure 5.13: SSEfu
CHAPTER 5. TESTING
79
Figure 5.14: BusSpeed Inc 2 words
5.3.1.3
In questa sezione mostriamo gli ultimi benchmark dell’esecuzione di una singola virtual machine. Questa suite si divide in 4 benchmark principali: il
primo di questi è BurnInSSE che esegue quattro esecuzioni consecutive di
operazioni aritmetiche. Il grafico in figura 5.21 sovrappone i MFLOPS ottenuti da ognuno dei tre sistemi di virtualizzazione al fine di mostrare il più
performante nelle quattro esecuzioni. Dal grafico risulta che Xen riesce ad
ottenere prestazioni leggermente migliori rispetto a ESXi e VMware Player.
CHAPTER 5. TESTING
80
CHAPTER 5. TESTING
81
CHAPTER 5. TESTING
Figure 5.19: BusSpeed Inc Read All
Figure 5.20: BusSpeed 128 bit SEE2
82
CHAPTER 5. TESTING
83
Figure 5.21: BurnInSSE
Il prossimo benchmark è DriveStressIO, dove mostriamo due grafici relativi rispettivamente all’operazione di lettura e all’operazione di scrittura,
5.22 e 5.23.
Il programma per quanto riguarda l’operazione di lettura fissa il tempo di
lettura in 8 valori ed enumera il numero di volte che riesce a leggere per quattro volte un file di 10,25 MB. Nel grafico VMware Player riesce ad ottenere
performance di grand lunga migliori rispetto a Xen e ESXi, probabilemente
grazie ad una gestione più semplice dello storage da parte della Full Virtualization Hosted. Il secondo grafico espone i risultati ottenuti dall’operazione
di scrittura di quattro file di 10,25 MB e i risultati sono i secondi necessari
per eseguire ogni singola scrittura. La scrittura dei file avviene in modo
CHAPTER 5. TESTING
84
Figure 5.22: DriveStress Read
sequenziale, nelle prime tre ESXi ottiene i risultati migliori, nell’ultima sorprendentemente ottiene i risultati peggiori e VMware Player che nella prima
scrittura aveva tempi di gran lunga inferiori a ESXi risulta il migliore. I
risultati migliori però sembrano essere quelli ottenuti da Xen, dal momento
che pur essendo inferiore a ESXi e VMware Player presenta risultati molto
stabili nelle quattro scritture sequenziali.
Il prossimo test presentato è la suite di benchmark descritta precedemente
IntBurn32; i risultati dellla suite mirano a valutare le performance della CPU
effettuando operazioni di somma e sottrazione su sei pattern differenti. Il
grafico in figura 5.24 è suddiviso su l’asse delle ascisse in sei pattern, ognuno
dei quali a sua volta mostra l’operazione di scrittura/lettura e sola lettera
per tutti e tre i sistemi di virtualizzazione. Come si evince dal grafico i
risultati non mostrano sostanziali differenze tra i diversi pattern, ad esempio
nel primo grafico possiamo vedere che nell’opererazione di scrittura/lettura
Xen ha prestazioni leggermente superiori a ESXi e VMware Player, che sono
invece sovrapponibili. Nel caso dell’operazione di lettura abbiamo migliori
prestazioni per Xen circa del 16% superiori a ESXi e circa del 10% maggiori
rispetto a VMware Player.
CHAPTER 5. TESTING
Figure 5.23: DriveStress Write
85
CHAPTER 5. TESTING
86
L’ultima suite di questa classe è Livermore Loops, la quale utilizza un codice
precompilato ottimizzato e mira a valutare le prestazioni dei tre sistemi in termini prestazionali delle CPU in situazioni di elevato carico computazionale.
Il grafico in figura 5.25 sull’asse delle ascisse presenta cinque indici computazionali e su quello delle ordinate i rispettivi valori in MFLOPS. I cinque
valori utilizzati sono: valore massimo, valore minimo, media aritmetica, media geometrica, media armonica. I tre sistemi hanno risultati simili, con un
vantaggio in termini prestazionali di Xen e VMware Player che sono quasi
sovrapponibili e uno svantaggio di ESXi di valori intorno all’ 11-16% per tutti
e cinque i risultati.
5.3.2
Cuncurrent Performance
Questa classe di benchmark a differenza della precedente, che mostra l’overhead
introdotto dal sistema di virtualizzazione, mira a valutare, con le stesse suite
di benchmark utilizzate per le Relative Performance, come i tre sistemi di
virtualizzazione si comportano per gli stessi parametri ma con esecuzione
concorrente di macchine virtuali, più precisamente con il sistema operativo
CentOs 6.1 configurate con 1 vCPU,1 GB RAM, 20 GB di storage e un adattore network per il recupero dei riusultati.
Per questa classe di test si presentano alcune problematiche decisionali circa
l’esecuzione di benchmark, infatti in presenza di una singola macchina virtuale non ci sono problemi per l’avvio del test ma in presenza di più macchine
virtuali sorge la necessità di avvio concorrente dei test.
Con ESXi, le macchine virtuali sono controllabili tramite la suite fornita da
VMware vSphere oppure tramite un sistema di gestione remota come RDP,
VNC, telnet, SSH e XTERM; nel nostro caso, dal momento che il sistema
virtualizzato è Linux, si è scelto di utilizzare SSH con XTERM.
Nel caso di Xen e VMware Player, una volta configurato il sistema, è possibile
utilizzare la stessa strategia di ESXi, a differenza della suite vSphere, oppure
è possibile utilizzare strumenti open-source come Virtual Machine Manager
(Xen), OpenXenManager (Xen), Xen Cloud Control System (Xen), Xen Orchestra (Xen) e Xen Web Manager (Xen), alcuni dei quali però necessitano
di alcune ulteriori configurazioni.
Una volta scelto il software per il controllo remoto della macchina virtuale
è possibile avviare i benchmark singolarmente su ogni macchina tramite
l’utilizzo di SSH con XTERM. Nel nostro scenario di test sono state utilizzate
due macchine di supporto, due notebook, tramite i quali è stato effettuato
CHAPTER 5. TESTING
87
Figure 5.24: IntBurn
CHAPTER 5. TESTING
Figure 5.25: Livermore Loops Opt 3
88
CHAPTER 5. TESTING
89
il controllo remoto SSH, è stato effettuato l’accesso remoto ad entrambe le
macchina virtuali, una per macchina, e cercando di ottenere la migliore sincronizzazione, sono stati avviati i test concorrentemente.
5.3.2.1
Classic Benchmark
In questa sezione analizzeremo la suite chiamata Classic Benchmark suddivisa in quattro benchmark. I prossimi grafici si presentano nella stessa forma
di quelli nelle Relative Performance con la differenza che in ogni grafico viene
aggiunta anche l’esecuzione della seconda macchina virtuale.
Il primo benchmark è Livermore Kernels Cuncurrent, in figura 5.26: dai
risultati è possibile notare che l’esecuzione concorrente delle macchine virtuali non comporta una calo prestazionale per ogni sistema ma causa svantaggio
ad una delle due macchine virtuali, nella situazione di codice non ottimizzato.
Mentre nella situazione di codice ottimizzato le prestazioni dei sistemi sono
più stabili e subiscono un leggero calo rispetto alla controparte su singola
macchina virtuale.
Il prossimo benchmark è Whetstone Cuncurrent Benchmark, figura 5.27,
nel quale i risultati, a differenza di quelli in singola macchina virtuale (si
ricorda che i valori riuscivano a rimanere ben distaccati per tutti i parametri
del benchmark) sono completamente sovrapponibili per tutti e tre i sistemi
di virtualizzazione ad eccezione del caso di test sulle espressioni, calcolo in
virgola fissa, operazioni condizionali (if-then-else) e operazioni di assegnamento, nelle quali Xen ha prestazioni leggermente migliori.
Nel benchmark Dhrystone Cuncurrent Benchmarks 5.28, i sistemi riescono a
migliorare le prestazioni rispetto a quelle ottenute dai benchmark per singola
macchina virtuale. Il risultati complessivamente migliorano e i valori risultanti nel test singola macchina sono rispettati anche nel test concorrente.
Osserviamo quindi che i sistemi, per questo benchmark, come per natura,
ottengono migliori risultati in situazioni di più macchine virtuali.
L’ultimo benchmark per la suite Classic è Linpack Cuncurrent Benchmark,
in figura 5.29, nel quale si verifica il fenomeno precedentemente osservato,
ovvero i risultati ottenuti migliorano rispetto a quelli della controparte a
singola macchina virtuale. I risultati complessivi per tutti e tre i sistemi
migliorano, anche se in questo caso l’andamento dei tre sistemi cambia: netto
miglioramento di Xen che determina le prestazioni migliori.
CHAPTER 5. TESTING
Figure 5.26: Livermore Kernels Cuncurrent (Livermore Loops)
90
CHAPTER 5. TESTING
Figure 5.27: Whetstone Cuncurrent Benchmark
91
CHAPTER 5. TESTING
Figure 5.28: Dhrystone Cuncurrent Benchmarks
92
CHAPTER 5. TESTING
Figure 5.29: Linpack Cuncurrent Benchmark
93
CHAPTER 5. TESTING
5.3.2.2
94
Memory Benchmark
Come nella classe Memory Benchmark per i test su singola macchina, questa
classe cerca di valutare le prestazioni nella gestione della memoria da parte
dei tre sistemi di virtualizzazione nella situazione in cui vi sono più macchine
virtuali in esecuzione concorrente.
Il primo benchmark è RandMem e in questo, a differenza dell’analisi presentata per i benchmark su singola macchina virtuale, presentiamo otto grafici
distinti per l’analisi dei risultati. In ogni grafico vengono aggiunti anche i
risultati ottenuti per la seconda macchina virtuale, quindi ogni grafico che
ha precedentemente rappresentato l’operazione di lettura e lettura/scrittura
adesso è suddiviso in due grafici, uno per ogni operazione. Le figure 5.30 e
5.31 mostrano l’operazione di lettura seriale di interi e la lettura/scrittura
seriale di interi. I due grafici mostrano un comportamento stabile di ESXi
per una macchina a svantaggio della seconda macchina. Le prestazioni di
Xen subiscono un netto calo per entrambe le due macchine virtuali, mentre
VMware Player sorprendetemente mostra un lieve miglioramento per entrambe le macchine virtuali rispetto la controparte a singola macchina virtuale.
CHAPTER 5. TESTING
95
I grafici per i risultati di lettura e lettura/scrittura di valori interi in accesso casuale sono nelle figure5.32 e 5.33 e i risultati ottenuti non presentano
evidenze rispetto a quelli ottenuti per singola macchina. Gli ultimi quattro
grafici sono 5.34, 5.35, 5.36, 5.37: rispettivamente i primi due rappresentano
i risultati per lettura e lettura/scrittura di valori in alternanza interi/double
in accesso seriale, mentre gli ultimi due per l’accesso casuale. Il quadro
delle prestazioni dei sistemi di virtualizzazione migliora, infatti l’operazione
di serial read e serial read/write ottiene risultati che superano i valori della
controparte a singola macchina, mentre per quanto riguarda l’operazione ad
accesso causale otteniamo valori che sono più stabili per tutte le dimensioni
di blocchi di memoria trattati.
CHAPTER 5. TESTING
Figure 5.30: Randmem Integer Serial Read, Cuncurrent
96
CHAPTER 5. TESTING
Figure 5.31: Randmem Integer Serial Read/Write, Cuncurrent
97
CHAPTER 5. TESTING
Figure 5.32: Randmem Integer Random Read, Cuncurrent
98
CHAPTER 5. TESTING
Figure 5.33: Randmem Integer Random Read/Write, Cuncurrent
99
CHAPTER 5. TESTING
100
Il secondo benchmark in figura 5.38 si presenta nella stessa forma del
benchmark Relative Performance con l’aggiunta dei valori per i risultati ottenuti dall’esecuzione della seconda macchina. In questo benchmark i risultati sono del tutto simili a quelli su singola macchina virtuale, ad eccezione
delle prestazioni di Xen, che nella versione a singola macchina virtuale sono
abbastanza superiori rispetto ESXi e VMware Player e subiscono un calo nei
test concorrenti.
L’ultimo benchmark che mira a valutare le prestazione della memoria
è BusSpeed: per questo benchmark a differenza della versione a singola
macchina presentiamo tre grafici. Il primo grafico in figura 5.39 mostra i
risultati ottenuti per la lettura dal bus trattando dati di 6 KB, il secondo in
figura 5.40 tratta dati di dimensione 768 KB, mentre l’ultimo in figura 5.41
tratta dati di dimensione 131070 KB.
Il benchmark per i dati con dimensione 6 KB mostra risultati con prestazioni
inferiori di circa il 20% rispetto alla versione su singola macchina virtuale.
L’unico a mantere una certa costanza in termini prestazionali per tutte le
sette tipologie di operazioni è ESXi, mentre l’ultima tipologia del benchmark con lettura dell’intero bus, con istrizuioni SSE2, mostra un incremento
di prestazioni sia a favore di ESXi che di VMware Player e Xen presenta
prestazioni simili ai precedenti test su singola macchina virtuale. Per i rimanenti due grafici che valutano le prestazioni del bus con blocchi di dimensione
768 e 131070 KB otteniamo risultati simili a quelli di Relative Performance.
CHAPTER 5. TESTING
Figure 5.34: Randmem Double/Integer Serial Read, Cuncurrent
101
CHAPTER 5. TESTING
102
Figure 5.35: Randmem Double/Integer Serial Read/Write, Cuncurrent
CHAPTER 5. TESTING
Figure 5.36: Randmem Double/Integer Random Read, Cuncurrent
103
CHAPTER 5. TESTING
104
Figure 5.37: Randmem Double/Integer Random Read/Write, Cuncurrent
CHAPTER 5. TESTING
Figure 5.38: SSEfu, Cuncurrent
105
CHAPTER 5. TESTING
5.3.2.3
106
Questa sezione mostra i risultati dell’ultima suite di benchmark utilizzata
per la classe di test concorrenti. Come per la versione a macchina virtuale
il primo benchmark utilizzato è BurnInSEE. Il grafico in figura 5.42 mostra
i risultati ottenuti su entrambe le macchine. Dal grafico è possibile notare,
a differenza della versione a singola macchina virtuale, un calo prestazionale
da parte di tutti e tre i sistemi di virtualizzazione. Anche in questo caso Xen
ha prestazioni leggermente migliori rispetto ESXi e migliori circa il 22% in
più rispetto VMware Player.
CHAPTER 5. TESTING
Figure 5.39: BusSpeed 6 KB, Cuncurrent
107
CHAPTER 5. TESTING
108
CHAPTER 5. TESTING
109
CHAPTER 5. TESTING
110
Figure 5.42: BurnInSEE, Cuncurrent
Il secondo benchmark è DriveStressIO e come per le precedenti versioni
presentiamo due grafici in figura 5.43 e in figura 5.44, uno per i risultati del
benchmark in fase di lettura e uno per la fase di scrittura. Il primo grafico in
figura 5.43 mostra l’operazione di lettura per quattro file di dimensione 10,25
MB. Il grafico a linee mostra che le due virtual machine, per ogni sistema
di virtualizzazione, hanno prestazioni sovrapponibili e, rispetto alla versione
a singola macchina virtuale, si osserva un netto peggioramento per tutti e
tre i sistemi. Il secondo grafico in figura 5.44 per l’operazione di scrittura, a
differenza del grafico in Relative Performance, mostra i tempi per le scritture
in millisecondi poichè le prestazioni dei sistemi sono crollate nettamente. I
risultati peggiorano ad eccezione di VMware Player, per il quale si osserva
che nel caso pessimo il tempo di scrittura si dimezza e nel caso ottimo il
CHAPTER 5. TESTING
111
Figure 5.43: DriveStress Read, Cuncurrent
tempo di scrittura è circa cinque volte più veloce degli altri due sistemi di
virtualizzazione.
Il prossimo benchmark è InBurn nella sua versione concorrente e a differenza del grafico per Relative Performance analizzeremo solo un singolo pattern dal momento che per gli altri pattern i risultati sono del tutto identici. Il
grafico in figura 5.45 è diviso in due parti, una per la scrittura/lettura del pattern A5A5A5A5 e una per la sola lettura. Mentre i dati di lettura/scrittura
tra i tre sistemi variano di pochi MB/s, nel caso invece della sola lettura
si osservano risultati simili al caso di singola macchina virtuale, con Xen in
vantaggio di circa il 17% su ESXi e VMware Player. L’ultimo grafico in
figura 5.46 mostra i risultati del benchmark Livermore Loops Opt 3 nella
sua versione concorrente. Come per la versione in singola macchina anche
in questo grafico mostriamo i quattro parametri del programma di benchmark con l’aggiunta dei valori per la seconda macchina virtuale. Come si
evince dai due grafici, quello per le Relative Performance e questo per le
Cuncurrent Perfomance, otteniamo risultati del tutto simili tra le due classi
di benchmark.
CHAPTER 5. TESTING
Figure 5.44: DriveStress Write, Cuncurrent
112
CHAPTER 5. TESTING
Figure 5.45: IntBurn, Cuncurrent
113
CHAPTER 5. TESTING
Figure 5.46: Livermore Loops Opt 3, Cuncurrent
114
Chapter 6
Conclusioni
Le pressioni economiche e di mercato che spingono le aziende a trovare nuove
leve di vantaggio competitivo e, contestualmente, a ottimizzare l’utilizzo delle
risorse esistenti e migliorare l’efficienza, portano a doversi confrontare con
l’esigenza di affrontare l’evoluzione dell’infrastruttura tecnologica secondo
nuove logiche e modelli [15].
Il business moderno risulta sempre più caratterizzato da una logica di servizio,
in base alla quale ogni tipo di attività risulta ripartita su una pluralità di
attori a ciascuno dei quali è delegato lo svolgimento di una parte. Le conseguenze di tali pressioni si ripercuotono sui data center, poichè l’incremento
di complessità determinato dall’aumento di componenti che deve essere continuamente rilasciato, gestito, reso sicuro, porta a una riduzione dell’efficienza
che inibisce la possibilità di aggiungere nuove funzionalità o migliorare i livelli di servizio.
E’ richiesto un nuovo modello di data center che permette di dominare la
complessità, rispondere alle richieste delle nuove applicazioni, mettere ordine
nella proliferazione di dati ed applicazioni. Nel tempo si è osservato il passaggio da una prima versione del data center basata sull’approccio centralizzato
dei mainframe al modello applicativo distribuito di tipo client/server; il data
center è diventato decentralizzato e progressivamente sempre più complicato
da gestire e controllare in modo adeguato. L’esigenza di adattarsi a modelli
di business orientati alla fornitura di servizi ha portato all’affermazione dei
Web Service e delle architettura orientate ai servizi (SOA). Da tale evoluzione
sono scaturiti diversi imperativi:
• Consolidamento per ridurre il numero di dispositivi semplificando la
gestione e riducendo gli oneri di manutenzione, e per sfruttare l’opportunità
115
CHAPTER 6. CONCLUSIONI
116
di razionalizzare delle risorse per applicare logiche di ottimizzazione e
di reucpero dell’efficienza.
• Automazione a tutti i livelli per poter far fronte ai nuovi imperativi
quali la compliance, la spingente richiesta del mercato e l’esigenza di
adattarsi in brevi tempi a nuove condizioni.
• Virtualizzazione rappresenta la nuova frontiera evolutiva, contro la
”fisicità” del data center che può rappresentare un collo di bottiglia;
grazie a questa tecnologia è possibile spezzare il legame tra potenza
di elaborazione, connettività, capacità di memorizzazione limitata ad
una specifica risorsa per evolvere verso la possibilità di allocare tutte le
risorse disponibili indipendentemente da dove si trovano e in modalità
on-demand.
L’evoluzione tecnologoica all’interno delle aziende negli ultimi anni è avvenuta
solitamente in modo destrutturato e disomogeneo per varie ragioni quali la
frettolosità nel rispondere rapidamente alle spinte di un mercato sempre più
competitivo in rapida evoluzione, la mancanza di coordinamento alla carenza
di competenza ed in generale il disallineamento tra IT e business.
In tale contesto altamente dinamico la virtualizzazione diventa strategica
all’intero dei data center e in generale delle architetture orientate ai servizi;
non a caso Gartner nel 2009 riporta la virtualizzazione al primo posto tra le
Top 10 Strategic Technologies, e il Cloud Computing al secondo posto [16]. Il
Cloud Computing prevede un’infrastruttura massiva ed astratta in cui nessuna decisione sui componenti tecnologici viene presa da parte dell’utente,
non è richiesta alcuna installazione ma unicamente una procedura di login. L’allocazione delle risorse avviene sia a livello di scalabilità di sistemi,
processori, memoria, storage, sia a livello applicativo tramite un modello di
costo del tipo ”pay per use”. In sostanza partizionare l’hardware in un pool
di risorse virtuali on-demand è il punto di incontro cruciale tra queste due
tecnologie.
Lo scopo di questo lavoro è stato misurare le perfomance di differenti tipologie
di hypervisor, si ricorda VMware ESXi come esponente di Full Virtualization bare-metal, Xen Hypervisor di Paravirtualization, VMware Player di Full
Virtualization hosted. I test sono stati condotti, basandoci su [21], su una
macchina non di ultimissima generazione, priva di supporto hardware alla
virtualizzazione per cui i risultati di questo lavoro non sono paragonabili alle
117
architetture moderne. Dai grafici mostrati non è possibile mostrare un potenziale ”vincitore” poichè gli hypervisor hanno mostrato prestazioni differenti
e abbastanza variabili a seconda del benchmark, e quindi dell’applicazione.
Tuttavia quando si decide di virtualizzare un’infrastruttura è importante
tenere in considerazione una serie di parametri quali:
1. Semplicità di installazione e utilizzo VMware ESXi e VMware
Player presentano un ambiente molto semplice ed intuitivo, il processo
di installazione è completamente gestito dall’installer e necessitano
tempi di configurazione minimali prima dell’utilizzo; l’installazione di
Xen Hypervsior è risultata più complessa e dipendente molto dal sistema operativo Host che ospita l’Hypervisor e le relative modifiche che
comporta la sua installazione, come l’editing di file di configurazione
del sistema, richiedono una buona conoscenza dell’ambiente Unix.
2. Tool di gestione Per interagire con l’hypervisor VMware ESXi è stato
utilizzato vSphere per creare, rimuovere, editare macchine virtuali ed
aggiungere risorse nel data storage; per interagire direttamente con
le macchine virtuali sono stati utilizzati senza problemi e senza alcun
tempo di configurazione aggiuntivo i protocolli elencati nel capitolo
precedente come RDP. Ad eccezione per il client vSphere, lo stesso
discorso vale anche per VMware Player. La ricerca di client per monitorare l’Hypervisor Xen ha portato al sorgere di vari problemi: molte
applicazioni sono compatibili con una serie limitata di sistemi Unix,
verificarsi di problemi con le librerie libvirt e addirittura forte calo
prestazionale dell’ambiente virtualizzato a causa dell’utilizzo di tali
tool.
3. Scenario di utilizzo La bontà di una scelta architetturale rispetto ad
un’altra dipende molto anche dallo scenario di utilizzo e dalle esigenze
del data center: un prodotto VMware offre certamente più portabilità a
discapito dei costi di licenza per ampliare la suite software con vCenter.
4. Hardware L’hardware ospitante è un criterio di scelta cruciale: nel
nostro lavoro creare e configurare una macchina virtuale su Xen ha
senz’altro comportato tempi elevati poichè l’hardware del server da
noi utilizzato non supporta la virtualizzazione e quindi il sistema operativo Guest è stato paravirtualizzato (che per altro è lo scopo di
questo lavoro); se si dispone di hardware di ultima generazione i costi
118
di creazione e configurazione di una nuova macchina virtuale sono quasi
identici fra entrambi gli hypervisor.
5. Performance Le prestazioni di un ambiente virtualizzato sono forse
le principali ragioni che motivano la scelta di un hypervisor rispetto
ad un altro; queste sono tuttavia fortemente dipendenti dai workload
applicati.
6. Costi I costi per virtualizzare un’infrastruttura sono un aspetto importante da tenere in considerazione: non è conveniente per una piccola
organizzazione spendere tanto per virtualizzare un’infrastruttura se non
sono garantiti i ritorni di investimento. D’altra parte in scenari vasti
e complessi come i sistemi informativi della pubblica amministrazione
i costi legati all’installazione, la gestione e la manutenzione di un data
center virtualizzato vengono ammortizzati nel tempo e vengono ripagati dall’efficienza, l’affidabilità, la versatilità, l’alta scalabilità e la
sicurezza offerta da queste infrastrutture.
In conclusione da questo lavoro deduciamo che non esiste un indice di qualità
assoluto per valutare un hypervisor poichè esistono molti fattori che possono
condizionare le scelta come l’hardware, i costi, l’usabilità e i workload a cui
sarà sottoposto il data center.
Bibliography
[1] Jyotiprakash Sahoo, Subasish Mohapatra, Radha Lath Virtualization:
A Survey On Concepts, Taxonomy And Associated Security Issues
Second International Conference on Computer and Network Technology
[2] Keith Adams, Ole Agesen VMware Inc. A Comparison of Software and
Hardware Techniques for x86 Virtualization ASPLOS’06 October 21-25,
2006
[3] Rakesh Kumar, Simon Mingay How IT Management Can ”Green” the
Data Center Gartner RAS Core Research Note G00153396
[4] Bart Veldhuis, Rob Turk Virtualization Taxonomy SURFworks
[5] Mendel Rosenblum VMware Inc., Tal Garfinkel Stanfod University
Virtual Machine Monitors: Current Technology and Future Trends
IEEE Computer Society
[6] James E. Smith University of Wisconsin-Madison, Ravi Nair IBM T.J.
Watson Research Center The Architecture of Virtual Machines IEEE
Computer Society
[7] White Paper VMware Infrastructure Overview
[8] White Paper Virtualization Overview
[9] White Paper Understanding Full Virtualization, Paravirtualization, and
Hardware Assist
[10] Gerald J. Popek University of California, Robert P. Goldberg
Honeywell Information Systems and Harvard University Formal
Requirements for Virtualizable Third Generation Architectures
Communications of the ACM, July 1974, Volume 17, Number 7
119
BIBLIOGRAPHY
120
[11] VMware Technical Documentation VMware ESX and VMware ESXi
[12] VMware Technical Documentation VMware ESX Server
[13] Wikipedia http://en.wikipedia.org/wiki/Timeline_of_
virtualization_development
[14] VMware Official Website http://www.VMware.com/it/
[15] Solution Guide Cisco EM C 2 VMware Data Center per il futuro
[16] Gartner Official Website
http://www.gartner.com/it/page.jsp?id=777212
[17] A synthetic benchmark H J Curnow and B A Wichmann Central
Computer Agency, Riverwalk House, London SW1P 4RT National
Physical Laboratory, Teddington, Middlesex TW11 OLW Computer
Journal, Vol 19, No 1, pp43-49. 1976
[18] Performance of Various Computers Using Standard Linear Equations
Software Jack J. Dongarra
[19] DHRYSTONE: A SYNTHETIC SYSTEMS PROGRAMMING
BENCHMARK REINHOLDP. WEICKER
[20] Roy Long Bottom Website http://www.roylongbottom.org.uk/
[21] Xen and the Art of Virtualization Paul Barham, Boris Dragovic, Keir
Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer†, Ian
Pratt, Andrew Warfield
[22] Xen Official Website http://www.xen.org/
[23] Spec suite Official Website http://www.spec.org/

Virtualization Benchmarking

Transcript

Documenti analoghi

VMware Horizon view 5.3 Piattaforme Hardware e

Virtualizzazione e Sicurezza

Progetto: Cluster ESX

e-learning e virtual machines - Università degli studi di Bergamo

Hotspot con Captive Portal su VMWare

i rischi dei dati virtuali

Warning VmWare [vmusr:vmtoolsd Failed registration of app type 2

Leonardo-Finmeccanica: la trasformazione digitale delle

VMware vSphere with Operations Management