disegno ed implementazione di una soluzione con macchine ... universit`a degli studi di perugia...

Universita degli Studi di Perugia

Facolta di Scienze Matematiche, Fisiche e NaturaliCorso di Laurea in Informatica

Tesi di Laurea

Disegno ed implementazione di unasoluzione con macchine virtuali (XEN)

per garantire servizi

Candidato

Ivan Grasso

Relatore CorrelatoreProf. Leonello Servoli Mirko Mariotti

Anno Accademico 2005-2006

Indice

1 Alta Disponibilita e Virtualizzazione 31.1 Cos’e l’Alta disponibilita . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Alta disponibilita tramite backups . . . . . . . . . . . . . . . 31.1.2 Alta disponibilita tramite ridondanza fisica . . . . . . . . . . 31.1.3 Alta disponibilita tramite virtualizzazione . . . . . . . . . . . 4

1.2 Cos’e la virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Teoria di Popek e Goldberg . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Insiemi di istruzioni . . . . . . . . . . . . . . . . . . . . . . 51.3.2 Teoremi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.3 Effetti della teoria di Popek e Goldberg . . . . . . . . . . . . 6

1.4 Tipi di virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.1 Emulazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.2 Virtualizzazione . . . . . . . . . . . . . . . . . . . . . . . . 61.4.3 Virtualizzazione a livello di SO . . . . . . . . . . . . . . . . 71.4.4 Paravirtualizzazione . . . . . . . . . . . . . . . . . . . . . . 7

1.5 Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5.1 Cos’e Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5.2 Paravirtualizzazione in Xen . . . . . . . . . . . . . . . . . . 81.5.3 Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . 91.5.4 I daemon di Xen . . . . . . . . . . . . . . . . . . . . . . . . 101.5.5 Caratteristiche di Xen . . . . . . . . . . . . . . . . . . . . . 11

1.6 Vantaggi della virtualizzazione . . . . . . . . . . . . . . . . . . . . . 11

2 Il prototipo: analisi delle possibilita e test dei componenti 132.1 Prototipo di architettura . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Soluzioni distinte per lo storage . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Block device remoti via hardware . . . . . . . . . . . . . . . 152.2.2 Block device remoti via software . . . . . . . . . . . . . . . . 152.2.3 Filesystem distribuiti . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Test delle componenti . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.1 Test di compatibilita . . . . . . . . . . . . . . . . . . . . . . 18

I

II INDICE

2.3.2 Test di I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Il prototipo: il sistema di Healthcheck e l’implementazione 333.1 Sistema di Healthcheck . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Analisi delle problematiche . . . . . . . . . . . . . . . . . . . . . . . 333.3 Analisi dei software . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 XenEnterprise . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.2 OpenQRM . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.3 Enomalism . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.4 Virtual Iron . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.5 Nagios e Cfengine . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Il prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.1 Schema Logico . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.2 Implementazione Fisica . . . . . . . . . . . . . . . . . . . . 40

4 Prospettive future 434.1 Virtualizzazione Hardware x86 . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2 Memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.3 Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.4 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A Installazione e uso di Xen 47A.1 Installazione di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 Configurazione di Xen . . . . . . . . . . . . . . . . . . . . . . . . . 47

A.2.1 Configurazione di xend . . . . . . . . . . . . . . . . . . . . . 47A.2.2 Configurazione dei macchine virtuali . . . . . . . . . . . . . 48A.2.3 pyGRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.3 Uso di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.3.1 Lanciare Xen . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.3.2 Il tool xm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A.4 Creazione di una VM SL4 . . . . . . . . . . . . . . . . . . . . . . . 50A.4.1 Installazione di SL4 . . . . . . . . . . . . . . . . . . . . . . 50A.4.2 Compilazione del kernel 2.6.16-xen . . . . . . . . . . . . . . 50A.4.3 Creazione e prova delle macchine virtuali . . . . . . . . . . . 51

B Uso di block device via rete 53B.1 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

B.1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.1.2 Installazione di un target . . . . . . . . . . . . . . . . . . . . 53B.1.3 Installazione di un initiator . . . . . . . . . . . . . . . . . . . 54

B.2 GNBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . 55

INDICE III

B.2.2 Installazione di GNBD . . . . . . . . . . . . . . . . . . . . . 55B.2.3 Esportazione e Importazione . . . . . . . . . . . . . . . . . . 56

C Installazione e uso di Nagios e Cfengine 57C.1 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

C.1.1 Installazione di Nagios e plugin . . . . . . . . . . . . . . . . 57C.1.2 Configurazione dell’interfaccia web . . . . . . . . . . . . . . 58C.1.3 Configurazione di Nagios . . . . . . . . . . . . . . . . . . . 59

C.2 Cfengine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.2.1 Installazione di Cfengine . . . . . . . . . . . . . . . . . . . . 61C.2.2 Configurazione di Cfengine . . . . . . . . . . . . . . . . . . 61

C.3 Integrazione fra Nagios e Cfengine . . . . . . . . . . . . . . . . . . . 62

IV INDICE

Elenco delle figure

1.1 Confronto del rendimento tra vari metodi di virtualizzazione . . . . . 81.2 Livelli di privilegi di un sistema operativo senza (sinistra) e con Xen

(destra) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Architettura di Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4 Ripristino di due servizi virtualizzati . . . . . . . . . . . . . . . . . . 12

2.1 Prototipo di architettura di un sistema ad alta disponibilita tramite Xen. 142.2 Le topologie FC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Architettura di iSCSI. . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Schema di filesystem distribuiti. . . . . . . . . . . . . . . . . . . . . 172.5 Esempio di risultato di un test con IOzone. . . . . . . . . . . . . . . 202.6 Test di lettura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Test di scrittura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . 212.8 Test di lettura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 222.9 Test di scrittura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . 222.10 Test di lettura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 232.11 Test di scrittura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . 232.12 Test di lettura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 242.13 Test di scrittura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . 242.14 Test di lettura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 252.15 Test di scrittura a 64 bit. . . . . . . . . . . . . . . . . . . . . . . . . 252.16 Test di lettura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . . 262.17 Test di scrittura a 32 bit. . . . . . . . . . . . . . . . . . . . . . . . . 262.18 Confronto 2D risultati scrittura a 32 bit. . . . . . . . . . . . . . . . . 272.19 Confronto 3D risultati scrittura a 32 bit. . . . . . . . . . . . . . . . . 282.20 Confronto 2D risultati lettura a 32 bit. . . . . . . . . . . . . . . . . . 282.21 Confronto 3D risultati lettura a 32 bit. . . . . . . . . . . . . . . . . . 292.22 Confronto 2D risultati scrittura a 64 bit. . . . . . . . . . . . . . . . . 292.23 Confronto 3D risultati scrittura a 64 bit. . . . . . . . . . . . . . . . . 302.24 Confronto 2D risultati lettura a 64 bit. . . . . . . . . . . . . . . . . . 302.25 Confronto 3D risultati lettura a 64 bit. . . . . . . . . . . . . . . . . . 31

V

VI ELENCO DELLE FIGURE

3.1 Schermata XenEnterprise . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Schermata OpenQRM . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3 Schermata Enomalism . . . . . . . . . . . . . . . . . . . . . . . . . 373.4 Schermata Virtual Iron . . . . . . . . . . . . . . . . . . . . . . . . . 373.5 Schema del prototipo. . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.1 Menu di pyGRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Introduzione

Introduzione generale

L’alta disponibilita e diventata al giorno d’oggi una delle caratteristiche fondamentalidi qualunque sistema di elaborazione orientato all’erogazione di servizi. Soprattuttoin alcuni ambiti specifici non e ammissibile la perdita di dati o l’impossibilita di usu-fruire 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 permessoscendere se si vuol mantenere un buon funzionamento. Per favorire questa politica,negli ultimi anni, sono state sviluppate notevolmente le tecniche di virtualizzazione deisistemi operativi, che garantiscono un rendimento di un processo al loro interno, prati-camente identico rispetto a quello nel sistema nativo. L’utilizzo di queste tecniche puoapportare grandi vantaggi nella progettazione ed implementazione di una soluzione adAlta 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 virtua-lizzazione, il loro funzionamento e le distinte soluzioni disponibili per imple-mentarle.

Capitolo 2 in questo capitolo viene proposto il prototipo concettuale per realizzarel’alta disponibilita mediante l’uso della virtualizzazione; inoltre vengono pre-sentati i test fatti sulle differenti soluzioni disponibili.

Capitolo 3 in questo capitolo viene definita ed implementata una prima versione delprototipo proposto nel capitolo precedente e tratte alcune cloncusioni.

Capitolo 4 in questo capitolo vengono descritte le possibilita che il futuro offre nel-l’ambito della virtualizzazione.

1

2 ELENCO DELLE FIGURE

Appendice A appendice nella quale viene descritta l’installazione e l’uso di Xen 3.0.2e la creazione di distinte immagini minimali funzionanti di Scientific Linux.

Appendice B appendice nella quale si spiega come installare e configurare i distintidispositivi di storage utilizati nei test.

Appendice C appendice nella quale si spiega come installare e configurare i program-mi Nagios e Cfengine utilizzati nel prototipo.

Capitolo 1

Alta Disponibilita eVirtualizzazione

1.1 Cos’e l’Alta disponibilita

Alta disponibilita e il termine usato per descrivere i sistemi di computer che sono staticonfigurati in modo da ridurre al minimo la percentuale di tempo in cui saranno inattivio non disponibili e, di conseguenza, consentirne il piu alto grado di utilizzo. L’altadisponibilita del sistema si ottiene riducendo la probabilita che un guasto hardware oun difetto software abbiano come conseguenza la perdita dell’uso del sistema o unaperdita dei suoi dati.

1.1.1 Alta disponibilita tramite backups

Una possibile soluzione, ma anche la piu semplice, e quella di gestire un sistema distorage in cui memorizzare i backup delle macchine, in maniera da essere pronti alsuccessivo ripristino in caso di guasti. Questa soluzione non e affatto ottimale in quantorichiede personale disponibile ad ogni ora per la riattivazione di servizi e potrebbeportare ad un tempo di ripristino troppo lungo, non piu accettabile, se il problema fossedella macchina che ospita i servizi stessi.

Inoltre in questo tipo di soluzione bisogna trovare un compromesso fra la frequenzadi backup (maggiore e il numero di backup, minore e il rendimento) e le performan-ce dei sistemi che si vogliono rendere affidabili (minore numero di backup, minoreaffidabilita).

1.1.2 Alta disponibilita tramite ridondanza fisica

Una seconda soluzione e quella di avere macchine fisiche in ridondanza, mantenendoun 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 diripresa del servizio piu basso. Lo svantaggio di questa scelta sta nella difficile gestionedelle copie in caso di grandi strutture dotate di tante macchine, oltre che ad un elevatocosto 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’usodi Virtual Machine multiple per il disaccoppiamento dei servizi dalla macchina. Inquesto modo, utilizzando una struttura di macchine virtuali ed un sistema automatico dimonitoraggio, 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’ope-razione quasi istantanea.

– Se si riscontrano problemi in una macchina fisica si puo migrare la virtualeprima che la macchina fallisca, con un downtime pari a zero.

• Permettere facilmente lo sviluppo ed il test di nuove versioni, isolandone l’ese-cuzione.

• Rendere indipendenti dall’hardware sottostante i servizi e l’installazione, defi-nendo 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 diuna risorsa normalmente fornita fisicamente e appartenente a un sistema. Tra gli impie-ghi della virtualizzazione il piu utilizzato e probabilmente la virtualizzazione di sistemioperativi ottenuta attraverso software specifici che riescono a creare ambienti distin-ti in un’unica macchina fisica, in maniera da permettere l’esecuzione di un sistemaoperativo in ognuno di questi ambienti.

Emulazione Virtualizzazione Virtualizzazione a livello di SO ParavirtualizazzioneBochs VMware OpenVZ Virtual IronQemu Plex86 Linux-VServer User-mode Linux

VirtualPC Microsoft Virtual PC FreeVPS L4DOSEMU Microsoft Virtual Server SWsoft Virtuozzo Xen

... ... ... ...

Tabella 1.1: Tipi di virtualizzazione.

Il componente fondamentale di un sistema basato su macchine virtuali e il Vir-tual 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’architettureinterrompendo 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 essereefficientemente virtualizzata. Fu introdotta da Popek e Goldberg nel 1974 nell’articolo“Formal Requirements for Virtualizable Third Generation Architectures“ 1 [1]. Unsistema di virtualizzazione deve:

• Essere equivalente, ossia un programma in esecuzione su di una macchina vir-tuale deve presentare lo stesso comportamento di quando e in esecuzione su diuna 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 delleistruzioni in tre diversi gruppi:

Privileged sono quelle che possono interrompere l’esecuzione del processore se e inmodalita utente (user-space) e non se e in modalita sistema (kernel-space).

Control sensitive sono quelle che tentano di cambiare la configurazione delle risorsenel sistema.

Behavior sensitive sono quelle il cui comportamento, oppure il cui risultato, dipendedalla 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 esseresempre costruito se qualsiasi insieme di istruzioni sensitive e un sotto-insieme delleistruzioni privileged.

1Requisiti formali per architetture di terza generazione virtualizzabili.


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 tempo-rali.

1.3.3 Effetti della teoria di Popek e Goldberg

In accordo ai due teoremi si hanno architetture come la System/370 che sono virtua-lizzabili perche hanno tutte istruzioni privilegiate ed altre, come la nota x86, che nonsoddisfano 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, per-mettendo l’esecuzione di un qualsiasi programma, compreso un sistema operativo.Questo permette per esempio all’interno di una particolare architettura, di far eseguireprogrammi 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 ilsoftware o l’hardware.

Virtualizzazione software (x86)

Nella virtualizzazione software si simula una parte dell’hardware ed e dunque pos-sibile eseguire un sistema operativo senza modifiche a patto che esso abbia la stessaarchitettura del sistema ospite. L’implementazione della virtualizzazione software perx86, come abbiamo gia visto, non e ottima perche questa architettura non soddisfa irequisiti della Teoria di Popek e Goldberg per virtualizzazione (1.3), e quindi avra unrendimento abbastanza penalizzato.

1.5. XEN 7

Virtualizzazione hardware

Al giorno d’oggi i due principali produttori di chip, Intel e AMD, hanno propostole proprie tecnologie di virtualizzazione hardware, rispettivamente VT e Pacifica, chediminuiscono, in termini di efficienza, il costo della virtualizzazione dell’architetturax86.

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 virtualizzazioneha un basso overhead che massimizza l’uso delle risorse del server ma ha anche ildifetto 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 compitodell’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 approccioutilizzato. In questo caso il software di paravirtualizzazione agisce direttamente sul-l’hardware in modo da gestire la condivisione delle risorse destinate alle varie virtualmachine. A questo punto pero il sistema operativo ospite dovra essere modificato perinteragire con l’hypervisor.

Questa implementazione ha due caratteristiche fondamentali ed interessanti rispettoalle altre soluzioni:

• L’hypervisor diventa molto piu semplice.

• Le macchine virtuali che girano su questo sistema hanno un rendimento maggio-re.

In questo gruppo ci sono varie soluzioni, e di seguito analizzeremo Xen che risultaessere la piu interessante per questo lavoro di tesi.

1.5 Xen

In questa sezione si effettuera una panoramica sulle caratteristiche e l’architettura dixen 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)“perl’architettura x86 in grado di asssicurare su di una singola macchina fisica l’esecuzionedi molteplici macchine virtuali, mantenendo una performance molto vicina a quella


nativa. Xen e nato all’inizio come un progetto di ricerca dell’Universita di Cambridgee la sua prima versione venne pubblicata nel 2003. Al giorno d’oggi esistono dueversioni con notevoli differenze e incompatibilita tra loro: Xen 2.0 e Xen 3.0. Laversione 2.0 non sara piu sviluppata e quindi la versione su cui si sta lavorando e allaquale 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 efficientee sicura tra le tecniche di virtualizzazione. Con essa Xen riesce a mantenere l’overheadal di sotto del 5% rispetto alle altre tecniche che di norma lo portano sopra il 30% (vediFigura 1.1 a pagina 8). Per far cio Xen introduce modifiche sia nelle macchine hostche nelle macchine guest. La macchina in cui verra fatta la virtualizzazione (cioe, lamacchina host) non sara piu una macchina x86, ma diventera una macchina con archi-tettura Xen-x86 e i sistemi operativi che si vorranno virtualizzare dovranno adattarsi aquesta architettura.

E per questo che non tutti i sistemi operativi sono supportati per la virtualizzazionetramite Xen o possono eseguirlo come hypervisor. La Tabella 1.2 a pagina 9 mostra isistemi operativi compatibili con Xen 3.0 in questo momento.

In questa tesi, si parlera di Xen utilizzando sempre come host un kernel Linux dellaserie 2.6.

1.5. XEN 9

Sistema operativo Host GuestLinux 2.6 Si Si

NetBSD 3.0 No In alto grado di sviluppoFreeBSD 5.3 No In alto grado di sviluppo

Plan9 No In sviluppoReactOS No Proggettato.

S.O. senza modifiche No 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 (vediFigura 1.2 a pagina 9). Questi livelli 2 sono numerati da 0 a 3 dove lo 0 rappresenta illivello con piu privilegi.

ring-0

XEN

ring-1

dom-0dom-U

ring-1

ring-3

aplicazioni utente

ring-0

SO

ring-1

ring-1

ring-3

aplicazioni utente

Sistema operativo senza Xen 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’unicodove 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 laseguente struttura:

ring-0 Livello dove si esegue l’hypervisor.

ring-1 Livello dove si eseguono i sistemi operativi ospite.

2chiamati col termine inglese: ring


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 eavviata nel ring-0 una prima macchina virtuale, in maniera totalmente trasparente al-l’utente (vedi Figura 1.3 a pagina 10). Questa, denominata VM0 oppure dom0, rappre-senta il sistema operativo su cui si e fatta l’installazione di Xen ed ha privilegi specialiper l’accesso all’hardware e per la gestione di tutte le altre macchine virtuali (deno-minate domU), contrariamente a tutte le altre macchine virtuali che possono accedereall’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’esecu-zione di un particolare programma python, denominato xend, all’interno del dom-0.Questo processo ha il compito di eseguire le richieste (creazione, distruzione, migra-zione..) che vengono effettuate tramite il comando xm (Si parlera del funzionamentonell’ 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 memorizzarele informazioni delle varie macchine virtuali, sotto forma di albero, all’interno di undatabase condiviso tra i differenti dom-U. Attraverso questo Xen riuscira a controllarele 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 deter-minato) e dal sistema operativo installato sull’hardware.

• Isolare le macchine su cui sono in esecuzione i servizi, in modo che, per esem-pio, ogni utente disponga di una macchina completa per il suo uso (maggioresicurezza di fronte a intrusioni).

• Possibilita di clonare le macchine per fare test e aggiornamenti, senza compro-mettere la integrita della macchina originale, con la possibilita di tornare indietroin maniera controllata.

• Possibilita di scalabilita, entro certi limiti.

• Mettere in pausa le macchine con la possibilita di migrare una macchina virtualea un’altra macchina fisica e riprendere l’esecuzione nel punto di arresto. Questopermette:

– Load-balancing: si possono migrare macchine virtuali da un host con un al-to carico ad un host senza carico senza fermare le macchine (live-migration).

– Alta disponibilita: se una macchina fallisce si possono migrare le macchinevirtuali (prima che falliscano) o recuperare uno snapshot e farlo eseguiresu un’altra macchina host.


Fallimento di una macchina fisica.

Servizio 3 Servizio 4

Macchina fisica 2


Macchina fisica 1

Internet


Macchina fisica 3

Migrazione delle macchine virtuali.


Macchina fisica 2


Macchina fisica 1

Internet


Macchina fisica 3

Ritorno allo stato di normalita.


Macchina fisica 2


Macchina fisica 1

InternetServizio 5

Macchina fisica 3

Servizio 6

Figura 1.4: Ripristino di due servizi virtualizzati

Capitolo 2

Il prototipo: analisi dellepossibilita e test dei componenti

In questo capitolo verra proposto un modello prototipale di architettura di un sistemaad alta disponibilita ed in seguito la serie di test effettuati per la determinazione dellamigliore soluzione.

2.1 Prototipo di architettura

La struttura proposta e quella mostrata nella Figura 2.1 a pagina 14. Gli elementipresenti e le loro funzioni sono:

Macchine fisiche In questo modello le macchine fisiche presenti hanno soltanto lafunzione di ospitare una o piu macchine virtuali, eseguendo Xen. Per questonelle macchine si puo utilizzare qualsiasi sistema GNU/Linux compatibile con irequisiti di quest’ultimo.

Macchine virtuali Tutti i servizi che devono essere altamente disponibili devono es-sere virtualizzati.

Storage I filesystem su cui si eseguono le macchine virtuali. Le immagini dellemacchine 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 funzionamentodel 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, sonoindipendenti dall’hardware sottostante ottenendo il vantaggio di poter essere eseguitein 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 hostautomaticamente.

2.2 Soluzioni distinte per lo storage

Uno degli elementi fondamentali di questo prototipo e il sistema utilizzato per memo-rizzare e distribuire le immagini delle macchine virtuali, per questo, e necessario unostudio delle distinte tecnologie e soluzioni esistenti sul mercato per rendere possibilela 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 dispositivicollegati via rete. In particolare, sono quelli basati su un hardware dedicato, di solitocostoso, 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 sto-rage in rete. Fibre Channel diventa importante e fondamentale nell’ambito dei grandisupercomputer e in ambito aziendale. Ci sono diverse topologie (Figura 2.2 a pagina15):

Figura 2.2: Le topologie FC.

Switched Fabric Tutti i device sono collegati ai Fibre Channel switches (molto simileall’implementazione delle moderne Ethernet).

Point-to-point Due dispositivi sono collegati direttamente (soluzione semplice e limi-tata).

Arbitrated Loop Tutti i device sono collegati ad anello rendendo questa soluzione lapiu sensibile ai problemi.

A dispetto del suo nome, Fibre Channel puo essere implementato sia con cavi di fibraottica, 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 deiprimi non viene utilizzato un hardware specifico ma bensı un software speciale. Questesoluzioni sono una buona alternativa in quanto il prezzo della implementazione non ecosi elevato e le prestazioni sono abbastanza buone.

Le due soluzioni principali sono GNBD e iSCSI.


2.2.2.1 iSCSI

L’iSCSI1 e un protocollo definito nel Request For Comments (RFC) 3720 [10] dall’In-ternet Engineering Task Force 2 per utilizzare il protocollo Small Systems ComputerInterface (SCSI), usando come mezzo trasmissivo una rete TCP/IP. Vista la vasta dif-fusione delle reti TCP/IP e il continuo sviluppo della tecnologia Gigabit Ethernet 3 leSAN[4] 4 basate su iSCSI sono divenute una soluzione economica, ma non per questopoco efficiente.

iSCSI e basata su un’architettura (Figura 2.3 a pagina 16) client-server (quella diSCSI), dove il client e chiamato ”initiator” ed il server e chiamato ”target”. In unsistema iSCSI, un initiator fa richiesta di un servizio a un target utilizzando uno deiprotocolli 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 core-ISCSI http://www.kernel.org/pub/linux/utils/storage/iscsi/.

Target La implementazione su cui si sta lavorando di piu e The iSCSI EnterpriseTarget http://iscsitarget.sourceforge.net/.

1Internet Small Computer Systems Interface2http://www.ietf.org/3Tecnologia per implementare reti Ethernet a una velocita nominale di 1 Gigabit per secondo.4Storage 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) at-traverso una rete che di solito e Ethernet; e una tecnologia sviluppata da Red Hat peressere utilizzata originalmente con il Red Hat Global File System.

L’unica distribuzione esistente e quella della Red Hat, che e parte di una suite cono-sciuta 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 dicalcolatori. 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 parti-zione).

• 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 primainstallazione e stato usato Xen 3.0.1) su varie distribuzioni GNU/Linux come sistemahost, sempre utilizzando il kernel Linux 2.6.16-xen (nella installazione di Xen 3.0.1 sie 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’im-portante e stato leggere con attenzione i requisiti d’installazione richiesti da Xen econformarsi alle richieste).

Test di sistemi guest

I test di compatibilita effettuati per il sistema guest si sono svolti con la distribuzio-ne Scientific Linux (nelle versioni 3 e 4), utilizzando sempre il kernel modificato daXen (Linux 2.6.16-xen per la versione di Xen 3.0.2 e Linux 2.6.12.6-Xen per la ver-sione 3.0.1). Durante i test si e verificata l’indipendenza delle macchine virtuali dal-l’hardware sottostante. Si sono eseguite le varie macchine su hardware diverso senzanessun tipo di problema, con la sola accortezza di ricordarsi dell’incompatibilita fral’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 distintesoluzioni di storage disponibili e il kernel linux modificato da Xen, senza riscontrareproblemi.

2.3. TEST DELLE COMPONENTI 19

2.3.2 Test di I/O

Sono stati realizzati diversi test per verificare le prestazioni delle soluzioni mostratenella Sezione 2.2, sia in macchine a 32 bit che a 64 per scoprire la migliore soluzioneda implementare in seguito nel prototipo.

2.3.2.1 IOzone

IOzone 5 e uno strumento ampiamente utilizzato per fare prove comparative di rendi-mento 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 altocarico di lavoro. Durante le prove e stato possibile verificare la stabilita delle variesoluzioni di storage e di quelle di Xen, garantendo assenza di problemi anche in casodi 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 lecaratteristiche mostrate nella Tabella 2.1 a pagina 19, mentre le macchine virtuali cari-cate (2 per ogni macchina fisica) avevano una memoria RAM di 512 MB ed eseguivanouna Scientific Linux 4.2 con un Kernel 2.6.16-xen.

Processore Dual AMD Opteron 2GHzMemoria 1GB

Disco 40GBConessione Rete Gigabit Ethernet / Fibra ottica

Sistema Operativo 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 Dual Pentium III 1GHzMemoria 256MB

Disco 210GB - RAID 5Conessione Rete Gigabit Ethernet

Sistema Operativo 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 dellaTabella 2.3 a pagina 19.

Spazio disco 4797776,28MBConessione Rete Fibra Ottica

Tabella 2.3: Caratteristiche disco FC.5URL: 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 Figura2.5 a pagina 20 rappresenta un esempio di un test effettuato con IOzone. Con l’assedelle ascisse viene rappresentata la dimensione del file a cui IOzone ha accesso, mentrecon l’asse delle ordinate si rappresenta la velocita di accesso. Analizzando l’immaginesi 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, quandoil file e molto piccolo ed esiste l’influenza della cache della CPU.

• Zona media: Queste misure rappresentano il risultato quando si ha l’influenzadella cache del buffer.

• Zona bassa: Queste misure rappresentano i risultati reali di accesso al disco intotale 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 apagina 19, collegato alle due macchine fisiche prima descritte (tramite una connessionein fibra ottica a 2Gb/s).

I risultati ottenuti si possono osservare dalle Figure 2.6-2.9. Analizzando le imma-gini si nota un piccolo miglioramento nel rendimento (piu visibile nella Figura 2.6 apagina 21) per file di dimensioni sotto 1KB nell’uso di Fibre Channel con un sistemaoperativo a 64 bit, mentre nei restanti test il rendimento e circa lo stesso per tutte e duele architetture.


Figura 2.6: Test di lettura a 64 bit.

Figura 2.7: Test di scrittura a 64 bit.




GNBD

In questi test e stato utilizzato il fileserver descritto nella tabella 2.2 e le due macchinedescritte nella tabella 2.1. I risultati ottenuti si possono osservare dalle Figure 2.10-2.13.

Analizzando le immagini si puo osservare un comportamento anomalo derivato


probabilmente dall’esistenza di carico nella rete. Per esempio nella Figura 2.12 a pagi-na 24 si puo identificare nella zona alta e bassa una differenza di velocita molto soste-nuta che non dovrebbe sussistere. Inoltre, come nella soluzione Fibre Channel, si puoosservare un incremento del rendimento per file di piccole dimensioni nell’architetturaa 64 bit.






iSCSI

Per effettuare questi test si e utilizzato lo stesso fileserver dei test con GNBD, gia mo-strato precedentemente, utilizzando come initiator l’implementazione chiamata core-iSCSI [12] e come target nelle macchine fisiche The iSCSI Enterprise Target [14]. Irisultati ottenuti si possono osservare dalle Figure 2.14-2.17.


Analizzando le immagini si puo osservare lo stesso comportamento riscontrato neitest effettuati con GNBD, probabilmente dovuto alla connessione di rete. Inoltre sicontinua ad osservare l’aumento del rendimento nella architettura a 64 bit per file dipiccole dimensioni.






2.3.2.5 Confronto dei risultati

Nei confronti di seguito riportati e stata utilizzata solamente la porzione di dati di mag-gior interesse per il rendimento del sistema di storage, nel nostro caso, ossia si analiz-zano i tempi di lettura/scrittura solamente per file di dimensioni maggiori di 512 MB eminori di 2 GB. Nelle Figure 2.20, 2.18, 2.22 e 2.24 si e riportato il confronto tra i ri-


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 diuna terza dimensione rappresentata dal record.

Come si evince dalle figure, il rendimento del dispositivo Fibre Channel e superiorealle 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 utilizzatocome SAN.

Nonostante questi validi motivi il costo del dispositivo e abbastanza elevato (circa1000 euro per una scheda di interfaccia) ed implementare una soluzione basata su iSC-SI o GNBD e poco penalizzante in termini di prestazioni e molto vantaggiosa dal latoeconomico. Quindi nell’implementazione finale del prototipo si e scelto iSCSI che hadimostrato scalabilita, stabilita ed un rendimento sebbene non in maniera elevatissimamigliore di GNBD.

Figura 2.18: Confronto 2D risultati scrittura a 32 bit.



Figura 2.20: Confronto 2D risultati lettura a 32 bit.

Capitolo 3

Il prototipo: il sistema diHealthcheck el’implementazione

3.1 Sistema di Healthcheck

Con il termine Healtcheck si identifica un tipo di servizio svolto da un programma chesi occupa di analizzare lo stato di funzionamento delle macchine monitorate e agire diconseguenza.

Sostanzialmente l’healtcheck puo essere visto come un supervisore che all’insor-gere di problemi, li ripristina senza l’intervento umano. Nel nostro caso specifico, essosi occupera sia della riattivazione dei servizi, che della gestione di tutta l’architetturavirtuale.

3.2 Analisi delle problematiche

La realizzazione di una struttura completamente virtuale apporta notevoli vantaggi, sianella gestione delle macchine, che nella flessibilita dell’infrastruttura stessa. Tali van-taggi sono sostanzialmente dovuti alla possibilita di gestire virtualmente le macchine,attraverso migrazioni live, riavii e pause e alla possibilita in caso di necessita, di unfacile incremento o una riduzione del numero delle macchine.

Tutto cio pero, non elimina la problematica dell’intervento umano nel caso insor-gano problemi ai servizi o alle stesse macchine virtuali.

Al giorno d’oggi, esistono soluzioni di monitoring in grado di controllare macchineed inviare segnalazioni in caso di problemi, ma la soluzione che si vuole ottenere deveriuscire 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 soloin casi limite.

Inizialmente, dopo aver analizzato approfonditamente il problema, si e deciso discrivere un software per gestire l’intera infrastruttura. Il software e stato scritto inlinguaggio C ed e stato composto di due parti: una parte master, da installare nellamacchina che effettua il monitoring, ed una parte slave, da installare nelle macchine damonitorare. Semplicemente il software creato si e basato sull’interazione fra master eslave che attraverso messaggi di tipo UDP si comunicano informazioni riguardanti lostato delle macchine ed eseguono script.

Lo sviluppo di tale programma ci ha aiutato a capire maggiormente le problemati-che nella realizzazione di un software di tale genere. I maggiori problemi realizzativi sisono riscontrati nella creazione delle dipendenze fra macchine virtuali e fisiche, nellacreazione di script per il controllo di servizi ed infine nella gestione della migrazionedelle macchine.

Dopo aver intuito le difficolta, si e pensato di esplorare nuove possibilita, alla ri-cerca di una soluzione piu adeguata alle esigenze, concentrandosi maggiormente susoftware che implementino gestione di virtualizzazione o monitoring.

3.3 Analisi dei software

Come gia affermato precedentemente, la ricerca di possibili soluzioni ha portato ad unaserie di software, ognuno con delle caratteristiche specifiche, e di seguito ne analizze-remo 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 diXen, che include una serie di tool in grado di semplificare la gestione e la pubblicazionedi macchine virtuali.

XenEnterprise e in grado di permettere la gestione (creazione, pausa, migrazione,etc..) delle macchine virtuali attraverso una semplice interfaccia grafica molto espli-cativa. 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 inte-resse in quanto non si occupa della gestione di servizi, e almeno in apparenza, nondimostra un notevole sviluppo nella gestione delle macchine virtuali in caso di falli-mento.

Figura 3.1: Schermata XenEnterprise

3.3.2 OpenQRM

OpenQRM e una piattaforma di system management molto interessante in quanto haavuto 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 dicomponenti in ogni parte del sistema, inclusa l’interfaccia, l’agente di monitoraggio edil motore di decisione.

OpenQRM inoltre ha un’alta scalabilita e riesce a gestire molteplici server conreport dettagliati, attraverso una semplice interfaccia. Il sistema e dotato di supporto aserver 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 Xenattraverso 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’altrascelta.


Figura 3.2: Schermata OpenQRM

3.3.3 Enomalism

Enomalism e una applicazione web tramite la quale si puo gestire l’amministrazionedi macchine virtuali Xen. Si basa su di una interfaccia grafica che semplifica la com-plessa gestione di centinaia di macchine virtuali, permettendo inoltre l’integrazione diapplicazioni di terzi attraverso l’utilizzo di particolari API.

Dall’analisi effettuata, Enomalism risulta essere un progetto open source che nonha trovato grande appoggio e si ritrova ancora in una fase di beta. Anche se viene dettoche e in continuo sviluppo, non sono state rilasciate nuove versioni e l’implementazionefino ad ora creata non sembra essere la soluzione ideale per implementare il nostroprototipo.

3.3.4 Virtual Iron

Virtual Iron e una soluzione per la creazione e la gestione di infrastrutture virtuali chepermette un avanzata paravirtualizzazione dei server attraverso l’uso dell’hypervisor diXen. Virtual Iron e distribuito in 3 versioni: Professional, Consolidation ed Enterprisedi cui una e open source.

Il sistema supporta fino a 8 CPU, sistemi a 32 e 64 bit e permette il recupero senzaintervento umano delle macchine in caso di fallimento. Inoltre crea dettagliati reportsulle singole macchine virtuali riguardo l’utilizzo delle risorse di sistema in esecuzio-ne, e permette in casi di eccessivo utilizzo di una particolare macchina fisica, il LoadBalancing attraverso migrazione virtuale.

Virtual Iron e il software che si avvicina maggiormente alla nostre richieste, anchese 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 creazionedel prototipo il software ancora non e disponibile in nessuna delle versioni ma, cio nontoglie 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 am-biente Linux/Unix e gestisce sistemi di notificazione basati su mail, messaggistica eSMS, oltre a disporre di un’interfaccia web accessibile via browser.

Nagios non contiene funzioni per la gestione della rete ma solo per il monitoraggiodi apparecchiature (computer, switch, router,..) e servizi (HTTP, FTP, POP3,..) ed ecomposto da due parti fondamentali: il nucleo, che rappresenta la parte principale delprogramma e i plugin, che sono programmi esterni tramite i quali si possono effettuarei controlli.

Nella realizzazione del prototipo la scelta e ricaduta proprio su questo software e lemotivazione che ci hanno portato a tale decisione, possono essere in sostanza riassuntedalle sue ottime caratteristiche:

• Monitoraggio di servizi di rete (SMTP, POP3, HTTP, NNTP, ICMP, SNMP)

• Monitoraggio delle risorse hardware dei server (carico del processore, utilizzodei 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 laloro risoluzione.

• Produzione di log dettagliati sulle attivita svolte.

• Interfaccia web per la verifica dello stato corrente, delle notifiche e della crono-logia dei problemi.

Attraverso l’utilizzo di tale programma si e risolta la problematica del monitoraggiodell’intera infrastruttura, sia virtuale, che fisica ma non si e affrontata minimamente laproblematica della riattivazione di servizi e gestione delle macchine virtuali. Per farcio, si e affiancato a Nagios, un altro software denominato Cfengine.

Cfengine [16] e un sistema di amministrazione di elaboratori Unix, il cui scopoprincipale 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 scopoe analizzare un file di configurazione e confrontare lo stato attuale della macchina conquello 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 delleopportune 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 serverremoto, di file e directory.

• Aggiornamento, cancellazione o linking di file (caratteristica, questa, molto po-tente che offre l’uso di espressioni regolari e di funzioni di ricerca/sostituzionesu 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 servizinon piu funzionanti, se non fosse per il fatto che il confronto tra lo stato ideale dellamacchina e quello attuale risulta gravoso per il sistema e si esegue di norma una voltaogni ora. Questo e uno dei motivi fondamentali per il quale si e utilizzato un softwaredi monitoring esterno come Nagios, oltre ovviamente alla possibilita, di avere sempreun’idea generale su tutto il funzionamento dell’infrastruttura.

3.4 Il prototipo

Nella realizzazione specifica del prototipo, in questa tesi, ci si e occupati solamentedella parte riguardante la riattivazione di servizi in macchine virtuali e di seguito nedaremo 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 xente-st206, l’unica avente il compito di occuparsi del monitoraggio.

In generale, e stata fatta la scelta di monitorare solamente il funzionamento del ser-vizio ssh e della raggiungibilita delle macchine attraverso il ping. Questa ha portatoalla semplificazione del prototipo, ma non per questo ad una perdita di generalizza-zione, in quanto grazie all’alta scalabilita dei software utilizzati, il discorso puo essereampliato 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 ildemone sshd cessi il suo funzionamento.

Interessandoci specificatamente delle macchine, Cfegine si e installato su ognunadi esse. Il motivo fondamentale di questa scelta e derivato dal fatto che, il nodo chesi occupa di effettuare il monitoring, deve essere in grado di far eseguire, ad ogniistante, su ognuna di esse, il servizio integrato in Cfengine che confronta gli stati dellamacchina 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, riuscendocooperativamente 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 al-

lerta 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 Cfengi-

ne, 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 sta-bile, permettendo la riattivazione dei servizi monitorati in modo automatico dopo solipochi secondi. Questo ha dimostrato la bonta dei software open source utilizzati edinoltre grazie all’ampio lavoro di analisi e quindi a scelte oculate, si e data al gruppola possibilita di proseguire nel lavoro, attraverso l’implementazione dell’intera gestio-ne delle macchine virtuali, rendendo cosı il prototipo una potente soluzione per l’altaaffidabilita.

Capitolo 4

Prospettive future

4.1 Virtualizzazione Hardware x86

In questi ultimi mesi si e assistito ad un incremento esponenziale dell’interesse neiconfronti della virtualizzazione, tanto che essa sta divenendo un elemento essenzialenei piani di sviluppo degli stessi produttori di chip.

Attualmente, sia Intel che AMD, hanno sviluppato indipendentemente le esten-sioni di virtualizzazione dell’architettura x86 denominate Intel VT (abbreviazione diVirtualization Technology) e Pacifica (AMD Virtualization), e di seguito tenteremo didescriverne le caratteristiche fondamentali, effettuando un confronto tra le due possi-bilita.

4.1.1 Architettura

Per assistere la virtualizzazione, VT e Pacifica hanno introdotto un nuovo livello privi-legiato al di sotto del ring 0. Entrambe le soluzioni hanno aggiunto 9 nuove istruzioniche lavorano solamente nel livello denominato Ring -1, create appositamente per esse-se usate dell’hypervisor. Questo permette di eseguire sistemi guest senza modificarneil sistema operativo e riducendone il costo di emulazione. Ovviamente quest’ultimonon e eleminato del tutto in quanto ogni sistema operativo deve essere convinto che dasolo ha accesso alla memoria della macchina ed ai bus di I/O, mentre in realta e semprel’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 con-troller hardware di memoria, assegnavano la RAM fra le applicazioni. AMD presentaun vantaggio in questo ambito perche le sue CPU includono il controller di memoriache Pacifica puo semplicemente riutilizzare. In contrapposizione, le CPU Intel deman-dano 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 dellamemoria. Il controller di memoria Intel in futuro sara introdotto nella CPU e potraessere 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’hypervi-sor, che si occupa di presentare i driver virtuali ai sistemi operativi guest. Le futureversioni di Pacifica e VT elimineranno i driver dall’hypervisor, permettendo ai driverdei 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, chefortunatamente 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 pergli utenti che non vogliono utilizzare le nuove possibilita di virtualizzazione. Un attac-co ad un sistema che utilizza un unico sistema operativo non virtualizzato, non richie-derebbe nemmeno l’hacking dell’hypervisor, poiche l’attaccante potrebbe solamenteinserire un virus o un trojan nell’inutilizzato Ring -1.

Un virus nel Ring -1 sarebbe il rootkit definitivo, perche funzionerebbe al di sottodel sistema operativo e simulerebbe esattamente il chip x86, riuscendo ad attaccarepersino il software perfettamente sicuro. In piu esso sarebbe indipendente dal sistemaoperativo, riuscendo a compromettere qualsiasi sistema x86 e sarebbe praticamenteimpossibile da rilevare solamente con il software.

Per proteggersi da tale virus, il sistema ha bisogno di un componente hardware chenon puo essere virtualizzato. Questo sarebbe fornito dalla Trusted Platform Module(TPM), con il discutibile chip PKI gia incluso in molti computer. La TPM si occupe-rebbe di osservare l’hypervisor e i programmi che carica in memoria, facendo un checkcon dei valori hash precalcolati, in maniera da assicurare l’inalterazione dell’hypervi-sor e creando un certificato digitale che potra poi essere verificato dal sistema operativovirtualizzato e dai software di sicurezza.

E per questo che sia Intel che AMD stanno programmando di introdurre nel 2007le tecnologie conosciute rispettivamente come La Grande e Presidio, destinate allasicurezza delle imprese.

Ringraziamenti

Al Prof. Leonello Servoli per avermi dato la possibilita di approfondire un argomentodi tale interesse e per la Sua puntuale disponibilita. Ad Igor per l’aiuto tecnico agli inizie l’appoggio morale. A Mirko e Massimo per avermi dato la possibilita di apprendereparte delle loro ampie conoscenze. Ad Alvaro per avermi insegnato un po’ di parolespagnole 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 qualchemaniera mi hanno dato una mano a crescere. Infine ad Elena, che con pazienza, hasempre 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 dellosviluppo del prototipo. Per l’installazione e sufficiente seguire le istruzioni disponibilinella documentazione di Xen [3]. Bisogna pero fare attenzione ai prerequisiti che, senon soddisfatti, potrebbero far insorgere diversi problemi.

Al momento della scrittura della tesi, la versione di pygrub che viene distribuitacon Xen 3.0.2 e errata e bisogna installare quella distribuita con la versione non stabiledi 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 al-l’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 lamacchina, 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 per-mettere 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 = "/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"

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 quellofornito 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 specificarel’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 piut-tosto che un kernel esterno, si dovrebbe utilizzare pygrub, modificando nel file diconfigurazione i seguenti parametri:


per

bootloader = "/usr/bin/pygrub"

Nell’immagine dovra ovviamente esistere un file /boot/grub.conf contenenteuna configurazione valida per il kernel installato nella macchina. A questo punto, ogniqual volta si avvia la macchina virtuale comparira un menu in cui scegliere quale kernelutilizzare.

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 thecommands before booting, ’a’ to modify the kernel argumentsbefore 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 sem-plicemente del comando:

# xend start

A.3.2 Il tool xm

Xm e il tool presente in Xen per controllare le macchine virtuali. Xm puo essereutilizzato 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 confi-gurazione <config file>.

xm list Stampa a schermo la lista delle macchine virtuali attive nel seguente for-mato:

# xm list

Name ID Mem(MiB) VCPUs State Time(s)

xentest206 18 512 1 -b---- 343.5

xentest207 19 512 1 -b---- 363.1

Domain-0 0 485 2 r----- 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 attra-verso il comando xm list.


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>, sen-za 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 Xen3.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 accessibileda una macchina funzionante con GNU/Linux (/dev/sdb1). Per far cio, si so-no scelti solamente pacchetti indispensabili al funzionamento del sistema e della re-te, potendo successivamente ampliare l’installazione attraverso software come yum

o apt-get. E importante far notare come non si debba installare ne SE-Linux neGRUB (o LILO). Una volta finita l’installazione minimale e avviata la macchina con ilsistema GNU/Linux originale, e necessario accedere alla partizione con SL4 e copiarei 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 nondovra 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 vir-tuale:

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


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 mac-china 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 solamentecopiare il nuovo kernel funzionante in /boot/ nella macchina virtuale e creare un filedi configurazione di grub valido in /boot/grub.conf per usare pygrub invecedi avere un kernel esterno alla macchina virtuale. Sarebbe opportuno a questo puntoeffettuare un aggiornamento di tutti i pacchetti e l’installazione del gcc.

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 quelloche 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 possonocompilare 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 delleseguenti 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’iSCSIiqn.1997-01.it.infn:pg.na48fs3.xentest206. Il block device esporta-to sara un file (con una immagine all’interno) chiamato /data16/images/206.img.

Per maggiori informazioni sulla configurazione e la definizione di block device daesportare, 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 perportare avanti la configurazione anteriormente mostrata. Per maggiori informazioni sifaccia 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 sicolleghera. 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’esportazionedei device locali ed una parte client che si occupa di importare i device da una specificamacchina.

B.2.2 Installazione di GNBD

GNBD fa parte di una suite piu grande di software RedHat, denominata cluster. Perl’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 diservizio 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 eCfengine

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 sviluppodel prototipo. Per l’installazione e sufficiente scaricare i sorgenti e seguire le istruzionidisponibili 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, ag-giungendo inoltre al gruppo creato l’utente apache, che deve avere accesso all’interfac-cia 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 cambia-re 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 all

# make install

# make install-init

# make install-commandmode

# make install-config

Una volta compilato nagios non resta che installare i plugin che vanno scaricati a parteall’indirizzo http://sourceforge.net/projects/nagiosplug/ e com-pilati.

# ./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 serverApache, ed esso sia gia installato e funzionante sulla macchina che ospita Nagios. Ilfile 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 ac-cessi. Quindi si creera un file .htaccess all’interno della cartella /usr/local/nagios/sbine 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, eper 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 comportereb-be 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 co-piati nella cartella /etc/nagios diversi file di configurazione. Per favorire la puli-zia del sistema si consiglia di creare un cartella /etc/nagios/sample nella qualespostare tutti i file di esempio e seguentemente creare una cartella nella quale inserirei veri e propri file di configurazione. Per far riconoscere questa cartella a Nagios, saraopportuno modificare il file di configurazione principale nagios.cfg, inserendo lariga:

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 filenagios.cfg da:


date format=us

a

date format=euro

Arrivati a questo punto non resta che creare i file di configurazione ed effettuare ilcheck 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 dellosviluppo 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 inlocale 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 ssh

# -- /var/cfengine/inputs/cfservd.conf

control:

cfrunCommand = ( "/var/cfengine/bin/cfagent" )


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

# /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 rileva-zione di un problema su di un servizio, Nagios attivi uno script che in caso di errorecritico invochi Cfengine nell’host remoto, riattivando il servizio. I file che di seguitomostreremo sono quelli della configurazione di Nagios opportunamente modificati perinvocare Cfengine. Come descritto precedentemente, questi file devono trovarsi nellacartella creata dall’utente, nel nostro caso /etc/nagios/xen.

Lo script handle cfrun viene attivato quando si rilevano problemi riguardantiil 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 no-tare, il servizio ssh ha attivo un event handler che richiama in caso di problemi ilcomando handle cfrun che mappa attraverso il file checkcommands.cfg lo scriptprecedentemente 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 xentest

service_description SSH

check_command check_ssh


normal_check_interval 1

retry_check_interval 1

check_period 24x7



notification_options w,u,c,r,f


event_handler_enabled 1


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 handle_cfrun

command_line /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 xentest206

hostgroups xentest

address 192.168.254.206


check_period 24x7




notification_options d,u,r,f

}

define host{


hostgroups xentest

address 192.168.254.207


check_period 24x7





}

define host{


hostgroups xentest


address 192.168.254.208


check_period 24x7





}

define host{


hostgroups xentest

address 192.168.254.209


check_period 24x7





}

define host{


hostgroups xentest

address 192.168.254.210


check_period 24x7





}

# -- /etc/nagios/xen/hostsgroups.cfg

define hostgroup{

hostgroup_name xentest

alias xentest

members xentest206, xentest207, xentest208, xentest209, xentest210

}

# -- /etc/nagios/xen/contacs.cfg

define contact{

contact_name nagios


alias Nagios Admin

host_notification_period 24x7

service_notification_period 24x7

service_notification_options w,u,c,r

host_notification_options d,u,r

service_notification_commands notify-by-email

host_notification_commands host-notify-by-email

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 manierada autorizzare Nagios ad eseguire cfrun dal server che effettua il monitoraggio. Ilmodello di sicurezza di Cfegine e basato su di una chiave pubblica/privata alla qualesono associati userid e host ip. Quindi per far funzionare il sistema bisogna creare unachiave 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’hostremoto. Il file inoltre dovra avere un nome speciale rappresentato dal seguente pattern

username-ip.addr.pub


quindi modifichiamo il nome del file ed editiamo cfservd.conf aggiungendo ladirettiva 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

Bibliografia

[1] Popek, G.J., Goldberg, R.P. Formal requirements for virtualizable third generationarchitectures. 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] SANURL: http://en.wikipedia.org/wiki/Storage area network

[5] SCSIURL: http://en.wikipedia.org/wiki/SCSI

[6] Fibre Channel OverviewURL: http://hsi.web.cern.ch/HSI/fcs/spec/overview.htm

[7] GNBD HomepageURL: http://sources.redhat.com/cluster/gnbd/

[8] IBM GPFSURL: http://www-03.ibm.com/servers/eserver/clusters/

software/gpfs.html

[9] Red Hat GFSURL: 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 homepageURL: http://www.nagios.org/

[16] Cfengine homepageURL: http://www.cfengine.org/

[17] XenEnterprise HomepageURL: http://www.xensource.com/products/xen enterprise/

[18] OpenQRM HomepageURL: http://www.openqrm.org/

[19] Virtual Iron HomepageURL: http://www.virtualiron.com/

disegno ed implementazione di una soluzione con macchine ... universit`a degli studi di perugia...

Documents