UNIVERSITA' DEGLI STUDI DI BARIFACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI

CORSO DI LAUREA IN INFORMATICA

TESI DI LAUREA INSISTEMI PER L'ELABORAZIONE DELL'INFORMAZIONE:

SISTEMI DISTRIBUITI

UN CLUSTER IN ALTADISPONIBILITÀ IN AMBIENTE LINUX

RELATORI:Chiar.mo Prof. S. PIZZUTILOdott. D. DIACONO

LAUREANDO:Sabino CALÒ

ANNO ACCADEMICO 2003/2004

INDICE GENERALE

INTRODUZIONE................................................................................4

CLUSTER: GENERALITA'..................................................................71.1 Architettura.................................................................................................. 81.2 High Performance Computer e High Availability.................................101.3 Il software libero....................................................................................... 121.4 Progetti Open-Source per cluster di calcolo.......................................... 131.5 Progetti Open-Source di cluster HA...................................................... 13

LINUX: INSTALLAZIONE KERNEL.............................................. 212.1 L'Hardware................................................................................................ 212.2 L'installazione del sistema operativo....................................................... 23

L'ALTA DISPONIBILITA' (HA)........................................................433.1 Livelli di disponibilità............................................................................... 443.2 Requisito dei cinque 9.............................................................................. 463.3 Le prestazioni............................................................................................ 483.4 Tipologie di cluster................................................................................... 49

IL CLUSTER REALIZZATO IN QUESTA INSTALLAZIONE......524.1 Elementi fondamentali: una visione panoramica.................................. 534.2 Schema di progetto................................................................................... 554.3 Heartbeat .................................................................................................. 60

L'INSTALLAZIONE E CONFIGURAZIONE DEL FILE-SYSTEM:DRBD...................................................................................................64

5.1 Tipologie di storage.................................................................................. 645.2 Il file-system utilizzato nel setup: motivi della scelta............................ 675.3 DRBD: caratteristiche e peculiarità........................................................ 705.4 Performance.............................................................................................. 835.5 Installazione e configurazione DRBD................................................. 1015.6 Alta disponibilità della rete interna ...................................................... 104

2

HEARTBEAT: SUITE PER L'ALTA DISPONIBILITA'................ 1086.1 La struttura modulare di Heartbeat...................................................... 1086.2 Il Resource Group.................................................................................. 1146.3 Installazione e configurazione............................................................... 1156.4 Gratuitous ARP...................................................................................... 122

STRUMENTI DI MONITORAGGIO E TEST DEL SISTEMA..... 1247.1 Mon.......................................................................................................... 1247.2 Webmin................................................................................................... 1287.3 Swatch...................................................................................................... 1307.4 Test del sistema....................................................................................... 132

APPENDICE......................................................................................140

File di configurazione..........................................................................141A1. /etc/fstab............................................................................................... 141A2. /etc/make.conf...................................................................................... 141A3. /etc/lilo.conf.......................................................................................... 144A4. /usr/src/linux/.config.......................................................................... 144A4 /etc/conf.d/net...................................................................................... 150A5. /root/.bash_profile............................................................................... 150A6. /root/.bashrc......................................................................................... 151A7. /etc/drbd.conf....................................................................................... 151A8. /etc/ha.d/haresources.......................................................................... 152A9. /etc/ha.d/ha.cf...................................................................................... 152A10. /etc/mon.d/mon.cf............................................................................ 152A11. /etc/mon.d/auth.cf............................................................................. 153A12. /root/.swatchrc................................................................................... 153A13. Script mon http.alert........................................................................... 154A14. 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 “gratuitous-

ARP”. 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

C a p i t o l o 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 ArchitetturaUn 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 client-

server.

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 AvailabilityE’ 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 liberoE' 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 delsistema operativo sviluppato originariamente da Linus Torvalds, la seconda indica invece l'insieme delkernel Linux e di svariati programmi open-source facenti capo al progetto GNU il cui padre è RichardStallman. Spesso questo insieme più o meno esteso può essere una “distribuzione Linux” creata dachiunque ed eventualmente messa in vendita. A volte si dice “Linux” per riferirsi erroneamente ad unaintera 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 calcoloLa 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 HAUn 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 capitolo3 Sendmail è un server di posta molto diffuso nei sistemi *NIX e caratterizzato dalla licenza GPL4 bind è un server DNS open-source con licenza GPL diffuso su sistemi *NIX5 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 Gentoo: www.gentoo.org, www.gentoo.it 7 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. Taledatabase 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 La modalità degradata è definita tale quando un cluster formato da due nodi continua a funzionarecon un nodo solo.

11 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 essere12 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

l'unico nodo rimasto del cluster e ognuno quindi comincerebbe a fornire

esattamente gli stessi servizi, generando incongruenze nei dati e confusione

generale. Questo è il cosiddetto fenomeno del “Brain-splitting”. Duplicando i

canali di connessione interna attraverso cui scambiare i messaggi di stato si

riduce la probabilità che si verifichi il brain-splitting perché diventa più

difficile l'interruzione contemporanea di più canali di comunicazione specie se

di natura diversa come l'ethernet e il collegamento seriale.

20

C a p i t o l o 2

LINUX: INSTALLAZIONE KERNEL

In questo secondo capitolo si analizza l'installazione del sistema. Come già

specificato, il sistema operativo su cui verrà basato l'intero cluster in alta

disponibilità è Linux e su di esso verranno installati i diversi pacchetti

software che consentono lo svolgimento delle funzioni tipiche di un sistema

in alta disponibilità.

Prima di proseguire però è doveroso specificare le caratteristiche hardware

delle macchine su cui il sistema verrà costruito.

2.1 L'HardwareLe due macchine, identiche, su cui il sistema viene installato sono basate sulla

piattaforma intel e processori Pentium 4 Xeon.

Nel “case” con fattore di forma 2U13, è montata una scheda madre basata sul

chipset intel E7501 abilitata ad ospitare contemporaneamente due processori

[5]. Per la configurazione utilizzata ne è stato montato soltanto uno, per il

motivo che ad un cluster HA non è richiesta una eccessiva potenza di calcolo.

Il processore utilizzato, come anticipato, è un pentium 4 xeon da 2 Ghz con

tecnologia HyperTreading14 che consente al kernel del sistema operativo di

13 2U: indica 2 unità dove 1 unità è lo spessore standard dei case adatti al montaggio in rack.14 HyperTreading(HT): tecnologia proprietaria sviluppata da intel che grazie ad una gestione intelligente

della pipeline di esecuzione della CPU rende possibile l'esecuzione contemporanea di alcune istruzionimacchina.

21

operare in modalità SMP15. Tale processore è coadiuvato da una cache L2 di

512Kb ed è caratterizzato da un FSB16 funzionante a 400 Mhz.

La memoria centrale RAM è costituita da 1GB di memoria DDR17 con

tecnologia ECC18, sufficiente per gli scopi cui il cluster è destinato.

Come tutte le unità di questo tipo la sezione grafica è ridotta all'indispensabile

in quanto non sono necessarie funzionalità avanzate.

Al contrario la connettività del sistema è garantita da due interfacce di rete

ethernet con velocità di 1Gb/sec. direttamente integrate sulla scheda madre,

presenti inoltre una porta seriale e una parallela, due porte USB oltre che le

classiche porte per mouse e tastiera PS/2.

Le periferiche di memorizzazione di massa comprendono un lettore CD-

ROM, lettore di floppy-disks e 4 Hard-Disk EIDE da 60 Gb ciascuno.

Tali Hard-disk sono collegati a un controller Adaptec 2400A che effettua il

RAID hardware. Le quattro unità sono configurate in questo modo: tre dischi

sono gestiti in Raid 5 mentre il quattro è in modalità hot-spare che il

controller automaticamente inserisce nel raid quando uno dei tre va in errore.

In tale evenienza, l'unità guasta viene esclusa automaticamente dal raid e viene

chiesto l'intervento dell'amministratore per la sostituzione fisica del

dispositivo guasto. Dopo la sostituzione la nuova unità viene configurata

come unità di hot-spare.

15 SMP: (Simultaneous Multi Processing) consente l'esecuzione contemporanea di istruzioni nei diversiprocessori disponibili.

16 FSB: (Front Side Bus): canale di comunicazione fra il chipset della scheda madre e il processore. Più èalto la frequenza di funzionamento, più si riduce il collo di bottiglia che c'è nel flusso di dati fra ilprocessore e il resto del sistema.

17 DDR: (Double Data Rate) tipo particolare di memoria sincrona che sfrutta il collegamento con ilchipset a doppio fronte. In parole povere il flusso di dati è raddoppiato per ogni ciclo di clock rispettoalle vecchie memorie a singolo fronte.

18 ECC: (Error Correction Code) particolare tecnologia che caratterizza le memorie più costose. Riducedrasticamente gli errori di paginazione della memoria rendendo il sistema più stabile.

22

La dissipazione del calore interno al case è invece affidata a quattro ventole da

8 cm in costante rotazione a pieni giri. Sono presenti inoltre sensori termici

che attivano allarmi luminosi e acustici in caso di guasti alle ventole e

conseguente aumento della temperatura a salvaguardia dei componenti interni

che si danneggerebbero in caso di surriscaldamento eccessivo.

2.2 L'installazione del sistema operativoQuesta parte importante del processo di installazione del cluster è iniziata il

18 novembre 2003 data in cui l'ultima versione della distribuzione Linux

scelta, Gentoo, era la 1.4. Si tenga comunque in considerazione il fatto che in

ogni momento è possibile aggiornare l'intero sistema alle ultime versioni di

tutti i pacchetti, presenti nel sito ufficiale www.gentoo.org e relativi mirror

attraverso il comando emerge -Dup world19.

Il processo di installazione del sistema può essere suddiviso in diverse fasi che

possono essere assimilate ai diversi livelli di astrazione via via crescenti che si

andranno a costruire.

2.2.1 Fase 1: avvio e creazione del file system

Il processo di installazione di ogni distribuzione Linux può essere eseguito in

diversi modi che fra gli altri comprendono l'installazione via rete (locale o

Internet). Il metodo classico rimane comunque il più diffuso e semplice, e

prevede l'utilizzo dei cd di installazione. Come già detto Gentoo è una

distribuzione diversa dalle altre in quanto consente di installare il sistema

compilando il software “ad hoc” sulla macchina stessa. Questa capacità rende

necessario il concetto di “stage” di installazione descritto qui di seguito.

L'installazione di Gentoo è suddivisa in tre fasi successive che vengono

denominate “stage”. In ognuno di tali stage viene compilata e installata una

19 Eventualmente prima di tale comando si può aggiornare il database locale dei pacchetti delladistribuzione con emerge sync. Tale aggiornamento può richiedere davvero molto tempo per cuisiconsideri anche l'ipotesi di eseguire un aggiornamento manuale dei soli pacchetti per cuil'aggiornamento è indispensabile.

23

porzione di sistema, a partire dallo stage 1 in cui si compila lo stesso

compilatore C e le relative librerie, fino allo stage 3 in cui è già tutto

precompilato tranne le applicazioni particolari non indispensabili all'utilizzo di

base del sistema operativo.

Vengono pertanto forniti da Gentoo tre files relativi ai diversi stage, per cui

nel file “stage1[...].tar.gz” è fornita una versione minimale del sistema

operativo che consente di effettuare la compilazione dei componenti di base

quali le librerie “glibc” usate dal compilatore C e lo stesso compilatore

“gcc”20; nel file “stage2[...].tar.gz” si trovano invece le versioni precompilate

del compilatore e relative librerie; il file “stage3[...].tar.gz comprende le

versioni precompilate del compilatore, dei principali server fra cui Xfree, e dei

diversi pacchetti applicativi che consentono di avere a disposizione un sistema

operativo perfettamente funzionante e completo di applicazioni di base.

Installando Gentoo quindi ci si trova nella condizione di dover scegliere da

quale stage partire, tenendo presente che ogni file di stage contiene quello

precedente in versione generica precompilata e considerando le potenzialità

della macchina su cui si effettua l'installazione in relazione al tempo

necessario a terminare il processo.

Si consideri infatti che la compilazione delle “glibc” su una macchina di media

potenza, basata ad esempio su un processore da 2 Ghz, richiede in media

circa 4 ore di elaborazione.

Nella installazione Gentoo Linux del sistema HA realizzato, si è scelto di

partire dallo stage 1 e dunque di ricompilare per intero il sistema in quanto,

come già descritto nel paragrafo relativo all'hardware, le capacità di

elaborazione delle macchine sono tali da poter garantire tempi di

compilazione non molto elevati. 3Inoltre, dato che le macchine sono collegate

costantemente alla rete Internet con collegamento via cavo alla velocità di

16Mbit minimi fornita dal GARR, si è preferito sfruttare questa opportunità

20 La versione del compilatore installata è la recente 3.2

24

per installare le versioni più aggiornate dei pacchetti, scaricate direttamente

dai mirror Gentoo.

Il primo passo compiuto per iniziare il processo di installazione è stato quello

di scaricare e masterizzare su un CD riscrivibile l'immagine del “liveCD”21

base avviabile (meno di 100 Mb) dal sito gentoo.org contenente il solo stage 1

del processo di installazione.

Si tenga presente che il processo di installazione descritto di seguito è stato

eseguito solo su una delle due macchine del cluster perchè, come sarà

spiegato in seguito, l'intera installazione è stata poi replicata attraverso una

copia fisica dei dati sull'altra macchina per avere così due installazioni

praticamente identiche.

Il disco avviabile creato è stato utilizzato nella fase di boot della macchina22

per avviare il sistema operativo (una Linux box essenziale) in esso presente.

Prima del “bootstrap” del sistema operativo si è provveduto a passare al

kernel alcune opzioni per informarlo di alcune caratteristiche peculiari del

sistema in oggetto in modo tale da potersi adattare all'ambiente in cui si stava

installando.

Le opzioni passate al kernel sono: smp che specifica al kernel di usare la

capacità di parallelismo dei processi per sfruttare la tecnologia Intel HTT23

presente nel processore installato; dokeymap necessaria per eseguire il mapping

della tastiera in modo tale da poter specificare successivamente il codice 21

relativo alla tastiera italiana[8].

21 LiveCD: termine per riferirsi a un CD contenente il sistema operativo Linux utilizzabile direttamenteda CD senza la necessità di dover scrivere alcunchè su eventuali dischi rigidi presenti nella macchina.

22 Questa fase prevede l'inserimento del cd avviabile prima che la macchina si riavvii cosìcchè attivandoopportunamente le opzioni del BIOS il boot del sistema viene eseguito direttamente da CD.

23 HTT: Hyper Threading Tecnology si veda il paragrafo relativo all'hardware.

25

A questo punto il sistema di installazione è attivo e si è provveduto a

inizializzare la rete in modo tale da poter eseguire il download dei diversi

pacchetti richiesti al sistema “portage”.

La prima cosa da fare per procedere con l'installazione e terminare la fase 1 è

preparare il “terreno” su cui andare a installare il nuovo sistema operativo. Per

fare questo dunque si deve eseguire un partizionamento del disco24 secondo

uno schema ben architettato che si analizzerà fra breve.

Per eseguire il partizionamento si è usato il tool di sistema “cfdisk”[6], che è

uno strumento interattivo funzionante all'interno della shell che consente la

creazione, modifica o rimozione delle partizioni logiche e fisiche degli hard

disk presenti nel sistema.

Questo tool è molto simile al più famoso, “fdisk”, il quale però essendo più

vecchio, è anche molto spartano in termini di usabilità, tale da poter indurre

errori in questa fase importantissima quanto delicata.

Lo schema di partizionamento è quello specificato nella seguente tabella:

24 Benchè nelle macchine sono presenti quattro dischi rigidi EIDE si parlerà comunque di unico disco inquanto il sistema di RAID hardware è configurato in modo tale da mostrare un unico disco eutilizzare invece il sistema di memorizzazione per assolvere alle funzioni di replicazione dovute allaconfigurazione particolare. Si veda il capitolo relativo all'hardware.

26

Nomepartizione

Dimensione(Mb)

Mount point Tipo Opzioni

sda1 100 /boot ext2 noautosda2 2000 swapsda3 10000 / ext3 noatimesda5 10000 /usr ext3 noatimesda6 2000 /var ext3 noatimesda7 2000 /tmp ext3 noatimesda8 10000 /opt ext3 noatimesda9 10000 /home ext3 noatimesda10 10000 /bind ext3 noatimesda11 10000 /sendmail ext3 noatime

Tabella 1: Schema di partizionamento

Si noti che i nomi delle partizioni sono quelli tipici dei dispositivi SCSI.

Questo avviene a causa della presenza del controller RAID Adaptec 2400A.

Dopo aver creato le partizioni secondo lo schema indicato, si è provveduto a

creare i file systems su ogni partizione in particolare:

mkswap /dev/sda2 per la partizione di swap

mkfs /dev/sda1 per la partizione /boot

mkfs -j /dev/sdax sostituendo a x ogni numero di partizione di tipo ext3 come

specificato in tabella.

Fatto questo si è provveduto ad attivare la partizione di swap col comando

swapon /dev/sda2 e a montare le diverse partizioni ai rispettivi mount point con

il comando mount /dev/sdax /mnt/gentoo/path dove /path corrisponde al

percorso relativo a ogni partizione come specificato nella tabella 1.

27

2.2.2 Fase 2: Compilazione del sistema base

Se le operazioni compiute finora possono essere analoghe all'installazione di

qualsiasi Linux box ciò che segue è tipico della sola installazione di Gentoo;

infatti il prossimo comando provvede a copiare il file compresso relativo allo

stage 1 dell'installazione dal CD autopartente alla directory /mnt/gentoo.

Il comando è cp /mnt/cdrom/stages/stage1* /mnt/gentoo

L'operazione successiva attraverso il comando

tar -jxvpf stage1*

espande invece il file dello stage 1 inserendo nei percorsi opportuni i file che

costituiscono il sistema base dal quale si farà partire la ricompilazione25.

Come è stato più volte ribadito, Gentoo può definirsi una meta-distribuzione

in quanto viene ricompilata sulla macchina per la quale si effettua

l'installazione. I sorgenti dei diversi pacchetti vengono scaricati direttamente

da internet e quindi sempre nelle versioni più aggiornate. Per poter eseguire

però questa operazione è necessario far conoscere al sistema dove andare a

cercare i diversi pacchetti. E' questo lo scopo del comando successivo:

mirrorselect -a -s4 -o >>/mnt/gentoo/etc/make.conf

che si occupa di ricercare sulla rete Internet i diversi mirror26 che contengono

i files Gentoo, aggiornando il file make.conf, analizzato più avanti.

Viene poi montato il file-system speciale “proc”27 con

25 I pacchetti copiati in questa fase sono precompilati in modo standard e saranno sovrascritti durante ilprocesso di ricompilazione con le versioni compilate ad hoc.

26 Un mirror è una copia speculare di un sito internet. I mirror vengono spesso usati per siti FTP checontengono files che vengono scaricati spesso, al fine di non sovraccaricare i server.

27 IL file-system proc è uno strumento speciale usato da Linux per tenere traccia di tutte le informazioniriguardanti lo stato attuale di funzionamento del sistema. E' costituito come un insieme di file permantener fede alla filosofia che caratterizza Linux in cui “tutto è un file”.

28

mount -t proc proc /mnt/gentoo/proc

e copiato il file “resolv.conf”, con

cp /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

contenente gli indirizzi dei server DNS configurati in fase di boot per poter

essere raggiunti anche dopo aver eseguito il comando successivo

chroot /mnt/gentoo /bin/bash che modifica il percorso di esecuzione dei

comandi alla directory /mnt/gentoo [6].

A questo punto la directory radice del sistema è /mnt/gentoo per cui tutte le

modifiche apportate sono relative ai file sotto tale percorso e quindi anche a

quello che sarà il sistema operativo finale della macchina.

Si può ora aggiornare l'ambiente di gentoo col comando

env-update seguito da

source /etc/profile,

e si può ora procedere a scaricare il database dei pacchetti gentoo che è stato

definito portage.

L'operazione che segue consente di tenere sempre aggiornato tale database

con i nuovi pacchetti aggiunti. Questa operazione andrebbe eseguita

periodicamente al fine di ottenere un sistema sempre aggiornato e quindi più

stabile malgrado il tempo richiesto per completare l'operazione non sia

brevissimo causa il download di migliaia di piccoli files.

Il comando per eseguire il download o l'aggiornamento del portage è

emerge sync.

29

A questo punto manca veramente poco all'inizio della compilazione del

sistema operativo e ciò che occorre fare adesso è la modifica del file /

etc/make.conf che contiene le informazioni necessarie ad effettuare la

compilazione.

Se gentoo compila il software tenendo conto delle caratteristiche peculiari

della macchina è proprio grazie alle opzioni specificate nel file make.conf; esso

infatti va modificato al fine di impostare alcune variabili che il sistema userà

per eseguire la compilazione. Tali variabili sono relative al tipo di processore,

ai percorsi in cui è installato il portage e agli indirizzi internet dei mirror

gentoo da cui scaricare i sorgenti del software per altro impostati

automaticamente dal comando “mirrorselect” eseguito poc'anzi.

Ora viene eseguita la compilazione del sistema operativo. Questa operazione

richiede tempo perché, partendo dallo stage 1, verranno compilati, con le

opzioni più adeguate, i componenti più interni del sistema operativo fra cui lo

stesso compilatore e le relative librerie.

Può sembrare strano o paradossale “compilare il compilatore” ma in effetti

non è così.

Questa infatti è la prima delle attività di compilazione. In questa fase il

compilatore generico, fornito per altro nel live-cd, compila i sorgenti di se

stesso con le opzioni più adeguate specificate in /etc/make.conf e sostituisce i

binari28 così generati a quelli generici forniti col live-cd e usati fino a questo

momento. Al termine di questa fase il sistema di installazione procede a

compilare e installare gli altri pacchetti di sistema.

I comandi necessari a completare questa fase dell'installazione sono

sh /usr/portage/scripts/bootstrap.sh e emerge system.

28 Col termine “binario” si intende la versione compilata in linguaggio macchina di un programma equindi direttamente eseguibile.

30

2.2.3 Fase 3: installazione del sistema base e utility di sistema

Lo stato attuale dell'installazione, dopo un lungo periodo dedicato alla

compilazione, ci presenta un sistema che manca della parte più caratteristica e

fondamentale: il kernel.

Tradotto alla lettera kernel sta a significare nucleo e in effetti il kernel è

considerato proprio il centro del sistema software, a diretto contatto con

l'hardware nei confronti del quale ha funzioni di interprete delle richieste,

provenienti dagli strati del sistema più esterni.

Un'immagine che può aiutare molto a capire la natura estremamente

modularizzata del sistema operativo Linux è la metafora della “cipolla”. Come

ben si sa, la cipolla è costituita da diversi strati uno nell'altro: al centro

troviamo l'hardware, immediatamente sopra c'è il kernel, poi il software di

sistema e ancora esternamente troviamo i programmi applicativi usati dagli

utenti abituali del sistema. Si nota quindi che ogni strato è un livello di

astrazione che fa da interprete fra lo strato esterno e quello interno e rende

possibile così l'astrazione funzionale che consente all'utente umano di usare la

macchina “computer” senza parlare il suo linguaggio criptico e poco

naturale29.

Quindi a questo punto, sistemate alcune configurazioni quali l'aggiornamento

del file /etc/fstab secondo il partizionamento del disco fisso specificato in

tabella 1 e la configurazione delle impostazioni geografiche col comando

ln -s /usr/share/zoneinfo/Europe/Rome /etc/localtime, si è provveduto al

download e alla configurazione del kernel.

29 Nota storica: agli albori della scienza informatica, la programmazione era un compito estremamentearduo e noioso che poteva essere svolto solo da pochi specialisti. Questo era dovuto al fatto che nonerano stati ancora concepiti i livelli di astrazione più esterni al kernel e quindi tali guru informatici“dialogavano” coi computer direttamente in linguaggio macchina che poi diventò Assembler e allafine C fino ad arrivare, ai giorni nostri, ad ambienti di sviluppo visuali che hanno reso possibile ilRAD: Rapid Application Development, che fa uso di istruzioni di livello elevatissimo quasi inlinguaggio naturale ognuna delle quali si traduce in tantissime istruzioni del “vecchio”, sottostante,linguaggio macchina.

31

Nel portage di gentoo sono presenti diverse versioni del kernel

opportunamente configurate a seconda dei diversi utilizzi o delle versioni del

kernel stesso.

Per il sistema in oggetto è stato scelto il kernel “vanilla” e installato col

comando

emerge vanilla-sources.

A questo punto sono stati installati i file sorgenti del kernel che devono poi

essere opportunamente configurati e compilati dall'utente-amministratore che

sta installando il sistema.

La distribuzione gentoo mette a disposizione un'utility di sistema per svolgere

velocemente la configurazione e installazione del kernel. L'utility è

“genkernel” ed è stata installata col comando

emerge genkernel.

Dopo il download e l'installazione di “genkernel” si è provveduto a lanciare il

comando genkernel --config ed effettuare la configurazione del kernel

specificando ad esempio il tipo di processore (Pentium 4) ed eliminando

successivamente tutti i driver relativi a periferiche non presenti nel sistema30.

Dopo aver salvato la configurazione nel file “/usr/src/linux/.config” l'utility

“genkernel” ha provveduto alla compilazione del kernel ora configurato, dei

moduli relativi, che si è scelto di creare in fase di configurazione, e ad

installare il tutto nei corretti percorsi di installazione.

Il kernel del nuovo sistema è ora presente e tecnicamente si può affermare

che ora il sistema operativo è effettivamente presente, dato che il kernel è in

grado di gestire la macchina in tutte le sue funzionalità senza l'ausilio di

ulteriori programmi. Sarebbe tuttavia impensabile, benchè possibile, utilizzare30 Si definisce driver un particolare programma del sistema operativo necessario per interfacciare il

sistema con l'hardware specifico. Per i dettagli circa i driver configurati nel kernel si veda il listato delfile “.config” presente in appendice.

32

un sistema informatico in questo stato, sia per la difficoltà delle operazioni

necessarie, sia per la mancanza di alcune funzionalità di protezione che

evitano all'utente non esperto di compromettere il funzionamento del sistema

e non permettono a malintenzionati di eseguire operazioni potenzialmente

dannose.

La prima delle funzioni di base totalmente automatiche che è stata installata è

la funzionalità di “hotplug”.

Con questa funzionalità si attiva la capacità della macchina di riconoscere e

configurare automaticamente dispositivi esterni che possono essere collegati

al sistema durante il normale funzionamento, quindi senza la necessità di

eseguire il riavvio.

I comandi utilizzati per installare “hotplug” e avviarlo ad ogni boot del

sistema sono i seguenti: emerge hotplug; rc-update add hotplug default.

Altro strumento indispensabile per un sistema multiutente che deve avere

funzionalità di server presente tradizionalmente in tutti i sistemi unix-like è il

“logger”.

Questo strumento si occupa di memorizzare nei cosiddetti “file di log”, creati

in una locazione predefinita del file-system (che solitamente è “/var/log”), tutti

i messaggi di stato o di errore che ogni singolo programma in esecuzione

solitamente emette [6]. Un logger è uno strumento indispensabile in quanto

normalmete in un sistema Linux sono solitamente attivi diversi programmi e

per sistemi server, attivi ininterrottamente, è improponibile che

l'amministratore sia costantemente presente per monitorare l'attività del

sistema. L'amministratore interviene in caso di problemi e grazie alla lettura

dei file di log riesce a risalire alla causa e a prendere i provvedimenti necessari.

33

Il comando per l'installazione del logger è emerge app-admin/sysklogd. Il logger

viene quindi aggiunto alla configurazione standard del sistema inserendolo nel

normale processo di startup col comando rc-update add sysklogd default.

Altro importante strumento da installare è un sistema di esecuzione di

comandi programmabile. Spesso si rende necessario eseguire operazioni

ripetitive a intervalli di tempo predefiniti o a scadenza periodica, ad esempio

si può pensare di eseguire un backup dei dati settimanalmente o giornalmente,

o si potrebbe pensare anche di inviare periodicamente un'e-mail

all'amministratore per aggiornarlo sullo stato attuale del sistema o quant'altro.

Per assolvere a questi compiti storicamente su sistemi Unix-like troviamo

l'applicazione cron evolutasi poi nelle diverse varianti, delle quali vcron è quella

usata in questa installazione. L'installazione è realizzata dal comando emerge

sys-apps/vcron. Anche vcron viene aggiunta al sistema base inserendola nel

processo di startup con rc-update add vcron default.

Ultimo e indispensabile tool da installare è il boot-loader.

In un sistema GNU/Linux l'avvio è gestito da un programma che si occupa

di far avviare l'immagine del kernel che si è opportunamente configurata.

Esso in pratica scrive nel primo settore del disco da cui si effettua il boot il

codice necessario per visualizzare l'interfaccia utente e successivamente

avviare l'immagine del kernel residente nella partizione di boot[6]. La

versatilità di tali strumenti permette di gestire diverse immagini del kernel

Linux eventualmente appartenenti anche a distribuzioni diverse, residenti

anche su partizioni diverse e consente di avviare sistemi operativi diversi da

Linux31.

Le alternative prese in considerazione sono lilo e grub. La scelta è ricaduta su

lilo a fronte della sua maggiore semplicità nell'installazione ma non è da

31 Avere più sistemi operativi sulla stessa macchina può essere rischioso dal punto di vista della sicurezzama spesso è la soluzione migliore se è indispensabile dover usare programmi applicativi progettatiesclusivamente per un determinato ambiente operativo

34

trascurare nemmeno grub che grazie alla sua più recente progettazione è molto

più flessibile e dispone di un ambiente operativo a shell32, da cui è possibile

impartire i comandi necessari al boot direttamente in fase di avvio del sistema

senza dover necessariamente editare i file di configurazione.

L'installazione di lilo dunque si è svolta attraverso il comando emerge lilo che ha

provveduto a scaricare i sorgenti, compilarli e installarli; successivamente si è

creato il file /etc/lilo.conf (il cui listato è presentato in appendice), affinché il

sistema carichi all'avvio l'immagine del kernel presente in /boot/,

precedentemente compilata.

Per scrivere il tutto sul primo settore del disco di avvio (MBR: Master boot

record) si è impartito il comando lilo.

A questo punto il sistema è quasi pronto. Ciò che rimane ancora da fare è

solo qualche configurazione finale riguardante la mappatura della tastiera

secondo la lingua italiana editando il file /etc/rc.conf ed inserendo la direttiva

keymap=it.

Infine è necessario configurare la rete per fare in modo che le interfacce di

rete siano automaticamente inizializzate, con la giusta configurazione ad ogni

avvio del sistema. Per lo scopo è stato impostato l'hostanme con il comando

echo freedom>/etc/hostname

ed editato il file /etc/conf.d/net (presente in appendice), affinché assegni

all'interfaccia di rete eth0 l'indirizzo IP pubblico 193.206.185.XXX, e

all'interfaccia eth1 l'indirizzo privato 192.168.0.1.

Per attivare e inizializzare automaticamente anche l'interfaccia di rete eth1 è

stato poi creato un alias a net.eth0 chiamato net.eth1 in /etc/init.d e aggiornata la

fase di boot del sistema con rc-update add net.eth0 default e rc-update add net.eth1

default per eseguire tali inizializzazioni all'avvio del sistema[3].

32 Shell: interprete dei comandi.

35

Ultimo passo prima del riavvio, è stata impostata la password di root col

comando passwd e infine, dopo aver terminato la sessione chroot attivata

all'inizio del processo di installazione (col comando exit), si è provveduto a

smontare la partizione proc con umount /mnt/gentoo/proc e tutte le altre

partizioni montate con umount -a.

Finalmente si è riavviato il sistema con il comando reboot.

2.2.3 Fase 4: Installazione del software applicativo

A questo punto il sistema è funzionante e autonomo. Si procederà perciò da

questo punto in poi all'installazione del software applicativo necessario.

Storicamente l'utilizzo di un sistema Unix prescinde dall'utilizzo di qualsiasi

interfaccia grafica. Gli utenti più esperti del sistema infatti si servono

soprattutto della shell a riga di comando.

Per l'utilizzo di questo cluster nel lavoro di tesi si è reso però necessario l'uso

di un'interfaccia grafica a finestre in previsione dell'utilizzo dell'utility pconsole,

che si occuperà di replicare lo stesso comando impartito in una finestra

dell'interfaccia grafica a entrambe le macchine del cluster attraverso

connessioni ssh33.

L'ambiente desktop scelto è KDE. Tale scelta rispetto alle alternative fra cui

la più importante è il progetto Gnome è stata operata considerando la sua

maggiore versatilità, maturità ed ergonomicità.. Giunto oggi alla versione 3.2

KDE si può considerare un prodotto ormai maturo e gli si deve gran parte

del merito per la diffusione di Linux anche su sistemi desktop. Infatti

un'interfaccia molto amichevole e graficamente molto curata, pone KDE in

diretta concorrenza con altri ambienti desktop molto più blasonati,

33 ssh: acronimo di “secure shell” ed è un elemento della suite di programmi OpenSSL che si occupa distabilire una connessione sicura, criptata e protetta da password, fra due host.

36

appartenenti a sistemi operativi commerciali. KDE come è logico, è un

prodotto assolutamente open source e totalmente gratuito.

L'installazione di KDE si è svolta col comando emerge kde-base/kdebase che

come al solito ha scaricato i sorgenti, li ha compilati e installati.

L'intero processo, a causa della grandezza dell'ambiente KDE, è durato

svariate ore.

Si è provveduto inoltre alla localizzazione dell'ambiente nella lingua italiana

attraverso emerge kde-i18n (export LINGUAS=it).

Dopo un ulteriore riavvio si sono poi operate alcune personalizzazioni

riguardanti in particolare la shell attraverso al creazione dei files

/root/.bash_profile e /root/.bashrc, che sono i file di configurazione delle

impostazioni della shell bash per l'utente root.

Nel file /root/.bash_profile che viene letto al primo avvio della shell da parte di

root si è aggiunta la riga

PATH=$PATH:/usr/X11R6/bin:/usr/kde/3.1/bin per fare in modo che gli

eseguibili contenuti nelle directory specificate possano essere avviati senza

specificare l'intero percorso. PATH infatti è la variabile di ambiente che

contiene tutti i percorsi predefiniti in cui la shell va a cercare i files da

eseguire.

In /root/.bashrc inoltre è stata inserita qualche riga di configurazione

riguardante i colori dell'output della shell e gli alias34 per alcuni comandi (cfr.

appendice).

Per completare la configurazione del sistema sono state installate alcune

migliorie grafiche al desktop manager peraltro presenti nel ramo ufficiale di

34 Alias: nome alternativo spesso definito dall'utente per riferirsi a un dato comando.

37

portage. Tali migliorie includono un tema per puntatori del mouse e un tema

per il desktop manager.

I comandi per l'installazione di tali elementi sono:

emerge thinkeramik e emerge blueglass-xcursor.

Uno dei programmi sicuramente più utilizzati in ambito cluster è pconsole.

Tale software ha la funzione di replicare i comandi impartiti da console a tutti

i nodi del cluster attraverso una connessione sicura che sfrutta ssh.

L'uso di pconsole si rende necessario in quanto nell'installazione dei

componenti che forniranno le funzioni di High Availability passa per gli stessi

comandi da impartire a tutti i nodi del cluster.

Pconsole infatti, lanciato da riga di comando con

pconsole.sh [indirizzo_IP_nodo1] [indirizzo_IP_nodo2],

apre nell'interfaccia grafica due sessioni ssh ad entrambi i nodi specificati dagli

IP ed invia loro lo stesso comando che viene digitato una sola volta nella

finestra del programma stesso. Si rende perciò indispensabile l'uso di

un'interfaccia a finestre e come è stato già visto è disponibile il server X e il

desktop manager KDE.

Sfortunatamente tale applicazione non è presente nel portage gentoo, per cui

si è resa necessaria la procedura di compilazione standard di Linux, a partire

dal codice sorgente.

Dopo aver scaricato i sorgenti di pconsole dal sito

http://www.heiho.net/pconsole/ si è provveduto alla scompattazione del

tarball e alla compilazione e installazione con i comandi

./configure; make; make install.

38

Come già specificato, pconsole utilizza la connessione di ssh ai due nodi per

replicare i comandi per cui è necessario installare anche il demone35 sshd che

fornirà il servizio di connessione criptata ai client che ne faranno richiesta.

L'installazione procede col comando emerge sshd e viene aggiunto poi tale

server alla configurazione standard con rc-update add sshd default.

2.2.4 Fase finale: replicazione dell'intera installazione sull'altro nodo.

A questo punto l'installazione del sistema base è davvero completa. Si

provvede perciò a replicare l'installazione e configurazione sull'altro nodo.

Per assolvere a questo compito generalmente si utilizzano appositi software di

installazione di cluster:ad esempio il software SIS (Systems Installation

Software) [2] è un tool integrato che consente l'installazione di Linux box già

configurate a partire da un server centrale che contiene tutte le informazioni

necessarie all'installazione.

Solitamente sistemi come questo sono comuni nelle installazioni dei cluster

adibiti al calcolo, i cosiddetti HPC (High Performance Computer), che sono

composti da un numero di nodi molto elevato (spesso dell'ordine delle

centinaia) per cui il processo di installazione diviene un passo molto

complesso che è necessario rendere omogeneo e quanto più automatizzato

possibile.

Solitamente si predispone un server centrale in cui si crea l'immagine del

sistema che deve essere installato sui diversi nodi e che poi, attraverso la

connessione di rete si provvede a trasferire ai nodi stessi. E' chiaro che

l'ampiezza di banda della rete del server è molto più grande di quella dei

35 Demone: in ambiente Linux un demone è un programma residente in memoria che assolve allefunzioni di server per un determinato scopo. Il demone sshd infatti è costantemente attivo in ascoltosu una porta predefinita, di eventuali connessioni da client esterni.

39

singoli nodi dato che contemporaneamente accedono ad esso i diversi nodi

del cluster.

Nel sistema come SIS c'è anche un configuratore che si occupa di configurare

opportunamente i diversi nodi impostando i parametri identificativi come

nome-host indirizzi di rete e altro, in modo opportuno.

Spesso SIS è integrato in altri tool più complessi che installano altri

componenti aggiuntivi come le librerie di calcolo MPI, sistemi di gestione

delle risorse come PBS o SGE e strumenti di monitoraggio del carico di

sistema come Ganglia.

Gli strumenti più avanzati inoltre dispongono di capacità aggiuntive in grado

di installare e configurare file-system distribuiti come PVFS o GPFS

(prodotto da IBM e gratuito solo per enti accademici) o infrastrutture di rete

particolari e ad alta velocità come Myrinet.

Tali strumenti integrati comprendono OSCAR il cui sito è

http://oscar.sourceforge.net, NPACI Rocks su www.Rocksclusters.org,

Warefulf presente su http://warewulf-cluster.org e infine troviamo CSM

(Cluster System Management) che è prodotto da IBM e fornito con licenza

proprietaria: si ha comunque la possibilità di scaricarlo da Internet e usarlo

gratuitamente solo per trenta giorni. E' disponibile al sito

www-1.ibm.com/servers/eserver/clusters/software/.

Per l'installazione del cluster oggetto di questa tesi, che è un cluster formato

da soli due nodi come richiesto a un sistema in alta disponibilità, non sono

stati usati tool di installazione appositamente concepiti, in quanto la

complessità del processo non era tale da giustificarne l'uso.

Per la replicazione dell'installazione infatti è stato usato un sistema

congegnato ad-hoc tanto semplice quanto rapido. Tale sistema si è avvalso

infatti dell'utility di rete netcat che consente di stabilire una connessione ad un

40

certo IP-porta nella rete direttamente da linea di comando, rendendo tale

connessione disponibile a eventuali comunicazioni sul canale così aperto.

Infatti a netcat è stato concatenato il comando dd per effettuare lo streaming

bit a bit dei dati del disco su cui si è effettuata l'installazione.

Innanzitutto si è provveduto ad avviare la macchina client (cioè il nodo di

destinazione), facendo boot da CD-ROM ed utilizzando il Live-CD Knoppix

3.236. Si è impostata l'interfaccia di rete con ifconfig eth0 192.168.0.2 netmask

255.255.255.0 e si è provveduto a mettere il sistema in ascolto sulla porta

9000 impartendo il comando di scrivere sul dispositivo /dev/sda i dati

ricevuti attraverso tale connessione, usando dei blocchi grandi 1Mb. Tutto

questo lo si evince dal seguente comando:

nc -l -p9000|dd of=/dev/sda bs=1Mb.

Sul nodo master e cioè quello che conteneva l'installazione già funzionante,

da replicare, si è impartito il comando con concatenazione inversa in modo da

inoltrare i dati letti sul dispositivo /dev/sda verso la connessione di rete

instaurata da netcat verso il sistema client configurato con l'IP 192.168.0.2 e in

ascolto sulla porta 9000. Il comando impartito dunque è il seguente:

dd if=/dev/sda |nc -w2 192.168.0.2 9000

Alla macchina master è stato precedentemente assegnato un IP sulla stessa

rete del client, col comando

ifconfig 192.168.0.1 netmask 255.255.255.0.

Dopo la fase di trasferimento dati (durata circa due ore) anche la macchina

client aveva il suo sistema operativo funzionante e configurato ma

perfettamente identico in ogni impostazione e personalizzazione a quello del

36 Live-CD: distribuzione Linux completa e funzionante completamente residente su CD-ROM cheessendo completamente autonoma non necessita di scrivere dati su dischi fissi. Tutte le impostazioni epersonalizzazioni si perdono ovviamente ad ogni riavvio. La distribuzione più famosa i questacategoria è certamente Knoppix, ma sulla stessa scia se ne stanno diffondendo molte altre.

41

nodo master. Si è provveduto pertanto a personalizzare tutti i parametri

relativi al client per distinguerlo dal master.

Chiaramente un risultato del genere è possibile solo quando le macchine

coinvolte nel processo di “clonazione” del sistema sono perfettamente

identiche.

42

C a p i t o l o 3

L'ALTA DISPONIBILITA' (HA)

Tutti passi dell'installazione finora eseguiti hanno consentito di rendere

disponibili gli strumenti indispensabili al funzionamento delle macchine

coinvolte nel cluster e messo a disposizione dell'amministratore di sistema i

tool necessari a gestire un sistema come quello che si è deciso di installare.

Attraverso l'utilizzo di questo software si provvederà adesso a installare i

componenti necessari affinché il sistema garantisca l'alta disponibilità.

E' bene chiarire in profondità il concetto di alta disponibilità. Si tenga

presente che lo scopo di un sistema HA è quello di fornire la capacità di fault

tolerance all'erogazione di un servizio. Tale funzionalità può ritenersi

indispensabile per servizi di particolare importanza ma, relativamente ai costi

di installazione e gestione di un siffatto sistema, si può scegliere di dotare di

tale funzionalità anche servizi non particolarmente critici.

Lo scopo di questa tesi è dimostrare che è possibile costruire un sistema HA

con costi particolarmente ridotti, legati esclusivamente all'acquisto

dell'hardware. I costi sono tali da consentire la fault tolerance anche a servizi

di rilevanza non critica, in quanto l'intero setup del sistema viene eseguito con

software completamente gratuito e open-source: dal sistema operativo al

software di monitoraggio dell'erogazione dei servizi che verrà descritto nei

capitoli successivi.

43

3.1 Livelli di disponibilitàLa disponibilità di un servizio può vedersi stratificata in livelli concentrici

ognuno dei quali è incluso nel successivo e possono essere schematizzati nel

seguente modo [2]:

• Livello 1: Disponibilità normale. A questo livello minimo di disponibilità

l'unica protezione contro eventuali interruzioni nell'erogazione del servizio

è il backup dei dati, eseguito a discrezione dell'amministratore del sistema.

E' evidente che in caso di interruzione del servizio, potrebbe essere

possibile ripristinare dati relativamente aggiornati, dipendentemente dalla

frequenza dell'operazione di backup ma è altrettanto evidente che la

ripresa nell'erogazione del servizio può avvenire solo quando

l'amministratore di sistema, dopo aver ripristinato i dati di backup, ritiene

di poter riprendere l'erogazione del servizio. Il tempo intercorrente

dall'interruzione al successivo ripristino della situazione normale di

funzionamento è dipendente dai tempi umani legati all'attività

dell'amministratore.

• Livello 2: Disponibilità maggiore. Lo scopo di un sistema che garantisce

questo livello di disponibilità è la salvaguardia dei dati nel miglior

aggiornamento possibile. Tale scopo è raggiunto attraverso il mirroring

fisico dei dischi attraverso tecnologie di RAID37. Anche se a questo livello

è possibile mantenere i dati sempre aggiornati, anche in caso di danni del

dispositivo di memorizzazione, la ripresa dell'erogazione del servizio

dipende ancora in maniera totale dalla disponibilità dell'amministratore di

sistema.

37 RAID: Acronimo di Redundant Array of Inexpensive Disk. Tale tecnologia, stratificata in diversilivelli che bilanciano, dal più basso al più alto, un diminuire dell'affidabilità e un aumento dellaprestazione nella velocità di gestione dei dati, fornisce la possibilità di recupero di dati nel caso diproblemi ai dischi che li contengono. Questa possibilità è data dal fatto che il RAID replica più omeno totalmente i dati memorizzati sui diversi dischi a sua disposizione.

44

• Livello 3: Alta disponibilità. A questo livello si garantisce la protezione del

sistema e dell'erogazione dei servizi. E' evidente come questo livello

rappresenti il salto di qualità nella scala della disponibilità, in quanto si

prescinde l'erogazione dei servizi oltre che da errori sui dati anche dai

tempi di reazione dell'amministratore. Un sistema che fornisce servizi in

alta disponibilità è costruito come un cluster di due nodi affiancati affinché

il secondo automaticamente intervenga prendendo il posto del primo nel

caso in cui quest'ultimo per una serie di eventi, previsti (si pensi alla

manutenzione ordinaria del singolo sistema) o casuali (difficili da

prevedere e causa principale dell'adozione dell'alta disponibilità),

interrompa l'erogazione dei servizi ad esso demandati.

• Livello 4: Disaster Recovery. Questo livello è un'evoluzione dell'alta

disponibilità che prevede la replicazione dell'intera installazione che eroga i

vari servizi, in un'altra area geografica più o meno distante dalla prima a

seconda del livello di fault tolerance che si vuole implementare.

Al fine di validare i motivi che impongono il ricorso all'alta disponibilità

nell'erogazione di servizi relativamente critici si riporta una statistica calcolata

dall'organo internazionale degli standard IEEE e risalente all'Aprile del 1995,

che mostra le classiche cause di downtime dei sistemi di elaborazione.

Come si evince dunque dal grafico, la causa principale di downtime è il

malfunzionamento software che per sua natura è praticamente impossibile

prevedere in quanto concerne malfunzionamenti relativi ad errori di

45

Ambiente 5,00%

Malfunzionamenti Software 40,00%

Hardware 10,00%Persone 15,00%

Downtime pianificati 30,00%

Cause di Downtime

programmazione che si verificano in presenza solo di certe condizioni

inizialmente ignote. E' evidente dunque che fornire un servizio con la

probabilità che quattro volte su dieci si interrompa, non è certo

incoraggiante!.

3.2 Requisito dei cinque 9I requisiti che un sistema in alta disponibilità deve soddisfare sono legati

tipicamente al tempo di disponibilità del servizio, alle prestazioni globali del

sistema e all'economicità totale del sistema implementato.

E' evidente che il requisito sulla disponibilità è quello che maggiormente

caratterizza un sistema di questo tipo e legata pertanto a tale caratteristica

troviamo una misura del tempo di disponibilità garantita [2], definita come il

rapporto percentuale fra il tempo di erogazione effettiva del servizio e il

tempo di osservazione. L’obiettivo ideale di un servizio altamente disponibile,

alla portata di poche implementazioni, è quello di raggiungere i “cinque 9”,

ossia un tempo di erogazione effettiva pari al 99,999% del tempo di

osservazione. Se rapportato ad un tempo di osservazione pari ad un anno

solare si ricava facilmente che il tempo massimo di sospensione del servizio

consentito da questo requisito è di soli 5 minuti e 15 secondi, che equivalgono

a 6 secondi per settimana. E' un risultato molto arduo da raggiungere che

richiede sforzi spesso fino a qualche tempo fa appannaggio solo di grandi

aziende. Con l'affermarsi negli ultimi anni della filosofia open-source, si sono

resi disponibili strumenti gratuiti per realizzare l'alta disponibilità di un

servizio per cui il sistema che si sta costruendo è pensato per soddisfare il

requisito dei “cinque 9”.

46

I tempi di sospensione del servizio consentiti a seconda della percentuale di

erogazione sono presentati nella tabella 2:

PercentualeUptime

Downtime per anno Downtime per settimana

98,00% 7,3 giorni 3 ore, 22 minuti99,00% 3,65 giorni 1 ora, 41 minuti99,80% 17 ore, 30 minuti 20 minuti, 10 secondi99,90% 8 ore, 45 minuti 10 minuti, 5 secondi99,99% 52 minuti, 30 secondi 1 minuto99,999% 5 minuti, 15 secondi 6 secondi99,9999% 30,5 secondi 0,6 secondi

Tabella 2 Percentuali di uptime

La strategia che consente di ottenere un livello di disponibilità sempre

maggiore consiste nella successiva eliminazione dei “single point of failure”,

ovvero di tutti quegli elementi che smettendo di funzionare coinvolgerebbero

l'intero sistema causandone l'arresto e quindi la sospensione nell'erogazione

del servizio.

Le possibili soluzioni a questo problema sono essenzialmente di due tipi: si

può migliorare la stabilità del singolo sistema, ridondando le componenti

critiche come i dischi che potrebbero inoltre supportare la sostituzione a

caldo, le interfacce di rete o altri componenti particolari. Questa soluzione si

definisce monolitica e richiede l'utilizzo di componenti molto particolari e di

conseguenza molto costosi e comunque non pone rimedio a tutti i casi in cui

si potrebbe verificare la sospensione del servizio.

L'altro tipo di soluzione, che è quella adottata in questo studio è appunto

definita soluzione cluster ed ha come caratteristica la replicazione dell'intero

sistema cosicché in presenza di un qualunque malfunzionamento che ferma

l'erogazione del servizio, l'altro sistema del cluster prende il suo posto e

continua a fornire il servizio allo stesso modo. Un cluster in alta disponibilità

47

è in grado di eseguire tale operazione in maniera totalmente trasparente ai

fruitori del servizio.

Questo tipo di soluzione presenta un grosso vantaggio: è possibile utilizzare

hardware non dedicato specificamente a un tale uso ma relativamente

generico e quindi non particolarmente costoso. E' anche evidente che è

possibile una gestione più economica e flessibile della manutenzione sia

hardware che software rendendola di fatto trasparente a quanti fanno uso del

sistema. Di contro tale soluzione richiede una maggiore complessità

nell'installazione e maggiore know-how dell'amministratore.

3.3 Le prestazioniAltra caratteristica non trascurabile di un sistema in alta disponibilità è la

prestazione del sistema nell'erogazione del servizio. In base a studi condotti in

merito in particolare dal Gartner Group e Forrester38 si evidenzia che il tempo

di attesa tollerabile dagli utenti dopo la richiesta di un servizio va dai 4 ai 20

secondi relativamente al tipo di applicazione. Considerando questi dati di

fatto, per rendere l'erogazione di un servizio sufficientemente continua è

necessario che in caso di malfunzionamenti legati al server, il tempo di

recovery non superi di molto la soglia prefissata. Si tenga in considerazione

che il tempo di risposta di una singola transazione comprende non solo il

tempo di elaborazione effettiva, che è l'unico sul quale si possono fare

interventi diretti, ma anche tempi legati all'ampiezza di banda del sistema di

comunicazione fra il client e il server, e alla latenza dei dispositivi di

connessione.

Deve essere inoltre garantita una qualità nell'erogazione del servizio

indipendente dal numero degli utenti che contemporaneamente lo richiedono:

in altri termini il sistema deve essere dimensionato in modo tale da supportare

il numero massimo di utenti che probabilmente possono richiedere il servizio

38 Gartner Group www3.gartner.com, Forrester www.forrester.com, sono enti di ricerca e analisi chesvolgono indagini spesso dietro commissione sui più disparati argomenti inerenti analisi di mercato,analisi delle tendenze comuni e di comportamento.

48

contemporaneamente. Questo fattore impone dunque la disponibilità di

potenza elaborativa adeguata facilmente e velocemente scalabile per far fronte

ad esigenze crescenti future.

Con la soluzione monolitica il problema si risolve potenziando l'hardware a

disposizione sostituendo e aggiornando i componenti che costituiscono il

collo di bottiglia39 per il sistema. Per contropartita si ha un aumento dei costi

di installazione oltre che una scarsa adattabilità dell'intera infrastruttura

all'aumentare del carico computazionale.

La soluzione cluster ancora una volta risolve il problema in modo più

efficiente ed economico; infatti la scalabilità delle prestazioni del sistema viene

ottenuta o aumentando il numero dei server sui quali viene distribuito il carico

di lavoro o aggiornando i server utilizzati. Nel primo caso, facendo

opportunamente uso di un nodo master eventualmente replicato che si occupi

di smistare le varie richieste ai diversi server, si ha la possibilità di aggiungere

risorse a seconda del carico elaborativo, considerando ogni server una risorsa

non specializzata e pertanto perfettamente modulare. Questo tipo di sistema è

infatti definito cluster con bilanciamento dinamico delle risorse [2].

3.4 Tipologie di clusterA fronte delle considerazioni fatte precedentemente si possono distinguere

due tipologie di cluster ad alta disponibilità utilizzabili per l’erogazione di

servizi:

1. Cluster Active-Active (AA) o Active-StandBy (AS)

2. Cluster a bilanciamento di carico (Load balancing cluster).

Un cluster per l'alta disponibilità AA o AS è costituito da due nodi ed è

caratterizzato dal fornire i suoi servizi con un minimo downtime. Il software

39 Nell'informatica l'espressione “collo di bottiglia” sta ad indicare un componente hardware o softwaredi un sistema di elaborazione che condiziona il resto del sistema a prestazioni non efficienti.

49

che realizza il cluster fra i due nodi è infatti in grado di riconoscere lo stato

dell'erogazione dei servizi e del funzionamento dei nodi e quindi agire di

conseguenza per far passare i servizi da un nodo all'altro attraverso la

migrazione dello storage, degli indirizzi IP e la riattivazione degli stessi

sull'altro nodo. Il tutto avviene in maniera del tutto trasparente

all'amministratore che interviene per riportare il cluster nello stato di

funzionamento standard ma senza che il servizio erogato abbia subito

interruzioni di sorta.

Un cluster per il bilanciamento del carico è costituito da un pool di nodi

opportunamente configurati per consentire la suddivisione dinamica e

bilanciata del carico di lavoro computazionale. In tale configurazione uno dei

nodi assume un ruolo specializzato, in quanto assolve alla funzione di

dispatcher e ha quindi la facoltà di ripartire ai nodi generici il lavoro

computazionale. Esso infatti è costantemente consapevole del carico presente

su ognuno dei nodi generici e, in base a una certa politica di ripartizione,

distribuisce i processi da elaborare in modo opportuno.

Il trasferimento fisico dei pacchetti ai nodi generici incaricati di una certa

elaborazione può essere effettuato con tecniche diverse che comprendono il

Direct-Redirect, il NAT (Network Address Translation) o l’ IP-Tunneling.

Nel primo caso si usa un furbo quanto semplice meccanismo ideato da IBM

che sfrutta la possibilità di cambiare opportunamente l'indirizzo MAC del

destinatario del pacchetto IP e reinserirlo sulla rete in modo che venga ora

ricevuto dal nodo generico stabilito dal dispatcher. Una volta ricevuto il

pacchetto, il nodo generico controlla che l'inidirizzo IP-destinatario ivi

contenuto, sia presente fra quelli impostati sulle sue interfacce di rete.

Ovviamente il pacchetto ha come indirizzo IP di destinazione quello del

dispatcher, e per far si che il nodo generico non lo rigetti, ha sull'interfaccia di

loopback proprio l'IP del dispatcher. Tale impostazione è possibile per il fatto

che l'interfaccia di loopback è strettamente privata.

50

Le risposte a tale comunicazione sono correttamente inviate al mittente dato

che l'IP-mittente del pacchetto ricevuto non subisce variazioni.

E' evidente che un cluster di questo tipo offre oltre che il bilanciamento del

carico e la scalabilità, per via della possibilità di aggiungere nodi generici in

ogni momento, la caratteristica di fault-tolerance in quanto se uno dei nodi

generici dovesse per qualunque problema rendersi non disponibile verrebbe

automaticamente trascurato dal dispatcher e indirettamente verrebbe messo

fuori dal cluster.

L’alta disponibilità viene realizzata completamente utilizzando per il nodo

“dispatcher” un cluster del primo tipo, eliminando così il single point of

failure. Naturalmente un servizio di questo tipo si rende necessario solo nel

caso in cui il carico al quale viene sottoposto il server è elevato, come ad

esempio può accadere per un web server aziendale.

In definitiva dunque l'architettura cluster è molto vantaggiosa per realizzare la

alta disponibilità dei servizi erogati, è in grado di fornire scalabilità nelle

prestazioni se si utilizza la tipologia di cluster che permette il load balancing e

non ultimo risulta essere molto più economica rispetto a soluzioni diverse che

offrono le stesse caratteristiche soprattutto se si tiene conto del fatto che il

software che permette l'implementazione del cluster può essere

completamente gratuito oltre che open-source. Nel setup realizzato per

questa tesi il software è interamente open-source.

51

C a p i t o l o 4

IL CLUSTER REALIZZATO IN QUESTA INSTALLAZIONE

Il cluster realizzato in questo setup è un cluster per l'alta disponibilità formato

da due nodi che fornisce l'erogazione di due servizi in configurazione Active-

Active.

Questa configurazione prevede due nodi che si controllano vicendevolmente

e costantemente sui quali appunto è distribuita in modo bilanciato

l'erogazione di diversi servizi.

La configurazione “Active-Active” si contrappone a quella “Active-Standby”,

in cui un solo nodo eroga tutti i servizi e l'altro interviene solo quando il

primo cade facendosi carico di tutti i servizi erogati da quest'ultimo.

L'insieme di un servizio e dell’indirizzo IP sul quale risponde viene definito

“Resource Group”: quando un nodo del cluster cade, tutto il Resource-

Group viene trasferito sull'altro nodo. Quando nel seguito ci si riferirà al

servizio, si intenderà quindi riferirsi al resource-group.

Per la migrazione degli indirizzi viene eseguito un meccanismo detto ARP-

spoofing che, come si vedrà più avanti, richiede particolari capacità e

impostazioni dell'hardware.

L'operazione di migrazione dell'intero servizio si definisce “Failover”.

Tornando ora alla configurazione Active-Active, i due nodi in tale

configurazione hanno ognuno il proprio servizio in esecuzione. Nel momento

in cui un nodo cade il suo servizio viene migrato sull'altro nodo con la

52

procedura di failover e su tale nodo alla fine è presente sia il suo servizio che il

servizio del nodo caduto.

Ognuno dei due nodi quindi svolge contemporaneamente funzione di server

per il servizio che eroga e di fault-tolerance per l'altro nodo in quanto in caso

di problemi su un nodo il servizio che esso erogava viene migrato

automaticamente sull'altro. E' bene dunque dimensionare le capacità di ogni

nodo del cluster in modo tale da poter sopportare, per periodi relativamente

non prolungati, il carico computazionale di entrambi i nodi.

4.1 Elementi fondamentali: una visione panoramicaGli elementi fondamentali e caratteristici su cui è stata condotta la ricerca

sono sostanzialmente i seguenti:

1. File-system. Il sistema di memorizzazione dei dati è uno degli elementi

critici di un cluster in quanto essendo il cluster un pool di nodi che

lavorano in modo cooperativo è evidente che i dati non possono essere

modificati contemporaneamente dai diversi nodi perché si andrebbe

incontro a gravi problemi di consistenza dei dati. Un file-system orientato

all'impiego in ambiente cluster deve fornire meccanismi di blocking sui

dati in modo tale da non permettere l'accesso contemporaneo.

2. Suite software per l'alta disponibilità. Questo elemento del cluster può

essere considerato il più importante non tanto in termini di criticità quanto

per la funzione che esso svolge. E' certamente il componente software che

alla fine rende l'hardware che si vuole utilizzare per costruire il cluster, un

cluster in alta disponibilità. Si parla di suite in quanto l'alta disponibilità

viene resa possibile grazie ad un insieme di programmi che svolgono

cooperativamente i loro compiti. In tale suite è presente pertanto un

modulo che effettua il controllo di “heartbeat” per stabilire lo stato di

funzionamento dei nodi, un insieme di script per fornire gli automatismi

53

necessari e l'interfacciamento con gli altri moduli software, in particolare il

modulo del file-system.

3. Strumenti di monitoraggio e analisi. Il ricorso a tali strumenti è dovuto al

fatto che la certezza sul funzionamento fisico dei due nodi non è

sufficiente a garantire che il servizio sia realmente erogato. Si pensi ad

esempio al fatto che per un qualunque motivo, inclusa l'intrusione esterna

non autorizzata, il servizio venga interrotto. Il nodo comunque è

funzionante secondo l'heartbeat ma il servizio non viene erogato.

Gli strumenti di monitoraggio consentono attraverso script appositi per ogni

servizio fornito, opportunamente scritti o modificati, di verificare l'erogazione

effettiva. Ci si potrebbe allora domandare in effetti quale sia l'utilità

dell'heartbeat. La risposta è pressoché immediata in quanto, mentre il

controllo effettuato dall'heartbeat è poco invasivo, quasi trasparente dal punto

di vista delle risorse impiegate, esso può essere ripetuto a intervalli molto

brevi, ed inoltre se il nodo non risponde all'heartbeat certamente non sta

nemmeno erogando il servizio; il controllo effettuato da strumenti di

monitoraggio come mon invece deve essere necessariamente lanciato ad

intervalli più lunghi nell'ordine dei trenta secondi per evitare di occupare il

sistema con richieste di solo monitoraggio. Le verifiche fatte da mon

consistono nella connessione ai server in ascolto sulle macchine e verificare

che la risposta ad alcuni input sia quella attesa. Praticamente ogni analisi di

mon equivale ad una richiesta di servizio identica a quella sottoposta da un

client.

Gli strumenti di analisi sono prettamente strumenti che analizzano il flusso

dei “log”.

I log sono messaggi che vengono emessi ad intervalli regolari o al verificarsi di

particolari condizioni come l'avvio o l'arresto e vengono memorizzati

all'interno di file di testo in percorsi predefiniti solitamente sotto /var/log e

organizzati opportunamente dal programma che li genera per evitare

54

confusione e una più immediata localizzazione delle informazioni. Il sistema

di analisi dei log deve accorgersi di situazioni critiche, come il failover dei

servizi, e provvedere ad avvisare, nei modi predefiniti, l'amministratore,

affinché prenda le dovute precauzioni nei tempi che ritiene ragionevoli.

Uno strumento che effettua un'analisi real-time dei log e che è in grado di

reagire alla presenza di determinati messaggi all'interno dei file log è swatch.

4.2 Schema di progettoL'illustrazione 1 rappresenta schematicamente il cluster che si è realizzato in

questo lavoro di tesi.

Dalla figura si nota la presenza dei due nodi, che sono fisicamente le due

macchine precedentemente descritte, su ognuno dei quali gira un servizio

differente.

55

Illustrazione 1: Modello del sistema

Nodo 1Nodo 1 Nodo 2Nodo 2

eth0: IP pubblico eth0: IP pubblico

eth1: connessione heartbeat e drbd privata

eth2: channel bonding con eth1

0 1 0 1

ttyS0: connessione seriale

Questo tipo di cluster non offre la caratteristica del bilanciamento di carico

dinamico, ma, l'amministratore in fase di setup è in grado di suddividere

staticamente i servizi da erogare distribuendoli in modo opportuno ai due

nodi. E' indispensabile inoltre che ognuno dei due nodi, per il tempo

necessario al ripristino dell'altro nodo nell'eventualità di un crash di sistema,

sia in grado di sopportare oltre che il suo, anche il carico computazionale del

nodo caduto.

Ognuno dei due nodi possiede tre interfacce di rete40 denominate, secondo la

nomenclatura Unix: eth0, eth1, eth2.

Come si nota dallo schema, la prima interfaccia eth0 è dedicata alle

connessioni esterne. Su tale interfaccia ognuno dei due nodi presenta

l'indirizzo IP pubblico rispettivamente 193.206.185.xx1 e 193.206.185.xx2

appartenenti allo spazio di indirizzi di una delle reti di classe C riservate

all'INFN.

I nodi quindi sono collegati all'esterno attraverso uno switch41, necessario

oltre che per motivi di praticità, per isolare dall'esterno i due nodi e consentire

il meccanismo di ARP-spoofing necessario al sistema di gestione del cluster,

Heartbeat, il quale per effettuare l'IP-takeover42 invia sulla rete dei gratuitous-

ARP.

Questo meccanismo non è generalmente consentito sugli switch della rete

dipartimentale, in quanto può essere usato per effettuare attacchi al sistema

del tipo “man-in-the-middle”43 Potrebbe inoltre essere necessario impostare40 Interfaccia di rete: ognuna delle schede ethernet Gigabit montate in ogni nodo.41 Switch: dispositivo hardware che consente il collegameto in rete di computer appartenenti a reti

diverse. 42 IP-takeover: operazione che consente la migrazione dell'IP da un nodo all'altro del cluster su cui

rispondeva il servizio erogato in alta disponibilità.43 Man-in-the-middle: tra le diverse tecniche per crackare un sistema ed effettuare operazioni illegali vi è

anche questa. Un attacco man-in-the-middle consiste nel frapporre una macchina esterna fra un certoserver e tutti i suoi client. Inviando infatti dei gratuitous-ARP sulla rete del server da una macchinapresente nella stessa rete si reindirizzano tutti i pacchetti destinati al server a tale macchina “intrusa” laquale risponderà ai vari client nel modo che ritiene opportuno e quanto più trasparente. Si pensi aidanni possibili se la macchina vittima dell'attacco è un file-server tipo ftp o altro. Nel cluster oggetto di

56

opportunamente sullo switch il tempo di aggiornamento delle tabelle dei

MAC per evitare che l'IP-takeover non richieda parecchio tempo, dopo

l'invio dei segnali di gratuitous-ARP.

Le altre due interfacce di rete eth1 ed eth2 sono invece utilizzate

esclusivamente per scopi interni al cluster. Le due interfacce sono connesse in

“channel-bonding” per evitare così un “single point of failure” rappresentato dal

collegamento interno fra i due nodi. La ridondanza di tale canale consente

inoltre una drastica diminuzione della probabilità che si verifichi il fenomeno

del brain-splitting, ma risulta di particolare importanza anche per l'integrità dei

dati che il file-system distribuito contiene.

Lo schema della figura 1 visualizza il file-system distribuito come un insieme

di blocchi. Su ogni nodo si nota la presenza di due blocchi denominati allo

stesso modo e rispettivamente 0 e 1. Tali blocchi, come si vedrà in dettaglio

nel capitolo dedicato al file-system, vengono definiti nbd (network block device) e

su ogni nodo contengono gli stessi dati: sono in parole povere l'uno la copia

speculare dell'altro. Sono costantemente sincronizzati tra loro con politiche

tali da porre rimedio alle diverse situazioni di errore che possono verificarsi.

La colorazione dei blocchi sta a rappresentare la capacità del nodo di

comandare operazioni di scrittura ed ha il seguente significato: se su un nodo

il blocco è verde, quel nodo ha la possibilità di scriverci e

contemporaneamente comanda all'altro nodo attraverso il canale interno di

effettuare la stessa scrittura; se il blocco è rosso, il nodo non ha la possibilità

di scriverci di sua iniziativa ma può solo effettuare scritture comandate

dall'altro nodo.

Questo meccanismo preserva l'integrità dei dati, consentendo solo ad un

nodo, definito primario, di comandare la scrittura sul dispositivo e consente la

disponibilità totale e immediata degli stessi dati presenti sull'altro altro nodo

(che si definisce secondario).

questo studio non si presentano problemi di questo tipo in quanto i due nodi sono i soli ad essereconnessi allo switch.

57

4.2.1 Installazione del channel-bonding

Come specificato nel paragrafo 4.2, per evitare che la scheda di rete per la

comunicazione di sincronizzazione interna rappresentasse un “single point of

failure”, si è provveduto a ridondarla utilizzando un altro dispositivo identico

per caratteristiche e specifiche.

Il channel-bonding è una funzionalità fornita con i sorgenti del kernel la cui

implementazione richiede una corretta configurazione del kernel utilizzato e

la compilazione del programma necessario a rendere effettivo questo tipo di

connessione [7]. In pratica è possibile configurare il channel-bonding in modo

tale che le due interfacce di rete siano utilizzate contemporaneamente per

incrementare le performance e l'affidabilità. In questo modo infatti, venendo

meno una, l'altra continuerebbe ancora a connettere i due nodi. Le due

interfacce possono essere configurate per lavorare singolarmente in modo tale

che un'interfaccia rimanga in stand-by e venga quindi attivata nel caso in cui

quella attiva dovesse rendersi non disponibile.

All'interno del ramo dei sorgenti del kernel al percorso

/usr/src/linux/Documentation/network è collocato il file ifenslave.c che realizza

effettivamente il bonding fra le due interfacce di rete.

Per effettuare il bonding perciò è necessario compilare il programma ifenslave.c.

Se ci si porta nella directory che contiene il sorgente attraverso il comando

cd /usr/src/linux/Documentation/network, si può lanciare la compilazione con

gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave.

Il file ottenuto lo si deve copiare nella directory degli eseguibili di sistema con

cp ifenslave /sbin/ifenslave. Si da' per scontato che /usr/src/linux sia un

collegamento alla directory contenente i sorgenti del kernel che si sta usando,

il quale per altro deve essere stato configurato ed eventualmente ricompilato

58

per supportare la funzionalità. Essa va per tanto abilitata fra le opzioni del

“network device” in fase di configurazione.

La configurazione si completa inserendo nel file /etc/modules.conf la riga

“alias bond0 bonding mode=0 miimon=100”.

Per attivare il channel bonding è sufficiente, dopo aver riavviato il sistema col

kernel eventualmente ricompilato e integrato del modulo relativo al bonding,

settare l'interfaccia di rete astratta bond0 con

ifconfig bond0 192.168.0.1 up

e aggiungere al meccanismo di bonding le interfacce di rete reali, che in

questo caso sono “eth1” ed “eth2”:

ifenslave bond0 eth1 eth2.

E' possibile inoltre inserire queste impostazioni negli appropriati file di

inizializzazione del sistema per fare in modo che l'impostazione venga

mantenuta ad ogni riavvio della macchina.

Tale configurazione va ripetuta allo stesso modo sull'altro nodo con la sola

accortezza di cambiare nel comando ifconfig bond0 192.168.0.1 l'indirizzo IP

con 192.168.0.2.

Le opzioni inserite nel file /etc/modules.conf, “mode=0 miimon=100” stanno

ad indicare il particolare uso che si vuole fare del channel bonding:

mode=0 specifica al driver di usare alternativamente le schede di rete in base

alla disponibilità ad accettare dati da trasportare, secondo l'algoritmo del

Round Robin;

miimon=100 indica l'attivazione della funzione di monitoraggio del

collegamento su ogni interfaccia di rete coinvolta nel bonding, in modo tale

59

che se su un'interfaccia il collegamento è caduto, non saranno inviati pacchetti

che poi andrebbero persi.

La funzionalità di monitoring deve essere supportata dalle interfacce di rete e

il valore 100 vuole indicare l'intervallo di tempo in millisecondi fra un

controllo e il successivo.

L'output del comando ifconfig dopo aver configurato e inizializzato

correttamente il channel bonding è il seguente:

[root]# /sbin/ifconfigbond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0 TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:0

eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x1080

eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:9 Base address:0x1400

Si noti che le interfacce di rete reali hanno un MAC-address44 identico, lo

stesso che viene impostato al dispositivo virtuale bond0 e determinato dalla

prima interfaccia di rete che nell'esempio visualizzato si riferisce a eth0.

4.3 Heartbeat Come già anticipato l'heartbeat è il meccanismo che consente il monitoraggio

costante dei due nodi del cluster. E' bene fare una distinzione fra i termini

“heartbeat” che si possono trovare in questo testo.

Se si parla di “Heartbeat” si fa riferimento all'intera suite di programmi che

consentono l'intera gestione del cluster High Avaliability.

44 MAC-address: è l'indirizzo hardware di ogni interfaccia di rete. E' un numero esadecimale enorme edunivoco e viene utilizzato per indirizzare i pacchetti del protocollo Ethernet.

60

All'interno della suite è presente poi il modulo denominato “heartbeat” (con il

primo carattere minuscolo) che si occupa di mandare e ricevere segnali di

sincronizzazione attraverso i canali di comunicazione interna predisposti

opportunamente. Questo modulo implementa il concetto di “battito del

cuore” che è alla base di tutto il cluster per cui se un nodo “muore” l'altro è in

grado di accorgersene e comportarsi di conseguenza.

4.3.1 Dati di sincronizzazione interna

Attraverso i canali di connessione interna del cluster transitano diversi tipi di

dati. In primo luogo e di fondamentale importanza al funzionamento di

heartbeat, il canale interno trasporta il segnale di sincronizzazione dei due

nodi. Tale segnale consente appunto ad Heartbeat di stabilire se i nodi sono

funzionanti e agire di conseguenza. Ovviamente tale segnale è ridondato

anche sul canale seriale che, come da schema, è rappresentato da un cavo

null-modem collegato sui dispositivi ttyS045 di entrambi i nodi.

Sul canale di comunicazione interna transitano altresì i dati necessari alla

sincronia degli nbd (network block device). In questo caso la presenza del

meccanismo di “channel-bonding” diventa addirittura indispensabile in

quanto consente di porre rimedio ad una situazione molto particolare,

analizzata nei dettagli nel capitolo dedicato al file-system: quella in cui non ci

sia sincronia fra gli nbd a causa di un'interruzione del canale di comunicazione

ethernet, questo provoca la caduta del nodo primario, prima della

risincronizzazione degli nbd.

Tale evento provoca la perdita dei dati o delle modifiche effettuate durante il

periodo di erogazione del servizio, senza sincronizzazione dei dati da parte di

entrambi i nodi.

45 ttyS0: nella simbologia dei device Unix, con “tty” si identificano tutti i terminali a carattere mentre“S0” rappresenta, nell'insieme di tali terminali, la prima interfaccia seriale.

61

4.3.2 Il fenomeno del brain-splitting

Come già accennato a volte può verificarsi, il fenomeno del brain-splitting.

Tale fenomeno corrisponde ad una particolare situazione in cui entrambi i

nodi, non ricevendo nessun segnale dall’altro nodo, credono di essere rimasti

soli nell'erogazione dei servizi. In altri termini ognuno dei due nodi registra la

situazione che l'altro nodo è inattivo.

In tale malaugurata evenienza la suite Heartbeat provvede ad eseguire il take-

over dei servizi erogati su entrambi i nodi, generando una situazione

pericolosissima che presenta le seguenti caratteristiche:

· su entrambi i nodi vengono impostati gli stessi indirizzi IP sui quali

vengono erogati gli stessi servizi: a seconda delle politiche di gestione

dell'indirizzamento sulla rete esterna alla quale i nodi sono collegati, si

potrebbero verificare effetti indesiderati;

· su entrambi i nodi vengono montati in scrittura i dispositivi a blocchi (nbd),

causando un irreparabile inconsistenza nei dati.

E' evidente, che una situazione del genere va assolutamente evitata. Per poter

prevenire il brain-splitting è necessario capire qual'è la causa scatenante.

Il motivo per cui si verifica il brain-splitting è l'interruzione del segnale di

heartbeat dovuto non alla caduta effettiva del nodo, ma all'interruzione di tutti

i canali di comunicazione interna.

Per porre rimedio a questa evenienza, ci sono due alternative. La prima, più

dispendiosa e più sicura, prevede l'utilizzo di un dispositivo “APC Master”.

Su tale dispositivo vengono collegate le prese di alimentazione elettrica dei

due nodi in modo da consentire l'interruzione dell'erogazione elettrica con

comandi software.

62

Tali comandi sono gestiti dalla suite Heartbeat attraverso l'algoritmo di

STONITH (Shoot The Other Node In The Head). Secondo tale algoritmo,

ognuno dei due nodi cerca di spegnere l'altro. Chi ci riesce per primo

continua ad erogare i servizi.

La seconda soluzione, meno dispendiosa, consiste nel ridondare i canali di

heartbeat tra i nodi: nel caso in esame lo stato del secondo nodo viene

controllato attraverso la porta seriale e il canale interno in “channel bonding”.

La scelta va operata in questo ambito su criteri meramente economici

rapportati alla probabilità che si verifichino le suddette situazioni. E' ovvio

che non esiste un limite matematicamente definito di probabilità nulla al

verificarsi di certi eventi: si sta parlando di dispositivi fisici e reali sempre

soggetti a malfunzionamenti, per cui non si può affermare che, pur

effettuando grossi investimenti in termini di affidabilità, si possa essere certi

che tale affidabilità sia sempre garantita.

63

C a p i t o l o 5

L'INSTALLAZIONE E CONFIGURAZIONE DEL FILE-SYSTEM:DRBD

Il sistema di memorizzazione dei dati in un elaboratore elettronico costituisce

un punto nevralgico dell'intero sistema.

E' fondamentale notare che le esigenze di un PC dal punto di vista della

memorizzazione dei dati sono notevolmente diverse dalle esigenze di un

cluster ad alta disponibilità, così come diversi sono anche i problemi legati alla

gestione. Si pensi ad esempio al fatto che in un cluster ogni nodo deve avere

l'accesso agli stessi dati, e gli stessi dati devono essere protetti da accessi

contemporanei da parte di più nodi. Inoltre un file-system progettato per

sistemi cluster deve fornire la possibilità della gestione dello storage da un

singolo punto oltre che un certo livello di consolidamento dei dati.

Potrebbero inoltre esserci esigenze ulteriori relative ad esempio al

throughput46 dei dati, che potrebbero richiedere specifiche particolari, volte

ad evitare che il file-system rappresenti il collo di bottiglia di un sistema

cluster di grande valore.

5.1 Tipologie di storageSi possono individuare due grosse famiglie o filosofie di supporti di

memorizzazione per sistemi cluster, che si differenziano per la dislocazione

fisica delle memorie di massa: storage esterni e storage interni.

46 Troughput: con questo termine si definisce l'entità di un flusso per unità di tempo. In questo contestosi riferisce al flusso di dati che viene calcolato in MB/sec

64

5.1.2 Storage esterno

Questo tipo di storage permette di risolvere subito il problema dell'accesso

condiviso ai dati da parte di tutti i nodi. Questi device infatti, sono dispositivi

esterni ai quali tutti i nodi del cluster possono accedere. Con questa soluzione

viene centralizzato il sistema di memorizzazione dei dati favorendo la

gestione del file-system da un solo punto e allo stesso tempo eliminando

l'onere della replica dei dati da parte del gestore del cluster.

La funzione di protezione dei dati con tecniche di ridondanza e replicazione è

gestita internamente al dispositivo di storage, riducendo fra le altre cose il

traffico di rete generato dai meccanismi di ridondanza.

Lo storage esterno può consentire maggiore efficienza nell'utilizzo dello

spazio disco riducendo la frammentazione dei dati.

Questi vantaggi sono apprezzati soprattutto nella realizzazione di cluster di

calcolo per i quali spesso si ha la necessità di dover memorizzare enormi

quantità di dati a velocità elevata: infatti lo storage esterno spesso è realizzato

con tecnologie tali da massimizzare questa capacità. Non è pertanto difficile

trovare storage esterni, connessi al cluster attraverso connessioni dedicate ad

alta velocità facenti uso di fibra ottica o dell'interfaccia “Firewire”47 e spesso

costruiti con tecnologia SCSI.

Spesso di parla di “SAN” (Storage Area Network) per far riferimento a un

insieme di questi dispositivi di storage che si avvalgono di una rete dedicata

esclusivamente al traffico dei dati e quindi spesso facente uso di connessioni

ad alta velocità per consentire alte prestazioni. Un altra tecnologia usata negli

storage esterni è “iSCSI” che sta ad indicare “SCSI su ip” ovvero il device è

costruito con tecnologia SCSI basata però sul protocollo di comunicazione

IP. Questa tecnologia comunque è ancora in fase di sperimentazione anche

47 Firewire: è il nome dato allo standard di collegamento ad alta velocita IEEE1394 il quale ha comelimite teorico di banda passante 480 Mb/sec. Molto usato in ambito desktop anche come interfacciadi collegamento per dispositivi di video editing digitale.

65

se promette molto bene per l'ampia diffusione della la rete di comunicazione

TCP/IP.

Il lato negativo più evidente in queste soluzioni di storage risiede nei costi da

sopportare. Tali dispositivi sono infatti molto onerosi in quanto devono

sfruttare tecnologie spesso dedicate e a volte proprietarie, per fornire le

prestazioni per cui sono costruiti. E' da valutare quindi con molta attenzione

se l'esigenza di disporre di dispositivi di questo genere giustifichi

l'investimento.

5.1.3 Storage interno e distribuito

Quest'altra categoria di storage è invece dedicata più propriamente a cluster

HA in quanto la caratteristica di essere “distribuito” consente il recupero dei

dati su tutti i nodi del cluster, nel caso in cui uno dei nodi dovesse rendersi

momentaneamente non disponibile.

In questi sistemi la caratteristica di alta velocità è spesso trascurabile perché

un cluster progettato per l'HA spesso è adibito all'erogazione di servizi e non

al calcolo intensivo, per cui la mole di dati da dover gestire e memorizzare

può essere relativamente ridotta.

Le soluzioni che consentono l'implementazione di uno storage distribuito e

affidabile si basano essenzialmente sul modello definito “un server-un disco”

il quale stabilisce che ogni nodo del cluster esporta un proprio quantitativo di

spazio disco, facendo in modo che ogni altro nodo del cluster vi possa

accedere.

Viene così costruito un device astratto che comprende i diversi dischi

esportati dai vari nodi e che viene considerato a tutti gli effetti uno storage

condiviso.

66

Un file-system così costruito si definisce “file-system parallelo” e presenta il

vantaggio più evidente nella suddivisione dei compiti di lettura/scrittura dei

dati ai diversi dispositivi presenti. Un altro evidente vantaggio di un file-

system siffatto risiede nell'alta affidabilità, grazie al fatto che questa tecnica

può incorporare strategie di ridondanza sui vari dischi basate su RAID,

eliminando per altro il “single point of failure” rappresentato dal file system di

uno specifico nodo.

E' evidente la difficoltà a cui si andrebbe incontro nel caso in cui si decidesse

di costruire un cluster senza un file-system appropriato: ogni nodo dovrebbe

gestire la sincronizzazione dei dati condivisi e si avrebbero grossi problemi nel

rendere affidabile un siffatto sistema. Si pensi ad esempio al recupero dei dati

residenti in un nodo del cluster momentaneamente caduto.

Le alternative possibili per la realizzazione di un file-system basato su dischi

interni sono:

• il setup di Network Block Device (NBD) in aggiunta al RAID software,

• l'uso della tecnologia DRBD sviluppata esclusivamente per cluster per

l'alta disponibilità,

• l'uso del file-system GPFS creato da IBM, non OpenSource ma gratuito

per enti accademici e praticamente perfetto per sistemi di calcolo

intensivo.

5.2 Il file-system utilizzato nel setup: motivi della sceltaPer il setup del cluster HA costruito in questa tesi sono state prese in

considerazione le diverse alternative menzionate nel paragrafo precedente ma

la scelta finale è ricaduta sulla tecnologia DRBD.

Prima che fosse creato DRBD, l'alternativa NBD+RAID era la soluzione

“Open” più indicata. La combinazione di queste due tecnologie infatti

67

consente di soddisfare le esigenze tipiche di un cluster-filesystem. Il “network

block device” infatti è un dispositivo che viene aggiunto ai dispositivi che il

kernel gestisce. Consente di montare un device remoto attraverso la rete per

fare in modo che venga trattato come un dispositivo locale. Tutto il traffico

dati relativo a tale dispositivo viene pertanto passato attraverso la connessione

di rete.

Per consentire la replica dei dati necessaria per assolvere alle caratteristiche di

disponibilità viene installato il RAID software fra il dispositivo remoto (NBD)

e quello locale gestendo poi opportunamente le diverse situazioni che

richiedono l'accesso ai dati sull'uno o sull'altro dispositivo.

A prima vista potrebbe sembrare che la tecnologia basata su NBD sia una

replica di NFS48 ma la differenza è radicale e determinante ai fini della

disponibilità e della capacità di recupero dei dati.

Rispetto a NFS, la tecnologia NBD sposta la centralizzazione del sistema

distribuendola ai vari nodi della rete. Praticamente NFS è basato su un server

che esporta una certa quantità di spazio disco e ogni client che ne fa uso

comunica direttamente al server le modifiche che vuole fare sui dati esportati.

Ciò significa che se il server cade nessuno dei client è in grado di usare lo

spazio esportato e quindi bisogna provvedere anche alla ridondanza del

server.

Con NBD invece ogni macchina esporta una certa quantità di spazio disco

che risulta disponibile ad ogni client, il quale attraverso la propria copia del

software NBD monta il dispositivo di rete e lo gestisce. Non vi sono quindi

richieste da dover essere processate a carico di un server come in NFS,

richieste che potrebbero essere innumerevoli e mettere in crisi il server stesso.

Generalmente grazie a questa capacità le prestazioni di NBD sono

sensibilmente migliori rispetto ad NFS. 48 NFS: Network File-System. Un server NFS esporta una certa quantità di spazio disco locale per

renderlo accessibile a tutti gli host presenti sulla rete i quali possono montarlo come un device locale.

68

Questa tecnologia è stata messa da parte a favore di DRBD, per le

caratteristiche più appropriate che questa tecnologia possiede.

Altra alternativa che merita menzione e che sicuramente può essere

considerata per le sue caratteristiche avanzate è GPFS.

Questo file-system è stato sviluppato da IBM e reso disponibile gratuitamente

agli ambienti accademici. Viene invece fornito dietro licenza proprietaria per

le realtà commerciali.

Le caratteristiche che rendono molto appetibile un file-system come GPFS

riguardano le performance, la possibilità di eseguire operazioni di

amministrazione da ogni nodo del cluster e la possibilità di recuperare i dati in

caso di errori. GPFS infatti usa la tecnica detta di “striping” per consentire

l'incremento delle performance che si basa sul fatto che un'operazione di

scrittura o successiva lettura viene svolta parallelamente da tutte le unità disco

presenti nel file-system in quanto ognuna di esse tratta un frammento diverso

dei dati da scrivere o leggere; la capacità di “recovery” è invece garantita dal

fatto che ogni frammento di dato viene scritto su più dispositivi diversi a

seconda della capacità di recupero che si vuole garantire. E' ovvio che una

maggiore ridondanza genera maggiore traffico di rete ed anche per questo

motivo GPFS è ottimizzato per soluzioni di rete ad alta velocità quali ad

esempio “myrinet”. Questo file-system è stato trascurato a favore di DRBD

in quanto per un sistema come quello che si è preventivato di creare, le

funzioni di GPFS seppur ottime e spesso indispensabili per cluster di grandi

dimensioni come quelli dedicati al calcolo intensivo, introducono una

complessità non giustificata per un cluster composto da soli due nodi. Si pensi

ad esempio allo striping che usato su due nodi si riduce banalmente ad una

copia speculare dei dati. Si può ritenere che GPFS sia una soluzione designata

per server di complessità elevata e di costi ovviamente più grandi, che

giustificherebbero la maggiore laboriosità di GPFS relativamente alle

mansioni che tali server dovranno svolgere.

69

Un certo interesse merita inoltre un altro progetto inizialmente proprietario

sotto licenza Sistina e da poco diventato “open” che va sotto il nome di

“OpenGFS”.

Presenta anch'esso alcune caratteristiche avanzate come GPFS ma è

ottimizzato in special modo per dispositivi di tipo SAN comunque non

pertinenti con l'hardware in uso in questo setup.

In definitiva, si potrebbe trarre la stessa conclusione data per GPFS in merito

al rapporto fra complessità e funzionalità fornite e al limite, quando tali

funzionalità diventassero indispensabili, sarebbe comunque preferibile GPFS

vista la sua maturità e il supporto IBM. Ci sarebbe qualcosa in più da

considerare quando l'ambiente di applicazione non fosse più accademico per

cui si rende necessario l'acquisto della licenza IBM.

Si è in sostanza ritenuto che DRBD, poiché ideato esclusivamente per

risolvere i problemi affrontati dai cluster per l'alta disponibilità, rappresenti il

miglior compromesso fra semplicità e funzioni implementate. Ancora, la

completa integrabilità di DRBD con la suite Heartbeat è una caratteristica

fondamentale per far sì che la gestione del file-system sia completamente

automatizzata. Altra caratteristica favorevole all'uso di DRBD consiste nel

ridotto calo di performance che introduce. Tutte queste particolarità saranno

meglio evidenziate nei paragrafi successivi in cui verranno presentate nei

dettagli le caratteristiche di DRBD e un'analisi approfondita delle

performance.

5.3 DRBD: caratteristiche e peculiaritàDRBD è l'acronimo di Distributed Replicated Block Device. Sviluppato da

Philipp Resiner è attualmente disponibile nella versione 0.6. E' rilasciato nei

termini della licenza GPL e quindi liberamente distribuibile e modificabile a

partire dal codice sorgente.

70

Drbd è un dispositivo a blocchi creato esclusivamente per risolvere problemi

tipici inerenti cluster in alta disponibilità. Si basa sul meccanismo della

replicazione dei dati fra due dispositivi a blocchi residenti su due nodi

differenti, attraverso una connessione di rete privata. Semanticamente il

funzionamento è simile al RAID-1 attuato però fra dispositivi remoti [4].

In parole povere Drbd si prende carico di copiare attraverso la rete i dati

scritti sul block device locale anche sul corrispondente block device remoto.

Su un sistema così composto, che lavora in maniera trasparente ai livelli

superiori si può installare il file-system vero e proprio (ext3), quindi un file-

system journaled,49 che fornisce capacità di ripristino molto rapide evitando il

controllo di consistenza dei dati al riavvio (fsck su ext250 ).

5.3.1 Funzionamento di DRBD

Il modulo kernel di Drbd presente su un nodo del cluster HA, lavora in

stretta sincronia con il modulo presente sull'altro nodo.

Il file di configurazione, esposto più avanti, è infatti identico su entrambi i

nodi. Nel momento in cui si decide di costituire un block-device basato su

Drbd, ognuno dei due nodi mette a disposizione una partizione del proprio

disco locale che ovviamente non va montata automaticamente attraverso

/etc/fstab51.

Leggendo il proprio file di configurazione /etc/drbd.conf, ogni copia di Drbd

presente sui nodi imposta la partizione fisica ivi specificata, a far parte del

block-device /dev/nbd/X e attraverso il canale di comunicazione privata che

49 Filesystem Journaled: la caratteristica Journaled di un file-system fornisce la capacità di evitareinconsistenze nei dati in quanto tutte le modifiche apportate vengono tracciate e memorizzate così incaso di spegnimento accidentale del sistema o crash, al successivo montaggio del file-system, il sistemaoperativo è in grado di ripristinare lo stato consistente dei dati annullando le operazioni noncompletate prima del blocco.

50 Ext2: file-system storico usato sulla gran parte delle installazioni Linux prima della creazione di ext3che ne rappresenta la diretta evoluzione con la sola aggiunta del journaling.

51 fstab: Per i dettagli inerenti le partizioni dei nodi che si sono installati vedere la tabella 1 a pagina 18

71

nel setup corrente è il channel-bonding fra eth1 ed eth2, si sincronizza con il

modulo Drbd presente sull'altro nodo che esegue le stesse operazioni.

A questo punto è disponibile il block-device /dev/nbd/X sul sistema

formato dai due nodi del cluster. Tale block-device, gestito da Drbd in

sincronia sui due nodi, è composto dalle due partizioni messe a disposizione

da ciascun nodo.

Il block-device, pur presente e sincronizzato, non è ancora disponibile per le

normali operazioni di input-output eseguite dal kernel in quanto va

inizializzato e poi montato dopo aver creato su di esso il file-system scelto.

L'inizializzazione del block-device /dev/nbd prevede l'assegnazione ad uno

dei due nodi la capacità di scrittura. Con Drbd infatti solo un nodo per volta è

in grado di scrivere sul block-device per evitare inconsistenze negli accessi agli

stessi dati da parte dei due nodi. Per questo motivo rispetto a un dato block-

device, ogni nodo può assumere il ruolo di 'primary' se possiede la capacità di

scriverci, 'secondary' se tale capacità non gli è accordata. Come si vedrà più

avanti è compito di Heartbeat stabilire i ruoli negli accessi ai block-device.

Se un nodo è 'primary', avrà la capacità di modificare il contenuto del block-

device e il modulo Drbd si occuperà di trasferire e replicare tali modifiche

anche sull'altro nodo comunicando attraverso la rete privata. Le modifiche

saranno quindi replicate sulla partizione che il nodo 'secondary' ha ceduto per

far parte del block-device Drbd.

Tutto ciò avviene in modo del tutto trasparente e a livello utente non si ha la

possibilità di entrare nel merito della gestione delle partizioni cedute al block-

device: in effetti il tentativo di montare tali partizioni manualmente produce

errori di grave entità che coinvolgono la perdita di sincronizzazione fra i due

nodi e gravi possibili inconsistenze nei dati.

72

Se durante le normali operazioni il nodo primario cade, Heartbeat si accorge

della situazione e rende primario l'altro nodo montando quindi il block-device

su quest'ultimo.

Quando il nodo caduto rientra nel cluster il modulo Drbd ivi residente si

accorge di aver perso la sincronizzazione e prima che possa permettere la

riammissione nel cluster sincronizza i suoi dati con quelli che nel frattempo

l'altro nodo ha scritto. Il servizio supportato dal block-device che ha

attraversato tutta questa situazione non subisce comunque interruzioni di

sorta in quanto tutte le fasi di recupero sono gestite in background.

5.3.2 Specifiche software di DRBD

Drbd è costruito come un modulo kernel che rende disponibili speciali block-

device chiamati NBD che possono essere gestiti in modo tale da garantire le

seguenti funzionalità:

· Nessuna perdita di dati in caso di errori su di un nodo.

· Capacità di aggiunta di un nodo ripristinato senza interruzione del servizio.

· Capacità di avvio del sistema senza intervento dell'amministratore.

· Possibilità di avviare un cluster degradato52 senza intervento

dell'amministratore.

La possibilità di non avere perdite di dati in caso di errori sui nodi è

sicuramente un requisito indispensabile ai fini della disponibilità di un servizio

perché l'erogazione di un servizio è basata anche sui dati relativi all'ambiente

52 Cluster degradato: un cluster con un solo nodo funzionante. L'altro è in fase di sincronizzazione onon è disponibile.

73

in cui il server è inserito. Ci sono comunque casi particolari in cui si è disposti

a pagare qualcosa in termini di capacità di recupero a fronte di un incremento

di performance.

La stretta correlazione di Drbd con server per l'alta disponibilità è evidenziata

inoltre dalla possibilità di far rientrare un nodo nel cluster senza la necessità di

dover riavviare o sospendere l'erogazione del servizio. Questo requisito è

soddisfatto grazie alle procedure in background che vengono eseguite sul

nodo che eroga fisicamente in quel momento il servizio attraverso le quali il

nodo secondario riesce di nuovo a sincronizzarsi e rendersi disponibile come

nodo in standby.

Altre funzionalità di monitoraggio riescono poi a fornire al cluster un certa

autonomia per alcune decisioni riguardanti la fase di avvio. L'avvio infatti

presenta il problema di stabilire quale dei nodi ha i dati aggiornati quando si è

precedentemente persa la sincronizzazione e Drbd è in grado di stabilirlo

senza l'intervento dell'utente. Ancora, se il cluster era già degradato la

ripartenza dello stesso deve avvenire ancora in modalità degradata senza

intervento dall'esterno.

5.3.3 I protocolli di sincronizzazione

Drbd è basato sul collegamento attraverso il protocollo TCP fra i due nodi

del cluster, tale scelta è stata dettata da questioni di praticità e per l'affidabilità

del protocollo stesso. TCP è infatti incluso nel kernel Linux, quindi

pienamente supportato e integra nelle sue specifiche, funzionalità di

riordinamento dei pacchetti e il controllo di flusso. Queste caratteristiche

rendono possibile la dislocazione remota dei due nodi per consentire capacità

di recupero dati estreme che possono coprire fino all'ultimo livello di

disponibilità che prevede il disaster-recovering attraverso la dislocazione

geografica della ridondanza. Il collegamento fra i due nodi può essere reso più

o meno interdipendente considerando la stabilità dell'hardware in relazione

all'affidabilità che si vuole ottenere. Vengono allo scopo utilizzati tre

74

protocolli che incorporano delle caratteristiche che regolano il funzionamento

di Drbd[4].

· Protocollo A: questo metodo di connessione fra i due nodi consente il

massimo grado di indipendenza. Se il nodo primario esegue un'operazione

di I/O53, invia al secondario il comando di eseguire la stessa operazione.

Non appena termina la scrittura sul proprio dispositivo locale, il nodo

primario invia al suo sistema operativo il segnale di aver terminato

l'operazione senza considerare ciò che è avvenuto sul secondario.

Naturalmente questo protocollo non soddisfa il primo requisito specificato

nel paragrafo 5.3.2, in quanto, se il primario va in crash dopo aver

segnalato il termine di una scrittura ma prima che il secondario abbia

effettivamente ricevuto tutti i dati concernenti l'operazione di scrittura, la

replica dei dati non sarà affatto speculare ed in effetti si verificherà una

perdita di dati. A volte comunque questo protocollo può rendersi

necessario nei casi in cui il collegamento di rete interno presenti un'elevata

latenza. Se non ci fosse il protocollo A, il nodo primario dovrebbe

attendere il segnale di termine delle operazioni di sincronizzazione

attraverso la rete e ciò pregiudicherebbe l'efficienza computazionale del

sistema.

· Protocollo B: questo protocollo favorisce una maggiore sicurezza nella

replica dei dati. Il funzionamento del Drbd è simile a quanto specificato

per il protocollo A con l'unica differenza che il nodo primario segnala al

proprio sistema operativo (attraverso il quale una applicazione sta

richiedendo operazioni di I/O) il termine dell'operazione stessa, solo

quando ha ricevuto dal secondario il pacchetto di risposta al comando di

scrittura. Questo pacchetto viene inviato dal secondario al primario non

appena riceve il comando di scrittura che provvederà successivamente ad

eseguire. In effetti, pur fornendo una certa sicurezza in più, il protocollo B

53 I/O: Forma abbreviata per indicare Input-Output. Generalmente si riferisce a operazioni eseguitesulle memorie coinvolgenti flussi di dati in input o in output.

75

è una via di mezzo fra A e C (quest'ultimo infatti garantisce la massima

affidabilità).

· Protocollo C: questo protocollo è il massimo dell'affidabilità ottenibile da

Drbd. Tale affidabilità è garantita dal fatto che il segnale di termine

dell'operazione di I/O, che il nodo primario invia al suo sistema operativo

è inviato solo quando il nodo secondario comunica di aver terminato la

sua operazione di scrittura, quando cioè i dati sono stati fisicamente

replicati.

E' evidente che il tempo di attesa da parte del sistema operativo del nodo

primario in questo caso comprende sia il tempo di scrittura sul nodo locale

che sul nodo secondario oltre al tempo di latenza del sistema di

connessione di rete necessario al trasporto dei segnali di sincronizzazione

delle operazioni eseguite.

5.3.5 Algoritmi di gestione dei blocchi

Normalmente i moderni file-system journaled (così come i DBMS54)

proteggono i propri dati in modo tale da riportarli in uno stato consistente in

seguito ad una operazione errata o alla sospensione anomala di un'operazione

di I/O.

Come già specificato un file-system si definisce “journaled” proprio perché

fornisce questa capacità che è implementata utilizzando un “giornale” in cui

vengono memorizzate temporaneamente le modifiche apportate

recentemente al file-system in modo tale da permettere l'annullamento di

54 DBMS: Acronimo di DataBase Management System e si riferisce al motore di gestione di una base didati

76

operazioni parzialmente compiute prima di una sospensione anomala

dell'attività del sistema [6].

Nei DBMS le operazioni di modifica vengono raggruppate in “transazioni” e

la scrittura effettiva delle modifiche avviene solo a transazione compiuta, per

cui un errore che si verifichi durante le modifiche intermedie, non viene

memorizzato fisicamente e i dati rimangono sempre consistenti.

DRBD deve in ogni caso preservare la consistenza dei dati soprattutto nella

previsione che il funzionamento del file-system potrebbe fermarsi in modo

anomalo per un motivo qualunque.

Praticamente il protocollo C non presenta questo problema, in quanto le

operazioni di scrittura avvengono in maniera sincrona su entrambi i nodi. I

problemi si presentano quando, usando i protocolli A e B, la scrittura di un

blocco su disco è necessaria per poter scrivere un blocco successivo. Tale

informazione sulla dipendenza fra i blocchi nelle operazioni di scrittura è

conosciuta solo dall'applicazione che sta eseguendo l'I/O e quindi il sistema

operativo non può conoscerlo. Inoltre essendo Linux un moderno sistema

operativo, implementa lo scheduler di I/O per le operazioni sulle memorie di

massa in modo tale da ottimizzare la velocità di I/O, organizzando

opportunamente la lista di operazioni da compiere, in modo tale da

minimizzare lo spostamento della testina di lettura/scrittura.

DRBD tuttavia risolve il problema della dipendenza di scrittura fra i blocchi e

consente anche di utilizzare le ottimizzazioni derivanti dall'utilizzo dello

scheduler del file-system attraverso l'implementazione di barriere di scrittura

che consentono al nodo secondario di mantenere i dati sempre in una forma

consistente [4].

Il funzionamento di tali barriere consiste nel determinare in sede del nodo

primario, l'esistenza di eventuali dipendenze di scrittura fra i blocchi da

trasferire al nodo secondario e, se qualche dipendenza esiste prima di inviare i

77

blocchi indipendenti, viene impostata la barriera di scrittura immediatamente

prima dei blocchi dipendenti e inviati quindi i blocchi non dipendenti e la

barriera.

Il nodo secondario, attraverso l'utilizzo dello scheduler, dispone

momentaneamente in memoria i blocchi da scrivere per riordinarli

opportunamente secondo le disponibilità del suo sistema di memorizzazione.

Appena riceve la barriera di scrittura, il nodo termina l'operazione di caching

ed ordinamento ed esegue la scrittura senza attendere altri blocchi che

saranno ovviamente dipendenti da quelli appena ricevuti e che vanno scritti

per primi.

5.3.6 Cambio dei ruoli fra i nodi

Il cambio dei ruoli che i nodi assumono rispetto a un Drbd block-device si

verifica in caso di crash del nodo primario o rientro nel cluster del nodo che

precedentemente era primario. Ovviamente nel secondo caso

l’amministratore del sistema deve guidare il processo, per cui il software di

gestione del cluster si limita semplicemente ad eseguire i comandi; nel primo

caso invece la caduta del nodo primario richiede che il sistema di gestione del

cluster prenda autonomamente la decisione di cambiare i ruoli dei nodi,

consentendo al secondario di apportare al block-device le modifiche

necessarie affinché l'applicazione continui il suo funzionamento.

Nel caso di crash sul nodo secondario, il nodo primario continua il suo

funzionamento ma è necessario che Drbd memorizzi tutte le modifiche che

avverranno fino al ritorno del secondario per poter successivamente

sincronizzare solo i dati modificati in tale periodo.

Secondo i protocolli A e B il nodo primario memorizza la “storia” dei blocchi

che ha comandato di scrivere al secondario finchè quest'ultimo non comunica

di averli effettivamente scritti.

78

Al crash del nodo secondario dunque vengono inclusi fra i blocchi modificati

anche quelli presenti nella “storia” in modo tale da non lasciare dati

inconsistenti sul nodo secondario.

Questo tipo di sincronizzazione viene definita “quick synchronization” [4] in

quanto la sincronizzazione coinvolge solo alcuni blocchi.

Se i dati relativi alle modifiche recenti che il primario possiede per qualche

ragione non dovessero essere applicabili, (perché ad esempio nel frattempo il

device sul nodo secondario è stato modificato dall'esterno), si rende

necessaria la “full synchronization” che invece coinvolge tutti i blocchi del

dispositivo e richiede una quantità di tempo abbastanza elevata anche perché

in questo processo non è possibile utilizzare lo scheduler del file-system.

Quest'ultima peculiarità trova la sua ragione nel fatto che, per soddisfare il

secondo requisito del software Drbd (che il cluster continui a funzionare pur

se in maniera degradata anche durante la fase di aggiunta di un nodo) i diversi

blocchi del dispositivo possono essere modificati durante il processo di

sincronizzazione. Si potrebbe verificare una situazione in cui l'operazione di

lettura eseguita dal codice di sincronizzazione sul primario, possa essere

richiesta prima della eventuale scrittura dello stesso blocco a causa dei

meccanismi di caching e ottimizzazione forniti dallo scheduler del file-system.

Ovviamente questo caso genererebbe inconsistenza fra le due repliche dei

dati.

Nel caso di crash sul nodo primario invece, utilizzando il protocollo A o B, si

potrebbe verificare la perdita dei dati che il nodo caduto stava scrivendo nel

momento precedente al crash. Il secondario termina le operazioni di scrittura

che erano ancora eventualmente pendenti ma potrebbe non aver traccia dei

dati modificati successivamente sul primario e non ancora ricevuti. In questo

caso infatti alla successiva riconnessione del nodo caduto la sincronizzazione

avverrà sulla base dei dati contenuti nel nodo che era secondario.

79

Normalmente in fase di boot del sistema Drbd assegna il ruolo primario al

nodo che contiene i dati aggiornati e il ruolo secondario al nodo che deve

essere sincronizzato. Tali ruoli sono però controllati anche dal software di

gestione del cluster nel quale potrebbero essere impostati in modo inverso.

Per far fronte a questo problema solitamente si avvia il gestore del cluster,

Heartbeat, solo dopo l'avvenuta sincronizzazione dei dati da parte di Drbd.

5.3.7 Decisioni in fase di riavvio

Pur non essendo un tema legato all'alta disponibilità la quale non ammette

interruzione totale di un servizio, in termini pratici un riavvio totale dell'intero

cluster potrebbe verificarsi più o meno frequentemente specie nei sistemi di

nuova installazione o in assenza di una adeguata politica di gestione della

alimentazione elettrica con gruppo di continuità e gruppo elettrogeno. Un

evento simile avrebbe forti ripercussioni sulla sincronizzazione dei dati e la

loro relativa consistenza per cui Drbd è progettato anche per far fronte a tale

evenienza che dovrebbe per altro essere evitata con ogni mezzo.

Le situazioni che si possono verificare durante il crash del sistema e durante il

suo riavvio sono le seguenti:

• I nodi del cluster cadono contemporaneamente. In questa situazione il

sistema è in grado di stabilire quale dei due nodi possiede i dati più

aggiornati stabilendo quale era primario prima del crash. Per far ciò nel

momento in cui un nodo assume il ruolo di primario viene settato su di

esso un flag detto “primary indicator”. Tale flag determina in fase di avvio

il nodo con i dati più aggiornati.

• Il nodo secondario è già non disponibile al momento del crash. In questo

caso dovendo riavviare il sistema, Drbd si affida ancora al “primary

indicator” per stabilire il nodo con i dati più aggiornati.

80

• Il nodo primario è caduto prima del riavvio. In questa situazione, il

secondario è stato portato a primario quindi al riavvio entrambi i nodi

hanno il primary indicator settato. Per riuscire anche in questo caso a

stabilire il nodo più aggiornato si usa un contatore definito “unconnected-

counter”. Ogni volta che un nodo cambia ruolo, quando l'altro nodo non è

presente viene incrementato il contatore. Al riavvio viene testato prima

tale contatore e viene stabilito che il nodo più aggiornato è quello col

valore più alto. Se tale valore è uguale si passa a testare anche il primary-

flag.

• La connessione di rete interna è interrotta al momento del riavvio. Questa

situazione porta, al fenomeno dello split-brain. Nel caso di questo sistema

dato che il segnale di sincronizzazione viaggia sia su LAN che su seriale, la

situazione citata si realizza solo nella ipotesi che siano disconnessi

entrambi i canali. In tale ipotesi succede che al riavvio, dopo aver

riconnesso i canali, il nodo selezionato come il più aggiornato è sempre il

secondario in quanto appena si interrompe la connessione al nodo

secondario risulta che il primario è caduto quindi il sistema di gestione del

cluster provvede a cambiare il ruolo del secondario in primario così

facendo però viene incrementato automaticamente da Drbd anche il

contatore unconnected-counter per cui al riavvio esso risulta il più

aggiornato ma in effetti non è necessariamente così. Drbd usa allora un

altro contatore definito “connected-counter” che viene incrementato se il

ruolo di un nodo rispetto ad un dato dispositivo a blocchi condiviso,

cambia quando la connessione è attiva. Il contatore inoltre viene

incrementato sul nodo primario anche quando quest'ultimo perde il

contatto dell'altro nodo ed è il caso in questione, per cui al riavvio

vengono testati nell'ordine connected-counter, unconnected-counter,

primary-indicator, per far fronte a tutte le problematiche sopra esposte.

• Riavvio in modalità degradata. Al riavvio del cluster i moduli di Drbd

presenti su entrambi i nodi si mettono in ascolto reciproco bloccando il

81

normale startup del sistema finché non riescono a collegarsi. Spesso però

può rendersi necessario riavviare un cluster che era già in modalità

degradata (solo un nodo realmente funzionante) ma se Drbd rimanesse in

ascolto dell'altro nodo la fase di startup non terminerebbe mai. Per

consentire un avvio del cluster in modalità degradata viene pertanto

utilizzato un timeout definito “startup-timeout” che inizia il suo count-down

se si verificano le seguenti condizioni: il connection indicator non è settato e

ciò significa che i due nodi non erano connessi prima del riavvio; il flag

primary indicator è settato e ciò dimostra che il nodo aveva il ruolo di

primario prima del riavvio. Queste condizioni dimostrano che il nodo

stava già funzionando in modalità degradata per cui se entro lo startup-

timeout, l'altro nodo non risponde, il nodo primario si avvia ugualmente.

• Un nodo non riesce a riavviarsi. Se durante un riavvio del cluster

precedentemente funzionante, si verifica un problema su di un nodo in

fase di avvio, l'altro nodo rimane in ascolto presentando tuttavia all'utente

la possibilità ti forzare l'avvio come primario. Se ciò accade il nodo

funzionante viene quindi avviato come primario. Al successivo riavvio del

nodo non funzionante, questo potrebbe prendersi il ruolo di primario

considerando i meta-dati impostati in merito ad un certo block-device. Per

evitare questa situazione, viene impostato, in caso di intervento umano al

riavvio, un contatore definito human interventio counter che assume priorità

massima rispetto a tutti i meta-dati descritti fin'ora ed evita che il nodo

precedentemente non funzionante possa divenire subito primario senza

che venga effettuata prima la sincronizzazione.

• Caduta di un nodo in fase di sincronizzazione. Se una tale evenienza

accade viene settato il flag che fra i meta-dati di un block-device ha la

priorità massima. Esso è definito consistency-flag e viene mantenuto attivo

finché il processo di sincronizzazione non termina. Qualsiasi sia il valore

degli altri meta-dati e dunque, qualunque sia lo stato del sistema, se il

82

consistency-flag è impostato, il nodo deve subire il processo di

sincronizzazione.

5.4 PerformanceNel sistema in alta disponibilità che si sta costruendo, le performance legate

alla gestione dei dati non sono determinanti, in quanto il flusso dei dati che si

prevede di dover gestire non è elevato. Tuttavia per un'analisi completa del

software Drbd è bene analizzare anche questo aspetto per consentire una

migliore valutazione del sistema nel caso si volessero apportare modifiche

successive alla configurazione dei gruppi di servizi, attivi sul cluster.

Dai dati reperiti sul sito ufficiale del progetto, www.drbd.org, si è appreso che

le performance di Drbd sono differenti a seconda della versione del kernel

che si utilizza. In particolare il kernel della serie 2.2.x fornisce prestazioni

inferiori in quanto Drbd non ne è parte ma si interfaccia ad esso come livello

intermedio fra le applicazioni e il kernel stesso, introducendo un overhead

computazionale. Drbd nel kernel 2.2.x utilizza metà degli slot del sistema

operativo che gestiscono le operazioni di input-output; la rimanente parte è

lasciata all'uso generico dello scheduler locale del file-system.

Il kernel 2.4 invece, incorporando Drbd ottimizza la gestione delle risorse

legate all'input-output dei dati generando una perdita non rilevante nelle

performance dal punto di vista dell'overhead computazionale. E' ovvio che la

differenza di performance dovuta alla replicazione dei dati attraverso la

connessione interna fra i nodi è comunque evidente.

Nel sistema in esame, il kernel appartiene alla versione 2.4.x per cui il

problema legato all'overhead computazionale non è significante.

83

E' stato comunque eseguito un test approfondito sulle performance di Drbd,

facendo uso di un software per il benchmark del file-system che verrà

descritto successivamente e che mette in evidenza le caratteristiche di Drbd.

5.4.1Software di benchmark I/O: iozone

iozone è un software open-source gratuito che consente di eseguire un

numero di test esaustivi sule performance del file-system in relazione alle

diverse esigenze che si potrebbero presentare.

Fra i diversi strumenti analoghi ad iozone è stato preferito quest'ultimo per il

fatto che presenta una maggiore completezza; in particolare ha la possibilità di

emettere i risultati in formato tabellare facilmente importabili all'interno di

fogli elettronici e successivamente utilizzabili per creare grafici tridimensionali

in grado di rendere immediatamente visibile l'entità delle caratteristiche del

file-system.

Verranno pertanto presentati e commentati i diversi grafici ottenuti in

relazione ad ogni tipo di test effettuato.

La riga di comando utilizzata per lanciare il test è stata la seguente:

iozone -Razb output.wks -g 2G -S 512 -i 0 -i 1 -i 2.

Questo comando è stato impartito nelle diverse configurazioni del file-system

e cioè: sul file-system ext3 residente in una partizione locale, sia sul file-system

ext3 montato però su un block-device Drbd ed eseguito per ogni protocollo

di Drbd. In tutto il test è stato eseguito per quattro volte.

Dalla riga del comando impartito si evidenziano le opzioni e i test che sono

stati richiesti a iozone.

84

L'opzione -R consente in output un file binario direttamente utilizzabile in

Microsoft Excel55.

L'opzione -a imposta la modalità di test automatica. Iozone si preoccuperà

pertanto di eseguire tutti i test per tutte le combinazioni possibili di grandezza

dell'unità di scrittura (record-size), variabile fra 4 kilobyte (KB) e 16 megabyte

(MB), e grandezza del file, variabile da 64KB a 2GB.

L'opzione -z usata in abbinamento al modo automatico, consente di forzare

l'esecuzione del test con piccoli record-size anche sui file di grandi

dimensioni. Generalmente la modalità automatica evita di eseguire anche

questi test, ma per completezza si è deciso di includerli.

L'opzione -g 2G sta ad indicare la grandezza massima del file da scrivere su

disco su cui eseguire i test. E' stato impostato un valore di due Gigabyte per

riuscire a testare il sistema di memorizzazione senza l'ausilio dei meccanismi

di caching effettuati in memoria RAM dal sistema operativo. E' stato scelto

dunque tale valore perchè pari al doppio della quantità di RAM installata.

L'opzione -S notifica ad iozone la quantità di memoria cache L1 installata nella

CPU. Questa informazione consente di calibrare opportunamente i test.

Le opzioni -i identificano le tipologie di test che si intendono eseguire ed in

particolare:

• -i 0 esegue un test write/re-write che consente di misurare le performance

in caso di scrittura e ri-scritturadi blocchi sequenziali.

• -i1 esegue test di read/re-read che misura òe prestazioni per letture e ri-

letture sequenziali.

• -i2 esegue invece test di lettura e scrittura casuale.

55 Microsoft Excel: Programma proprietario con licenza commerciale Microsoft che implementa il foglioelettronico facente parte della suite Microsoft Office.

85

5.4.2 I risultati del test iozone

iozone ha prodotto ogni volta che è stato eseguito un file in formato binario

per Microsoft Excel. Tuttavia i risultati così ottenuti sono stati analizzati con

la suite Open Office in grado di aprire e convertire i file della nota suite

Microsoft nel proprio formato. I dati ottenuti, in formato tabellare sono stati

poi utilizzati per creare i grafici riassuntivi mostrati di seguito e

opportunamente commentati. Ognuno dei grafici presentati mostra sull'asse

denominato “file size KB”, le dimensioni della grandezza espressa in kilobyte,

del file utilizzato per il test; sull'asse denominato “block size KB”, la

grandezza dei blocchi di dati utilizzati per le operazioni di lettura o scrittura

del file; sull'asse denominato “Performance KB/sec”, la misura in kilobyte

per secondo, della performance del file-system analizzato, in funzione dei due

parametri precedenti.

5.4.3 Test di scrittura

Vengono analizzate adesso le performance dei file-system in merito

all'operazione di scrittura. Tale operazione riguarda la scrittura del file di test,

su locazioni sequenziali.

86

Come si evince dall'illustrazione 2, le performance tipiche del file-system ext3

si aggirano mediamente sui 100 megabyte per secondo. E' un risultato di tutto

rispetto considerando che si stanno utilizzando dischi EIDE e tale valore è

molto vicino al limite teorico del canale EIDE. Tuttavia sono doverose

alcune precisazioni. Il valore medio riscontrato è ottenibile soltanto quando la

grandezza del file che si sta scrivendo non supera i 500 megabyte ed è dovuto

al fatto che fino a tale valore il sistema operativo fa largo uso dello scheduling

delle operazioni su disco mantenendole in un buffer in memoria centrale. La

memoria RAM infatti è ampia 1 gigabyte e con tale disponibilità, il sistema

operativo può facilmente gestire l'intera operazione di I/O all'interno del

buffer riservato al caching del file-system. E' evidente che fino a tale soglia le

prestazioni del file-system non sono indicative delle prestazioni dei dischi

fisici in quanto non coinvolgono operazioni di lettura/scrittura eseguite

direttamente su disco. I valori più interessanti che rivelano le potenzialità

effettive del sistema di memorizzazione sono quelli misurati dopo la soglia di

caduta delle prestazioni, dove la grandezza del file di test è tale da non

permettere l'utilizzo delle ottimizzazioni dovute al sistema operativo. Come si

87

Illustrazione 2: writer report, ext3 su block-device locale

64 2561024 4096 32768 262144 2097152

10000

100000

1000000

4 16 128 2048

ext3 writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

vede quindi le performance reali di scrittura diretta su disco sul file-system

ext3 si aggirano mediamente intorno al valore di 14 megabyte per secondo.

L'illustrazione 3 mostra le performance di scrittura con file-system ext3

montato su un Drbd block-device configurato con protocollo A. Anche qui

valgono le stesse considerazioni fatte per ext3 su block-device locale. Le

prestazioni medie si aggirano ancora sui 100 megabyte per secondo ed anche

qui troviamo la soglia di caduta delle prestazioni in prossimità delle

dimensioni del file di test intorno ai 500 megabyte dovuta ancora alla cache

del sistema operativo.

Le prestazioni reali, registrate dopo la soglia di caduta delle prestazioni, sono

sensibilmente più basse di quelle registrate sul block-device locale per via della

gestione della replica dei dati che Drbd introduce ad ogni operazione di

scrittura. Per soddisfare tale protocollo l'operazione di scrittura termina dopo

aver inviato i dati da replicare sull'altro nodo.

88

Illustrazione 3: Writer Report con DRBD protocollo A

64 256 2048 16384131072

2097152

1000

10000

100000

1000000

4 16 256

4096

drbd protA writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

file size KB

performance KB/sec

Block size KB

Le prestazioni reali medie si aggirano dunque mediamente intorno ai 2,8

megabyte per secondo.

Stesse considerazioni anche per il file-system ext3 montato su Drbd block-

device configurato con protocollo B. Si nota ancora la soglia di caduta delle

prestazioni intorno alla grandezza del file di test di 500 megabyte, le

prestazioni con cache del sistema operativo sono ancora misurate intorno ai

100 megabyte per secondo, mentre le prestazioni reali si attestano ancora

intorno ai 2,8 megabyte per secondo.

La differenza fra Drbd con protocollo A e protocollo B è praticamente

inesistente: infatti l'unica differenza fra le specifiche del protocollo A e le

specifiche del protocollo B riguarda il messaggio di “ricevuto” che il

secondario invia al primario dopo aver ricevuto un comando di scrittura. Tale

messaggio arriva quasi istantaneamente per due motivi: innanzitutto la rete di

connessione interna ai nodi ha un'ampiezza di banda tale da non costituire un

collo di bottiglia per le operazioni svolte durante il test; inoltre il nodo

89

Illustrazione 4: Writer Report con DRBD protocollo B

64 25610244096 32768262144

2097152

1000

10000

100000

1000000

4 16 128

2048

drbd protoB writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

file size KB

performance KB/sec

Block size KB

secondario non sta eseguendo altri processi “time consuming” che

potrebbero ritardare l'esecuzione delle operazioni richieste da Drbd.

La differenza principale delle performance col protocollo C rispetto ai due

precedenti protocolli è un risultato inatteso sulle performance reali, dopo la

soglia di caduta. Il valore medio è circa di 9 megabyte per secondo e

certamente questo è un valore inatteso in quanto a causa delle specifiche più

restrittive di tale protocollo, le quali prevedono che il primario termini

un'operazione di scrittura solo quando il secondario ha comunicato a sua

volta di averla materialmente terminata, ci si aspettava che le performance in

questo caso fossero peggiori. Tuttavia questo non causa perdite di dati e non

compromette l'affidabilità di tale protocollo, secondo quanto specificato dagli

sviluppatori di Drbd per i quali questo comportamento rappresenta oggetto di

indagine. Si osservi che comunque esiste un calo delle performance rispetto

alla scrittura diretta su ext3 valutabile intorno al 30%.

90

Illustrazione 5: Writer Report con DRBD protocollo C

64 256 2048 16384262144

1000

10000

100000

1000000

4 16 256

4096

drbd protoC writer

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

5.4.4 Test di ri-scrittura

Verranno ora considerate le operazioni di ri-scrittura. Le performance

vengono misurate quando l'operazione di scrittura viene ripetuta una seconda

volta. In questa analisi si mette in evidenza l'influenza della cache del disco,

che conserva in memoria, da dove quindi li recupera per la successiva

operazione di scrittura, i dati appena scritti.

91

Illustrazione 6: Re-Writer Report con ext3 locale

64 2561024 4096 32768 2621442097152

10000

100000

1000000

4 16 128

2048

ext3 re-writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Perfromance KB/sec

Block size KB

92

Illustrazione 7: Re-Writer Report con Drbd protocollo A

64 256 1024 4096 32768262144

2097152

1000

10000

100000

1000000

4 16 128

1024

16384

drbd protoA Re-writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

file size KB

performance KB/sec

block size KB

Illustrazione 8: Re-Writer Report con DRBD protocollo B

64 256 1024 409632768

2621442097152

1000

10000

100000

1000000

4 16 128

1024

16384

drbd protoB Re-writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

file size KB

performance KB/sec

Block size KB

Come mostrato nelle illustrazioni 6, 7, 8 e 9 le performance di un'operazione

di riscrittura sono molto superiori di quelle di scrittura a causa del pieno

utilizzo delle ottimizzazioni sulle operazioni di I/O operate dal sistema

operativo. I valori medi si attestano intorno ai 450 megabyte per secondo e si

notano inoltre gli effetti del caching dati operato dal processore, che causa i

picchi nel grafico visualizzato, quando si ottimizzano le dimensioni dei

blocchi dei dati scritti, rispetto all'ampiezza della linea di cache della CPU.

Come al solito si verifica la caduta delle performance in corrispondenza della

stessa soglia evidenziata per le operazioni di scrittura, dopo la quale i valori

reali delle performance di I/O ritornano ad essere gli stessi ottenuti

dall'operazione di scrittura e cioè: circa 15 megabyte per secondo per il file-

system montato su block-device locale; circa 2,8 megabyte per secondo su

Drbd block-device con protocollo A e protocollo B; circa 10 megabyte per

secondo con Drbd block-device configurato con protocollo C.

93

Illustrazione 9: Re-Writer Report con Drbd protocollo C

64

128

256

512

1024

2048

4096

8192

16384

32768

65536

131072

262144

524288

1048576

2097152

1000

10000

100000

1000000

4 16 256

4096

drbd ProtoC re-writer report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

5.4.5 Test di lettura

Il test che si analizza adesso riguarda operazioni di lettura sequenziale su file

di test. Come si vedrà l'operazione di lettura non grava sulle prestazioni del

file-system quando eseguita su device Drbd in quanto Drbd esegue

localmente le operazioni di lettura. Le prestazioni quindi, considerando il file-

system montato su device locale o su Drbd con i tre diversi protocolli di

sincronizzazione, sono in linea di massima paragonabili.

Anche qui si nota la soglia di caduta delle prestazioni quando il file di test

supera i 512 megabyte e in media le prestazioni reali del sistema, nelle

operazioni di lettura, fanno registrare un rate di 40 megabyte per secondo.

Interessante in questo test è notare l'effetto dovuto alla cache del processore

che per le operazioni di lettura viene ottimizzata al massimo. Essendo infatti il

kernel ricompilato su ogni macchina, è stato ottimizzato per la CPU installata.

Il kernel dunque ottimizza la lettura da disco richiedendo al controller EIDE

di leggere un quantitativo di dati pari ad una linea di cache per ogni

94

Illustrazione 10: Reader Report

64 2561024 4096 32768262144

2097152

10000

100000

1000000

10000000

4 16 128

2048

reader report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

operazione di lettura. Essendo poi un test effettuato con lettura sequenziale, i

dati da dover leggere successivamente sono già presenti in cache per cui non è

necessario accedere di novo al canale EIDE. Questo tipo di ottimizzazione è

proficua solo quando i blocchi di dati da leggere hanno dimensioni inferiori a

512 Kilobyte che rappresenta l'ampiezza della memoria cache del processore.

5.4.6 Test di ri-lettura

Il test di ri-lettura misura le performance del file-system in corrispondenza di

una lettura successiva a dati già letti. Questo test mette in evidenza l'effetto

della cache di primo livello che agisce maggiormente in corrispondenza di file

di test di piccole dimensioni e ampiezza dei blocchi letti molto ristretta. In

queste condizioni il grafico relativo mostra un picco abbastanza evidente.

Tuttavia le prestazioni ottenute dopo la soglia di caduta, come già detto

dovuta all'impossibilità di applicare gli algoritmi di ottimizzazione del kernel,

sono leggermente più basse dei risultati ottenuti con la singola lettura appunto

perchè l'operazione richiede che la testina di lettura ritorni indietro ogni volta

(dopo la soglia di caduta infatti la cache non ha più effetto).

95

Anche in questo caso non ci sono differenze fra le prestazioni ottenute su

file-system montato su device locale o su device Drbd in quanto anche in

questo caso si tratta di operazioni di lettura che Drbd comunque esegue in

locale. Si nota inoltre che il picco di prestazioni si attesta circa su 1,5 gigabyte

per secondo mentre le prestazioni reali non superano mediamente i 25

megabyte per secondo.

5.4.7 Test di lettura casuale.

Questo test esegue la lettura del file di testo a blocchi non sequenziali al fine

di misurare le performance del file-system su operazioni riguardanti dati non

contigui che richiedono spostamenti continui della testina di lettura/scrittura.

96

Illustrazione 11: Re-Reader Report

64 256 2048 16384262144

10000

100000

1000000

10000000

4 16 256

4096

re-reader report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

Anche in questo caso le differenze fra le performance su device locale o su

device Drbd non differiscono per il fatto che si tratta di operazioni di lettura

che Drbd esegue comunque localmente. I risultati ottenuti prima della soglia

di caduta delle performance sono analoghi a quelli ottenuti con operazioni di

lettura sequenziale, in quanto, finché vengono usati meccanismi di

ottimizzazioni che fanno uso della memoria centrale (caching del sistema

operativo), le operazioni di accesso casuale ai dati non introducono tempi di

latenza dovuti a spostamenti meccanici della testina di lettura/scrttura, dato

che la memoria centrale ha un tempo di accesso istantaneo per qualunque

locazione. Infatti la memoria RAM deve il suo nome proprio a questa

particolare caratteristica. Tuttavia i valori medi risultano leggermente più bassi

in quanto non possono essere utilizzate ottimizzazioni dovute alla cache del

processore perché comunque i dati letti, se pur istantaneamente, non sono

contigui.

I risultati più interessanti si ottengono come al solito dopo la soglia di caduta

delle performance. Si nota infatti che le performance scalano in relazione alla

grandezza dei blocchi di lettura. Questo effetto è giustificato dal fatto che non

intervenendo adesso nessun meccanismo di caching, tutte le operazioni

vengono svolte su disco; per questo motivo ogni operazione di lettura da

97

Illustrazione 12: Random-Read Report

64 2561024 4096 32768262144

2097152

100

1000

10000

100000

1000000

10000000

4 16 128

2048

random read report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

locazioni casuali, richiede lo spostamento meccanico della testina del disco

per cui se con ogni operazione di lettura si leggono più dati contigui (blocchi

più ampi), le performance relative crescono. Tuttavia la crescita delle

prestazioni si arresta quando la grandezza dei blocchi raggiunge la capacità

della cache del processore e cioè 512 Kilobyte in quanto per blocchi più

grandi il processore può ottimizzare sempre e soltanto 512 kilobyte di dati

sequenziali; dopo è comunque necessaria una successiva lettura su disco

eseguita per altro su locazioni adiacenti. Le performance reali sono comprese

pertanto fra 1,2 e circa 50 megabyte per secondo.

5.4.8 Test di scrittura casuale

Questo test misura le capacità del file-system in corrispondenza di scritture di

dati eseguite su locazioni casuali e non necessariamente adiacenti. Gran parte

delle considerazioni da dover fare per questo test sono state già fatte per i test

precedenti. Infatti prima della soglia di caduta delle performance, con

l'utilizzo delle ottimizzazioni dovute al caching dei dati le caratteristiche delle

scritture casuali sono simili a quelle delle scritture sequenziali, dato che non ci

sono latenze dovute a spostamenti continui della testina di lettura/scrittura

del disco. Dopo la soglia di caduta si registra invece lo stesso fenomeno

presentatosi con le operazioni di lettura casuale e cioè l'incremento delle

prestazioni dovuto al crescere delle dimensioni dei blocchi di scrittura.

Valgono anche in questo caso le considerazioni fatte al paragrafo 5.4.7

relative al migliore utilizzo della cache del processore. La differenza rispetto

alle operazioni di lettura casuale sta nel fatto che le performance reali sono

ovviamente più basse e si attestano in valori compresi fra 1 e 4 megabyte per

secondo se il file-system è montato su Drbd device per via dei meccanismi di

replicazione dei dati; fra 1 e 25 megabyte per secondo se il file-system è su un

device locale. Il valore minimo delle performance reali è identico sia per i

device locali che Drbd in quanto in tali situazioni il collo di bottiglia è

rappresentato dagli spostamenti della testina del disco e non dai meccanismi

di replicazione dei dati introdotti da Drbd.

98

99

Illustrazione 13: Random-Write Report

64 256 2048 163841310722097152

100

1000

10000

100000

1000000

4 16 256

4096

local random write report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

Illustrazione:14: Random-Write Report con Drbd

64 256 204816384

1310722097152

100

1000

10000

100000

1000000

4 16 256

4096

drbd random write report

4

8

16

32

64

128

256

512

1024

2048

4096

8192

16384

File size KB

Performance KB/sec

Block size KB

5.4.9 Conclusioni

In conclusione, per favorire l'incremento delle prestazioni del file-system

bisogna cercare di sfruttare le ottimizzazioni che derivano dallo scheduling del

sistema operativo e dai meccanismi di cache della CPU. E' pertanto

consigliabile, al fine di sfruttare lo scheduling del sistema operativo eseguito

attraverso l'ordinamento delle operazioni di I/O, con dati in memoria

centrale, evitare di gestire file di dimensioni superiori a 1 Gigabyte perché tale

situazione ricade nella zona oltre la soglia di caduta delle performance che

ridurrebbe drasticamente il throughput dati gestito.

Usando infatti file di tali dimensioni non è possibile contenerli nella memoria

centrale per cui è richiesto un continuo accesso al canale EIDE per reperire le

informazioni necessarie. Come si è visto dall'analisi dei grafici questa

ottimizzazione è la più consistente dato che permette incrementi in

prestazioni molto importanti e sia in lettura che in scrittura.

E' bene inoltre non superare la dimensione di 512 Kilobyte sui blocchi di dati

gestiti visto che fino a tale soglia si sfrutta il caching del processore. L'effetto

della cache è molto evidente durante le operazioni di lettura e tuttavia oltre

tale soglia non si registra una brusca caduta delle prestazioni. Un'eccezione va

fatta per le operazioni casuali di lettura o scrittura, eseguite su file di

dimensioni superiori a 1 gigabyte, per i quali la possibilità di utilizzare blocchi

maggiori di 512 kilobyte consente prestazioni maggiori in quanto ogni blocco

di dati viene letto sequenzialmente.

Ulteriori ottimizzazioni potrebbero essere sfruttate in operazioni di ri-lettura

con file minori di 512 kilobyte. Infatti in tal caso le operazioni vengono svolte

interamente nella cache della CPU e quindi alla sua stessa velocità di clock

senza dover più volte accedere a bus esterni, come la memoria centrale o

addirittura il canale EIDE, per reperire altri dati. Questa situazione è tipica

dell'accesso consecutivo ad uno stesso file di piccole dimensioni.

100

5.5 Installazione e configurazione DRBDLa procedura di installazione del software Drbd si esegue secondo gli

standard della distribuzione Gentoo. Drbd è inserito nel portage di Gentoo

dove sono disponibili i sorgenti e i file relativi alla compilazione e installazione

del software.

E' sufficiente infatti impartire il comando

emerge drbd

per ottenere il download dell'ultima versione stabile del software e la

successiva compilazione ed installazione.

Normalmente l'installazione di drbd richiede e l'inserimento del modulo drbd

nel kernel e la ricompilazione dello stesso. Queste operazioni vengono svolte

automaticamente dallo script di installazione invocato da emerge per cui dopo

l'esecuzione del comando il modulo drbd è già installato e pronto a

funzionare.

Su ogni nodo del cluster due partizioni vengono destinate alla creazione di

due Drbd block-device. Le partizioni destinate a Drbd hanno entrambe la

dimensione di 10 Gigabyte e su ogni nodo saranno appunto /dev/sda10 e

/dev/sda11.

Per poter svolgere le sue funzioni Drbd richiede che sia opportunamente

creato il file /etc/drbd.conf56 . In tale file sono specificate le risorse che sono

devolute a Drbd e le modalità di configurazione delle risorse stesse oltre alle

modalità con cui Drbd dovrà utilizzarle.

Per fare in modo che il sistema operativo sappia come montare i Drbd block-

device, sono state aggiunte al file /etc/fstab le seguenti righe:

/dev/nbd/0 /bind ext3 noauto 0 0

56 Il file di configurazione di Drbd, drbd.conf è presentato integralmente in appendice.

101

/dev/nbd/1 /sendmail ext3 noauto 0 0

I punti di mount /bind e /sendmail sono stati precedentemente creati con

mkdir /bind; mkdir /sendmail. L'opzione noauto è invece fondamentale perchè i

block-device non vanno montati dal sistema operativo automaticamente, ma

dal software di gestione del cluster (Heartbeat) secondo le decisioni prese in

fase di avvio del cluster o in seguito a eventuali take-over delle risorse gestite.

Il file /etc/drbd.conf deve essere identico su entrambi i nodi del cluster, per cui

va copiato senza nessuna modifica anche sull'altro nodo.

Va ricordato che tutti i comandi eseguiti sono stati impartiti attraverso il

software pconsole per cui l'installazione di Drbd è avvenuta

contemporaneamente su entrambi i nodi del cluster.

Per completare l'installazione, Drbd va inoltre aggiunto all'elenco dei

programmi eseguiti in fase di avvio. Il wrapper Drbd è stato inserito dal

processo di installazione nella directory /etc/init.d per cui è sufficiente eseguire

il comando rc-update add drbd default per fare in modo che ad ogni riavvio ogni

nodo carichi anche il proprio modulo Drbd.

Per rendere funzionante a questo punto la replicazione dei dati sui Drbd

block-device è necessario rendere attiva l'interfaccia di rete privata che sarà

utilizzata sia da Drbd che da Heartbeat.

5.5.1 Il file di configurazione “drbd.conf”

Il file /etc/drbd.conf è formato da diverse sezioni, una per ogni risorsa

configurata, o meglio, per ogni block-device che si vuole aggiungere al cluster.

Ogni riga che inizia con resource indica che si sta configurando un nuovo

block-device identificato dal nome che segue la parola resource [4].

102

Per ogni risorsa configurata ci sono poi diverse sottosezioni che configurano

le diverse caratteristiche di ogni block-device.

Innanzitutto si trova la riga protocol che specifica il tipo di protocollo con cui

Drbd deve effettuare la sincronizzazione su tale device. Nel cluster che

costruito, si utilizza il protocollo C.

Successivamente si specifica qual'è il comando per effettuare il controllo

dell'integrità dei dati, poi la sezione relativa alla configurazione della rete di

comunicazione che si occupa di configurare i parametri relativi alla velocità di

sincronizzazione e vari time-out come quello relativo al tempo di attesa

dell'altro nodo.

Le sezioni successive sono decisamente più importanti e configurano le

risorse che di ogni nodo vengono utilizzate. In dettaglio la configurazione

delle risorse avviene attraverso le seguenti righe:

on freedom { #HA1device=/dev/nbd/0disk=/dev/sda10address=192.168.0.1 port=7788}

on independence { #HA2device=/dev/nbd/0disk=/dev/sda10address=192.168.0.2 port=7788}

Le righe precedentemente evidenziate sono relative alla configurazione della

singola risorsa che sarà disponibile su ogni nodo attraverso il file57

“/dev/nbd/0”.

All'interno di ogni sottosezione, che inizia con la parola on seguita dal nome

del nodo che esporta le risorse, troviamo innanzitutto la definizione del57 In Linux come in tutti i sistemi *nix si usa dire che “tutto è un file” per riferirsi al fatto che qualunque

elemento del sistema è accessibile attraverso un file. A questa caratteristica non si sottraggononemmeno le risorse hardware per le quali il sistema riserva la directory /dev all'interno della quale ognifile fa riferimento a ogni diverso dispositivo hardware.

103

device che viene configurato, definito dal file “/dev/nbd/0”; con l'attributo

“disk” viene specificata quale sarà la partizione reale che deve essere esportata

dallo specifico nodo per far parte del block-device condiviso.

Gli attributi “address” e “port” invece si riferiscono alla configurazione del

modulo drbd che verrà eseguito su ogni nodo e che, per la sincronizzazione

fra i nodi, utilizzerà l'indirizzo IP 192.168.0.1 sul nodo “freedom” e

192.168.0.2 sul nodo “independence”; su entrambi sarà in ascolto sulla porta

7788.

Si noti che per ogni risorsa aggiuntiva configurata (relativa ad altri block-

device) la porta sulla quale il modulo drbd rimane in ascolto per la sua

sincronizzazione deve essere sempre diversa.

5.6 Alta disponibilità della rete interna Come si nota dal paragrafo 5.5.1 la rete interna utilizzata per la

sincronizzazione dei dati di Drbd ha indirizzo 192.168.0. Tale rete è stata

assegnata alle interfacce “eth1” ed “eth2” configurate in channel bonding [7]

per far in modo che anche il collegamento di rete interna che Drbd usa per

sincronizzare i dati fra i due nodi del cluster, non rappresenti un “single point

of failure”.

Come già detto Drbd è in grado di svolgere il suo compito anche quando i

dati sono momentaneamente non sincronizzati, ma ci possono essere casi in

cui la caduta del nodo primario, potrebbe generare perdite di dati. Proprio

questo caso, testato direttamente sul cluster costruito, ha suggerito

l'opportunità della replicazione del canale di sincronizzazione. Si è eseguita

infatti la seguente prova utilizzando su entrambi i nodi la sola interfaccia eth1

come canale di sincronizzazione di Drbd.

104

Il nodo “freedom” è stato reso primario[4] per il Drbd block-device

“/dev/nbd/0” attraverso il comando drbdsetup /dev/nbd/0 primary e si è

montato il dispositivo al percorso /bind col comando

mount /dev/nbd/058

Successivamente è stato eseguito il comando touch test che ha creato sul block-

device un file chiamato test.

Per verificare la sincronizzazione si è smontato il dispositivo “/dev/nbd/0”

dal nodo “freedom” e lo si è montato temporaneamente sul nodo

“independence”.

Dopo aver riportato “freedom” al suo ruolo di nodo primario si è provveduto

ad interrompere a il canale di sincronizzazione, staccando fisicamente il cavo

ethernet incrociato che collega i due nodi.

In questa circostanza drbd automaticamente si rende conto che la replica dei

dati non viene eseguita e provvede a memorizzare i cambiamenti effettuati al

block-device in una locazione del disco che si definisce “bitmap”, per poter

eseguire, quando il collegamento fra i nodi è ripristinato, l'aggiornamento

della replica sull'altro nodo, dei soli dati specificati dalla bitmap. Questa

operazione viene infatti definita “fast resync”.

A questo punto il file /bind/test è stato modificato attraverso il comando

echo modifica da freedom>/bind/test

che ha inserito il testo “modifica da freedom” all'interno del file “/bind/test”.

Tale modifica quindi non è stata replicata sul nodo “independence” ma

rimane nella “bitmap” del nodo primario “freedom” in attesa del “fast

58 Si noti che il comando non specifica né il percorso in cui montare il dispositivo, né il tipo di file-system contenuto in quanto i parametri corretti sono già impostati nel file /etc/fstab.

105

resync”. Tutta questa procedura rimane comunque trasparente all'utente in

quanto viene eseguita in background da Drbd.

Si è provveduto ora a spegnere il nodo “freedom”, per simulare un crash

accidentale del nodo primario e si è reso primario il nodo “independence”

rispetto allo stesso device “/dev/nbd/0”. Dopo averlo montato nella

directory predefinita, è possibile verificare che la modifica al file “/bind/test”

non è stata ovviamente effettuata.

Si è quindi modificato ulteriormente il file “/bind/test” con il comando

echo modifica da independence>/bind/test

che ha inserito una stringa di testo diversa all'interno del file test.

Quest'ultima modifica viene eseguita nella bitmap residente su

“independence”.

Ripristinando il collegamento di rete privato e rendendo ancora primario il

nodo “freedom” ci si accorge allora che il “fast resync” è avvenuto

correttamente, ma la stringa memorizzata nel file di test è “modificato da

independence”. La modifica effettuata su “freedom” va dunque persa59.

La perdita di dati dunque avviene in presenza di due avvenimenti successivi:

la assenza di sincronizzazione tra i drbd dei nodi per un problema sulla rete

interna, si pensi ad esempio ad un problema della scheda di rete, e il

successivo blocco totale del nodo primario. In tal caso le modifiche fatte sui

dati durante il funzionamento in assenza di sincronizzazione vengono perse.

Per ridurre la probabilità che si verifichi questo problema si è provveduto

quindi a ridondare il canale di sincronizzazione di Drbd mediante “channel

bonding” in quanto costituisce un “single point of failure” forse non di

59 Si consideri che tutti i passaggi eseguiti manualmente per rendere primario o secondario un nodorispetto a un DRBD block-device e le operazioni di montaggio e smontaggio dei device, a clusterultimato vengono eseguite automaticamente da Heartbeat.

106

primaria importanza, in quanto non coinvolge l'intero funzionamento del

cluster, ma abbastanza critico per la consistenza dei dati immagazzinati. Si

pensi ad esempio ad intere transazioni su database che potrebbero andare

perse.

Si potrebbero perciò introdurre nelle definizioni dell'alta disponibilità, diversi

livelli di criticità per i “single point of failure” il maggiore dei quali prevede

l'interruzione dei servizi erogati.

107

C a p i t o l o 6

HEARTBEAT: SUITE PER L'ALTA DISPONIBILITA'

In questo capitolo si analizza nei dettagli il funzionamento e la configurazione

di Heartbeat. Questo software caratterizza il funzionamento dell'intero cluster

in quanto tiene traccia del funzionamento dei singoli nodi e prende le

decisioni opportune nei casi di malfunzionamento. Come ogni software

sviluppato per ambiente Linux o comunque Unix-like, Heartbeat è una suite

composta da un insieme di piccoli moduli altamente specializzati su una certa

funzione che interagiscono continuamente per raggiungere l'obiettivo finale

della suite. Questo modo modularizzato di operare consente di rendere molto

snello ed efficiente lo sviluppo del software, in quanto in caso di

manutenzione o aggiunta di funzionalità future, le modifiche coinvolgeranno

solo i moduli direttamente interessati e non l'intera suite.

6.1 La struttura modulare di HeartbeatSchematicamente si può riassumere la sua struttura con la seguente

illustrazione.

108

Dall'illustrazione 15 è evidente che Heartbeat ha un'architettura

multiprocesso e questo è voluto oltre che per ragioni storiche anche per

motivi di sicurezza. Il fatto che ogni processo separato gestisca un aspetto

particolare delle funzioni della suite evita che il crash di una certa funzionalità

coinvolga tutte le altre.

Come si vede in figura 15, in Heartbeat ci sono quattro categorie di processo:

primo e più importante è il “Master Control Process”, troviamo poi i processi

di “lettura” e “scrittura” e il processo di “lettura FIFO”.

Ci sono poi altri processi che possono essere considerati processi “client” in

quanto eseguono certe operazioni e chiedono al “Master Control Process” di

reagire di conseguenza. I più importanti sono “ipfail” e “CCM” (Consensus

Cluster Membership)[5].

Il “Master Control Process” è il cuore del sistema di monitoraggio. Ha il

controllo dell'intera attività della suite e si interfaccia con gli altri processi di

109

Illustrazione 15: Schema moduli Heartbeat

Heartbeat a cui invia e riceve i dati necessari per prendere le decisioni in caso

di malfunzionamenti sui nodi. In particolare: provvede all'invio dei segnali di

heartbeat attraverso i canali configurati che collegano i nodi del cluster,

gestisce i time-out sui segnali di heartbeat attraverso i quali stabilire se un

nodo è effettivamente funzionante, invia pacchetti firmati attraverso

l'apposito plugin o autentica pacchetti ricevuti utilizzando gli appositi

algoritmi crittografici opportunamente configurati, si occupa infine di avviare

o riavviare i diversi processi della suite relativi alle diverse funzionalità

implementate.

Il processo “FIFO reader” ha l'unico scopo di leggere la coda attraverso la

quale comunicano i diversi processi di Heartbeat accessibili attraverso il file-

system al percorso /var/lib/heartbeat/fifo.

La comunicazione fra processi attraverso la coda “first-in-first-out” è

utilizzata quando i processi risiedono sulla stessa macchina ed è facilmente

realizzabile, dato che due processi possono scambiarsi messaggi aprendo in

lettura o scrittura la stessa coda.

Il modulo “FIFO reader” evita che la gestione di tale comunicazione venga

eseguita all'interno del “Master Control Process”.

I “read processes” sono processi adibiti esclusivamente alla lettura di messaggi

da sottoporre al “Master Control Process”. Il loro funzionamento è molto

simile al “FIFO reader” tranne per il fatto che i dati letti vengono ricevuti

dall'esterno attraverso i canali di comunicazione fra i nodi. Dato che i canali di

comunicazione possono essere diversi è necessario che ci sia un processo di

lettura per ogni tipo di canale da cui ricevere dati.

I “write processes” hanno le stesse caratteristiche dei “read processes” ma

sono adibiti alla trasmissione di dati all'esterno. Anche in questo caso ci

saranno processi di scrittura diversi per ogni tipo di canale di comunicazione

utilizzato.

110

I “client processes” eseguono operazioni che si possono definire esterne

all'attività del “Master Control Process” ad esempio “ipfail” esegue un

monitoraggio della connessione fra i nodi e stabilisce quando è necessario

eseguire il failover del gruppo di servizi chiedendo al “Master Control

Process” di eseguire materialmente l'operazione.

CCM invece, acronimo di Consensus Cluster Membership, svolge la funzione

di monitorare lo stato del cluster per fornire in ogni momento al Master

Control Process le informazioni relative ai nodi del cluster effettivamente

connessi e pienamente funzionanti.

La principale funzione di questo modulo è quella di verificare lo stato della

connessione fra i nodi per risolvere problemi legati a connessioni solo parziali

o comunque non desiderate che potrebbero verificarsi in seguito a

malfunzionamenti software o danni arrecati dall'esterno. In pratica ogni nodo,

grazie al “CCM”, è consapevole del fatto di essere o meno membro del

cluster ed ancora i nodi parzialmente collegati (nel caso di interruzione di uno

dei canali ridondati di connessione interna), non vengono considerati membri

del cluster e non potranno accogliere un eventuale failover. E' evidente che

questo componente assume un'importanza crescente all'aumentare del

numero di nodi che compongono il cluster benché la sua funzione rimane

indispensabile anche con cluster formati da due soli nodi.

6.1.1 I plugin

I moduli descritti fin'ora costituiscono il nucleo della suite e assolvono le

funzioni primarie necessarie al funzionamento del cluster. Tale nucleo

centrale per altro, non implementa alcune funzionalità esterne e più vicine al

contesto operativo in cui verrà collocato il cluster.

Per assolvere alle funzioni di interfacciamento col mondo esterno Heartbeat

si appoggia a plugin che vengono utilizzati in modo opportuno a seconda del

tipo di ambiente in cui andrà ad operare e si possono suddividere in tre

111

categorie: ci sono plugin di STONITH, plugin di Comunicazione, plugin di

autenticazione. L'illustrazione 16 mostra una visione più ampia della suite

Heartbeat.

I plugin di STONITH implementano le funzioni necessarie a far fronte al

problema del brain-splitting. STONITH è infatti acronimo di Shoot The

Other Node In The Head ed è un meccanismo che si occupa di disattivare

istantaneamente un nodo del cluster quando se ne presenta la necessità, in

particolare quando uno stesso gruppo di servizi è erogato da più di un nodo, a

causa di un failover sbagliato causato ad esempio dall'interruzione simultanea

di tutti i canali di comunicazione interna.

112

Illustrazione 16: Heartbeat: visione più ampia

Questa operazione è realizzata con un dispositivo hardware che collegato al

cluster attraverso la rete ethernet o le porte seriali, è in grado di comunicare

con Heartbeat e ricevere comandi. Tale dispositivo hardware gestisce

l'erogazione di energia elettrica a ciascuno dei nodi del cluster cosicché, in

caso di brain-splitting è in grado di bloccare istantaneamente il

funzionamento di uno dei nodi.

Con il plugin di STONITH sono forniti anche i driver per il funzionamento

del dispositivo hardware.

Tutte le comunicazioni verso l'esterno, eseguite da Heartbeat sono gestite da

plugin. I canali supportati comprendono le comunicazioni UDP di tipo

broadcast, multicast e unicast60 e le comunicazioni attraverso le porte seriali.

Tali plugin si occupano di inviare al kernel le richieste necessarie all'invio dei

segnali generati dai vari moduli del nucleo della suite o alla ricezione di quelli

provenienti dall'esterno.

I plugin di autenticazione forniscono tutte le funzionalità riguardanti la

sicurezza delle comunicazioni fra i nodi del cluster. Tutti i messaggi scambiati

dai nodi sono accompagnati da chiavi di autenticazione che consentono ai

nodi che li ricevono di stabilire che un certo segnale ricevuto sia autentico ed

effettivamente proveniente da un certo nodo. Sono tuttavia implementati tre

diversi algoritmi di crittografia a seconda del livello di sicurezza che si vuole

ottenere pagando in termini di utilizzo di CPU.

Le autenticazioni possono essere eseguite con l'algoritmo “crc” il più semplice

ma anche il meno sicuro, con l'algoritmo “MD5”, o con l'algoritmo “sha1”

che offre una codifica difficilmente reversibile ma richiede un carico di lavoro

supplementare. Quest'ultimo algoritmo tuttavia, è consigliabile se le

comunicazioni di sincronizzazione devono passare attraverso segmenti di rete

non esclusivamente ad utilizzo dei nodi del cluster; se la rete di connessione

60 Le trasmissioni di rete possono essere di vari tipi a seconda dei destinatari a cui sono indirizzate. Letrasmissioni broadcast infatti sono inviate a tutti gli host connessi alla rete, quelle multicast a diversihost specificati e quelle unicast a un solo host specificato.

113

interna è assolutamente privata, non vi è alcuna necessità di codificare in

modo sicuro i messaggi di sincronizzazione.

I “resource script” che si trovano schematizzati nell'illustrazione 16 possono

essere considerati a tutti gli effetti componenti esterni di Heartbeat. Sono dei

file in formato testo che possono essere modificati dall'amministratore di

sistema per essere adattati alle specifiche esigenze e vengono invocati

automaticamente da Heartbeat per svolgere funzioni particolari o

dall'amministratore per gestire alcuni aspetti della suite. Heartbeat ad esempio

potrebbe invocare lo script “MailTo” per inviare dei messaggi di posta

elettronica al verificarsi di particolari situazioni, l'amministratore potrebbe

invece invocare lo script “heartbeat start” per avviare manualmente le

funzioni di Heartbeat o “heartbeat stop” per fermarne il funzionamento.

6.2 Il Resource GroupNella logica di Heartbeat si definisce risorsa ogni entità del sistema che

Heartbeat gestisce [5]. Una risorsa può essere ad esempio un indirizzo IP, un

servizio come Apache, un componente hardware come un'unità disco, una

risorsa del kernel come un filesystem.

Per ognuna delle risorse gestite da Heartbeat, esiste uno script in grado di

eseguire l'avvio (start), lo spegnimento (stop) similmente a quanto accade con

gli script presenti in “/etc/rc.d/”. Si parla di Resource Group per il fatto che

l'operazione di take-over da un nodo all'altro interessa tutte le risorse che un

certo nodo del cluster gestisce, quindi ad esempio il resource group di un dato

nodo potrebbe essere composto da un indirizzo IP sul quale fornisce dei

servizi, una certa partizione di disco affidata a DRBD sulla quale ad esempio

svolge ruolo primario e i servizi forniti all'indirizzo specificato all'inizio.

Nel momento in cui il nodo cade, il service group viene interamente migrato

sull'altro nodo e le risorse così trasferite vengono attivate così com'erano sul

nodo caduto.

114

Si consideri quindi l'importanza della risorsa disco rappresentata dal device

DRBD, che è virtualmente identica a quella presente sul nodo caduto: nel

momento del take-over viene semplicemente cambiato il ruolo del nodo

primario che adesso viene assunto dal nodo intervenuto in sostituzione di

quello caduto. Questo passaggio è possibile per il fatto che Heartbeat integra

uno script denominato datadisk espressamente scritto per i device DRBD.

6.3 Installazione e configurazioneL'installazione di Heartbeat non richiede particolari attenzioni. Si svolge

secondo lo standard della distribuzione Gentoo attraverso il comando

emerge heartbeat

Al solito viene scaricato il pacchetto sorgente da uno dei mirror Gentoo

disponibili per poi procedere alla compilazione della suite Heartbeat e alla

successiva installazione nei percorsi predefiniti.

Anche Heartbeat come ogni software per piattaforma *NIX, si configura

attraverso dei file di configurazione.

I file modificati per far sì che la suite Heartbeat rispondesse alle caratteristiche

peculiari del sistema sono stati sostanzialmente i seguenti:

/etc/ha.d/ha.cf

/etc/ha.d/haresources

/etc/ha.d/authkeys.

La configurazione dei tre file elencati evidenzia le politiche di gestione delle

risorse che si sono decise in fase di progetto e le funzioni di recovery e

monitoraggio che si è scelto di attivare. Si tenga presente che i file di

configurazione sono identici su entrambi i nodi.

115

6.3.1 Il file haresources

All'interno del file haresources vengono configurati i Resource Group per

ciascuno dei nodi.

Dato che in produzione il cluster avrà il compito di erogare due servizi in

configurazione Active/Active, viene definito un Resource Group per ogni

nodo.

Le righe all'interno del file haresources sono simili alle seguenti:

freedom 193.206.185.XXX datadisk::drbd0

independence 193.206.185.XXX datadisk::drbd1.

All'inizio di ogni riga, che denota ogni resource group, si trova l'hostname

(come specificato dall'output del comando uname -n) del nodo che ospita il

resource-group inizialmente. Successivamente si configura l'indirizzo IP al

quale il cluster dovrà rispondere nell'erogare i servizi, che viene generato

come “alias IP” dell'interfaccia di rete esterna, configurata cona la stessa

sottorete dell'indirizzo del resource group.

Per i due servizi che si devono erogare si sono configurati due device DRBD

denominati drbd0 e drbd1. Con lo script datadisk Heartbeat è in grado di dare

al nodo il ruolo primario per il device specificato provvedendo inoltre a

montare il device al percorso stabilito all'interno del file /etc/fstab. Per questo

motivo nel file /etc/fstab i dispositivi DRBD devono essere configurati con

l'opzione noauto per far sì che vengano montati correttamente da Heartbeat.

In particolare lo script datadisk esegue il comando

drbdsetup /dev/nbd/X primary

per rendere primario il nodo e montare il dispositivo,

116

drbdsetup /dev/nbd/X secondary

per rendere il nodo secondario dopo aver smontato il device ed eseguire

eventualmente il take-over del resource-group.

A questo punto si inseriscono i wrapper dei servizi che si vogliono erogare

così come sono specificati all'interno della directory “/etc/rc.d/”.

6.3.2 Il file ha.cf

Il file ha.cf viene letto da Heartbeat nel momento in cui viene lanciato

attraverso il comando

/etc/init.d/heartbeat start.

Tale file contiene le impostazioni necessarie affinchè la suite sia configurata

per adattarsi alle specifiche del sistema su cui va ad essere eseguita e per

soddisfare le politiche di gestione che si sono stabilite in fase di progetto.

Analizzando il file, contenuto integralmente in appendice, si trova la riga

keepalive 2

che specifica il tempo in secondi entro cui inviare due segnali di heartbeat fra i

due nodi; la riga

deadtime 5

stabilisce il tempo in secondi entro cui, non avendo risposto al segnale di

heartbeat, un nodo può essere considerato non funzionante;

initdead 120

117

imposta a 120 secondi il tempo di “deadtime” solo per la prima volta, quindi

subito dopo l'avvio di Heartbeat per far in modo che si consideri il tempo

necessario a stabilire la comunicazione fra i nodi e ad inizializzare i diversi

plugin che gestiscono le diverse funzioni di Heartbeat. Questo per evitare di

produrre un take-over delle risorse prima ancora che il sistema di heartbeat sia

stato completamente inizializzato.

La riga successiva

auto_failback on

sta ad indicare un particolare comportamento del cluster.

Secondo l'impostazione applicata quando un nodo rientra nel cluster dopo

esserne stato escluso per malfunzionamento o per manutenzione, in

quest'ultimo caso volontariamente da parte dell'amministratore, il service

group configurato per default su tale nodo viene automaticamente riportato

su di esso.

E' evidente che i servizi torneranno ad essere erogati su tale nodo solo dopo

che il file-system condiviso è stato sincronizzato. Il compito di verificare la

sincronizzazione dei block-device condivisi è assolto da DRBD.

Le righe seguenti impostano il sottosistema di comunicazione fra i nodi

utilizzato da Heartbeat. In particolare la riga

serial /dev/ttyS0

imposta il device seriale che eventualmente Heartbeat deve utilizzare per il

segnale di sincronizzazione;

bcast bond0

bcast eth2

118

specifica invece gli altri canali utilizzati per il segnale di sincronizzazione

ridondando quello seriale ed evitando così l'introduzione di “Single point of

failure”.

Si noti che il canale bond0, in cui la comunicazione avviene con il protocollo

TCP/IP, di per sé è già ridondato per il motivo specificato nel paragrafo 5.6.

Indirettamente assume un'importanza rilevante anche per il funzionamento di

Heartbeat in quanto rappresenta un canale in più di comunicazione fra i nodi

che diminuisce la probabilità di interruzione simultanea di tutti i canali interni

che causerebbe il pericoloso fenomeno del “brain-splitting”. Per questo

motivo si è ritenuto opportuno non dotare il sistema della funzionalità di

STONITH61 (Shoot The Other Node In The Head).

Si noti inoltre che il canale di comunicazione fra i nodi viene ulteriormente

ridondato dall'interfaccia di rete eth2; ma a questo proposito è necessaria una

precisazione: il canale eth2 corrisponde all'interfaccia attraverso cui il cluster

comunica con l'esterno e sulla quale eroga i servizi. Mandando il segnale di

Heartbeat anche su tale canale non si conoscono a priori quali saranno i

segmenti di rete che il pacchetto TCP/IP relativo a Heartbeat attraverserà

prima di raggiungere la destinazione.

Per questo motivo, al fine di garantire la sicurezza del sistema si rende

necessario codificare con un algoritmo sicuro le comunicazioni di Heartbeat.

L'algoritmo scelto, il più sicuro supportato da Heartbeat è sha1. Tale

impostazione va applicata nel file authkeys come si vedrà più avanti in questo

stesso paragrafo. L'overhead computazionale introdotto dalla codifica con

sha1 rispetto al crc è assolutamente irrilevante per la potenza di calcolo

dell'hardware in uso.

61 Heartbeat fornisce attraverso plugin supporto alla funzionalità di STONITH e attraverso unmeccanismo di arbitraggio, stabilisce quale dei due nodi deve essere drasticamente disattivato inviandoquindi al dispositivo hardware apposito il comando di disattivazione dell'alimentazione elettrica.

119

Le righe successive specificano i nomi dei nodi del cluster così come risulta

dall'output del comando uname -n.

Le righe seguenti sono di particolare importanza in quanto provvedono a far

eseguire ad Heartbeat comandi corrispondenti a plugin della suite o comandi

esterni che vengono lanciati come processi “figli” di Heartbeat.

Con la riga

respawn hacluster /usr/lib/heartbeat/ipfail

si provvede a far eseguire ad Heartbeat il proprio plugin “ipfail” con i privilegi

dell'utente “hacluster”.

Il plugin “ipfail” si occupa di monitorare costantemente il collegamento del

nodo con l'esterno. Nel caso in cui il nodo risulti isolato è evidente che non

può erogare alcun servizio e in tal caso “ipfail” richiede un fail-over del

Resource Group.

Il comando “respawn” all'inizio della riga, specifica che Heartbeat si

preoccuperà di monitorare costantemente il funzionamento del processo e di

rilanciarlo nel caso in cui venga interrotto.

Allo stesso modo vengono avviati anche altri due programmi esterni che

saranno analizzati più in dettaglio nel capitolo 7, si tratta di “mon” e

“swatch”, due tool di monitoraggio che controllano rispettivamente

l'erogazione effettiva dei servizi e i file di log alla ricerca di alcune particolari

stringhe.

Le righe che eseguono tali programmi sono le seguenti:

respawn root /usr/bin/swatch -t /var/log/ha-log -t /var/log/messages

respawn root /usr/sbin/mon.

120

L'ultima riga del file ha.cf configura l'indirizzo IP verso cui eseguire il

comando di “ping” utilizzato da “ipfail” per verificare il collegaento del nodo

con l'esterno.

E' evidente che tale indirizzo IP deve corrispondere a un host sicuro e sempre

funzionante e in questo caso è stato scelto il gateway della rete esterna.

La riga è la seguente:

ping 193.206.185.1.

6.3.3 Il file authkeys

Come analizzato nel paragrafo 6.2, tutte le comunicazioni che avvengono fra i

nodi sono cifrate e autenticate per evitare problemi di sicurezza che

potrebbero falsare il corretto funzionamento di Heartbeat.

Attraverso i plugin di autenticazione, Heartbeat consente l'utilizzo di algoritmi

crittografici più o meno sicuri affinchè si renda possibile un corretto

bilanciamento fra prestazioni e sicurezza in relazione all'ambiente operativo

del cluster [5].

Nel file “authkeys” si configura appunto l'algoritmo crittografico per le

comunicazioni fra i nodi ed in particolare attraverso le righe

auth 1

1 sha1 freedom-independence-fr

si specifica di utilizzare per il cluster l'algoritmo “sha1”.

Questa scelta è dovuta al fatto che le comunicazioni fra i nodi avvengono

anche attraverso un canale insicuro, eth2.

121

6.4 Gratuitous ARPParticolare attenzione va posta nella configurazione della rete esterna alla

quale il cluster eroga i servizi. Questa attenzione maggiore è dovuta al

particolare meccanismo che Heartbeat utilizza per migrare il Resource Group

da un nodo all'altro.

Come già evidenziato nel paragrafo 6.3.1, l'indirizzo IP di ogni Resource

Group al quale i diversi servizi rispondono, è un alias dell'indirizzo

configurato sull'interfaccia di rete esterna.

In caso di fail-over, tale indirizzo deve essere migrato da un nodo all'altro con

il Resource Group, il cluster cioè deve continuare a rispondere allo stesso

indirizzo per l'erogazione dei vari servizi.

Il meccanismo che Heartbeat utilizza per far in modo che i pacchetti destinati

ad un certo indirizzo IP raggiungano un host diverso dal precedente, fa uso

dei cosiddetti “Gratuitous ARP”.

Come da modello ISO-OSI [1], il protocollo ARP (Address Resolution

Protocol), si occupa di instradare i pacchetti ethernet eseguendo la traduzione

da indirizzi IP del livello 3 del modello ISO-OSI, in indirizzi ethernet del

livello 2, relativi alle interfacce di rete presenti su ogni host di una rete e

realizzando così l'astrazione data-link. Ogni host della rete solitamente

conserva una tabella di associazione fra indirizzi IP e indirizzi MAC che viene

aggiornata periodicamente in base alle impostazioni che l'amministratore ha

predefinito. Tali tabelle sono conservate anche all'interno di dispositivi di

instradamento come router e switch per far in modo che i pacchetti destinati

ad un dato host vengano recapitati direttamente senza eseguire prima la

richiesta in broadcast dell'indirizzo ethernet.

Attraverso i “Gratuitous ARP” si chiede agli host della rete (fra cui i

dispositivi di instradamento) di aggiornare la propria tabella ARP associando

un dato indirizzo IP ad un certo indirizzo MAC.

122

Il problema sta nel fatto che alcuni dispositivi di instradamento sono

configurati per rifiutare i gratuitous-ARP al fine di evitare tecniche di cracking

basate su ARP-spoofing[2].

Per poter utilizzare correttamente Heartbeat è dunque necessario utilizzare

dispositivi che consentano i gratuitous-ARP.

123

C a p i t o l o 7

STRUMENTI DI MONITORAGGIO E TEST DEL SISTEMA

In questo capitolo si analizzano alcuni strumenti che sono stati installati e

configurati sul cluster al fine di fornire funzionalità aggiuntive necessarie a

facilitare le mansioni di amministrazione e controllo del corretto

funzionamento del cluster stesso.

Tali strumenti non sono indispensabili all'erogazione dei servizi in alta

disponibilità in quanto svolgono solo la funzione di monitoraggio del corretto

funzionamento; sono tuttavia molto importanti in quanto consentono di

prevenire problemi più gravi aumentando così ulteriormente i periodi di

erogazione.

Precisamente gli strumenti utilizzati per svolgere il monitoraggio del cluster

sono mon, swatch, webmin.

Come specificato nel capitolo 6.3.2, i programmi mon e swatch sono avviati da

Heartbeat come processi “figli” e costantemente monitorati. Questa

configurazione è stata scelta per realizzare una integrazione di strumenti

esterni nella suite Heartbeat evidenziando anche la flessibilità di tale suite

tipica dei tool pensati per piattaforme *NIX.

Al termine di questo capitolo viene descritto un test eseguito per verificare il

corretto funzionamento del cluster, basato sull'erogazione in alta disponibilità

di un web server.

7.1 MonMon è un tool di monitoraggio molto versatile e altamente configurabile che

attraverso degli script creati ad hoc, molti dei quali forniti nel pacchetto di

124

installazione del software, verifica il funzionamento di alcune risorse del

sistema sul quale è installato.

In linea di massima, mon non è uno strumento costruito specificamente per

l'impiego in sistemi cluster e tanto meno in sistemi per l'alta disponibilità, ma

è talemente flessibile da poterlo configurare per svolgere una ruolo quasi

indispensabile, nel cluster che si è configurato.

La funzione di mon all'interno del cluster oggetto di questa tesi riguarda il

monitoraggio dell'effettiva erogazione dei servizi.

Considerando ad esempio il test che viene descritto alla fine del presente

capitolo riguardante l'erogazione di un web server, mon interroga il server ad

intervalli regolari verificando che la sua risposta sia quella attesa. Nel caso il

server emetta una risposta diversa mon genera il fail-over del resource group

dal nodo attivo al nodo in standby.

Mon ha la possibilità di essere avviato come un normale programma a riga di

comando o attraverso il wrapper posizionato in “/etc/init.d”.

La possibilità di eseguire mon a riga di comando consente di specificare

opzioni di esecuzione differenti come ad esempio un diverso file di

configurazione, che potrebbe fornire diversi vantaggi soprattutto in fase di

testing della configurazione.

7.1.1 Installazione e configurazione

Anche l'installazione e la configurazione di mon segue gli standard della

distribuzione Linux “Gentoo”, visto che i sorgenti del software sono presenti

all'interno del portage62.

62 cfr. cap. 2

125

L'installazione dunque viene eseguita con il comando

emerge mon.

La configurazione è stata effettuata classicamente attraverso file di testo che

per la distribuzione “Gentoo”, sono collocati all'interno della directory

“/etc/mon.d/” e in particolare i file modificati per la configurazione di mon

sono stati mon.cf e auth.cf.

La parte principale del file mon.cf entro la quale si configura il monitor del

servizio web basato su Apache utilizzato per il test del sistema è la seguente:

## define groups of hosts to monitor#hostgroup test_apache2 193.206.185.XXX

watch test_apache2service apache2

interval 5smonitor http.monitorperiod wd {Mon-Sun} hr {0-23}

alertafter 2alert mail.alert root@localhostalert apache2-restart.alert

service apache2-takeoverinterval 5smonitor http.monitorperiod wd {Mon-Sun} hr {0-23}

alertafter 3 30mnumalerts 1alert mail.alert -S "Apache2 non riparte, provvedo a fermare heartbeat per causare il takeover" root@localhostalert haStop.alert

Come si nota mon opera a un livello più alto rispetto a Heartbeat. Mon astrae

l'hardware su cui il servizio viene erogato e verifica direttamente l'indirizzo IP

del servizio fornito in alta disponibilità, raggiungendolo dall'interfaccia di rete

esterna secondo quanto specificato dalla riga hostgroup.

126

La riga watch identifica un gruppo di test e nel caso in esame il gruppo di test

test_apache2 è formato da apache2 e apache2-takeover configurati dalla direttiva

service.

Il test “apache2” viene eseguito ogni 5 secondi eseguendo lo script fornito

con il pacchetto di installazione http.monitor.

Secondo la direttiva period il test viene eseguito nei giorni che vanno dal lunedi

alla domenica e nelle ore comprese fra le 0 e le 23: praticamente sempre.

La direttiva alertafter 2 specifica che mon deve eseguire gli script di allarme,

specificati subito dopo, dopo il secondo tentativo fallito quindi dopo 10

secondi di inattività del server. Se ciò succede, mon provvede ad eseguire gli

script di allarme inviando prima un messaggio e-mail all'amministratore e

provvedendo poi automaticamente a riavviare il server Apache con la

direttiva alert http.alert facente uso dello script http.alert.

Il test apache2-takeover è sostanzialmente simile al precedente. L'unica grande

differenza sta nella direttiva alertafter 3 30m in cui si chiede a mon di eseguire i

successivi script di allarme dopo 3 tentativi falliti in 30 minuti.

La situazione di tre tentativi falliti si verificherà necessariamente dopo il

tentativo fatto dal test precedente apache2, di riavviare il server. Se si è

verificato il terzo tentativo fallito, vuol dire che neanche il riavvio del server è

servito a rendere disponibile il servizio perciò in questo caso l'unica soluzione

possibile rimane il fail-over sull'altro nodo. E' ciò che esegue lo script di

allarme specificato dalla direttiva alert haStop.alert dopo che è stato inviato

all'amministratore un messaggio e-mail.

Gli script http.alert e hatop.alert (presentati in appendice) sono stati creati

appositamente per adattare mon al funzionamento combinato con Apache e

Heartbeat[2]. In particolare http.alert contiene la sola riga /etc/init.d/apache2

restart e haStop.alert contiene la riga /etc/init.d/heartbeat stop, necessaria per

127

fermare Heartbeat sul nodo monitorato e sufficiente a causare il fail-over del

service group sull'altro nodo.

Ci sono funzioni di mon che, a causa della criticità per la sicurezza del sistema

dovrebbero essere eseguite solo dall'amministratore del sistema. Per questo

motivo il file auth.cf stabilisce per ogni funzione di mon quali sono gli utenti

che hanno i privilegi di eseguirle.

Nel caso del cluster realizzato, il solo amministratore è in grado di effettuare il

reset, o di rileggere il file delle autorizzazioni, appunto auth.cf. Tutti gli utenti

possono invece visualizzare le liste contenenti i test che non sono andati a

buon fine, i test che hanno avuto successo o ancora, possono visualizzare lo

stato di mon.

Mon viene avviato attraverso Heartbeat come processo “figlio” e da

quest'ultimo continuamente monitorato.

Il file di configurazione di “mon” è relativo solo ai servizi che il nodo su cui è

installato fornisce. Nel momento in cui il resource-group viene migrato

sull'altro a causa di crash sul nodo active, monitorare ancora il servizio è

ininfluente perché anche in caso di ulteriori problemi il fail-over, provocato

da mon, non servirebbe a nulla.

7.2 WebminWebmin è uno strumento di gestione del sistema scritto interamente nel

linguaggio Perl ed è orientato alla gestione del sistema operativo e della sua

configurazione attraverso l'utilizzo di interfacce grafiche basate su pagine

web.

La sua struttura modulare consente la scrittura di moduli necessari alle proprie

esigenze e integrarli nel sistema. Per questo motivo, già inseriti nel pacchetto

di installazione ci sono i moduli per la configurazione e la gestione di

Heartbeat e di mon.

128

La forza di Webmin oltre che nell'interfaccia grafica sta soprattutto nella sua

architettura. Esso infatti è costruito sul modello client-server per cui per

poterlo utilizzare è necessario avviare il server Webmin attraverso il wrapper e

questo sarà in ascolto sulla porta 10000.

Con un browser, da locale o da remoto è possibile accedere a Webmin

specificando sulla barra dell'indirizzo la stringa http://nomehost:10000.

Webmin supporta inoltre connessioni cifrate basate sulle librerie SSL (Secure

Socket Layer) per rendere indecifrabili le comunicazioni fra client e server

quando vi si accede da remoto. E' inoltre necessario, ogni qualvolta si vuole

entrare nell'interfaccia di gestione del sistema, loggarsi con user-name e

password come in un normale login al sistema. Gli utenti e le password sono

infatti reperiti dal file /etc/passwd.

L'installazione di Webmin avviene nel solito modo col comando

emerge webmin,

e si è inoltre provveduto ad impostare il sistema operativo per caricare il

server Webmin ad ogni riavvio col comando

rc-update add webmin default.

La configurazione di Webmin ha richiesto pochi passaggi inerenti in

particolare l'impostazione della connessione cifrata come metodo di

collegamento di default e l'impostazione dei giusti percorsi dei file di

configurazione per quanto riguarda invece i moduli di Heartbeat e mon.

Il modulo Webmin di Heartbeat consente di svolgere tutte le operazioni di

gestione della suite che normalmente si eseguono modificando i file di

configurazione e consente inoltre di eseguire manualmente il take-over dei

resource-group da un nodo all'altro, tutto attraverso l'interfaccia grafica web-

based.

129

Il modulo inerente mon è invece basato su uno script “cgi” contenuto nel file

“mon.cgi” che visualizza graficamente lo stato delle risorse monitorate e le

temporizzazioni intercorrenti fra i vari test.

Dalla stessa interfaccia è inoltre possibile eseguire tutte le operazioni di

gestione di mon, come la visualizzazione della lista dei test riusciti e falliti o il

riavvio del programma, dipendentemente comunque dai permessi utente di

cui si dispone.

Teoricamente attraverso Webmin è possibile amministrare completamente il

cluster costruito facendo uso dell'intuitiva interfaccia grafica. Per le operazioni

più critiche è comunque consigliabile accedere al sistema attraverso shell e

utilizzare le operazioni a riga di comando.

7.3 SwatchSwatch è uno strumento di analisi dei log.

Tutti i programmi progettati per la piattaforma *NIX compreso il sistema

operativo stesso, durante il normale svolgimento delle operazioni o quando si

verificano particolari errori, emettono dei messaggi di log memorizzandoli in

appositi file contenuti solitamente nella directory /etc/var/log [6].

Ogni amministratore di sistema periodicamente dovrebbe analizzare i file di

log alla ricerca di messaggi particolari per prevenire errori gravi o problemi

irreversibili. Ci sono tuttavia dei messaggi che possono indicare un

malfunzionamento imminente e che richiedono azioni immediate da parte

dell'amministratore. Per questo scopo si utilizza Swatch.

Swatch tiene costantemente sotto controllo alcuni file di log che gli sono stati

specificati e reagisce quando all'interno dei file riscontra una particolare

stringa specificata nel suo file di configurazione.

130

Le azioni tipiche che swatch può eseguire riguardano l'invio di e-mail, l'output

a console di messaggi, l'emissione di suoni o l'esecuzione di comandi.

Swatch è presente nel portage di “Gentoo” per cui l'installazione è stata

eseguita con

emerge swatch.

La configurazione di swatch si basa semplicemente sull'editing del file di

configurazione contenuto nella directory di root e denominato .swatchrc.

Viene ora presentato un estratto del file di configurazione

/root/.swatcrc installato nel cluster.

watchfor /dead/echo bold undersore blinkbell write rootcontinue

La direttiva watchfor indica la particolare stringa da ricercare all'interno dei file

specificati nella riga di comando di swatch. Ogni volta che viene riscontrata

tale stringa, viene emesso un suono con la direttiva bell e visualizzata la riga

contenente la stringa trovata sulla console di root attraverso la direttiva

write root.

Swatch viene eseguito da Heartbeat come processo “figlio” attraverso il

comando

swatch -t /var/log/ha-log -t /var/log/messages

e ciò significa che swatch comincerà a monitorare costantemente i file

/var/log/ha-log

131

e /var/log/messages che contengono rispettivamente i messaggi emessi da

Heartbeat e i messaggi emessi dal kernel.

7.4 Test del sistemaIl sistema così configurato consente l'erogazione di qualunque servizio, in alta

disponibilità L'alta disponibilità è sempre garantita, modificando

opportunamente alcuni file di configurazione, in particolare il file

/etc/ha.d/haresources, per aggiungere servizi da erogare e il file

/etc/mon.d/mon.cf, per adattare “mon” ai servizi che si devono fornire.

Per verificare il corretto funzionamento del sistema si è provveduto a titolo

sperimentale ad installare ed erogare in alta disponibilità un servizio web

basato sul server Apache.

Dopo aver eseguito l'installazione del server con il comando

emerge apache

si è provveduto a modificare i file di configurazione nel modo seguente:

• /etc/ha.d/haresources contiene la riga freedom 193.206.185.XXX

datadisk::drbd0 apache2;

• /etc/mon.d/mon.cf contiene le righe già descritte al paragrafo 7.1.1.

La configurazione specificata nel file harsources consente di avviare sul nodo

“freedom” il server apache attivando contestualmente un alias IP

sull'interfaccia di rete esterna e montando il DRBD block device /dev/nbd/0

al percorso specificato opportunamente nel file /etc/fstab corrispondente a

/home/httpd/.

132

Il server è stato configurato per rimanere in ascolto allo stesso indirizzo IP

specificato in haresources ed è stato impostato, come directory del sito web

fornito da apache, il percorso /home/httpd/www, corrispondente quindi ad una

directory residente sul DRBD block device montato da Heartbeat attraverso

l'impostazione nel file haresources.

La pagina che apache fornirà puntando un qualunque browser all'indirizzo

193.206.185.XXX è la sua pagina predefinita nella quale è stato inserito un

link al file server.php, residente nella stessa directory.

Il file server.php è una pagina web che incorpora alcuni script PHP63, necessari

alla visualizzazione dell'hostname della macchina che sta eseguendo il server

apache. In questo caso tale pagina PHP visualizzerà l'hostname del particolare

nodo del cluster che in quel momento sta effettivamente erogando il web

server ed altre informazioni riguardanti lo stato del web server.

Si è provveduto a questo punto ad avviare Heartbeat sul nodo “freedom” e

successivamente sul nodo “independence” ottenendo così l'avvio del server

apache sul nodo “freedom” in ascolto sulla porta 80 all'indirizzo

193.206.185.XXX.

Puntando un browser con un host remoto allo stesso indirizzo IP si ottiene la

pagina seguente:

63 PHP: Linguaggio di scripting integrabile direttamente all'interno del codice HTML che costituisce unaqualunque pagina web. Per poter essere eseguito è necessario il supporto da parte del server web.

133

La pagina web nell'illustrazione 17 è sufficiente per verificare il corretto

funzionamento del server apache sull'indirizzo generato da Heartbeat.

Per verificare inoltre qual'è effettivamente il nodo del cluster che sta fornendo

il servizio web è sufficiente cliccare sul link in fondo alla pagina per ottenere il

caricamento del file server.php.

134

Illustrazione 17: pagina predefinita

Come si legge dall'illustrazione 18, il nodo che fornisce la pagina web su cui è

in esecuzione il server apache è “freedom”.

A questo punto si può simulare un crash del nodo “freedom” attraverso lo

shutdown manuale di Heartbeat con il comando

/etc/init.d/heartbeat stop

al fine di causare il failover del resource-group del nodo “freedom” sul nodo

“independence”.

Interrompendo Heartbeat su “freedom”si interrompe la comunicazione con

l'altro nodo del cluster. Così facendo Heartbeat in esecuzione sul nodo

“independence”, non ricevendo più segnali da “freedom” (da nessuno dei

canali di comunicazione ridondati), stabilisce che l'erogazione del gruppo di

135

Illustrazione 18: caratteristiche del server lette dal file “server.php”

servizi forniti da “freedom” ha subito un'interruzione e provvede così ad

eseguire il take-over del resource-group di “freedom”.

I messaggi emessi da Heartbeat su independence, sono inseriti nel file

/var/log/ha-log visualizzati di seguito.

L'illustrazione 19, mostra la sequenza di operazioni eseguite da Heartbeat per

effettuare il take-over del resource-group di freedom e mostra inoltre i

messaggi che denotano l'interruzione dei collegamenti seriale ed ethernet, con

il nodo “freedom”.

La situazione così simulata si può verificare in seguito a varie cause: il crash

del nodo; l'interruzione irreversibile del server apache, e in tal caso è mon che

forza l'interruzione di Heartbeat; l'isolamento del nodo dall'esterno, a causa

dell'interruzione del canale eth2 e in questo caso il plugin “ipfail” di Heartbeat

genera il take-over del resource group di “freedom” su “independence”.

136

Illustrazione 19: messaggi di Heartbeat su "independence"

Ecco come appare adesso lo stato del server.

Alla fine del take-over delle risorse su “independence”, il servizio apache che

risponde all'indirizzo 193.206.185.XXX ha subito un'interruzione di pochi

secondi dopodichè il nodo “independence” si è fatto carico del servizio come

dimostrato dall'illustrazione 20 che mostra lo stesso file server.php (dato che è

situato sul DRBD block-device, dunque condiviso fra i nodi), che

nell'illustrazione 18 era erogato dal nodo “freedom”.

Quando il nodo “freedom” viene riavviato, si provvede a rimetterlo nel

cluster facendo ripartire Heartbeat con il comando

/etc/init.d/heartbeat start.

137

Illustrazione 20: caratteristiche server apache su "independence"

A questo punto, secondo l'impostazione “auto_failback on” specificata nel

file ha.cf, il resource group del nodo “freedom” viene automaticamente

migrato da “independence”, cosicchè il server apache e l'alias IP

193.206.185.XXX tornano ad essere erogati dal nodo “freedom” secondo

l'impostazione predefinita specificata nel file haresources.

In questo stato, la pagina PHP server.php erogata dal cluster è la stessa

visualizzata nell'illustrazione 18.

Il corretto funzionamento del cluster è possibile monitorarlo anche attraverso

Webmin, infatti puntando il browser all'IP di ognuno dei nodi alla porta

10000, dopo aver effettuato il login, è possibile aprire le pagine inerenti

“mon” ed “Heartbeat”.

La pagina relativa a “mon” viene aggiornata ad intervalli regloari e mostra

attraverso colorazioni particolari lo stato del monitoraggio.

138

Illustrazione 21: modulo Webmin relativo a "mon"

Attraverso l'interfaccia Webmin visualizzata nell'illustrazione 21 è inoltre

possibile eseguire diverse operazioni di gestione e configurazione del

programma “mon”.

Il modulo Webmin relativo a Heartbeat permette una gestione completa della

suite e consente inoltre di eseguire il take-over dei resource-group attraverso

l'interfaccia grafica come si può vedere nell'illustrazione 22.

Come si può notare il take-over può essere eseguito semplicemente

premendo i pulsanti visualizzati nell'illustrazione 22. Dalla stessa illustrazione

si può notare la diversa colorazione relativa allo stato delle risorse in quanto la

visualizzazione è riferita al nodo “freedom” per cui risultano attive, di colore

verde, le risorse erogate da tale nodo.

139

Illustrazione 22: modulo Webmin relativo a Heartbeat

APPENDICE

140

FILE DI CONFIGURAZIONE

A1. /etc/fstab/dev/sda1 /boot ext2 noauto,noatime 1 1/dev/sda3 / ext3 noatime 0 0/dev/sda2 none swap sw 0 0/dev/sda5 /usr ext3 noatime 0 0/dev/sda6 /var ext3 noatime 0 0/dev/sda7 /tmp ext3 noexec,nosuid 0 0/dev/sda8 /opt ext3 noatime 0 0/dev/sda9 /home ext3 nosuid 0 0/dev/nbd/0 /bind ext3 noatime,noauto 0 0/dev/nbd/1 /sendmail ext3 noatime,noauto 0 0

/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0/dev/fd0 /mnt/floppy vfat noauto 0 0# NOTE: The next line is critical for boot!none /proc proc defaults 0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for# POSIX shared memory (shm_open, shm_unlink).# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will# use almost no memory if not populated with files)# Adding the following line to /etc/fstab should take care of this:none /dev/shm tmpfs defaults 0 0

A2. /etc/make.conf# Copyright 2000-2002 Daniel Robbins, Gentoo Technologies, Inc.# Contains local system settings for Portage system# Please review 'man make.conf' for more information.

# Build-time functionality# ========================## The USE variable is used to enable optional build-time functionality. For# example, quite a few packages have optional X, gtk or GNOME functionality# that can only be enabled or disabled at compile-time. Gentoo Linux has a# very extensive set of USE variables described in our USE variable HOWTOat# http://www.gentoo.org/doc/use-howto.html## The available list of use flags with descriptions is in your portagetree.# Use 'less' to view them: --> less /usr/portage/profiles/use.desc <--## Example:#USE="X gtk gnome -alsa"USE="php"

# Host Setting# ============#

141

# If you are using a Pentium Pro or greater processor, leave this line as-is;# otherwise, change to i586, i486 or i386 as appropriate. All modernsystems# (even Athlons) should use "i686-pc-linux-gnu"#CHOST="i686-pc-linux-gnu"

# Host and optimization settings # ==============================## For optimal performance, enable a CFLAGS setting appropriate for your CPU## -mcpu=<cpu-type> means optimize code for the particular type of CPUwithout# breaking compatibility with other CPUs.## -march=<cpu-type> means to take full advantage of the ABI andinstructions# for the particular CPU; this will break compatibility with older CPUs(for# example, -march=athlon-xp code will not run on a regular Athlon, and# -march=i686 code will not run on a Pentium Classic.## CPU types supported in gcc-3.2 and higher: athlon-xp, athlon-mp, athlon-4,# athlon-tbird, athlon, k6, k6-2, k6-3, i386, i486, i586 (Pentium), i686# (PentiumPro), pentium, pentium-mmx, pentiumpro, pentium2 (Celeron),pentium3,# and pentium4. Note that Gentoo Linux 1.4 and higher include at least gcc-3.2.# # CPU types supported in gcc-2.95*: k6, i386, i486, i586 (Pentium), i686# (Pentium Pro), pentium, pentiumpro Gentoo Linux 1.2 and below use gcc-2.95*## Decent examples:##CFLAGS="-mcpu=athlon-xp -O3 -pipe"CFLAGS="-O3 -march=pentium4 -funroll-loops -pipe"

# If you set a CFLAGS above, then this line will set your default C++ flagsto# the same settings. If you don't set CFLAGS above, then comment this lineout.CXXFLAGS="${CFLAGS}"

# Advanced Masking# ================## Gentoo is using a new masking system to allow for easier stabilitytesting# on packages. KEYWORDS are used in ebuilds to mask and unmask packagesbased# on the platform they are set for. A special form has been added that# indicates packages and revisions that are expected to work, but have notyet# been approved for the stable set. '~arch' is a superset of 'arch' which# includes the unstable, in testing, packages. Users of the 'x86'architecture# would add '~x86' to ACCEPT_KEYWORDS to enable unstable/testing packages.# '~ppc', '~sparc', '~sparc64' are the unstable KEYWORDS for theirrespective# platforms. DO NOT PUT ANYTHING BUT YOUR SPECIFIC ~ARCHITECTURE IN THELIST.# IF YOU ARE UNSURE OF YOUR ARCH, OR THE IMPLICATIONS, DO NOT MODIFY THIS.##ACCEPT_KEYWORDS="~arch"

142

# Portage Directories# ===================## Each of these settings controls an aspect of portage's storage and file# system usage. If you change any of these, be sure it is available when# you try to use portage. *** DO NOT INCLUDE A TRAILING "/" ***## PORTAGE_TMPDIR is the location portage will use for compilations and# temporary storage of data. This can get VERY large depending upon# the application being installed.PORTAGE_TMPDIR="/var/tmp"## PORTDIR is the location of the portage tree. This is the repository# for all profile information as well as all ebuilds. This directory# itself can reach 200M. WE DO NOT RECOMMEND that you change this.PORTDIR="/usr/portage"## DISTDIR is where all of the source code tarballs will be placed for# emerges. The source code is maintained here unless you delete# it. The entire repository of tarballs for gentoo is 9G. This is# considerably more than any user will ever download. 2-3G is# a large DISTDIR.DISTDIR="${PORTDIR}/distfiles"## PKGDIR is the location of binary packages that you can have created# with '--buildpkg' or '-b' while emerging a package. This can get# upto several hundred megs, or even a few gigs.PKGDIR="${PORTDIR}/packages"## PORTDIR_OVERLAY is a directory where local ebuilds may be stored without# concern that they will be deleted by rsync updates. Default is not# defined.#PORTDIR_OVERLAY="/usr/local/portage"

# Fetching files # ==============## If you need to set a proxy for wget or lukemftp, add the appropriate"export# ftp_proxy=<proxy>" and "export http_proxy=<proxy>" lines to /etc/profileif# all users on your system should use them.## Portage uses wget by default. Here are some settings for some alternate# downloaders -- note that you need to merge these programs first beforethey# will be available.## Lukemftp (BSD ftp):#FETCHCOMMAND="/usr/bin/lukemftp -s -a -o \${DISTDIR}/\${FILE} \${URI}"#RESUMECOMMAND="/usr/bin/lukemftp -s -a -R -o \${DISTDIR}/\${FILE} \${URI}"## Prozilla (turbo downloader)#FETCHCOMMAND='/usr/bin/proz --no-getch -s ${URI} -P ${DISTDIR}'

# Advanced Features# =================## MAKEOPTS provides extra options that may be passed to 'make' when a# program is compiled. Presently the only use is for specifying# the number of parallel makes (-j) to perform. The suggested number# for parallel makes is CPUs+1.MAKEOPTS="-j3"## AUTOCLEAN enables portage to automatically clean out older or overlapping# packages from the system after every successful merge. This is the

143

# same as running 'emerge -c' after every merge. Set with: "yes" or"no".#AUTOCLEAN="yes"## FEATURES are settings that affect the functionality of portage. Most of# these settings are for developer use, but some are available to non-# developers as well. 'buildpkg' is an always-on setting for the emerge# flag of the same name. It causes binary packages to be created of all# packages that are merged.#FEATURES="sandbox ccache buildpkg"## RSYNC_RETRIES sets the number of times portage will attempt to retrieve# a current portage tree before it exits with an error. This allows# for a more successful retrieval without user intervention most times.#RSYNC_RETRIES="3"GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.tu-clausthal.de/pub/linux/gentoo/http://212.219.247.11/sites/www.ibiblio.org/gentoo/http://212.219.247.15/sites/www.ibiblio.org/gentoo/ftp://ftp.iasi.roedu.net/pub/mirrors/gentoo.org/"

A3. /etc/lilo.confboot=/dev/sda map=/boot/System.mapinstall=/boot/boot.bprompttimeout=30lba32default=2.4.26vga=789

image=/boot/bzImageinitrd=/boot/initrd-2.4.20-gentoo-r8label=2.4.20-g-r8read-onlyroot=/dev/sda3

image=/boot/kernel-2.4.25label=2.4.25read-onlyroot=/dev/sda3

image=/boot/kernel-2.4.26label=2.4.26read-onlyroot=/dev/sda3

A4. /usr/src/linux/.config

CONFIG_X86=yCONFIG_UID16=y

CONFIG_EXPERIMENTAL=y

144

CONFIG_MODULES=yCONFIG_MODVERSIONS=yCONFIG_KMOD=y

CONFIG_MPENTIUM4=yCONFIG_X86_WP_WORKS_OK=yCONFIG_X86_INVLPG=yCONFIG_X86_CMPXCHG=yCONFIG_X86_XADD=yCONFIG_X86_BSWAP=yCONFIG_X86_POPAD_OK=yCONFIG_RWSEM_XCHGADD_ALGORITHM=yCONFIG_X86_L1_CACHE_SHIFT=7CONFIG_X86_HAS_TSC=yCONFIG_X86_GOOD_APIC=yCONFIG_X86_PGE=yCONFIG_X86_USE_PPRO_CHECKSUM=yCONFIG_X86_F00F_WORKS_OK=yCONFIG_NOHIGHMEM=yCONFIG_MTRR=yCONFIG_SMP=yCONFIG_NR_CPUS=32CONFIG_X86_TSC=yCONFIG_HAVE_DEC_LOCK=y

CONFIG_NET=yCONFIG_X86_IO_APIC=yCONFIG_X86_LOCAL_APIC=yCONFIG_PCI=yCONFIG_PCI_GOANY=yCONFIG_PCI_BIOS=yCONFIG_PCI_DIRECT=yCONFIG_PCI_NAMES=yCONFIG_HOTPLUG=y

CONFIG_SYSVIPC=yCONFIG_SYSCTL=yCONFIG_KCORE_ELF=yCONFIG_BINFMT_AOUT=yCONFIG_BINFMT_ELF=yCONFIG_BINFMT_MISC=y

CONFIG_ACPI_BOOT=y

CONFIG_PARPORT=mCONFIG_PARPORT_PC=mCONFIG_PARPORT_PC_CML1=mCONFIG_PARPORT_PC_FIFO=yCONFIG_PARPORT_PC_SUPERIO=yCONFIG_PARPORT_OTHER=yCONFIG_PARPORT_1284=y

CONFIG_PNP=mCONFIG_ISAPNP=m

CONFIG_BLK_DEV_FD=mCONFIG_PARIDE=mCONFIG_PARIDE_PARPORT=mCONFIG_PARIDE_PD=mCONFIG_PARIDE_PCD=m

145

CONFIG_PARIDE_PF=mCONFIG_PARIDE_PT=mCONFIG_PARIDE_PG=mCONFIG_BLK_DEV_LOOP=yCONFIG_BLK_DEV_NBD=mCONFIG_BLK_DEV_RAM=yCONFIG_BLK_DEV_RAM_SIZE=8192CONFIG_BLK_DEV_INITRD=y

CONFIG_PACKET=yCONFIG_PACKET_MMAP=yCONFIG_NETFILTER=yCONFIG_FILTER=yCONFIG_UNIX=yCONFIG_INET=y

CONFIG_IP_NF_CONNTRACK=mCONFIG_IP_NF_FTP=mCONFIG_IP_NF_AMANDA=mCONFIG_IP_NF_TFTP=mCONFIG_IP_NF_IRC=mCONFIG_IP_NF_IPTABLES=mCONFIG_IP_NF_MATCH_LIMIT=mCONFIG_IP_NF_MATCH_MAC=mCONFIG_IP_NF_MATCH_PKTTYPE=mCONFIG_IP_NF_MATCH_MARK=mCONFIG_IP_NF_MATCH_MULTIPORT=mCONFIG_IP_NF_MATCH_TOS=mCONFIG_IP_NF_MATCH_RECENT=mCONFIG_IP_NF_MATCH_ECN=mCONFIG_IP_NF_MATCH_DSCP=mCONFIG_IP_NF_MATCH_AH_ESP=mCONFIG_IP_NF_MATCH_LENGTH=mCONFIG_IP_NF_MATCH_TTL=mCONFIG_IP_NF_MATCH_TCPMSS=mCONFIG_IP_NF_MATCH_HELPER=mCONFIG_IP_NF_MATCH_STATE=mCONFIG_IP_NF_MATCH_CONNTRACK=mCONFIG_IP_NF_FILTER=mCONFIG_IP_NF_TARGET_REJECT=mCONFIG_IP_NF_NAT=mCONFIG_IP_NF_NAT_NEEDED=yCONFIG_IP_NF_TARGET_MASQUERADE=mCONFIG_IP_NF_TARGET_REDIRECT=mCONFIG_IP_NF_NAT_AMANDA=mCONFIG_IP_NF_NAT_IRC=mCONFIG_IP_NF_NAT_FTP=mCONFIG_IP_NF_NAT_TFTP=mCONFIG_IP_NF_MANGLE=mCONFIG_IP_NF_TARGET_TOS=mCONFIG_IP_NF_TARGET_ECN=mCONFIG_IP_NF_TARGET_DSCP=mCONFIG_IP_NF_TARGET_MARK=mCONFIG_IP_NF_TARGET_LOG=mCONFIG_IP_NF_TARGET_ULOG=mCONFIG_IP_NF_TARGET_TCPMSS=m

CONFIG_IDE=y

CONFIG_BLK_DEV_IDE=y

146

CONFIG_BLK_DEV_IDEDISK=yCONFIG_IDEDISK_STROKE=yCONFIG_BLK_DEV_IDECD=yCONFIG_BLK_DEV_IDETAPE=mCONFIG_BLK_DEV_IDEFLOPPY=mCONFIG_BLK_DEV_IDESCSI=mCONFIG_BLK_DEV_CMD640=yCONFIG_BLK_DEV_CMD640_ENHANCED=yCONFIG_BLK_DEV_IDEPCI=yCONFIG_IDEPCI_SHARE_IRQ=yCONFIG_BLK_DEV_IDEDMA_PCI=yCONFIG_IDEDMA_PCI_AUTO=yCONFIG_BLK_DEV_IDEDMA=yCONFIG_BLK_DEV_AEC62XX=yCONFIG_BLK_DEV_ALI15X3=yCONFIG_BLK_DEV_AMD74XX=yCONFIG_BLK_DEV_CMD64X=yCONFIG_BLK_DEV_CY82C693=yCONFIG_BLK_DEV_CS5530=yCONFIG_BLK_DEV_HPT34X=yCONFIG_BLK_DEV_HPT366=yCONFIG_BLK_DEV_PIIX=yCONFIG_BLK_DEV_NS87415=yCONFIG_BLK_DEV_OPTI621=yCONFIG_BLK_DEV_RZ1000=yCONFIG_BLK_DEV_SVWKS=yCONFIG_BLK_DEV_SIS5513=yCONFIG_BLK_DEV_SLC90E66=yCONFIG_BLK_DEV_TRM290=yCONFIG_BLK_DEV_VIA82CXXX=yCONFIG_IDEDMA_AUTO=yCONFIG_BLK_DEV_ATARAID=m

CONFIG_SCSI=yCONFIG_BLK_DEV_SD=yCONFIG_SD_EXTRA_DEVS=40CONFIG_CHR_DEV_ST=mCONFIG_CHR_DEV_OSST=mCONFIG_BLK_DEV_SR=yCONFIG_SR_EXTRA_DEVS=2CONFIG_CHR_DEV_SG=yCONFIG_SCSI_DEBUG_QUEUES=yCONFIG_SCSI_MULTI_LUN=y

CONFIG_SCSI_DPT_I2O=y

CONFIG_NETDEVICES=y

CONFIG_DUMMY=mCONFIG_BONDING=mCONFIG_EQUALIZER=yCONFIG_TUN=mCONFIG_ETHERTAP=y

CONFIG_NET_ETHERNET=yCONFIG_HAPPYMEAL=mCONFIG_SUNGEM=mCONFIG_NET_VENDOR_3COM=yCONFIG_VORTEX=mCONFIG_NET_VENDOR_SMC=y

147

CONFIG_NET_VENDOR_RACAL=yCONFIG_HP100=mCONFIG_NET_PCI=yCONFIG_PCNET32=mCONFIG_ADAPTEC_STARFIRE=mCONFIG_TULIP=mCONFIG_DE4X5=mCONFIG_DGRS=mCONFIG_DM9102=mCONFIG_EEPRO100=mCONFIG_E100=mCONFIG_FEALNX=mCONFIG_NATSEMI=mCONFIG_NE2K_PCI=mCONFIG_8139CP=mCONFIG_8139TOO=mCONFIG_8139TOO_8129=yCONFIG_SIS900=mCONFIG_EPIC100=mCONFIG_SUNDANCE=mCONFIG_TLAN=mCONFIG_VIA_RHINE=mCONFIG_WINBOND_840=mCONFIG_NET_POCKET=y

CONFIG_ACENIC=mCONFIG_DL2K=mCONFIG_E1000=yCONFIG_NS83820=mCONFIG_HAMACHI=mCONFIG_YELLOWFIN=mCONFIG_R8169=mCONFIG_SK98LIN=mCONFIG_TIGON3=m

CONFIG_INPUT=yCONFIG_INPUT_KEYBDEV=yCONFIG_INPUT_MOUSEDEV=yCONFIG_INPUT_MOUSEDEV_SCREEN_X=1024CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768

CONFIG_VT=yCONFIG_VT_CONSOLE=yCONFIG_SERIAL=mCONFIG_SERIAL_NONSTANDARD=yCONFIG_COMPUTONE=mCONFIG_ROCKETPORT=mCONFIG_CYCLADES=mCONFIG_CYZ_INTR=yCONFIG_DIGIEPCA=mCONFIG_MOXA_INTELLIO=mCONFIG_MOXA_SMARTIO=mCONFIG_ISI=mCONFIG_SYNCLINK=mCONFIG_SYNCLINKMP=mCONFIG_N_HDLC=mCONFIG_RISCOM8=mCONFIG_SPECIALIX=mCONFIG_SPECIALIX_RTSCTS=yCONFIG_SX=m

148

CONFIG_RIO=mCONFIG_UNIX98_PTYS=yCONFIG_UNIX98_PTY_COUNT=256CONFIG_PRINTER=m

CONFIG_MOUSE=yCONFIG_PSMOUSE=yCONFIG_82C710_MOUSE=m

CONFIG_RTC=y

CONFIG_AUTOFS_FS=mCONFIG_AUTOFS4_FS=mCONFIG_REISERFS_FS=yCONFIG_EXT3_FS=yCONFIG_JBD=yCONFIG_FAT_FS=mCONFIG_MSDOS_FS=mCONFIG_UMSDOS_FS=mCONFIG_VFAT_FS=mCONFIG_CRAMFS=mCONFIG_TMPFS=yCONFIG_RAMFS=yCONFIG_ISO9660_FS=yCONFIG_JOLIET=yCONFIG_ZISOFS=yCONFIG_PROC_FS=yCONFIG_DEVFS_FS=yCONFIG_DEVFS_MOUNT=yCONFIG_ROMFS_FS=mCONFIG_EXT2_FS=yCONFIG_SYSV_FS=m

CONFIG_ZISOFS_FS=y

CONFIG_PARTITION_ADVANCED=yCONFIG_MSDOS_PARTITION=yCONFIG_BSD_DISKLABEL=yCONFIG_MINIX_SUBPARTITION=yCONFIG_SOLARIS_X86_PARTITION=yCONFIG_UNIXWARE_DISKLABEL=yCONFIG_LDM_PARTITION=yCONFIG_SUN_PARTITION=yCONFIG_EFI_PARTITION=yCONFIG_NLS=y

CONFIG_NLS_DEFAULT="iso8859-1"CONFIG_NLS_CODEPAGE_437=mCONFIG_NLS_CODEPAGE_737=mCONFIG_NLS_CODEPAGE_775=mCONFIG_NLS_CODEPAGE_850=mCONFIG_NLS_CODEPAGE_852=mCONFIG_NLS_CODEPAGE_855=mCONFIG_NLS_CODEPAGE_857=mCONFIG_NLS_CODEPAGE_860=mCONFIG_NLS_CODEPAGE_861=mCONFIG_NLS_CODEPAGE_862=mCONFIG_NLS_CODEPAGE_863=mCONFIG_NLS_CODEPAGE_864=mCONFIG_NLS_CODEPAGE_865=m

149

CONFIG_NLS_CODEPAGE_866=mCONFIG_NLS_CODEPAGE_869=mCONFIG_NLS_CODEPAGE_936=mCONFIG_NLS_CODEPAGE_950=mCONFIG_NLS_CODEPAGE_932=mCONFIG_NLS_CODEPAGE_949=mCONFIG_NLS_CODEPAGE_874=mCONFIG_NLS_ISO8859_8=mCONFIG_NLS_CODEPAGE_1250=mCONFIG_NLS_CODEPAGE_1251=mCONFIG_NLS_ISO8859_1=mCONFIG_NLS_ISO8859_2=mCONFIG_NLS_ISO8859_3=mCONFIG_NLS_ISO8859_4=mCONFIG_NLS_ISO8859_5=mCONFIG_NLS_ISO8859_6=mCONFIG_NLS_ISO8859_7=mCONFIG_NLS_ISO8859_9=mCONFIG_NLS_ISO8859_13=mCONFIG_NLS_ISO8859_14=mCONFIG_NLS_ISO8859_15=mCONFIG_NLS_KOI8_R=mCONFIG_NLS_KOI8_U=mCONFIG_NLS_UTF8=m

CONFIG_VGA_CONSOLE=yCONFIG_VIDEO_SELECT=y

CONFIG_FB=yCONFIG_DUMMY_CONSOLE=yCONFIG_FB_VESA=yCONFIG_VIDEO_SELECT=yCONFIG_FBCON_CFB8=yCONFIG_FBCON_CFB16=yCONFIG_FBCON_CFB24=yCONFIG_FBCON_CFB32=yCONFIG_FONT_8x8=yCONFIG_FONT_8x16=y

CONFIG_LOG_BUF_SHIFT=0

CONFIG_ZLIB_INFLATE=yCONFIG_ZLIB_DEFLATE=m

A4 /etc/conf.d/net

iface_eth2="193.206.185.XXX broadcast 193.206.185.255 netmask255.255.255.0"iface_bond0="192.168.0.1 broadcast 192.168.0.255 netmask255.255.255.0"gateway="eth2/193.206.185.1"

A5. /root/.bash_profile

alias l='ls --color'

150

alias cd..='cd ..;l'alias la='l -a'alias ll='l -l'

A6. /root/.bashrc

alias l='ls --color'alias cd..='cd ..;l'alias la='l -a'alias ll='l -l'

A7. /etc/drbd.conf

resource drbd0 { #BINDprotocol=C fsckcmd=fsck -p -ynet {

sync-max=100Mtl-size=10000timeout=60connect-int=10ping-int=10}

on freedom { #HA1device=/dev/nbd/0disk=/dev/sda10address=192.168.0.1 port=7788}

on independence { #HA2device=/dev/nbd/0disk=/dev/sda10address=192.168.0.2 port=7788}

}

resource drbd1 { #SENDMAILprotocol=C fsckcmd=fsck -p -ynet {

sync-max=100Mtl-size=10000timeout=60connect-int=10ping-int=10}

on freedom { #HA1device=/dev/nbd/1disk=/dev/sda11address=192.168.0.1

151

port=7789}

on independence { #HA2device=/dev/nbd/1disk=/dev/sda11address=192.168.0.2 port=7789}

}

A8. /etc/ha.d/haresources

freedom 193.206.185.XXX datadisk::drbd0 apache2 #qui vanno gli script di avvio dei servizi da avviare in HA

su freedom

independence 193.206.185.XXX datadisk::drbd1 #qui vanno gli script di avvio dei servizi da avviare in HA

su independence

A9. /etc/ha.d/ha.cf

debugfile /var/log/ha-debuglogfile /var/log/ha-loglogfacility local0keepalive 2 #intervallo di heartbeatdeadtime 5 #tempo minimo per essere considerato downinitdead 120 #tempo necessario al bootauto_failback on #Il Resource Group torna automaticamente al

ritorno del nodo se l'opzione è on serial /dev/ttyS0 #device seriale baud 19200 #velocità serialeudpport 694 #porta usata per le comunicazioni in bcast

(bond0)bcast bond0 #interfaccia di comunicazione internanode freedom #nome nodo come specificato in uname -nnode independence

apiauth ipfail uid=haclusterrespawn hacluster /usr/lib/heartbeat/ipfail #comando da

monitorare e rieseguire verifica la connessione esterna

respawn root /usr/bin/swatch -t /var/log/ha-log -t /var/log/messages

respawn root /usr/sbin/monping 193.206.185.1 #indirizzo da interrogare per

verificare il #funzionamento della rete esterna

A10. /etc/mon.d/mon.cf

alertdir = /usr/lib/mon/alert.dmondir = /usr/lib/mon/mon.d

152

logdir = /var/log/mon.dstatedir = /var/lib/mon.dauthfile = /etc/mon/auth.cfmaxprocs = 20histlength = 100randstart = 60s

## define groups of hosts to monitor#hostgroup test_apache2 193.206.185.XXX

watch test_apache2service apache2

interval 5smonitor http.monitorperiod wd {Mon-Sun} hr {0-23}

alertafter 2alert mail.alert root@localhostalert apache2-restart.alert

service apache2-takeoverinterval 5smonitor http.monitorperiod wd {Mon-Sun} hr {0-23}

alertafter 3 30mnumalerts 1alert mail.alert -S "Apache2 non riparte, provvedo a fermare heartbeat per causare il takeover" root@localhostalert haStop.alert

A11. /etc/mon.d/auth.cfcommand sectionlist: allreset: rootloadstate: rootsavestate: rootversion: allreload auth: rootservertime: alllist failures: alllist successes: alllist state: allmonitor: all

A12. /root/.swatchrc

watchfor /dead/echo bold undersore blinkbell write rootcontinue

watchfor /shutdown/echo bold undersore blinkbell

153

write rootcontinue

watchfor /Gratuitous Arp/echo blinkbell write rootcontinue

watchfor /takeover/echo undersorebell write rootcontinue

watchfor /transition/echo bold undersore blinkbell write rootcontinue

watchfor /down/echo bold undersore blinkbell write rootcontinue

A13. Script mon http.alert#!/bin/sh/etc/init.d/apache2 restart

A14. Script mon stopha.alert#!/bin/sh/etc/init.d/heartbeat stopha.alert

154

The GNU General Public License(GPL)

Version 2, June 1991Copyright (C) 1989, 1991 Free Software Foundation, Inc.59 Temple Place, Suite 330, Boston, MA 02111-1307 USAEveryone is permitted to copy and distribute verbatim copiesof this license document, but changing it is not allowed.PreambleThe licenses for most software are designed to take awayyour freedom to share and change it. By contrast, the GNUGeneral Public License is intended to guarantee your freedomto share and change free software--to make sure the softwareis free for all its users. This General Public Licenseapplies to most of the Free Software Foundation's softwareand to any other program whose authors commit to using it.(Some other Free Software Foundation software is covered bythe GNU Library General Public License instead.) You canapply it to your programs, too.When we speak of free software, we are referring to freedom,not price. Our General Public Licenses are designed to makesure that you have the freedom to distribute copies of freesoftware (and charge for this service if you wish), that youreceive source code or can get it if you want it, that youcan change the software or use pieces of it in new freeprograms; and that you know you can do these things.To protect your rights, we need to make restrictions thatforbid anyone to deny you these rights or to ask you tosurrender the rights. These restrictions translate tocertain responsibilities for you if you distribute copies ofthe software, or if you modify it.For example, if you distribute copies of such a program,whether gratis or for a fee, you must give the recipientsall the rights that you have. You must make sure that they,too, receive or can get the source code. And you must showthem these terms so they know their rights.We protect your rights with two steps: (1) copyright thesoftware, and (2) offer you this license which gives youlegal permission to copy, distribute and/or modify thesoftware.Also, for each author's protection and ours, we want to makecertain that everyone understands that there is no warrantyfor this free software. If the software is modified bysomeone else and passed on, we want its recipients to knowthat what they have is not the original, so that anyproblems introduced by others will not reflect on theoriginal authors' reputations.

155

Finally, any free program is threatened constantly bysoftware patents. We wish to avoid the danger thatredistributors of a free program will individually obtainpatent licenses, in effect making the program proprietary.To prevent this, we have made it clear that any patent mustbe licensed for everyone's free use or not licensed at all.The precise terms and conditions for copying, distributionand modification follow.TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION ANDMODIFICATION0. This License applies to any program or other work whichcontains a notice placed by the copyright holder saying itmay be distributed under the terms of this General PublicLicense. The "Program", below, refers to any such program orwork, and a "work based on the Program" means either theProgram or any derivative work under copyright law: that isto say, a work containing the Program or a portion of it,either verbatim or with modifications and/or translated intoanother language. (Hereinafter, translation is includedwithout limitation in the term "modification".) Eachlicensee is addressed as "you".Activities other than copying, distribution and modificationare not covered by this License; they are outside its scope.The act of running the Program is not restricted, and theoutput from the Program is covered only if its contentsconstitute a work based on the Program (independent ofhaving been made by running the Program). Whether that istrue depends on what the Program does.1. You may copy and distribute verbatim copies of theProgram's source code as you receive it, in any medium,provided that you conspicuously and appropriately publish oneach copy an appropriate copyright notice and disclaimer ofwarranty; keep intact all the notices that refer to thisLicense and to the absence of any warranty; and give anyother recipients of the Program a copy of this License alongwith the Program.You may charge a fee for the physical act of transferring acopy, and you may at your option offer warranty protectionin exchange for a fee.2. You may modify your copy or copies of the Program or anyportion of it, thus forming a work based on the Program, andcopy and distribute such modifications or work under theterms of Section 1 above, provided that you also meet all ofthese conditions:

a) You must cause the modified files to carryprominent notices stating that you changed the filesand the date of any change.b) You must cause any work that you distribute orpublish, that in whole or in part contains or isderived from the Program or any part thereof, to be

156

licensed as a whole at no charge to all third partiesunder the terms of this License.c) If the modified program normally reads commandsinteractively when run, you must cause it, whenstarted running for such interactive use in the mostordinary way, to print or display an announcementincluding an appropriate copyright notice and a noticethat there is no warranty (or else, saying that youprovide a warranty) and that users may redistributethe program under these conditions, and telling theuser how to view a copy of this License. (Exception:if the Program itself is interactive but does notnormally print such an announcement, your work basedon the Program is not required to print anannouncement.)

These requirements apply to the modified work as a whole. Ifidentifiable sections of that work are not derived from theProgram, and can be reasonably considered independent andseparate works in themselves, then this License, and itsterms, do not apply to those sections when you distributethem as separate works. But when you distribute the samesections as part of a whole which is a work based on theProgram, the distribution of the whole must be on the termsof this License, whose permissions for other licenseesextend to the entire whole, and thus to each and every partregardless of who wrote it.Thus, it is not the intent of this section to claim rightsor contest your rights to work written entirely by you;rather, the intent is to exercise the right to control thedistribution of derivative or collective works based on theProgram.In addition, mere aggregation of another work not based onthe Program with the Program (or with a work based on theProgram) on a volume of a storage or distribution mediumdoes not bring the other work under the scope of thisLicense.3. You may copy and distribute the Program (or a work basedon it, under Section 2) in object code or executable formunder the terms of Sections 1 and 2 above provided that youalso do one of the following:

a) Accompany it with the complete correspondingmachine-readable source code, which must bedistributed under the terms of Sections 1 and 2 aboveon a medium customarily used for software interchange;or,b) Accompany it with a written offer, valid for atleast three years, to give any third party, for acharge no more than your cost of physically performingsource distribution, a complete machine-readable copyof the corresponding source code, to be distributedunder the terms of Sections 1 and 2 above on a mediumcustomarily used for software interchange; or,

157

c) Accompany it with the information you received asto the offer to distribute corresponding source code.(This alternative is allowed only for noncommercialdistribution and only if you received the program inobject code or executable form with such an offer, inaccord with Subsection b above.)

The source code for a work means the preferred form of thework for making modifications to it. For an executable work,complete source code means all the source code for allmodules it contains, plus any associated interfacedefinition files, plus the scripts used to controlcompilation and installation of the executable. However, asa special exception, the source code distributed need notinclude anything that is normally distributed (in eithersource or binary form) with the major components (compiler,kernel, and so on) of the operating system on which theexecutable runs, unless that component itself accompaniesthe executable.If distribution of executable or object code is made byoffering access to copy from a designated place, thenoffering equivalent access to copy the source code from thesame place counts as distribution of the source code, eventhough third parties are not compelled to copy the sourcealong with the object code.4. You may not copy, modify, sublicense, or distribute theProgram except as expressly provided under this License. Anyattempt otherwise to copy, modify, sublicense or distributethe Program is void, and will automatically terminate yourrights under this License. However, parties who havereceived copies, or rights, from you under this License willnot have their licenses terminated so long as such partiesremain in full compliance.5. You are not required to accept this License, since youhave not signed it. However, nothing else grants youpermission to modify or distribute the Program or itsderivative works. These actions are prohibited by law if youdo not accept this License. Therefore, by modifying ordistributing the Program (or any work based on the Program),you indicate your acceptance of this License to do so, andall its terms and conditions for copying, distributing ormodifying the Program or works based on it.6. Each time you redistribute the Program (or any work basedon the Program), the recipient automatically receives alicense from the original licensor to copy, distribute ormodify the Program subject to these terms and conditions.You may not impose any further restrictions on therecipients' exercise of the rights granted herein. You arenot responsible for enforcing compliance by third parties tothis License.7. If, as a consequence of a court judgment or allegation ofpatent infringement or for any other reason (not limited topatent issues), conditions are imposed on you (whether bycourt order, agreement or otherwise) that contradict theconditions of this License, they do not excuse you from the

158

conditions of this License. If you cannot distribute so asto satisfy simultaneously your obligations under thisLicense and any other pertinent obligations, then as aconsequence you may not distribute the Program at all. Forexample, if a patent license would not permit royalty-freeredistribution of the Program by all those who receivecopies directly or indirectly through you, then the only wayyou could satisfy both it and this License would be torefrain entirely from distribution of the Program.If any portion of this section is held invalid orunenforceable under any particular circumstance, the balanceof the section is intended to apply and the section as awhole is intended to apply in other circumstances.It is not the purpose of this section to induce you toinfringe any patents or other property right claims or tocontest validity of any such claims; this section has thesole purpose of protecting the integrity of the freesoftware distribution system, which is implemented by publiclicense practices. Many people have made generouscontributions to the wide range of software distributedthrough that system in reliance on consistent application ofthat system; it is up to the author/donor to decide if he orshe is willing to distribute software through any othersystem and a licensee cannot impose that choice.This section is intended to make thoroughly clear what isbelieved to be a consequence of the rest of this License.8. If the distribution and/or use of the Program isrestricted in certain countries either by patents or bycopyrighted interfaces, the original copyright holder whoplaces the Program under this License may add an explicitgeographical distribution limitation excluding thosecountries, so that distribution is permitted only in oramong countries not thus excluded. In such case, thisLicense incorporates the limitation as if written in thebody of this License.9. The Free Software Foundation may publish revised and/ornew versions of the General Public License from time totime. Such new versions will be similar in spirit to thepresent version, but may differ in detail to address newproblems or concerns.Each version is given a distinguishing version number. Ifthe Program specifies a version number of this License whichapplies to it and "any later version", you have the optionof following the terms and conditions either of that versionor of any later version published by the Free SoftwareFoundation. If the Program does not specify a version numberof this License, you may choose any version ever publishedby the Free Software Foundation.10. If you wish to incorporate parts of the Program intoother free programs whose distribution conditions aredifferent, write to the author to ask for permission. Forsoftware which is copyrighted by the Free SoftwareFoundation, write to the Free Software Foundation; we

159

sometimes make exceptions for this. Our decision will beguided by the two goals of preserving the free status of allderivatives of our free software and of promoting thesharing and reuse of software generally.NO WARRANTY11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE ISNO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BYAPPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THECOPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM"AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCEOF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVEDEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,REPAIR OR CORRECTION.12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREEDTO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTYWHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTEDABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OFTHE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOTLIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE ORLOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THEPROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCHHOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OFSUCH DAMAGES.END OF TERMS AND CONDITIONSHow to Apply These Terms to Your New ProgramsIf you develop a new program, and you want it to be of thegreatest possible use to the public, the best way to achievethis is to make it free software which everyone canredistribute and change under these terms.To do so, attach the following notices to the program. It issafest to attach them to the start of each source file tomost effectively convey the exclusion of warranty; and eachfile should have at least the "copyright" line and a pointerto where the full notice is found.

one line to give the program's name and a brief ideaof what it does.Copyright (C) This program is free software; you can redistribute itand/or modify it under the terms of the GNU GeneralPublic License as published by the Free SoftwareFoundation; either version 2 of the License, or (atyour option) any later version.This program is distributed in the hope that it willbe useful, but WITHOUT ANY WARRANTY; without even theimplied warranty of MERCHANTABILITY or FITNESS FOR A

160

PARTICULAR PURPOSE. See the GNU General Public Licensefor more details.You should have received a copy of the GNU GeneralPublic License along with this program; if not, writeto the Free Software Foundation, Inc., 59 TemplePlace, Suite 330, Boston, MA 02111-1307 USA

Also add information on how to contact you by electronic andpaper mail.If the program is interactive, make it output a short noticelike this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) year name ofauthor Gnomovision comes with ABSOLUTELY NO WARRANTY;for details type `show w'. This is free software, andyou are welcome to redistribute it under certainconditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should showthe appropriate parts of the General Public License. Ofcourse, the commands you use may be called something otherthan `show w' and `show c'; they could even be mouse-clicksor menu items--whatever suits your program.You should also get your employer (if you work as aprogrammer) or your school, if any, to sign a "copyrightdisclaimer" for the program, if necessary. Here is a sample;alter the names:

Yoyodyne, Inc., hereby disclaims all copyrightinterest in the program `Gnomovision' (which makes passes atcompilers)written by James Hacker.signature of Ty Coon, 1 April 1989Ty Coon, President of Vice

This General Public License does not permit incorporatingyour program into proprietary programs. If your program is asubroutine library, you may consider it more useful topermit linking proprietary applications with the library. Ifthis is what you want to do, use the GNU Library GeneralPublic License instead of this License.

161

162

BIBLIOGRAFIA

1. Pradeep K. Sinha, Distributed Operating Systems: concept and design,

IEEE Press New York, NY, 1997

2. Dal sito http://linux.cineca.it/linuxlab4.html

Dispense Cineca: Laboratorio cluster Linux, setup per l'erogazione di

servizi

3. Dal sito http://www.faqs.org/docs/linux_network/

Olaf Kirk, NAG, The Linux Network Administrator Guide

4. Dal sito http://www.drbd.org/documentation.html

Philipp Reisner et al., Documentazione completa sul “DRBD”

5. Alan Robertson, Heartbeat programming tutorial, Ottawa Linux

Symposium, 2003 (www.linux-ha.org/heartbeat)

6. Richard Petersen, Linux: guida completa, McGawHill Milano, 1996.

7. Dal sito http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-

2.4/Documentation/networking/bonding.txt:

Thomas Davis, Linux Ethernet Bonding Driver mini-howto

8. Dal sito http://www.gentoo.it/handbook/handbook.html

Daniel Robbins et al., manuale del sistema operativo Gentoo/Linux

163