TESI - DRBD

UNIVERSITA' DEGLI STUDI DI BARI
FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
CORSO DI LAUREA IN INFORMATICA
TESI DI LAUREA IN
SISTEMI PER L'ELABORAZIONE DELL'INFORMAZIONE:
SISTEMI DISTRIBUITI
UN CLUSTER IN ALTA
DISPONIBILITÀ IN AMBIENTE LINUX
RELATORI:
Chiar.mo Prof. S. PIZZUTILO
dott. D. DIACONO
LAUREANDO:
Sabino CALÒ
ANNO ACCADEMICO 2003/2004
INDICE GENERALE
INTRODUZIONE................................................................................4
CLUSTER: GENERALITA'..................................................................7
1.1 Architettura.................................................................................................. 8
1.2 High Performance Computer e High Availability.................................10
1.3 Il software libero....................................................................................... 12
1.4 Progetti Open-Source per cluster di calcolo.......................................... 13
1.5 Progetti Open-Source di cluster HA...................................................... 13
LINUX: INSTALLAZIONE KERNEL.............................................. 21
2.1 L'Hardware................................................................................................ 21
2.2 L'installazione del sistema operativo....................................................... 23
L'ALTA DISPONIBILITA' (HA)........................................................43
3.1 Livelli di disponibilità...............................................................................
3.2 Requisito dei cinque 9..............................................................................
3.3 Le prestazioni............................................................................................
3.4 Tipologie di cluster...................................................................................
44
46
48
49
IL CLUSTER REALIZZATO IN QUESTA INSTALLAZIONE......52
4.1 Elementi fondamentali: una visione panoramica.................................. 53
4.2 Schema di progetto................................................................................... 55
4.3 Heartbeat .................................................................................................. 60
L'INSTALLAZIONE E CONFIGURAZIONE DEL FILE-SYSTEM:
DRBD...................................................................................................64
5.1 Tipologie di storage.................................................................................. 64
5.2 Il file-system utilizzato nel setup: motivi della scelta............................ 67
5.3 DRBD: caratteristiche e peculiarità........................................................ 70
5.4 Performance.............................................................................................. 83
5.5 Installazione e configurazione DRBD................................................. 101
5.6 Alta disponibilità della rete interna ...................................................... 104
2
HEARTBEAT: SUITE PER L'ALTA DISPONIBILITA'................ 108
6.1 La struttura modulare di Heartbeat...................................................... 108
6.2 Il Resource Group.................................................................................. 114
6.3 Installazione e configurazione............................................................... 115
6.4 Gratuitous ARP...................................................................................... 122
STRUMENTI DI MONITORAGGIO E TEST DEL SISTEMA..... 124
7.1 Mon..........................................................................................................
7.2 Webmin...................................................................................................
7.3 Swatch......................................................................................................
7.4 Test del sistema.......................................................................................
124
128
130
132
APPENDICE......................................................................................140
File di configurazione..........................................................................141
A1. /etc/fstab............................................................................................... 141
A2. /etc/make.conf...................................................................................... 141
A3. /etc/lilo.conf.......................................................................................... 144
A4. /usr/src/linux/.config.......................................................................... 144
A4 /etc/conf.d/net...................................................................................... 150
A5. /root/.bash_profile............................................................................... 150
A6. /root/.bashrc......................................................................................... 151
A7. /etc/drbd.conf....................................................................................... 151
A8. /etc/ha.d/haresources.......................................................................... 152
A9. /etc/ha.d/ha.cf...................................................................................... 152
A10. /etc/mon.d/mon.cf............................................................................ 152
A11. /etc/mon.d/auth.cf............................................................................. 153
A12. /root/.swatchrc................................................................................... 153
A13. Script mon http.alert........................................................................... 154
A14. Script mon stopha.alert....................................................................... 154
BIBLIOGRAFIA.................................................................................163
3
INTRODUZIONE
Il lavoro di tesi è stato svolto all'interno di una collaborazione fra il
Dipartimento di Informatica dell'Università degli Studi di Bari e l'Istituto
Nazionale di Fisica Nucleare (INFN) sez. di Bari. Il lavoro di tesi ha avuto
come scopo la ricerca lo studio di soluzioni open-source e quindi la
realizzazione di un sistema distribuito (cluster) per l'erogazione di servizi di
rete in Alta Disponibilità (HA).
Il sistema distribuito è stato costruito su due macchine identiche con
tecnologia non dedicata basate su CPU x86 di tipo Intel Pentium4 Xeon (cfr.
cap. 2), fornite dall'INFN, per la propria rete dipartimentale.
Entrambi i nodi del cluster hanno un sistema operativo Gentoo Linux e sono
interconnessi al fine di fornire l'erogazione dei servizi in alta disponibilità in
maniera distribuita.
Il sistema di memorizzazione di massa è basato su un progetto open-source di
recente introduzione, denominato DRBD (cfr. cap. 5), che consente di
disporre di dispositivi condivisi astraendo i reali dispositivi hardware costituiti
da generici dischi EIDE installati all'interno di ciascuno dei nodi del cluster.
Il centro del sistema è costituito dalla suite Heartbeat (cfr. cap. 6), che ha il
compito di gestire le risorse del cluster e di reagire ad eventuali
malfunzionamenti, per evitare di interrompere l'erogazione dei servizi.
4
Nel capitolo 1, sono presentate le basi teoriche sui sistemi distribuiti, i diversi
modelli teorici e le diverse tipologie di cluster, ponendo particolare attenzione
alla distinzione fra cluster di calcolo a bilanciamento di carico e cluster per
l'erogazione di servizi in alta disponibilità.
Il capitolo 2, prende in considerazione il sistema distribuito dal punto di vista
del singolo nodo. Dopo la descrizione dell'hardware, viene descritta
l'installazione del sistema operativo, la configurazione del kernel e la
configurazione delle partizioni del disco rigido nonché l'installazione dei
programmi di utilità di sistema fra cui una utility di replicazione della riga di
comando ai diversi nodi.
Il capitolo 3, analizza i concetti teorici inerenti l'alta disponibilità: i livelli di
disponibilità, i requisiti di un sistema distribuito in alta disponibilità e le
tipologie di cluster per l'HA.
Nel capitolo 4 è descritto schematicamente il cluster costruito in questo
lavoro di tesi, le tipologie di collegamento fra i due nodi, in particolare
l'installazione e configurazione del meccanismo di channel bonding necessario a
ridondare il collegamento di rete inerno al cluster. Vengono inoltre presentati
i primi concetti relativi ad Heartbeat e le soluzioni a problemi particolari, nello
specifico il problema del “Brain-Splitting”.
Il capitolo 5 è dedicato alla descrizione del modulo DRBD ed alla sua
installazione e configurazione. DRBD fornisce al sistema operativo un
dispositivo di memorizzazione condiviso e astratto costituito da partizioni
reali residenti su entrambi i nodi del cluster. In tale capitolo si descrivono i
requisiti software che DRBD fornisce e l'algoritmo alla base del sistema.
Viene inoltre presentata l'analisi dei test sulle performance che sono stati
eseguiti sui dispositivi DRBD nelle diverse configurazioni.
Nel capitolo 6 viene analizzata nei minimi dettagli la suite Heartbeat, la sua
struttura modulare e i meccanismi di funzionamento che rendono necessarie
5
alcune attenzioni sulla scelta di alcuni dispositivi hardware, in particolare lo
switch a cui sono collegati i nodi, affinchè supporti i pacchetti di “gratuitousARP”. Il capitolo si conclude con la procedura di installazione e
configurazione della suite.
Il capitolo 7 riguarda invece gli strumenti di monitoraggio necessari a
controllare costantemente il funzionamento del sistema. Vengono installati e
configurati i software “mon”, “swatch” e “Webmin”. Alla fine del capitolo
viene descritto un test per verificare le funzionalità del sistema. Tale
descrizione è completata con alcuni screenshot che mostrano il
comportamento del sistema durante il test eseguito.
Chiude il lavoro di tesi un'appendice contenente alcuni file testuali di
configurazione di diversi software: Sistema operativo, DRBD, Heartbeat,
mon e swatch.
6
Capitolo 1
CLUSTER: GENERALITA'
L'informatica è una scienza relativamente moderna nata contestualmente
all'invenzione delle macchine in grado di eseguire calcoli in maniera
automatica e rapidissima che sono state definite computer o calcolatori. Lo
scopo dell'informatica è quello di rendere possibile la descrizione di un
problema reale sotto forma di un procedimento fatto di passaggi elementari o
“atomi” di ragionamento che prende il nome di algoritmo. Inizialmente i
computer risolvevano problemi abbastanza semplici ma grazie alla ricerca
nella scienza informatica, attualmente i computer risolvono problemi molto
complessi e in alcuni casi sono in grado di prendere semplici decisioni, in
relazione agli stimoli del mondo esterno, avvicinandosi così poco alla volta
all'estrema complessità del ragionamento umano.
Il progresso tecnologico nel campo dell'elettronica, sinergicamente generato
dalla ricerca informatica, ha reso disponibili macchine di calcolo sempre più
veloci e versatili tali da poter essere aggregate a costituire quasi una
emulazione della rete neuronale del cervello umano. L'aggregazione di più
computer, al fine di risolvere uno stesso problema comune, raggiungendo
quindi lo stesso scopo, prende il nome di sistema distribuito o “cluster”.
Il paradigma alla base di una sistema distribuito è assimilabile a “divide et
impera”. Secondo questo paradigma di ragionamento ogni problema può
essere risolto scomponendolo in tanti sottoproblemi più piccoli, la soluzione
di ognuno dei quali genera la soluzione del problema primario. L'applicazione
di questo schema di ragionamento incorpora il concetto di modularità che
7
caratterizza tutti i moderni sistemi di calcolo, in modo più evidente i sistemi
distribuiti.
Un sistema distribuito infatti è un sistema modulare perchè è composto da un
insieme più o meno grande di calcolatori identici che si definiscono “nodi”. In
un sistema distribuito si ha la possibilità di aggiungere o eliminare nodi dal
sistema generando rispettivamente un aumento o una diminuzione nella
capacità di calcolo dell'intero sistema. Questa caratteristica prende il nome di
scalabilità. Si definisce che un sistema è molto scalabile quando l'aumento
delle prestazioni di calcolo cresce più che proporzionalmente rispetto al
numero dei nodi.
Secondo la definizione principale un cluster è un sistema distribuito
composto da un numero non specificato di singoli computer definiti
“processori” o più semplicemente “nodi”, interconnessi fra loro da una rete
di comunicazione privata usata esclusivamente per la sincronizzazione e lo
scambio di messaggi fra i processi che girano sul cluster e si condividono le
risorse che possono essere locali o remote [1].
1.1 Architettura
Un sistema distribuito può distinguersi principalmente in due categorie
relative essenzialmente al modo in cui sono disposte e gestite le risorse di
sistema. Possiamo infatti distinguere sistemi cosiddetti “Tightly coupled” la
cui caratteristica distintiva sta nel fatto che ogni nodo del cluster condivide la
stessa memoria che utilizza anche per gli scopi di comunicazione fra i processi
in esecuzione; al contrario, i sistemi definiti “Loosely coupled” si
differenziano dai precedenti per il fatto che ogni nodo utilizza e gestisce la
propria memoria mentre i processi in esecuzione sui vari nodi comunicano
attraverso i messaggi utilizzando le tecniche cosiddette di “Message Passing”.
I sistemi del tipo “loosely coupled” corrispondono più propriamente alla
definizione di sistema distribuito.
8
I modelli in base ai quali è possibile costruire un sistema distribuito variano in
base alla specializzazione dei diversi nodi all'interno del cluster.
Il
modello
definito
“minicomputer”
caratterizza
sistemi
distribuiti
essenzialmente “Tightly coupled” che condividono le stesse risorse
centralizzate. Questo tipo di sistema in effetti è concettualmente simile ad un
computer singolo anche se scalabile e modulare.
Secondo il modello “workstation model” un sistema distribuito è di tipo
“loosely coupled” in quanto formato da un insieme di workstation complete
che gestiscono autonomamente le proprie risorse. I processi vengono
opportunamente trasferiti ed eseguiti sulle workstation libere gestendo
comunque la priorità dei processi locali e remoti.
Il modello “workstation-server model” si applica a sistemi distribuiti formati
da un insieme di workstation connesse inoltre a minicomputer specializzati in
particolari servizi. Tipicamente un utente di un tale sistema svolge in locale le
operazioni generiche, in remoto le operazioni specializzate per cui esiste un
minicomputer dedicato. Questo modello fornisce alcuni vantaggi che nelle
diverse situazioni applicative possono essere di grande importanza se non a
volte richieste come scelta progettuale: è possibile ad esempio centralizzare le
risorse di memorizzazione di massa costituendo appositamente un
minicomputer come file-server, in modo da fornire prestazioni eccellenti
nell'input-output dei dati, si centralizzerebbe così anche il lavoro di
manutenzione e infine non si rende necessaria la migrazione dei processi dato
che le elaborazioni remote vengono eseguite attraverso il protocollo clientserver.
Il modello “processor pool model” caratterizza sistemi distribuiti formati da
nodi generici non specializzati che vengono dinamicamente allocati dal
sistema di gestione delle risorse e forniscono all'esterno l'immagine di sistema
singolo. L'utente che deve eseguire i suoi processi si collega al cluster
attraverso terminali remoti che non fanno parte del cluster e dunque non si
9
connette ad un nodo in particolare come nei modelli “workstation” e
“workstation server”, ma concettualmente all'intero sistema. Questo modello
è il più diffuso fra gli attuali cluster adibiti al calcolo massivo.
Il sistema operativo di un sistema distribuito deve essere tale da consentire e
favorire le operazioni tipiche di un cluster. Si possono innanzitutto
distinguere due classi di sistemi operativi per cluster denominati “Network
operating system” e “Distributed Operating System”. Le differenze fra le due
tipologie risiedono principalmente nell'immagine del sistema che forniscono
all'utente. Un “Network Operating system” infatti coordinando i diversi
sistemi operativi presenti su ogni nodo e adibiti alla gestione delle risorse
locali, dà all'utente la possibilità di conoscere quali sono i nodi del cluster il
loro stato e gli consente inoltre di scegliere su quali nodi eseguire la sua
computazione. D'altro canto un “Distributed Operating System” fornisce
all'utente l'immagine di sistema singolo prendendosi in carico la gestione del
carico di lavoro da assegnare ai diversi nodi del cluster. E' evidente che i
malfunzionamenti di ciascun nodo sono nascosti all'utente in quanto egli
stesso non è a conoscenza del modo in cui il sistema è costruito. Un sistema
operativo distribuito è ovviamente complesso in quanto deve consentire
performance e quindi scalabilità, affidabilità attraverso la gestione della
ridondanza dei componenti più sensibili ed infine sicurezza dato che un
sistema distribuito solitamente è usato da diversi utenti per ognuno dei quali si
deve garantire riservatezza e permessi.
1.2 High Performance Computer e High Availability
E’ doverosa ora un'altra distinzione fondamentale in merito alle tipologie di
cluster che è possibile realizzare. Tale distinzione è legata essenzialmente
all’utilizzo a cui il cluster è dedicato.
Un cluster può essere un HPC (High Performance Computer), dedicato
solitamente al calcolo massivo, tipico delle simulazioni scientifiche in cui sono
in gioco diverse variabili. Questi sistemi sono assimilabili al modello
10
“processor pool” e sono quindi di tipo “loosely coupled” in quanto ogni
nodo gestisce le proprie risorse. Forniscono all'utente l'immagine di sistema
singolo e generalmente sono formati da almeno 32 nodi.
L’altro tipo di cluster è definito “sistema ad alta disponibilità” (HA: High
Availability) che ha come obbiettivo primario quello di garantire con ogni
sforzo il requisito dell'affidabilità che generalmente caratterizza ogni sistema
distribuito.
I cluster per l'alta disonibilità hanno lo scopo di fornire servizi. Si adotta la
soluzione cluster per far in modo che i servizi vengano erogati limitando al
minimo le interruzioni e questo è possibile in quanto la struttura e gestione
del cluster fa’ sì che nel caso di blocco del nodo che fisicamente sta erogando
un servizio, un altro si faccia carico dell’intero gruppo di servizi forniti dal
nodo caduto. Lo scopo che ci si prefigge nel progetto di un cluster per l'alta
disponibilità è quello di eliminare i punti deboli del sistema definiti “single
point of failure”, attraverso la ridondanza degli stessi.
Generalmente un cluster HA è realizzato con soli due nodi, sia perché non è
sottoposto a carichi di lavoro computazionale elevati, tipici degli HPC, sia per
semplificare l’arbitraggio delle risorse condivise e limitare i fenomeni negativi
ad esso legati, primo fra tutti il “Brain-splitting”, analizzato più avanti.
E’ ovvio che anche in questo caso lo switching fra i processori è totalmente
trasparente all’utente il quale ancora una volta ha l’immagine di un singolo
sistema a cui richiedere servizi.
Ci sono due modelli possibili per realizzare un cluster di questo tipo e sono
definiti A-S (Active-Standby) e A-A (Active-Active).
Nel modello A-S, i servizi offerti dal cluster sono residenti tutti su un nodo;
vengono poi presi totalmente in carico dall’altro nodo precedentemente in
standby, nel momento in cui il nodo attivo cade.
11
Nel modello A-A i servizi sono distribuiti su entrambi i nodi che si
compensano a vicenda quando uno dei due cade.
I modi per realizzare questi obiettivi sono diversi e verranno presi in
considerazione quelli inerenti la piattaforma e l’ambiente operativo scelti per
la realizzazione del cluster HA oggetto di studio di questa tesi.
1.3 Il software libero
E' possibile realizzare un sistema in alta disponibilità attraverso l'utilizzo di
tecnologie proprietarie che integrano gli strumenti necessari per poter
installare e configurare un cluster HA. Tali soluzioni spesso molto costose,
sono caratterizzate dal fatto che il codice sorgente non è accessibile per cui
per ogni tipo di intervento inerente la manutenzione del sistema o la modifica
della configurazione, è necessario ricorrere alla casa costruttrice del pacchetto
software.
Visto il fiorire di progetti sempre più sofisticati e maturi nel panorama
dell'open-source, inerenti anche soluzioni riguardanti la realizzazione di
cluster, si è scelto per lo studio di questa tesi, di realizzare un sistema
distribuito per l'alta disponibilità, basato essenzialmente su software libero e
gratuito.
Il sistema operativo scelto per realizzare il cluster HA è GNU/Linux1. Questo
sistema UNIX-like è notoriamente orientato alle reti e ha come vantaggio non
trascurabile, oltre che la stabilità e l’efficienza tipica dei sistemi *NIX, il fatto
che è Open-Source e generalmente gratuito. E’ evidente come la caratteristica
Open-Source sia garanzia di trasparenza e stabilità, per il fatto che chiunque
può analizzare, modificare e correggere il codice sorgente.
1
Si noti la differenza tra le diciture Linux e GNU/Linux. La prima sta ad indicare il solo kernel del
sistema operativo sviluppato originariamente da Linus Torvalds, la seconda indica invece l'insieme del
kernel Linux e di svariati programmi open-source facenti capo al progetto GNU il cui padre è Richard
Stallman. Spesso questo insieme più o meno esteso può essere una “distribuzione Linux” creata da
chiunque ed eventualmente messa in vendita. A volte si dice “Linux” per riferirsi erroneamente ad una
intera distribuzione quando invece il termine “Linux” sta ad indicare il solo kernel.
12
Diversi progetti vengono attualmente sviluppati per la realizzazione di cluster
di cui segue un’analisi sommaria delle relative caratteristiche.
1.4 Progetti Open-Source per cluster di calcolo
La costruzione tipica di un cluster HPC basato su sistemi operativi Unix-like
risponde alla tipologia denominata “Beowulf” la quale fa uso di librerie
dedicate, principalmente PVM (Parallel Virtual Machine) e MPI (Message
Passing Interface) [2].
Il software applicativo che deve essere eseguito su questo tipo di cluster deve
essere ottimizzato per far uso esplicito delle librerie “Beowulf” affinchè il
sistema realizzi un parallelismo puro nell'esecuzione del software.
Esiste anche un progetto, denominato open-Mosix, che permette la
realizzazione di cluster HPC senza la necessità di codice scritto
opportunamente. Questo progetto che per altro fornisce anche utility di
gestione e monitoraggio complete di GUI, è basato sulle strategie di
migrazione dei processi che fanno in modo che il carico computazionale sia
equilibrato e distribuito sui diversi nodi del cluster. E’ evidente però che se il
sistema non è ben calibrato, la migrazione dei processi diventa proprio il collo
di bottiglia dell’intero sistema, soprattutto per la quantità di dati che devono
essere migrati con ogni processo.
1.5 Progetti Open-Source di cluster HA
Un sistema in alta disponibilità è caratterizzato tipicamente da diversi
componenti software intercomunicanti che sinergicamente permettono al
sistema di lavorare e fornire servizi in alta disponibilità. Tale insieme di
componenti
nelle
soluzioni
proprietarie
è
spesso
nascosto
e
l'utente/acquirente del sistema (che spesso comprende anche l'hardware), può
non avere nessuna conoscenza di tali componenti, né di come essi
interagiscono, né delle funzioni che essi svolgono. Questo modo di fare
13
ovviamente rende l'utente finale sempre in un certo senso dipendente
dall'azienda fornitrice del sistema che si garantisce così un introito economico
più o meno costante nei servizi post-vendita.
Questo lavoro oggetto della tesi ha previsto per sommi capi la costruzione di
un sistema cluster HA costituito da due nodi “Supermicro SuperServer
6023P-i”2, da inserire nella rete informatica della sezione di Bari dell'”Istituto
Nazionale di Fisica Nucleare” (INFN).
Tale sistema dovrà fornisce due servizi in alta disponibilità costituenti un
server di posta basato su “sendmail”3 e un server DNS (Domain Name
Service) basato su “bind”4.
La soluzione realizzata prevede l'utilizzo di soli componenti software di tipo
open-source che caratterizzati dalla licenza GPL5 sono generalmente gratuiti,
a sorgente aperto e disponibile, quindi modificabili, ridistribuibili anche dietro
pagamento nei termini previsti dalla licenza stessa. Risulta quindi evidente
come ogni soggetto che voglia implementare una soluzione di cluster in alta
disponibilità può sfruttare le proprie risorse interne per progettare il sistema in
ogni sua parte o eventualmente accedere alla comunità open-source per
acquisire le nozioni o le competenze necessarie per costruirsi il proprio
sistema personalizzato.
1.5.1
Il sistema operativo
Il componente del sistema più indispensabile è ovviamente il sistema
operativo. Per la scelta di questo componente sono state valutate diverse
alternative ognuna con le sue diverse peculiarità e lati negativi; comunque la
2
Per la descrizione completa dell'hardware si consulti il prossimo capitolo
3
Sendmail è un server di posta molto diffuso nei sistemi *NIX e caratterizzato dalla licenza GPL
4
bind è un server DNS open-source con licenza GPL diffuso su sistemi *NIX
5
General Public Licence: testo integrale in appendice
14
scelta ha escluso a priori sistemi proprietari e closed source primo fra tutti
Microsoft Windows. Le alternative prese in considerazione sono state quindi
di tipo open source e hanno visto coinvolti sistemi Linux, nelle sue diverse
distribuzioni, e le diverse varianti di BSD.
Si sono considerate le diverse caratteristiche positive riguardanti i sistemi BSD
prima fra tutte la sicurezza, che caratterizza in particolare il sistema
OpenBSD, ma sono state considerate anche situazioni negative, come il
supporto della comunità open-source, molto più limitato rispetto ad un
sistema Linux; inoltre da ricerche effettuate sulla rete si è riscontrato che ci
sono già state esperienze riguardanti sistemi HA basati su Linux da cui
eventualmente si potrebbe attingere o fare riferimento in caso di necessità
future. La scelta finale è dunque caduta su un sistema Linux.
Fra le diverse e numerosissime distribuzioni di Linux presenti nel panorama
della comunità open-source è stata scelta la distribuzione Gentoo6. Rispetto
alle altre, questa distribuzione ha la caratteristica di essere fornita in linea
preferenziale in formato sorgente, il che implica che l'utente deve eseguire la
compilazione dell'intero sistema prima di poterlo utilizzare7. Questa modalità
ha come effetto negativo il fatto che spesso la compilazione, specie se di tutto
il sistema, richiede molto tempo. Si intuisce però che è possibile ottenere un
sistema operativo personalizzato per le proprie esigenze, nel senso che è
possibile scegliere cosa compilare e installare. Un vantaggio ancora più grande
è che il sistema risultante è specificamente creato per la macchina su cui gira,
ed è quindi ottimizzato in termini di prestazioni e stabilità in quanto sfrutta
tutte le caratteristiche dell’ hardware.
Non si pensi però che Gentoo sia una distribuzione orientata specificamente
ad utenti avanzati in quanto l'installazione del software non è più complicata
che impartire da shell il comando emerge nome-pacchetto, dove nome-pacchetto è il
6
7
Gentoo: www.gentoo.org, www.gentoo.it
Sono comunque disponibili versioni precompilate di tutto o parte del sistema per le architetture più
diffuse.
15
9nome del software che si intende installare e presente nel portage8 di Gentoo.
A corredo di tutto, sono inoltre disponibili numerosissime guide in lingua
italiana presso www.gentoo.it. La descrizione di tale installazione per il
sistema oggetto di questa tesi è dettagliata nel capitolo 2.
1.5.2 Gestore del File-system condiviso
Altro elemento fondamentale di un sistema in HA è il file system. E' chiaro
che un comune file system per sistemi singoli non è assolutamente
appropriato in quanto per un cluster in HA il file system deve avere
funzionalità avanzate e particolari, comunque non necessarie e non applicabili
ai sistemi di elaborazione classici.
Tipicamente un file-system dedicato a cluster in alta disponibilità deve essere
tale da garantire funzionalità di “recovering” dei dati indispensabile nei casi in
cui una situazione di crash si verifica in concomitanza con gli accessi alle
memorie di massa. La politica di gestione di questa funzionalità è comunque
differente a seconda delle tipologie dell'hardware che si intende
acquistare/utilizzare. Il sistema di memorizzazione di massa infatti può essere
di due tipi: possiamo avere un sistema di dischi centrale, separato dai due nodi
ma al quale questi possono accedere contemporaneamente mediante canale
SCSI o fiber-channel, oppure un sistema di memorizzazione distribuito sui
vari nodi che utilizzi i dischi montati all’interno delle macchine coinvolte.
Quest'ultimo tipo di memorizzazione di massa è quello utilizzato per questo
cluster ed è basato sul software DRBD scritto da Philipp Reisner9.
L'aspetto positivo principale di un file-system distribuito consiste nel fatto che
i costi necessari per far sì che il file system non introduca nel sistema un single
point of failure sono molto piccoli. Infatti un crash in un sistema di dischi
8
Portage è il database on-line delle applicazioni installabili automaticamente col comando emerge. Tale
database comprende attualmente più di cinquemila pacchetti, per un totale di più di 9 Gb di dati,
numero in rapida crescita considerando anche il tempo relativamente breve da quando Gentoo si è
inserita nel panorama delle distribuzioni Linux
9
Philipp Reisner: [email protected]
16
centrale condiviso comprometterebbe l'intero sistema, e realizzare l’alta
disponibilità di un array di dischi, seppure possibile, è molto costoso.
L'aspetto negativo consiste in una riduzione delle prestazioni nell'input-output
dei dati. Nel caso in esame questo limite non incide in modo significativo
sulla bontà del sistema, in quanto non si dovrà gestire un flusso di dati molto
oneroso.
Tecnicamente DRBD è un modulo del kernel che mette a disposizione dei
nodi, tipicamente due, uno (o più) “block device” distribuito su entrambi i
nodi e quindi accessibile da entrambi. Ogni block device è formato da due
partizioni residenti rispettivamente su entrambi i nodi nelle quali i dati
vengono replicati. In tal modo anche se un nodo cade, l'altro ha comunque la
possibilità di accedere ai dati replicati sulla sua partizione e quindi continuare
a lavorare. Le politiche di replicazione dei dati sono gestite secondo tre
protocolli che bilanciano più o meno prestazioni e affidabilità. La scelta di tali
protocolli va fatta in base alle esigenze che si hanno e all'hardware che si
dispone.
Per quanto riguarda l'accesso ai dati consentito da DRBD, per garantire
costantemente l'integrità dei dati i nodi non possono effettuare
contemporaneamente operazioni di scrittura. Vengono perciò stabiliti dei
ruoli fra i due nodi: il nodo abilitato alla scrittura viene definito primario
mentre l'altro è detto secondario. Il nodo secondario non può comandare
operazioni di scrittura sui block device ma solo scrivere sulla sua partizione la
replica dei dati al comando del nodo primario. L'algoritmo del DRBD
gestisce tutte le situazioni in cui si verificano crash dei nodi primario o
secondario con opportuno cambio dei ruoli, al fine di garantire sempre
l'integrità dei dati e limitare al minimo l'intervento dell'amministratore,
favorendo per quanto possibile una fornitura pressoché continua dei servizi
offerti dal cluster.
17
Le funzioni assolte da DRBD in un sistema di cluster HA sono
principalmente quattro e cioè:
·
Garantisce che non ci sia nessuna perdita di dati in caso di caduta (crash)
di un nodo. Questo è, anzi dovrebbe essere, un elemento obbligatorio in
un sistema HA ma spesso viene trascurato per favorire un incremento in
prestazioni.
·
Rende possibile aggiungere un nodo al cluster, ad esempio per rimpiazzare
una macchina compromessa, senza interruzione dei servizi. Anche questo
è un elemento importante che garantisce l'alta disponibilità in quanto
l'obiettivo fondamentale è proprio quello di non interrompere la fornitura
dei vari servizi.
·
Può determinare quale nodo possiede i dati più aggiornati. Dato che
questo sistema è caratterizzato dalla replicazione dei dati sui diversi nodi, vi
è dunque il problema di determinare quale dei nodi possiede i dati più
aggiornati e quindi su quale di essi continuare a lavorare.
·
Con DRBD si può riavviare il cluster in modalità degradata10 senza
l'intervento dell'amministratore.
In alternativa a DRBD si potrebbe prevede l'uso di una soluzione ibrida
formata dall'insieme di NBD+Raid 111. In questa soluzione le funzioni di
esportazione dei dati vengono eseguite da NBD che rende disponibile un
block-device di rete fra i due nodi sul quale opera il Raid 1 software per
rendere disponibili i meccanismi di replicazione dei dati. Si è però preferito
l’uso di DRBD sia perché creato specificatamente per cluster HA a due nodi,
sia perché rende disponibili funzionalità di gestione e configurazione pensate
proprio per cluster HA. A tal proposito si veda il file “drbd.conf”, presente in
appendice, opportunamente creato per il sistema oggetto della tesi.
10
11
La modalità degradata è definita tale quando un cluster formato da due nodi continua a funzionare
con un nodo solo.
NBD: Network block device
18
1.5.3 Software di gestione del cluster
Al fine della realizzazione specifica del cluster HA, questo elemento è il
componente più importante del sistema in quanto è quello che rende l'insieme
di componenti finora descritto un cluster HA. Esso si occupa della gestione
delle risorse disponibili nel sistema e del controllo dei componenti finora
descritti.
Anche in questo caso le alternative disponibili sono state diverse e tutte le
soluzioni offrivano più o meno le stesse caratteristiche, ma la scelta è stata
operata tenendo in considerazione la piena compatibilità con DRBD, il
gestore del file-system.
I pacchetti considerati sempre ovviamente open-source sono stati Kimberlite,
LinuxFailSafe ed HeartBeat. E' stato scelto quest'ultimo, in quanto in grado di
operare in stretta combinazione con DRBD. HeartBeat si basa su un
meccanismo molto semplice ma allo stesso tempo molto efficace. Attraverso
il programma “heartbeat”, a brevi intervalli i nodi si scambiano messaggi di
stato continuamente, come un battito cardiaco che interrompendosi denota la
“morte” di uno dei nodi. Ovviamente HeartBeat è in grado di accorgersi di
questo evento e agire di conseguenza.
I nodi vengono connessi fra loro attraverso l'interfaccia ethernet per
scambiare i messaggi di stato e per esigenze legate al funzionamento in
cluster; le interfacce sono configurate con indirizzi IP privati destinati
esclusivamente alla comunicazione interna12. I messaggi possono però essere
inviati anche attraverso un'altra interfaccia ethernet o attraverso un
collegamento seriale fra i nodi. La replicazione si rende necessaria per
eliminare il single point of failure nel caso in cui ci fosse un unico collegamento
interno e questo si interrompesse. Ad ognuno dei nodi risulterebbe essere
12
Per l'inetrfacciamento esterno i nodi sono forniti di un'altra interfaccia ethernet come si evince dalla
descrizione dell'hardware presentata nel prossimo capitolo.
19
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
Capitolo 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'Hardware
Le 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 istruzioni
macchina.
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 CDROM, 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 diversi
processori 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 il
processore e il resto del sistema.
17
DDR: (Double Data Rate) tipo particolare di memoria sincrona che sfrutta il collegamento con il
chipset a doppio fronte. In parole povere il flusso di dati è raddoppiato per ogni ciclo di clock rispetto
alle vecchie memorie a singolo fronte.
18
ECC: (Error Correction Code) particolare tecnologia che caratterizza le memorie più costose. Riduce
drasticamente 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 operativo
Questa 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 della
distribuzione con emerge sync. Tale aggiornamento può richiedere davvero molto tempo per cui
siconsideri anche l'ipotesi di eseguire un aggiornamento manuale dei soli pacchetti per cui
l'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 direttamente
da 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è attivando
opportunamente 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 in
quanto il sistema di RAID hardware è configurato in modo tale da mostrare un unico disco e
utilizzare invece il sistema di memorizzazione per assolvere alle funzioni di replicazione dovute alla
configurazione particolare. Si veda il capitolo relativo all'hardware.
26
Nome
Dimensione Mount point
Tipo
Opzioni
ext2
noauto
partizione
(Mb)
sda1
100
sda2
2000
sda3
10000
/
ext3
noatime
sda5
10000
/usr
ext3
noatime
sda6
2000
/var
ext3
noatime
sda7
2000
/tmp
ext3
noatime
sda8
10000
/opt
ext3
noatime
sda9
10000
/home
ext3
noatime
sda10
10000
/bind
ext3
noatime
sda11
10000
/sendmail
ext3
noatime
/boot
swap
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 il
processo 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 che
contengono 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 informazioni
riguardanti lo stato attuale di funzionamento del sistema. E' costituito come un insieme di file per
mantener 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 e
quindi 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 estremamente
arduo e noioso che poteva essere svolto solo da pochi specialisti. Questo era dovuto al fatto che non
erano 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 alla
fine C fino ad arrivare, ai giorni nostri, ad ambienti di sviluppo visuali che hanno reso possibile il
RAD: Rapid Application Development, che fa uso di istruzioni di livello elevatissimo quasi in
linguaggio 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, utilizzare
30
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 del
file “.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 sicurezza
ma spesso è la soluzione migliore se è indispensabile dover usare programmi applicativi progettati
esclusivamente 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 di
stabilire 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 alle
funzioni di server per un determinato scopo. Il demone sshd infatti è costantemente attivo in ascolto
su 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 che
essendo completamente autonoma non necessita di scrivere dati su dischi fissi. Tutte le impostazioni e
personalizzazioni si perdono ovviamente ad ogni riavvio. La distribuzione più famosa i questa
categoria è 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
Capitolo 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 diversi
livelli che bilanciano, dal più basso al più alto, un diminuire dell'affidabilità e un aumento della
prestazione nella velocità di gestione dei dati, fornisce la possibilità di recupero di dati nel caso di
problemi ai dischi che li contengono. Questa possibilità è data dal fatto che il RAID replica più o
meno 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.
Cause di Downtime
Hardware 10,00%
Persone 15,00%
Malfunzionamenti Software 40,00%
Downtime pianificati 30,00%
Ambiente 5,00%
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
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 9
I 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:
Percentuale
Downtime per anno
Downtime per settimana
98,00%
7,3 giorni
3 ore, 22 minuti
99,00%
3,65 giorni
1 ora, 41 minuti
99,80%
17 ore, 30 minuti
20 minuti, 10 secondi
99,90%
8 ore, 45 minuti
10 minuti, 5 secondi
99,99%
52 minuti, 30 secondi
1 minuto
99,999%
5 minuti, 15 secondi
6 secondi
99,9999%
30,5 secondi
0,6 secondi
Uptime
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 prestazioni
Altra 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 che
svolgono 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 cluster
A 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 software
di 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
Capitolo 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 ActiveActive.
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 ResourceGroup 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 ARPspoofing 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 panoramica
Gli 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 progetto
L'illustrazione 1 rappresenta schematicamente il cluster che si è realizzato in
questo lavoro di tesi.
eth0: IP pubblico
eth0: IP pubblico
Nodo 2
Nodo 1
eth1: connessione heartbeat e drbd privata
eth2: channel bonding con eth1
0
1
0
1
ttyS0: connessione seriale
Illustrazione 1: Modello del sistema
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
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 gratuitousARP.
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 impostare
40
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 certo
server e tutti i suoi client. Inviando infatti dei gratuitous-ARP sulla rete del server da una macchina
presente nella stessa rete si reindirizzano tutti i pacchetti destinati al server a tale macchina “intrusa” la
quale risponderà ai vari client nel modo che ritiene opportuno e quanto più trasparente. Si pensi ai
danni 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 essere
connessi 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/ifconfig
bond0
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 ed
univoco 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 takeover 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
Capitolo 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 storage
Si 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 contesto
si 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 come
limite teorico di banda passante 480 Mb/sec. Molto usato in ambito desktop anche come interfaccia
di 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 filesystem 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 scelta
Per 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 filesystem 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 evitare
inconsistenze nei dati in quanto tutte le modifiche apportate vengono tracciate e memorizzate così in
caso di spegnimento accidentale del sistema o crash, al successivo montaggio del file-system, il sistema
operativo è in grado di ripristinare lo stato consistente dei dati annullando le operazioni non
completate prima del blocco.
50
Ext2: file-system storico usato sulla gran parte delle installazioni Linux prima della creazione di ext3
che 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 blockdevice, 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 blockdevice 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 blockdevice: 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 blockdevice 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 o
non è 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 eseguite
sulle 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 di
dati
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 “unconnectedcounter”. 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 primaryflag.
•
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 startuptimeout, 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 Performance
Nel 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 riletture sequenziali.
•
55
-i2 esegue invece test di lettura e scrittura casuale.
Microsoft Excel: Programma proprietario con licenza commerciale Microsoft che implementa il foglio
elettronico 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
ext3 writer report
1000000
4
8
16
32
64
128
100000
256
Performance KB/sec
512
1024
2048
4096
8192
16384
4096
32768
262144
File size KBlocale
Illustrazione 2: writer report, ext3 su block-device
2097152
4
16
128
2048
10000
64 256
1024
Block size KB
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
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.
drbd protA writer report
1000000
100000
performance KB/sec
1000
64 256
2048
16384
131072
2097152
file size KB
4
16
256
4096
10000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
Block size KB
Illustrazione 3: Writer Report con DRBD protocollo A
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
Le prestazioni reali medie si aggirano dunque mediamente intorno ai 2,8
megabyte per secondo.
drbd protoB writer report
1000000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
100000
performance KB/sec
1000
64 256
1024 4096
32768
262144
file size KB
2097152
4
16
128
2048
10000
Block size KB
Illustrazione 4: Writer Report con DRBD protocollo B
Stesse considerazioni anche per il file-system ext3 montato su Drbd blockdevice 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
secondario non sta eseguendo altri processi “time consuming” che
potrebbero ritardare l'esecuzione delle operazioni richieste da Drbd.
drbd protoC writer
1000000
4
8
16
32
100000
64
128
256
Performance KB/sec
512
10000
1024
2048
4096
2048
16384
262144
4
16
256
4096
8192
1000
64 256
File size KB
16384
Block size KB
Illustrazione 5: Writer Report con DRBD protocollo C
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
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.
ext3 re-writer report
1000000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
100000
10000
64 256
1024 4096
32768
262144
File size KB
2097152
4
16
128
2048
Perfromance KB/sec
Block size KB
Illustrazione 6: Re-Writer Report con ext3 locale
91
drbd protoA Re-writer report
1000000
100000
performance KB/sec
1000
64 256
1024 4096
32768
262144
2097152
4
16
128
1024
16384
10000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
block size KB
file size KB
Illustrazione 7: Re-Writer Report con Drbd protocollo A
drbd protoB Re-writer report
1000000
4
8
16
32
64
128
256
100000
512
1024
2048
performance KB/sec
1000
64 256
1024 4096
32768
262144
file size KB
2097152
4
16
128
1024
16384
10000
4096
8192
16384
Block size KB
Illustrazione 8: Re-Writer Report con DRBD protocollo B
92
drbd ProtoC re-writer report
1000000
4
8
16
32
64
100000
128
256
512
Performance KB/sec
1024
2048
Illustrazione 9: Re-Writer Report con Drbd protocollo C
1048576
File size KB
2097152
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1000
4
16
256
4096
10000
4096
8192
16384
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 filesystem 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
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 filesystem montato su device locale o su Drbd con i tre diversi protocolli di
sincronizzazione, sono in linea di massima paragonabili.
reader report
10000000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
1000000
Performance KB/sec
10000
64 256
1024 4096
32768
262144
File size KB
2097152
4
16
128
2048
100000
Block size KB
Illustrazione 10: Reader Report
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
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
re-reader report
10000000
1000000
Performance KB/sec
10000
64 256
2048
16384
262144
File size KB
4
16
256
4096
100000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
Block size KB
Illustrazione 11: Re-Reader Report
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
random read report
10000000
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
1000000
100000
10000
Performance KB/sec
100
64 256
1024
4096
32768
262144
File size KB
2097152
4
16
128
2048
1000
Block size KB
Illustrazione 12: Random-Read Report
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
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
local random write report
1000000
4
8
16
32
100000
64
128
10000
256
512
Performance KB/sec
1024
1000
2048
16384
131072
2097152
4
16
256
4096
100
64 256
2048
4096
8192
16384
Block size KB
File size KB
Illustrazione 13: Random-Write Report
drbd random write report
1000000
4
8
16
32
100000
64
128
10000
256
512
Performance KB/sec
1024
2048
1000
16384
2048
16384
131072
File size KB
2097152
4
16
256
4096
100
64 256
4096
8192
Block size KB
Illustrazione:14: Random-Write Report con Drbd
99
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 DRBD
La 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 blockdevice, 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 { #HA1
device=/dev/nbd/0
disk=/dev/sda10
address=192.168.0.1
port=7788
}
on independence { #HA2
device=/dev/nbd/0
disk=/dev/sda10
address=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 del
57
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 sottraggono
nemmeno le risorse hardware per le quali il sistema riserva la directory /dev all'interno della quale ogni
file 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 blockdevice) 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 blockdevice 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 filesystem 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 nodo
rispetto a un DRBD block-device e le operazioni di montaggio e smontaggio dei device, a cluster
ultimato 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
Capitolo 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 Heartbeat
Schematicamente si può riassumere la sua struttura con la seguente
illustrazione.
108
Illustrazione 15: Schema moduli Heartbeat
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
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 filesystem 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.
Illustrazione 16: Heartbeat: visione più ampia
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
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. Le
trasmissioni broadcast infatti sono inviate a tutti gli host connessi alla rete, quelle multicast a diversi
host 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 Group
Nella 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 configurazione
L'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 un
meccanismo di arbitraggio, stabilisce quale dei due nodi deve essere drasticamente disattivato inviando
quindi 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 ARP
Particolare 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
Capitolo 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 Mon
Mon è 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_apache2
service apache2
interval 5s
monitor http.monitor
period wd {Mon-Sun} hr {0-23}
alertafter 2
alert mail.alert root@localhost
alert apache2-restart.alert
service apache2-takeover
interval 5s
monitor http.monitor
period wd {Mon-Sun} hr {0-23}
alertafter 3 30m
numalerts 1
alert mail.alert -S "Apache2 non riparte,
provvedo a fermare heartbeat per causare
il takeover" root@localhost
alert 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 Webmin
Webmin è 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 webbased.
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 Swatch
Swatch è 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 blink
bell
write root
continue
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 sistema
Il 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 una
qualunque pagina web. Per poter essere eseguito è necessario il supporto da parte del server web.
133
Illustrazione 17: pagina predefinita
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 18: caratteristiche del server lette dal file “server.php”
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
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.
Illustrazione 19: messaggi di Heartbeat su "independence"
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
Ecco come appare adesso lo stato del server.
Illustrazione 20: caratteristiche server apache su "independence"
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
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.
Illustrazione 21: modulo Webmin relativo a "mon"
138
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.
Illustrazione 22: modulo Webmin relativo a Heartbeat
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
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 HOWTO
at
# http://www.gentoo.org/doc/use-howto.html
#
# The available list of use flags with descriptions is in your portage
tree.
# 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 asis;
# otherwise, change to i586, i486 or i386 as appropriate. All modern
systems
# (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 CPU
without
# breaking compatibility with other CPUs.
#
# -march=<cpu-type> means to take full advantage of the ABI and
instructions
# 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, athlon4,
# 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 gcc3.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 gcc2.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++ flags
to
# the same settings. If you don't set CFLAGS above, then comment this line
out.
CXXFLAGS="${CFLAGS}"
# Advanced Masking
# ================
#
# Gentoo is using a new masking system to allow for easier stability
testing
# on packages. KEYWORDS are used in ebuilds to mask and unmask packages
based
# 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 not
yet
# 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 their
respective
# platforms. DO NOT PUT ANYTHING BUT YOUR SPECIFIC ~ARCHITECTURE IN THE
LIST.
# 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/profile
if
# 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 before
they
# 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.tuclausthal.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.conf
boot=/dev/sda
map=/boot/System.map
install=/boot/boot.b
prompt
timeout=30
lba32
default=2.4.26
vga=789
image=/boot/bzImage
initrd=/boot/initrd-2.4.20-gentoo-r8
label=2.4.20-g-r8
read-only
root=/dev/sda3
image=/boot/kernel-2.4.25
label=2.4.25
read-only
root=/dev/sda3
image=/boot/kernel-2.4.26
label=2.4.26
read-only
root=/dev/sda3
A4. /usr/src/linux/.config
CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
144
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_MPENTIUM4=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_X86_TSC=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_ACPI_BOOT=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=m
CONFIG_ISAPNP=m
CONFIG_BLK_DEV_FD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
145
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETFILTER=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
146
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_OPTI621=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_DPT_I2O=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=y
CONFIG_TUN=m
CONFIG_ETHERTAP=y
CONFIG_NET_ETHERNET=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_NET_VENDOR_SMC=y
147
CONFIG_NET_VENDOR_RACAL=y
CONFIG_HP100=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_TULIP=m
CONFIG_DE4X5=m
CONFIG_DGRS=m
CONFIG_DM9102=m
CONFIG_EEPRO100=m
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
CONFIG_8139TOO_8129=y
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_WINBOND_840=m
CONFIG_NET_POCKET=y
CONFIG_ACENIC=m
CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m
CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
CONFIG_CYZ_INTR=y
CONFIG_DIGIEPCA=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_N_HDLC=m
CONFIG_RISCOM8=m
CONFIG_SPECIALIX=m
CONFIG_SPECIALIX_RTSCTS=y
CONFIG_SX=m
148
CONFIG_RIO=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_82C710_MOUSE=m
CONFIG_RTC=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_ZISOFS_FS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
CONFIG_SUN_PARTITION=y
CONFIG_EFI_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
149
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOG_BUF_SHIFT=0
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
A4 /etc/conf.d/net
iface_eth2="193.206.185.XXX
broadcast
255.255.255.0"
iface_bond0="192.168.0.1
broadcast
255.255.255.0"
gateway="eth2/193.206.185.1"
193.206.185.255
netmask
192.168.0.255
netmask
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
alias
alias
alias
l='ls --color'
cd..='cd ..;l'
la='l -a'
ll='l -l'
A7. /etc/drbd.conf
resource drbd0 { #BIND
protocol=C
fsckcmd=fsck -p -y
net {
sync-max=100M
tl-size=10000
timeout=60
connect-int=10
ping-int=10
}
on freedom { #HA1
device=/dev/nbd/0
disk=/dev/sda10
address=192.168.0.1
port=7788
}
on independence { #HA2
device=/dev/nbd/0
disk=/dev/sda10
address=192.168.0.2
port=7788
}
}
resource drbd1 { #SENDMAIL
protocol=C
fsckcmd=fsck -p -y
net {
sync-max=100M
tl-size=10000
timeout=60
connect-int=10
ping-int=10
}
on freedom { #HA1
device=/dev/nbd/1
disk=/dev/sda11
address=192.168.0.1
151
port=7789
}
on independence { #HA2
device=/dev/nbd/1
disk=/dev/sda11
address=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-debug
logfile
/var/log/ha-log
logfacility local0
keepalive
2
#intervallo di heartbeat
deadtime
5
#tempo minimo per essere considerato down
initdead
120
#tempo necessario al boot
auto_failback on
#Il Resource Group torna automaticamente al
ritorno del nodo se l'opzione è on
serial
/dev/ttyS0
#device seriale
baud
19200
#velocità seriale
udpport
694
#porta usata per le comunicazioni in bcast
(bond0)
bcast
bond0
#interfaccia di comunicazione interna
node
freedom
#nome nodo come specificato in uname -n
node
independence
apiauth
respawn
ipfail uid=hacluster
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/mon
ping
193.206.185.1
#indirizzo da interrogare per
verificare il
#funzionamento della rete esterna
A10. /etc/mon.d/mon.cf
alertdir
mondir
= /usr/lib/mon/alert.d
= /usr/lib/mon/mon.d
152
logdir
= /var/log/mon.d
statedir
= /var/lib/mon.d
authfile
= /etc/mon/auth.cf
maxprocs
= 20
histlength = 100
randstart = 60s
#
# define groups of hosts to monitor
#
hostgroup test_apache2 193.206.185.XXX
watch test_apache2
service apache2
interval 5s
monitor http.monitor
period wd {Mon-Sun} hr {0-23}
alertafter 2
alert mail.alert root@localhost
alert apache2-restart.alert
service apache2-takeover
interval 5s
monitor http.monitor
period wd {Mon-Sun} hr {0-23}
alertafter 3 30m
numalerts 1
alert mail.alert -S "Apache2 non riparte,
provvedo a fermare heartbeat per causare il
takeover" root@localhost
alert haStop.alert
A11. /etc/mon.d/auth.cf
command section
list:
all
reset:
root
loadstate:
root
savestate:
root
version:
all
reload auth:
root
servertime: all
list failures:
all
list successes: all
list state: all
monitor:
all
A12. /root/.swatchrc
watchfor /dead/
echo bold undersore blink
bell
write root
continue
watchfor /shutdown/
echo bold undersore blink
bell
153
write root
continue
watchfor /Gratuitous Arp/
echo blink
bell
write root
continue
watchfor /takeover/
echo undersore
bell
write root
continue
watchfor /transition/
echo bold undersore blink
bell
write root
continue
watchfor /down/
echo bold undersore blink
bell
write root
continue
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 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away
your freedom to share and change it. By contrast, the GNU
General Public License is intended to guarantee your freedom
to share and change free software--to make sure the software
is free for all its users. This General Public License
applies to most of the Free Software Foundation's software
and to any other program whose authors commit to using it.
(Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can
apply 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 make
sure that you have the freedom to distribute copies of free
software (and charge for this service if you wish), that you
receive source code or can get it if you want it, that you
can change the software or use pieces of it in new free
programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that
forbid anyone to deny you these rights or to ask you to
surrender the rights. These restrictions translate to
certain responsibilities for you if you distribute copies of
the 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 recipients
all the rights that you have. You must make sure that they,
too, receive or can get the source code. And you must show
them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the
software, and (2) offer you this license which gives you
legal permission to copy, distribute and/or modify the
software.
Also, for each author's protection and ours, we want to make
certain that everyone understands that there is no warranty
for this free software. If the software is modified by
someone else and passed on, we want its recipients to know
that what they have is not the original, so that any
problems introduced by others will not reflect on the
original authors' reputations.
155
Finally, any free program is threatened constantly by
software patents. We wish to avoid the danger that
redistributors of a free program will individually obtain
patent licenses, in effect making the program proprietary.
To prevent this, we have made it clear that any patent must
be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution
and modification follow.
TERMS
AND
CONDITIONS
MODIFICATION
FOR
COPYING,
DISTRIBUTION
AND
0. This License applies to any program or other work which
contains a notice placed by the copyright holder saying it
may be distributed under the terms of this General Public
License. The "Program", below, refers to any such program or
work, and a "work based on the Program" means either the
Program or any derivative work under copyright law: that is
to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into
another language. (Hereinafter, translation is included
without limitation in the term "modification".) Each
licensee is addressed as "you".
Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope.
The act of running the Program is not restricted, and the
output from the Program is covered only if its contents
constitute a work based on the Program (independent of
having been made by running the Program). Whether that is
true depends on what the Program does.
1. You may copy and distribute verbatim copies of the
Program's source code as you receive it, in any medium,
provided that you conspicuously and appropriately publish on
each copy an appropriate copyright notice and disclaimer of
warranty; keep intact all the notices that refer to this
License and to the absence of any warranty; and give any
other recipients of the Program a copy of this License along
with the Program.
You may charge a fee for the physical act of transferring a
copy, and you may at your option offer warranty protection
in exchange for a fee.
2. You may modify your copy or copies of the Program or any
portion of it, thus forming a work based on the Program, and
copy and distribute such modifications or work under the
terms of Section 1 above, provided that you also meet all of
these conditions:
a) You must cause the modified files to carry
prominent notices stating that you changed the files
and the date of any change.
b) You must cause any work that you distribute or
publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be
156
licensed as a whole at no charge to all third parties
under the terms of this License.
c) If the modified program normally reads commands
interactively when run, you must cause it, when
started running for such interactive use in the most
ordinary way, to print or display an announcement
including an appropriate copyright notice and a notice
that there is no warranty (or else, saying that you
provide a warranty) and that users may redistribute
the program under these conditions, and telling the
user how to view a copy of this License. (Exception:
if the Program itself is interactive but does not
normally print such an announcement, your work based
on the Program is not required to print an
announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its
terms, do not apply to those sections when you distribute
them as separate works. But when you distribute the same
sections as part of a whole which is a work based on the
Program, the distribution of the whole must be on the terms
of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part
regardless of who wrote it.
Thus, it is not the intent of this section to claim rights
or contest your rights to work written entirely by you;
rather, the intent is to exercise the right to control the
distribution of derivative or collective works based on the
Program.
In addition, mere aggregation of another work not based on
the Program with the Program (or with a work based on the
Program) on a volume of a storage or distribution medium
does not bring the other work under the scope of this
License.
3. You may copy and distribute the Program (or a work based
on it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you
also do one of the following:
a) Accompany it with the complete corresponding
machine-readable
source
code,
which
must
be
distributed under the terms of Sections 1 and 2 above
on a medium customarily used for software interchange;
or,
b) Accompany it with a written offer, valid for at
least three years, to give any third party, for a
charge no more than your cost of physically performing
source distribution, a complete machine-readable copy
of the corresponding source code, to be distributed
under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
157
c) Accompany it with the information you received as
to the offer to distribute corresponding source code.
(This alternative is allowed only for noncommercial
distribution and only if you received the program in
object code or executable form with such an offer, in
accord with Subsection b above.)
The source code for a work means the preferred form of the
work for making modifications to it. For an executable work,
complete source code means all the source code for all
modules
it
contains,
plus
any
associated
interface
definition files, plus the scripts used to control
compilation and installation of the executable. However, as
a special exception, the source code distributed need not
include anything that is normally distributed (in either
source or binary form) with the major components (compiler,
kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies
the executable.
If distribution of executable or object code is made by
offering access to copy from a designated place, then
offering equivalent access to copy the source code from the
same place counts as distribution of the source code, even
though third parties are not compelled to copy the source
along with the object code.
4. You may not copy, modify, sublicense, or distribute the
Program except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense or distribute
the Program is void, and will automatically terminate your
rights under this License. However, parties who have
received copies, or rights, from you under this License will
not have their licenses terminated so long as such parties
remain in full compliance.
5. You are not required to accept this License, since you
have not signed it. However, nothing else grants you
permission to modify or distribute the Program or its
derivative works. These actions are prohibited by law if you
do not accept this License. Therefore, by modifying or
distributing the Program (or any work based on the Program),
you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or
modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based
on the Program), the recipient automatically receives a
license from the original licensor to copy, distribute or
modify the Program subject to these terms and conditions.
You may not impose any further restrictions on the
recipients' exercise of the rights granted herein. You are
not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of
patent infringement or for any other reason (not limited to
patent issues), conditions are imposed on you (whether by
court order, agreement or otherwise) that contradict the
conditions of this License, they do not excuse you from the
158
conditions of this License. If you cannot distribute so as
to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all. For
example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive
copies directly or indirectly through you, then the only way
you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or
unenforceable under any particular circumstance, the balance
of the section is intended to apply and the section as a
whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to
infringe any patents or other property right claims or to
contest validity of any such claims; this section has the
sole purpose of protecting the integrity of the free
software distribution system, which is implemented by public
license
practices.
Many
people
have
made
generous
contributions to the wide range of software distributed
through that system in reliance on consistent application of
that system; it is up to the author/donor to decide if he or
she is willing to distribute software through any other
system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is
believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is
restricted in certain countries either by patents or by
copyrighted interfaces, the original copyright holder who
places the Program under this License may add an explicit
geographical
distribution
limitation
excluding
those
countries, so that distribution is permitted only in or
among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the
body of this License.
9. The Free Software Foundation may publish revised and/or
new versions of the General Public License from time to
time. Such new versions will be similar in spirit to the
present version, but may differ in detail to address new
problems or concerns.
Each version is given a distinguishing version number. If
the Program specifies a version number of this License which
applies to it and "any later version", you have the option
of following the terms and conditions either of that version
or of any later version published by the Free Software
Foundation. If the Program does not specify a version number
of this License, you may choose any version ever published
by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into
other free programs whose distribution conditions are
different, write to the author to ask for permission. For
software which is copyrighted by the Free Software
Foundation, write to the Free Software Foundation; we
159
sometimes make exceptions for this. Our decision will be
guided by the two goals of preserving the free status of all
derivatives of our free software and of promoting the
sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS
NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM
"AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE
OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED
TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY
WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED
ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL,
SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF
THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE
PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the
greatest possible use to the public, the best way to achieve
this is to make it free software which everyone can
redistribute and change under these terms.
To do so, attach the following notices to the program. It is
safest to attach them to the start of each source file to
most effectively convey the exclusion of warranty; and each
file should have at least the "copyright" line and a pointer
to where the full notice is found.
one line to give the program's name and a brief idea
of what it does.
Copyright (C)
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General
Public License as published by the Free Software
Foundation; either version 2 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will
be useful, but WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A
160
PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General
Public License along with this program; if not, write
to the Free Software Foundation, Inc., 59 Temple
Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and
paper mail.
If the program is interactive, make it output a short notice
like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of
author Gnomovision comes with ABSOLUTELY NO WARRANTY;
for details type `show w'. This is free software, and
you are welcome to redistribute it under certain
conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show
the appropriate parts of the General Public License. Of
course, the commands you use may be called something other
than `show w' and `show c'; they could even be mouse-clicks
or menu items--whatever suits your program.
You should also get your employer (if you work as a
programmer) or your school, if any, to sign a "copyright
disclaimer" for the program, if necessary. Here is a sample;
alter the names:
Yoyodyne,
Inc.,
hereby
disclaims
all
copyright
interest
in the program `Gnomovision' (which makes passes at
compilers)
written by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not
your program into proprietary programs.
subroutine library, you may consider
permit linking proprietary applications
this is what you want to do, use the
Public License instead of this License.
permit incorporating
If your program is a
it more useful to
with the library. If
GNU Library General
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/linux2.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