Studio di soluzioni di Storage per sistemi ad alta afﬁdabilità Università degli Studi di Perugia...

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 CorrelatoreProf. Leonello Servoli Álvaro López García

Anno Accademico 2006-2007

Indice

1 Introduzione 1

1.1 Obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Alta disponibiltà . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.2 Alta disponibiltà o Alta affidabilità . . . . . . . . . . . . . .. 2

1.2.3 Calcolo del rischio . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.4 Alta disponibiltà dei servizi . . . . . . . . . . . . . . . . . . 3

1.2.4.1 Considerazione da prendere . . . . . . . . . . . . . 4

1.2.4.2 Ridondanza fisica . . . . . . . . . . . . . . . . . . 5

1.2.4.3 Backup dei dati . . . . . . . . . . . . . . . . . . . 5

1.2.4.4 Virtualizzazione . . . . . . . . . . . . . . . . . . . 5

1.3 Organizzazione tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Virtualizzazione 9

2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Un po di storia . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Vantaggi e applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Tecniche di virtualizzazione . . . . . . . . . . . . . . . . . . . . . .11

2.3.1 Virtualizzazione applicativo . . . . . . . . . . . . . . . . . . 11

2.3.2 Parallell virtual macchine . . . . . . . . . . . . . . . . . . . 12

2.3.3 Re-implementazione delle librerie . . . . . . . . . . . . . . .12

2.3.4 Emulazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.4.1 Svantaggi . . . . . . . . . . . . . . . . . . . . . . 13

2.3.4.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.5 Virtualizzazione per traduzione binaria . . . . . . . . . .. . 13

2.3.5.1 Svantaggi . . . . . . . . . . . . . . . . . . . . . . 14

2.3.5.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . 14

I

II INDICE

2.3.6 Paravirtualizzazione . . . . . . . . . . . . . . . . . . . . . . 14

2.3.6.1 Svantaggi . . . . . . . . . . . . . . . . . . . . . . 14

2.3.6.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Teorie di Popek e Goldberg . . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 Una sfida per la virtualizzazione: x86 . . . . . . . . . . . . . 15

2.4.1.1 Il problema del x86 . . . . . . . . . . . . . . . . . 15

2.4.1.2 Livelli di privilegi di ISA . . . . . . . . . . . . . . 16

2.4.1.3 Struttura di controllo di un sistema virtuale . . . . .16

2.4.2 Altri ostacoli . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Soluzioni esistenti per il problema dell’x86 . . . . . . . . .. . . . . 18

2.5.1 La virtualizzazione della CPU :Intel VT-x e AMD-V . . . .. 18

2.5.2 Riferimento per provare la virtualizzazione . . . . . . .. . . 19

2.6 Prospettive future . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6.1 Virtualizzazione memoria . . . . . . . . . . . . . . . . . . . 20

2.6.1.1 Senza virtualizzazione: . . . . . . . . . . . . . . . 20

2.6.1.2 Con virtualizzazione . . . . . . . . . . . . . . . . . 20

2.6.1.3 Soluzione esistente . . . . . . . . . . . . . . . . . 21

2.6.2 Virtualizzazione delle periferiche . . . . . . . . . . . . . .. 21

2.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Xen 23

3.1 Xen e paravirtualizazzione . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Sistemi operativi supportati . . . . . . . . . . . . . . . . . . . . . .. 24

3.3 Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Confronto con altre soluzioni di virtualizzazione . . . .. . . . . . . . 26

3.4.1 Sul funzionamento . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.2 Sulla performance . . . . . . . . . . . . . . . . . . . . . . . 27

3.5 Demoni Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.1 Xend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.2 Xenstored . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Conclusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Prototipo e Test 29

4.1 Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Schema funzionale . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Composizione . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.3 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.3.1 Virtualizzazione delle macchine critiche . . . . . . 30

4.1.3.2 Nodo di monitoraggio . . . . . . . . . . . . . . . . 31

INDICE III

4.2 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

4.2.4 Block device remoti via software . . . . . . . . . . . . . . . . 33

4.2.4.1 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.4.2 ATA over ETHERNET (AoE) . . . . . . . . . . . . 34

4.3 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 Bonnie . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.3 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

4.3.4 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

4.4 Conclusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

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 INDICE

B iSCSI, ATA over ethernet, Iozone 59

B.1 ATA over ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.1.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.1.2 Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.1.3 Alcuni problemi riscontrati . . . . . . . . . . . . . . . . . . . 61

B.1.3.1 Installazione del Target e Initiator . . . . . . . . . . 61

B.1.3.2 Creazione dei VM da imagini sportati col standard

ATA . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.2 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.2.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.2.1.1 configurazione /etc/ietd.conf . . . . . . . . . . . . 62

B.2.1.2 lancio del target . . . . . . . . . . . . . . . . . . . 63

B.2.2 Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B.2.2.1 Configurazione . . . . . . . . . . . . . . . . . . . 63

B.2.2.2 lancia l’initiator . . . . . . . . . . . . . . . . . . . 64

Elenco delle figure

1.1 Schema di ridondanza tramite clonazione dell’hardware. . . . . . . 5

1.2 prototipo della soluzione della virtualizzazione . . . .. . . . . . . . 6

1.3 Schema di un esempio della soluzione colla virtualizzazione . . . . . 8

2.1 Schermata di una macchina Ubuntu su PC Windows . . . . . . . . .. 10

2.2 Una macchina virtuale Mac su linux . . . . . . . . . . . . . . . . . . 13

2.3 Livelli di privilegi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Struttura di controllo di un sistema virtuale . . . . . . . . .. . . . . 17

2.5 VMCS di Intel e AMD . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Indirizzamento senza virtualizzazione . . . . . . . . . . . . .. . . . 20

2.7 Indirizzamento con virtualizzazione . . . . . . . . . . . . . . .. . . 21

2.8 Schema del EPT e SPT . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Logo di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Imagine di una schermata con aperti varie macchine virtuali con Xen . 25

3.3 Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Confronto performance Xen e altre soluzioni di virtualizzazione . . . 27

4.1 Struttura del prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 schermata di nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Struttura del sistema dei test . . . . . . . . . . . . . . . . . . . . . .35

4.4 troughput per le operazione di read e write . . . . . . . . . . . .. . . 37

4.5 velocità media delle VM per le operazione di read e write .. . . . . . 38

4.6 distribuzione delle VM per read . . . . . . . . . . . . . . . . . . . . 38

4.7 distribuzione delle VM per write . . . . . . . . . . . . . . . . . . . . 39

4.8 Carico del file server . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.9 Troughput delle operazione di read e write . . . . . . . . . . . .. . . 40

4.10 Velocità media di read e write con aoe . . . . . . . . . . . . . . . .. 40

V

VI ELENCO DELLE FIGURE

4.11 distribuzione delle VM per read . . . . . . . . . . . . . . . . . . . .41

4.12 distribuzione delle VM per write . . . . . . . . . . . . . . . . . . .. 41

4.13 Carico del file server . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.14 Confronto sull’operazione di read . . . . . . . . . . . . . . . . .. . 43

4.15 Confronto sull’operazione di write . . . . . . . . . . . . . . . .. . . 43

4.16 Confronto sul carico del file server . . . . . . . . . . . . . . . . .. . 44

4.17 Operazione di write . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.18 Operazione di read . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.19 Operazione di write . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.20 Operazione di read . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.21 Confronto 3d sull’operazione di write . . . . . . . . . . . . . .. . . 47

4.22 Confronto 3d sull’operazione di read . . . . . . . . . . . . . . .. . . 47

4.23 Confronto 2d sull’operazione di write . . . . . . . . . . . . . .. . . 48

4.24 Confronto 2d sull’operazione di read . . . . . . . . . . . . . . .. . . 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 dipiù; la stessa cosa vale

per i grandi network o per i sistemi computazionali dedicatialla 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 percentualecomposta 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à.

1Infrastruttura distribuita per consentire l’utilizzo di risorse di calcolo e di storage provenienti da unnumero elevato di calcolatori interconnessi da una rete

1

2 CAPITOLO 1. INTRODUZIONE

tasso di disponibiltà durata di indisponibiltà97% 11 giorni98% 7 giorni99% 3 giorni e 15 ore

99,9% 8 ore e 48 minuti99,99% 53 minuti99,999% 5 minuti99,9999% 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 pianifi-

cate 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 difermata 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 didown-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 didown-time, oltre ai failure non pianificati, sono da consi-

derare anche i down-time prodotti da aggiornamenti ciclicidei 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 deglieffetti prodotti da ogni singolo

evento d’outage devono essere sommati tra loro per ottenereil valore di effetto totale.

Dal punto di vista matematico l’effetto prodotto non è altroche 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’a-

nalisi storica dei down-time (ecco dunque l’importanza di avere policy per l’auditing

dei disservizi). Per ciò che riguarda la durata è necessarioconsiderare il tempo me-

dio di interruzione prodotto dall’outage. In questa valutazione bisogna prevedere non

solamente il tempo di disservizio ma anche i tempi necessarial ripristino dei dati e al

ripristino delle attività da parte degli utenti. L’unita dimisura 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 disservi-

zio.Per esempio un down-time pianificato può impattare soloil 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’in-

terfaccia di cui possono usufruire i clienti. Dei esempi molto semplici sono il servizio


web, ed il servizio di posta elettronica. In questa i serviziche si vogliono rendere al-

tamente 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 eccoalcune 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 edi inondazione.

Oltre a questo bisogna anche avere un piano di controllo per rilevare o prevenire gua-

sti, come test di vita TCP HEALTCHECK , programmi di test invocati periodicamente

(heartbeat) ,interfacce di tipo < <diagnostic> > sui componenti; questo piano deve ri-

guardare ogni livello di architettura, ogni componente , ogni legame di comunicazione

tra i componenti,ecc.... .

Queste sono alcune delle considerazioni da fare per evitareun guasto ma è quasi

impossibile eliminare il rischio al 100% . Perchè ci sono deiproblemi 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; sonopresentate 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 ser-

vizi richiesti, creando una copia esatta della macchina . Iltempo di down-time è ab-

bastanza piccolo in quanto è uguale solo al tempo necessarioall’ avvio della macchina

copia. Ma questa tecnica comporta un consumo di risorse economiche, un numero ele-

vato di indirizzi IP, è necessario la presenza 24h/7 di un personale pronto a spostare i

servizi ed avviare le macchine ” clone ”. Un esempio di questasoluzione è 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 necessa-

rio 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 que-

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


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

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

3tratteremo più in profondità questo argomento nel capitolo2

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

ne.

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.


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

cessori MAC ai processori INTEL. In più aziende del calibro d’Intel , AMD si sono lan-

ciate 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 per-

chè, 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 macchi-

na 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

10 CAPITOLO 2. VIRTUALIZZAZIONE

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 funzionasenza 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 virtualizza-

zione

• Hypervisore o VMM (VIRTUAL MACCHINE MONITOR):La componente di

sistema che realizza la virtualizzazione. Esistono numerosi nel mercato (Vm-

ware, Virtual PC, Parallels Workstation, Xen, Qemu...). L’hypervisore può es-

sere 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 stessamacchina 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 ulti-

ma generazione delle applicazioni vecchie. Per esempio perusare dei software o giochi

sviluppati per un sistema ”vecchio” ed incompatibile con ilhardware di una macchi-

na recente, il sistema ”vecchio” può essere virtualizzato.Questa situazione è molto

frequente anche in grandi aziende , che non possono cambiarei software ad ogni rin-

novamento di materiale. Un altro vantaggio dell’ uso delle macchine virtuali è una

stabilita ed una sicurezza importante : infatti un guasto diuna 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 inun file1. È quindi molto

facile realizzare un backup del suo sistema ad un istante preciso, nel caso di un pro-

blema 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’utiliz-

zazione 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. Ve-

diamo 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 ese-

guito o interpretato dalla JVM su una piattaforma diversa daquella con la quale

è stato generato, questo operazione è possibile grazie allaportabilità di JVM.

1vedere l’appendice B, creazione macchina virtuale


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

gola applicazione in quanto questa viene distribuita tra levarie 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 ladistribuzione 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 sipuò 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 nonpuò 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. È possibileemulare completamen-

te un ambiente sia hardware che software oppure soltanto unodei due. È più facile

tecnicamente fare un emulazione di tipo software poiché puòbastare un semplice tra-

duttore che traduce al sistema che ospita le istruzioni. Nelcaso 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 unacomputazione molto complessa

3Multi 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 tra-

durli affinché possano essere eseguiti dalla macchina fisicao reale.Questa descrizione

è sufficiente a fare capire il principale problema della virtualizzazione : la perdita del-

l’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 to-

talità 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 diLinux, 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.


Vedremo nel paragrafo seguente come l’hyervisore effettuaquesta 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 questatecnica.

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

virtualizzazione prendono il problema al contrario : modificano direttamente i siste-

mi 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 è dipochi 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 Architectu-

res” uscito in 1974, Gerald J. Popek e Robert P. Goldberg[1] hanno introdotto le con-

dizioni 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 (Istruc-

tion Set Architecture) della macchina originale deve avereper poter essere virtualizza-

to. 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 de-

finisce 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 modifi-

care la configurazione delle risorse in possesso del processore, e sono dette critiche. Per

proteggere la stabilita della macchina, queste istruzioninon possono essere eseguite da

tutti i programmi.


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ù cri-

tiche 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 è infat-

ti 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 pri-

vilegiato 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 ”perico-

lose” e non privilegiati. Queste ultimi non generano erroriautomatiche, 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 softwarehypervisor.

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

dere 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 tentatividi accesso del OS invitato ai

indirizzi di memoria non disponibile e ridirigerlo ad altriindirizzi 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 me-

moria e delle interruzioni, le periferie devono essere gestite dal VMM che deve poi

emularle per ogni OS invitato. Una fonte in più per il ritardoe soprattutto una perdita

enorme di funzionalità.


2.5 Soluzioni esistenti per il problema dell’x86

Per semplificare tutto questo, Intel ha concepito VT e AMD V. Queste due tecnolo-

gie sono molto simili, al punto che non faremo differenza traloro nella descrizione

seguente. Intel VT e AMD V si compongono entrambi di tre particiascuno destina-

to 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 figura2.5. Tra le nuove istruzioni,

una di loro (VM entry) permette di commutare il processore inuna nuova modalità di

esecuzione, dedicato ai sistemi guest. Questa modalità possiede anche quattro livelli

di privilegi diversi. Cosi sono eliminati i problemi legatiall’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 pas-

saggio è deciso dalle condizioni fissate dal VMM grazie ai bitdi controllo memorizzati

nella VMCS.

Figura 2.5: VMCS di Intel e AMD

Al momento del passaggio, lo stato del processore nella modalità guest è memoriz-

zato nella VMCS e lo stato del processore nella modalità hostè ricaricata dalla VMCS.

Le istruzioni necessarie sono quindi eseguite, poi il VMM fauscire 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 daVmware 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 In-

put/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.

Core Duo, Core solo, Core 2Duo, Core 2 extremePentium EE, Pentium D

INTEL Xeon, XeonMpItanium 2

tutti i CPU in socket AM2 tranne le sempronAMD Opteron Socket F

Turion S1

Tabella 2.1: Processori AMD e Intel che implementano il supporto alla virtualizzazione


2.6 Prospettive future

2.6.1 Virtualizzazione memoria

Un sistema operativo quando è l’unico a girare su una macchina, si occupa dell’indi-

rizzamento totale della memoria centrale. In altri termini, decide di allocare una certa

quantità per ogni applicazione, quantità che sarà compresatra 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 memoriacentrale disponibile, la me-

moria virtuale può essere rappresentata sul disco fisico. Lacorrispondenza tra questa

memoria lineare e la memoria fisica è realizzata da una unita di CPU, la MMU (Memo-

ry Management Unit). La MMU mantiene aggiornato lapage 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 suoindirizzamento 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 eli 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 è chiamataShadow 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 del-

la 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 inventatoExtended Page Tables

(EPT) eNested 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 didedicare una parte degli

indirizzi fisici della memoria ad ogni OS. Questi possono quindi accedere direttamente

ai loro dominio di indirizzo, senza provocare l’interventodel 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 effet-

ti, 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 alVMM 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 fun-

zionalità delle VM moltiplicati: riconoscimento di un grannumero di apparecchiature

come fotocamera, stampa, chiavi USB,ecc.. .


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 integratonei 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 solu-

zioni che esistono in questa categoria, Xen possiede una particolarità, è una soluzione

23

24 CAPITOLO 3. XEN

molto efficiente in termini di performance. Questa particolarità è dovuta al fatto che

Xen è basata non sulla virtualizzazione ma sulla paravirtualizazzione, cioè Xen non mi-

ra 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 diapproccio accresce l’efficien-

za.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 al-

cune 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 è differenzia-

ta 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 program-

mi 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 creatadirettamente dall’hypervisor

al momento del boot. Da esso possono essere fatte partire successivamente le altre mac-

chine virtuali. Tutte le altre istanze di macchina virtualein 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 25

Sistema operativo Dom0 (host OS) DomU (guest OS)Linux 2.6 Si Si

NetBSD 3.1 No SiNetBSD 4.0_BETA2 Si Si

sistema operativo non-modificato No 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 sistemaoperativo 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 dellostrato 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.

26 CAPITOLO 3. XEN

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

tualPC sono delle macchine virtuali complete per i sistemi operativi guest, è in-

clusa 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 permettedelle macchine

virtuali complete per i sistemi operativi guest; includonoanche 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 iso-

lare certi aspetti o risorse del sistema operativo Host comeil 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 ma-

niera isolata dalle altre UML che girano sulla macchina. Soluzione, molto poco

efficiente, poichè due KERNEL sonocaricati; è usata sopratutto nello sviluppo

del kernel.

3.4.2 Sulla performance

In figura 3.4 è ben visibile che il decadimento di performancedi 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 altribenchmarks

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)

28 CAPITOLO 3. XEN

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 questodemone 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 si-

glati con Microsoft dimostrano che anche i grandi “ calibri “sono interessati da questa

realtà. Per l’utilizzazione, Xen è realmente piacevole ad utilizzare, con delle perfor-

mance eccezionali. Il grosso problema, per adesso è la sua complessità rispetto alle

altre soluzioni che hanno tutte un interfaccia grafica completa. Virt-manager è un in-

terfaccia 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 unamacchina fisica esistente.

Ma la versione, non gratuita di Xen, XenEnterprise, permette di superare queste lacu-

ne, offrendo un interfaccia molto più completa e uno strumento di migrazione P2V, che

funziona solo con i Kernel “Xenzzati”.

1software 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 diefficienza.

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 lemacchine 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; que-

sti ultimi vengono caricati attraverso la rete dallo storage alle macchine fisiche, ci

sono varie soluzioni disponibile, effettueremo varie testper trovare la soluzione

migliore.

29

30 CAPITOLO 4. PROTOTIPO E TEST

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

do passo consiste nel monitoraggio della situazione in modocontinuo 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 vir-

tualizzati di conseguenza anche i dati o servizi presenti suqueste. 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 instal-

lato 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 diusare 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 ri-

sorse di rete. La sua funzione base è quella di controllare nodi, reti e servizi specificati,

avvertendo quando questi non garantiscono il loro servizioo 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, inquesto caso come si è

detto precedentemente della memorizzazione dei file systemdelle macchine virtuali.


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 tecnologiedisponibili 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 bisognainstallare un server ed

un client, ed altri no.

4.2.3 Block device remoti via hardware

Questa soluzione consiste nell’esportazione block deviceche sono collegati a dispositi-

vi 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 permettedi 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. Esisteun 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’installa-

zione via hardware ci sono appositi scatole con interfacciaethernet che implementa il

protocollo iSCSI, in questa scatola si inseriscono i dischied 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. Es-

sendo 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 chiamatotarget 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 concepitoper i supercomputer ma è

diventato standard dei SAN (storage area network), permette di avere buone prestazio-

ni in termini di efficienza. Per implementarlo basta collegare il dispositivo coll’inter-

faccia fibre chanel ai computer anche essi con interfaccia FC.

4.2.4 Block device remoti via software

Questa soluzione consiste nell’esportazione di blocchi dipartizioni nella rete a traverso

software specifici, questo permette di avere buone prestazioni senza avere la necessita

di possedere hardware. Vedremo 2 soluzioni che sonoiSCSI e ATA over Ethernet

4.2.4.1 iSCSI

Come si è spiegato in precedenza, il protocollo è basato su unarchitettura client-server,

quindi per fare un implementazione bisogna installare il server ossia untarget sul fi-

le server ed un client chiamatoinitiator sulle macchine fisiche. Il funzionamento di

questo protocollo è semplice: Iltarget 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.


4.2.4.2 ATA over ETHERNET (AoE)

AoE è anche esso un protocollo basato su un’ architettura client-server, untarget (ser-

ver) che esporta risorse con apposititools, ed uninitiator (client) che li importa sempre

con tools specifici. Per implementarlo bisogna installare iltarget sul file server ed l’

initiator sulle macchine fisiche. Il tool usato per l’esportazione si chiamaVblade, il

funzionamento è analogo a quello di iSCSI, iltarget in questo casoVblade esporta

partizioni dal lato server e l’initiator fa una scoperta di questi partizioni.

L’installazione e la modalità di uso diVblade è 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 Dual Pentium III 1GHzMemoria 256MB

Disco 210GB - RAID 5Connessione Rete Gigabit EthernetSistema Operativo Slackware Linux 10.2 - Kernel 2.6.15.6

Tabella 4.2: Caratteristiche file server

Processore Intel Xeon a 3.12 GhzMemoria 1GB

Disco 40GBConnessione Rete Gigabit EthernetSistema Operativo 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 sul-

le 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 sca-

libilità per i due protocolliiSCSI e AoE. Le macchine virtuali create in questi test


sono stai installato su partizioni LVM1questa scelta è stata obbligatoria in quanto non è

possibile fare partire macchine virtuali con Xen con partizioni “normali” questo ovvia-

mente influisce sul rendimento ma è stato applicato la stessacosa 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 naturaleciclo di calcolo della

durata di un secondo. Per dirla in altro modo, nell’arco di unsecondo 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 coniSCSI cheAoE per le operazio-

ne di read e write.iltroughput con n numero di macchine virtuali è uguale:∑n

i=1Vi

dove Vi è la velocità delle operazione con la macchina virtuale i. Lamedia delle

velocità per n numero virtuali è data da Vn=∑n

i=1Vi/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 trou-

ghput è quello effettivo si dovrebbe avere Tn => Tm quindi Vn*N => Vm*M

questo implica : 1 =>N

M=> Vm

Vn

cioè il rapporto fra il numero delle VM n con

il numero delle VM m deve essere maggiore o uguale al rapportofra 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.

1Il gestore logico dei volumi (anche noto come logical volumemanager o LVM) è un software di gestionedei 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 iltroughput 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 iltroughput varia molto ed è irregolare. Questo fatto è

probabilmente dovuto al fatto che il valore deltroughput 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


Figura 4.5: velocità media delle VM per le operazione di reade 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 tra6 e 7, questa distribu-

zione è più o meno omogenea. Per la scrittura figura 4.7 invecec’è 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 impiegocrescente 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 cresce-

re 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 presta-

zioni col crescere del numero delle VM; questa perdita di efficienza è più grande per

l’operazione di read.


Figura 4.9: Troughput delle operazione di read e write

Nella figura 4.10 si vede la velocittà media delle VM per read ewrite, 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 35ore e ricordando che

si trattava di un file di dimensione 300MB questo tempo è moltogrande, 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 contempi 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 cresceredelle VM, si nota

che non c’è grande cambiamento tra il carico per una macchinaed il carico per 20

macchine, infatti si passa da 1 a 2. Questo fatto è dovuto principalmente al fatto il


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 eper

AoE ma col crescere del numero delle VM iltroughput di AoE diminuisce in maniera

monotona invece per iSCSI iltroughput 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 glistessi comportamen-

ti dell’operazione di read, c’è una grande differenza ditroughput 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ù VMrispetto a AoE.

Figura 4.15: Confronto sull’operazione di write

Nella figura 4.16 si nota che esiste una grande differenza delcarico 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. Perentrambi i protocolli

la variazione è poca anche se c’è una grande differenza tra diloro. Questo fatto può


essere spiegato come detto precedentemente il fatto che i pacchetti del protocollo AoE

passano pochi livelli essendo AoE basato solo su MAC addressrispetto 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 menoper 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 divelocità 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 dimensionedel record non influisce


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 perle 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 nelpunto 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/3di quello di AoE

circa 3000 kb/s.


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

partimento di fisica. I test sono stati principalmente due tipi: alcuni test sulla scalabilità

dei protocolli e un test sul rendimento di questi protocollicon 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 AoEsono stati scontrati un

comportamento che inizialmente è parso anomalo e inspiegabile, alcuni macchine pre-

cisamente 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è lancian-

do prima i jobs sulle macchine che prima avevano impiegato più tempo e dopo le altre

macchine, i risultati hanno dimostrato che le 8 macchine coni jobs lanciati per primi

hanno finiti per primi, questo fatto dimostra che l’ordine incui sono stati lanciati in-

fluisce 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 hannopiù o meno lo stesso rendi-

mento 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 è statonotato 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 ottieneun 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.

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

loads:

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

to 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 opera-

zioni:

• 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 di-

sponibile, 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.confo 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, lamigrazione, 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


xm list : lista le macchina virtuale esistenti nel sistema inquesto formato

Name ID Mem(MiB) VCPUs State Times

macchinavirtuale1 3 512 1 -b—- 234.2

macchinavirtuale2 4 512 1 -b—- 256.4

macchinavirtuale3 11 256 2 -r—- 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 macchinaidentificata 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 utilizzatidalla 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


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

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 hauna architettura client-

server, 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

60 APPENDICE B. ISCSI, ATA OVER ETHERNET, IOZONE

• 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/zeroof=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ù recentii moduli sono inclusi bi-

sogna solo compilare ed installarli, per la compilazione del Kernel si può fare col co-

mando make menuconfig nella directory del sorgente del Kernel. Invece per quelli

antecedenti della versione 2.6.12 si può scaricare i modulida questo indirizzo:

http://linux.softpedia.com/get/System/Operating-Systems/Kernels/ATA-over-Ethernet-

driver-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 visualiz-

zare i device esportati, possono essere scaricati da questoindirizzo:

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 colcommando:

• 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 sullamacchina sulla quale gira. La

soluzione è ovviamente quella di installare il target ed il initiator su due macchine

diverse.


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

mazioni per un device di cui si vuole esportare, la strutturadi 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 daesportare

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 peri moduli:

• make initiator KERNEL_DIR=/usr/src/linux

• make install

dove linux indica il sorgente del Kernel che si vuole utilizzare. Quindi bisogna configu-

rare 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 targetche si vuole fare richie-

ste, la struttura dei voci è cosi:

CHANNEL="0 1 eth0 192.168.254.543260 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


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 altroche montarli in una directory ed

è pronto.

Bibliografia

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

65

Studio di soluzioni di Storage per sistemi ad alta afﬁdabilità Università degli Studi di Perugia...

Documents

Transcript of Studio di soluzioni di Storage per sistemi ad alta afﬁdabilità Università degli Studi di Perugia...