Disegno ed implementazione di una soluzione con macchine virtuali

Transcript

Università degli Studi di Perugia
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
Tesi di Laurea
Disegno ed implementazione di una
soluzione con macchine virtuali (XEN)
per garantire servizi
Candidato
Ivan Grasso
Relatore
Prof. Leonello Servoli
Correlatore
Mirko Mariotti
Anno Accademico 2005-2006
Indice
1 Alta Disponibilità e Virtualizzazione
1.1 Cos’è l’Alta disponibilità . . . . . . . . . . . . . .
1.1.1 Alta disponibilità tramite backups . . . . .
1.1.2 Alta disponibilità tramite ridondanza fisica
1.1.3 Alta disponibilità tramite virtualizzazione .
1.2 Cos’è la virtualizzazione . . . . . . . . . . . . . .
1.3 Teoria di Popek e Goldberg . . . . . . . . . . . . .
1.3.1 Insiemi di istruzioni . . . . . . . . . . . .
1.3.2 Teoremi . . . . . . . . . . . . . . . . . . .
1.3.3 Effetti della teoria di Popek e Goldberg . .
1.4 Tipi di virtualizzazione . . . . . . . . . . . . . . .
1.4.1 Emulazione . . . . . . . . . . . . . . . . .
1.4.2 Virtualizzazione . . . . . . . . . . . . . .
1.4.3 Virtualizzazione a livello di SO . . . . . .
1.4.4 Paravirtualizzazione . . . . . . . . . . . .
1.5 Xen . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Cos’è Xen . . . . . . . . . . . . . . . . . .
1.5.2 Paravirtualizzazione in Xen . . . . . . . .
1.5.3 Architettura di Xen . . . . . . . . . . . . .
1.5.4 I daemon di Xen . . . . . . . . . . . . . .
1.5.5 Caratteristiche di Xen . . . . . . . . . . .
1.6 Vantaggi della virtualizzazione . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Il prototipo: analisi delle possibilità e test dei componenti
2.1 Prototipo di architettura . . . . . . . . . . . . . . . . .
2.2 Soluzioni distinte per lo storage . . . . . . . . . . . .
2.2.1 Block device remoti via hardware . . . . . . .
2.2.2 Block device remoti via software . . . . . . . .
2.2.3 Filesystem distribuiti . . . . . . . . . . . . . .
2.3 Test delle componenti . . . . . . . . . . . . . . . . . .
2.3.1 Test di compatibilità . . . . . . . . . . . . . .
I
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
3
4
4
5
5
5
6
6
6
6
7
7
7
7
8
9
10
11
11
.
.
.
.
.
.
.
13
13
14
15
15
17
18
18
II
INDICE
2.3.2
Test di I/O . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Il prototipo: il sistema di Healthcheck e l’implementazione
3.1 Sistema di Healthcheck . . . . . . . . . . . . . . . . . .
3.2 Analisi delle problematiche . . . . . . . . . . . . . . . .
3.3 Analisi dei software . . . . . . . . . . . . . . . . . . . .
3.3.1 XenEnterprise . . . . . . . . . . . . . . . . . .
3.3.2 OpenQRM . . . . . . . . . . . . . . . . . . . .
3.3.3 Enomalism . . . . . . . . . . . . . . . . . . . .
3.3.4 Virtual Iron . . . . . . . . . . . . . . . . . . . .
3.3.5 Nagios e Cfengine . . . . . . . . . . . . . . . .
3.4 Il prototipo . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Schema Logico . . . . . . . . . . . . . . . . . .
3.4.2 Implementazione Fisica . . . . . . . . . . . . .
4 Prospettive future
4.1 Virtualizzazione Hardware x86
4.1.1 Architettura . . . . . .
4.1.2 Memoria . . . . . . .
4.1.3 Input/Output . . . . .
4.1.4 Sicurezza . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Installazione e uso di Xen
A.1 Installazione di Xen . . . . . . . . . . . . . . . .
A.2 Configurazione di Xen . . . . . . . . . . . . . .
A.2.1 Configurazione di xend . . . . . . . . . .
A.2.2 Configurazione dei macchine virtuali . .
A.2.3 pyGRUB . . . . . . . . . . . . . . . . .
A.3 Uso di Xen . . . . . . . . . . . . . . . . . . . .
A.3.1 Lanciare Xen . . . . . . . . . . . . . . .
A.3.2 Il tool xm . . . . . . . . . . . . . . . . .
A.4 Creazione di una VM SL4 . . . . . . . . . . . .
A.4.1 Installazione di SL4 . . . . . . . . . . .
A.4.2 Compilazione del kernel 2.6.16-xen . . .
A.4.3 Creazione e prova delle macchine virtuali
B Uso di block device via rete
B.1 iSCSI . . . . . . . . . . . . . . .
B.1.1 Introduzione . . . . . . .
B.1.2 Installazione di un target .
B.1.3 Installazione di un initiator
B.2 GNBD . . . . . . . . . . . . . . .
B.2.1 Introduzione . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
.
.
.
.
.
.
.
.
.
.
.
33
33
33
34
34
35
36
36
37
39
39
40
.
.
.
.
.
43
43
43
43
44
44
.
.
.
.
.
.
.
.
.
.
.
.
47
47
47
47
48
48
49
49
49
50
50
50
51
.
.
.
.
.
.
53
53
53
53
54
55
55
INDICE
III
B.2.2
B.2.3
Installazione di GNBD . . . . . . . . . . . . . . . . . . . . .
Esportazione e Importazione . . . . . . . . . . . . . . . . . .
C Installazione e uso di Nagios e Cfengine
C.1 Nagios . . . . . . . . . . . . . . . . . . . .
C.1.1 Installazione di Nagios e plugin . .
C.1.2 Configurazione dell’interfaccia web
C.1.3 Configurazione di Nagios . . . . .
C.2 Cfengine . . . . . . . . . . . . . . . . . . .
C.2.1 Installazione di Cfengine . . . . . .
C.2.2 Configurazione di Cfengine . . . .
C.3 Integrazione fra Nagios e Cfengine . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
56
57
57
57
58
59
61
61
61
62
IV
INDICE
Elenco delle figure
1.1
1.2
1.3
1.4
Confronto del rendimento tra vari metodi di virtualizzazione . . . . .
Livelli di privilegi di un sistema operativo senza (sinistra) e con Xen
(destra) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ripristino di due servizi virtualizzati . . . . . . . . . . . . . . . . . .
9
10
12
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
Prototipo di architettura di un sistema ad alta disponibilità tramite Xen.
Le topologie FC. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architettura di iSCSI. . . . . . . . . . . . . . . . . . . . . . . . . .
Schema di filesystem distribuiti. . . . . . . . . . . . . . . . . . . . .
Esempio di risultato di un test con IOzone. . . . . . . . . . . . . . .
Test di lettura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . .
Test di scrittura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . .
Confronto 2D risultati scrittura a 32 bit. . . . . . . . . . . . . . . . .
Confronto 2D risultati lettura a 32 bit. . . . . . . . . . . . . . . . . .
14
15
16
17
20
21
21
22
22
23
23
24
24
25
25
26
26
27
28
28
29
29
30
30
31
V
8
VI
ELENCO DELLE FIGURE
3.1
3.2
3.3
3.4
3.5
Schermata XenEnterprise
Schermata OpenQRM . .
Schermata Enomalism .
Schermata Virtual Iron .
Schema del prototipo. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
37
37
40
A.1 Menu di pyGRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Introduzione
Introduzione generale
L’alta disponibilità è diventata al giorno d’oggi una delle caratteristiche fondamentali
di qualunque sistema di elaborazione orientato all’erogazione di servizi. Soprattutto
in alcuni ambiti specifici non è ammissibile la perdita di dati o l’impossibilità di usufruire di servizi. Non potendo garantire la perfezione, solitamente una soglia del 99%
di uptime è considerata, tranne casi particolari, il limite sotto il quale non è permesso
scendere se si vuol mantenere un buon funzionamento. Per favorire questa politica,
negli ultimi anni, sono state sviluppate notevolmente le tecniche di virtualizzazione dei
sistemi operativi, che garantiscono un rendimento di un processo al loro interno, praticamente identico rispetto a quello nel sistema nativo. L’utilizzo di queste tecniche può
apportare grandi vantaggi nella progettazione ed implementazione di una soluzione ad
Alta disponibilità attraverso l’isolamento del sistema operativo, erogatore del servizio,
dalla rispettiva macchina fisica.
Struttura della tesi
La tesi è strutturata in 4 capitoli suddivisi in:
Capitolo 1 in questo capitolo vengono descritte sia l’alta disponibilità, che la virtualizzazione, il loro funzionamento e le distinte soluzioni disponibili per implementarle.
Capitolo 2 in questo capitolo viene proposto il prototipo concettuale per realizzare
l’alta disponibilità mediante l’uso della virtualizzazione; inoltre vengono presentati i test fatti sulle differenti soluzioni disponibili.
Capitolo 3 in questo capitolo viene definita ed implementata una prima versione del
prototipo proposto nel capitolo precedente e tratte alcune cloncusioni.
Capitolo 4 in questo capitolo vengono descritte le possibilità che il futuro offre nell’ambito della virtualizzazione.
1
2
ELENCO DELLE FIGURE
Appendice A appendice nella quale viene descritta l’installazione e l’uso di Xen 3.0.2
e la creazione di distinte immagini minimali funzionanti di Scientific Linux.
Appendice B appendice nella quale si spiega come installare e configurare i distinti
dispositivi di storage utilizati nei test.
Appendice C appendice nella quale si spiega come installare e configurare i programmi Nagios e Cfengine utilizzati nel prototipo.
Capitolo 1
Alta Disponibilità e
Virtualizzazione
1.1 Cos’è l’Alta disponibilità
Alta disponibilità è il termine usato per descrivere i sistemi di computer che sono stati
configurati in modo da ridurre al minimo la percentuale di tempo in cui saranno inattivi
o non disponibili e, di conseguenza, consentirne il più alto grado di utilizzo. L’alta
disponibilità del sistema si ottiene riducendo la probabilità che un guasto hardware o
un difetto software abbiano come conseguenza la perdita dell’uso del sistema o una
perdita dei suoi dati.
1.1.1 Alta disponibilità tramite backups
Una possibile soluzione, ma anche la più semplice, è quella di gestire un sistema di
storage in cui memorizzare i backup delle macchine, in maniera da essere pronti al
successivo ripristino in caso di guasti. Questa soluzione non è affatto ottimale in quanto
richiede personale disponibile ad ogni ora per la riattivazione di servizi e potrebbe
portare ad un tempo di ripristino troppo lungo, non più accettabile, se il problema fosse
della macchina che ospita i servizi stessi.
Inoltre in questo tipo di soluzione bisogna trovare un compromesso fra la frequenza
di backup (maggiore è il numero di backup, minore è il rendimento) e le performance dei sistemi che si vogliono rendere affidabili (minore numero di backup, minore
affidabilità).
1.1.2 Alta disponibilità tramite ridondanza fisica
Una seconda soluzione è quella di avere macchine fisiche in ridondanza, mantenendo
un mirror (copia) della macchina che offre il servizio. Tramite questa soluzione si
3
4
CAPITOLO 1. ALTA DISPONIBILITÀ E VIRTUALIZZAZIONE
riesce in caso di guasto ad utilizzare la copia della macchina rendendo il tempo di
ripresa del servizio più basso. Lo svantaggio di questa scelta stà nella difficile gestione
delle copie in caso di grandi strutture dotate di tante macchine, oltre che ad un elevato
costo di manutenzione hardware e software.
1.1.3 Alta disponibilità tramite virtualizzazione
Una terza soluzione al problema è quella che si propone in questa tesi, ossia l’uso
di Virtual Machine multiple per il disaccoppiamento dei servizi dalla macchina. In
questo modo, utilizzando una struttura di macchine virtuali ed un sistema automatico di
monitoraggio, si otterrebbero molteplici vantaggi rispetto alle altre soluzioni proposte:
• Ridurre il downtime a pochi secondi.
– Avviare una nuova macchina virtuale in un’altra macchina fisica è un’operazione quasi istantanea.
– Se si riscontrano problemi in una macchina fisica si può migrare la virtuale
prima che la macchina fallisca, con un downtime pari a zero.
• Permettere facilmente lo sviluppo ed il test di nuove versioni, isolandone l’esecuzione.
• Rendere indipendenti dall’hardware sottostante i servizi e l’installazione, definendo una macchina virtuale e distribuendola sulle varie macchine fisiche.
1.2 Cos’è la virtualizzazione
In informatica la virtualizzazione consiste nella creazione di una versione virtuale di
una risorsa normalmente fornita fisicamente e appartenente a un sistema. Tra gli impieghi della virtualizzazione il più utilizzato è probabilmente la virtualizzazione di sistemi
operativi ottenuta attraverso software specifici che riescono a creare ambienti distinti in un’unica macchina fisica, in maniera da permettere l’esecuzione di un sistema
operativo in ognuno di questi ambienti.
Emulazione
Bochs
Qemu
VirtualPC
DOSEMU
...
Virtualizzazione
VMware
Plex86
Microsoft Virtual PC
Microsoft Virtual Server
...
Virtualizzazione a livello di SO
OpenVZ
Linux-VServer
FreeVPS
SWsoft Virtuozzo
...
Paravirtualizazzione
Virtual Iron
User-mode Linux
L4
Xen
Tabella 1.1: Tipi di virtualizzazione.
Il componente fondamentale di un sistema basato su macchine virtuali è il Virtual Machine Monitor, conosciuto anche con il nome di hypervisor. Il suo compito è
...
1.3. TEORIA DI POPEK E GOLDBERG
5
quello di allocare le risorse dinamicamente quando necessarie e isolare l’architetture
interrompendo eventuali attività pericolose per il sistema.
1.3 Teoria di Popek e Goldberg
Questa teoria stabilisce i requisiti minimi che deve avere un’architettura per essere
efficientemente virtualizzata. Fu introdotta da Popek e Goldberg nel 1974 nell’articolo
“Formal Requirements for Virtualizable Third Generation Architectures“ 1 [1]. Un
sistema di virtualizzazione deve:
• Essere equivalente, ossia un programma in esecuzione su di una macchina virtuale deve presentare lo stesso comportamento di quando è in esecuzione su di
una macchina fisica.
• Controllare tutte le risorse del sistema.
• Essere efficiente.
1.3.1 Insiemi di istruzioni
Per individuare i requisiti di virtualizzazione è stata introdotta una classificazione delle
istruzioni in tre diversi gruppi:
Privileged sono quelle che possono interrompere l’esecuzione del processore se è in
modalità utente (user-space) e non se è in modalità sistema (kernel-space).
Control sensitive sono quelle che tentano di cambiare la configurazione delle risorse
nel sistema.
Behavior sensitive sono quelle il cui comportamento, oppure il cui risultato, dipende
dalla configurazione delle risorse del sistema.
1.3.2 Teoremi
Il risultato finale dell’analisi può essere espresso attraverso due teoremi.
Primo teorema
Per qualsiasi calcolatore di terza generazione, un Virtual Machine Monitor potrà essere
sempre costruito se qualsiasi insieme di istruzioni sensitive è un sotto-insieme delle
istruzioni privileged.
1 Requisiti
formali per architetture di terza generazione virtualizzabili.
6
Secondo teorema
Un sistema di terza generazione sarà ricorsivamente virtualizzabile se
1. È virtualizzabile
2. Si può costruire su di lui un Virtual Machine Monitor senza dipendenze temporali.
1.3.3 Effetti della teoria di Popek e Goldberg
In accordo ai due teoremi si hanno architetture come la System/370 che sono virtualizzabili perchè hanno tutte istruzioni privilegiate ed altre, come la nota x86, che non
soddisfano i requisiti (ha 17 istruzioni sensitive, non privilegiate).
1.4 Tipi di virtualizzazione
1.4.1 Emulazione
In questo modello, il software di virtualizzazione simula interamente l’hardware, permettendo l’esecuzione di un qualsiasi programma, compreso un sistema operativo.
Questo permette per esempio all’interno di una particolare architettura, di far eseguire
programmi compilati per un’altra. Un emulatore è tipicamente diviso in diversi moduli:
• Emulatore di CPU.
• Modulo per il sistema di memoria.
• Modulo per i dispositivi di I/O.
1.4.2 Virtualizzazione
Quando si parla di virtualizzazione bisogna fare una distinzione se essa riguarda il
software o l’hardware.
Virtualizzazione software (x86)
Nella virtualizzazione software si simula una parte dell’hardware ed è dunque possibile eseguire un sistema operativo senza modifiche a patto che esso abbia la stessa
architettura del sistema ospite. L’implementazione della virtualizzazione software per
x86, come abbiamo già visto, non è ottima perchè questa architettura non soddisfa i
requisiti della Teoria di Popek e Goldberg per virtualizzazione (1.3), è quindi avrà un
rendimento abbastanza penalizzato.
1.5. XEN
7
Virtualizzazione hardware
Al giorno d’oggi i due principali produttori di chip, Intel e AMD, hanno proposto
le proprie tecnologie di virtualizzazione hardware, rispettivamente VT e Pacifica, che
diminuiscono, in termini di efficienza, il costo della virtualizzazione dell’architettura
x86.
1.4.3 Virtualizzazione a livello di SO
Attraverso questo tipo di virtualizzazione si suddivide un unico server fisico in più parti,
ognuna visibile dall’esterno come un server a se stante. Questo tipo virtualizzazione
ha un basso overhead che massimizza l’uso delle risorse del server ma ha anche il
difetto che, a differenza dell’emulazione e della paravirtualizzazione (vedi par. 1.4.4),
su di essa non possono essere eseguiti differenti sistemi operativi. Quindi è compito
dell’unico kernel gestire e mantenere isolate le risorse evitando un Denial of Service.
1.4.4 Paravirtualizzazione
Questo modello si differenzia da quello di virtualizzazione per il differente approccio
utilizzato. In questo caso il software di paravirtualizzazione agisce direttamente sull’hardware in modo da gestire la condivisione delle risorse destinate alle varie virtual
machine. A questo punto però il sistema operativo ospite dovrà essere modificato per
interagire con l’hypervisor.
Questa implementazione ha due caratteristiche fondamentali ed interessanti rispetto
alle altre soluzioni:
• L’hypervisor diventa molto più semplice.
• Le macchine virtuali che girano su questo sistema hanno un rendimento maggiore.
In questo gruppo ci sono varie soluzioni, e di seguito analizzeremo Xen che risulta
essere la più interessante per questo lavoro di tesi.
1.5 Xen
In questa sezione si effettuerà una panoramica sulle caratteristiche e l’architettura di
xen tralasciandone l’utilizzo, dettagliatamente analizzato nell’Appendice A.
1.5.1 Cos’è Xen
Xen [3] è un “open-source para-virtualizing virtual machine monitor (hypervisor)“per
l’architettura x86 in grado di asssicurare su di una singola macchina fisica l’esecuzione
di molteplici macchine virtuali, mantenendo una performance molto vicina a quella
8
nativa. Xen è nato all’inizio come un progetto di ricerca dell’Università di Cambridge
e la sua prima versione venne pubblicata nel 2003. Al giorno d’oggi esistono due
versioni con notevoli differenze e incompatibilità tra loro: Xen 2.0 e Xen 3.0. La
versione 2.0 non sarà più sviluppata e quindi la versione su cui si sta lavorando e alla
quale si farà riferimento è la 3.0.
Native Linux (L), Xen/Linux (X), VMware Workstation 3.2 (V), User Mode Linux (U).
Figura 1.1: Confronto del rendimento tra vari metodi di virtualizzazione
1.5.2 Paravirtualizzazione in Xen
La tecnica che Xen utilizza è chiamata paravirtualizzazione (1.4.4) ed è la più efficiente
e sicura tra le tecniche di virtualizzazione. Con essa Xen riesce a mantenere l’overhead
al di sotto del 5% rispetto alle altre tecniche che di norma lo portano sopra il 30% (vedi
Figura 1.1 a pagina 8). Per far ciò Xen introduce modifiche sia nelle macchine host
che nelle macchine guest. La macchina in cui verrà fatta la virtualizzazione (cioè, la
macchina host) non sarà più una macchina x86, ma diventerà una macchina con architettura Xen-x86 e i sistemi operativi che si vorranno virtualizzare dovranno adattarsi a
questa architettura.
È per questo che non tutti i sistemi operativi sono supportati per la virtualizzazione
tramite Xen o possono eseguirlo come hypervisor. La Tabella 1.2 a pagina 9 mostra i
sistemi operativi compatibili con Xen 3.0 in questo momento.
In questa tesi, si parlerà di Xen utilizzando sempre come host un kernel Linux della
serie 2.6.
1.5. XEN
9
Sistema operativo
Linux 2.6
NetBSD 3.0
FreeBSD 5.3
Plan9
ReactOS
S.O. senza modifiche
Host
Si
No
No
No
No
No
Guest
Si
In alto grado di sviluppo
In alto grado di sviluppo
In sviluppo
Proggettato.
Supporto iniziale tramite Intel VT
Tabella 1.2: Compatibilità tra Xen 3.0 e distinti sistemi operativi
1.5.3 Architettura di Xen
L’architettura x86 ha un modello di protezione basato su quattro livelli di privilegi (vedi
Figura 1.2 a pagina 9). Questi livelli 2 sono numerati da 0 a 3 dove lo 0 rappresenta il
livello con più privilegi.
ring-3
ring-3
ring-1
ring-1
ring-1
ring-1
ring-0
ring-0
SO
XEN
dom-0
dom-U
aplicazioni
utente
Sistema operativo senza Xen
aplicazioni
utente
Xen
Figura 1.2: Livelli di privilegi di un sistema operativo senza (sinistra) e con Xen
(destra)
Un sistema operativo non virtualizzato avrà la seguente struttura:
ring-0 Livello dove si esegue il kernel del sistema operativo. Questo livello è l’unico
dove si possono invocare istruzioni di tipo privilegiato.
ring-1, ring-2 Livelli di solito non utilizzati.
ring-3 Livello dove si eseguono le applicazioni utente.
Un sistema operativo modificato per eseguire Xen come hypervisor avrà invece la
seguente struttura:
ring-0 Livello dove si esegue l’hypervisor.
ring-1 Livello dove si eseguono i sistemi operativi ospite.
2 chiamati
col termine inglese: ring
10
ring-2 Livello di solito non usato.
ring-3 Livello dove si eseguono le applicazioni utente.
Una volta installato Xen in una macchina fisica, in automatico viene caricata e
avviata nel ring-0 una prima macchina virtuale, in maniera totalmente trasparente all’utente (vedi Figura 1.3 a pagina 10). Questa, denominata VM0 oppure dom0, rappresenta il sistema operativo su cui si è fatta l’installazione di Xen ed ha privilegi speciali
per l’accesso all’hardware e per la gestione di tutte le altre macchine virtuali (denominate domU), contrariamente a tutte le altre macchine virtuali che possono accedere
all’hardware solo attraverso il dom-0.
Figura 1.3: Architettura di Xen
1.5.4 I daemon di Xen
1.5.4.1 Xen daemon: xend
Per controllare, creare ed effettuare azioni nei distinti dom-U è indispensabile l’esecuzione di un particolare programma python, denominato xend, all’interno del dom-0.
Questo processo ha il compito di eseguire le richieste (creazione, distruzione, migrazione..) che vengono effettuate tramite il comando xm (Si parlerà del funzionamento
nell’ Appendice A).
1.5.4.2 Xen Store Daemon: xenstored
Questo daemon è un server in esecuzione nel dom-0 che ha il compito di memorizzare
le informazioni delle varie macchine virtuali, sotto forma di albero, all’interno di un
database condiviso tra i differenti dom-U. Attraverso questo Xen riuscirà a controllare
le varie macchine virtuali in esecuzione.
1.6. VANTAGGI DELLA VIRTUALIZZAZIONE
11
1.5.5 Caratteristiche di Xen
• Virtualizzazione con una penalizzazione nel rendimento molto bassa.
• Possibilità di mettere in pausa la esecuzione delle Virtual Machine.
• Migrazione delle Virtual Machine senza interruzioni –live migration–.
• Riallocazione di memoria in esecuzione.
• Controllo delle Virtual Machine via interfaccia web.
• Software libero (licenza GPL).
1.6 Vantaggi della virtualizzazione
La virtualizzazione tramite Xen, permette di:
• Eseguire distinti sistemi operativi contemporaneamente in una singola macchina.
• Separare i servizi dall’hardware (per quelli che non dipendono da un HW determinato) e dal sistema operativo installato sull’hardware.
• Isolare le macchine su cui sono in esecuzione i servizi, in modo che, per esempio, ogni utente disponga di una macchina completa per il suo uso (maggiore
sicurezza di fronte a intrusioni).
• Possibilità di clonare le macchine per fare test e aggiornamenti, senza compromettere la integrità della macchina originale, con la possibilità di tornare indietro
in maniera controllata.
• Possibilità di scalabilità, entro certi limiti.
• Mettere in pausa le macchine con la possibilità di migrare una macchina virtuale
a un’altra macchina fisica e riprendere l’esecuzione nel punto di arresto. Questo
permette:
– Load-balancing: si possono migrare macchine virtuali da un host con un alto carico ad un host senza carico senza fermare le macchine (live-migration).
– Alta disponibilità: se una macchina fallisce si possono migrare le macchine
virtuali (prima che falliscano) o recuperare uno snapshot e farlo eseguire
su un’altra macchina host.
12
Fallimento di una macchina fisica.
Macchina fisica 1
Servizio 2
Servizio 1
Macchina fisica 2
Internet
Servizio 4
Servizio 3
Macchina fisica 3
Servizio 6
Servizio 5
Migrazione delle macchine virtuali.
Macchina fisica 1
Servizio 1
Servizio 2
Macchina fisica 2
Servizio 3
Internet
Servizio 4
Macchina fisica 3
Servizio 5
Servizio 6
Ritorno allo stato di normalità.
Macchina fisica 1
Servizio 1
Servizio 2
Servizio 3
Servizio 4
Servizio 6
Macchina fisica 2
Internet
Servizio 5
Macchina fisica 3
Figura 1.4: Ripristino di due servizi virtualizzati
Capitolo 2
Il prototipo: analisi delle
possibilità e test dei componenti
In questo capitolo verrà proposto un modello prototipale di architettura di un sistema
ad alta disponibilità ed in seguito la serie di test effettuati per la determinazione della
migliore soluzione.
2.1 Prototipo di architettura
La struttura proposta è quella mostrata nella Figura 2.1 a pagina 14. Gli elementi
presenti e le loro funzioni sono:
Macchine fisiche In questo modello le macchine fisiche presenti hanno soltanto la
funzione di ospitare una o più macchine virtuali, eseguendo Xen. Per questo
nelle macchine si può utilizzare qualsiasi sistema GNU/Linux compatibile con i
requisiti di quest’ultimo.
Macchine virtuali Tutti i servizi che devono essere altamente disponibili devono essere virtualizzati.
Storage I filesystem su cui si eseguono le macchine virtuali. Le immagini delle
macchine vengono caricate da un server, tramite rete.
Servizio di healtcheck Questo servizio deve essere eseguito sia sulla macchina fisica,
sia su quella virtuale, poiché è incaricato di gestire e verificare il funzionamento
del sistema. Nella Sezione 3.1 si parlerà più in dettaglio di questo sistema.
In questo schema le macchine virtuali, quelle che realmente eseguono i servizi, sono
indipendenti dall’hardware sottostante ottenendo il vantaggio di poter essere eseguite
in uno qualsiasi dei nodi fisici. Per far ciò si deve utilizzare un server di storage per
13
14CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI
Figura 2.1: Prototipo di architettura di un sistema ad alta disponibilità tramite Xen.
caricare le immagini tramite rete ed esser cosı̀ in grado di spostare una maccchina host
automaticamente.
2.2 Soluzioni distinte per lo storage
Uno degli elementi fondamentali di questo prototipo è il sistema utilizzato per memorizzare e distribuire le immagini delle macchine virtuali, per questo, è necessario uno
studio delle distinte tecnologie e soluzioni esistenti sul mercato per rendere possibile
la distribuzione di un filesystem via rete.
In generale possiamo suddividere le soluzioni nelle seguenti categorie:
• Block device remoti via hardware
• Block device remoti via software
• Filesystem distribuiti
2.2. SOLUZIONI DISTINTE PER LO STORAGE
15
2.2.1 Block device remoti via hardware
Queste soluzioni si basano sulla esportazione di diversi block device da vari dispositivi
collegati via rete. In particolare, sono quelli basati su un hardware dedicato, di solito
costoso, e specificamente disegnato per fare questa funzione.
La tecnologia più conosciuta è Fibre Channel[6].
2.2.1.1 Fibre Channel
Fibre Channel è una tecnologia ad alta velocità, utilizzata principalmente per lo storage in rete. Fibre Channel diventa importante e fondamentale nell’ambito dei grandi
supercomputer e in ambito aziendale. Ci sono diverse topologie (Figura 2.2 a pagina
15):
Figura 2.2: Le topologie FC.
Switched Fabric Tutti i device sono collegati ai Fibre Channel switches (molto simile
all’implementazione delle moderne Ethernet).
Point-to-point Due dispositivi sono collegati direttamente (soluzione semplice e limitata).
Arbitrated Loop Tutti i device sono collegati ad anello rendendo questa soluzione la
più sensibile ai problemi.
A dispetto del suo nome, Fibre Channel può essere implementato sia con cavi di fibra
ottica, che con twisted-pair.
2.2.2 Block device remoti via software
Queste soluzioni sono simili ai block device remoti via hardware ma a differenza dei
primi non viene utilizzato un hardware specifico ma bensı̀ un software speciale. Queste
soluzioni sono una buona alternativa in quanto il prezzo della implementazione non è
cosi elevato e le prestazioni sono abbastanza buone.
Le due soluzioni principali sono GNBD e iSCSI.
2.2.2.1 iSCSI
L’iSCSI 1 è un protocollo definito nel Request For Comments (RFC) 3720 [10] dall’Internet Engineering Task Force 2 per utilizzare il protocollo Small Systems Computer
Interface (SCSI), usando come mezzo trasmissivo una rete TCP/IP. Vista la vasta diffusione delle reti TCP/IP e il continuo sviluppo della tecnologia Gigabit Ethernet 3 le
SAN[4] 4 basate su iSCSI sono divenute una soluzione economica, ma non per questo
poco efficiente.
iSCSI è basata su un’architettura (Figura 2.3 a pagina 16) client-server (quella di
SCSI), dove il client è chiamato ”initiator” ed il server è chiamato ”target”. In un
sistema iSCSI, un initiator fa richiesta di un servizio a un target utilizzando uno dei
protocolli di trasporto definiti per lo standard SCSI.
Figura 2.3: Architettura di iSCSI.
Attualmente esistono varie implementazioni di iSCSI per i sistemi GNU/Linux:
Initiator
La implementazione più stabile e la più matura è quella chiamata coreISCSI http://www.kernel.org/pub/linux/utils/storage/
iscsi/.
Target
La implementazione su cui si sta lavorando di più è The iSCSI Enterprise
Target http://iscsitarget.sourceforge.net/.
1 Internet
Small Computer Systems Interface
2 http://www.ietf.org/
3 Tecnologia
4 Storage
per implementare reti Ethernet a una velocità nominale di 1 Gigabit per secondo.
Area Network, soluzione di storage in reti usando protocolli di basso livello (SCSI, ATA, ecc)
2.2. SOLUZIONI DISTINTE PER LO STORAGE
17
L’installazione e configurazione di iSCSI viene descritta nell’Appendice B.
2.2.2.2 GNBD
GNBD [7] consente l’accesso a distinti block device (sia locali che in una SAN) attraverso una rete che di solito è Ethernet; è una tecnologia sviluppata da Red Hat per
essere utilizzata originalmente con il Red Hat Global File System.
L’unica distribuzione esistente è quella della Red Hat, che è parte di una suite conosciuta con il nome di Cluster ftp://sources.redhat.com/pub/cluster/
releases.
2.2.3 Filesystem distribuiti
I filesystem distribuiti più utilizzati e conosciuti sono due:
GFS
sviluppato dalla Red Hat.
GPFS
General Parallel File System, sviluppato dalla IBM.
Essi permettono di accedere ad uno stesso filesystem da un numero indeterminato di
calcolatori. Inoltre attraverso essi si può ottenere:
• Una alta scalabilità e flessibilità.
• Un aggiornamento unico del software per tutte le macchine.
• Un’ottima gestione di grandi volumi di dati (vengono usati come un’unica partizione).
• Un minor uso di copie ridondate di dati.
Figura 2.4: Schema di filesystem distribuiti.
2.3 Test delle componenti
2.3.1 Test di compatibilità
Per poter implementare il prototipo è stato necessario effettuare una nutrita serie di test,
raggruppabili in:
• Test di compatibilità delle componenti software
• Test di prestazioni delle diverse soluzioni di I/O
Test di sistemi host
I test effettuati si sono basati sull’installazione e prova di Xen 3.0.2 (in una prima
installazione è stato usato Xen 3.0.1) su varie distribuzioni GNU/Linux come sistema
host, sempre utilizzando il kernel Linux 2.6.16-xen (nella installazione di Xen 3.0.1 si
è era usato il kernel Linux 2.6.12.6-xen):
• Slackware Linux 10.2.
• Gentoo Linux 2006.0.
• Scientific Linux.
• Ubuntu Drapper.
• Fedora 5.
Durante le installazioni non si sono riscontrati particolari problemi, nè errori (l’importante è stato leggere con attenzione i requisiti d’installazione richiesti da Xen e
conformarsi alle richieste).
Test di sistemi guest
I test di compatibilità effettuati per il sistema guest si sono svolti con la distribuzione Scientific Linux (nelle versioni 3 e 4), utilizzando sempre il kernel modificato da
Xen (Linux 2.6.16-xen per la versione di Xen 3.0.2 e Linux 2.6.12.6-Xen per la versione 3.0.1). Durante i test si è verificata l’indipendenza delle macchine virtuali dall’hardware sottostante. Si sono eseguite le varie macchine su hardware diverso senza
nessun tipo di problema, con la sola accortezza di ricordarsi dell’incompatibilità fra
l’architettura a 32 bit e quella a 64.
Test di dispositivi storage
Sono stati anche eseguiti test per verificare la compatibilità tra i driver delle distinte
soluzioni di storage disponibili e il kernel linux modificato da Xen, senza riscontrare
problemi.
2.3. TEST DELLE COMPONENTI
19
2.3.2 Test di I/O
Sono stati realizzati diversi test per verificare le prestazioni delle soluzioni mostrate
nella Sezione 2.2, sia in macchine a 32 bit che a 64 per scoprire la migliore soluzione
da implementare in seguito nel prototipo.
2.3.2.1 IOzone
IOzone 5 è uno strumento ampiamente utilizzato per fare prove comparative di rendimento nell’accesso ai dischi (sia tra differenti filesystem che tra differenti dispositivi).
Si è utilizzato questo tool per effettuare i test, sottoponendo le macchine ad un alto
carico di lavoro. Durante le prove è stato possibile verificare la stabilità delle varie
soluzioni di storage e di quelle di Xen, garantendo assenza di problemi anche in caso
di live-migration sotto alto tasso di I/O.
2.3.2.2 Caratteristiche delle macchine utilizzate nei test
Le macchine fisiche utilizzate (in totale sono state due) per eseguire i test avevano le
caratteristiche mostrate nella Tabella 2.1 a pagina 19, mentre le macchine virtuali caricate (2 per ogni macchina fisica) avevano una memoria RAM di 512 MB ed eseguivano
una Scientific Linux 4.2 con un Kernel 2.6.16-xen.
Processore
Memoria
Disco
Conessione Rete
Sistema Operativo
Dual AMD Opteron 2GHz
1GB
40GB
Gigabit Ethernet / Fibra ottica
Gentoo Linux - Kernel 2.6.16-xen
Tabella 2.1: Caratteristiche macchine fisiche.
Per gli altri test, si è utilizzato il fileserver descritto nella Tabella 2.2 a pagina 19.
Processore
Memoria
Disco
Conessione Rete
Sistema Operativo
Dual Pentium III 1GHz
256MB
210GB - RAID 5
Gigabit Ethernet
Slackware Linux 10.2 - Kernel 2.6.15.6
Tabella 2.2: Caratteristiche fileserver.
In alcuni test si è utilizzato anche un disco Fibre Channel con le caratteristiche della
Tabella 2.3 a pagina 19.
Spazio disco
Conessione Rete
4797776,28MB
Fibra Ottica
Tabella 2.3: Caratteristiche disco FC.
5 URL:
http://www.iozone.org/
2.3.2.3 Interpretazione dei risultati
Prima di introdurre i test di I/O, si spiegherà come analizzare le immagini. La Figura
2.5 a pagina 20 rappresenta un esempio di un test effettuato con IOzone. Con l’asse
delle ascisse viene rappresentata la dimensione del file a cui IOzone ha accesso, mentre
con l’asse delle ordinate si rappresenta la velocità di accesso. Analizzando l’immagine
si nota che ci sono tre differenti zone:
Figura 2.5: Esempio di risultato di un test con IOzone.
• Zona alta: queste misure rappresentano il risultato dell’accesso al disco, quando
il file è molto piccolo ed esiste l’influenza della cache della CPU.
• Zona media: Queste misure rappresentano il risultato quando si ha l’influenza
della cache del buffer.
• Zona bassa: Queste misure rappresentano i risultati reali di accesso al disco in
totale assenza di effetti di cache.
2.3.2.4 Risultati
Fibre Channel
Nel test si è utilizzato un disco Fibre Channel con le caratteristiche della Tabella 2.3 a
pagina 19, collegato alle due macchine fisiche prima descritte (tramite una connessione
in fibra ottica a 2Gb/s).
I risultati ottenuti si possono osservare dalle Figure 2.6-2.9. Analizzando le immagini si nota un piccolo miglioramento nel rendimento (più visibile nella Figura 2.6 a
pagina 21) per file di dimensioni sotto 1KB nell’uso di Fibre Channel con un sistema
operativo a 64 bit, mentre nei restanti test il rendimento è circa lo stesso per tutte e due
le architetture.
Figura 2.6: Test di lettura a 64 bit.
Figura 2.7: Test di scrittura a 64 bit.
21
GNBD
In questi test è stato utilizzato il fileserver descritto nella tabella 2.2 e le due macchine
descritte nella tabella 2.1. I risultati ottenuti si possono osservare dalle Figure 2.102.13.
Analizzando le immagini si può osservare un comportamento anomalo derivato
23
probabilmente dall’esistenza di carico nella rete. Per esempio nella Figura 2.12 a pagina 24 si può identificare nella zona alta e bassa una differenza di velocità molto sostenuta che non dovrebbe sussistere. Inoltre, come nella soluzione Fibre Channel, si può
osservare un incremento del rendimento per file di piccole dimensioni nell’architettura
a 64 bit.
iSCSI
Per effettuare questi test si è utilizzato lo stesso fileserver dei test con GNBD, già mostrato precedentemente, utilizzando come initiator l’implementazione chiamata coreiSCSI [12] e come target nelle macchine fisiche The iSCSI Enterprise Target [14]. I
risultati ottenuti si possono osservare dalle Figure 2.14-2.17.
25
Analizzando le immagini si può osservare lo stesso comportamento riscontrato nei
test effettuati con GNBD, probabilmente dovuto alla connessione di rete. Inoltre si
continua ad osservare l’aumento del rendimento nella architettura a 64 bit per file di
piccole dimensioni.
2.3.2.5 Confronto dei risultati
Nei confronti di seguito riportati è stata utilizzata solamente la porzione di dati di maggior interesse per il rendimento del sistema di storage, nel nostro caso, ossia si analizzano i tempi di lettura/scrittura solamente per file di dimensioni maggiori di 512 MB e
minori di 2 GB. Nelle Figure 2.20, 2.18, 2.22 e 2.24 si è riportato il confronto tra i ri-
27
sultati delle varie soluzioni per le diverse modalità di test di IOzone. Nelle figure 2.19,
2.21, 2.23 e 2.25 invece è riportato il grafico 3D delle stesse quantità con l’aggiunta di
una terza dimensione rappresentata dal record.
Come si evince dalle figure, il rendimento del dispositivo Fibre Channel è superiore
alle soluzioni software proposte, in quanto:
• Il tipo di conessione utilizzata tra le macchine e il disco è di 2Gb/s.
• Il disco Fibre Channel è un dispositivo hardware specifico per essere utilizzato
come SAN.
Nonostante questi validi motivi il costo del dispositivo è abbastanza elevato (circa
1000 euro per una scheda di interfaccia) ed implementare una soluzione basata su iSCSI o GNBD è poco penalizzante in termini di prestazioni e molto vantaggiosa dal lato
economico. Quindi nell’implementazione finale del prototipo si è scelto iSCSI che ha
dimostrato scalabilità, stabilità ed un rendimento sebbene non in maniera elevatissima
migliore di GNBD.
Figura 2.18: Confronto 2D risultati scrittura a 32 bit.
Figura 2.20: Confronto 2D risultati lettura a 32 bit.
29
31
Capitolo 3
Il prototipo: il sistema di
Healthcheck e
l’implementazione
3.1 Sistema di Healthcheck
Con il termine Healtcheck si identifica un tipo di servizio svolto da un programma che
si occupa di analizzare lo stato di funzionamento delle macchine monitorate e agire di
conseguenza.
Sostanzialmente l’healtcheck può essere visto come un supervisore che all’insorgere di problemi, li ripristina senza l’intervento umano. Nel nostro caso specifico, esso
si occuperà sia della riattivazione dei servizi, che della gestione di tutta l’architettura
virtuale.
3.2 Analisi delle problematiche
La realizzazione di una struttura completamente virtuale apporta notevoli vantaggi, sia
nella gestione delle macchine, che nella flessibilità dell’infrastruttura stessa. Tali vantaggi sono sostanzialmente dovuti alla possibilità di gestire virtualmente le macchine,
attraverso migrazioni live, riavii e pause e alla possibilità in caso di necessità, di un
facile incremento o una riduzione del numero delle macchine.
Tutto ciò però, non elimina la problematica dell’intervento umano nel caso insorgano problemi ai servizi o alle stesse macchine virtuali.
Al giorno d’oggi, esistono soluzioni di monitoring in grado di controllare macchine
ed inviare segnalazioni in caso di problemi, ma la soluzione che si vuole ottenere deve
riuscire a gestire indipendentemente dall’intervento umano, non solo la riattivazione di
33
34CAPITOLO 3. IL PROTOTIPO: IL SISTEMA DI HEALTHCHECK E L’IMPLEMENTAZIONE
servizi, ma anche la gestione delle macchine virtuali, obbligando tale intervento solo
in casi limite.
Inizialmente, dopo aver analizzato approfonditamente il problema, si è deciso di
scrivere un software per gestire l’intera infrastruttura. Il software è stato scritto in
linguaggio C ed è stato composto di due parti: una parte master, da installare nella
macchina che effettua il monitoring, ed una parte slave, da installare nelle macchine da
monitorare. Semplicemente il software creato si è basato sull’interazione fra master e
slave che attraverso messaggi di tipo UDP si comunicano informazioni riguardanti lo
stato delle macchine ed eseguono script.
Lo sviluppo di tale programma ci ha aiutato a capire maggiormente le problematiche nella realizzazione di un software di tale genere. I maggiori problemi realizzativi si
sono riscontrati nella creazione delle dipendenze fra macchine virtuali e fisiche, nella
creazione di script per il controllo di servizi ed infine nella gestione della migrazione
delle macchine.
Dopo aver intuito le difficoltà, si è pensato di esplorare nuove possibilità, alla ricerca di una soluzione più adeguata alle esigenze, concentrandosi maggiormente su
software che implementino gestione di virtualizzazione o monitoring.
3.3 Analisi dei software
Come già affermato precedentemente, la ricerca di possibili soluzioni ha portato ad una
serie di software, ognuno con delle caratteristiche specifiche, e di seguito ne analizzeremo i pro ed i contro in riferimento alla nostra idea realizzativa.
I software sono i seguenti:
• XenEnterprise
• OpenQRM
• Enomalism
• Virtual Iron
• Nagios e Cfengine
e di seguito ne analizzeremo le caratteristiche.
3.3.1 XenEnterprise
XenEnterprise è un package integrato a pagamento, sviluppato dagli stessi autori di
Xen, che include una serie di tool in grado di semplificare la gestione e la pubblicazione
di macchine virtuali.
XenEnterprise è in grado di permettere la gestione (creazione, pausa, migrazione,
etc..) delle macchine virtuali attraverso una semplice interfaccia grafica molto esplicativa. Ovviamente esso semplifica notevolmente il compito di chi deve occuparsi di
3.3. ANALISI DEI SOFTWARE
35
grandi infrastrutture e non vuole utilizzare in maniera costante la linea di comando,
implementando inoltre all’interno un supporto per driver di innumerevoli periferiche.
Nella nostra specifica realizzazione, il programma non risulta di particolare interesse in quanto non si occupa della gestione di servizi, e almeno in apparenza, non
dimostra un notevole sviluppo nella gestione delle macchine virtuali in caso di fallimento.
Figura 3.1: Schermata XenEnterprise
3.3.2 OpenQRM
OpenQRM è una piattaforma di system management molto interessante in quanto ha
avuto due anni di collaudo come prodotto commerciale, prima di divenire open source.
Uno dei suo pregi è l’architettura modulare basata su plugin che permette l’aggiunta di
componenti in ogni parte del sistema, inclusa l’interfaccia, l’agente di monitoraggio ed
il motore di decisione.
OpenQRM inoltre ha un’alta scalabilità e riesce a gestire molteplici server con
report dettagliati, attraverso una semplice interfaccia. Il sistema è dotato di supporto a
server con dischi locali, NAS o iSCSI e permette l’utilizzo di kernel 2.4 e 2.6.
Il programma grazie alla sua estendibilità, ha da poco aggiunto il supporto a Xen
attraverso plugin di sviluppatori esterni, ma il rischio di immaturità di tale soluzione,
non ne fa un sistema totalmente affidabile e ciò ci ha fatto propendere per un’altra
scelta.
Figura 3.2: Schermata OpenQRM
3.3.3 Enomalism
Enomalism è una applicazione web tramite la quale si può gestire l’amministrazione
di macchine virtuali Xen. Si basa su di una interfaccia grafica che semplifica la complessa gestione di centinaia di macchine virtuali, permettendo inoltre l’integrazione di
applicazioni di terzi attraverso l’utilizzo di particolari API.
Dall’analisi effettuata, Enomalism risulta essere un progetto open source che non
ha trovato grande appoggio e si ritrova ancora in una fase di beta. Anche se viene detto
che è in continuo sviluppo, non sono state rilasciate nuove versioni e l’implementazione
fino ad ora creata non sembra essere la soluzione ideale per implementare il nostro
prototipo.
3.3.4 Virtual Iron
Virtual Iron è una soluzione per la creazione e la gestione di infrastrutture virtuali che
permette un avanzata paravirtualizzazione dei server attraverso l’uso dell’hypervisor di
Xen. Virtual Iron è distribuito in 3 versioni: Professional, Consolidation ed Enterprise
di cui una è open source.
Il sistema supporta fino a 8 CPU, sistemi a 32 e 64 bit e permette il recupero senza
intervento umano delle macchine in caso di fallimento. Inoltre crea dettagliati report
sulle singole macchine virtuali riguardo l’utilizzo delle risorse di sistema in esecuzione, e permette in casi di eccessivo utilizzo di una particolare macchina fisica, il Load
Balancing attraverso migrazione virtuale.
Virtual Iron è il software che si avvicina maggiormente alla nostre richieste, anche
se non supporta la gestione dei servizi, che però potrebbe essere gestita da programmi
3.3. ANALISI DEI SOFTWARE
37
Figura 3.3: Schermata Enomalism
all’interno delle macchine virtuali stesse. Sfortunatamente al momento della creazione
del prototipo il software ancora non è disponibile in nessuna delle versioni ma, ciò non
toglie che in futuro esso possa essere preso in considerazione come soluzione ottimale.
Figura 3.4: Schermata Virtual Iron
3.3.5 Nagios e Cfengine
Nagios [15] è un software open source per il monitoraggio di server e servizi di rete,
progettato per garantire alle strutture responsabili di essere costantemente informate
sulle prestazioni ed eventuali problemi dei sistemi monitorati. Esso funziona in ambiente Linux/Unix e gestisce sistemi di notificazione basati su mail, messaggistica e
SMS, oltre a disporre di un’interfaccia web accessibile via browser.
Nagios non contiene funzioni per la gestione della rete ma solo per il monitoraggio
di apparecchiature (computer, switch, router,..) e servizi (HTTP, FTP, POP3,..) ed è
composto da due parti fondamentali: il nucleo, che rappresenta la parte principale del
programma e i plugin, che sono programmi esterni tramite i quali si possono effettuare
i controlli.
Nella realizzazione del prototipo la scelta è ricaduta proprio su questo software e le
motivazione che ci hanno portato a tale decisione, possono essere in sostanza riassunte
dalle sue ottime caratteristiche:
• Monitoraggio di servizi di rete (SMTP, POP3, HTTP, NNTP, ICMP, SNMP)
• Monitoraggio delle risorse hardware dei server (carico del processore, utilizzo
dei dischi e della memoria)
• Semplice sviluppo di plugin tramite diversi linguaggi (Bash, C++, Perl, Python,
PHP, ..) per monitorare nuovi tipi di servizio.
• Notificazione ai contatti in caso di problemi.
• Capacità di definire eventi da eseguire durante il verificarsi di problemi per la
loro risoluzione.
• Produzione di log dettagliati sulle attività svolte.
• Interfaccia web per la verifica dello stato corrente, delle notifiche e della cronologia dei problemi.
Attraverso l’utilizzo di tale programma si è risolta la problematica del monitoraggio
dell’intera infrastruttura, sia virtuale, che fisica ma non si è affrontata minimamente la
problematica della riattivazione di servizi e gestione delle macchine virtuali. Per far
ciò, si è affiancato a Nagios, un altro software denominato Cfengine.
Cfengine [16] è un sistema di amministrazione di elaboratori Unix, il cui scopo
principale è automatizzare la configurazione e il mantenimento di sistemi operativi,
soprattutto quando si dispone di un gruppo eterogeneo di questi, su diversi elaboratori.
Cfengine può essere definito come l’interprete di un linguaggio evoluto il cui scopo
è analizzare un file di configurazione e confrontare lo stato attuale della macchina con
quello ideale descritto nel file, ricreandolo in caso di incongruenze tra i due.
Le sue principali caratteristiche sono:
• Monitoraggio e aggiornamento di permessi sui file.
• Montaggio e smontaggio automatico di filesystem NFS in corrispondenza delle
opportune modifiche in fstab.
3.4. IL PROTOTIPO
39
• Amministrazione attraverso singoli file, di netmask, configurazione del DNS,
route di default e interfacce di rete primarie.
• Copia ricorsiva in altre locazioni del filesystem , sia localmente che in un server
remoto, di file e directory.
• Aggiornamento, cancellazione o linking di file (caratteristica, questa, molto potente che offre l’uso di espressioni regolari e di funzioni di ricerca/sostituzione
su tutto il testo).
• Avvio, uccisione o riavvio di processi.
• Esecuzione diretta di una molteplicità di comandi di sistema.
Nell’infrastruttura creata Cfengine potrebbe da solo riuscire a riattivare i servizi
non più funzionanti, se non fosse per il fatto che il confronto tra lo stato ideale della
macchina e quello attuale risulta gravoso per il sistema e si esegue di norma una volta
ogni ora. Questo è uno dei motivi fondamentali per il quale si è utilizzato un software
di monitoring esterno come Nagios, oltre ovviamente alla possibilità, di avere sempre
un’idea generale su tutto il funzionamento dell’infrastruttura.
3.4 Il prototipo
Nella realizzazione specifica del prototipo, in questa tesi, ci si è occupati solamente
della parte riguardante la riattivazione di servizi in macchine virtuali e di seguito ne
daremo una descrizione prima logica e poi implementativa.
3.4.1 Schema Logico
Il prototipo si è realizzato utilizzando rispettivamente:
• 1 macchina fisica: 1 macchina virtuale (xentest206)
• 1 macchina fisica: 2 macchine virtuali (xentest207, xentest208)
• 1 macchina fisica: 2 macchine virutali (xentest209, xentest210)
con i seguenti software installati:
• xentest207, xentest208, xentest209, xentest210: Cfegine
• xentest206: Nagios, Cfegine
Figura 3.5: Schema del prototipo.
3.4.2 Implementazione Fisica
3.4.2.1 Nagios
Nella realizzazione fisica del prototipo, si è installato Nagios nella macchina xentest206, l’unica avente il compito di occuparsi del monitoraggio.
In generale, è stata fatta la scelta di monitorare solamente il funzionamento del servizio ssh e della raggiungibilità delle macchine attraverso il ping. Questa ha portato
alla semplificazione del prototipo, ma non per questo ad una perdita di generalizzazione, in quanto grazie all’alta scalabilità dei software utilizzati, il discorso può essere
ampliato ad una molteplicità di servizi.
3.4.2.2 Cfengine
Nel prototipo Cfengine ha il compito di riattivare il servizio ssh nel caso in cui il
demone sshd cessi il suo funzionamento.
Interessandoci specificatamente delle macchine, Cfegine si è installato su ognuna
di esse. Il motivo fondamentale di questa scelta è derivato dal fatto che, il nodo che
si occupa di effettuare il monitoring, deve essere in grado di far eseguire, ad ogni
istante, su ognuna di esse, il servizio integrato in Cfengine che confronta gli stati della
macchina ed in caso ne ripristina i servizi.
3.4. IL PROTOTIPO
41
3.4.2.3 Interazione tra i software
Nell’implementazione realizzata i due software interagiscono tra di loro, riuscendo
cooperativamente a rilevare e riavviare il servizio non più funzionante. Nello specifico,
di seguito, descriveremo le varie fasi del processo con maggiore chiarezza:
1) Stato quiete Il servizio è attivo e Nagios non rileva problemi.
2) Caduta del servizio Il servizio per qualche motivo non è più attivo, ma Nagios non lo ha
ancora rilevato.
3) Stato Allerta Nagios si rende conto che il servizio non risponde, entra in uno stato di allerta ed esegue il corrispettivo evento. Nel nostro caso viene eseguito lo script locale
handle cfrun.sh al quale viene passato l’indirizzo della macchina remota.
4) Stato Segnalazione Lo script attivato esegue un programma di Cfengine denominato cfrun
che invia un segnale alla macchina remota interessata.
5) Stato Ripristino La macchina remota riceve il segnale ed esegue istantaneamente Cfengine, il quale dopo aver effettuato il confronto tra gli stati, si rende conto dell’inconsistenza
e riattiva il servizio.
6) Stato quiete Una volta riattivato il servizio, si ristabilisce la situazione iniziale, nella quale
Nagios non rileva problemi.
3.4.2.4 Conclusioni
La struttura che si è riusciti a realizzare si è dimostrata, nel complesso, solida e stabile, permettendo la riattivazione dei servizi monitorati in modo automatico dopo soli
pochi secondi. Questo ha dimostrato la bontà dei software open source utilizzati ed
inoltre grazie all’ampio lavoro di analisi e quindi a scelte oculate, si è data al gruppo
la possibilità di proseguire nel lavoro, attraverso l’implementazione dell’intera gestione delle macchine virtuali, rendendo cosı̀ il prototipo una potente soluzione per l’alta
affidabilità.
Capitolo 4
Prospettive future
4.1 Virtualizzazione Hardware x86
In questi ultimi mesi si è assistito ad un incremento esponenziale dell’interesse nei
confronti della virtualizzazione, tanto che essa sta divenendo un elemento essenziale
nei piani di sviluppo degli stessi produttori di chip.
Attualmente, sia Intel che AMD, hanno sviluppato indipendentemente le estensioni di virtualizzazione dell’architettura x86 denominate Intel VT (abbreviazione di
Virtualization Technology) e Pacifica (AMD Virtualization), e di seguito tenteremo di
descriverne le caratteristiche fondamentali, effettuando un confronto tra le due possibilità.
4.1.1 Architettura
Per assistere la virtualizzazione, VT e Pacifica hanno introdotto un nuovo livello privilegiato al di sotto del ring 0. Entrambe le soluzioni hanno aggiunto 9 nuove istruzioni
che lavorano solamente nel livello denominato Ring -1, create appositamente per essese usate dell’hypervisor. Questo permette di eseguire sistemi guest senza modificarne
il sistema operativo e riducendone il costo di emulazione. Ovviamente quest’ultimo
non è eleminato del tutto in quanto ogni sistema operativo deve essere convinto che da
solo ha accesso alla memoria della macchina ed ai bus di I/O, mentre in realtà è sempre
l’hypervisor che manipola l’accesso ai dispositivi reali.
4.1.2 Memoria
La memoria è stata parzialmente virtualizzata sin dai 386, nel senso che il SO e un controller hardware di memoria, assegnavano la RAM fra le applicazioni. AMD presenta
un vantaggio in questo ambito perchè le sue CPU includono il controller di memoria
che Pacifica può semplicemente riutilizzare. In contrapposizione, le CPU Intel demandano il controllo di memoria ad un circuito integrato separato che non supporta VT, è
43
44
CAPITOLO 4. PROSPETTIVE FUTURE
ciò comporta un maggiore lavoro da parte dell’hypervisor nell’amministrazione della
memoria. Il controller di memoria Intel in futuro sarà introdotto nella CPU e potrà
essere in grado di usare VT, ma ciò non avverrà prima del 2007.
4.1.3 Input/Output
Attualmente, la virtualizzazione di I/O richiede dei driver in esecuzione nell’hypervisor, che si occupa di presentare i driver virtuali ai sistemi operativi guest. Le future
versioni di Pacifica e VT elimineranno i driver dall’hypervisor, permettendo ai driver
dei sistemi ospite di comunicare direttamente con l’hardware.
4.1.4 Sicurezza
La virtualizzazione può contribuire a proteggere un sistema da bug o da vulnerabilità,
ma in realtà non si fa che abbassare il problema di sicurezza e stabilità di un livello.
A questo punto, la bontà dei sistemi dipende sostanzialmente dagli hypervisor, che
fortunatamente tendono ad essere robusti in quanto, rispetto a grandi sistemi operativi,
sono dei microkernel, ed è più facile verificarne la sicurezza.
Ma VT e Pacifica possono ancora introdurre nuove vulnerabilità, specialmente per
gli utenti che non vogliono utilizzare le nuove possibilità di virtualizzazione. Un attacco ad un sistema che utilizza un unico sistema operativo non virtualizzato, non richiederebbe nemmeno l’hacking dell’hypervisor, poichè l’attaccante potrebbe solamente
inserire un virus o un trojan nell’inutilizzato Ring -1.
Un virus nel Ring -1 sarebbe il rootkit definitivo, perchè funzionerebbe al di sotto
del sistema operativo e simulerebbe esattamente il chip x86, riuscendo ad attaccare
persino il software perfettamente sicuro. In più esso sarebbe indipendente dal sistema
operativo, riuscendo a compromettere qualsiasi sistema x86 e sarebbe praticamente
impossibile da rilevare solamente con il software.
Per proteggersi da tale virus, il sistema ha bisogno di un componente hardware che
non può essere virtualizzato. Questo sarebbe fornito dalla Trusted Platform Module
(TPM), con il discutibile chip PKI già incluso in molti computer. La TPM si occuperebbe di osservare l’hypervisor e i programmi che carica in memoria, facendo un check
con dei valori hash precalcolati, in maniera da assicurare l’inalterazione dell’hypervisor e creando un certificato digitale che potrà poi essere verificato dal sistema operativo
virtualizzato e dai software di sicurezza.
È per questo che sia Intel che AMD stanno programmando di introdurre nel 2007
le tecnologie conosciute rispettivamente come La Grande e Presidio, destinate alla
sicurezza delle imprese.
Ringraziamenti
Al Prof. Leonello Servoli per avermi dato la possibilità di approfondire un argomento
di tale interesse e per la Sua puntuale disponibilità. Ad Igor per l’aiuto tecnico agli inizi
e l’appoggio morale. A Mirko e Massimo per avermi dato la possibilità di apprendere
parte delle loro ampie conoscenze. Ad Alvaro per avermi insegnato un po’ di parole
spagnole ed avermi raccontato di una realtà che non conoscevo. A tutti i miei amici,
che mi hanno sempre aiutato nel percorso universitario, anche nei periodi più difficili.
Alla mia famiglia che mi è sempre stata vicina, ed a tutte le persone che in qualche
maniera mi hanno dato una mano a crescere. Infine ad Elena, che con pazienza, ha
sempre sopportato i miei impegni senza mai smettere di credere in me.
45
Appendice A
Installazione e uso di Xen
A.1 Installazione di Xen
Si è scelto di installare Xen 3.0.2 perché è l’ultima versione stabile al momento dello
sviluppo del prototipo. Per l’installazione è sufficiente seguire le istruzioni disponibili
nella documentazione di Xen [3]. Bisogna però fare attenzione ai prerequisiti che, se
non soddisfatti, potrebbero far insorgere diversi problemi.
Al momento della scrittura della tesi, la versione di pygrub che viene distribuita
con Xen 3.0.2 è errata e bisogna installare quella distribuita con la versione non stabile
di Xen. Per fare questo, si può scaricare la versione dal sito web http://www.cl.
cam.ac.uk/Research/SRG/netos/xen/downloads.html e procedere all’installazione:
#
#
#
#
tar zxfv xen-unstable-src.tgz
cd xen unstable/tools/pygrub/
make build
make install
A questo punto, l’installazione di Xen dovrebbe essere pronta e una volta riavviata la
macchina, xend può essere lanciato attravarso il comando:
# xend start
Se ci sono problemi o errori, si consiglia di consultare la documentazione di Xen.
A.2 Configurazione di Xen
A.2.1 Configurazione di xend
Il demone xend viene configurato attraverso il file /etc/xen/xend-config.spx.
La configurazione di default è valida, ma bisogna cambiare una riga nel file per permettere la migrazione delle macchine virtuali.
47
48
APPENDICE A. INSTALLAZIONE E USO DI XEN
(xend-relocation-server no)
per
(xend-relocation-server yes)
A.2.2 Configurazione dei macchine virtuali
Ogni macchina virtuale necessita di un file di configurazione con la seguente struttura:
kernel
memory
name =
disk =
root =
vif =
dhcp =
= "/boot/kernel-2.6.12.6-xenU.64"
= 512
"xen-test"
[’phys:/dev/sdb1,sda1,w’]
"/dev/sda1 ro"
[’mac=00:00:00:00:02:07’]
"dhcp"
kernel Il path al kernel per utilizzare.
memory La memoria RAM da utilizzatare.
name Il nome della macchina (se si usa il DHCP questo nome sarà cambiato in quello
fornito dal DHCP).
disk Il block device in cui si trova il filesystem della macchina virtuale.
root Punto di mount per la partizione root.
vif Il MAC address della macchina (se non si usa il DHCP si può anche specificare
l’indirizzo IP).
dhcp Se questa variabile ha come valore “dhcp” questo servizio verrà utilizato.
A.2.3 pyGRUB
Se si volesse utilizzare un kernel interno all’immagine della macchina virtuale piuttosto che un kernel esterno, si dovrebbe utilizzare pygrub, modificando nel file di
configurazione i seguenti parametri:
kernel = "/boot/kernel-2.6.12.6-xenU.64"
per
bootloader = "/usr/bin/pygrub"
Nell’immagine dovrà ovviamente esistere un file /boot/grub.conf contenente
una configurazione valida per il kernel installato nella macchina. A questo punto, ogni
qual volta si avvia la macchina virtuale comparirà un menù in cui scegliere quale kernel
utilizzare.
A.3. USO DI XEN
49
pyGRUB version 0.3
??????????????????????????????????????????????????????????????????????????
? Linux 32bit kernel 2.6.12.6-xen
?
? Linux 32bit kernel 2.6.16-xen
?
?
?
?
?
?
?
?
?
?
?
?
?
??????????????????????????????????????????????????????????????????????????
Use the ˆ and ? keys to select which entry is highlighted.
Press enter to boot the selected OS. ’e’ to edit the
commands before booting, ’a’ to modify the kernel arguments
before booting, or ’c’ for a command line.
Figura A.1: Menu di pyGRUB
A.3 Uso di Xen
A.3.1 Lanciare Xen
Xen funziona tramite un daemon chiamato xend che per essere avviato necessita semplicemente del comando:
# xend start
A.3.2 Il tool xm
Xm è il tool presente in Xen per controllare le macchine virtuali. Xm può essere
utilizzato per creare, distruggere, mettere in pausa, migrare, reassegnare memoria, ecc.
L’uso è questo:
# xm <ordine> [argomenti]
I comandi più utilizzati sono:
xm create <config file> Crea una macchina virtuale secondo il file di configurazione <config file>.
xm list Stampa a schermo la lista delle macchine virtuali attive nel seguente formato:
# xm list
Name
xentest206
xentest207
Domain-0
ID Mem(MiB) VCPUs
18
512
1
19
512
1
0
485
2
State
-b----b---r-----
Time(s)
343.5
363.1
17502.3
xm console <dom id> Effettua l’accesso alla console della macchina <dom id>.
<dom id> può essere il nome della macchina oppure l’ID che compare attraverso il comando xm list.
50
xm shutdown <dom id> Fa lo shutdown della macchina <dom id>.
xm destroy <dom id> Distrugge la macchina virtuale <dom id>.
xm reboot <dom id> Riavvia la macchina <dom id>.
xm migrate <dom id> <host> Migra la macchina <dom id> all’host <host>
(che ovviamente ha xend in esecuzione).
xm migrate --live <dom id> <host> Migra la macchina <dom id>, senza metterla in pausa, all’host <host>.
...
A.4 Creazione di una VM SL4
Di seguito si descrivono le fasi per creare un’immagine funzionante di SL4 sotto Xen
3.0.2. Nell’esempio l’installazione viene effettuata in /dev/sdb1.
A.4.1 Installazione di SL4
Si è scelto di fare un’installazione minimale di SL4 in un block device accessibile
da una macchina funzionante con GNU/Linux (/dev/sdb1). Per far ciò, si sono scelti solamente pacchetti indispensabili al funzionamento del sistema e della rete, potendo successivamente ampliare l’installazione attraverso software come yum
o apt-get. È importante far notare come non si debba installare né SE-Linux né
GRUB (o LILO). Una volta finita l’installazione minimale e avviata la macchina con il
sistema GNU/Linux originale, è necessario accedere alla partizione con SL4 e copiare
i contenuti di /dev nella partizione con SL4:
# mount /dev/sdb1 /mnt/test
# cp -a /dev/* /mnt/test/dev/
È anche necessario disattivare udev perché una volta virtualizzata, la macchina non
dovrà accedere a nessun device, perché tale gestione verrà effettuata dal dom0:
# mv /mnt/test/sbin/start_udev /mnt/test/sbin/start_udev.no
A.4.2 Compilazione del kernel 2.6.16-xen
È necessario fare una compilazione del kernel 2.6.16-xen per la nuova macchina virtuale:
# cd /usr/src/linux-2.6.16-xen
# make menuconfig
# make
A.4. CREAZIONE DI UNA VM SL4
51
# cp vmlinuz /boot/kernel-2.6.16-xenU
# cp .config /boot/config-2.6.16-xenU
A.4.3 Creazione e prova delle macchine virtuali
Per testare il funzionamento del nuovo kernel si deve creare un file di configurazione,
ad esempio test.cfg:
kernel = "/boot/kernel-2.6.12.6-xenU.64"
memory = 512
name = "xen-test"
disk = [’phys:/dev/sdb1,sda1,w’]
root = "/dev/sda1 ro"
vif = [’mac=00:00:00:00:02:07’]
dhcp ="dhcp"
Inoltre il server DHCP deve essere configurato per assegnare un indirizzo IP alla macchina virtuale. A questo punto la VM potrebbe essere lanciata:
# xm create -c test.cfg
Se non ci sono errori, l’immagine creata è pronta per essere usata. Bisogna solamente
copiare il nuovo kernel funzionante in /boot/ nella macchina virtuale e creare un file
di configurazione di grub valido in /boot/grub.conf per usare pygrub invece
di avere un kernel esterno alla macchina virtuale. Sarebbe opportuno a questo punto
effettuare un aggiornamento di tutti i pacchetti e l’installazione del gcc.
52
Appendice B
Uso di block device via rete
I block device via rete permettono l’esportazioni di device attraverso una rete Ethernet.
In questa appendice si afronterà l’installazione delle due soluzione utilizzati nella tesi:
iSCSI e GNBD.
B.1 iSCSI
B.1.1 Introduzione
iSCSI ha una struttura di tipo client-server. Il client viene chiamato initiator ed è quello
che comincia una petizione di una risorsa– mentre il server viene chiamato target.
B.1.2 Installazione di un target
B.1.2.1 Installazione
L’implementazione utilizata viene chiamata “The iSCSI Enterprise Target” http:
//iscsitarget.sourceforge.net. Una volta scaricati i sorgenti si possono
compilare e installare tramite i comandi:
# make KERNELSRC=/usr/src/linux
# make KERNELSRC=/usr/src/linux install
dove linux è un link simbolico che punta al kernel sul quale si vuole compilare iSCSI.
B.1.2.2 Configurazione
La configurazione avviene tramite il file /etc/ietd.conf che ha una o più delle
seguenti strutture:
Target iqn.1997-01.it.infn:pg.na48fs3.xentest206
# Lun definition
53
54
APPENDICE B. USO DI BLOCK DEVICE VIA RETE
Lun 0 Path=/data16/images/206.img,Type=fileio
Alias˜xentest206
In questa configurazione si definisce un dispositivo da essere esportato tramite l’iSCSI
iqn.1997-01.it.infn:pg.na48fs3.xentest206. Il block device esportato sarà un file (con una immagine all’interno) chiamato /data16/images/206.img.
Per maggiori informazioni sulla configurazione e la definizione di block device da
esportare, si può guardare la bibliografia [11].
B.1.2.3 Lanciare il servizio
Per lanciare il servizio si deve eseguire il comando:
/etc/init.d/iscsi-target start
B.1.3 Installazione di un initiator
Per l’installazione di un initiator sono necessari due paccheti: core-icsi-tools http://
www.kernel.org/pub/linux/utils/storage/iscsi/ e core-iscsi http:
//www.kernel.org/pub/linux/kernel/people/nab/iscsi-initiator-core/
di cui uno contiene il modulo per il kernel e l’altro i tools per utilizare iSCSI.
B.1.3.1 Installazione di core-iscsi
L’installazione viene effettuata tramite i comandi:
# make initiator KERNEL_DIR=/usr/src/linux
# make install
dove linux è un link simbolico che punta al kernel sul quale si vuole compilare iSCSI.
B.1.3.2 Installazione di core-iscsi-tools
L’installazione viene effettuata tramite il comando:
# make install
B.1.3.3 Configurazione
Ci sono vari file di configurazione, ma ci limiteremo a parlare di quelli necessari per
portare avanti la configurazione anteriormente mostrata. Per maggiori informazioni si
faccia riferimento alla bibliografia [13].
/etc/initiatorname.iscsi Questo file conterrà l’iSCSI Qualified Name della macchina.
/etc/sysconfig/initiator In questo file ci sono i distinti target a cui la macchina si
collegherà. Seguendo la configurazione il target sarà (in una unica righa):
B.2. GNBD
55
CHANNEL="0 1 eth0 192.168.254.54 3260 0 AuthMethod=None;
MaxRecvDataSegmentLength=8192 nopout timeout=5
iqn.1997-01.it.infn:pg.na48fs3.xentest206"
B.1.3.4 Lanciare il servizio
Per utilizare i dispositivi tramite iSCSI rimane soltanto da eseguire il commando:
/etc/init.d/initiator start
Tramite il commando
/etc/init.d/initiator status
invece si ottengono informazioni dai dispositivi:
# /etc/init.d/initiator status
----------[iSCSI Session Info for iSCSI Channel 0]----------TargetName: iqn.1997-01.it.infn:pg.na48fs3.xentest206
TargetAlias:
PyX Session ID: 9 ISID: 0x80 33 94 32 00 00 TSIH: 4864
Cmds in Session Pool: 32 Session State: INIT SESS LOGGED IN
-----------[iSCSI Session Values]-----------CmdSN : ExpCmdSN : MaxCmdSN : ITT : TTT
0x00098669 0x00098669 0x00098689 0x000a8b7e 0x0006dd91
------------[iSCSI Connections]-------------CID: 0 Connection State: INIT CONN LOGGED IN
Address 192.168.254.54:3260,1 TCP ExpStatSN: 0x000a8b7d
-------------[SCSI Info for iSCSI Channel 0]------------SCSI Host No: 8 SCSI-II Host TCQ Count: 128
Logical Unit TCQ Depth: 64 SGTableSize: 32 MaxSectors: 256
iSCSI Logical Unit Number: 0 Status: ONLINE -> READ/WRITE
DISK: sdd
SCSI BUS Location: 0/0/0 Sector Size: 512
Active Tasks: 11 Total Tasks: 1311950 Total Bytes: 69679982272k
B.2 GNBD
B.2.1 Introduzione
GNBD è suddiviso in due componenti, una parte server che si occupa dell’esportazione
dei device locali ed una parte client che si occupa di importare i device da una specifica
macchina.
B.2.2 Installazione di GNBD
GNBD fa parte di una suite più grande di software RedHat, denominata cluster. Per
l’installazione si devono scaricare i sorgenti da ftp://sources.redhat.com/
pub/cluster/releases ed in seguito compilarli attraverso i comandi:
56
APPENDICE B. USO DI BLOCK DEVICE VIA RETE
# ./configure --kernel_src=/usr/src/linux
# make install
dove linux è un link simbolico che punta al kernel sul quale si vuole compilare GNBD.
B.2.3 Esportazione e Importazione
Sulla macchina server una volta compilato GNBD bisogna far partire il demone di
servizio con il comando
# gnbd_serv
ed esportare con l’istruzione:
# gnbd_export -c -e <nome_univoco_device> -d <nome_block_device>
che ovviamente si può utilizare più volte per esportare più di un device.
Per quanto riguarda le macchine client bisogna prima caricare il modulo del kernel
con il comando
# modprobe gnbd
e poi importare con
# gnbd_import -i <server_gnbd>
Una volta effettuato il comando, i devices importati saranno disponibili in /dev/gnbd/.
Appendice C
Installazione e uso di Nagios e
Cfengine
C.1 Nagios
C.1.1 Installazione di Nagios e plugin
Si è installato Nagios 2.5 perché è l’ultima versione stabile al momento dello sviluppo
del prototipo. Per l’installazione è sufficiente scaricare i sorgenti e seguire le istruzioni
disponibili nella documentazione di Nagios [15].
# tar xvzf nagios-2.5.tar.gz
Una volta scompattati i sorgenti bisogna creare l’utente ed il gruppo per Nagios, aggiungendo inoltre al gruppo creato l’utente apache, che deve avere accesso all’interfaccia web del programma.
#
#
#
#
adduser nagios
/usr/sbin/groupadd nagcmd
/usr/sbin/usermod -G nagcmd apache
/usr/sbin/usermod -G nagcmd nagios
Successivamente si devono creare le directory che ospiteranno il programma e cambiare i permessi di quest’ultime.
# mkdir /usr/local/nagios /etc/nagios /var/nagios
# chown nagios.nagios /usr/local/nagios /etc/nagios /var/nagios
Eseguire il configure specificando le directory ed il gruppo
# ./configure --sysconfdir=/etc/nagios
--localstatedir=/var/nagios --with-command-group=nagcmd
57
58
APPENDICE C. INSTALLAZIONE E USO DI NAGIOS E CFENGINE
ed iniziare la compilazione
#
#
#
#
#
make
make
make
make
make
all
install
install-init
install-commandmode
install-config
Una volta compilato nagios non resta che installare i plugin che vanno scaricati a parte
all’indirizzo http://sourceforge.net/projects/nagiosplug/ e compilati.
# ./configure --sysconfdir=/etc/nagios
--localstatedir=/var/nagios
# make
# make install
C.1.2 Configurazione dell’interfaccia web
La configurazione dell’interfaccia web si basa sull’ipotesi che si utilizzi il web server
Apache, ed esso sia già installato e funzionante sulla macchina che ospita Nagios. Il
file di configurazione che si modificherà sarà /etc/httpd/conf/httpd.conf,
aggiungendo alla fine di esso le seguenti righe:
ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin
<Directory "/usr/local/nagios/sbin">
AllowOverride AuthConfig
Options ExecCGI
Order allow,deny
Allow from 192.168.0.0/24
</Directory>
Alias /nagios /usr/local/nagios/share
<Directory "/usr/local/nagios/share">
Options None
AllowOverride AuthConfig
Order allow,deny
Allow from 192.168.0.0/24
</Directory>
Nelle precedenti righe inoltre si definisce l’utilizzo di file locali per la verifica degli accessi. Quindi si creerà un file .htaccess all’interno della cartella /usr/local/nagios/sbin
e si aggiungeranno al file le seguenti righe:
C.1. NAGIOS
59
AuthName Nagios-Monitoring
AuthType Basic
AuthUserFile /etc/nagios/htpasswd
require valid-user
A questo punto Nagios permetterà solo ad alcuni utenti l’accesso alla cartella CGI, e
per creare tali utenti basta eseguire il comando:
# htpasswd2 -c htpasswd nagios
tramite il quale viene creato un primo utente e poi:
# htpasswd2 htpasswd utente
per creare tutti gli altri di cui abbiamo bisogno, senza il parametro -c che comporterebbe la ricreazione del file e la perdita delle informazioni in esso contenute.
C.1.3 Configurazione di Nagios
Durante l’installazione, attraverso l’esecuzione del comando install-config, si sono copiati nella cartella /etc/nagios diversi file di configurazione. Per favorire la pulizia del sistema si consiglia di creare un cartella /etc/nagios/sample nella quale
spostare tutti i file di esempio e seguentemente creare una cartella nella quale inserire
i veri e propri file di configurazione. Per far riconoscere questa cartella a Nagios, sarà
opportuno modificare il file di configurazione principale nagios.cfg, inserendo la
riga:
cfg_dir=/etc/nagios/nome_cartella_progetto
che nel nostro caso è stata chiamata xen. L’albero della cartella /etc/nagios
dovrebbe presentarsi ora in questa maniera:
|-- nagios
| |-- nagios.cfg
| |-- cgi.cfg
| |-- resource.cfg
| |-- htpasswd
| |-- xen
| | |-- file di configurazione
| |-- sample
| | |-- file di esempio (*-sample)
.. ..
Per permettere inoltre a Nagios la gestione italiana delle date basta modificare il file
nagios.cfg da:
60
date format=us
a
date format=euro
Arrivati a questo punto non resta che creare i file di configurazione ed effettuare il
check per verificare eventuali problemi.
# /usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg
Nagios 2.5
Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
Last Modified: 07-13-2006
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 10 services.
Checking hosts...
Checked 5 hosts.
Checking host groups...
Checked 1 host groups.
Checking service groups...
Checked 0 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 20 commands.
Checking time periods...
Checked 1 time periods.
Checking extended host info definitions...
Checked 0 extended host info definitions.
Checking extended service info definitions...
Checked 0 extended service info definitions.
Checking for circular paths between hosts...
C.2. CFENGINE
61
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors:
0
Things look okay - No serious problems were detected during
the pre-flight check
Infine lanciare il demone di Nagios.
# /etc/init.d/nagios start
C.2 Cfengine
C.2.1 Installazione di Cfengine
Si è installato Cfengine 2.1.21 perché è l’ultima versione stabile al momento dello
sviluppo del prototipo. Per l’installazione è sufficiente scaricare i sorgenti e compilarli
[16].
# ./configure
# make
# make install
C.2.2 Configurazione di Cfengine
Cfengine gestisce i file di configurazione nella cartella /var/cfengine/inputs.
Di seguito verra creata una configurazione per testare il funzionamento di Cfengine in
locale creando nell’host, nel quale vogliamo riattivare un servizio, i seguenti file:
# -- /var/cfengine/inputs/cfagent.conf
control:
actionsequence = ( processes )
smtpserver = ( localhost ) # usato da cfexecd
sysadm = ( root@localhost ) # dove inviare output
processes:
"ssh" restart "/usr/sbin/ssh" useshell=false # riattivare il servizio
# -- /var/cfengine/inputs/cfservd.conf
control:
cfrunCommand = ( "/var/cfengine/bin/cfagent" )
62
AllowUsers = ( root )
admit:
/var/cfengine/bin/cfagent 127.0.0.1
# -- /var/cfengine/inputs/cfrunhosts.conf
sshserver
Per assicurarsi che Cfengine riesca ad effettuare il parsing dei file, lanciare il
comando:
# /usr/sbin/cfagent -qIv
ed infine testare il funzionamento attraverso la riattivazione del demone ssh:
# killall ssh;/usr/sbin/cfagent -qI
Una volta completata l’installazione si possono attivare tutti i servizi di Cfengine.
# for i in cfenvd cfservd cfexecd; do
chkconfig $i on; service $i restart;done
C.3 Integrazione fra Nagios e Cfengine
Di seguito si spiegherà come far interagire i due programmi in modo che alla rilevazione di un problema su di un servizio, Nagios attivi uno script che in caso di errore
critico invochi Cfengine nell’host remoto, riattivando il servizio. I file che di seguito
mostreremo sono quelli della configurazione di Nagios opportunamente modificati per
invocare Cfengine. Come descritto precedentemente, questi file devono trovarsi nella
cartella creata dall’utente, nel nostro caso /etc/nagios/xen.
Lo script handle cfrun viene attivato quando si rilevano problemi riguardanti
il servizio ssh e solo in caso di uno stato critico viene eseguita la chiamata a cfrun.
# -- /etc/nagios/xen/handle_cfrun.sh
#!/bin/sh
# $1 = status, $2 = status type, $3 = hostname, $4 = attempt
HOME=/usr/local/nagios
export HOME
HOST=‘echo $3 | cut -f1 -d.‘
cd /etc/nagios/xen
echo "/usr/sbin/cfrun -f $HOME/cfrun.hosts -T $HOST" > 1.txt
case "$1" in
OK)
;;
WARNING)
C.3. INTEGRAZIONE FRA NAGIOS E CFENGINE
63
;;
CRITICAL)
if [ $2 == "HARD" ] || [[ $2 == "SOFT" && $4 -eq 3 ]]; then
/usr/sbin/cfrun -f $HOME/cfrun.hosts -T $HOST
fi
;;
UNKNOWN)
;;
esac
exit 0
Il file services.cfg rappresenta i servizi monitorati da Nagios e come si può notare, il servizio ssh ha attivo un event handler che richiama in caso di problemi il
comando handle cfrun che mappa attraverso il file checkcommands.cfg lo script
precedentemente descritto.
# -- /etc/nagios/xen/services.cfg
define service{
hostgroups
xentest
service_description
PING
check_command
check_ping!100.0,20%!500.0,60%
max_check_attempts
3
normal_check_interval
5
retry_check_interval
1
check_period
24x7
notification_interval
120
notification_period
24x7
notification_options
w,u,c,r,f
contact_groups
localadmins
}
define service{
hostgroups
service_description
check_command
max_check_attempts
normal_check_interval
retry_check_interval
check_period
notification_period
contact_groups
event_handler_enabled
xentest
SSH
check_ssh
3
1
1
24x7
120
24x7
w,u,c,r,f
localadmins
1
64
event_handler
handle_cfrun
}
# -- /etc/nagios/xen/checkcommands.cfg
define command{
command_name
check_ssh
command_line
$USER1$/check_ssh -H $HOSTADDRESS$
}
define command{
command_name
command_line
handle_cfrun
/etc/nagios/xen/handle_cfrun.sh
$SERVICESTATE$ $SERVICESTATETYPE$
$HOSTNAME$ $SERVICEATTEMPT$
}
Infine descriviamo i restanti file di configurazione di Nagios:
# -- /etc/nagios/xen/hosts.cfg
define host{
host_name
hostgroups
address
max_check_attempts
check_period
contact_groups
notification_period
}
define host{
host_name
hostgroups
address
max_check_attempts
check_period
contact_groups
notification_period
}
define host{
host_name
hostgroups
xentest206
xentest
192.168.254.206
3
24x7
localadmins
120
24x7
d,u,r,f
xentest207
xentest
192.168.254.207
3
24x7
localadmins
120
24x7
d,u,r,f
xentest208
xentest
address
max_check_attempts
check_period
contact_groups
notification_period
192.168.254.208
3
24x7
localadmins
120
24x7
d,u,r,f
define host{
host_name
hostgroups
address
max_check_attempts
check_period
contact_groups
notification_period
}
xentest209
xentest
192.168.254.209
3
24x7
localadmins
120
24x7
d,u,r,f
define host{
host_name
hostgroups
address
max_check_attempts
check_period
contact_groups
notification_period
}
xentest210
xentest
192.168.254.210
3
24x7
localadmins
120
24x7
d,u,r,f
65
}
# -- /etc/nagios/xen/hostsgroups.cfg
define hostgroup{
hostgroup_name
xentest
alias
xentest
members
xentest206, xentest207, xentest208, xentest209,
}
# -- /etc/nagios/xen/contacs.cfg
define contact{
contact_name
nagios
66
alias
host_notification_period
service_notification_period
service_notification_options
host_notification_options
service_notification_commands
host_notification_commands
email
Nagios Admin
24x7
24x7
w,u,c,r
d,u,r
notify-by-email
host-notify-by-email
[email protected]
}
# -- /etc/nagios/xen/contacgroups.cfg
define contactgroup{
contactgroup_name
localadmins
alias
Local Site Administrator
members
nagios
}
# -- /etc/nagios/xen/timeperiods.cfg
define timeperiod{
timeperiod_name
24x7
alias
24 Hours A Day, 7 Days A Week
sunday
00:00-24:00
monday
00:00-24:00
tuesday
00:00-24:00
wednesday
00:00-24:00
thursday
00:00-24:00
friday
00:00-24:00
saturday
00:00-24:00
}
Una volta generati i file, non resta che configurare Cfegine nell’host remoto in maniera
da autorizzare Nagios ad eseguire cfrun dal server che effettua il monitoraggio. Il
modello di sicurezza di Cfegine è basato su di una chiave pubblica/privata alla quale
sono associati userid e host ip. Quindi per far funzionare il sistema bisogna creare una
chiave per Nagios e inserirla all’interno dell’host remoto da monitorare.
Per far ciò diveniamo l’utene Nagios ed eseguiamo cfkey:
# su - nagios
# cfkey
Questo ultimo comando si occuperà di creare le chiavi. In seguito copiamo il file
.pub della chiave appena creata nella cartella /var/cfengine/ppkeys nell’host
remoto. Il file inoltre dovrà avere un nome speciale rappresentato dal seguente pattern
username-ip.addr.pub
67
quindi modifichiamo il nome del file ed editiamo cfservd.conf aggiungendo la
direttiva che permette l’esecuzione all’utente nagios.
# -- /var/cfengine/inputs/cfservd.conf
control:
cfrunCommand = ( "/var/cfengine/bin/cfagent" )
AllowUsers = ( nagios root )
admit:
/var/cfengine/bin/cfagent 127.0.0.1 192.168.254.206
# ip del server di monitoraggio
Infine effettuiamo il test di funzionamento eseguendo il comando:
# cfrun -f ˜/cfrun.hosts sshserver
68
Bibliografia
[1] Popek, G.J., Goldberg, R.P. Formal requirements for virtualizable third generation
architectures. Communications of the ACM, Volume 17 - Issue 7 (Luglio 1974).
URL:
http://portal.acm.org/citation.cfm?doid=361011.
361073
[2] Smith, J., Ravi, N. Virtual Machines. Morgan Kaufmann (2005).
[3] Xen homepage.
URL:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
index.html
[4] SAN
URL: http://en.wikipedia.org/wiki/Storage area network
[5] SCSI
URL: http://en.wikipedia.org/wiki/SCSI
[6] Fibre Channel Overview
URL: http://hsi.web.cern.ch/HSI/fcs/spec/overview.htm
[7] GNBD Homepage
URL: http://sources.redhat.com/cluster/gnbd/
[8] IBM GPFS
URL:
http://www-03.ibm.com/servers/eserver/clusters/
software/gpfs.html
[9] Red Hat GFS
URL: http://www.redhat.com/software/rha/gfs/
[10] Satran, J., Meth, K. et al. RFC 3720: Internet Small Computer Systems Interface
(iSCSI). IETF (Aprile 2004).
URL: http://www.ietf.org/rfc/rfc3720.txt
[11] Rockwood, Ben. A Quick Guide to iSCSI on Linux. (Agosto 2004).
URL: http://cuddletech.com/articles/iscsi/iscsiref.pdf
69
70
BIBLIOGRAFIA
[12] core-iSCSI homepage.
URL:
ttp://www.kernel.org/pub/linux/utils/storage/
iscsi/
[13] core-iSCSI HOWTO.
URL:
http://www.kernel.org/pub/linux/utils/storage/
iscsi/HOWTO
[14] The iSCSI Enterprise Target homepage.
URL: http://iscsitarget.sourceforge.
[15] Nagios homepage
URL: http://www.nagios.org/
[16] Cfengine homepage
URL: http://www.cfengine.org/
[17] XenEnterprise Homepage
URL: http://www.xensource.com/products/xen enterprise/
[18] OpenQRM Homepage
URL: http://www.openqrm.org/
[19] Virtual Iron Homepage
URL: http://www.virtualiron.com/

Disegno ed implementazione di una soluzione con macchine virtuali

Transcript

Documenti analoghi

Virtualizzazione e Sicurezza

Nagios - Ninux

Corso Nagios - Linuxservizi

Aprire le nuove funzionalità in formato pdf

KPX129 - Power Bike Descrizione del prodotto Informazione di

COR35441 - Spacenet pentagonale piccola, rossa Descrizione del