UNIVERSITA' DEGLI STUDI DI BARI UN CLUSTER IN ALTA DISPONIBILITÀ IN AMBIENTE LINUX

UNIVERSITA' DEGLI STUDI DI BARI FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA TESI DI LAUREA IN SISTEMI PER L'ELABORAZIONE DELL'INFORMAZIONE: SISTEMI DISTRIBUITI UN CLUSTER IN ALTA DISPONIBILITÀ IN AMBIENTE LINUX RELATORI: Chiar.mo Prof. S. PIZZUTILO dott. D. DIACONO LAUREANDO: Sabino CALÒ ANNO ACCADEMICO 2003/2004

INDICE GENERALE INTRODUZIONE...4 CLUSTER: GENERALITA'...7 1.1 Architettura... 8 1.2 High Performance Computer e High Availability...10 1.3 Il software libero... 12 1.4 Progetti Open-Source per cluster di calcolo... 13 1.5 Progetti Open-Source di cluster HA... 13 LINUX: INSTALLAZIONE KERNEL... 21 2.1 L'Hardware... 21 2.2 L'installazione del sistema operativo... 23 L'ALTA DISPONIBILITA' (HA)...43 3.1 Livelli di disponibilità... 3.2 Requisito dei cinque 9... 3.3 Le prestazioni... 3.4 Tipologie di cluster... 44 46 48 49 IL CLUSTER REALIZZATO IN QUESTA INSTALLAZIONE...52 4.1 Elementi fondamentali: una visione panoramica... 53 4.2 Schema di progetto... 55 4.3 Heartbeat... 60 L'INSTALLAZIONE E CONFIGURAZIONE DEL FILE-SYSTEM: DRBD...64 5.1 Tipologie di storage... 64 5.2 Il file-system utilizzato nel setup: motivi della scelta... 67 5.3 DRBD: caratteristiche e peculiarità... 70 5.4 Performance... 83 5.5 Installazione e configurazione DRBD... 101 5.6 Alta disponibilità della rete interna... 104 2

HEARTBEAT: SUITE PER L'ALTA DISPONIBILITA'... 108 6.1 La struttura modulare di Heartbeat... 108 6.2 Il Resource Group... 114 6.3 Installazione e configurazione... 115 6.4 Gratuitous ARP... 122 STRUMENTI DI MONITORAGGIO E TEST DEL SISTEMA... 124 7.1 Mon... 7.2 Webmin... 7.3 Swatch... 7.4 Test del sistema... 124 128 130 132 APPENDICE...140 File di configurazione...141 A1. /etc/fstab... 141 A2. /etc/make.conf... 141 A3. /etc/lilo.conf... 144 A4. /usr/src/linux/.config... 144 A4 /etc/conf.d/net... 150 A5. /root/.bash_profile... 150 A6. /root/.bashrc... 151 A7. /etc/drbd.conf... 151 A8. /etc/ha.d/haresources... 152 A9. /etc/ha.d/ha.cf... 152 A10. /etc/mon.d/mon.cf... 152 A11. /etc/mon.d/auth.cf... 153 A12. /root/.swatchrc... 153 A13. Script mon http.alert... 154 A14. Script mon stopha.alert... 154 BIBLIOGRAFIA...163 3

INTRODUZIONE Il lavoro di tesi è stato svolto all'interno di una collaborazione fra il Dipartimento di Informatica dell'università degli Studi di Bari e l'istituto Nazionale di Fisica Nucleare (INFN) sez. di Bari. Il lavoro di tesi ha avuto come scopo la ricerca lo studio di soluzioni open-source e quindi la realizzazione di un sistema distribuito (cluster) per l'erogazione di servizi di rete in Alta Disponibilità (HA). Il sistema distribuito è stato costruito su due macchine identiche con tecnologia non dedicata basate su CPU x86 di tipo Intel Pentium4 Xeon (cfr. cap. 2), fornite dall'infn, per la propria rete dipartimentale. Entrambi i nodi del cluster hanno un sistema operativo Gentoo Linux e sono interconnessi al fine di fornire l'erogazione dei servizi in alta disponibilità in maniera distribuita. Il sistema di memorizzazione di massa è basato su un progetto open-source di recente introduzione, denominato DRBD (cfr. cap. 5), che consente di disporre di dispositivi condivisi astraendo i reali dispositivi hardware costituiti da generici dischi EIDE installati all'interno di ciascuno dei nodi del cluster. Il centro del sistema è costituito dalla suite Heartbeat (cfr. cap. 6), che ha il compito di gestire le risorse del cluster e di reagire ad eventuali malfunzionamenti, per evitare di interrompere l'erogazione dei servizi. 4

Nel capitolo 1, sono presentate le basi teoriche sui sistemi distribuiti, i diversi modelli teorici e le diverse tipologie di cluster, ponendo particolare attenzione alla distinzione fra cluster di calcolo a bilanciamento di carico e cluster per l'erogazione di servizi in alta disponibilità. Il capitolo 2, prende in considerazione il sistema distribuito dal punto di vista del singolo nodo. Dopo la descrizione dell'hardware, viene descritta l'installazione del sistema operativo, la configurazione del kernel e la configurazione delle partizioni del disco rigido nonché l'installazione dei programmi di utilità di sistema fra cui una utility di replicazione della riga di comando ai diversi nodi. Il capitolo 3, analizza i concetti teorici inerenti l'alta disponibilità: i livelli di disponibilità, i requisiti di un sistema distribuito in alta disponibilità e le tipologie di cluster per l'ha. Nel capitolo 4 è descritto schematicamente il cluster costruito in questo lavoro di tesi, le tipologie di collegamento fra i due nodi, in particolare l'installazione e configurazione del meccanismo di channel bonding necessario a ridondare il collegamento di rete inerno al cluster. Vengono inoltre presentati i primi concetti relativi ad Heartbeat e le soluzioni a problemi particolari, nello specifico il problema del Brain-Splitting. Il capitolo 5 è dedicato alla descrizione del modulo DRBD ed alla sua installazione e configurazione. DRBD fornisce al sistema operativo un dispositivo di memorizzazione condiviso e astratto costituito da partizioni reali residenti su entrambi i nodi del cluster. In tale capitolo si descrivono i requisiti software che DRBD fornisce e l'algoritmo alla base del sistema. Viene inoltre presentata l'analisi dei test sulle performance che sono stati eseguiti sui dispositivi DRBD nelle diverse configurazioni. Nel capitolo 6 viene analizzata nei minimi dettagli la suite Heartbeat, la sua struttura modulare e i meccanismi di funzionamento che rendono necessarie 5

alcune attenzioni sulla scelta di alcuni dispositivi hardware, in particolare lo switch a cui sono collegati i nodi, affinchè supporti i pacchetti di gratuitousarp. Il capitolo si conclude con la procedura di installazione e configurazione della suite. Il capitolo 7 riguarda invece gli strumenti di monitoraggio necessari a controllare costantemente il funzionamento del sistema. Vengono installati e configurati i software mon, swatch e Webmin. Alla fine del capitolo viene descritto un test per verificare le funzionalità del sistema. Tale descrizione è completata con alcuni screenshot che mostrano il comportamento del sistema durante il test eseguito. Chiude il lavoro di tesi un'appendice contenente alcuni file testuali di configurazione di diversi software: Sistema operativo, DRBD, Heartbeat, mon e swatch. 6

Capitolo 1 CLUSTER: GENERALITA' L'informatica è una scienza relativamente moderna nata contestualmente all'invenzione delle macchine in grado di eseguire calcoli in maniera automatica e rapidissima che sono state definite computer o calcolatori. Lo scopo dell'informatica è quello di rendere possibile la descrizione di un problema reale sotto forma di un procedimento fatto di passaggi elementari o atomi di ragionamento che prende il nome di algoritmo. Inizialmente i computer risolvevano problemi abbastanza semplici ma grazie alla ricerca nella scienza informatica, attualmente i computer risolvono problemi molto complessi e in alcuni casi sono in grado di prendere semplici decisioni, in relazione agli stimoli del mondo esterno, avvicinandosi così poco alla volta all'estrema complessità del ragionamento umano. Il progresso tecnologico nel campo dell'elettronica, sinergicamente generato dalla ricerca informatica, ha reso disponibili macchine di calcolo sempre più veloci e versatili tali da poter essere aggregate a costituire quasi una emulazione della rete neuronale del cervello umano. L'aggregazione di più computer, al fine di risolvere uno stesso problema comune, raggiungendo quindi lo stesso scopo, prende il nome di sistema distribuito o cluster. Il paradigma alla base di una sistema distribuito è assimilabile a divide et impera. Secondo questo paradigma di ragionamento ogni problema può essere risolto scomponendolo in tanti sottoproblemi più piccoli, la soluzione di ognuno dei quali genera la soluzione del problema primario. L'applicazione di questo schema di ragionamento incorpora il concetto di modularità che 7

caratterizza tutti i moderni sistemi di calcolo, in modo più evidente i sistemi distribuiti. Un sistema distribuito infatti è un sistema modulare perchè è composto da un insieme più o meno grande di calcolatori identici che si definiscono nodi. In un sistema distribuito si ha la possibilità di aggiungere o eliminare nodi dal sistema generando rispettivamente un aumento o una diminuzione nella capacità di calcolo dell'intero sistema. Questa caratteristica prende il nome di scalabilità. Si definisce che un sistema è molto scalabile quando l'aumento delle prestazioni di calcolo cresce più che proporzionalmente rispetto al numero dei nodi. Secondo la definizione principale un cluster è un sistema distribuito composto da un numero non specificato di singoli computer definiti processori o più semplicemente nodi, interconnessi fra loro da una rete di comunicazione privata usata esclusivamente per la sincronizzazione e lo scambio di messaggi fra i processi che girano sul cluster e si condividono le risorse che possono essere locali o remote [1]. 1.1 Architettura Un sistema distribuito può distinguersi principalmente in due categorie relative essenzialmente al modo in cui sono disposte e gestite le risorse di sistema. Possiamo infatti distinguere sistemi cosiddetti Tightly coupled la cui caratteristica distintiva sta nel fatto che ogni nodo del cluster condivide la stessa memoria che utilizza anche per gli scopi di comunicazione fra i processi in esecuzione; al contrario, i sistemi definiti Loosely coupled si differenziano dai precedenti per il fatto che ogni nodo utilizza e gestisce la propria memoria mentre i processi in esecuzione sui vari nodi comunicano attraverso i messaggi utilizzando le tecniche cosiddette di Message Passing. I sistemi del tipo loosely coupled corrispondono più propriamente alla definizione di sistema distribuito. 8

I modelli in base ai quali è possibile costruire un sistema distribuito variano in base alla specializzazione dei diversi nodi all'interno del cluster. Il modello definito minicomputer caratterizza sistemi distribuiti essenzialmente Tightly coupled che condividono le stesse risorse centralizzate. Questo tipo di sistema in effetti è concettualmente simile ad un computer singolo anche se scalabile e modulare. Secondo il modello workstation model un sistema distribuito è di tipo loosely coupled in quanto formato da un insieme di workstation complete che gestiscono autonomamente le proprie risorse. I processi vengono opportunamente trasferiti ed eseguiti sulle workstation libere gestendo comunque la priorità dei processi locali e remoti. Il modello workstation-server model si applica a sistemi distribuiti formati da un insieme di workstation connesse inoltre a minicomputer specializzati in particolari servizi. Tipicamente un utente di un tale sistema svolge in locale le operazioni generiche, in remoto le operazioni specializzate per cui esiste un minicomputer dedicato. Questo modello fornisce alcuni vantaggi che nelle diverse situazioni applicative possono essere di grande importanza se non a volte richieste come scelta progettuale: è possibile ad esempio centralizzare le risorse di memorizzazione di massa costituendo appositamente un minicomputer come file-server, in modo da fornire prestazioni eccellenti nell'input-output dei dati, si centralizzerebbe così anche il lavoro di manutenzione e infine non si rende necessaria la migrazione dei processi dato che le elaborazioni remote vengono eseguite attraverso il protocollo clientserver. Il modello processor pool model caratterizza sistemi distribuiti formati da nodi generici non specializzati che vengono dinamicamente allocati dal sistema di gestione delle risorse e forniscono all'esterno l'immagine di sistema singolo. L'utente che deve eseguire i suoi processi si collega al cluster attraverso terminali remoti che non fanno parte del cluster e dunque non si 9

connette ad un nodo in particolare come nei modelli workstation e workstation server, ma concettualmente all'intero sistema. Questo modello è il più diffuso fra gli attuali cluster adibiti al calcolo massivo. Il sistema operativo di un sistema distribuito deve essere tale da consentire e favorire le operazioni tipiche di un cluster. Si possono innanzitutto distinguere due classi di sistemi operativi per cluster denominati Network operating system e Distributed Operating System. Le differenze fra le due tipologie risiedono principalmente nell'immagine del sistema che forniscono all'utente. Un Network Operating system infatti coordinando i diversi sistemi operativi presenti su ogni nodo e adibiti alla gestione delle risorse locali, dà all'utente la possibilità di conoscere quali sono i nodi del cluster il loro stato e gli consente inoltre di scegliere su quali nodi eseguire la sua computazione. D'altro canto un Distributed Operating System fornisce all'utente l'immagine di sistema singolo prendendosi in carico la gestione del carico di lavoro da assegnare ai diversi nodi del cluster. E' evidente che i malfunzionamenti di ciascun nodo sono nascosti all'utente in quanto egli stesso non è a conoscenza del modo in cui il sistema è costruito. Un sistema operativo distribuito è ovviamente complesso in quanto deve consentire performance e quindi scalabilità, affidabilità attraverso la gestione della ridondanza dei componenti più sensibili ed infine sicurezza dato che un sistema distribuito solitamente è usato da diversi utenti per ognuno dei quali si deve garantire riservatezza e permessi. 1.2 High Performance Computer e High Availability E doverosa ora un'altra distinzione fondamentale in merito alle tipologie di cluster che è possibile realizzare. Tale distinzione è legata essenzialmente all utilizzo a cui il cluster è dedicato. Un cluster può essere un HPC (High Performance Computer), dedicato solitamente al calcolo massivo, tipico delle simulazioni scientifiche in cui sono in gioco diverse variabili. Questi sistemi sono assimilabili al modello 10

processor pool e sono quindi di tipo loosely coupled in quanto ogni nodo gestisce le proprie risorse. Forniscono all'utente l'immagine di sistema singolo e generalmente sono formati da almeno 32 nodi. L altro tipo di cluster è definito sistema ad alta disponibilità (HA: High Availability) che ha come obbiettivo primario quello di garantire con ogni sforzo il requisito dell'affidabilità che generalmente caratterizza ogni sistema distribuito. I cluster per l'alta disonibilità hanno lo scopo di fornire servizi. Si adotta la soluzione cluster per far in modo che i servizi vengano erogati limitando al minimo le interruzioni e questo è possibile in quanto la struttura e gestione del cluster fa sì che nel caso di blocco del nodo che fisicamente sta erogando un servizio, un altro si faccia carico dell intero gruppo di servizi forniti dal nodo caduto. Lo scopo che ci si prefigge nel progetto di un cluster per l'alta disponibilità è quello di eliminare i punti deboli del sistema definiti single point of failure, attraverso la ridondanza degli stessi. Generalmente un cluster HA è realizzato con soli due nodi, sia perché non è sottoposto a carichi di lavoro computazionale elevati, tipici degli HPC, sia per semplificare l arbitraggio delle risorse condivise e limitare i fenomeni negativi ad esso legati, primo fra tutti il Brain-splitting, analizzato più avanti. E ovvio che anche in questo caso lo switching fra i processori è totalmente trasparente all utente il quale ancora una volta ha l immagine di un singolo sistema a cui richiedere servizi. Ci sono due modelli possibili per realizzare un cluster di questo tipo e sono definiti A-S (Active-Standby) e A-A (Active-Active). Nel modello A-S, i servizi offerti dal cluster sono residenti tutti su un nodo; vengono poi presi totalmente in carico dall altro nodo precedentemente in standby, nel momento in cui il nodo attivo cade. 11

Nel modello A-A i servizi sono distribuiti su entrambi i nodi che si compensano a vicenda quando uno dei due cade. I modi per realizzare questi obiettivi sono diversi e verranno presi in considerazione quelli inerenti la piattaforma e l ambiente operativo scelti per la realizzazione del cluster HA oggetto di studio di questa tesi. 1.3 Il software libero E' possibile realizzare un sistema in alta disponibilità attraverso l'utilizzo di tecnologie proprietarie che integrano gli strumenti necessari per poter installare e configurare un cluster HA. Tali soluzioni spesso molto costose, sono caratterizzate dal fatto che il codice sorgente non è accessibile per cui per ogni tipo di intervento inerente la manutenzione del sistema o la modifica della configurazione, è necessario ricorrere alla casa costruttrice del pacchetto software. Visto il fiorire di progetti sempre più sofisticati e maturi nel panorama dell'open-source, inerenti anche soluzioni riguardanti la realizzazione di cluster, si è scelto per lo studio di questa tesi, di realizzare un sistema distribuito per l'alta disponibilità, basato essenzialmente su software libero e gratuito. Il sistema operativo scelto per realizzare il cluster HA è GNU/Linux1. Questo sistema UNIX-like è notoriamente orientato alle reti e ha come vantaggio non trascurabile, oltre che la stabilità e l efficienza tipica dei sistemi *NIX, il fatto che è Open-Source e generalmente gratuito. E evidente come la caratteristica Open-Source sia garanzia di trasparenza e stabilità, per il fatto che chiunque può analizzare, modificare e correggere il codice sorgente. 1 Si noti la differenza tra le diciture Linux e GNU/Linux. La prima sta ad indicare il solo kernel del sistema operativo sviluppato originariamente da Linus Torvalds, la seconda indica invece l'insieme del kernel Linux e di svariati programmi open-source facenti capo al progetto GNU il cui padre è Richard Stallman. Spesso questo insieme più o meno esteso può essere una distribuzione Linux creata da chiunque ed eventualmente messa in vendita. A volte si dice Linux per riferirsi erroneamente ad una intera distribuzione quando invece il termine Linux sta ad indicare il solo kernel. 12

Diversi progetti vengono attualmente sviluppati per la realizzazione di cluster di cui segue un analisi sommaria delle relative caratteristiche. 1.4 Progetti Open-Source per cluster di calcolo La costruzione tipica di un cluster HPC basato su sistemi operativi Unix-like risponde alla tipologia denominata Beowulf la quale fa uso di librerie dedicate, principalmente PVM (Parallel Virtual Machine) e MPI (Message Passing Interface) [2]. Il software applicativo che deve essere eseguito su questo tipo di cluster deve essere ottimizzato per far uso esplicito delle librerie Beowulf affinchè il sistema realizzi un parallelismo puro nell'esecuzione del software. Esiste anche un progetto, denominato open-mosix, che permette la realizzazione di cluster HPC senza la necessità di codice scritto opportunamente. Questo progetto che per altro fornisce anche utility di gestione e monitoraggio complete di GUI, è basato sulle strategie di migrazione dei processi che fanno in modo che il carico computazionale sia equilibrato e distribuito sui diversi nodi del cluster. E evidente però che se il sistema non è ben calibrato, la migrazione dei processi diventa proprio il collo di bottiglia dell intero sistema, soprattutto per la quantità di dati che devono essere migrati con ogni processo. 1.5 Progetti Open-Source di cluster HA Un sistema in alta disponibilità è caratterizzato tipicamente da diversi componenti software intercomunicanti che sinergicamente permettono al sistema di lavorare e fornire servizi in alta disponibilità. Tale insieme di componenti nelle soluzioni proprietarie è spesso nascosto e l'utente/acquirente del sistema (che spesso comprende anche l'hardware), può non avere nessuna conoscenza di tali componenti, né di come essi interagiscono, né delle funzioni che essi svolgono. Questo modo di fare 13

ovviamente rende l'utente finale sempre in un certo senso dipendente dall'azienda fornitrice del sistema che si garantisce così un introito economico più o meno costante nei servizi post-vendita. Questo lavoro oggetto della tesi ha previsto per sommi capi la costruzione di un sistema cluster HA costituito da due nodi Supermicro SuperServer 6023P-i 2, da inserire nella rete informatica della sezione di Bari dell' Istituto Nazionale di Fisica Nucleare (INFN). Tale sistema dovrà fornisce due servizi in alta disponibilità costituenti un server di posta basato su sendmail 3 e un server DNS (Domain Name Service) basato su bind 4. La soluzione realizzata prevede l'utilizzo di soli componenti software di tipo open-source che caratterizzati dalla licenza GPL5 sono generalmente gratuiti, a sorgente aperto e disponibile, quindi modificabili, ridistribuibili anche dietro pagamento nei termini previsti dalla licenza stessa. Risulta quindi evidente come ogni soggetto che voglia implementare una soluzione di cluster in alta disponibilità può sfruttare le proprie risorse interne per progettare il sistema in ogni sua parte o eventualmente accedere alla comunità open-source per acquisire le nozioni o le competenze necessarie per costruirsi il proprio sistema personalizzato. 1.5.1 Il sistema operativo Il componente del sistema più indispensabile è ovviamente il sistema operativo. Per la scelta di questo componente sono state valutate diverse alternative ognuna con le sue diverse peculiarità e lati negativi; comunque la 2 Per la descrizione completa dell'hardware si consulti il prossimo capitolo 3 Sendmail è un server di posta molto diffuso nei sistemi *NIX e caratterizzato dalla licenza GPL 4 bind è un server DNS open-source con licenza GPL diffuso su sistemi *NIX 5 General Public Licence: testo integrale in appendice 14

scelta ha escluso a priori sistemi proprietari e closed source primo fra tutti Microsoft Windows. Le alternative prese in considerazione sono state quindi di tipo open source e hanno visto coinvolti sistemi Linux, nelle sue diverse distribuzioni, e le diverse varianti di BSD. Si sono considerate le diverse caratteristiche positive riguardanti i sistemi BSD prima fra tutte la sicurezza, che caratterizza in particolare il sistema OpenBSD, ma sono state considerate anche situazioni negative, come il supporto della comunità open-source, molto più limitato rispetto ad un sistema Linux; inoltre da ricerche effettuate sulla rete si è riscontrato che ci sono già state esperienze riguardanti sistemi HA basati su Linux da cui eventualmente si potrebbe attingere o fare riferimento in caso di necessità future. La scelta finale è dunque caduta su un sistema Linux. Fra le diverse e numerosissime distribuzioni di Linux presenti nel panorama della comunità open-source è stata scelta la distribuzione Gentoo6. Rispetto alle altre, questa distribuzione ha la caratteristica di essere fornita in linea preferenziale in formato sorgente, il che implica che l'utente deve eseguire la compilazione dell'intero sistema prima di poterlo utilizzare7. Questa modalità ha come effetto negativo il fatto che spesso la compilazione, specie se di tutto il sistema, richiede molto tempo. Si intuisce però che è possibile ottenere un sistema operativo personalizzato per le proprie esigenze, nel senso che è possibile scegliere cosa compilare e installare. Un vantaggio ancora più grande è che il sistema risultante è specificamente creato per la macchina su cui gira, ed è quindi ottimizzato in termini di prestazioni e stabilità in quanto sfrutta tutte le caratteristiche dell hardware. Non si pensi però che Gentoo sia una distribuzione orientata specificamente ad utenti avanzati in quanto l'installazione del software non è più complicata che impartire da shell il comando emerge nome-pacchetto, dove nome-pacchetto è il 6 7 Gentoo: www.gentoo.org, www.gentoo.it Sono comunque disponibili versioni precompilate di tutto o parte del sistema per le architetture più diffuse. 15

9nome del software che si intende installare e presente nel portage8 di Gentoo. A corredo di tutto, sono inoltre disponibili numerosissime guide in lingua italiana presso www.gentoo.it. La descrizione di tale installazione per il sistema oggetto di questa tesi è dettagliata nel capitolo 2. 1.5.2 Gestore del File-system condiviso Altro elemento fondamentale di un sistema in HA è il file system. E' chiaro che un comune file system per sistemi singoli non è assolutamente appropriato in quanto per un cluster in HA il file system deve avere funzionalità avanzate e particolari, comunque non necessarie e non applicabili ai sistemi di elaborazione classici. Tipicamente un file-system dedicato a cluster in alta disponibilità deve essere tale da garantire funzionalità di recovering dei dati indispensabile nei casi in cui una situazione di crash si verifica in concomitanza con gli accessi alle memorie di massa. La politica di gestione di questa funzionalità è comunque differente a seconda delle tipologie dell'hardware che si intende acquistare/utilizzare. Il sistema di memorizzazione di massa infatti può essere di due tipi: possiamo avere un sistema di dischi centrale, separato dai due nodi ma al quale questi possono accedere contemporaneamente mediante canale SCSI o fiber-channel, oppure un sistema di memorizzazione distribuito sui vari nodi che utilizzi i dischi montati all interno delle macchine coinvolte. Quest'ultimo tipo di memorizzazione di massa è quello utilizzato per questo cluster ed è basato sul software DRBD scritto da Philipp Reisner9. L'aspetto positivo principale di un file-system distribuito consiste nel fatto che i costi necessari per far sì che il file system non introduca nel sistema un single point of failure sono molto piccoli. Infatti un crash in un sistema di dischi 8 Portage è il database on-line delle applicazioni installabili automaticamente col comando emerge. Tale database comprende attualmente più di cinquemila pacchetti, per un totale di più di 9 Gb di dati, numero in rapida crescita considerando anche il tempo relativamente breve da quando Gentoo si è inserita nel panorama delle distribuzioni Linux 9 Philipp Reisner: philipp.reisner@linbit.com 16

centrale condiviso comprometterebbe l'intero sistema, e realizzare l alta disponibilità di un array di dischi, seppure possibile, è molto costoso. L'aspetto negativo consiste in una riduzione delle prestazioni nell'input-output dei dati. Nel caso in esame questo limite non incide in modo significativo sulla bontà del sistema, in quanto non si dovrà gestire un flusso di dati molto oneroso. Tecnicamente DRBD è un modulo del kernel che mette a disposizione dei nodi, tipicamente due, uno (o più) block device distribuito su entrambi i nodi e quindi accessibile da entrambi. Ogni block device è formato da due partizioni residenti rispettivamente su entrambi i nodi nelle quali i dati vengono replicati. In tal modo anche se un nodo cade, l'altro ha comunque la possibilità di accedere ai dati replicati sulla sua partizione e quindi continuare a lavorare. Le politiche di replicazione dei dati sono gestite secondo tre protocolli che bilanciano più o meno prestazioni e affidabilità. La scelta di tali protocolli va fatta in base alle esigenze che si hanno e all'hardware che si dispone. Per quanto riguarda l'accesso ai dati consentito da DRBD, per garantire costantemente l'integrità dei dati i nodi non possono effettuare contemporaneamente operazioni di scrittura. Vengono perciò stabiliti dei ruoli fra i due nodi: il nodo abilitato alla scrittura viene definito primario mentre l'altro è detto secondario. Il nodo secondario non può comandare operazioni di scrittura sui block device ma solo scrivere sulla sua partizione la replica dei dati al comando del nodo primario. L'algoritmo del DRBD gestisce tutte le situazioni in cui si verificano crash dei nodi primario o secondario con opportuno cambio dei ruoli, al fine di garantire sempre l'integrità dei dati e limitare al minimo l'intervento dell'amministratore, favorendo per quanto possibile una fornitura pressoché continua dei servizi offerti dal cluster. 17

Le funzioni assolte da DRBD in un sistema di cluster HA sono principalmente quattro e cioè: Garantisce che non ci sia nessuna perdita di dati in caso di caduta (crash) di un nodo. Questo è, anzi dovrebbe essere, un elemento obbligatorio in un sistema HA ma spesso viene trascurato per favorire un incremento in prestazioni. Rende possibile aggiungere un nodo al cluster, ad esempio per rimpiazzare una macchina compromessa, senza interruzione dei servizi. Anche questo è un elemento importante che garantisce l'alta disponibilità in quanto l'obiettivo fondamentale è proprio quello di non interrompere la fornitura dei vari servizi. Può determinare quale nodo possiede i dati più aggiornati. Dato che questo sistema è caratterizzato dalla replicazione dei dati sui diversi nodi, vi è dunque il problema di determinare quale dei nodi possiede i dati più aggiornati e quindi su quale di essi continuare a lavorare. Con DRBD si può riavviare il cluster in modalità degradata10 senza l'intervento dell'amministratore. In alternativa a DRBD si potrebbe prevede l'uso di una soluzione ibrida formata dall'insieme di NBD+Raid 111. In questa soluzione le funzioni di esportazione dei dati vengono eseguite da NBD che rende disponibile un block-device di rete fra i due nodi sul quale opera il Raid 1 software per rendere disponibili i meccanismi di replicazione dei dati. Si è però preferito l uso di DRBD sia perché creato specificatamente per cluster HA a due nodi, sia perché rende disponibili funzionalità di gestione e configurazione pensate proprio per cluster HA. A tal proposito si veda il file drbd.conf, presente in appendice, opportunamente creato per il sistema oggetto della tesi. 10 11 La modalità degradata è definita tale quando un cluster formato da due nodi continua a funzionare con un nodo solo. NBD: Network block device 18

1.5.3 Software di gestione del cluster Al fine della realizzazione specifica del cluster HA, questo elemento è il componente più importante del sistema in quanto è quello che rende l'insieme di componenti finora descritto un cluster HA. Esso si occupa della gestione delle risorse disponibili nel sistema e del controllo dei componenti finora descritti. Anche in questo caso le alternative disponibili sono state diverse e tutte le soluzioni offrivano più o meno le stesse caratteristiche, ma la scelta è stata operata tenendo in considerazione la piena compatibilità con DRBD, il gestore del file-system. I pacchetti considerati sempre ovviamente open-source sono stati Kimberlite, LinuxFailSafe ed HeartBeat. E' stato scelto quest'ultimo, in quanto in grado di operare in stretta combinazione con DRBD. HeartBeat si basa su un meccanismo molto semplice ma allo stesso tempo molto efficace. Attraverso il programma heartbeat, a brevi intervalli i nodi si scambiano messaggi di stato continuamente, come un battito cardiaco che interrompendosi denota la morte di uno dei nodi. Ovviamente HeartBeat è in grado di accorgersi di questo evento e agire di conseguenza. I nodi vengono connessi fra loro attraverso l'interfaccia ethernet per scambiare i messaggi di stato e per esigenze legate al funzionamento in cluster; le interfacce sono configurate con indirizzi IP privati destinati esclusivamente alla comunicazione interna12. I messaggi possono però essere inviati anche attraverso un'altra interfaccia ethernet o attraverso un collegamento seriale fra i nodi. La replicazione si rende necessaria per eliminare il single point of failure nel caso in cui ci fosse un unico collegamento interno e questo si interrompesse. Ad ognuno dei nodi risulterebbe essere 12 Per l'inetrfacciamento esterno i nodi sono forniti di un'altra interfaccia ethernet come si evince dalla descrizione dell'hardware presentata nel prossimo capitolo. 19