Studio di soluzioni di Storage per sistemi ad alta affidabilità

Università degli Studi di Perugia
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
Tesi di Laurea
Studio di soluzioni di Storage per
sistemi ad alta affidabilità
Candidato
Oumar Mahamoud Mohamed
Relatore
Prof. Leonello Servoli
Correlatore
Álvaro López García
Anno Accademico 2006-2007
Indice
1 Introduzione
1.1 Obiettivo della tesi . . . . . . . . . . . . . .
1.2 Alta disponibiltà . . . . . . . . . . . . . . . .
1.2.1 Definizione . . . . . . . . . . . . . .
1.2.2 Alta disponibiltà o Alta affidabilità . .
1.2.3 Calcolo del rischio . . . . . . . . . .
1.2.4 Alta disponibiltà dei servizi . . . . .
1.2.4.1 Considerazione da prendere
1.2.4.2 Ridondanza fisica . . . . .
1.2.4.3 Backup dei dati . . . . . .
1.2.4.4 Virtualizzazione . . . . . .
1.3 Organizzazione tesi . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
3
3
4
5
5
5
7
2 Virtualizzazione
2.1 Introduzione . . . . . . . . . . . . . . . . . . .
2.1.1 Un po di storia . . . . . . . . . . . . .
2.1.2 Definizione . . . . . . . . . . . . . . .
2.2 Vantaggi e applicazioni . . . . . . . . . . . . .
2.3 Tecniche di virtualizzazione . . . . . . . . . .
2.3.1 Virtualizzazione applicativo . . . . . .
2.3.2 Parallell virtual macchine . . . . . . .
2.3.3 Re-implementazione delle librerie . . .
2.3.4 Emulazione . . . . . . . . . . . . . . .
2.3.4.1 Svantaggi . . . . . . . . . .
2.3.4.2 Vantaggi . . . . . . . . . . .
2.3.5 Virtualizzazione per traduzione binaria
2.3.5.1 Svantaggi . . . . . . . . . .
2.3.5.2 Vantaggi . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
11
11
12
12
12
13
13
13
14
14
I
INDICE
II
2.3.6
2.4
2.5
2.6
2.7
3 Xen
3.1
3.2
3.3
3.4
Paravirtualizzazione . . . . . . . . . . . . . . . . .
2.3.6.1 Svantaggi . . . . . . . . . . . . . . . . .
2.3.6.2 Vantaggi . . . . . . . . . . . . . . . . . .
Teorie di Popek e Goldberg . . . . . . . . . . . . . . . . .
2.4.1 Una sfida per la virtualizzazione: x86 . . . . . . . .
2.4.1.1 Il problema del x86 . . . . . . . . . . . .
2.4.1.2 Livelli di privilegi di ISA . . . . . . . . .
2.4.1.3 Struttura di controllo di un sistema virtuale
2.4.2 Altri ostacoli . . . . . . . . . . . . . . . . . . . . .
Soluzioni esistenti per il problema dell’x86 . . . . . . . . .
2.5.1 La virtualizzazione della CPU :Intel VT-x e AMD-V
2.5.2 Riferimento per provare la virtualizzazione . . . . .
Prospettive future . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Virtualizzazione memoria . . . . . . . . . . . . . .
2.6.1.1 Senza virtualizzazione: . . . . . . . . . .
2.6.1.2 Con virtualizzazione . . . . . . . . . . . .
2.6.1.3 Soluzione esistente . . . . . . . . . . . .
2.6.2 Virtualizzazione delle periferiche . . . . . . . . . .
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
15
15
15
16
16
17
18
18
19
20
20
20
20
21
21
22
Xen e paravirtualizazzione . . . . . . . . . . . .
Sistemi operativi supportati . . . . . . . . . . . .
Architettura di Xen . . . . . . . . . . . . . . . .
Confronto con altre soluzioni di virtualizzazione .
3.4.1 Sul funzionamento . . . . . . . . . . . .
3.4.2 Sulla performance . . . . . . . . . . . .
Demoni Xen . . . . . . . . . . . . . . . . . . . .
3.5.1 Xend . . . . . . . . . . . . . . . . . . .
3.5.2 Xenstored . . . . . . . . . . . . . . . . .
Conclusione . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
26
26
27
28
28
28
28
4 Prototipo e Test
4.1 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Schema funzionale . . . . . . . . . . . . . . . . .
4.1.2 Composizione . . . . . . . . . . . . . . . . . . .
4.1.3 Funzionamento . . . . . . . . . . . . . . . . . . .
4.1.3.1 Virtualizzazione delle macchine critiche
4.1.3.2 Nodo di monitoraggio . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
30
30
31
3.5
3.6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDICE
4.2
III
Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.1
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.2
File system remoti . . . . . . . . . . . . . . . . . . . . . . .
32
4.2.3
Block device remoti via hardware . . . . . . . . . . . . . . .
32
4.2.3.1
iSCSI . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2.3.2
ATA OVER ETHERNET (AoE) . . . . . . . . . .
33
4.2.3.3
Fibre Chanel . . . . . . . . . . . . . . . . . . . . .
33
Block device remoti via software . . . . . . . . . . . . . . . .
33
4.2.4.1
iSCSI . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2.4.2
ATA over ETHERNET (AoE) . . . . . . . . . . . .
34
TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3.1
Sistema dei test . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3.2
Tools per i test . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.2.1
IOzone . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.2.2
4.2.4
4.3
Bonnie . . . . . . . . . . . . . . . . . . . . . . . .
35
test scalabilità . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.3.1
iSCSI . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.3.3.2
AoE . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.3.3.3
Confronto dei risultati ed interpretazioni . . . . . .
42
Test I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3.4.1
iSCSI . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3.4.2
ATA . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3.4.3
Confronto dei risultati ed interpretazione . . . . . .
45
Conclusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.3
4.3.4
4.4
A Installazione e Utilizzazione di Xen
51
A.1 Installazione e creazione delle VM . . . . . . . . . . . . . . . . . . .
51
A.1.1 installazione . . . . . . . . . . . . . . . . . . . . . . . . . .
51
A.1.1.1
Dai tarballs . . . . . . . . . . . . . . . . . . . . . .
51
A.1.1.2
Dai sorgenti . . . . . . . . . . . . . . . . . . . . .
52
A.1.2 Configurazione del Grub . . . . . . . . . . . . . . . . . . . .
52
A.2 configurazione delle macchine virtuali e uso di xm . . . . . . . . . .
53
A.2.1 configurazione dei domini . . . . . . . . . . . . . . . . . . .
53
A.2.2 Utilizzo di Xen . . . . . . . . . . . . . . . . . . . . . . . . .
53
A.2.2.1
Si lancia Xen . . . . . . . . . . . . . . . . . . . . .
53
A.2.2.2
Comandi Xen . . . . . . . . . . . . . . . . . . . .
53
A.3 Esempio di una creazione di una macchina virtuale ubuntu . . . . . .
54
IV
B iSCSI, ATA over ethernet, Iozone
B.1 ATA over ethernet . . . . . . . . . . . . . . . . . . . . . . .
B.1.1 Target . . . . . . . . . . . . . . . . . . . . . . . . .
B.1.2 Initiator . . . . . . . . . . . . . . . . . . . . . . . .
B.1.3 Alcuni problemi riscontrati . . . . . . . . . . . . . .
B.1.3.1 Installazione del Target e Initiator . . . . .
B.1.3.2 Creazione dei VM da imagini sportati col
ATA . . . . . . . . . . . . . . . . . . . .
B.2 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . .
B.2.1.1 configurazione /etc/ietd.conf . . . . . . .
B.2.1.2 lancio del target . . . . . . . . . . . . . .
B.2.2 Initiator . . . . . . . . . . . . . . . . . . . . . . . .
B.2.2.1 Configurazione . . . . . . . . . . . . . .
B.2.2.2 lancia l’initiator . . . . . . . . . . . . . .
INDICE
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
standard
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
59
59
59
60
61
61
62
62
62
62
63
63
63
64
Elenco delle figure
1.1
1.2
1.3
Schema di ridondanza tramite clonazione dell’hardware . . . . . . .
prototipo della soluzione della virtualizzazione . . . . . . . . . . . .
Schema di un esempio della soluzione colla virtualizzazione . . . . .
5
6
8
2.1
2.2
2.3
Schermata di una macchina Ubuntu su PC Windows . . . . . . . . . .
Una macchina virtuale Mac su linux . . . . . . . . . . . . . . . . . .
Livelli di privilegi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
13
16
2.4
2.5
2.6
2.7
2.8
Struttura di controllo di un sistema virtuale
VMCS di Intel e AMD . . . . . . . . . . .
Indirizzamento senza virtualizzazione . . .
Indirizzamento con virtualizzazione . . . .
Schema del EPT e SPT . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
17
18
20
21
21
3.1
3.2
3.3
3.4
Logo di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Imagine di una schermata con aperti varie macchine virtuali con Xen
Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . . . .
Confronto performance Xen e altre soluzioni di virtualizzazione . .
.
.
.
.
23
25
26
27
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Struttura del prototipo . . . . . . . . . . . . . . . . . . .
schermata di nagios . . . . . . . . . . . . . . . . . . . .
Struttura del sistema dei test . . . . . . . . . . . . . . .
troughput per le operazione di read e write . . . . . . . .
velocità media delle VM per le operazione di read e write
distribuzione delle VM per read . . . . . . . . . . . . .
distribuzione delle VM per write . . . . . . . . . . . . .
Carico del file server . . . . . . . . . . . . . . . . . . .
Troughput delle operazione di read e write . . . . . . . .
Velocità media di read e write con aoe . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
30
31
35
37
38
38
39
39
40
40
V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ELENCO DELLE FIGURE
VI
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
distribuzione delle VM per read . . .
distribuzione delle VM per write . . .
Carico del file server . . . . . . . . .
Confronto sull’operazione di read . .
Confronto sull’operazione di write . .
Confronto sul carico del file server . .
Operazione di write . . . . . . . . . .
Operazione di read . . . . . . . . . .
Operazione di write . . . . . . . . . .
Operazione di read . . . . . . . . . .
Confronto 3d sull’operazione di write
Confronto 3d sull’operazione di read .
Confronto 2d sull’operazione di write
Confronto 2d sull’operazione di read .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
43
43
44
45
45
46
46
47
47
48
48
Capitolo 1
Introduzione
1.1 Obiettivo della tesi
Negli ultimi anni si è registrata una crescita notevole delle aspettative del mercato e
della ricerca verso il mondo della computazione basta pensare che i siti internet più
popolari forniscono talmente tante informazioni che un loro rallentamento o una loro
interruzione comporterebbe perdite per milioni di euro o di più; la stessa cosa vale
per i grandi network o per i sistemi computazionali dedicati alla ricerca scientifica
come Grid1 . Tutti questi sistemi devono avere una caratteristica importante per poter
soddisfare l’esigenza del mercato o della ricerca scientifica: l’alta disponibilità.
L’obiettivo di questa tesi è quello di identificare una soluzione di storage per il
prototipo di virtualizzazione realizzato nella sede del Dipartimento di Fisica a Perugia.
1.2 Alta disponibiltà
1.2.1 Definizione
L’alta disponibiltà è un termine che in informatica è usato spesso ed indica in una
architettura di sistema o in un servizio il tasso di disponibiltà. Il termine disponibilità
indica la probabilità che un servizio o un sistema sia funzionante ad un instante preciso.
Per misurare la disponibilità si usa spesso una percentuale composta da ’9’, se un
servizio è disponibile al 99% significa che questo ultimo è indisponibile meno di 3.65
giorni per anno. La tabella 2.1 presenta il tempo di indisponibiltà sulla base di un
anno(365 giorni)in funzione del tasso di disponibiltà.
1 Infrastruttura distribuita per consentire l’utilizzo di risorse di calcolo e di storage provenienti da un
numero elevato di calcolatori interconnessi da una rete
1
CAPITOLO 1. INTRODUZIONE
2
tasso di disponibiltà
97%
98%
99%
99,9%
99,99%
99,999%
99,9999%
durata di indisponibiltà
11 giorni
7 giorni
3 giorni e 15 ore
8 ore e 48 minuti
53 minuti
5 minuti
32 secondi
Tabella 1.2: Tasso di disponibiltà
1.2.2 Alta disponibiltà o Alta affidabilità
La disponibiltà viene definita come la percentuale di tempo in cui un sistema è in grado
di eseguire un lavoro produttivo rispetto al tempo totale. Il valore limite al quale tutti
mirano è chiaramente il 100%. Il concetto di disponibilità è più significativo di quello
di affidabilità in quanto esprime più compiùtamente il vero obiettivo dei clienti, che è
quello di garantire che le risorse, i servizi e le applicazioni del sistema siano funzionanti
e accessibili dagli utenti in ogni momento, non quello di verificare quanto tempo passa
prima che un singolo componente si guasti.
Molti sistemi raggiungono un livello di disponibiltà di circa il 99%: una percentuale
che a prima vista sembra molto elevata, ma se si fa riferimento a un periodo di un anno,
l’1% di mancata disponibilità equivale a circa 90 ore, ovvero poco più di tre giorni e
mezzo. E’ vero che una parte non trascurabile di queste 90 ore è dovuta alle fermate
pianificate per la manutenzione preventiva, allo scopo di prevenire fermate non pianificate sicuramente più dannose. Tuttavia una disponibiltà del 99% è sufficiente solo per
applicazioni non critiche o per lavorazioni non eccessivamente critiche. In altri casi,
qualunque interruzione può mettere a repentaglio vite umane, quattrini e reputazione.
Fino ad oggi, in tali situazioni sono stati spesso utilizzati sistemi fault tolerant2 , basati
su architetture ampiamente ridondanti e su componenti molto specializzati, con i quali
si cerca di prevenire qualunque interruzione del servizio agli utenti.
I sistemi fault tolerant possono raggiungere o superare un livello di disponibiltà
del 99,999% che equivale a una media di circa cinque minuti di fermata all’anno. Ma
ovviamente per adottare una soluzione di alta disponibiltà esiste un costo da sostenere
e quindi capita a domandarsi se conviene o no un approccio di questo tipo, per questo
facciamo un piccolo studio di questo approccio e i vari fattori che intervengono nella
sua implementazione sia come costi da sostenere che come utili.
2È
la capacita di un sistema di non subire fallimenti anche in presenza di guasti
1.2. ALTA DISPONIBILTÀ
3
1.2.3 Calcolo del rischio
Di fatto si può parlare di rischi di down-time che possono essere causati da diversi
scenari di failure sia fisici che logici, ognuno dei quali ha pesi diversi. Nella realtà
all’interno degli scenari di down-time, oltre ai failure non pianificati, sono da considerare anche i down-time prodotti da aggiornamenti ciclici dei sistemi sia hardware
che software (aggiornamento di patch di sicurezza, service, partizionamenti di volume,
upgrade di memoria, aggiornamenti del BIOS etc).
Nell’ambito di ciascun sistema esistono quindi rischi differenziati legati a diversi
scenari di down-time, per ciascuno di questi è necessario calcolare l’effetto prodotto
sia prima che dopo l’implementazione della soluzione di alta affidabilità. Per ogni
scenario (con e senza alta disponibiltà), i risultati degli effetti prodotti da ogni singolo
evento d’outage devono essere sommati tra loro per ottenere il valore di effetto totale.
Dal punto di vista matematico l’effetto prodotto non è altro che la moltiplicazione di
tre variabili:
• Probabilità che l’evento si manifesti (P)
• Durata dell’effetto prodotto (D)
• Percentuale degli utenti che subiscono l’outage (I)
Per il fattore di probabilità bisogna prevedere la frequenza media con cui l’evento può
manifestarsi per l’intera durata di vita del proprio sistema. Non esiste nessun metodo
per calcolarlo nel futuro. Tuttavia questo dato può essere ottenuto sulla base dell’analisi storica dei down-time (ecco dunque l’importanza di avere policy per l’auditing
dei disservizi). Per ciò che riguarda la durata è necessario considerare il tempo medio di interruzione prodotto dall’outage. In questa valutazione bisogna prevedere non
solamente il tempo di disservizio ma anche i tempi necessari al ripristino dei dati e al
ripristino delle attività da parte degli utenti. L’unita di misura risulta essere il tempo.
Nella valutazione occorre essere molto conservativi e basarsi sulle esperienze vissute.
Per area di impatto si considera invece la percentuale di utenti coinvolta nel disservizio.Per esempio un down-time pianificato può impattare solo il 15% della totalità degli
utenti mentre un down-time non pianificato può raggiungere facilmente il 100% se si
manifesta durante gli orari di picco.
1.2.4 Alta disponibiltà dei servizi
Un servizio è una applicazione o un insieme di operazioni accessibile attraverso un’interfaccia di cui possono usufruire i clienti. Dei esempi molto semplici sono il servizio
CAPITOLO 1. INTRODUZIONE
4
web, ed il servizio di posta elettronica. In questa i servizi che si vogliono rendere altamente disponibile sono servizi Grid, per questo d’ora in poi ci riferiremo a questi
ultimi ed ai vari problemi relativi ad essi.
1.2.4.1 Considerazione da prendere
L’erogazione di un servizio può essere interrotta da problemi, che possono essere di
natura diversa come il malfunzionamento di una macchina causato da un problema
hardware o software o la caduta del sistema per cause esterne ( mancanza di potenza
elettrica, guasto di climatizzatori) in questo caso la disponibiltà è azzerata perchè il
servizio non è più disponibile ovvero il servizio è in stato di Down quindi per avere un
tasso di disponibilità alto bisogna diminuire al minimo il tempo di down-time. L’alta
disponibiltà chiede un ambiente adatto per le macchine ecco alcune delle caratteristiche
salienti che questo ambiente deve avere:
• alimentazione stabile per garantire una continua erogazione della corrente alle
macchine;
• ventilazione continua per evitare il rischio di riscaldamento delle macchine;
• servizio di ripristino pronto per ripristinare il sistema in caso di problemi o
guasti;
• servizio di sicurezza per evitare che persone non esperte o mal intenzionate si
introducano nel locale;
• cavi di alimentazione e di comunicazione devono essere ridondanti e protetti
inoltre bisogna anche stare attenti al rischio di incendio e di inondazione.
Oltre a questo bisogna anche avere un piano di controllo per rilevare o prevenire guasti, come test di vita TCP HEALTCHECK , programmi di test invocati periodicamente
(heartbeat) ,interfacce di tipo < <diagnostic> > sui componenti; questo piano deve riguardare ogni livello di architettura, ogni componente , ogni legame di comunicazione
tra i componenti,ecc.... .
Queste sono alcune delle considerazioni da fare per evitare un guasto ma è quasi
impossibile eliminare il rischio al 100% . Perchè ci sono dei problemi come incendio
o terremoti che non possono essere prevenuti, perciò bisogna orientarsi per cercare
soluzioni per diminuire al minimo il down-time. Ci sono molte tecniche che sono usate
per risolvere il problema di minimizzare il down-time; sono presentate di seguito le più
importanti.
1.2. ALTA DISPONIBILTÀ
5
1.2.4.2 Ridondanza fisica
Questa tecnica suggerisce di replicare i componenti sui quali sono in esecuzione i servizi richiesti, creando una copia esatta della macchina . Il tempo di down-time è abbastanza piccolo in quanto è uguale solo al tempo necessario all’ avvio della macchina
copia. Ma questa tecnica comporta un consumo di risorse economiche, un numero elevato di indirizzi IP, è necessario la presenza 24h/7 di un personale pronto a spostare i
servizi ed avviare le macchine ” clone ”. Un esempio di questa soluzione è illustrato
nella figura seguente.
Figura 1.1: Schema di ridondanza tramite clonazione dell’hardware
1.2.4.3 Backup dei dati
La ridondanza fisica assicura la disponibiltà dei dati di un sistema ma non permette
di assicurare una protezione dei dati contro gli errori di manipolazione degli utenti o
contro catastrofi naturali come incendio, inondazione o terremoto. È quindi necessario di prevedere meccanismi di salvaguardia o backup (idealmente su siti lontani per
garantire l’incolumità dei dati). Si effettua quindi un backup dei dati delle macchine
su cui i servizi sono in esecuzione, in questo modo quando cade una macchina viene
riavviato coi dati di backup; in questo caso il tempo di down-time dipende dal tempo
necessario per recuperare i dati di backup e far ripartire una nuova macchina con questi dati. Questa soluzione garantisce più l’integrità che l’altà disponibilità in quanto il
tempo di ripristino del sistema con i dati di backup è molto elevato.
1.2.4.4 Virtualizzazione
Questa è una tecnica in continuo sviluppo e può essere usata sia per garantire l’alta
disponibiltà, sia per sfruttare al meglio le risorse disponibili in un sistema. La virtualiz-
CAPITOLO 1. INTRODUZIONE
6
zazione permette di creare in un dato sistema diversi ambienti di esecuzione, isolati uno
dall’altro, nei quali si possono far eseguire distinti sistemi operativi(chiamati macchine
virtuali)3 .
Per garantire l’alta disponibilità, si virtualizza le macchine che forniscono i servizi,
in modo che questi non siano legati alle macchine fisiche. Il file system delle macchine
vrituali risiedono in un file server con altà affidabilità, tutte le macchine fisiche della
rete possono accedere ai questi file system e quindi caricarli a traverso la rete. Quando
una macchina fisica si guasta o si rompe è allora possibile traferire le macchine virtuali
in esecuzione su questa macchina su un altra macchina, i file system di queste macchine
vengono caricati dal file server dove sono memorizzati. L’operazione di trasferimento
è automatizzata ed effettuata da un programma di monitoraggio. Vediamo il prototipo
di questa soluzione nella figura 1.2.
Figura 1.2: prototipo della soluzione della virtualizzazione
Lo storage è il punto fondamentale del prototipo, rende visibile alle macchine fisiche i dati delle macchine vrituali attraverso la rete, ci sono varie soluzioni sia hardare
che software per realizzarlo, in questa tesi vedremo e testeremo alcuni di loro.
I vantaggi di questa soluzione sono.
• Servizi indipendenti dall’ hardware.
• Costi più sostenibili in confronto alle altre soluzioni.
• massima utilizzazione delle risorse.
3 tratteremo
più in profondità questo argomento nel capitolo 2
1.3. ORGANIZZAZIONE TESI
7
gli svantaggi:
• Downtime di circa 1 minuto mentre con linux-HA di pochi secondi!!
• Complessità elevata
Vediamo nello schema della figura 1.3 un esempio di funzionamento di questa soluzione.
La macchina fisica 2 cade ( figura 1.3.a)quindi le macchine virtuali 3 e 4 che erano
in esecuzione su questa sono in down-time. È necessario spostare le macchine virtuali
verso un altra macchina. Vengono spostati le macchine virtuali della macchina fisica 2
verso la macchina 1 (figura 1.3.b). La situazione è ripristinata (figura 1.3.c) ed le VM
girano tutti sulla macchina 1 come mostrato nella figura 1.5.
1.3 Organizzazione tesi
I capitoli che seguono saranno cosi strutturati:
• Capitolo 2:in questo capitolo si spiega la virtualizzazione e le varie tecniche
attraverso cui si può realizzarla;
• Capitolo 3:in questo capitolo si spiega che cos’è Xen , come funziona, e le sue
caratteristiche
• Capitolo 4:in questo capitolo si presenta il prototipo realizzato e i test effettuati
per trovare una soluzione di storage per le macchine virtuali;
• Capitolo 5:Conclusioni e sviluppi futuri per la virtualizzazione e Xen
• Appendice A: installazione e uso di xen
• Appendice B: uso dei protoccoli ATA e iSCSI.
8
CAPITOLO 1. INTRODUZIONE
a) caduta di una macchina fisica
b) trasferimento delle VM verso una altra macchina
c) situazione ripristinata
Figura 1.3: Schema di un esempio della soluzione colla virtualizzazione
Capitolo 2
Virtualizzazione
2.1 Introduzione
2.1.1 Un po di storia
La virtualizzazione non è una tecnica nuova nel mondo della computazione, dato che
risale all ’inizio dell’era dell’informatica. Si possono citare i lavori svolti in questo
campo Da Popek e Goldberg in 1974 che hanno analizzato i diversi tipi di soluzione di
virtualizzazione possibile, i loro rispettivi vantaggi e inconvenienti.
Recentemente si è sentito parlare molto di virtualizzazione dal passaggio dei processori MAC ai processori INTEL. In più aziende del calibro d’Intel , AMD si sono lanciate nella sfida cercando di risolvere la questione con l’ottimizzazione dei processori.
Si può quindi quasi dire che la virtualizzazione è passata sotto i riflettori. Quasi perchè, malgrado tutto, la virtualizzazione rimane una tecnologia abbastanza misteriosa
per molte persone.
2.1.2 Definizione
La virtualizzazione, è certo una bella parola, ma non molto chiara. Precisiamo prima
che ci sono 2 tipi di virtualizzazione: quella hardware e quella software. Nel primo
caso l’obiettivo è quello di fare funzionare molti sistemi operativi sulla stessa macchina separatamente l’uno di l’altro come se fossero su macchine fisiche distinte. Nel
secondo caso si tratta di fare girare molte applicazioni diverse nella stessa macchina.
La virtualizzazione è un insieme di tecniche hardware o software per realizzare questi
obiettivi, anche se non è semplice.
La gestione delle risorse fisiche (CPU,memorie,periferie,..) è garantita dal OS, le
9
CAPITOLO 2. VIRTUALIZZAZIONE
10
eventuali applicazioni non hanno alcun legame diretto con le risorse fisiche, passando
tutte attraverso l’OS. Dunque per concezione un sistema operativo si aspetta ad essere
l’unico ad avere la gestione della macchina e di tutte le sue risorse ed a dialogare
direttamente con la CPU. La virtualizzazione quindi ha il compito di fare ”credere” ad
ogni OS della macchina di essere l’unico, anche se in realtà sono molti a condividere le
risorse, perciò il software di virtualizzazione deve simulare una macchina virtuale per
ogni OS. Ogni OS vede solo la sua macchina virtuale e funziona senza preoccuparsi di
niente. Vediamo la definizione di alcuni termini usati spesso.
• macchina o sistema host:macchina che ospita le macchine virtuali.
• macchina guest o macchina virtuale:sistema virtualizzato, l’insieme di risorse
materiali (disco, memoria, periferie, CPU,..)simulato dal software di virtualizzazione
• Hypervisore o VMM (VIRTUAL MACCHINE MONITOR):La componente di
sistema che realizza la virtualizzazione. Esistono numerosi nel mercato (Vmware, Virtual PC, Parallels Workstation, Xen, Qemu...). L’ hypervisore può essere installato sia come una applicazione del sistema operativo ospite sia come
uno strato software più profondo del sistema operativo.
2.2 Vantaggi e applicazioni
Le macchine virtuali hanno molte applicazioni, spesso nel campo professionale. Un
primo utilizzo è quello di avere più sistemi operativi contemporanemente attivi su una
sola macchina, molto più facilmente di un multi boot. Si può quindi pensare di avere
Windows su un Macintosh, Windows, MacOs e Linux sulla stessa macchina etc. Al di
la del semplice gadget, è un vantaggio per tutti gli sviluppatori che devono provare i
loro codici sotto ogni piattaforma, sotto ogni navigatore etc .... . La figura 2.1 mostra
un esempio di una macchina virtuale Windows su una macchina Ubuntu (Linux).
Figura 2.1: Schermata di una macchina Ubuntu su PC Windows
2.3. TECNICHE DI VIRTUALIZZAZIONE
11
L’uso delle macchine virtuali ha il anche vantaggio di fare girare su un PC di ultima generazione delle applicazioni vecchie. Per esempio per usare dei software o giochi
sviluppati per un sistema ”vecchio” ed incompatibile con il hardware di una macchina recente, il sistema ”vecchio” può essere virtualizzato. Questa situazione è molto
frequente anche in grandi aziende , che non possono cambiare i software ad ogni rinnovamento di materiale. Un altro vantaggio dell’ uso delle macchine virtuali è una
stabilita ed una sicurezza importante : infatti un guasto di una macchina virtuale non
ha effetti sulle altre macchine. Lo stesso, un virus che infetta una macchina virtuale
non contamina le altre. In alcuni casi una VM è incapsulata in un file1 . È quindi molto
facile realizzare un backup del suo sistema ad un istante preciso, nel caso di un problema o di un virus basta cancellare il file della VM in corso e rimpiazzarlo col file di
backup realizzato un giorno prima. Questo file è anche molto facilmente trasferibile da
un computer ad un altro.
Infine, e sopratutto, la virtualizzazione permette alle aziende di ottimizzare l’utilizzazione delle loro risorse fisiche. Grazie alla virtualizzazione, è non solo possibile di
fare funzionare più macchine virtuali su un solo computer, ma anche di utilizzare più
computer per fare girare una sola macchina virtuale. Le risorse sono quindi utilizzate
al meglio secondo il carico.
2.3 Tecniche di virtualizzazione
Ci sono molti tipi di virtualizzazione, alcuni utilizzati frequentemente altri meno. Vediamo alcuni di loro.
2.3.1 Virtualizzazione applicativo
Si virtualizza al livello delle applicazione , esempi più conosciuti sono:
• Java : JVM(Java virtual macchine), quando un programma scritto in java viene
compilato si ottiene un codice chiamato Bytecode, questo codice può essere eseguito o interpretato dalla JVM su una piattaforma diversa da quella con la quale
è stato generato, questo operazione è possibile grazie alla portabilità di JVM.
1 vedere
l’appendice B, creazione macchina virtuale
CAPITOLO 2. VIRTUALIZZAZIONE
12
2.3.2 Parallell virtual macchine
Una macchina virtuale che dispone delle risorse di più macchine fisiche. Questo tipo
di virtualizzazione è spesso usato nel ambito dei Cluster2 e del calcolo parallelo. In
questo caso l’obiettivo è quello della ricerca della massima dell’efficienza per una singola applicazione in quanto questa viene distribuita tra le varie macchine fisiche che
formano una sola macchina virtuale. Esempi di questa tecnica sono le librerie PVM. La
macchina virtuale di PVM è realizzata da un insieme di processi demone (1 per ogni
host). Questa tecnica ha una migliore gestione eterogeneità ed è fault tolerant ma è
troppo specifica in quanto è usato principalmente solo per la distribuzione del calcolo.
2.3.3 Re-implementazione delle librerie
In questa tecnica si riscrivano le librerie di un sistema operativo per fare funzionare dei
programmi sotto un altro sistema operativo. Come esempio si può citare Wine che è un
implementazione delle librerie Windows.
2.3.4 Emulazione
L’emulazione consiste nel riprodurre da un software chiamato emulatore le funzioni
di un determinato sistema su un secondo sistema differente dal primo. Per esempio un
programma scritto sotto il sistema operativo MS Windows non può girare sotto Linux o
MacOS ma facendo una emulazione dell’ ambiente windows in Linux o MacOS si può
fare funzionare questo programma. Esistono varie categorie di emulatori cosi come
si può emulare una piattaforma in molte maniere. È possibile emulare completamente un ambiente sia hardware che software oppure soltanto uno dei due. È più facile
tecnicamente fare un emulazione di tipo software poiché può bastare un semplice traduttore che traduce al sistema che ospita le istruzioni. Nel caso invece dell’emulazione
hardware sarà necessario simulare la circuiteria ed il comportamento fisico del sistema
come avviene ad esempio nel MAME3 . Altri emulatori presenti nel mercato sono:
• VICE, emulatore dei computer a 8 bit
• PCSX2, emulatore di PS2
• Dosbox, emulatore di MS-DOS
Questa tecnica ha sia dei vantaggi che degli svantaggi vediamone.
2 è un insieme di computer connessi tramite una rete telematica con lo scopo di distribuire una
computazione molto complessa
3 Multi Arcade Macchine Emulator, software in grado di emulare varie piattaforme di gioco arcade
2.3. TECNICHE DI VIRTUALIZZAZIONE
13
2.3.4.1 Svantaggi
La maggior parte delle tecniche di virtualizzazione si basano sullo stesso concetto:
intercettare al volo le richieste dei sistemi operativi verso la macchina virtuale e tradurli affinché possano essere eseguiti dalla macchina fisica o reale.Questa descrizione
è sufficiente a fare capire il principale problema della virtualizzazione : la perdita dell’efficienza. In effetti un istruzione è rimpiazzata da una decina di altre istruzioni, ed
il tempo di calcolo è più lungo di una situazione non virtuale. Questo problema è
ancora peggiorato nel caso dell’emulazione poiché l’emulatore deve intercettare la totalità delle istruzioni del software emulato e questo comporta una perdita di efficienza
maggiore.
2.3.4.2 Vantaggi
L’emulazione permette di eseguire una applicazione in qualsiasi tipo hardware che sia
compatibile o no. Un esempio preciso è quello dell’emulatore DosBox, un emulatore
DOS open source (free) che può essere utilizzato per far girare i vecchi programmi
che hanno problemi a funzionare sui altri sistemi operativi. Si può anche emulare un
sistema operativo all’interno di un altro sistema come per esempio mostrato nella figura
2.2 dove MacOs è emulato su Linux.
Figura 2.2: Una macchina virtuale Mac su linux
2.3.5 Virtualizzazione per traduzione binaria
Quando i sistemi usano hardware compatibili come nel caso di Linux, Windows, e di
MacOS (da quando è uscito il MacIntel) la virtualizzazione può operare in un modo
più efficiente; infatti in questa tecnica l’hypervisore sfoglia le istruzioni usate da ogni
sistema operativo ospite e traduce solo quelle che possono causare incomprensione
o danni al sistema virtualizzato. Gli altri sono direttamente eseguiti dal processore.
CAPITOLO 2. VIRTUALIZZAZIONE
14
Vedremo nel paragrafo seguente come l’hyervisore effettua questa operazione e quali
sono le istruzioni ”pericolosi”. Alcuni software che sono usati per questa soluzione
sono:
• Vmware
• VirtualBox (open source).
Adesso valutiamo Vediamo gli vantaggi e svantaggi di questa tecnica.
2.3.5.1 Svantaggi
Ha una complessità di funzionamento elevata e richiede una compatibilità hardware tra
il sistema guest ed il sistema host.
2.3.5.2 Vantaggi
Il vantaggio principale di questa tecnica è l’efficienza; infatti i più veloci virtualizzatori
riccorono tutti alla Binary traduction; oltre a questo permette anche di non modificare
i sistemi guest.
2.3.6 Paravirtualizzazione
Per ridurre ancora il rallentamento dovuto alla virtualizzazione, le soluzioni di paravirtualizzazione prendono il problema al contrario : modificano direttamente i sistemi operativi guest in modo che non ci sia più tanto il bisogno della traduzione delle
istruzioni. Xen di cui è basato questa tesi è un perfetto esempio.
2.3.6.1 Svantaggi
Richiede la modifica del sistema operativo guest. Se l’efficienza può essere garantita, si
perde il vantaggio dell’universalita, poiché ci vuole una versione speciale del software
di paravirtualizzazione per ogni versione di sistema operativo che si vuole utilizzare.
2.3.6.2 Vantaggi
Offre le maggior prestazioni, la perdita di performance è di pochi punti percentuali.
2.4. TEORIE DI POPEK E GOLDBERG
15
2.4 Teorie di Popek e Goldberg
Nell’ articolo ” Formal Requirements for Virtualizable Third Generation Architectures” uscito in 1974, Gerald J. Popek e Robert P. Goldberg[1] hanno introdotto le condizioni necessari e sufficienti in un’ architettura per supportare in maniere efficiente un
sistema virtualizzato. Queste condizioni sono ancora utilizzate come riferimento nella
virtualizzazione.
Secondo Popek e Goldberg le caratteristiche di un sistema perchè operi come un
virtualizzatore sono:
• Fedeltà: il software deve essere eseguito dalla VMM in modo analogo ad una
esecuzione via hardware
• Prestazioni: la maggior parte delle istruzioni del guest devono essere eseguite
dall’hardware senza l’intervento della VMM
• Sicurezza: la VMM gestisce tutte le risorse
Il problema sollevato da loro è quello di determinare le caratteristiche che L’ISA (Istruction Set Architecture) della macchina originale deve avere per poter essere virtualizzato. In effetti in un’ architettura per poter essere virtualizzata in modo efficiente, tutte le
sue istruzioni devono essere privilegiati.
2.4.1 Una sfida per la virtualizzazione: x86
2.4.1.1 Il problema del x86
Come è noto un processore è capace di eseguire solo un numero ridotto di istruzioni
elementari. Queste istruzioni sono chiamati ISA (Instruction Set Architetture), sono
memorizzati in memoria e non sono modificabili . Questo insieme di istruzioni definisce le capacita di un processore la cui l’architettura fisica può essere ottimizzata
eseguendo le istruzioni del ISA il più efficacemente possibile. Esistono molte ISA,
Il più conosciuto nel mondo dei PC è senza altro il x86, usato dai processori INTEL
e AMD da quando esistono . Si può citare per esempio il PowerPc, l’Alpha AXP, il
SPARC o i recenti AMD64 O EM64T. Molto presente e molto usato ma non si può
dire che l’x86 è un esempio perfetto di ISA, e sopratutto non si presta molto bene alla
virtualizzazione.Perché?
Le istruzioni dell’ISA x86 non sono tutte uguali. Tra loro, alcune possono modificare la configurazione delle risorse in possesso del processore, e sono dette critiche. Per
proteggere la stabilita della macchina, queste istruzioni non possono essere eseguite da
tutti i programmi.
CAPITOLO 2. VIRTUALIZZAZIONE
16
2.4.1.2 Livelli di privilegi di ISA
Dal punto di vista della CPU i programmi appartengono a 4 categorie, o livello di
astrazione come mostrato nella figura 2.3.
Figura 2.3: Livelli di privilegi
Ogni anello rappresenta un livello di privilegio decrescente. Le istruzioni più critiche richiedono i privilegi più alti , di ordine 0. Purtroppo, su processore x86, 17 di
questi istruzioni critiche possono essere eseguite da processi nei livelli 1, 2, o 3. Questo
crea un grosso problema ai programmi di virtualizzazione; un sistema operativo è infatti previsto per funzionare nell’ anello 0 ed utilizzare le istruzioni critiche per distribuire
le risorse del processore tra le diverse applicazioni. Ma quando si trova in situazione
di guest o ospite su una macchina virtuale, lo stesso OS non deve poter modificare le
risorse fisiche sotto il rischio di causare errori al sistema. Solo l’hypervisor deve avere
questi diritti. Bisogna quindi intercettare tutte le istruzioni critiche.
2.4.1.3 Struttura di controllo di un sistema virtuale
La figura 2.4 mostra come la macchina virtuale deve interporsi tra la macchina reale
ed i sistemi operativi guest. Per quanto riguarda le istruzioni privilegiate non ci sono
problemi in quanto possono solo essere eseguite dai programmi che appartengono al
livello 0 in questo caso cioè l’hypervisor, quindi l’OS guest gira in un anello non privilegiato insieme ad altre applicazioni e la richiesta di istruzioni privilegiate genera un
errore che è gestito dal VMM. Invece è molto più difficile per le 17 istruzioni ”pericolose” e non privilegiati. Queste ultimi non generano errori automatiche, devono essere
2.4. TEORIE DI POPEK E GOLDBERG
17
rilevati man a mano dal VMM, poi reinterpretati . Questo comporta un sovraccarico di
calcolo importante, ed una grande complessità del software hypervisor.
Figura 2.4: Struttura di controllo di un sistema virtuale
Come mostrato nella figura 2.4 il sistema guest ” crede ” che gira in un dominio
privilegiato ma realmente questo dominio non lo è, quindi l’Hypervisor deve provvedere a gestire e a soddisfare tutte le richieste dei sistemi guest installati nel dominio
non privilegiato ma che possono richiedere esecuzione delle istruzioni privilegiate.
2.4.2 Altri ostacoli
A parte i difetti dell’ x86, la virtualizzazione dell’hardware pone altri problemi. Per
esempio, l’OS guest ”pensa” che ha accesso alla totalità della memoria della macchina.
Invece non è cosi perchè la condivide con gli altri OS ed il VMM. Quindi è il compito
di questo ultimo di sorvegliare ed intercettare i tentativi di accesso del OS invitato ai
indirizzi di memoria non disponibile e ridirigerlo ad altri indirizzi liberi. Altro esempio
è il fatto che l’ OS invitato gira in un dominio insieme ad altri applicazioni, e questo
mette a rischio la sua stabilita. Infine l’OS invitato non deve scoprire che esso sta
girando in dominio non privilegiato altrimenti rischia di guastare il sistema; quindi è
sempre il VMM che deve intercettare le istruzioni suscettibili di rivelare lo stato di
privilegio degli invitati.
L’ultimo ostacolo è la gestione delle periferiche : generando degli accessi in memoria e delle interruzioni, le periferie devono essere gestite dal VMM che deve poi
emularle per ogni OS invitato. Una fonte in più per il ritardo e soprattutto una perdita
enorme di funzionalità.
18
CAPITOLO 2. VIRTUALIZZAZIONE
2.5 Soluzioni esistenti per il problema dell’x86
Per semplificare tutto questo, Intel ha concepito VT e AMD V. Queste due tecnologie sono molto simili, al punto che non faremo differenza tra loro nella descrizione
seguente. Intel VT e AMD V si compongono entrambi di tre parti ciascuno destinato a risolvere le difficoltà della virtualizzazione del CPU , della virtualizzazione della
memoria, e della virtualizzazione delle periferie. Vediamo ciascuna di queste soluzioni.
2.5.1 La virtualizzazione della CPU :Intel VT-x e AMD-V
Per facilitare la virtualizzazione della CPU, Intel e AMD hanno cercato di eliminare la
necessita di sorvegliare e di tradurre delle istruzioni. Per fare questo, nuove istruzioni
sono state aggiunte. Una nuova struttura di controllo è anche nata , battezzata VMCS
(Virtual Macchine Control Structure ) mostrato nella figura 2.5. Tra le nuove istruzioni,
una di loro (VM entry) permette di commutare il processore in una nuova modalità di
esecuzione, dedicato ai sistemi guest. Questa modalità possiede anche quattro livelli
di privilegi diversi. Cosi sono eliminati i problemi legati all’esecuzione del OS guest
nel anello 3 : l’ OS guest può girare in anello 3 della modalità VM. Quando il contesto
lo richiede il processore passa dalla modalità guest alla modalità normale. Questo passaggio è deciso dalle condizioni fissate dal VMM grazie ai bit di controllo memorizzati
nella VMCS.
Figura 2.5: VMCS di Intel e AMD
Al momento del passaggio, lo stato del processore nella modalità guest è memorizzato nella VMCS e lo stato del processore nella modalità host è ricaricata dalla VMCS.
Le istruzioni necessarie sono quindi eseguite, poi il VMM fa uscire il processore dalla
modalità host per riportarlo in modalità guest , memorizzando lo stato del processore
host nella VMCS e ricaricando lo stato guest precedentemente memorizzato. Non c’è
quindi più traduzioni di istruzioni. Il passaggio si fa in maniera automatica grazie alle
regole fissate nella VMCS. Intel e AMD pensano cosi di aumentare considerevolmente
2.5. SOLUZIONI ESISTENTI PER IL PROBLEMA DELL’X86
19
la velocità del hypervisor. In tanto, dei test realizzati da Vmware tendono a dimostrare
che il guadagno non è cosi evidente.
Il guadagno sarebbe più netto con Parallels Workstation. Intel VT e AMD-V sono
delle soluzioni ancora molto giovani e non mature. Dei grossi progressi in questo
dominio sono attesi. D’altra parte, Intel e AMD hanno previsto di allargare il campo
delle ottimizzazioni.
Nel futuro prossimo è prevista la virtualizzazione come della memoria o del Input/Output.
2.5.2 Riferimento per provare la virtualizzazione
Si presenta alcuni delle soluzione più frequenti nel mercato:
1. Microsoft Virtuali PC 2004. Non prende in carico VT o V.
2. Vmware Workstation 5.5 : La versione 5.5 prende già in carico le ottimizzazione
Intel VT. La beta di Vmware Workstation 6.0 è uscita . È gratuita e contiene il
supporto di Windows Vista.
3. Vmware Fusion: È il nome della beta di Vmware workstation per Mac Intel
4. Parallels Workstation o Parallels Desktop for Mac: Il primo funziona su PC, il
secondo su Mac. Entrambi gestiscono le ottimizzazioni Intel VT. In più Parallels
Desktop for Mac è l’unico hypervisor a gestire l’accelerazione 3D offerte dalle
schede grafiche sotto le sue macchine virtuale.
5. Qemu per Linux : opera come virtualizatore
6. Xen: soluzione di paravirtualizzazione, Opensource.
Nella tabella 2.1 sono presenti i processori Intel e AMD che integrano le ottimizzazioni
descritte precedentemente.
INTEL
AMD
Core Duo, Core solo, Core 2Duo, Core 2 extreme
Pentium EE, Pentium D
Xeon, XeonMp
Itanium 2
tutti i CPU in socket AM2 tranne le sempron
Opteron Socket F
Turion S1
Tabella 2.1: Processori AMD e Intel che implementano il supporto alla virtualizzazione
CAPITOLO 2. VIRTUALIZZAZIONE
20
2.6 Prospettive future
2.6.1 Virtualizzazione memoria
Un sistema operativo quando è l’unico a girare su una macchina, si occupa dell’indirizzamento totale della memoria centrale. In altri termini, decide di allocare una certa
quantità per ogni applicazione, quantità che sarà compresa tra il bit d’indirizzo x e
quello d’indirizzo y. Questo indirizzamento è realizzato su un spazio virtuale, detta
lineare o logico, che rappresenta la totalità della memoria centrale disponibile, la memoria virtuale può essere rappresentata sul disco fisico. La corrispondenza tra questa
memoria lineare e la memoria fisica è realizzata da una unita di CPU, la MMU (Memory Management Unit). La MMU mantiene aggiornato la page table ovvero la tabella
di corrispondenza tra gli indirizzi fisici e quelli lineari.
Su una macchina sulla quale girano più di un sistema operativo, ciascuno deve
utilizzare solo una porzione della memoria totale. La condivisione è decisa dal VMM
nel momento della creazione di ogni VM. Per esempio, l’OS 1 deve utilizzare i bit zero
a x, e l’OS 2 i bit x+1 a z, ma purtroppo un OS inizia sempre il suo indirizzamento a
zero. Per evitare i conflitti tra i vari OS che girano simultaneamente, bisogna quindi
che l’hypervisore blocca tutti i accessi dei OS verso la MMU e li reinterpreta. Il VMM
costruisce quindi, per ogni OS, una ”falsa” page table che fa corrispondere gli indirizzi
lineari reclamati dal OS a quegli che li sono riservati. Questa tabella di corrispondenza
intermediaria è chiamata Shadow Page Table (SPT). Infine, un semplice accesso alla
memoria diventa un operazione complessa. Vediamo gli schemi di queste operazioni
con virtualizzazione e senza.
2.6.1.1 Senza virtualizzazione:
La MMU Page Table traduce gli indirizzi della memoria virtuale in indirizzi fisici della
memoria centrale
Figura 2.6: Indirizzamento senza virtualizzazione
2.6.1.2 Con virtualizzazione
Gli indirizzi lineari delle macchine virtuali vengono tradotti in indirizzi logici della macchina fisica o host dal VMM SPT, infine questi indirizzi vengono tradotti in
indirizzi fisici dal MMU PT
2.6. PROSPETTIVE FUTURE
21
Figura 2.7: Indirizzamento con virtualizzazione
2.6.1.3 Soluzione esistente
Per ridurre il lavoro del VMM, Intel e AMD hanno inventato Extended Page Tables
(EPT) e Nested Page Tables (NPT) rispettivamente. Si tratta in emtrembi i casi di
implementare gli SPT in hardware. In più della PT della MMU, ci sono quindi una EPT
o NPT per ogni OS guest. Queste tabelle permettono infatti di dedicare una parte degli
indirizzi fisici della memoria ad ogni OS. Questi possono quindi accedere direttamente
ai loro dominio di indirizzo, senza provocare l’intervento del VMM. L’insieme degli
indirizzi di memoria fisiche dei OS guest è poi ricompilato nel EPT. Lo schema è il
seguente:
Figura 2.8: Schema del EPT e SPT
Queste optimizazzione non sono ancora attivati nei processori Intel o AMD venduti
attualemente. Si pensa che lo saranno nel corso dell’anno 2007.
2.6.2 Virtualizzazione delle periferiche
L’ultimo cantiere della virtualizzazione hardware è quello delle periferiche. In effetti, attualemente, i VMM utilizano un driver generico per tutte le VM qualsiasi sia il
hardware installato nella macchina. I sistemi operativi guest vedono delle periferiche
virtuali, emulati dal VMM, e tutte le loro richieste vanno al VMM che li reindirizza vers
l’hardware. La virtualizzazione delle periferiche permeterebbe di montare direttamente
una periferica su una macchina virtuale, questo permetterebe un guadagno importante
in termini di velocità di esecuzione. Ma sopprattuto si può sperare di vedere le funzionalità delle VM moltiplicati: riconoscimento di un gran numero di apparecchiature
come fotocamera, stampa, chiavi USB,ecc.. .
22
CAPITOLO 2. VIRTUALIZZAZIONE
2.7 Conclusioni
Questa tecnologia costituirà uno dei temi di maggior sviluppo dei CPU Intel, e AMD
per i prossimi anni . Sotto questo auspicio, e grazie a la moltiplicazioni del numero del
core interno dei processori. I vantaggi che ognuno potrà trarne sono tanti, sicurezza,
stabilita, interoperabilità, ecc.. ma bisogna aspettare finché le performance offerte dalle
ottimizzazioni hardware implementate dai costruttori saranno veramente efficaci.
Capitolo 3
Xen
Xen è un progetto ideato dall’università di Cambridge in Inghilterra. Conosce una
popolarità crescente, poichè comincia ad essere integrato nei distribuzioni Linux dei
più grandi editori del mondo libero (Novell, Red Hat, Fedora). Il progetto ha addirittura
contribuito alla creazione di una azienda, XenSource, che recentemente ha siglato un
accordo tecnologico con Microsoft che tratta la prossima offerta di virtualizzazione che
sarà proposta dal futuro server Windows Longhorn. Attualmente esistono due versioni
: Xen 2.0 e Xen 3.0. La versione a cui ci riferiremo di seguito sarà l’ultima ovvero la
3.0.
Figura 3.1: Logo di Xen
3.1 Xen e paravirtualizazzione
Xen è un monitor di macchine virtuale o hypervisor. Ma contrariamente alle altre soluzioni che esistono in questa categoria, Xen possiede una particolarità, è una soluzione
23
CAPITOLO 3. XEN
24
molto efficiente in termini di performance. Questa particolarità è dovuta al fatto che
Xen è basata non sulla virtualizzazione ma sulla paravirtualizazzione, cioè Xen non mira a creare un emulazione dell’hardware di un generico computer x86 su cui far girare
il sistema operativo , ma piùttosto di regolare e controllare l’accesso alle risorse fisiche
della macchina da parte delle varie istanze delle macchine virtuali; questo approccio
prende il nome di paravirtualizzazione ed è simile a ciò che si utilizza nel campo dei
mainframe e dei supercomputer, come ad esempio nei sistemi operativi VM/CMS e
OS/360 di IBM, in cui il virtual machine monitor di macchine virtuali è implementato
direttamente nell’hardware dei processori. Questo tipo di approccio accresce l’efficienza.Tuttavia questo comporta che il sistema operativo destinato a girare sulla macchina
virtuale (guest) debba essere portato per essere reso compatibile con Xen, in quanto alcune chiamate di sistema del kernel non sarebbero possibili. Questa modifica permette
già di realizzare una parte della virtualizzazione.
3.2 Sistemi operativi supportati
Una altra particolarità di Xen è la sua terminologia. La macchina virtuale è differenziata del contesto nel quale gira, questo contesto chiamato “dominio”. Il manuale di uso
dice “la relazione tra le macchine virtuali ed i domini è simile a quella tra i programmi ed i processi : una macchina virtuale è una entità persistente che risiede nel disco.
Quando è caricata per essere eseguita, funziona in un dominio. Ogni dominio possiede
un identificatore unico, identico ad un identificatore di un processo”. Un dominio Xen
può essere costituito da kernel Linux (2.4 e 2.6) e NetBSD/FreeBSD. Si distinguono 2
tipi di domini :
• Dom0 o dominio privilegiato
• DomU o dominio non privilegiato
Il primo rappresenta l’istanza di macchina virtuale creata direttamente dall’hypervisor
al momento del boot. Da esso possono essere fatte partire successivamente le altre macchine virtuali. Tutte le altre istanze di macchina virtuale in esecuzione sono dominioU
e per ogni istanza viene creato un nuovo dominio. Nella tabella xx è presente la lista
dei sistemi operativi supportati per ogni dominio fino alla versione attuale (versione
3.0).
La figura 3.2 mostra un esempio di varie macchine virtuali o sistemi operativi in
una sola macchina con Xen che dirige ”l’orchestra”.
3.3. ARCHITETTURA DI XEN
Sistema operativo
Linux 2.6
NetBSD 3.1
NetBSD 4.0_BETA2
sistema operativo non-modificato
25
Dom0 (host OS)
Si
No
Si
No
DomU (guest OS)
Si
Si
Si
solo Intel Vt-x e AMD-v
Tabella 3.1: Sistemi operativi supportati da Xen
Figura 3.2: Imagine di una schermata con aperti varie macchine virtuali con Xen
3.3 Architettura di Xen
Xen non ha supporto diretto per la maggior parte dell’hardware. Per utilizzarlo si fa
” aiutare ” dal primo sistema virtuale, il Domain0, che è anche il sistema dall’interno
del quale tutti gli altri possono essere gestiti. Tale sistema è il primo a fare boot, e
direttamente alla partenza del sistema (Xen non è un sistema operativo completo, e non
può esistere ”da solo”). Altri domini possono avere l’accesso a parte dell’hardware, se
specificato nella configurazione.
Sullo schema mostrato in figura 3.3 , si vede la presenza dello strato Xen VMM
sullo strato hardware. Al di sopra si trova il Dominio0, privilegiato; questo ultimo è
l’unico capace di utilizzare le chiamate del sistema specifiche, è lui che controlla gli
altri domini. Le richieste provenienti dagli altri domini sono trattate dal Dominio0.
CAPITOLO 3. XEN
26
Figura 3.3: Architettura di Xen
3.4 Confronto con altre soluzioni di virtualizzazione
Generalmente, la virtualizzazione necessita un sistema operativo host installato sull’
hardware, e possibilmente uno strato intermedio. Uno o molti sistemi operativi guest
possono quindi essere installati contemporaneamente.
3.4.1 Sul funzionamento
• I software di virtualizzazione di tipo QEMU, VMWare Workstation/GSX ou VirtualPC sono delle macchine virtuali complete per i sistemi operativi guest, è inclusa anche un BIOS software (Firmware) . Il sistema operativo guest ”crede” di
girare su un hardware, allorché è virtualizzato dal software di virtualizzazione.
Queste soluzioni sono le più semplici da realizzare ma poco efficienti.
• Il software di virtualizzazione di tipo VMWARE ESX permette delle macchine
virtuali complete per i sistemi operativi guest; includono anche un BIOS, ma a
differenza delle soluzioni sopra descritte, le macchine virtuali si trovano su un
Kernel leggero chiamato vmkernel. È un architettura molto simile a Xen.
• I software di tipi chroot, Linux-VServer, OpenVZ o BSD Jail fanno solo isolare certi aspetti o risorse del sistema operativo Host come il file system o gli
indirizzi di memoria. Queste soluzioni sono molto efficienti, dato che c’è poco
sovraccarico, ma gli ambienti virtualizzati sono poco o niente isolati.
• User Mode Linux(acronimo UML) è un kernel Linux compilato per funzionare
3.4. CONFRONTO CON ALTRE SOLUZIONI DI VIRTUALIZZAZIONE
27
in spazio utente di memoria. Si lancia quindi come una applicazione dentro il
sistema operativo Host. UML può lanciare e gestire le sue applicazioni in maniera isolata dalle altre UML che girano sulla macchina. Soluzione, molto poco
efficiente, poichè due KERNEL sono caricati; è usata sopratutto nello sviluppo
del kernel.
3.4.2 Sulla performance
In figura 3.4 è ben visibile che il decadimento di performance di Xen è mimino rispetto
ad altre soluzioni. Il rendimento con SPEC INT2000 (CPU intensive), che possiede un
tasso di operazione di I/O molto basso quindi impegna meno i OS, le tre soluzioni di
virtualizzazione hanno rendimento abbastanza buono. Invece per gli altri benchmarks
che hanno un tasso elevato di I/O le altre soluzioni si dimostrano poco efficienti rispetto
a Xen.
Figura 3.4: Confronto performance Xen e altre soluzioni di virtualizzazione
(L= native Linux, X= Xen/Linux, V= VMware Workstation, U= User Mode Linux)
CAPITOLO 3. XEN
28
3.5 Demoni Xen
3.5.1 Xend
Il demone Xend gira nel dominio0 esso è incaricato alla gestione, creazione, controllo
dei domini non privilegiati, si possono dare ordini a questo demone a traverso il tool
xm (vedere appendice A) o attraverso un altro tool con un interfaccia Web.
3.5.2 Xenstored
Questo demone si occupa della gestione e della memorizzazione delle informazioni
relative alle varie istanze che girano sopra il domini0
3.6 Conclusione
Xen è l’esempio perfetto della creatività e della credibilità del mondo Open Source1.
In effetti, questo progetto universitario è diventato uno dei maggiori nell’ambito della
virtualizzazione, tecnologia che ha tutto il suo futuro davanti, ed i recenti accordi siglati con Microsoft dimostrano che anche i grandi “ calibri “ sono interessati da questa
realtà. Per l’utilizzazione, Xen è realmente piacevole ad utilizzare, con delle performance eccezionali. Il grosso problema, per adesso è la sua complessità rispetto alle
altre soluzioni che hanno tutte un interfaccia grafica completa. Virt-manager è un interfaccia che può essere usata anche per Xen ma non è un strumento ideale sopratutto
per i debuttanti che non sono in grado di configurare i file di creazione di domini che
vedremmo nell’apendice A. Inoltre, non ci sono ancora strumenti come P2V (Physical
to Virtual), che permettono di creare domini a partire di una macchina fisica esistente.
Ma la versione, non gratuita di Xen, XenEnterprise, permette di superare queste lacune, offrendo un interfaccia molto più completa e uno strumento di migrazione P2V, che
funziona solo con i Kernel “Xenzzati”.
1 software
libero senza licenze restrittivi
Capitolo 4
Prototipo e Test
In questo capitolo si spiega come funziona il prototipo dell’alta disponibiltà tramite la
virtualizzazione, e si presentano le varie tecnologie di memorizzazione che possono
essere utilizzate. Infine si presentano i test effettuati sulle varie soluzioni di storage per
trovare la soluzione migliore in termini di scalabilità e di efficienza.
4.1 Prototipo
4.1.1 Schema funzionale
La figura 4.1 rappresenta lo schema funzionale del prototipo
4.1.2 Composizione
Come si vede nella figura 4.1 la struttura è composta da:
• Macchine fisiche: Sono le macchine sul quale sono presenti le macchine virtuali,
Xen è installato su questi e ovviamente sono sistemi compatibili con Xen come
per esempio GNU/Linux.
• Macchine virtuali: Si tratta delle macchine virtuali dove girano i servizi; ogni
macchina virtuale può essere trasferita da un macchina fisica ad un’altra
• Memorizzazione: È il sistema che si occupa della memorizzazione dei VM; questi ultimi vengono caricati attraverso la rete dallo storage alle macchine fisiche, ci
sono varie soluzioni disponibile, effettueremo varie test per trovare la soluzione
migliore.
29
CAPITOLO 4. PROTOTIPO E TEST
30
Figura 4.1: Struttura del prototipo
• Nodo di monitoraggio: Si occupa del controllo della situazione delle VM; rileva
la caduta o il malfunzionamento delle VM e causa il loro trasferimento verso
altre macchine fisiche.
4.1.3 Funzionamento
L’obiettivo principale di questo prototipo è quello di rendere altamente affidabili le
macchine che forniscono i servizi. Questo scopo è realizzato in 2 passi, il primo passo
consiste nel virtualizzare le macchine sulle quale sono in esecuzioni i servizi, il secondo passo consiste nel monitoraggio della situazione in modo continuo per rilevare e
risolvere problemi. Ognuno di questi passi è complesso e richiede un’accurata scelta
sia di hardware che di software.
4.1.3.1 Virtualizzazione delle macchine critiche
Le macchine critiche sono le macchine in cui un loro rallentamento o un loro guasto
comporterebbe una perdita dei dati importanti e non solo. Questi macchine sono virtualizzati di conseguenza anche i dati o servizi presenti su queste. Come spiegato nel
capitolo 2 ci sono vari tecniche di virtualizzazione, ma la tecnica adottata in questo
caso è la para virtualizzazione usando come hypervisor Xen. Xen deve essere installato su tutte le macchine fisiche che devono accogliere le macchine virtuali, in questa
operazione ovviamente bisogna tenere conto che non tutti i sistemi operativi (Vede-
4.2. STORAGE
31
re capitolo 3) possono eseguire Xen, per questo si è scelto di usare una distribuzione
Linux(da aggiungere).
4.1.3.2 Nodo di monitoraggio
Il nodo di monitoraggio è molto importante in questa soluzione, perchè si occupa non
solo della rilevazione dei problemi delle macchine virtuali ma anche alla risoluzione
di questi problemi. Per realizzare questo controllo, ci sono molti software nel mercato
come Nessus, Snort, Ethereal, CFengine Nagios, questo ultimo è quello usato in questo
prototipo. Nagios è una applicazione open source per il monitoraggio di computer e risorse di rete. La sua funzione base è quella di controllare nodi, reti e servizi specificati,
avvertendo quando questi non garantiscono il loro servizio o quando ritornano attivi.
Nagios si decompone in 3 parte:
• Un motore di applicazioni che ordina i comandi di supervisione
• Un interfaccia WEB, che permette di avere una vista della situazione e delle
possibili anomalie
• I plugins, una centinai di minipogrammi che possono configurati in maniera
personalizzata
Figura 4.2: schermata di nagios
4.2 Storage
4.2.1 Introduzione
Il nodo di storage si occupa della memorizzazione di dati, in questo caso come si è
detto precedentemente della memorizzazione dei file system delle macchine virtuali.
CAPITOLO 4. PROTOTIPO E TEST
32
Questo nodo è uno dei nodi più critici di questa soluzione in quanto da la possibilità
a tutte le macchine fisiche di poter accedere i file system delle VM a traverso la rete.
Questo rende le VM visibile a tutti i nodi della rete, cosi quando cade una macchina
fisica il nodo di controllo può trasferire le macchine virtuali che erano in esecuzione
su questa macchina verso una altra macchina fisica che funziona caricando i loro file
system direttamente dal nodo di storage. Ovviamente lo storage deve essere affidabile
per garantire l’integrità dei dati.
Per la realizzazione dello storage ci sono varie tecnologie disponibili tra cui:
• File system remoti
• Block device remoti via hardware
• Block device remoti via software
4.2.2 File system remoti
Questa soluzione consiste di installare un file system distribuito, in questo modo tutte
le macchine possono accedere ai dati che si trovano nelle altre macchine. Ci sono molti
file system disponibili, tra cui il NFS, AFS, GFS, GPFS, ecc ... . Uno o più file server
fanno un export di partizioni di dischi nella rete, di seguito le altre macchine possono
usare queste partizione. L’implementazione dipende del file system distribuito, ci sono
alcuni file system come AFS (Albert File System) dove bisogna installare un server ed
un client, ed altri no.
4.2.3 Block device remoti via hardware
Questa soluzione consiste nell’esportazione block device che sono collegati a dispositivi di rete; questi device hanno un particolare hardware e sono appositamente dedicati e
fatti per la memorizzazione. Questa soluzione offre alte prestazioni ma è anche costosa.
Ci sono 3 principali tecnologie che sono i più usati.
4.2.3.1 iSCSI
iSCSI è un protocollo del livello applicazione che permette di trasportare i comandi
SCSI su una rete che usa i protocolli TCP/IP. È un protocollo di incapsulamento: serve
a trasportare un protocollo di alto livello, in questo caso il protocollo SCSI. iSCSI è
stato standardizzato dal ’IETF in aprile 2004 e definito nel Request For Comments.
iSCSI è basata su un paradigma di tipo Client-Server. Esiste un server chiamato
target che esporta partizioni o dischi attraverso comandi SCSI ed un client chiamato
4.2. STORAGE
33
initiator che importa queste risorse sempre attraverso comandi SCSI. Per l’installazione via hardware ci sono appositi scatole con interfaccia ethernet che implementa il
protocollo iSCSI, in questa scatola si inseriscono i dischi ed infine la si collega alla rete
per poter essere utilizzata.
4.2.3.2 ATA OVER ETHERNET (AoE)
Si tratta di protocollo di comunicazione di rete che usa le stesse norme di ethernet. Essendo prima di tutto destinato alle reti LAN e non all’Internet non si basa sui protocolli
TCP/IP; ciò permette un guadagno in termini di performance, ma usa direttamente gli
indirizzi MAC. Il vantaggio di questo tipo di funzionamento è la possibilità di utilizzare
qualsiasi hardware conforme alle specificazione di Ethernet. Un semplice switch basta
per connettere dischi AoE ai computer della rete. Il protocollo è basato su architettura
client-server, esiste un server chiamato target che esporta le partizioni ed un client che
li importa questi partizioni.
4.2.3.3 Fibre Chanel
Fibre Chanel è un protocollo che inizialmente era concepito per i supercomputer ma è
diventato standard dei SAN (storage area network), permette di avere buone prestazioni in termini di efficienza. Per implementarlo basta collegare il dispositivo coll’interfaccia fibre chanel ai computer anche essi con interfaccia FC.
4.2.4 Block device remoti via software
Questa soluzione consiste nell’esportazione di blocchi di partizioni nella rete a traverso
software specifici, questo permette di avere buone prestazioni senza avere la necessita
di possedere hardware. Vedremo 2 soluzioni che sono iSCSI e ATA over Ethernet
4.2.4.1 iSCSI
Come si è spiegato in precedenza, il protocollo è basato su un architettura client-server,
quindi per fare un implementazione bisogna installare il server ossia un target sul file server ed un client chiamato initiator sulle macchine fisiche. Il funzionamento di
questo protocollo è semplice: Il target installato sul lato server esporta partizioni o
blocchi a traverso la rete, ed l’ initiator installato sul lato client fa una scoperta di
questi elementi con un processo specifico.
L’installazione e la configurazione di iSCSI è descritta nell’appendice B.
CAPITOLO 4. PROTOTIPO E TEST
34
4.2.4.2 ATA over ETHERNET (AoE)
AoE è anche esso un protocollo basato su un’ architettura client-server, un target (server) che esporta risorse con appositi tools, ed un initiator (client) che li importa sempre
con tools specifici. Per implementarlo bisogna installare il target sul file server ed l’
initiator sulle macchine fisiche. Il tool usato per l’esportazione si chiama Vblade, il
funzionamento è analogo a quello di iSCSI, il target in questo caso Vblade esporta
partizioni dal lato server e l’initiator fa una scoperta di questi partizioni.
L’installazione e la modalità di uso di Vblade è descritta nell’appendice B.
4.3 TEST
4.3.1 Sistema dei test
Sono stati utilizzati 3 macchine fisiche e un file server per effettuare i test, le tabelle
4.2 e 4.3 mostrano le caratteristiche di queste macchine.
Processore
Memoria
Disco
Connessione Rete
Sistema Operativo
Dual Pentium III 1GHz
256MB
210GB - RAID 5
Gigabit Ethernet
Slackware Linux 10.2 - Kernel 2.6.15.6
Tabella 4.2: Caratteristiche file server
Processore
Memoria
Disco
Connessione Rete
Sistema Operativo
Intel Xeon a 3.12 Ghz
1GB
40GB
Gigabit Ethernet
Linux - Kernel 2.6.16-xen
Tabella 4.4: Caratteristiche macchine fisiche
Lo schema della figura 4.3 mostra la struttura con la quale sono stati effettuati i test.
4.3. TEST
35
Figura 4.3: Struttura del sistema dei test
4.3.2 Tools per i test
4.3.2.1 IOzone
Iozone è un software di misurazione delle prestazione di un sistema storage, questo
programma è stato utilizzato per realizzare i test, si può scaricarlo da questo indirizzo:
http://iozone.org
Per l’installazione basta compilarlo col commando : make ; make linux, per l’uso
e le opzioni disponibili riferirsi alla documentazione inclusa.
4.3.2.2 Bonnie
Bonnie è un altro benchmark che è stato utile per realizzare alcuni test non pesanti sulle macchine virtuali, si può trovarlo in questo indirizzo: http://texttuality.
com/bonnie/, per installarlo bisogna compilarlo col commando: make, è inclusa
una documentazione sull’uso e le opzioni disponibili.
4.3.3 test scalabilità
In questi test si è voluto verificare il comportamento del prototipo in termini di scalibilità per i due protocolli iSCSI e AoE. Le macchine virtuali create in questi test
36
CAPITOLO 4. PROTOTIPO E TEST
sono stai installato su partizioni LVM1 questa scelta è stata obbligatoria in quanto non è
possibile fare partire macchine virtuali con Xen con partizioni “normali” questo ovviamente influisce sul rendimento ma è stato applicato la stessa cosa anche col protocollo
iSCSI. Sono stati fatti alcuni rilevazione in funzione del numero di macchine virtuali
impiegati:
• carico del File server: Il carico del file server si ottiene col commando Uptime
che da come risultato qualcosa del genere:
23:02:23 up 23 days, 23:25, 1 user, load average: 0.57, 0.57, 0.83
dove il load average indica il carico del lavoro, un punto di carico equivale a dire
che la CPU ha lavoro a sufficienza per riempire il suo naturale ciclo di calcolo della
durata di un secondo. Per dirla in altro modo, nell’arco di un secondo la CPU non
ha tempo di eseguire un NOP, ossia un’istruzione vuota, che non fa nulla, che viene
abitualmente "eseguita” nelle pause di elaborazione. Questa rilevazione ha l’obiettivo
di darci un idea sull’andamento del carico del file server in funzione della crescita del
numero delle macchine virtuali.
• Throughput delle VM per le operazione di read e write con un job leggero: si
prende la somma della velocità delle VM sia con iSCSI che AoE per le operazioPn
ne di read e write.il troughput con n numero di macchine virtuali è uguale: i=1 Vi
dove Vi è la velocità delle operazione con la macchina virtuale i. La media delle
Pn
velocità per n numero virtuali è data da Vn = i=1 Vi /N, quindi il troughput con
N VM(Virtual Macchine) è Tn =Vn *N, se si aumenta il numero delle VM a m
dove m => n abbiamo il troughput con m VM Tm =Vm *M; in teoria se il troughput è quello effettivo si dovrebbe avere Tn => Tm quindi Vn *N => Vm *M
N
=> VVm
cioè il rapporto fra il numero delle VM n con
questo implica : 1 => M
n
il numero delle VM m deve essere maggiore o uguale al rapporto fra la velocità
media con i rispettivi numero delle VM, questo ovviamente è una conseguenza
del troughput effettivo.
• Velocità media delle VM per avere un idea sul comportamento del insieme delle
VM e vedere quanto scende e con che andatura questa velocità col crescere del
numero delle VM.
È stato usato una scala di numero di macchine virtuali che parte da 1 fino 20 e facendo
rilevamenti sui i punti: 3,6,9,15, e 20 macchine. Si è lanciato in ogni macchina un
job leggero e si sono rilevati gli criteri precedentemente menzionati, questi test hanno
l’obiettivo di testare la scalabilità dei due protocolli e di fare un confronto tra di loro.
1 Il gestore logico dei volumi (anche noto come logical volume manager o LVM) è un software di gestione
dei dischi disegnato per essere più flessibile del normale partizionamento fisico
4.3. TEST
37
Oltre a grafici relativi alle misurazione dei termini sopra menzionanti e al confronto
tra iSCSI e AoE in questi termini, si è anche prodotto grafici che rappresentano le
distribuzioni delle macchine rispetto al tempo impiegato da questi ultimi a finire i test.
I risultati ottenuti sono presentati in forma grafica di seguito.
4.3.3.1 iSCSI
La figura 4.4 mostra il grafico che rappresenta il troughput prodotto per le operazione
di write e di read nei vari test, come si può vedere c’ è un irregolarità. Il valore del
troughput con una sola macchina in teoria dovrebbe corrispondere la capacita massima
del canale di comunicazione che per tutti i test è stato un solo. Quindi questo valore
dovrebbe rimanere uguale o diminuire aumentando il numero delle macchine virtuali
ma come si vede nel grafo il troughput varia molto ed è irregolare. Questo fatto è
probabilmente dovuto al fatto che il valore del troughput per una sola macchina o per
un certo numero di macchine virtuali in cui il trougput è irregolare, non corrisponde
alla capacita effettiva del canale, ovvero la velocità delle operazione sia di write che di
read per queste macchine è inferiore alla velocità massima possibile.
Figura 4.4: troughput per le operazione di read e write
Da notare comunque anche nella figura 4.5 la dimunuzione delle velocità media di
read e write, questo dimostra che esiste un certo limite per il numero delle macchine
virtuali che possono essere presenti sullo stesso canale.
La figura 4.6 e 4.7 mostrano le distribuzione delle VM rispetto ai tempi impiegati
per svolgere i test di read e write, i test consistevano in un job che scrive e che legge su
38
CAPITOLO 4. PROTOTIPO E TEST
Figura 4.5: velocità media delle VM per le operazione di read e write
un file di dimensione di 300MB; come si vede per l’operazione di read ci sono 9 VM
che hanno impiegato a finire l’operazione tra 3 e 4 ore, 5 VM tra 6 e 7, questa distribuzione è più o meno omogenea. Per la scrittura figura 4.7 invece c’è più omogenità in
quanto ci sono solo 3 gruppi, 11 Vm che hanno fatto tra 2 e 3, 6 tra 3 e 4, e 3 tra 1 e 2.
Figura 4.6: distribuzione delle VM per read
Infine la figura 4.8 rappresenta il carico del file server in funzione del numero delle
VM, come si può notare il carico cresce e quindi c’è un impiego crescente delle CPU
col crescere del numero delle VM.
4.3. TEST
39
Figura 4.7: distribuzione delle VM per write
Figura 4.8: Carico del file server
4.3.3.2 AoE
Per il protocollo AoE si osserva nella figura 4.9 che il troughput diminuisce col crescere del numero delle VM sia per l’operazione di write che per l’operazione di read, per
il write si vede una diminuzione più contenuta rispetto a quella con l’operazione. La
diminuzione regolare del troughput dimostra comunque una diminuzione delle prestazioni col crescere del numero delle VM; questa perdita di efficienza è più grande per
l’operazione di read.
40
CAPITOLO 4. PROTOTIPO E TEST
Figura 4.9: Troughput delle operazione di read e write
Nella figura 4.10 si vede la velocittà media delle VM per read e write, come si vede
questa velocità diminuisce col aumentare delle VM, questo fatto mostra che esiste un
valore che indica il numero delle VM in cui la velocità delle operazione potrebbe essere
molto bassa e quindi un limite nella scala delle VM.
Figura 4.10: Velocità media di read e write con aoe
La figura 4.11 e 4.12 mostrano le distribuzione delle VM rispetto ai tempi impiegati
per svolgere i test di read e write, i test sono gli stessi con iscsi; come si vede per
4.3. TEST
41
l’operazione di read ci sono 8 VM che hanno impiegato a finire l’operazione tra 3 e 5
ore, il resto delle VM hanno impiegato un tempo maggiore di 35 ore e ricordando che
si trattava di un file di dimensione 300MB questo tempo è molto grande, in effetti la
distribuzione è sparsa quindi esiste 2 gruppi di macchine virtuali con risultati diversi,
un gruppo con risultato più o meno accettabile ed un altro con tempi molto lunghi e
quindi non accettabili. Per la scrittura figura 4.12 invece c’è più omogenità in quanto
anche se ci sono sempre 2 gruppi, la differenza fra i due gruppi è minore rispetto a
quella che c’è per l’operazione di read.
Figura 4.11: distribuzione delle VM per read
Figura 4.12: distribuzione delle VM per write
La figura 4.13 mostra che il carico del file server col crescere delle VM, si nota
che non c’è grande cambiamento tra il carico per una macchina ed il carico per 20
macchine, infatti si passa da 1 a 2. Questo fatto è dovuto principalmente al fatto il
42
CAPITOLO 4. PROTOTIPO E TEST
protocollo AoE che utilizza pochi livelli precisamente solo il livello MAC della pila
dei protocolli TCP/IP, quindi i pacchetti AoE richiedono pochi manipolazioni e quindi
impegnano meno la CPU.
Figura 4.13: Carico del file server
4.3.3.3 Confronto dei risultati ed interpretazioni
Nelle figure seguenti si è cercato di fare un confronto dei risultati tra il protocollo AoE
e il protocollo iSCSI. Le figure 4.14 e 4.15 mostrano rispettivamente il confronto di
troughput per le operazione di read e di write, come si può vedere per l’operazione di
read il troughput ha lo stesso valore per una sola macchina virtuale per iSCSI e per
AoE ma col crescere del numero delle VM il troughput di AoE diminuisce in maniera
monotona invece per iSCSI il troughput ha un andatura irregolare, comunque con iSCSI
si possiede un troughput molto maggiore di quello di AoE questo significa una velocità
media più grande per iSCSI e quindi una maggiore scalabilità.
Per l’operazione di write in figura 4.15 abbiamo più o meno gli stessi comportamenti dell’operazione di read, c’è una grande differenza di troughput tra i due protocolli,
4.3. TEST
43
Figura 4.14: Confronto sull’operazione di read
il troughput maggiore per AoE si ottiene con una sola macchina ed è 4Mb/s invece
per iSCSI si ottiene con 9 macchine ed è verso 10,5Mb/s, questa significa una velocità
media più grande per iSCSI e quindi può fare funzionare più VM rispetto a AoE.
Figura 4.15: Confronto sull’operazione di write
Nella figura 4.16 si nota che esiste una grande differenza del carico del file sever tra
i due protocolli, per il protocollo iSCSI si osserva un carico di lavoro che parte da 5 per
1 macchina virtuali e aumenta fino 8,5 per 20 VM, invece per il protocollo ATA il carico
di lavoro varia da 1 per una macchina virtuali a 2 per 20 VM. Per entrambi i protocolli
la variazione è poca anche se c’è una grande differenza tra di loro. Questo fatto può
CAPITOLO 4. PROTOTIPO E TEST
44
essere spiegato come detto precedentemente il fatto che i pacchetti del protocollo AoE
passano pochi livelli essendo AoE basato solo su MAC address rispetto ai pacchetti di
iSCSI basato su TCP/IP
Figura 4.16: Confronto sul carico del file server
4.3.4 Test I/O
I test di I/O sono stati effettuati con il tools di Iozone, hanno l’obiettivo di fare un
confronto tra i protocolli iSCSI e ATA in termini di efficienza. Si è lanciato un job
pesante e si sono rilevati le velocità di alcune operazione tra cui READ e WRITE.
4.3.4.1 iSCSI
La velocità dell’operazione effetiva si vede a partire della dimensione di file superiore
al 256 MB perché non ci sono più effetti della cache e della memoria centrale che ha
una dimensione di 256 MB. Si ha un valore che parte da più o meno per il write di 4096
kb/s e di 18Mb/s per il read.
4.3.4.2 ATA
È stato usato sempre lo stesso file server di quello con iscsi.
Nelle figure 4.19 e 4.20 si osserva che si ha per AoE un valore di velocità che inizia
per il write di circa 4096 kb/s e di circa 16384 per il read.
4.3. TEST
45
Figura 4.17: Operazione di write
Figura 4.18: Operazione di read
4.3.4.3 Confronto dei risultati ed interpretazione
Si fa un confronto di rendimento tra i due protocolli, nelle figure 4.21 e 4.22 si mostrano
un grafo 3d in cui si tiene conto della dimensione del file e della dimensione del record
per misurare la velocità in kb/s ma come si vede la dimensione del record non influisce
46
CAPITOLO 4. PROTOTIPO E TEST
Figura 4.19: Operazione di write
Figura 4.20: Operazione di read
sui risultati quindi teniamo conto solo della dimensione del file.
Nelle figure 4.23 e 4.24 si vede il confronto tra iSCSI e Aoe per le operazioni di
write e read, come si può notare la curva che rappresenta il protocollo iSCSI supera
quella di AoE ad un certo punto; questo punto corrisponde nel punto in cui l’effetto
4.3. TEST
47
Figura 4.21: Confronto 3d sull’operazione di write
Figura 4.22: Confronto 3d sull’operazione di read
della cache e della memoria centrale non ci sono più. Si osserva che il protocollo
iSCSI ha un rendimento circa 4096 kb/s più o meno uguale al 4/3 di quello di AoE
circa 3000 kb/s.
48
CAPITOLO 4. PROTOTIPO E TEST
Figura 4.23: Confronto 2d sull’operazione di write
Figura 4.24: Confronto 2d sull’operazione di read
4.4. CONCLUSIONE
49
4.4 Conclusione
I test per i storage sono stati effettuati solo per i protocolli iSCSI e AoE, si è voluto
studiare, confrontare e capire i punti critici di questi protocolli. L’obiettivo di questi
esperimenti era quello di identificare la possibilità per convenienza di un impiego di
questi protocolli nel prototipo dell’alta dispnibilità basato sulla virtualizzazione del dipartimento di fisica. I test sono stati principalmente due tipi: alcuni test sulla scalabilità
dei protocolli e un test sul rendimento di questi protocolli con una singola macchina.
I primi test avevano l’obiettivo di studiare il comportamento dei protocolli con un
numero crescente delle macchine virtuali, i test hanno evidenziato una differenza tra i
due protocolli: il protocollo iSCSI ha un comportamento più omogeneo, col crescere
del numero delle macchine virtuali le macchine virtuali hanno dimostrato di avere più
o meno gli stessi prestazioni indipendentemente da quali macchina fisica sono presenti
e da l’ordine in cui sono stati lanciati i jobs. Invece per AoE sono stati scontrati un
comportamento che inizialmente è parso anomalo e inspiegabile, alcuni macchine precisamente 8 hanno impiegato per finire i jobs lanciati con un tempo più o meno uguale
a quello con iSCSI, invece per 12 macchine i tempi sono stati molto lunghi.
Si è scoperto dopo inversando l’ordine in cui sono stati lanciati i jobs cioè lanciando prima i jobs sulle macchine che prima avevano impiegato più tempo e dopo le altre
macchine, i risultati hanno dimostrato che le 8 macchine con i jobs lanciati per primi
hanno finiti per primi, questo fatto dimostra che l’ordine in cui sono stati lanciati influisce sui risultati ed imposta il numero 8, il numero massimo delle VM che possono
eseguire jobs contemporaneamente su un unico canale per AoE. Naturalmente questo
non significa che si possono usare solo 8 macchine virtuali per il protocollo AoE, ma
8 macchine è il numero massimo delle VM che possono interfacciarsi senza restare in
attesa sullo stesso canale col file server.
Per il secondo test che riguarda il rendimento i risultati hanno dimostrato che ci
sono leggeremente delle differenze, i due protocolli hanno più o meno lo stesso rendimento fino a a quando c’è un file di dimensione uguale o inferiore alla dimensione della
memoria disponibile; dopodiché il protocollo iSCSI ha un rendimento uguale quasi al
doppio di quello di AoE. Una cosa molto importante che è stato notato con i test con
job leggeri ma con più di una macchina virtuale è una differenza non trascurabile del
carico del file server con iSCSI e con AoE, col protocollo iSCSI si ha un maggiore
carico della CPU rispetto a AoE, con questo ultimo si ottiene un carico molto basso
non superiore a 2 punti, ricordando che un punto equivale ad un impiego totale della
CPU nel ciclo delle macchina questo significa che un impiego del file server con altre
applicazioni per altri motivi nello stesso tempo che sono collegati le VM è possibile ed
sfruttabile in quanto l’overhead è molto minore rispetto con iSCSI.
50
CAPITOLO 4. PROTOTIPO E TEST
Appendice A
Installazione e Utilizzazione di
Xen
A.1 Installazione e creazione delle VM
L’installazione procede in questi stadi:
1. installazione di xen
2. configurazione del Grub e riavvio sul nuovo kernel
A.1.1 installazione
Si possono installare in due modi:
A.1.1.1 Dai tarballs
In questo caso sono disponibili Kernel precompilati. L’installazione si fa col ausilio
di un script shell, che installa Xen e copia i Kernel predefiniti. Il vantaggio di questo
metodo è che l’installazione è molto veloce, ma come questi Kernel sono generici non
sono per forza adatti a tutte le distribuzione ( questo implica che il metodo non può
funzionare dappertutto).
Pre-built tarballs sono disponibili per il download dalla pagina XenSource downloads:
http://www.xensource.com/downloads/
Una volta scaricati i tarball, scompattare ed installare con:
• tar zxvf xen-3.0-install.tgz
51
52
APPENDICE A. INSTALLAZIONE E UTILIZZAZIONE DI XEN
• cd xen-3.0-install
• sh ./install.sh
A.1.1.2 Dai sorgenti
Questo metodo consiste la compilazione dei sorgenti, questa operazione prende molto tempo ma in compenso si ottiene migliore performance e sopratutto permette di
scegliere le opzione necessari nei kernel. Si può trovare questi sorgenti sull’indirizzo.
http://www.xensource.com/downloads/
È incluso un target “world” all’internet dei Makefile, questo target fa queste operazioni:
• compila Xen
• compila i tools di controllo, ed include xend
• scarica (se necessario) e scompatta il sorgente Linux 2.6 per l’uso di Xen
• compila il Linux Kernel da utilizzare come dominio 0.
Per l’installazione basta fare:
• make world
• make install
Un alternativa ai questi metodi sarebbe quella dell’installazione tramite package disponibile, ma questa soluzione è valida solo per pochi distribuzione tra cui Ubuntu e
Federa core.
Una volta fatto l’installato, bisogna configurare il boot loader od il programma che
carica i sistemi operativi installati sulla macchina
A.1.2 Configurazione del Grub
Al avvio della macchina Il boot loader legge il file grub.conf o menu.lst che si trova
nella cartella /boot/grub, e mostra in video i sistemi operativi indicati in questo file,
l’utente sceglie poi il sistema da caricare. In questo file bisogna aggiungere questa
voce:
title Xen 3.0 / XenLinux 2.6
kernel /boot/xen-3.0.gz dom0_mem=262144
module /boot/vmlinuz-2.6-xen0 root=/dev/sda4 ro console=tty0
A.2. CONFIGURAZIONE DELLE MACCHINE VIRTUALI E USO DI XM
53
Dove la lignea del kernel indica il percorso dove trovare Xen, la lignea del
module indica il percorso dei moduli per inizializzare il sistema.
Bisogna riavviare la macchina e caricare il sistema XenLinux
A.2 configurazione delle macchine virtuali e uso di xm
A.2.1 configurazione dei domini
Quando si vuole creare un nuovo dominio o una macchina virtuale bisogna editare
un file di configurazione nel quale si indica i vari parametri del dominio che si vuole
creare. Questo file ha una struttura di questo tipo.
kernel = "/boot/kernel-2.6.12.6-xen"
memory = 512 n
name = "xen-test"
disk = [’phys:/dev/sdb1,sda1,w’]
root = "/dev/sda1 ro"
vif = [’mac=00:00:00:00:02:07’]
dhcp = "dhcp"
kernel Il path al kernel per utilizzare.
memory La memoria RAM da utilizzatore.
name Il nome della macchina (se si usa il DHCP questo nome sarà cambiato in
quello a fornito dal DHCP).
disk Il block device in cui si trova il filesystem della macchina virtuale.
root Punto di montaggio per la partizione radice
vif si può indicare un address mac o un indirizzo IP
dhcp indica l’utilizzo di un dhcp
A.2.2 Utilizzo di Xen
A.2.2.1 Si lancia Xen
Il demone xend può essere avviato con il commando: xend start
A.2.2.2 Comandi Xen
Per eseguire comandi come la creazione, l’eliminazione, la migrazione, può essere
usato ci si serve del tools xm, la struttura di comandi è di questo tipo.
xm <comando>
I comandi sono molti ne elenchiamo i più importanti
54
APPENDICE A. INSTALLAZIONE E UTILIZZAZIONE DI XEN
xm list : lista le macchina virtuale esistenti nel sistema in questo formato
Name
macchinavirtuale1
macchinavirtuale2
macchinavirtuale3
ID
3
4
11
Mem(MiB)
512
512
256
VCPUs
1
1
2
State
-b—-b—-r—-
Times
234.2
256.4
4322.4
xm create <filediconfig>: fa partire una macchina con i dati inseriti nel file indicato.
xm console <id o nome>: permette di connettersi a la macchina identificata dal id
o dal nome indicato, il nome ed il id sono quelli dati dal commando xm list.
xm shutdown <dom id> spegne la macchina indicato dal dominio.
xm destroy <dom id> Distrugge la macchina virtuale col dominio indicato.
xm reboot <dom id> Riavvia la macchina col dominio indicato.
xm migrate <dom id> <host> Migra la macchina <dom id> all’host <host> (l’host
di destinazione deve eseguire xen).
xm migrate –live <dom id> <host> Migra la macchina indicato, senza interruzione,
all’host indicato.
A.3 Esempio di una creazione di una macchina virtuale
ubuntu
In questa sezione spiegammo come creare un dominio Ubuntu funzionante con Xen.
Per prima creiamo un sistema base, cioè immagini di dischi dove sara installato il
file system.
• dd if=/dev/zero of=/home/xen/Ubuntu/image bs=1M count=2000
un altra immagine per lo swap di 128 MB
• dd if=/dev/zero of=/home/xen/Ubuntu/swapimage bs=1M count=128
creazione del file system di tipo ext3 per il sistema operativo guest
• mkfs.ext3 /home/xen/Ubuntu/image
creazione del file system swap
• mkfs.ext3 /home/xen/Ubuntu/swapimage
A.3. ESEMPIO DI UNA CREAZIONE DI UNA MACCHINA VIRTUALE UBUNTU55
Adesso installiamo il sistema operativo:
In un primo momento montiamo l’immagine del disco che abbiamo creato per
installare il sistema operativo.
creiamo un punto di montaggio
• mkdir /mnt/ext
lo montiamo nel punto creato con l’opzione loop non essendo la nostra immagine un
disco fisico
• mount -o loop /home/xen/Ubuntu/image /mnt/ext
installiamo il sistema operativo con lo script debootstrap, che provvede a scaricare ed
installare un sistema Ubuntu minimale.
• debootstrap –arch i386 dapper /mnt/ext/ http://archive.ubuntulinux.org/ubuntu
Lo script ha scaricato l’insieme di pacchetti necessari al installazione di sistema Ubuntu
di base nel immagine creato, comunque qualche configurazione sono necessari prima
di lanciare il sistema appena installato:
Cambiamo la cartella root del sistema fisico per permettere le configurazione al
sistema virtuale:
• chroot /mnt/ext/
Editiamo il file /etc/fstab e definiamo le partizioni e i punti di montaggio utilizzati
dalla macchina virtuale
• vi /etc/fstab
ed lo mettiamo in questo modo
/dev/hda1 / ext3 defaults 0 0
/dev/hda2 none swap sw 0 0
proc /proc proc defaults 0 0 sys
/sys sysfs defaults 0 0
Se vogliamo assegnare un indirizzo alle interfacce editiamo il file:
• vi /etc/network/interfacce
APPENDICE A. INSTALLAZIONE E UTILIZZAZIONE DI XEN
56
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
abbiamo assegnato l’indirizzo 192.168.0.2 all’interffacia eth0 in questo esempio
Assegnamo un nome alla nostra macchina:
• echo macchinavirtuale > /etc/hostname
Possiamo fare altre configurazione come il DNS o altro ma ci limitiamo a questo
lasciando il resto per quando sarà necessario.
Smontiamo l’immagine:
• umount /mnt/ext
Adesso dobbiamo configurare la macchina virtuale e farla partire, perciò editiamo un
file:
• vi /home/xen/ubuntu.cfg
Inseriamo questi parametri: indica il kernel che sarà usato dalla macchina.
• kernel = "/boot/xen-linux-2.6.12xenu"
la memoria concessa
• memory = 200
#nome
• name = "ubuntu"
Xen gestirà le interfacce non definiamo niente
A.3. ESEMPIO DI UNA CREAZIONE DI UNA MACCHINA VIRTUALE UBUNTU57
• vif = [ ” ]
• #dhcp = "dhcp"
si indica le partizioni utilizzati dalla macchina virtuale
• disk=[’file:/home/xen/Ubuntu/image,hda1,w’,’file:/home/xen/Ubuntu/swapeimage,hda2,w’,
]
• root = "/dev/hda1 ro"
Facciamola partire:
• xm create ubuntu.cfg -c
È la macchina è avviata.
58
APPENDICE A. INSTALLAZIONE E UTILIZZAZIONE DI XEN
Appendice B
iSCSI, ATA over ethernet,
Iozone
In questo appendice descriviamo come si fanno l’installazione e la configurazione dei
software di esportazione e di importazione dei blocchi di dischi a traverso la rete, ATA
over ethernet e iSCSI.
B.1 ATA over ethernet
Come abbiamo detto nel capitolo quattro, questo standard ha una architettura clientserver, quindi bisogna implementare sia un Client detto anche initiator che un Server
detto Target.
B.1.1 Target
Il Target è un processo che permette di esportare i blocchi a traverso la rete, perchè una
macchina sia da Target bisogna scaricare un tools chiamato Vblade, il sorgente può
essere scaricato da questo indirizzo:
http://sourceforge.net/project/
Una volta scaricato eseguire le istruzioni successive:
• tar zxvf vblade-14.tar.gz
• cd vblade-14
• make
59
APPENDICE B. ISCSI, ATA OVER ETHERNET, IOZONE
60
• make install
Se non ci sono errori il tools è stato installato con successo, La strutturai del comando
è:
./Vblade <shelf> <slot> <ethn> <device>
dove:
• <device> indica il disco o l’immagine da esporre
• <ethn> indica l’interfaccia sul quale esporre i dischi
• <shelf> e <slot> sono 2 identificatori di canali, i canali permettono di esportare
più elementi in una unica interfaccia nello stesso tempo.
vediamo un esempio di esportazione di un indagine di disco.
1. creiamo un immagine di 100MB col comando: dd if=/dev/zero of=immagine
bs=1M count=100
2. lo formattiamo con: mkfs -t ext3 immagine
3. nella directory di Vblade diamo il commando: ./vblade 0 0 eth0 /path/immagine
(./vbladed , per eseguire il processo in background), il risultato è di questo tipo:
ioctl returned 0
10485760 bytes
pid 10621: e0.0, 20480 sectors
B.1.2 Initiator
Per implementare il Client o l’Initiator bisogna avere un Kernel con il supporto AOE(ATA
over Ethernet), per i Kernel di versione 2.6.12 o più recenti i moduli sono inclusi bisogna solo compilare ed installarli, per la compilazione del Kernel si può fare col comando make menuconfig nella directory del sorgente del Kernel. Invece per quelli
antecedenti della versione 2.6.12 si può scaricare i moduli da questo indirizzo:
http://linux.softpedia.com/get/System/Operating-Systems/Kernels/ATA-over-Ethernetdriver-8157.shtml
Poi eseguire questi istruzioni:
• tar zxvf aoe6.tar.gz
• cd aoe6
B.1. ATA OVER ETHERNET
61
• make
• make install
Quindi bisogna scaricare tools chiamato aoetools, questi tools permettono di visualizzare i device esportati, possono essere scaricati da questo indirizzo:
http://linux.softpedia.com/get/System/Networking/ATA-over-Ethernet-Tools-8123.shtm
Poi eseguire queste istruzioni:
• tar zxvf aoetools.tar.gz
• cd aoetools
• make
• make install
Una volta installato i moduli e tools, bisogna caricare i moduli co commando:
• modprobe aoe
Per vedere i blocchi mesi in rete si può dare il commando:
• aoe-stat;aoe-discover
Il risalutato dovrebbe essere di questo tipo:
en.n 5.9G
Infine per poter usare questi dispositivi basta montarli col commando:
• mount /dev/etherd/en.n /path
B.1.3 Alcuni problemi riscontrati
B.1.3.1 Installazione del Target e Initiator
Comunque i test che abbiamo effettuati con questo standard hanno evidenziato che
L’Iniziatore ed il Target non possono essere sulla stessa macchina, perché l’initiator
non riesce a scoprire i dispositivi esportati su un interfaccia che si trova sulla stessa
macchina che esso gira. Questo perché l’initiator esegue una richiesta broadacast su
tutte le interfacce della rete tranne quelle presenti sulla macchina sulla quale gira. La
soluzione è ovviamente quella di installare il target ed il initiator su due macchine
diverse.
APPENDICE B. ISCSI, ATA OVER ETHERNET, IOZONE
62
B.1.3.2 Creazione dei VM da imagini sportati col standard ATA
I test che abbiamo fatto creando macchine virtuali da imagini di dischi esportati in rete
col standard ATA hanno dimostrato che le macchine virtuali create da queste imagini
non partono. La soluzione sempre secondo i test è l’uso di imagini di tipo lvm(logical
volume manage), o lsvm....
B.2 iSCSI
Questo standard è basato anche esso su un architettura client-server, un target (server)
e un initiator(client).
B.2.1 Target
Per installare il target bisogna scaricare il supporto per il Kernel ed installarlo, si può
trovare questi moduli dal link successivo:
http://iscsitarget.sourceforge.net/
si compila e si installa con le istruzione successive:
• make KSRC=/usr/src/linux
• make KSRC=/usr/src/linux install
linux indica il sorgente del kernel col quale si vuole utilizzare.
Una volta installato bisogna configurare il file di configurazione /etc/ietd.conf di
cui il demone iscsi-target legge al suo avvio.
B.2.1.1 configurazione /etc/ietd.conf
questo file contiene i Target che devono essere eseguiti, ogni target indica le informazioni per un device di cui si vuole esportare, la struttura di un target è in questo
modo:
Target iqn.1997-01.it.infn:pg.na48fs3.xentest209 :indica la macchina sul quale si
trova il target
# Lun definition
Lun 0 Path=/data16/images/209.img,Type=fileio :indica l’immagine o il disco da
esportare
B.2. ISCSI
63
Alias xentest209 :indica l’alias del target
B.2.1.2 lancio del target
Si lancia il target col commando:
• /etc/init.d/iscsi-target start
B.2.2 Initiator
È necessario installare moduli iscsi e tools iscsi per fare funzionare l’initiator, i moduli
si possono trovare sull’indirizzio:
http://www.kernel.org/pub/linux/kernel/people/nab/iscsi-initiator-core/
Invece i tools si possono trovare sull’indirrizzio:
http://www.kernel.org/pub/linux/utils/storage/iscsi/
Per installare i tools basta scompattare il sorgente e fare: make install, invece per
i moduli:
• make initiator KERNEL_DIR=/usr/src/linux
• make install
dove linux indica il sorgente del Kernel che si vuole utilizzare. Quindi bisogna configurare l’initiator, ci sono molti file che si possono configurare ma ci sono principalmente
2 necessari per il funzionamento del servizio perciò ci occuperemo solo di questi.
B.2.2.1 Configurazione
I 2 principali file sono:
• /etc/sysconfig/initiator : in questo file ci si mette i target che si vuole fare richieste, la struttura dei voci è cosi:
CHANNEL="0 1 eth0 192.168.254.54 3260 AuthMethod=None;MaxRecvDataSegmentLength=8192
nopout_timeout=5 iqn.1997-01.it.infn:pg.na48fs3.xentest208"
Si indica il nome del target che si vuole fare richieste, l’interfaccia ed il canale dove
fare questa richiesta.
• /etc/initiatorname.iscsi : si inserisce il nome della macchina initiator col formato
iqn(iscsi qualified name), è in questo modo:
InitiatorName=iqn.1997-01.it.infn:pg.na48fs3
64
APPENDICE B. ISCSI, ATA OVER ETHERNET, IOZONE
B.2.2.2 lancia l’initiator
Per lanciarlo si esegue il commando:
• /etc/init.d/initiator start
Poi si esegue il commando:
• /etc/init.d/initiator status
Questo ultimo commando permette di fare vedere i dispositivi ISCSI disponibile in
rete. Per utilizzarli questi dispositivi non bisogna altro che montarli in una directory ed
è pronto.
Bibliografia
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
65