Disegno ed implementazione di una soluzione con macchine virtuali (XEN) per garantire servizi

Università degli Studi di Perugia Facoltà 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 Disponibilità e Virtualizzazione 3 1.1 Cos è l Alta disponibilità........................ 3 1.1.1 Alta disponibilità tramite backups............... 3 1.1.2 Alta disponibilità tramite ridondanza fisica.......... 3 1.1.3 Alta disponibilità tramite virtualizzazione........... 4 1.2 Cos è la virtualizzazione........................ 4 1.3 Teoria di Popek e Goldberg....................... 5 1.3.1 Insiemi di istruzioni...................... 5 1.3.2 Teoremi............................. 5 1.3.3 Effetti della teoria di Popek e Goldberg............ 6 1.4 Tipi di virtualizzazione......................... 6 1.4.1 Emulazione........................... 6 1.4.2 Virtualizzazione........................ 6 1.4.3 Virtualizzazione a livello di SO................ 7 1.4.4 Paravirtualizzazione...................... 7 1.5 Xen................................... 7 1.5.1 Cos è Xen............................ 7 1.5.2 Paravirtualizzazione in Xen.................. 8 1.5.3 Architettura di Xen....................... 9 1.5.4 I daemon di Xen........................ 10 1.5.5 Caratteristiche di Xen..................... 11 1.6 Vantaggi della virtualizzazione..................... 11 2 Il prototipo: analisi delle possibilità e test dei componenti 13 2.1 Prototipo di architettura......................... 13 2.2 Soluzioni distinte per lo storage.................... 14 2.2.1 Block device remoti via hardware............... 15 2.2.2 Block device remoti via software................ 15 2.2.3 Filesystem distribuiti...................... 17 2.3 Test delle componenti.......................... 18 2.3.1 Test di compatibilità...................... 18 I

II INDICE 2.3.2 Test di I/O........................... 19 3 Il prototipo: il sistema di Healthcheck e l implementazione 33 3.1 Sistema di Healthcheck......................... 33 3.2 Analisi delle problematiche....................... 33 3.3 Analisi dei software........................... 34 3.3.1 XenEnterprise......................... 34 3.3.2 OpenQRM........................... 35 3.3.3 Enomalism........................... 36 3.3.4 Virtual Iron........................... 36 3.3.5 Nagios e Cfengine....................... 37 3.4 Il prototipo............................... 39 3.4.1 Schema Logico......................... 39 3.4.2 Implementazione Fisica.................... 40 4 Prospettive future 43 4.1 Virtualizzazione Hardware x86..................... 43 4.1.1 Architettura........................... 43 4.1.2 Memoria............................ 43 4.1.3 Input/Output.......................... 44 4.1.4 Sicurezza............................ 44 A Installazione e uso di Xen 47 A.1 Installazione di Xen........................... 47 A.2 Configurazione di Xen......................... 47 A.2.1 Configurazione di xend..................... 47 A.2.2 Configurazione dei macchine virtuali............. 48 A.2.3 pygrub............................ 48 A.3 Uso di Xen............................... 49 A.3.1 Lanciare Xen.......................... 49 A.3.2 Il tool xm............................ 49 A.4 Creazione di una VM SL4....................... 50 A.4.1 Installazione di SL4...................... 50 A.4.2 Compilazione del kernel 2.6.16-xen.............. 50 A.4.3 Creazione e prova delle macchine virtuali........... 51 B Uso di block device via rete 53 B.1 iscsi.................................. 53 B.1.1 Introduzione.......................... 53 B.1.2 Installazione di un target.................... 53 B.1.3 Installazione di un initiator................... 54 B.2 GNBD.................................. 55 B.2.1 Introduzione.......................... 55

INDICE III B.2.2 Installazione di GNBD..................... 55 B.2.3 Esportazione e Importazione.................. 56 C Installazione e uso di Nagios e Cfengine 57 C.1 Nagios.................................. 57 C.1.1 Installazione di Nagios e plugin................ 57 C.1.2 Configurazione dell interfaccia web.............. 58 C.1.3 Configurazione di Nagios................... 59 C.2 Cfengine................................. 61 C.2.1 Installazione di Cfengine.................... 61 C.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..... 8 1.2 Livelli di privilegi di un sistema operativo senza (sinistra) e con Xen (destra)................................. 9 1.3 Architettura di Xen........................... 10 1.4 Ripristino di due servizi virtualizzati.................. 12 2.1 Prototipo di architettura di un sistema ad alta disponibilità tramite Xen. 14 2.2 Le topologie FC............................. 15 2.3 Architettura di iscsi.......................... 16 2.4 Schema di filesystem distribuiti..................... 17 2.5 Esempio di risultato di un test con IOzone............... 20 2.6 Test di lettura a 64 bit.......................... 21 2.7 Test di scrittura a 64 bit......................... 21 2.8 Test di lettura a 32 bit.......................... 22 2.9 Test di scrittura a 32 bit......................... 22 2.10 Test di lettura a 64 bit.......................... 23 2.11 Test di scrittura a 64 bit......................... 23 2.12 Test di lettura a 32 bit.......................... 24 2.13 Test di scrittura a 32 bit......................... 24 2.14 Test di lettura a 64 bit.......................... 25 2.15 Test di scrittura a 64 bit......................... 25 2.16 Test di lettura a 32 bit.......................... 26 2.17 Test di scrittura a 32 bit......................... 26 2.18 Confronto 2D risultati scrittura a 32 bit................. 27 2.19 Confronto 3D risultati scrittura a 32 bit................. 28 2.20 Confronto 2D risultati lettura a 32 bit.................. 28 2.21 Confronto 3D risultati lettura a 32 bit.................. 29 2.22 Confronto 2D risultati scrittura a 64 bit................. 29 2.23 Confronto 3D risultati scrittura a 64 bit................. 30 2.24 Confronto 2D risultati lettura a 64 bit.................. 30 2.25 Confronto 3D risultati lettura a 64 bit.................. 31 V

VI ELENCO DELLE FIGURE 3.1 Schermata XenEnterprise........................ 35 3.2 Schermata OpenQRM.......................... 36 3.3 Schermata Enomalism......................... 37 3.4 Schermata Virtual Iron......................... 37 3.5 Schema del prototipo........................... 40 A.1 Menu di pygrub............................ 49

Introduzione Introduzione generale L alta disponibilità è 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 è ammissibile la perdita di dati o l impossibilità di usufruire di servizi. Non potendo garantire la perfezione, solitamente una soglia del 99% di uptime è considerata, tranne casi particolari, il limite sotto il quale non è 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 può apportare grandi vantaggi nella progettazione ed implementazione di una soluzione ad Alta disponibilità attraverso l isolamento del sistema operativo, erogatore del servizio, dalla rispettiva macchina fisica. Struttura della tesi La tesi è strutturata in 4 capitoli suddivisi in: Capitolo 1 in questo capitolo vengono descritte sia l alta disponibilità, 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 disponibilità 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 possibilità 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 Disponibilità e Virtualizzazione 1.1 Cos è l Alta disponibilità Alta disponibilità è 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 più alto grado di utilizzo. L alta disponibilità del sistema si ottiene riducendo la probabilità 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 disponibilità tramite backups Una possibile soluzione, ma anche la più semplice, è 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 è 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 più 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 è il numero di backup, minore è il rendimento) e le performance dei sistemi che si vogliono rendere affidabili (minore numero di backup, minore affidabilità). 1.1.2 Alta disponibilità tramite ridondanza fisica Una seconda soluzione è 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 DISPONIBILITÀ E VIRTUALIZZAZIONE riesce in caso di guasto ad utilizzare la copia della macchina rendendo il tempo di ripresa del servizio più basso. Lo svantaggio di questa scelta stà 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 disponibilità tramite virtualizzazione Una terza soluzione al problema è 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 è un operazione quasi istantanea. Se si riscontrano problemi in una macchina fisica si può 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 è 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 più utilizzato è 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 Virtualizzazione Virtualizzazione a livello di SO Paravirtualizazzione Bochs VMware OpenVZ Virtual Iron Qemu Plex86 Linux-VServer User-mode Linux VirtualPC Microsoft Virtual PC FreeVPS L4 DOSEMU Microsoft Virtual Server SWsoft Virtuozzo Xen............ Tabella 1.1: Tipi di virtualizzazione. Il componente fondamentale di un sistema basato su macchine virtuali è il Virtual Machine Monitor, conosciuto anche con il nome di hypervisor. Il suo compito è

1.3. TEORIA DI POPEK E GOLDBERG 5 quello di allocare le risorse dinamicamente quando necessarie e isolare l architetture interrompendo eventuali attività 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 è 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 è stata introdotta una classificazione delle istruzioni in tre diversi gruppi: Privileged sono quelle che possono interrompere l esecuzione del processore se è in modalità utente (user-space) e non se è in modalità 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 può essere espresso attraverso due teoremi. Primo teorema Per qualsiasi calcolatore di terza generazione, un Virtual Machine Monitor potrà essere sempre costruito se qualsiasi insieme di istruzioni sensitive è un sotto-insieme delle istruzioni privileged. 1 Requisiti formali per architetture di terza generazione virtualizzabili.

6 CAPITOLO 1. ALTA DISPONIBILITÀ E VIRTUALIZZAZIONE Secondo teorema Un sistema di terza generazione sarà ricorsivamente virtualizzabile se 1. È virtualizzabile 2. Si può 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 perchè 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 è 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 è 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 già visto, non è ottima perchè questa architettura non soddisfa i requisiti della Teoria di Popek e Goldberg per virtualizzazione (1.3), è quindi avrà 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 più 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 è 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 però il sistema operativo ospite dovrà essere modificato per interagire con l hypervisor. Questa implementazione ha due caratteristiche fondamentali ed interessanti rispetto alle altre soluzioni: L hypervisor diventa molto più 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 più interessante per questo lavoro di tesi. 1.5 Xen In questa sezione si effettuerà una panoramica sulle caratteristiche e l architettura di xen tralasciandone l utilizzo, dettagliatamente analizzato nell Appendice A. 1.5.1 Cos è Xen Xen [3] è 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 CAPITOLO 1. ALTA DISPONIBILITÀ E VIRTUALIZZAZIONE nativa. Xen è nato all inizio come un progetto di ricerca dell Università di Cambridge e la sua prima versione venne pubblicata nel 2003. Al giorno d oggi esistono due versioni con notevoli differenze e incompatibilità tra loro: Xen 2.0 e Xen 3.0. La versione 2.0 non sarà più sviluppata e quindi la versione su cui si sta lavorando e alla quale si farà riferimento è 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 è chiamata paravirtualizzazione (1.4.4) ed è la più 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 ciò Xen introduce modifiche sia nelle macchine host che nelle macchine guest. La macchina in cui verrà fatta la virtualizzazione (cioè, la macchina host) non sarà più una macchina x86, ma diventerà una macchina con architettura Xen-x86 e i sistemi operativi che si vorranno virtualizzare dovranno adattarsi a questa architettura. È 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 parlerà di Xen utilizzando sempre come host un kernel Linux della serie 2.6.

1.5. XEN 9 Sistema operativo Host Guest Linux 2.6 Si Si NetBSD 3.0 No In alto grado di sviluppo FreeBSD 5.3 No In alto grado di sviluppo Plan9 No In sviluppo ReactOS No Proggettato. S.O. senza modifiche No Supporto iniziale tramite Intel VT Tabella 1.2: Compatibilità 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 più privilegi. ring-3 ring-3 ring-1 ring-1 ring-0 SO ring-1 ring-1 ring-0 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 avrà la seguente struttura: ring-0 Livello dove si esegue il kernel del sistema operativo. Questo livello è 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 avrà 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 CAPITOLO 1. ALTA DISPONIBILITÀ E VIRTUALIZZAZIONE 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 è 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 è 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 parlerà del funzionamento nell Appendice A). 1.5.4.2 Xen Store Daemon: xenstored Questo daemon è 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 riuscirà 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. Possibilità 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). Possibilità di clonare le macchine per fare test e aggiornamenti, senza compromettere la integrità della macchina originale, con la possibilità di tornare indietro in maniera controllata. Possibilità di scalabilità, entro certi limiti. Mettere in pausa le macchine con la possibilità 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 disponibilità: 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 CAPITOLO 1. ALTA DISPONIBILITÀ E VIRTUALIZZAZIONE Fallimento di una macchina fisica. Macchina fisica 1 Servizio 1 Servizio 2 Macchina fisica 2 Servizio 3 Servizio 4 Internet Macchina fisica 3 Servizio 5 Servizio 6 Migrazione delle macchine virtuali. Macchina fisica 1 Servizio 1 Servizio 2 Macchina fisica 2 Servizio 3 Servizio 4 Internet Macchina fisica 3 Servizio 5 Servizio 6 Ritorno allo stato di normalità. Macchina fisica 1 Servizio 1 Servizio 2 Servizio 6 Macchina fisica 2 Servizio 3 Servizio 4 Servizio 5 Internet Macchina fisica 3 Figura 1.4: Ripristino di due servizi virtualizzati

Capitolo 2 Il prototipo: analisi delle possibilità e test dei componenti In questo capitolo verrà proposto un modello prototipale di architettura di un sistema ad alta disponibilità ed in seguito la serie di test effettuati per la determinazione della migliore soluzione. 2.1 Prototipo di architettura La struttura proposta è 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 più macchine virtuali, eseguendo Xen. Per questo nelle macchine si può 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. macchine vengono caricate da un server, tramite rete. Le immagini delle Servizio di healtcheck Questo servizio deve essere eseguito sia sulla macchina fisica, sia su quella virtuale, poiché è incaricato di gestire e verificare il funzionamento del sistema. Nella Sezione 3.1 si parlerà più 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 ciò si deve utilizzare un server di storage per 13

14CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.1: Prototipo di architettura di un sistema ad alta disponibilità 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 è il sistema utilizzato per memorizzare e distribuire le immagini delle macchine virtuali, per questo, è 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 più conosciuta è Fibre Channel[6]. 2.2.1.1 Fibre Channel Fibre Channel è una tecnologia ad alta velocità, 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 più sensibile ai problemi. A dispetto del suo nome, Fibre Channel può 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 è cosi elevato e le prestazioni sono abbastanza buone. Le due soluzioni principali sono GNBD e iscsi.

16CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI 2.2.2.1 iscsi L iscsi 1 è 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 è basata su un architettura (Figura 2.3 a pagina 16) client-server (quella di SCSI), dove il client è chiamato initiator ed il server è 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 Target La implementazione più stabile e la più matura è quella chiamata core- ISCSI http://www.kernel.org/pub/linux/utils/storage/ iscsi/. La implementazione su cui si sta lavorando di più è The iscsi Enterprise Target http://iscsitarget.sourceforge.net/. 1 Internet Small Computer Systems Interface 2 http://www.ietf.org/ 3 Tecnologia per implementare reti Ethernet a una velocità nominale di 1 Gigabit per secondo. 4 Storage 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 è Ethernet; è una tecnologia sviluppata da Red Hat per essere utilizzata originalmente con il Red Hat Global File System. L unica distribuzione esistente è quella della Red Hat, che è 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 più utilizzati e conosciuti sono due: GFS GPFS sviluppato dalla Red Hat. 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 può ottenere: Una alta scalabilità e flessibilità. 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.

18CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI 2.3 Test delle componenti 2.3.1 Test di compatibilità Per poter implementare il prototipo è stato necessario effettuare una nutrita serie di test, raggruppabili in: Test di compatibilità 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 è 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 è 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, nè errori (l importante è stato leggere con attenzione i requisiti d installazione richiesti da Xen e conformarsi alle richieste). Test di sistemi guest I test di compatibilità 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 è 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 incompatibilità fra l architettura a 32 bit e quella a 64. Test di dispositivi storage Sono stati anche eseguiti test per verificare la compatibilità 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 è uno strumento ampiamente utilizzato per fare prove comparative di rendimento nell accesso ai dischi (sia tra differenti filesystem che tra differenti dispositivi). Si è utilizzato questo tool per effettuare i test, sottoponendo le macchine ad un alto carico di lavoro. Durante le prove è stato possibile verificare la stabilità 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 è utilizzato il fileserver descritto nella Tabella 2.2 a pagina 19. Processore Dual Pentium III 1GHz Memoria 256MB Disco 210GB - RAID 5 Conessione Rete Gigabit Ethernet Sistema Operativo Slackware Linux 10.2 - Kernel 2.6.15.6 Tabella 2.2: Caratteristiche fileserver. In alcuni test si è utilizzato anche un disco Fibre Channel con le caratteristiche della Tabella 2.3 a pagina 19. Spazio disco Conessione Rete 4797776,28MB Fibra Ottica 5 URL: http://www.iozone.org/ Tabella 2.3: Caratteristiche disco FC.

20CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI 2.3.2.3 Interpretazione dei risultati Prima di introdurre i test di I/O, si spiegherà 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 velocità 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 è 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 è 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 (più 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 è circa lo stesso per tutte e due le architetture.

2.3. TEST DELLE COMPONENTI 21 Figura 2.6: Test di lettura a 64 bit. Figura 2.7: Test di scrittura a 64 bit.

22CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.8: Test di lettura a 32 bit. Figura 2.9: Test di scrittura a 32 bit. GNBD In questi test è 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.10-2.13. Analizzando le immagini si può osservare un comportamento anomalo derivato

2.3. TEST DELLE COMPONENTI 23 probabilmente dall esistenza di carico nella rete. Per esempio nella Figura 2.12 a pagina 24 si può identificare nella zona alta e bassa una differenza di velocità molto sostenuta che non dovrebbe sussistere. Inoltre, come nella soluzione Fibre Channel, si può osservare un incremento del rendimento per file di piccole dimensioni nell architettura a 64 bit. Figura 2.10: Test di lettura a 64 bit. Figura 2.11: Test di scrittura a 64 bit.

24CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.12: Test di lettura a 32 bit. Figura 2.13: Test di scrittura a 32 bit. iscsi Per effettuare questi test si è utilizzato lo stesso fileserver dei test con GNBD, già 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.

2.3. TEST DELLE COMPONENTI 25 Analizzando le immagini si può 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. Figura 2.14: Test di lettura a 64 bit. Figura 2.15: Test di scrittura a 64 bit.

26CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.16: Test di lettura a 32 bit. Figura 2.17: Test di scrittura a 32 bit. 2.3.2.5 Confronto dei risultati Nei confronti di seguito riportati è 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 è riportato il confronto tra i ri-

2.3. TEST DELLE COMPONENTI 27 sultati delle varie soluzioni per le diverse modalità di test di IOzone. Nelle figure 2.19, 2.21, 2.23 e 2.25 invece è riportato il grafico 3D delle stesse quantità con l aggiunta di una terza dimensione rappresentata dal record. Come si evince dalle figure, il rendimento del dispositivo Fibre Channel è superiore alle soluzioni software proposte, in quanto: Il tipo di conessione utilizzata tra le macchine e il disco è di 2Gb/s. Il disco Fibre Channel è un dispositivo hardware specifico per essere utilizzato come SAN. Nonostante questi validi motivi il costo del dispositivo è abbastanza elevato (circa 1000 euro per una scheda di interfaccia) ed implementare una soluzione basata su isc- SI o GNBD è poco penalizzante in termini di prestazioni e molto vantaggiosa dal lato economico. Quindi nell implementazione finale del prototipo si è scelto iscsi che ha dimostrato scalabilità, stabilità ed un rendimento sebbene non in maniera elevatissima migliore di GNBD. Figura 2.18: Confronto 2D risultati scrittura a 32 bit.

28CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.19: Confronto 3D risultati scrittura a 32 bit. Figura 2.20: Confronto 2D risultati lettura a 32 bit.

2.3. TEST DELLE COMPONENTI 29 Figura 2.21: Confronto 3D risultati lettura a 32 bit. Figura 2.22: Confronto 2D risultati scrittura a 64 bit.

30CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI Figura 2.23: Confronto 3D risultati scrittura a 64 bit. Figura 2.24: Confronto 2D risultati lettura a 64 bit.

2.3. TEST DELLE COMPONENTI 31 Figura 2.25: Confronto 3D risultati lettura a 64 bit.

32CAPITOLO 2. IL PROTOTIPO: ANALISI DELLE POSSIBILITÀ E TEST DEI COMPONENTI

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 può essere visto come un supervisore che all insorgere di problemi, li ripristina senza l intervento umano. Nel nostro caso specifico, esso si occuperà 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 flessibilità dell infrastruttura stessa. Tali vantaggi sono sostanzialmente dovuti alla possibilità di gestire virtualmente le macchine, attraverso migrazioni live, riavii e pause e alla possibilità in caso di necessità, di un facile incremento o una riduzione del numero delle macchine. Tutto ciò però, 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 è deciso di scrivere un software per gestire l intera infrastruttura. Il software è stato scritto in linguaggio C ed è 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 è 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 difficoltà, si è pensato di esplorare nuove possibilità, alla ricerca di una soluzione più adeguata alle esigenze, concentrandosi maggiormente su software che implementino gestione di virtualizzazione o monitoring. 3.3 Analisi dei software Come già 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 è 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 è 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 è 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 è 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 scalabilità e riesce a gestire molteplici server con report dettagliati, attraverso una semplice interfaccia. Il sistema è 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 estendibilità, ha da poco aggiunto il supporto a Xen attraverso plugin di sviluppatori esterni, ma il rischio di immaturità di tale soluzione, non ne fa un sistema totalmente affidabile e ciò ci ha fatto propendere per un altra scelta.

36CAPITOLO 3. IL PROTOTIPO: IL SISTEMA DI HEALTHCHECK E L IMPLEMENTAZIONE Figura 3.2: Schermata OpenQRM 3.3.3 Enomalism Enomalism è una applicazione web tramite la quale si può 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 è 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 è 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 è distribuito in 3 versioni: Professional, Consolidation ed Enterprise di cui una è 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 è il software che si avvicina maggiormente alla nostre richieste, anche se non supporta la gestione dei servizi, che però 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 è disponibile in nessuna delle versioni ma, ciò 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] è un software open source per il monitoraggio di server e servizi di rete, progettato per garantire alle strutture responsabili di essere costantemente informate

38CAPITOLO 3. IL PROTOTIPO: IL SISTEMA DI HEALTHCHECK E L IMPLEMENTAZIONE 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 è 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 è 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. Capacità di definire eventi da eseguire durante il verificarsi di problemi per la loro risoluzione. Produzione di log dettagliati sulle attività svolte. Interfaccia web per la verifica dello stato corrente, delle notifiche e della cronologia dei problemi. Attraverso l utilizzo di tale programma si è risolta la problematica del monitoraggio dell intera infrastruttura, sia virtuale, che fisica ma non si è affrontata minimamente la problematica della riattivazione di servizi e gestione delle macchine virtuali. Per far ciò, si è affiancato a Nagios, un altro software denominato Cfengine. Cfengine [16] è un sistema di amministrazione di elaboratori Unix, il cui scopo principale è automatizzare la configurazione e il mantenimento di sistemi operativi, soprattutto quando si dispone di un gruppo eterogeneo di questi, su diversi elaboratori. Cfengine può essere definito come l interprete di un linguaggio evoluto il cui scopo è 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 molteplicità di comandi di sistema. Nell infrastruttura creata Cfengine potrebbe da solo riuscire a riattivare i servizi non più 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 è uno dei motivi fondamentali per il quale si è utilizzato un software di monitoring esterno come Nagios, oltre ovviamente alla possibilità, 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 è 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 è 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

40CAPITOLO 3. IL PROTOTIPO: IL SISTEMA DI HEALTHCHECK E L IMPLEMENTAZIONE Figura 3.5: Schema del prototipo. 3.4.2 Implementazione Fisica 3.4.2.1 Nagios Nella realizzazione fisica del prototipo, si è installato Nagios nella macchina xentest206, l unica avente il compito di occuparsi del monitoraggio. In generale, è stata fatta la scelta di monitorare solamente il funzionamento del servizio ssh e della raggiungibilità 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 scalabilità dei software utilizzati, il discorso può essere ampliato ad una molteplicità 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 è installato su ognuna di esse. Il motivo fondamentale di questa scelta è 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.