virtualizzazione in un cluster ad alta disponibilità in ambiente linux

Transcript

UNIVERSITÀ DEGLI STUDI DI CAMERINO
FACOLTÀ DI SCIENZE E TECNOLOGIE
Corso di Laurea Specialistica in Informatica
Dipartimento di Matematica e Informatica
VIRTUALIZZAZIONE IN UN CLUSTER AD
ALTA DISPONIBILITÀ IN AMBIENTE
LINUX
Tesi di Laurea Sperimentale
In
Reti di Elaboratori
Laureando
Mirco Perini
Relatore
Prof. F. Marcantoni
_________________
Anno Accademico 2005-2006
h o ri sa li to i l c rep a cc io d ella S ib i lla
h o lo t ta to p er o n o ra re l a mia Mu ta
h o vig i la to su lla g en t e d ell e A ra n c e
h o co mb a ttu to la g u er ra so t to la La n te rn a
h o tra s cin a to a m ic i fu o r i d a l N ive o
h o p u n ta to i p i ed i g u a rd a n d o le S c in t il le
ma i l ve ro co ra g g io lo v ed o in te.. in vo i
n ella d if fi co l tà d e lla vi t a … tu tt i i g io rn i
se ma i d o v rò b e re a n ch ’ io d a q u e sto a ma ro
ca li ce sp e mo d ’a v er i l v o st ro st e sso a rd i re.
forza papà
forza mamma
Ringraziamenti
Vorrei ringraziare il Prof. Fausto Marcantoni per avermi seguito e
consigliato nella realizzazione del progetto e nella stesura della tesi.
Un ulteriore grazie va agli operatori e ai ragazzi della Ripartizione
Servizi Informatici e Statistici dell’Università degli Studi di Perugia, ed
in particolare a Tiziano Micheli per aver ascoltato le mie noiose
spiegazioni, a Giovanni Sabatini e Federico Giorgetti per la disponibilità
e soprattutto a Marco Pallotta colui che mi ha permesso di diventare
l’amministratore di sistema che sono oggi.
Un meritato ringraziamento va al compagno di questa fantastica
avventura Dott. Carlo Manuali, alla Dott.sa Chiara Del Buono e alla sua
crew per aver sopportato il mio nervosismo, a tutti i ―malati‖ di
nolannoparty, agli amici del fù GHS, a Maurino e a tutti i ragazzi della
sua band per essere stati la colonna sonora di questa tesi ed infine a tutti
coloro che con il loro affetto e la loro pazienza mi hanno sopportato ed
hanno permesso per la terza volta che tutto questo si realizzasse.
Grazie.
———————————————————————————————— INDICE
Indice
INTRODUZIONE ....................................................... VI
CAPITOLO 1
SISTEMI DISTRIBUITI: GENERALITÀ ...................... 1
1 .1 A R C H IT E T T U R A ................................ ................................ ..... 3
1 .2 S IS T E M I O P E R A T IV I T I P IC I D E I C L U S T E R ................................ ... 6
1 .3 T IP O L O G IE D I C L U S T E R ................................ ........................... 8
CAPITOLO 2
L'ALTA DISPONIBILITÀ .......................................... 15
2 .1 L IV E L L I D I D IS P O N IB I L I T À ................................ ..................... 1 6
2 .2 I L R E Q U IS IT O D E I C IN Q U E 9 ................................ .................... 2 0
2 .3 L E P R E S T A Z IO N I N E L L ' A L T A D IS P O N IB I L I T À .............................. 2 5
2 .4 T IP O L O G IE D I C L U S T E R IN A L T A D IS P O N IB I L IT À ........................ 2 7
CAPITOLO 3
LA VIRTUALIZZAZIONE ......................................... 32
3 .1 C O N C E T T I GE N E R A L I ................................ ............................. 3 4
I
———————————————————————————————— INDICE
3 .2 A S P E T T I F O N D AM E N T A L I ................................ ....................... 3 6
3 .3 R E Q U IS IT I D I U N A M A C C H IN A V IR T U A L E ................................ .. 4 0
3 .4 V IR T U A L M AC H IN E M O N IT O R ( VM M) ................................ ..... 4 1
3 .4 .1 F U L L V IR T U A L IZ A T IO N E P AR A V IR T U A L IZ A T I O N .............. 4 2
3 .4 .2 B IN A R Y T R A N S L A T I O N E D Y N A M IC R E C O M P I L A T I O N ......... 4 3
3 .4 .3 S T R U T T U R A IN T E R N A D E L L ' H Y P E R V IS O R ........................ 4 4
3 .4 .3 .1 V IR T U A L I Z Z A Z IO N E D E L L A CP U ...................... 4 5
3 .4 .3 .2 V IR T U A L I Z Z A Z IO N E D E L L A M E M O R IA ............... 4 9
3 .4 .3 .3 V IR T U A L I Z Z A Z IO N E D E L L E P E R IF E R IC H E ........... 5 3
3 .5 B E N E F IC I D E L L A V IR T U A L I Z Z A Z IO N E ................................ ....... 5 5
3 .6 P R IN C IP A L I S O F T W AR E D I V IR T U A L I Z Z A Z IO N E ........................... 5 9
CAPITOLO 4
REALIZZAZIONE DEL PR OGETTO ......................... 63
4 .1 A N A L IS I D E L P R O B LE M A ................................ ........................ 6 4
4 .2 I N S T A L L A Z IO N E E C O N F I G U R A Z IO N E D E I D U E N O D I .................... 6 7
4 .2 .1 C H A N N E L B O N D IN G ................................ .................... 6 8
4 .3 C O N F IG U R A Z IO N E D E L L O S T O R A GE C O N D IV IS O ......................... 7 3
4 . 3 .1 T IP O L O G IE D I S T O R A G E ............................................... 7 4
4 . 3 .2 C A R A T T E R IS T IC H E D I DRB D ................................ ........ 8 1
4 .3 .2 .1 I P R O T O C O L L I D I S IN C R O N IZ Z A Z IO N E ................ 8 3
4 . 3 .3 I N S T A L L A Z IO N E E C O N F I G U R A Z IO N E D I D R B D ................ 8 5
4 .3 .3 .1 I L F I L E D I C O N F I G U R A Z IO N E " D R B D . C O N F " ........ 8 8
4 .4 C O N F IG U R A Z IO N E D I H E AR T B E A T ................................ ........... 9 5
4 . 4 .1 L A S T R U T T U R A D I H E AR T B E A T ................................ ..... 9 5
4 .4 .1 .1 I P L U G IN D I H E A R T B E A T ................................ . 9 9
4 .4 .2 I R E S O U R C E G R O U P ................................ .................. 1 0 1
4 . 4 .3 I N S T A L L A Z IO N E E C O N F I G U R A Z IO N E D I H E A R T B E A T ...... 1 0 2
4 .5 C O N F IG U R A Z IO N E D E L L E V IR T U A L M AC H IN E ........................... 1 1 2
4 . 5 .1 I N S T A L L A Z IO N E E C O N F IG U R A Z IO N E D I VM W AR E S E R V E R 1 1 3
4 .5 .2 I N S T A L L A Z IO N E D E L L E V IR T U A L M AC H IN E S ................. 1 1 9
4 .6 I N T E GR A Z IO N E D I T U T T O I L S IS T E M A ................................ ..... 1 2 5
4 .7 T E S T IN G D E L P R O GE T T O ................................ ...................... 1 3 7
II
———————————————————————————————— INDICE
CONCLUSIONI ........................................................ 144
APPENDICE A - I FILE DEL S.O. ............................ 147
APPENDICE B - I FILE DI DRBD ............................ 155
APPENDICE C - I FILE DI HEARTBEAT ................ 161
APPENDICE D - I FILE DI PROGETTO .................. 173
BIBLIOGRAFIA ....................................................... 177
III
——————————————————————————ELENCO DELLE FIGURE
Elenco delle figure
2 .1
P R O B AB I L I C A U S E D I D O W N T IM E ................................ ........... 1 9
2 .2
I C O S T I D E L L ' A L T A A F F ID AB I L IT À ................................ ......... 2 2
2 .3
C L U S T E R IN C O N F IG U R A Z IO N E A C T IV E - S T A N D B Y .................... 2 7
2 .4
C L U S T E R IN C O N F IG U R A Z IO N E A C T IV E - A C T IV E ....................... 2 8
2 .5
C L U S T E R IN C O N F IG U R A Z IO N E L O A D B A L A N C IN G .................... 2 9
3 .1
E S E M P IO D I V IR T U A L IZ Z A Z IO N E ................................ ............ 3 3
3 .2
M U L T IP L A Z IO N E
TEMPORA LE
NEGLI
A M B IE N T I
VIR TUALI
D E G L I A N N I S E S S A N T A ................................ ......................... 3 5
3 .3
S C H E M A A L IV E L L I D E L L A S T R U T T U R A D I U N C A LC O L A T O R E
S E N Z A V IR T U A L M AC H IN E
3 .4
................................ .................... 3 7
SCHEMA
DI
V IR T U A L I
................................ ................................ .......... 3 8
UN
C ALC OLAT ORE
DOTATO
DI
M AC C H I N E
3 .5
S T R U T T U R A D E L V IR T U A L M A C H IN E M O N IT O R ....................... 4 5
3 .6
I N T E R C E T T A Z IO N E D E L L E E C C E Z IO N I D E L D IS P A T C H E R ............. 4 7
3 .7
S IS T E M A D I IN D IR IZ Z AM E N T O D E L L A M E M O R I A N E L VMM ........ 5 2
3 .8
M AS C H E R AM E N T O D E L L I V E L L O H AR D W A R E N E L V MM ............ 5 8
3 .9
T AB E L L A
C O M P AR A T IV A
DEI
P R IN C IP A L I
SOFTWARE
DI
V IR T U A L I Z Z A Z IO N E ................................ ............................. 6 2
4 .1
F O T O D E L N O D O A L P H A ................................ ....................... 6 6
4 .2
F O T O D E L N O D O B R A V O ................................ ....................... 6 6
4 .3
SCHEMA
DEL
PROGETTO
C H AN E L L B O N D IN G
D OPO
L ' IN S T A L L A Z IO N E
DEL
................................ ............................. 7 3
4 .4
I M P O S T A Z IO N E D I D RB D P E R L ' A V V IO A L B O O T ...................... 8 7
4 .5
S C H E M A D E L P R O G E T T O D O P O L ' IN S T A L L A Z IO N E D I DRB D ....... 9 4
4 .6
S C H E M A D E I M O D U L I D I H E AR T B E A T ................................ ..... 9 6
4 .7
M O D U L I E S T E R N I D I H E A R T B E A T ................................ .......... 9 9
4 .8
I M P O S T A Z IO N E D I H E AR T B E A T P E R L ' A V V IO A L B O O T ............. 1 0 4
IV
——————————————————————————ELENCO DELLE FIGURE
4 .9
SCHEMA
DEL
PROGETTO
D OPO
L ' IN S T A L L A Z IO N E
DI
H E AR T B E A T ................................ ................................ ..... 1 1 1
4 .1 0 L A
F IN E S T R A
DI
L O G IN
DI
V M W AR E
MANAGEMENT
I N T E R F AC E ................................ ................................ ...... 1 1 8
4 .1 1 L A S C H E R M A T A IN I Z I A L E D I VM W A R E S E R V E R C O N S O L E ........ 1 2 0
4 .1 2 F A S I IN IZ I A L I D E L L A C O N F IG U R A Z IO N E D I U N A V M C O N
VM W A R E S E R V E R C O N S O L E ............................................... 1 2 1
4 .1 3 C O N F IG U R A Z IO N E H AR D W A R E D I U N A V M C O N VM W A R E
S E R V E R C O N S O L E ................................ ............................. 1 2 3
4 .1 4 I N S T A L L A Z IO N E D E L S IS T E M A O P E R A T IV O IN U N A M AC C H IN A
V IR T U A L E ................................ ................................ ........
123
4 .1 5 L E F A S I D I IN S T A L L A Z I O N E D E I VM W A R E T O O L S IN U N A
M AC C H IN A V IR T U A L E
................................ ........................ 1 2 5
4 .1 6 A V V IO D I H E AR T B E A T E T E S T D I F U N Z IO N A L I T À D E L L O
S C R IP T R E A L I Z Z A T O
................................ .......................... 1 3 4
4 .1 7 S C H E M A F IN A L E D E L P R O G E T T O ................................ .......... 1 3 5
4 .1 8 F O T O D E L C L U S T E R N E L L A C O N F I G U R A Z IO N E D E F I N IT IV A ....... 1 3 6
4 .1 9 L A M UI M O S T R A L O S T A T O D E L L E Q U A T T R O M AC C H IN E
V IR T U A L I S U L N O D O A L P H A ................................ ................
140
4 .2 0 I L C L IE N T K M A I L M O S T R A L A S E Q U E N Z A D I M E S S A G G I D I U P E
D O W N D E L L E M AC C H IN E V IR T U A L I
................................ ...... 1 4 1
4 .2 1 S C H E D A D E L P R O G E T T O A S E G U I T O D E L C R AS H S I M U L A T O ...... 1 4 3
V
————————————————————————————— INTRODUZIONE
Introduzione
Il presente lavoro di tesi è stato svolto presso l’Area Servizi TecnicoSistemistici
della
Ripartizione
Servizi
Informatici
e
Statistici
dell’Università degli studi di Perugia.
Il progetto ha avuto come scopo la ricerca, lo studio e
l’implementazione di una soluzione completamente open-source
finalizzata alla virtualizzazione di alcune macchine, utilizzando come
sistema ospite un Cluster composto da due nodi configurato per
l’erogazione di servizi in alta affidabilità (High Avaiability o HA).
Nella sala macchine dell’Ateneo, come in molte altre aziende, si è
notato che diverse macchine server vengono utilizzate ampliamente al
disotto delle loro potenzialità. Questo significa nella pratica che, per la
maggior parte del tempo, il processore di tali macchine resta inutilizzato,
in attesa che gli venga dato qualcosa da fare.
Di fatto questa situazione rappresenta per l’amministrazione un
inutile spreco di risorse: gli investimenti finanziari effettuati per
l’acquisto di tali macchine e il tempo richiesto ai sistemisti per la loro
gestione, potrebbero essere facilmente recuperati mediante un attento
VI
————————————————————————————— INTRODUZIONE
consolidamento, avente come fine ultimo l’accorpamento in un unico
server delle attività svolte da un insieme di macchine.
Proprio sulla base dei principi appena illustrati, la Ripartizione
Servizi Informatici e Statistici ha deciso attraverso questo lavoro di tesi
di sperimentare la virtualizzazione di alcune delle sue macchine,
ponendosi fondamentalmente due obiettivi: da un lato la minimizzazione
delle spese necessarie alla realizzazione del progetto stesso e dall’altro il
miglioramento della qualità dei servizi offerti con particolare riferimento
alla loro affidabilità.
Nei
capitoli
iniziali
verranno
illustrate
le
caratteristiche
fondamentali delle teorie alla base di questo lavoro. Nel primo capitolo si
affronterà un analisi dei fondamenti e delle tipologie di sistemi
distribuiti,
soffermandosi
in
particolare
sui
sistemi
operativi
maggiormente utilizzati e sulle differenze tra cluster per il calcolo
scientifico e cluster per l’alta affidabilità.
Nel secondo capitolo si proseguirà con una attenta descrizione dei
diversi livelli di disponibilità, dei requisiti fondamentali, delle vari livelli
prestazionali dell’affidabilità e delle varie tipologie che caratterizzano un
cluster in high avaiability.
Nel terzo capitolo verranno affrontati i concetti basilari su cui si
fondano le teorie della virtualizzazione: dagli aspetti fondamentali ai
requisiti indispensabili per la sua attuazione. Nella parte conclusiva del
capitolo verrà infine descritta, in modo dettagliato, l’architettura alla base
VII
————————————————————————————— INTRODUZIONE
della virtualizzazione con particolare riferimento ai benefici introdotti da
questa tecnica ed ai principali software utilizzati.
Nel quarto e ultimo capitolo verrà affrontata la fase di analisi di
questo lavoro di tesi, si cercherà di far capire il percorso logico e le
motivazioni che hanno condotto alle scelte adottate all’interno del
progetto. Si partirà in principio con una panoramica delle potenziali
soluzioni a disposizione, sia dal punto di vista software che da quello
hardware, e si proseguirà poi con un dettagliato studio delle informazioni
raccolte
che
porterà
alla
definizione
delle
scelte
progettuali
effettivamente adottate nella fase realizzativa. La seconda parte del
capitolo è invece incentrato sull’implentazione pratica del lavoro ed in
particolare sull’installazione e la configurazione degli strumenti scelti per
la messa in opera del progetto. Il primo di questi strumenti è il modulo
DRDB che, in combinazione con il meccanismo del channel bonding,
fornisce ai sistemi operativi appartenenti al cluster, un dispositivo di
memorizzazione di massa condiviso realizzato attraverso le partizioni dei
dischi reali. Nei paragrafi seguenti verrà prima configurata la suite
Heartbeat, indispensabile per garantire l’alta disponibilità del sistema, e
successivamente VMWare Server per la virtualizzazione. Nella parte
conclusiva del capitolo verranno infine illustrate le modifiche necessarie
per integrare gli strumenti mostrati e rendere operativo l’intero progetto.
Chiudono il lavoro di tesi una serie di appendici contenenti i file testuali
relativi alla configurazione dei software utilizzati.
VIII
————————————————————— SISTEMI DISTRIBUITI: GENERALITÀ
Capitolo 1
1 Sistemi distribuiti: generalità
Nonostante l’informatica sia una scienza relativamente moderna è
riuscita nel corso del tempo ad invadere ogni strato della società civile.
Il suo sviluppo, avvenuto contestualmente all’invenzione delle
macchine in grado di eseguire calcoli in modo automatico ed in brevi
lassi di tempo, ha consentito agli studiosi di addentrarsi in realtà prima
di allora inesplorate.
I primi computer erano in grado di risolvere solo problemi
elementari, ma grazie alla ricerca e agli investimenti negli ambienti
accademici e in quelli aziendali, la scienza informatica è stata
progressivamente in grado di progettare elaboratori sempre più potenti,
denominati supercomputer, capaci di risolvere problematiche sempre
più evolute.
La crescente richiesta di ingenti capacità elaborative in molti
settori legati alla ricerca e all’analisi di realtà complesse (scientifica,
finanziaria, ecc…) condussero molte aziende a realizzare prodotti
1
informatici specializzati e progettati appositamente allo scopo ma a
prezzi decisamente elevati.
Il successivo avvento dell’informatica personale e la creazione di
ciò che può esserne ritenuto il suo simbolo, il personal computer (PC),
portarono realtà consolidate come i supercomputer a diminuire la loro
incidenza sul mercato. La diffusione dei PC a prezzi modesti indusse la
richiesta di capacità di calcolo ad orientarsi verso soluzioni a basso
costo; nacquero così software in grado di ―virtualizzare‖ un gruppo di
macchine, creando un unico sistema in grado di redistribuire il carico
operativo su ogni singolo componente.
Un gruppo di computer, uniti allo scopo di risolvere insieme un
problema comune e visibili all’utente come un unica macchina virtuale,
viene definito sistema distribuito o cluster1
Il paradigma alla base del sistema distribuito è assimilabile alla
teoria del ―divide et impera‖, tipica degli studi sugli algoritmi, secondo
la quale ogni problema può essere risolto con una scomposizione in
sottoproblemi più piccoli, la cui risoluzione genera una parte della
soluzione complessiva del problema primario. L’applicazione di questo
schema di ragionamento incorpora il concetto di modularità che
1
Un cluster (dall’inglese grappolo) è un insieme di computer connessi tramite una
rete telematica. Lo scopo di un cluster è quello di distribuire una computazione molto
complessa tra i vari computer componenti il cluster. In sostanza un problema che
richiede molte elaborazioni per essere risolto viene scomposto in sottoproblemi
separati i quali vengono risolti in parallelo. Questo aumenta, ovviamente, la potenza
di calcolo del sistema
2
caratterizza tutti i moderni sistemi di calcolo, in modo particolare i
sistemi distribuiti.
Un sistema distribuito, infatti, non è altro che un insieme di
calcolatori identici che vengono comunemente definiti ―nodi‖. In un
sistema di questo tipo si ha la possibilità di aggiungere o eliminare nodi
generando rispettivamente un aumento oppure una diminuzione di
potenza di calcolo complessiva dell’intero sistema. Questa particolare
caratteristica prende il nome di scalabilità. In generale un sistema si
definisce scalabile quanto l’aumento delle prestazioni di calcolo
aumenta in modo proporzionale al numero di nodi del sistema.
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 tra loro
da una rete di comunicazione privata utilizzata esclusivamente per la
sincronizzazione dei dati e l’interscambio di messaggi fra i processi in
esecuzione e che condividono delle risorse locali o remote[1].
1.1 Architettura
In funzione della modalità con cui le risorse utilizzate dai nodi sono
disposte e gestite, un sistema distribuito può essere principalmente
distinto in due categorie[2]:
3

Sistemi Tightly Coupled o anche definiti Shared Memory, la cui
caratteristica distintiva sta nel fatto che ogni singolo nodo del
cluster condivide la medesima porzione di memoria, utilizzata
anche per scopi di comunicazione e sincronizzazione;

Sistemi Loosely Coupled, si differenziano dai precedenti per il
fatto che ognuno dei nodi utilizza e gestisce autonomamente la
propria memoria principale e lo scambio di informazioni tra i
processi avviene mediante una tecnica denominata di ―Message
Passing‖.
La specializzazione che rivestono i diversi nodi all’interno del cluster,
classifica ulteriormente un sistema distribuito, consentendo di
individuare dei modelli che meglio definiscono la tipologia di
soluzione adottata.
Fanno parte della categoria Tightly Coupled i sistemi definibili
come minicomputer che in realtà non sono altro che sistemi dotati di un
certo numero di processori che condividono le stesse risorse
centralizzate mantenendo al contempo caratteristiche di scalabilità e
modularità. La sincronizzazione delle operazioni e lo scambio di
messaggi tra di essi avviene utilizzando aree della memoria principale
ed ogni operazione d’inserimento dati e consultazione viene realizzata
utilizzando appositi terminali oppure workstation.
Nella categoria Loosely Coupled possiamo individuare i seguenti
modelli [3]:
4

workstation model: comprendono quei sistemi caratterizzati
dalla presenza di un insieme di workstation che gestiscono
autonomamente le proprie risorse e che sono dotate sia di un
sistema di gestione dei processi locali, sia di un sistema per la
gestione dei processi remoti in grado di spostare i processi sui
nodi meno carichi;

workstation-server model: è un modello caratterizzato dalla
flessibilità del modello workstation model, dato che anch’esso è
costituito da un gruppo di workstation interconnesse, ma eredita
anche i vantaggi del modello a minicomputer. Tale soluzione
permette l’esecuzione di operazioni generiche sulle workstation
e di operazioni particolarmente specializzate sui minicomputer
dedicati. I vantaggi forniti da questo modello possono essere di
importanza
rilevante,
quando
sono
richiesti
livelli
di
performance molto elevati, spesso infatti la scelta risulta
obbligata. Grazie a questo modello, per esempio, è possibile
centralizzare
le
risorse
di
memorizzazione
di
massa
predisponendo un minicomputer come file server, al fine di
fornire
prestazioni
eccellenti
nell’input/output
dei
dati,
semplificare la manutenzione, evitare un traffico eccessivo
nella migrazione dei processi dati ed eseguire elaborazioni
remote attraverso protocolli di tipo client-server;
5

processor pool model: è caratterizzato dalla presenza di nodi
generici non specializzati che vengono dinamicamente allocati
dal sistema di gestione delle risorse e che vengono rappresentati
esternamente con l’immagine di un sistema singolo. L’utente
che deve utilizzare le risorse di calcolo del cluster, non si
collega in modo diretto ai nodi, ma a terminali specializzati che
non fanno parte del cluster. Pertanto la percezione che ne risulta
è quella di collegarsi direttamente all’interno del sistema. Per le
sue caratteristiche di praticità ed efficacia, questo modello,
risulta essere quello più diffuso tra gli attuali cluster adibiti al
calcolo scientifico.
1.2 Sistemi Operativi tipici dei cluster
Una parte cruciale nel corretto funzionamento dei sistemi distribuiti è
svolta dal sistema operativo che deve essere in grado di consentire e
favorire le operazioni tipiche eseguite da un cluster. Si possono in tal
senso distinguere due classi di sistemi operativi per cluster denominati
Network
Operating System e Distributed Operating System. Le
differenze fra i due possono essere individuate, in particolare,
nell’immagine che l’utente percepisce dell’intero sistema [4].
6
Un Network Operating System coordina i diversi sistemi operativi
presenti su ogni nodo, demandati alla gestione delle risorse locali,
dando all’utente la possibilità di conoscere quali sono i nodi che
costituiscono il cluster, il loro stato e il nodo sul quale eseguire la
computazione.
Un Distributed Operating System invece si prende in carico la
gestione dell’onere di assegnamento del lavoro ai diversi nodi del
cluster, fornendo all’utente l’immagine di un sistema unico. È evidente,
in questo caso, che i malfunzionamenti di ciascun nodo vengono
nascosti all’utente, dato che egli stesso non conosce come il sistema è
costruito.
Un sistema operativo distribuito è estremamente complesso, sia
perché deve consentire performance, scalabilità e affidabilità nella
gestione dei suoi componenti, ma anche e soprattutto per la sicurezza
che deve garantire sicurezza visto l’utilizzo contemporaneo di diversi
utenti.
La necessità di utilizzare un sistema operativo con le
caratteristiche appena esposte e nel contempo di abbattere i costi del
software, ha fatto si che il sistema operativo GNU/Linux2 giocasse un
2
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ò costituire 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.
7
ruolo chiave per la definizione e l’implementazione di modelli di
clustering.
GNU/Linux è un sistema UNIX-Like notoriamente orientato alle
reti e che ha come vantaggio non trascurabile, oltre alla stabilità e
l’efficienza tipica di tutti i sistemi *NIX, il fatto di essere
completamente open-source e quindi generalmente gratuito.
È evidente come la caratteristica open-source di tali prodotti sia
garanzia di trasparenza e stabilità, per il fatto che chiunque può
analizzare, modificare e correggere il codice sorgente.
1.3 Tipologie di cluster
Un cluster può, in generale, essere visto come un insieme di nodi
ognuno dei quali è un fornitore di servizi per tutto l’insieme.
All’interno del cluster si avranno quindi diverse tipologie di nodi
con specifici compiti per la collettività come File Server, Batch Server,
Tape Server o nodi che offrono servizi specializzati come NIS, DNS,
Web, Mail, FTP e così via.
Per passare da un insieme di sistemi interconnessi ad un cluster
sono necessari almeno tre elementi:

un meccanismo di condivisione delle informazioni
amministrative;
8

un’architettura con forte centralizzazione delle immagini di
sistema (auspicabile ma non essenziale);

un meccanismo di gestione della schedulazione di richieste
delle risorse.
Quest’ultimo punto (insieme alla distribuzione sui vari nodi di tali
richieste) è il primo valore aggiunto che deve essere previsto dopo lo
startup iniziale.
Ovviamente la topologia del cluster e soprattutto la sua architettura
vanno selezionate in base alle diverse esigenze degli utilizzatori ed al
particolare contesto in cui si viene ad operare.
Mentre un responsabile IT (Information Technology) potrebbe
essere interessato al mantenimento della massima affidabilità dei propri
server o alla diminuzione del tempo generale di esecuzione delle
applicazioni e dei servizi di punta della sua organizzazione, un fisico
delle alte energie potrebbe essere interessato alla simulazione su larga
scala o alla disponibilità di enormi quantità di dati sperimentali
fisicamente distribuiti suWAN.
In definitiva la distinzione fondamentale sulle tipologie di cluster è
legata essenzialmente alle finalità cui il cluster è destinato, si possono
quindi individuare almeno quattro categorie distinte [5]:

cluster per l’affidabilità dei servizi;

cluster per l’alta disponibilità dei servizi (High Avaiability
oppure HA)
9

cluster per il bilanciamento del carico (Load Balancing
oppure LB);

cluster per il calcolo parallelo.
Cluster per l’affidabilità dei servizi
Tale soluzione prevede la predisposizione di un insieme di sistemi che
devono mantenere copie separate dei servizi e che rispondono
comunque ad un unico nome host virtuale con il quale i client
interrogano il singolo servizio.
Essenzialmente, avendo a disposizione un cluster con forte
centralizzazione delle immagini di sistema e di quelle applicative,
diverse tipologie di servizi di rete si prestano per far sì che ogni singolo
nodo del cluster possa, nel caso si renda necessario, diventare un nodoservizio.
Questo permette di avere una scalabilità dei servizi a costi irrisori
rispetto ad un eventuale cambio architetturale (ad esempio da low ad
high level server).
Il punto cruciale di questo modello è il servizio di virtualizzazione
dei nomi macchina a livello DNS (fino ad arrivare a criteri avanzati di
load balancing) e la gestione del carico della rete (attuabile con
l’introduzione di router in grado di effettuarne il bilanciamento del
carico).
10
Cluster per l’alta disponibilità dei servizi
Se il modello di affidabilità risponde alla domanda di scalabilità, quello
di alta disponibilità risponde alla domanda di continuità di servizio,
puntando sull’eliminazione dei punti deboli del sistema comunemente
definiti single point of failure.
Un cluster per l’alta disponibilità (HA cluster) è costituito
essenzialmente da due (o più) server gemelli, nei quali meccanismi
hardware e software permettono di far sì che se il nodo principale del
cluster HA si blocca, il nodo secondario, fino a quel momento in attesa,
si riconfiguri per apparire come il nodo principale del cluster, con
un’immagine congrua al nodo originale immediatamente prima della
sua indisponibilità (ovvero senza perdite di dati sensibili).
All’utente
finale,
attraverso
complessi
algoritmi
per
la
determinazione delle variazioni di stato dei sistemi, l’intero processo di
riconfigurazione apparirà come una breve indisponibilità temporanea
del servizio.
Tale modello è particolarmente indicato per tipologie di servizi
come File Server, Web Server o Database Server.
Cluster per il bilanciamento del carico
Un load balancing cluster può essere un incomparabile strumento di
produttività. L’idea (che estende il modello di affidabilità) è quella di
introdurre un sotto-sistema di schedulazione delle richieste applicative,
11
ad esempio un sistema di code che sia in grado di reindirizzare la
richiesta sul nodo più scarico, in grado di far fronte alla richiesta
utente.
I sotto-sistemi di questo tipo solitamente sono dotati di vari
strumenti amministrativi che permettono un controllo molto fine
sull’utilizzo delle risorse e che consentono un monitoraggio avanzato
dello stato del cluster.
L’asintoto attuale di questo modello è rappresentato dalla
possibilità di includere a livello kernel i meccanismi di schedulazione,
la gestione dello spazio globale delle risorse (file system e processi) e la
gestione delle politiche di bilanciamento del carico e della migrazione
dei processi.
Cluster per il calcolo parallelo
La ragione principale per cui molti sforzi si sono concentrati verso lo
sviluppo di architetture cluster per il calcolo parallelo basate su PC
sono i costi.
In questo modo, invece di rincorrere a colpi di milioni di dollari
l’ultimo supercomputer in grado di far fronte alle sempre maggiori
richieste di TeraFlops (trilioni di operazioni in virgola mobile per
secondo), si è sempre più affermata l’idea di assemblare grandi
quantità di processori classe PC con una struttura di comunicazione a
banda larga e bassa latenza, appositamente progettata.
12
Per mantenere tali caratteristiche a volte viene utilizzato un
protocollo di rete diverso dal TCP/IP (come ad esempio Myrinet), che
contiene
troppo
overhead
rispetto
alle
limitate
esigenze
di
indirizzamento, routing, e controllo nell’ambito di una rete di cui i nodi
siano ben noti a priori.
In alcuni casi viene utilizzato un meccanismo di Direct Memory
Access (DMA) fra i nodi, fornendo una sorta di distribuited shared
memory che può essere acceduta direttamente da ogni processore su
ogni nodo.
È previsto, inoltre, un livello di comunicazione a scambio di
messaggi (message passing) per la sincronizzazione dei nodi, le cui
implementazioni più diffuse sono rappresentate da MPI (Message
Passing Interface), OpenMP (Open Message Passing) e PVM
(Parallel Virtual Machine).
MPI è una API (Application Program Interface) per gli
sviluppatori di programmi paralleli che garantisce una piena astrazione
dell’hardware correntemente utilizzato senza alcuna necessità di
inserire nel codice del programma alcuna direttiva di effettiva
distribuzione dei segmenti di codice fra i nodi del cluster garantendo,
fra l’altro, una buona portabilità del codice prodotto.
PVM permette ad un insieme di computer di essere visto come una
singola macchina parallela; la Parallel Virtual Machine è composta da
13
due entità principali: il processo PVM daemon su ogni processore e
l’insieme delle routine che ne forniscono il controllo [6].
14
————————————————————————— L’ALTA DISPONIBILITÀ
Capitolo 2
2 L’alta disponibilità
Nel corso del capitolo si cercherà di chiarire in profondità il concetto di
alta disponibilità. Si tenga presente che lo scopo di un sistema in High
Avaiability, o in sintesi HA, è nella pratica quello di fornire la capacità
di fault tolerance3 all’erogazione di un servizio.
Tale funzionalità può ritenersi cruciale ed indispensabile per
servizi di particolare importanza ma, grazie ad un progressivo
abbattimento dei costi di realizzazione derivati dall’utilizzo di
hardware ad ampia diffusione in congiunzione con la nascita di
software open-source e gratuito, si può scegliere di dotare di tale
funzionalità anche servizi che non sono particolarmente critici.
3
Con il termine fault tolerance (letteralmente ―tolleranza ai guasti‖) si intende la
capacità di un sistema di non subire fallimenti ovvero interruzioni di servizio, anche
in presenza di guasti. È importante notare che la tolleranza ai guasti non garantisce
l’immunità da tutti i guasti, ma solo che i guasti per cui è stata progettata una
determinata protezione non causino fallimenti.
15
2.1 Livelli di disponibilità
La disponibilità di un servizio può essere definita come una serie
stratificata di livelli concentrici, ed ognuno dei quali include il
precedente e lo estende con nuove funzionalità, essi possono essere
schematizzati nel seguente modo [7]:

Livello 1: Disponibilità normale. Rappresenta il livello
minimo di disponibilità. L’unica protezione contro eventuali
interruzioni nell’erogazione del servizio è il backup dei dati,
eseguito secondo una politica decisa e posta in essere
dall’amministratore di sistema. Risulta evidente che in caso di
guasto con il successivo ripristino del sistema e delle
informazioni gestite, potrebbe essere possibile ottenere solo
parte dei dati, che risulterebbero così aggiornati in modo
incompleto (in funzione della frequenza con cui vengono
eseguiti e conservati i backup). È altresì ovvio che l’erogazione
del
servizio
potrà
essere
ripresa
solamente
quando
l’amministratore avrà completato il restore dell’intero sistema e
riterrà sicuro e opportuno riprendere l’erogazione del servizio
agli utenti. Il tempo di ripresa dell’attività è pertanto
inevitabilmente legato ad un fattore umano. Attente analisi,
svolte nell’ambito di questa problematica, hanno dimostrato che
in situazioni critiche, quali il ripristino di un sistema
16
informativo, l’incidenza dell’errore umano aumenta in modo
esponenziale, dilatando ulteriormente i tempi potenziali per la
ripresa del servizio.

Livello 2: Media disponibilità con protezione dei dati.
Lo scopo di un sistema, in grado di garantire questo livello di
disponibilità, è quello di garantire un miglior livello di
aggiornamento dei dati anche in caso di guasto di uno o più
dischi (in funzione del tipo di tecnologia utilizzata).
Tale obiettivo è raggiunto attraverso la replicazione fisica dei
dati memorizzati sui dischi attraverso una tecnologia definita
RAID4. Anche in questa situazione, come in quella presentata
precedentemente, è possibile mantenere i dati aggiornati anche
nell’eventualità di danni lievi ai dispositivi di memorizzazione
di massa in uso. Tuttavia la ripresa dell’erogazione piena del
servizio dipenderà comunque, seppure in modo minore, dalla
disponibilità
dell’amministratore
di
sistema
che
dovrà
intervenire manualmente per riportare la funzionalità allo stato
normale.

Livello 3: Alta disponibilità con protezione del sistema.
Questo livello garantisce la protezione del sistema e
l’erogazione dei servizi ad esso collegati, anche in caso di
guasto di una porzione particolarmente significativa del
17
sistema. Risulta evidente come questo livello rappresenti un
notevole salto di qualità rispetto ai quelli appena presentati. In
soluzioni di questo tipo non si è più dipendenti dal livello di
disponibilità dell’amministratore di sistema e soprattutto la
ripresa dell’erogazione del servizio non è più vincolata ad
eventuali errori umani. Un sistema implementato secondo
queste specifiche è costituito da un cluster di almeno due nodi,
configurati in modo che il secondo intervenga automaticamente
prendendo il posto del primo, nel caso in cui quest’ultimo non
fosse più in grado di erogare il servizio per un evento casuale
(rottura di
un
componente hardware) oppure previsto
(manutenzione programmata del sistema).

Livello 4: Disaster Recovery con protezione del sito.
Questo
livello,
che
rappresenta
l’evoluzione
dell’alta
disponibilità, permette di mettere al riparo i dati anche da eventi
che comportino la distruzione dell’intero sito nel quale sono
fisicamente collocate le macchine. Essenzialmente, si procede
con una replicazione dell’intera infrastruttura di sistema e dei
dati in essa contenuti, in un’area dislocata geograficamente
lontano, più o meno distante in funzione del livello di fault
tolerance che si vuole ottenere.
4
RAID: Acronimo di Redundat Array of Inexpensive Disk. Sistema di sicurezza che
consente la registrazione simultanea su più memorie degli stessi dati.
18
Al fine di comprendere a fondo i motivi che impongono il ricorso
all’alta disponibilità nell’erogazione di un servizio, si riporta una
statistica redatta dall’IEEE5, che mostra le classiche cause di downtime
di un sistema di elaborazione [36][4].
15,00%
10,00%
30,00%
5,00%
40,00%
Malfunzionamenti Software
Downtime Pianificati
Persone
Hardware
Ambiente
Figura 2-1 Probabili cause di downtime.
Come si evince dal grafico, la causa principale di inattività dei sistemi
informatici è un malfunzionamento software che per sua natura è
praticamente impossibile da prevedere in quanto concerne errori di
5
IEEE: acronimo di Institute of Electrical and Electronic Engineers. Organismo
Americano che nasce nel 1963 dalla fusione di due istituzioni precedenti: l’IRE
(Institute of Radio Engineers) e l’AIEE (American Institute of Electic Engineers).
Scopo fondamentale è la promozione, lo sviluppo e l’applicazione di tecnologie e
19
programmazione che si verificano unicamente in presenza di certe
condizioni ignote a priori.
Sulla base di questa analisi risulta evidente quindi che fornire un
servizio con la probabilità che quattro volte su dieci si interrompa, non
è di certo incoraggiante. Proprio per questo motivo l’adozione di un
cluster in alta disponibilità ben configurato, può ridurre drasticamente
le percentuali indicate nel grafico, eliminando i punti deboli del sistema
definiti SPF (Single Point of Failure).
2.2 Il requisito dei cinque 9
Un sistema in alta disponibilità viene tipicamente classificato sulla base
di tre fattori:

il tempo di disponibilità del servizio;

le prestazioni complessive del sistema;

l’economicità totale del sistema implementato.
È evidente come il tempo di disponibilità del servizio sia quello che
maggiormente caratterizza un sistema ad alta disponibilità. Proprio per
questo motivo uno dei parametri presi generalmente in considerazione
è il tempo di disponibilità garantita [4] definito come il rapporto
scienze per il beneficio dell’umanità attraverso la definizione di standard
internazionali.
20
percentuale fra il tempo di erogazione effettiva del servizio ed il tempo
di osservazione.
L’obiettivo ideale di ogni sistema ad alta disponibilità è quello di
raggiungere la fatidica soglia dei ―cinque 9‖, ovvero un tempo di
erogazione effettiva del servizio pari al 99,999% del tempo totale di
osservazione.
Se prendiamo in considerazione un tempo di osservazione pari ad
un anno solare, si ricava facilmente che il tempo massimo consentito
per la sospensione del servizio è di soli 5 minuti e 15 secondi, che
equivalgono ad una media settimanale di 6 secondi. Tale valore è un
traguardo estremamente arduo da raggiungere, e sino a pochi anni fa
era raggiungibile solamente con implementazioni ad appannaggio di
grandi aziende specializzate nella creazione di sistemi ad alta
disponibilità e con grande impiego di risorse finanziarie.
Con l’affermarsi negli ultimi anni, in modo sempre più marcato,
della filosofia open-source, ed in particolare con la diffusione dei
sistemi operativi GNU/Linux, sono stati creati diversi strumenti gratuiti
per la realizzazione dell’alta disponibilità in grado di avvicinarsi alla
fatidica soglia del 99,999% di uptime del servizio.
I tempi di sospensione di un servizio, ammissibili secondo la
percentuale di erogazione del servizio stesso, sono riassunti nella
tabella seguente:
21
Percentuale Uptime
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 e 30 minuti
20 minuti, 10 secondi
99,90%
8 ore e 45 minuti
99,99%
1 minuto
99,999%
6 secondi
99,9999%
30,5 secondi
0,6 secondi
Tabella 2-1 Tempi di sospensione in base alla percentuale di erogazione.
Figura 2-2 I costi dell’alta affidabilità [43].
Per ottenere percentuali di uptime sempre più elevate, è
indispensabile analizzare nel dettaglio l’infrastruttura che si desidera
realizzare mirando all’eliminazione progressiva di ogni single point of
failure, ovvero tutti gli elementi la cui compromissione porterebbe ad
un inevitabile collasso dell’intera struttura, interrompendo pertanto
l’erogazione del servizio stesso.
22
Le possibili soluzioni a questo problema sono essenzialmente di
due tipi: si può procedere con l’introduzione della ridondanza
dell’hardware chiave del sistema, oppure si possono adottare soluzioni
clusterizzate.
L’introduzione di componenti ridondati nel sistema, sebbene
migliori il livello di disponibilità medio del servizio, non pone al riparo
da diverse tipologie di guasto ed implica, se estremizzata, un
incremento smisurato dei costi di realizzazione.
A dimostrazione di quanto esposto si prenda in considerazione la
ridondanza di componenti relativamente economici quali le schede di
rete, gli hard disk o gli alimentatori, questo può portare ad avere
considerevoli vantaggi in termini di disponibilità con un leggero
aggravio in termini finanziari pari solo al 1-2% del costo totale del
sistema. Se si cerca però di ridondare componenti chiave quali CPU,
moduli di memoria RAM o controller RAID del sistema i costi possono
lievitare fino al 200-300% del costo del sistema base.
Come si può facilmente comprendere, un sistema così configurato
diviene poco conveniente in termini economici ed induce alla ricerca di
implementazioni alternative in grado di offrire gli stessi livelli di
disponibilità a costi decisamente più ridotti.
Con il passare degli anni e con l’evoluzione delle tecniche di
programmazione sia nei software che nei sistemi operativi, si sono
creati programmi in grado di trasformare una collezione di due o più
23
personal computer in un sistema server virtuale in grado di erogare i
suoi servizi con livelli di continuità conformi alla fatidica soglia dei
cinque 9.
Tale tecnica prende il nome di clustering HA (High Avaiability) ed
attualmente è talmente diffusa da essere presente in ogni reparto
dell’Information Tecnology (IT). Aziende del calibro di Google,
Porsche, Sony, Motorola e FedEX stanno utilizzando da anni sistemi
basati sulla tecnologia Linux Virutal Server (ed in particolare LinuxHA) all’interno di diverse sezioni critiche della loro infrastruttura
informatica.
Il segreto di tale diffusione è da ricercarsi, probabilmente, nella
semplicità dell’idea che sta alla base di tale soluzione ad alta
disponibilità. Nell’implementazione più semplice si hanno due
macchine gemelle che sono in grado di erogare in modo
intercambiabile un determinato insieme di servizi e che, attraverso un
software di analisi dello stato dei servizi, sono in grado di commutare
l’erogazione del servizio stesso da un server ad un altro. In questo
modo se una delle macchine viene danneggiata mentre sta fornendo un
servizio, ad esempio a causa della rottura di un componente hardware,
il sistema automaticamente provvede a spostare l’erogazione del
servizio sul server superstite, escludendo dall’intera infrastruttura la
macchina danneggiata.
24
L’affinamento di questi passaggi ed alcune accortezze in termini di
implementazione del servizio permettono di non far percepire il guasto
all’utente che non noterà discontinuità nell’erogazione del servizio.
2.3 Le prestazioni nell’alta disponibilità
Altra caratteristica non trascurabile di un sistema in alta disponibilità
sono le prestazione complessive nell’erogazione del servizio. In base
ad alcuni studi condotti sull’argomento da diverse aziende, ed in
particolare dal Gartner Group e dalla Forresters6, si evidenzia che il
tempo di attesa tollerabile dagli utenti dopo aver effettuato la richiesta
di un servizio va dai 4 ai 20 secondo in funzione del tipo di
applicazione.
Considerando questi dati, 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 consideri inoltre 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
6
Gartner Group (www3.gartner.com), Forrester (www.forrester.com), sono enti di
ricerca e analisi che svolgono indagini sui più disparati argomenti: analisi di mercato,
analisi delle tendenze comuni e di comportamento.
25
diretti, ma anche i tempi legati all’ampiezza di banda del sistema di
comunicazione fra il client e il server, e la latenza dei dispositivi .
Inoltre deve essere 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 in contemporane. Questo
fattore impone dunque la disponibilità di potenza elaborativa che sia
adeguata e facilmente e velocemente scalabile per far fronte ad
esigenze crescenti nel futuro.
Adottando una soluzione di ridondanza dei componenti, il
problema viene risolto potenziando l’hardware a disposizione,
sostituendo e aggiornando le periferiche che costituiscono il collo di
bottiglia7 del sistema. Questo induce però un aumento dei costi di
installazione oltre che una scarsa adattabilità dell’intera infrastruttura
all’aumento del carico computazionale.
La soluzione cluster, ancora una volta, mostra di poter risolvere il
problema in modo più efficiente ed economico; infatti la scalabilità
delle prestazioni del sistema viene ottenuta aumentando il numero dei
server sui quali è distribuito il carico di lavoro oppure aggiornando i
server utilizzati [4].
7
In ambito informatico con l’espressione ―collo di bottiglia‖ si indica un componente
hardware o software di un sistema di elaborazione che condiziona il resto del sistema
a prestazioni non efficienti.
26
2.4 Tipologie di cluster in alta disponibilità
Scendendo maggiormente in dettaglio, a seguito di tutte le
considerazioni fatte fin qui, si distinguono due tipologie di cluster ad
alta disponibilità utilizzabili per l’erogazione di servizi:

Cluster Active-Standby (A-S) o Active-Active (A-A);

Cluster a bilanciamento di carico (Load Balancing cluster).
Nella tipologia di cluster Active-Standby i servizi offerti sono tutti
residenti su un solo nodo, vengono poi presi totalmente in carico
dall’altro nodo, precedentemente in standby, nel momento in cui il
nodo principale dovesse cadere.
ACTIVE
STANDBY
Web Server
Database Server
ACTIVE
Web Server
Database Server
ACTIVE
Web Server
Database Server
Figura 2-3 Cluster in configurazione Active-Standby.
27
Nel modello Active-Active i servizi sono invece distribuiti su entrambi i
nodi, i quali si compensano a vicenda nel caso uno dei due dovesse
bloccarsi, prendendo in carico il lavoro di quel nodo in difficoltà.
ACTIVE
Web Server
ACTIVE
Web Server
ACTIVE
Database Server
ACTIVE
Database Server
Web Server
Figura 2-4 Cluster in configurazione Active-Active.
Il software che realizza queste configurazioni fra i nodi è 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 eventuali indirizzi
IP e la riattivazione degli stessi sull’altro nodo. Il tutto avviene in
maniera del tutto trasparente per l’amministratore che interviene
solamente per riportare il cluster nello stato di funzionamento standard,
28
ma senza che il servizio erogato abbia subito interruzioni di qualsiasi
tipo.
Un cluster per il bilanciamento del carico è costituito, a differenza
dei precedenti, da un pool di nodi opportunamente configurati per
consentire la suddivisione dinamica e bilanciata del carico di lavoro
computazionale.
Load Balancing
LAN / WAN
Web Server 1
Web Server 3
Web Server 2
Figura 2-5 Cluster in configurazione Load Balancing.
In tale configurazione uno dei nodi assume un ruolo specializzato, in
quanto assolve alla funzione di dispatcher e ha quindi la facoltà di
ripartire tra i nodi generici il lavoro. Esso infatti è costantemente
consapevole del carico presente su ogni nodo e, in base alla politica
29
scelta per la ripartizione, distribuisce i processi da elaborare in modo
opportuno.
Il trasferimento dei pacchetti dalla macchina che funge da load
balancer agli altri nodi incaricati di una certa elaborazione può avviene
con tecniche diverse che comprendono il Direct-Redirect, il NAT
(Network Address Translation) o l’IP-Tunneling.
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 faulttolerance in quanto se uno dei nodi generici dovesse per qualunque
problema
rendersi
non
disponibile
verrebbe
automaticamente
trascurato e indirettamente verrebbe messo fuori dal cluster.
L’alta disponibilità viene realizzata completamente utilizzando per
il nodo dispatcher un cluster del tipo Active-Standby, 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 è
decisamente elevato, come può accadere per un web server aziendale.
In definitiva dunque l’architettura cluster è molto vantaggiosa per
realizzare l’alta disponibilità dei servizi erogati, è in grado di fornire
scalabilità nelle prestazioni se si utilizza la tipologia di cluster che
consente il load balancing e non ultimo risulta essere molto più
economica rispetto a soluzioni diverse che offrono le stesse
30
caratteristiche, soprattutto in considerazione del fatto che il software
che ne permette l’implementazione può essere reperito in modo
gratuito oltre che open-source.
31
—————————————————————————— LA VIRTUALIZZAZIONE
Capitolo 3
3 La virtualizzazione
Il concetto di virtualizzazione è uno dei più pervasivi e utilizzati in
informatica. In [8] la virtualizzazione viene definita come:
[…] a framework or methodology of dividing the resources of a
computer into multiple execution environments, by applying one
or more concepts or technologies such as hardware and software
partitioning,
time-sharing,
partial
or
complete
machine
simulation, emulation, quality of service, and many others.
In particolare, la virtualizzazione definisce e implementa un livello di
astrazione rispetto alle risorse del computer: questo livello di astrazione
media tra le risorse fisiche del computer e il software che le utilizza.
Questa strategia permette di creare, all’interno della stessa macchina
fisica, più ambienti di esecuzione virtuali (le macchine virtuali) che
emulano il comportamento della macchina reale sottostante, mettendo a
32
disposizione dei livelli superiori l’interfaccia esportata dall’hardware
della macchina.
Negli ultimi anni questa tecnologia è stata rivalutata, soprattutto
perché dà la possibilità di eseguire simultaneamente sulla stessa
macchina fisica diverse istanze di sistemi operativi. Ad esempio, è
possibile eseguire Linux, Windows e Solaris in concorrenza sulla stessa
macchina, sfruttando l’esistenza di diverse macchine virtuali all’interno
delle quali è possibile eseguire sistemi operativi (vedi fig. 3-1).
LINUX
CPU
MEM
WINDOWS
DISCO
MACCHINA VIRTUALE
CPU
MEM
DISCO
MACCHINA VIRTUALE
SOFTWARE DI VIRTUALIZZAZIONE
CPU
MEMORIA
DISCO
MACCHINA REALE
Figura 3-1 Esempio di virtualizzazione.
Il software di virtualizzazione è in grado di tenere traccia dello stato di
ogni sistema operativo in esecuzione nelle macchine virtuali, in maniera
simile a quella con cui un sistema operativo tradizionale tiene traccia
dello stato dei processi e, inoltre, fornisce protezione e isolamento tra le
macchine virtuali [9].
33
Non solo si hanno benefici in termini economici, per cui, ad
esempio, è possibile consolidare su una macchina fisica diversi server,
ma altresì si hanno benefici in termini di controllo centralizzato degli
ambienti virtuali. È possibile salvare lo stato delle macchine virtuali o
sospendere l’esecuzione per poi ripristinarla successivamente, oppure si
può migrare una macchina virtuale tra diverse macchine fisiche.
3.1 Concetti generali
Le prime macchine virtuali furono implementate negli anni sessanta dalla
IBM con lo scopo di creare più ambienti di lavoro su un unico
calcolatore. Ogni macchina virtuale era una copia del sistema ospitante.
Istanziando più macchine virtuali si avevano a disposizione diversi
calcolatori (virtuali) pronti all’uso. L’obiettivo di questo meccanismo era
ottimizzare l’utilizzo del calcolatore reale (all’epoca molto oneroso)
permettendo allo stesso tempo il suo utilizzo da parte di più utenti in
contemporanea. Le risorse del calcolatore venivano condivise fra gli
ambienti virtuali creati attraverso una forma di multiplazione temporale
simile a quella che avviene nei moderni sistemi operativi tra i processi
(vedi fig. 3.2).
Esistono anche altri tipi di macchine virtuali che non sono incentrate
sull’utilizzo condiviso di un calcolatore. Esse hanno lo scopo di
34
effettuare il porting, cioè l’adattamento, di applicazioni e sistemi
operativi tra calcolatori con architetture diverse.
Sistema
Operativo
1
Sistema
Operativo
2
Sistema
Operativo
3
Sistema
Operativo
1
Sistema
Operativo
2
t
Figura 3-2 Multiplazione temporale negli ambienti virtuali degli anni sessanta.
Ogni architettura hardware risponde a determinate specifiche descritte
dalle ISA (Instruction Set Architecture) che possiamo descrivere come
l’interfaccia di presentazione dell’architettura verso i propri utilizzatori. I
sistemi operativi e le applicazioni che devono lavorare con una
determinata architettura conoscono e rispettano solo quella determinata
ISA. Questo rende praticamente impossibile la portabilità dei sistemi
operativi fra le diverse architetture [10].
Per ovviare a questo problema esistono quindi particolari macchine
virtuali in grado di imitare architetture diverse da quella del sistema
operativo. Interponendo queste macchine virtuali fra il calcolatore
ospitante ed il sistema operativo impossibilitato a girare su tale
architettura si crea una nuova interfaccia in grado di tradurre le istruzioni
tra le due ISA.
Riepilogando, esistono due grandi famiglie di macchine virtuali con
obiettivi ben diversi:
35

Condivisione delle risorse hardware di un calcolatore;

Emulazione di architetture hardware diverse da quelle in
possesso.
In generale un obiettivo esclude l’altro poiché, come sarà possibile
vedere, emulare totalmente una architettura diversa è molto dispendioso
eliminando di fatto la possibilità di prevedere altre macchine virtuali
istanziate contemporaneamente. Allo stesso modo, la ricerca di
prestazioni elevate in modo da poter avviare simultaneamente più
macchine virtuali implica l’introduzione di macchine virtuali che
emulano solo in parte un calcolatore fisico, che di conseguenza devono
essere simili.
3.2 Aspetti fondamentali
La progettazione di un sistema complesso è facilitata da un approccio a
livelli di astrazione. In questo modo è possibile progettare una parte del
sistema senza considerare i dettagli delle altre parti. Ogni livello di
astrazione è rappresentato ai livelli superiori attraverso una interfaccia
che ne rappresenta il funzionamento senza scendere nei dettagli
implementativi e costrutti del livello, si può pertanto dividere la struttura
di un calcolatore in tre livelli di astrazione (vedi fig. 3.3).
36
Applicazione Utente
Applicazione Utente
API
Sistema Operativo
ISA
Hardware
Figura 3-3 Schema a livelli della struttura di un calcolatore senza virtual machine.
Il livello hardware comprende la parte fisica del calcolatore (CPU,
memoria, dispositivi di I/O, ecc…). Esso viene interfacciato ai livelli
superiori attraverso le ISA (Instruction Set Architecture) cioè un insieme
di istruzioni macchina proprie di una architettura con cui è possibile
interagire con il livello hardware stesso.
I livelli successivi sono di tipo software ovvero non hanno nessun
tipo di rappresentazione tangibile. Il primo di questi è il sistema
operativo che possiamo definire come l’applicazione che sta a più vicino
contatto con il livello hardware e che permette il funzionamento di tutte
le applicazioni. Il sistema operativo interagisce con il livello hardware
attraverso le istruzioni che fanno parte dell’ISA relativa all’hardware del
calcolatore. L’interfaccia superiore del sistema operativo è detta API
(Application Programming Interface) che è un insieme di regole e
metodologie che i livelli superiori devono utilizzare per interagire con le
librerie del sistema operativo.
37
L’ultimo livello di astrazione è quello delle applicazioni utente che
rappresenta tutti i programmi (processi) che interagiscono direttamente
con l’utilizzatore del calcolatore attraverso l’interfaccia grafica o altri
metodi di input e output.
La virtualizzazione di un sistema operativo comporta l’introduzione
di un nuovo livello posto tra l’hardware e il sistema operativo. Il nuovo
livello viene chiamato Virtual Machine Monitor o Hypervisor (vedi fig.
3.4). Ha il compito di fornire delle repliche del sistema hardware del
calcolatore attraverso la suddivisione temporale delle risorse. Si può
infatti affermare che il cuore, l’elemento chiave della virtualizzazione è
proprio il virtual machine monitor (VMM). La sua attività principale è il
controllo, da effettuare in modo trasparente, sulle istanze virtuali di
sistema da esso create. Ogni istanza virtuale prende il nome di virtual
machine o domain.
Dominio 1
Applicazione
Utente
Dominio 2
Applicazione
Utente
Applicazione Utente
Sistema Operativo
Sistema Operativo
Virtual Machine Monitor
Hardware
Figura 3-4 Schema di un calcolatore dotato di macchine virtuali.
38
I livelli che si trovano al di sopra della virtualizzazione prendono il
nome di sistemi ospiti (Guest Systems) mentre i livelli su cui si appoggia
il virtual machine monitor sono chiamati sistemi ospitanti (Host
Systems).
Le CPU attualmente in commercio prevedono almeno due modalità
di funzionamento: una privilegiata (identificata con diversi nomi: kernel
mode, monitor mode, supervisor mode oppure system mode) in cui è
possibile invocare qualsiasi istruzione macchina e una modalità utente
(user mode) in cui, per questioni di sicurezza e protezione dell’hardware,
è possibile invocare solo alcune istruzioni macchina, generalmente quelle
ritenute non pericolose. In un sistema privo di macchine virtuali le
applicazioni lavorano in modalità utente e il sistema operativo (o parte di
esso: il kernel) lavora in modalità privilegiata. È possibile vedere le due
modalità come due livelli gerarchici, infatti, le applicazioni che lavorano
in user mode non possono in alcun modo influire sul sistema operativo
che lavora in modo privilegiato; viceversa, il sistema operativo riesce a
controllare l’attività delle applicazioni grazie alla possibilità di lavorare
in modalità privilegiata. Lo scheduling dei processi, ad esempio, avviene
in modalità privilegiata, in questo modo, nessuna applicazione (processo)
che sta lavorando in modalità utente può impedire il cambio di contesto e
di processo.
In un’architettura basata su macchine virtuali, il virtual machine
monitor deve appartenere ad un livello gerarchico più alto di quello dei
39
sistemi operativi, poiché deve avere il controllo su di loro . La maggior
parte delle CPU prevede due soli livelli8 e dunque, se il VMM lavora
nella modalità privilegiata, i sistemi operativi devono forzatamente
utilizzare solo la modalità utente come le applicazioni che vi girano.
3.3 Requisiti di una macchina virtuale
Il virtual machine monitor deve in generale rispondere ai seguenti
requisiti [10]:

Compatibilità: l’utilizzo delle macchine virtuali non deve
richiedere
modifiche
ai
livelli
superiori;
sarebbe
infatti
improponibile al mercato una macchina virtuale che richieda
modifiche agli applicativi. Per questo motivo è necessario che le
macchine virtuali imitino completamente i comportamenti della
macchina che vanno a virtualizzare;

Performance: l’introduzione di un livello tra il sistema operativo
e l’hardware comporta l’introduzione di un certo overhead9. Il
raggiungimento di performance simili a quelle di una macchina
8
In realtà l’architettura x86 a 32 bit e a 64 bit prevedono quattro modalità di
funzionamento ma i sistemi operativi moderni utilizzano solo le due poste agli estremi.
9
Con il termine overhead si intende il tempo impiegato in attività accessorie
all’esecuzione di un compito. In questo caso al tempo strettamente necessario per
eseguire una certa interazione tra sistema operativo e hardware va aggiunto il tempo
speso nella gestione di questa interazione da parte del virtual machine monitor.
40
reale
copre
buona
parte
degli
studi
sull’ottimizzazione
dell’attività di virtualizzazione;

Semplicità: le macchine virtuali possono essere utilizzate per
aumentare la sicurezza e l’affidabilità dei server. Per garantire
ciò, anche il virtual machine monitor deve essere affidabile. In
generale una architettura semplice è anche caratterizzata da un
certo grado di affidabilità e robustezza;

Isolamento: ogni macchina virtuale deve essere isolata da ogni
altra, quindi sia da attacchi accidentali che malintenzionati. Non
deve essere possibile consentire che una macchina virtuale
interferisca con un’altra macchina e che siano violati i
meccanismi di protezione implementati dal VMM.
3.4 Virtual Machine Monitor (VMM)
Il Virtual Machine Monitor (VMM) anche definito Hypervisor è il
software vero e proprio che permette l’esecuzione multipla di sistemi
operativi, sullo stesso computer e nello stesso momento.
Il VMM è il componente primario della virtualizzazione che abilita
la suddivisione delle risorse base di un PC, come ad esempio il
partizionamento della CPU, della memoria e dell’I/O. Con l’evolversi
delle tecnologie di virtualizzazione ed il miglioramento dell’hardware, le
41
funzionalità base del VMM possono risiedere in uno strato software a sé
stante, che può trovarsi direttamente sull’hardware della macchina
oppure essere implementato in una parte del sistema operativo.
3.4.1 Full virtualization e paravirtualization
Esiste una distinzione tra le tipologie di virtualizzazione che vengono
fornite. Si ha virtualizzazione completa (full virtualization) quando un
sistema operativo può essere eseguito nella macchina virtuale creata
dall’hypervisor senza che sia necessario modificare il codice. Invece, nel
caso della paravirtualizzazione (paravirtualization) sono necessarie
alcune modifiche al codice del sistema operativo per ―portarlo‖, cioè per
permettergli di essere eseguito da una macchina virtuale.
In questo ultimo caso, il VMM presenta un’interfaccia di astrazione,
tramite la macchina virtuale, non uguale ma simile all’interfaccia
esportata dall’hardware sottostante. Sono quindi necessarie delle
modifiche al codice del sistema operativo, ma non alle applicazioni che
vengono eseguite sul sistema operativo.
Uno dei vantaggi della paravirtualizzazione è una performance
migliore. Infatti, non è necessario effettuare la traduzione dinamica delle
istruzioni. Uno svantaggio, invece, è che il numero di sistemi operativi
che possono essere eseguiti con questa tecnologia è minore, in quanto
42
possono essere eseguiti nelle macchine virtuali, solo quei sistemi
operativi dei quali è possibile modificare il codice.
3.4.2 Binary translation e dynamic recompilation
Tra le varie tecniche utilizzate per implementare la virtualizzazione
completa è possibile citare quella della binary translation, tra gli altri
utilizzata da VMware [11] e da Virtual PC della Microsoft [12]. Questa
tecnica prevede una traduzione a tempo di esecuzione del codice
destinato all’architettura hardware. In pratica, visto che il codice del
sistema operativo non viene modificato, tutte le parti di codice che
contengono operazioni privilegiate, e che quindi richiedono l’intervento
del VMM, devono essere interpretate a tempo di esecuzione per inserivi
un
trap
al
VM.
Questa
soluzione,
rispetto
a
quella
della
paravirtualizzazione, ha però un overhead più elevato.
Un’altra tecnica per implementare la virtualizzazione completa è la
dynamic recompilation. Questo termine viene usato per indicare il fatto
che un sistema operativo, progettato per essere eseguito su una
particolare classe di CPU e quindi con un determinato linguaggio
macchina, viene eseguito da una macchina virtuale che emula un altro
tipo di CPU, con un differente insieme di istruzioni. Di conseguenza, a
tempo di esecuzione parti di codice vengono ricompilate per essere
43
eseguite sulla nuova architettura. È un esempio pratico di questa filosofia
PearPC [13] che permette l’esecuzione di MacOS, noto sistema per
processori PowerPC su macchine con architettura x86.
Nella binary translation esiste il classico ciclo di prelievo-decodificaesecuzione dell’istruzione, e quindi ogni istruzione viene emulata per la
nuova architettura. Nel caso della dinamyc recompilation, invece,
durante l’esecuzione vengono riscritte in blocco sezioni di codice, ad
esempio la prima volta che si entra in una determinata sezione di codice.
Successivamente, se le stesse istruzioni dovessero essere rieseguite, si
utilizzerà nuovamente la sezione ricompilata. Un’altra differenza è
dovuta al fatto che, nel caso della binary translation le istruzioni vengono
eseguite direttamente dalle macchine virtuali e non vengono tradotte,
invece, nel caso della dynamic recompilation tutte le istruzioni devono
essere emulate.
3.4.3 Struttura interna dell’hypervisor
La struttura centrale del Virtual Machine Monitor (VMM), è la parte che
esegue la virtualizzazione vera e propria, può essere suddivisa in tre
moduli che gestiscono la virtualizzazione (o in alcuni casi l’emulazione)
della CPU, della memoria e delle periferiche di input e di output.
44
Nei prossimi paragrafi verranno descritte nel dettaglio le
implementazioni di ognuno di questi moduli [10].
Macchina Virtuale
Macchina Virtuale
Sistema Operativo
Sistema Operativo
CPU
Virtuale
Memoria
Virtualizzata
Periferiche
Virtuali
CPU
Virtuale
Memoria
Virtualizzata
Periferiche
Virtuali
Virtual Machine Monitor
Macchina Reale
CPU
Periferiche
I/O
Memoria
Figura 3-5 Struttura del Virtual Machine Monitor.
3.4.3.1
Virtualizzazione della CPU
La gran parte dei microprocessori presenti nei calcolatori moderni
presentano un istruction set (l’insieme delle istruzioni macchina con cui
vengono scritti i programmi) non adatto alla virtualizzazione. La
virtualizzazione
della
CPU
passa
attraverso
la
risoluzione
o
l’aggiramento di questo problema.
MODALITÀ DI FUNZIONAMENTO DELLA CPU
La famiglia di CPU x86 presenta due soli modi di funzionamento che in
un sistema non virtualizzato sono assegnati al sistema operativo e alle
applicazioni. Il virtual machine monitor deve però utilizzare un modo di
funzionamento più privilegiato rispetto a quello del sistema operativo.
45
Per questo motivo si sceglie di assegnare al virtual machine monitor il
livello privilegiato mentre sistema operativo e applicazioni girano in
modalità utente. In questo modo l’hypervisor riesce a mantenere il
controllo della CPU.
Eseguendo il sistema operativo in modalità utente, le istruzioni
privilegiate che esso tenta di eseguire sono facilmente catturate dal
virtual machine monitor: la CPU reale infatti, lancia delle eccezioni
(traps) quando si trova in modalità utente e deve eseguire una istruzione
privilegiata. È sufficiente implementare un sistema in grado di percepire
quando le eccezioni vengono lanciate (dispatcher), capire quale
istruzione l’ha generata (allocator) ed eseguire una istruzione alternativa
(interpreter). L’interpreter può eseguire la stessa istruzione in modalità
privilegiata, oppure scegliere di eseguire una istruzione equivalente che
produce gli stessi effetti. Il VMM deve quindi implementare questi tre
moduli per eseguire la virtualizzazione della CPU (vedi fig. 3.6).
ISTRUZIONI “SENSITIVE”
Un ulteriore problema è rappresentato dalle sensitive instructions cioè
quelle istruzioni che interferiscono con lo stato della VMM o delle altre
macchine virtuali eventualmente istanziate dal virutal machine monitor.
Se queste istruzioni sono tutte privilegiate allora la complessità
dell’hypervisor non aumenta poiché vengono riconosciute grazie alle
eccezioni della CPU ed in questo caso la CPU stessa viene definita
virtualizzabile.
46
Sistema operativo ospitato
Istruzione
Privilegiata
Dispatcher delle eccezioni
Allocator
Interpreter
Eccezione
(trap)
Istruzione
Alternativa
Output
dell’istruzione
Microprocessore reale
tempo
Figura 3-6 Intercettazione delle eccezioni del dispatcher.
Purtroppo il progetto delle attuali CPU non ha tenuto conto delle
esigenze di una possibile virtualizzazione. Nelle CPU della famiglia x86
esistono delle istruzioni sensitive non privilegiate che non possono essere
catturate dall’hypervisor e di conseguenza la CPU non rilascia eccezioni
nel caso si verifichino. Per questo motivo deve esistere un sistema che
permetta il riconoscimento delle istruzioni sensitive non privilegiate
prima che vengano messe in esecuzione. Questo sistema si fonda sulla
traduzione binaria dinamica che permette di tradurre al volo le istruzioni
sensitive non privilegiate sostituendole con altre non pericolose.
L’implementazione di un traduttore binario dinamico necessità però di
47
molte risorse ed aumenta notevolmente la complessità del VMM. Le
istruzioni tradotte vengono poi memorizzate in una memoria cache in
modo da evitare inutili traduzioni successive.
Per diminuire l’inevitabile overhead introdotto dal traduttore binario
dinamico vengono di norma implementate funzioni di ottimizzazione
dinamica del codice.
SCHEDULING DELLE CPU VIRTUALI
Più macchine virtuali che lavorano contemporaneamente, necessitano di
più CPU virtuali che lavorano a turno sul processore reale del
calcolatore.
Deve quindi esistere un algoritmo di scheduling delle macchine
virtuali, generalmente basato sul round robin: ad ogni macchina virtuale
viene concesso, a turno, l’utilizzo delle risorse reali per un quanto di
tempo prestabilito. Quando una macchina virtuale termina la sua
porzione di tempo deve ―congelarsi‖ e attendere che le venga assegnato il
nuovo turno. La CPU virtuale deve quindi avvalersi di una struttura dati
in memoria sui cui possa memorizzare lo stato della sua CPU reale
(registri, translation look-aside buffer, ecc…) in ogni transizione tra le
macchine virtuali. Questi dati verranno poi ricaricati sulla CPU reale
quando la machina virtuale entrerà in un nuovo quanto di tempo ad essa
dedicato.
48
3.4.3.2
Virtualizzazione della memoria
La memoria di un calcolatore classico è formata da una sequenza di celle
elementari su cui è possibile scrivere e leggere dati. Ad ogni cella è
assegnato un indirizzo che viene chiamato fisico perché è effettivamente
quello che indica la posizione della cella nell’implementazione hardware
della memoria. Per migliorare e facilitare la gestione della memoria
centrale da parte della CPU ad ogni cella è assegnato almeno un indirizzo
logico. Poiché la CPU e il sistema operativo utilizzano i soli indirizzi
logici, deve esistere un’unità che effettui la conversione e il controllo
sulla validità degli indirizzi: la Memory Management Unit (MMU).
La gestione di grosse quantità di memoria necessita di un sistema di
indirizzamento basato su elementi di memoria di capacità maggiore
rispetto alle celle. Questi elementi, che a loro volta saranno formati da un
numero
prestabilito
di
celle,
sono
chiamati
pagine
(pages).
Analogamente a quello che succede per le celle, anche in questo caso si
hanno pagine logiche (spesso chiamate semplicemente pagine) e pagine
fisiche chiamate normalmente frames.
Le corrispondenze tra pagine e frames sono mantenute dalla page
table (letteralmente tabella delle pagine). In questa situazione l’algoritmo
di indirizzamento della memoria svolto dalla memory management unit
prevede l’indirizzamento della pagina (logica) e della cella (in termini di
offset rispetto all’inizio della pagina) e la conversione della parte di
49
indirizzo riferito alla pagina tramite un accesso alla page table da cui si
ottiene l’indirizzo del frame.
Il tempo impiegato nella conversione tra gli indirizzi di pagine e
frames dipende dalla dimensione della page table e dal tempo impiegato
per scorrerla. Per questo motivo parte della page table viene memorizzata
in una memoria ad accesso veloce chiamata generalmente cache memory
e che nello specifico viene denominata Translation lookaside buffer
(TLB). Esistono diversi tipi di TLB che sono più o meno adatti alla
virtualizzazione, tra i più funzionali c’è il TLB di tipo tagged in cui oltre
agli indirizzi di pagine e frames viene memorizzato un indicatore con il
processo proprietario della pagina. Questa importante caratteristica può
essere sfruttata per discriminare fra le pagine appartenenti a macchine
virtuali diverse. La virtualizzazione è notevolmente agevolata quando la
TLB viene gestita dal sistema operativo e quindi dal virtual machine
monitor nel caso di un sistema virtualizzato. Purtroppo l’architettura x86
non risponde a nessuna delle due caratteristiche elencate e quindi, la
virtualizzazione di questa architettura è correlata a diverse complicazioni.
Virtualizzare la memoria significa condividere in modo sicuro la
memoria centrale del calcolatore e creare una rappresentazione virtuale
di questo complesso sistema di indirizzamento e di tutti gli altri dettagli,
quali caching della page table e gestione della memoria.
La memoria centrale del calcolatore viene quindi suddivisa in parti,
ciascuna delle quali assegnata in esclusiva ad una macchina virtuale.
50
Ogni sistema operativo ospitato costruisce e gestisce una propria page
table che servirà come riferimento alla memory management unit e al
translation look-aside buffer per eseguire le conversioni fra gli indirizzi.
L’architettura x86 ha MMU e TLB di tipo hardware che quindi non
possono essere gestiti dai sistemi operativi ospitati e nemmeno dal
VMM.
La page table di ogni sistema operativo ospitato traduce gli indirizzi
delle pagine in indirizzi di frames che vengono calcolati come se la
macchina virtuale avesse a disposizione l’intero banco di memoria del
calcolatore reale. Per ovviare a questo problema è necessario introdurre
una nuova tabella che traduce gli indirizzi dei frames virtuali in indirizzi
di frames reali effettivamente residenti nella memoria reale.
Questa struttura dati, unica per ogni macchina virtuale, viene detta
pmap ed anche in questo caso la virtualizzazione introduce un passaggio
in più che genera overhead. Infatti, MMU e TLB dovrebbero effettuare il
doppio degli accessi in memoria per tradurre un indirizzo. Per evitare ciò,
il VMM si occupa allora del mantenimento di un’altra tabella delle
pagine trasparente alle macchine virtuali che per questo è definita
shadow (letteralmente ombra). La shadow page table mantiene la
corrispondenza tra le pagine di ogni macchina virtuale e i frames reali. È
quindi necessaria l’implementazione di un algoritmo che mantenga
coerentemente il contenuto della shadow page table con i contenuti della
coppia formata da page table e pmap. È necessario poi che il virtual
51
machine monitor catturi ogni istruzione di indirizzamento che utilizzi le
page tables virtuali e le sostituisca con nuove istruzioni che dicano al
MMU di utilizzare la shadow page table come riferimento per la
conversione degli indirizzi.
L’utilizzo della shadow page table permette anche lo spostamento al
volo delle locazioni di memoria utilizzate da una macchina virtuale senza
dover modificare la page table della macchina stessa, è sufficiente
modificare il pmap corrispondente e la shadow page table.
Page
Table1
Page
Table1
Indirizzo del
frame virtuale
Pmap1
Indirizzo
del frame reale
Memoria centrale
del calcolatore
Pmap2
Shadow
page table
Figura 3-7 Sistema di indirizzamento della memoria nel VMM.
52
CONDIVISIONE DELLA MEMORIA
Risparmiare memoria è fondamentale per un virtual machine monitor,
per cui, quando è possibile si tende a condividere locazioni di memoria
fra diverse macchine virtuali. Soprattutto nel caso delle sue applicazioni
in ambito server, il VMM si trova ad istanziare numerose macchine
virtuali su cui viene eseguito lo stesso sistema operativo. Una parte delle
informazioni immagazzinate in memoria centrale dai sistemi operativi
ospitati sono di sola lettura come, ad esempio, alcune parti del kernel del
sistema stesso. Esistono alcuni algoritmi di riconoscimento di pagine
simili basati sul controllo di una chiave (hash) assegnata ad ogni pagina
che ne riassume il contenuto. Nel caso il virtual machine monitor
individui due pagine simili, modifica immediatamente la shadow page
table in modo che le pagine allocate dalle due macchine virtuali puntino
allo stesso frame.
3.4.3.3
Virtualizzazione delle periferiche
La virtualizzazione dei dispositivi di input e di output di un calcolatore è
particolarmente complessa a causa della eterogeneità dei dispositivi
stessi. È infatti impossibile definire un unico livello di astrazione per tutti
i tipi dispositivi.
53
Nelle prime applicazioni della virtualizzazione, i sistemi IBM
prevedevano dei canali asincroni di comunicazione attraverso i quali il
sistema virtuale poteva interagire con la periferica senza introdurre
fastidiosi overheads. Con questo sistema non era necessario nessun tipo
di interazione con il virtual machine monitor durante la comunicazione
con le periferiche. Questo sistema non è più applicabile a causa
dell’enorme eterogeneità delle periferiche che vengono utilizzate
soprattutto nei sistemi desktop.
I VMM utilizzati nelle varie applicazioni comunicano con le
periferiche effettuando appropriate system calls sul sistema operativo
ospitante. La struttura del virtual machine monitor risulta in questo modo
molto semplice poiché viene progettato tenendo conto delle sole API del
sistema operativo. Questa modalità purtroppo introduce delle latenze
nell’interazione con le periferiche poiché, in ogni caso, la comunicazione
tra macchina virtuale e periferica reale deve passare attraverso il
controllo effettuato dall’hypervisor e dal sistema operativo host.
In ambito server, dove l’eterogeneità delle periferiche è trascurabile
rispetto alla necessità di avere un ridottissimo overhead, le periferiche
vengono virtualizzate attraverso interfacce semplificate che comportano
un elevato grado di semplicità di progettazione e di portabilità delle
macchine virtuali stesse. La gestione della comunicazione tra macchine
virtuali e periferiche reali passa comunque attraverso il virtual machine
monitor.
54
Alcuni hypervisor hanno inoltre la possibilità di virtualizzare una
periferica non presente nel calcolatore reale. In questo caso si parla di
―emulazione di una periferica‖. Come è già stato specificato più volte,
emulare qualcosa significa, imitarne il comportamento. È infatti possibile
creare una emulazione di periferica SCSI quando esse non sono presenti
o emulare porte seriali e parallele oppure, soprattutto nel caso di console
giocattolo, tutto l’hardware che sta attorno alla CPU.
3.5 Benefici della virtualizzazione
Come si è detto nei paragrafi precedenti, l’idea di creare una macchina
virtuale nacque all’incirca negli anni sessanta quando i calcolatori erano
molto onerosi in termini di costo e di spazio. In quella situazione era
conveniente cercare un meccanismo per riuscire ad utilizzare più sistemi
operativi (quindi più applicazioni) su una sola macchina. Con il
progredire delle tecnologie elettroniche ed informatiche i calcolatori sono
diventati sempre meno grandi, meno costosi e più potenti. Questo tipo di
progresso nell’hardware nascose le potenzialità della virtualizzazione.
Al giorno d’oggi la ricerca sulla virtualizzazione ha ripreso vigore
poiché il livello di integrazione dei moderni calcolatori è tale da
mantenere sottoutilizzati i calcolatori che svolgono attività di server.
Infatti, per questioni di sicurezza e affidabilità, si tende ad installare una
55
sola applicazione per sistema operativo e quindi una sola applicazione
per calcolatore. In questo modo se una applicazione o un sistema
operativo è sotto attacco gli altri servizi forniti non ne risentono perché
meccanicamente indipendenti. Questa tecnica, assolutamente infallibile
da un punto di vista di affidabilità mostra però problemi in termini di
risorse: sono necessari svariati calcolatori che, tenuto conto delle
potenzialità odierne, risultano sottoutilizzati ed i costi di gestione e di
spazio necessario aumentano.
Attraverso l’impiego delle macchine virtuali è possibile sostituire i
server sottoutilizzati con un unico calcolatore su cui girano diverse
istanze di macchine virtuali. Su ognuna di queste è possibile installare il
sistema operativo e l’applicazione che si utilizzava precedentemente. In
questo modo, il numero dei calcolatori diminuisce, i costi di gestione e di
spazio diminuiscono, e il rendimento del calcolatore aumenta poiché
viene sfruttato maggiormente rispetto a prima.
Anche se con questo tipo di progettazione si ha un solo calcolatore,
le macchine virtuali sono isolate ―meccanicamente‖ tra loro e quindi le
applicazioni mantengono lo stesso tipo di isolamento che avevano
girando in calcolatori reali diversi. Infatti nel caso in cui una applicazione
o un sistema operativo sia attaccato o comunque abbia problemi, sarà
eventualmente la macchina virtuale su cui gira ad avere problemi e non il
calcolatore reale.
56
L’utilizzo delle macchine virtuali comporta una certa forma di
standardizzazione che ha aspetti positivi in termini di istallazione di
sistemi e di loro amministrazione. Si pensi ad esempio ad una serie di
calcolatori differenti tra loro: il sistema operativo deve essere installato e
configurato su ognuno di essi per adattarsi alle caratteristiche hardware
del calcolatore. Questa attività richiede tempo e rappresenta un costo
notevole. Per evitare ciò si può installare su ogni macchina un virtual
machine monitor che generalmente è molto più leggero ed elastico di un
sistema operativo. Su ogni calcolatore viene quindi generata una
macchina virtuale standardizzata che li rende tutti uguali agli occhi del
sistema operativo. In questo modo è possibile effettuare una sola
installazione e configurazione del sistema operativo su di una macchina
virtuale e poi copiare il file immagine contenente la macchina virtuale. In
questo modo abbiamo configurato diversi calcolatori impiegando solo il
tempo necessario alla configurazione di un solo sistema operativo e al
trasferimento dell’immagine relativa tra i calcolatori.
La virtualizzazione permette di creare una imitazione d un
componente hardware o di un intero calcolatore. Nell’esempio visto in
precedenza si creavano macchine virtuali identiche al calcolatore
sottostante. È anche possibile generare macchine virtuali che differiscono
dal calcolatore su cui si appoggiano. Questo permette di utilizzare sistemi
57
operativi su architetture diverse da quelle per cui erano stati progettati10.
Attraverso una stretta emulazione delle caratteristiche prestazionali di un
calcolatore si riesce anche ad imitare le prestazioni di calcolatori obsoleti
e piattaforme di gioco in cui la temporizzazione delle attività è
fondamentale.
App
App
App
App
SO
SO
SO
SO
HW
HW
VMM
HW
a
b
Figura 3-8 Mascheramento del livello hardware nel VMM.
I domini creati dal VMM, oltre che essere isolati tra di loro, sono isolati
anche dal calcolatore reale poiché le interazioni con esso avvengono
sotto il controllo dell’hypervisor che interrompe eventuali attività
pericolose. Questa caratteristica dà la possibilità di utilizzare le macchine
virtuali anche in ambito di ricerca e di testing di software. È possibile
infatti testare il comportamento di applicazioni costruendo, attraverso il
virtual machine monitor, situazioni critiche (introduzione di nuovi
dispositivi, malfunzionamenti, ecc…) ed analizzare l’andamento della
situazione senza danneggiare il calcolatore reale.
10
Tra gli esempi più famosi Microsoft VirtualPC che permette agli utenti di architetture
PowerPC di utilizzare sistemi operativi Microsoft Windows progettati per architetture
x86 e dall’altro lato PearPC che consente di utilizzare MacOS nato per processori
PowerPC su architetture x86.
58
3.6 Principali software di virtualizzazione
L’architettura utilizzata in molti PC è particolarmente difficile da
virtualizzare, in quanto tutto ciò che non è supportato direttamente
dall’hardware come ad esempio l’accesso che normalmente avviene in
modo esclusivo a varie risorse del sistema, deve essere modificato e reso
compatibile, in modo da far convivere più sistemi operativi
contemporaneamente, attraverso il software. La piena virtualizzazione,
ossia la simulazione di un insieme completo di hardware di tipo standard,
nella architettura x86 ha quindi costi significativi nella complessità e
nelle performance per l’hypervisor (o VMM).
Un approccio alternativo richiede che il sistema operativo ospite sia
modificato. Questo sistema è utilizzato dal recente progetto open-source
Xen [14], è chiamato paravirtualizzazione e permette alte performance ed
una semplicità maggiore dell’hypervisor. Xen, è un’implementazione
software di macchina virtuale che gira quasi esclusivamente in sistemi
operativi di tipo linux, ma con kernel modificati.
Molti produttori di CPU hanno iniziato recentemente ad aggiungere
il supporto hardware per la virtualizzazione nei loro prodotti. I rispettivi
nomi per i progetti che realizzano questo obiettivo sono Vanderpool oVT
(Virtualization Technology) per Intel e Pacifica o SVM per AMD. In
59
particolare
viene
aggiunto
il
supporto
alle
parti
difficilmente
virtualizzabili o inefficienti da virtualizzare, nell’architettura x86,
garantendo un supporto ulteriore agli hypervisors. Questo nuovo passo,
porta e porterà ad un aumento notevole di performance, migliorerà la
semplicità del codice da scrivere per virtualizzare un sistema, e
permetterà infine piena e completa virtualizzazione [15][16].
Tra i sistemi simile a Xen, che usa anch’esso la paravirtualizzazione
è Denali, che garantisce macchine virtuali ad alte performance, sempre
nelle architetture x86. Denali supporta macchine virtuali specializzate e
minimali per fornire servizi Internet.
Il sistema può scalare migliaia di macchine virtuali. A differenza di
Xen, Denali non preserva l’interfaccia dell’applicazione binaria, per
questo motivo le applicazioni devono essere ricompilate per girare nel
sistema operativo. La differenza tra Xen e Denali è proprio di carattere,
di utilizzo e di scelte progettuali differenti. Xen preferisce far girare un
numero moderato di sistemi operativi pienamente funzionanti, mentre
Denali preferisce quelli specializzati e leggeri [17].
VMware permette la virtualizzazione di sistemi operativi non
modificati, sempre nell’architettura x86. La tecnologia utilizzata è
estremamente
complessa
ma
è
anche
altrettanto
performante.
Recentemente, VMware per contrastare la concorrenza ha rilasciato
gratuitamente VMware Server. Questo è un prodotto freeware che
permette di partizionare server x86 (anche a 64 bit) in più macchine
60
virtuali. Supporta inoltre la tecnologia di virtualizzazione Intel
Virtualization Technology e utilizza una specifica e potente interfaccia
per il monitoraggio delle macchine virtuali.
Virtuozzo, un altro sistema proprietario, sostituisce lo strato di
astrazione dell’hardware con una versione modificata, migliorando le
performance del sistema operativo. Questo è ottenuto forzando però
l’utilizzo dello stesso sistema operativo da parte di tutte le macchine
virtuali [18].
Un’altra implementazione dell’hypervisor è chiamata lightweight
hypervisor
introdotta in Parallels Workstation, anch’esso un sistema
proprietario. Questo tipo di hypervisor è uno strato software snello tra il
sistema operativo ospitato, che non necessita modifiche, ed il computer
ospite. Il lightweight hypervisor controlla direttamente una parte
dell’hardware della macchina e fornisce una interfaccia di supporto per le
chiamate di sistema virtualizzate, sia per i VMM che per il sistema
operativo ospitato, eliminato l’overhead e migliorando la velocità, le
performance e l’isolamento della macchina virtuale [19].
La tabella riassuntiva 3.1 presenta le caratteristiche base dei
principali Virtual Machine Manager.
61
Figura 3-9 Tabella comparativa dei principali software di virtualizzazione.
62
—————————————————————— REALIZZAZIONE DEL PROGETTO
Capitolo 4
4 Realizzazione del progetto
L’Università degli Studi di Perugia è continuamente impegnata nel
tentativo di ridurre i costi di gestione e nell’ottimizzare le risorse a sua
disposizione.
A questo scopo la Ripartizione Servizi Informatici e Statistici, che è
la struttura demandata all’amministrazione sia dei server e che più in
generale alla struttura informatica dell’Ateneo, ha deciso nell’ultimo
periodo di rivedere il parco macchine a sua disposizione.
Una dettagliata analisi della sala server ha messo in evidenza che
molte delle macchine utilizzate risultano sovradimensionate rispetto alla
capacità di calcolo richiesta dai servizi che offrono.
Proprio sulla base di questa motivazione e sulla crescente spinta del
mondo IT verso i software di virtualizzazione, è nata l’idea di un
progetto finalizzato alla realizzazione di una struttura che permettesse di
63
virtualizzare tutte quelle macchine con modeste richieste di calcolo
cercando nel contempo di migliorane l’affidabilità complessiva.
4.1 Analisi del problema
Quando si inizia la realizzazione di un progetto è importante capirne
bene le finalità e soprattutto le necessità che deve soddisfare, proprio per
questi motivi occorre analizzare il problema a fondo e in modo
dettagliato.
Essendo il progetto di natura sperimentale, inteso a verificare la
fattibilità dell’utilizzo della virtualizzazione su un ampio numero di
server, si è cercato di ridurre al minimo le spese necessarie: puntando su
macchine riciclate, per quanto riguarda l’hardware, e su prodotti opensource o freeware per la parte relativa al software.
La necessità di realizzare un sistema in grado di garantire la
disponibilità dei servizi offerti, ha indirizzato verso l’utilizzo di due
macchine da configurare in alta affidabilità. Il software scelto per la
realizzazione del sistema è hearbeat del progetto Linux-HA, un prodotto
open-source in grado di rispecchiare pienamente i requisiti di
minimizzazione dei costi imposti dal progetto.
L’utilizzo
di
un
sistema
in
alta
disponibilità
richiede
obbligatoriamente la presenza di uno storage condiviso tra le macchine
64
che ne fanno parte. Poiché nelle disponibilità della Ripartizione Servizi
Informatici e Statistici non vi è un dispositivo adeguato da poter
recuperare e destinare a questo progetto, si è pensato di sopperire a
questa mancanza mediante il software drbd, che consente la realizzazione
di uno storage condiviso attraverso i dischi fissi dei nodi.
Il recente annuncio della società VMware, in merito al rilascio
gratuito della versione server del suo famoso e rinomato software per la
virtualizzazione, ha inciso notevolmente, insieme alle doti di stabilità e
performance, sulla scelta di adottare per questo progetto VMware Server
come layer di virtualizzazione.
Sulla base dei software scelti e di tutte le considerazioni sin qui fatte,
le due macchine recuperate sono state configurate con determinate
caratteristiche fisiche. La necessità di conferire al sistema capacità
prestazionali accettabili e throughtput adeguato nelle connessioni di rete,
ha reso necessaria l’installazione di almeno 4 interfacce di rete per ogni
nodo.
Per migliorare l’affidabilità delle macchine, aderendo inoltre al
livello 2 di disponibilità esposto nel paragrafo 2.1, i computer sono stati
dotati di un hard disk supplementare in modo da poter effettuare il
mirroring (RAID 1) dei dischi di sistema.
La necessità infine di mandare in esecuzione diverse macchine
virtuali, obbliga i nodi ad essere dotati di molta RAM. Nel caso specifico
si è riusciti a recuperare un GigaByte per ogni macchina che, in aggiunta
65
ai processori rispettivamente di classe Pentium IV e Xeon, sono in grado
di garantire una capacità di calcolo sufficiente agli scopi che ci si è
prefissati.
Nome Nodo
Alpha
Bravo
Marca/Modello
IBM xSeries 336
Assemblato
Processore
Intel Xeon 3.20 Ghz
Intel Pentium 4 2.40 Ghz
Memoria RAM
1 GB
1 GB
Dischi
Maxtor 6Y080M0 – 80 GB
HDS728080PLA380 – 80 GB
Maxtor 6Y080L0 – 80 GB
Maxtor 6Y080L0 – 80 GB
Dischi
BCM5704 Gigabit Ethernet
RTL-8169 Gigabit Ethernet
RTL-8169 Gigabit Ethernet
VT6105 [Rhine-III]
VT6105 [Rhine-III]
Tabella 4-1 Caratteristiche hardware dei nodi.
Figura 4-1 Foto del nodo Alpha.
Figura 4-2 Foto del nodo Bravo.
66
4.2 Installazione e configurazione dei nodi
Una volta recuperate le macchine e terminata la configurazione della loro
parte hardware si è proceduto all’installazione del sistema operativo. Per
questo progetto si è scelta la distribuzione Kubuntu nella versione 6.06.1
LTS Alternate per via delle sue spiccate caratteristiche open-source e per
il forte orientamento verso gli ambienti server.
Kubuntu è un sistema operativo GNU/Linux di facile utilizzo che si
fonda sul progetto Ubuntu (distribuzione di derivazione Debian) al quale
viene sostituito l’ambiente grafico GNOME con quello KDE (K Desktop
Environment) decisamente più intuitivo.
È stata scelta la versione definita LTS (Long Team Support) poiché
vanta un ragguardevole supporto di 5 anni, molto utile negli ambienti
server in cui la completa reinstallazione del sistema non è sempre
facilmente attuabile. La dicitura Alternate indica infine che il CD
consente di eseguire installazioni personalizzate in modalità esperta,
necessario per la configurazione del RAID software.
Una volta giunta a termine l’installazione del sistema operativo in
entrambe le macchine, è bene controllare che i software installati siano
speculari. A questo proposito si può utilizzare il comando dpkg che,
lanciato con le giuste opzioni, restituisce l’elenco completo dei pacchetti
installati. Utilizzando lo stesso comando, insieme all’elenco dei package
67
appena creato, si possono ottenere due macchine perfettamente speculari
dal punto di vista del software installato.
alpha:~# dpkg --get-selections > pacchetti_alpha.txt
bravo:~# dpkg --set-selections < pacchetti_alpha.txt
bravo:~# dselect
Ottenuta la specularità del sistema operativo tra le macchine, si può
procedere alla configurazione dei componenti necessari al funzionamento
del progetto ed in particolare alle schede di rete [20][21][22].
4.2.1 Channel Bonding
Il channel bonding è una tecnica utilizzata per configurare due o più
interfacce di rete, in modo da agire come so fossero una sola. Viene
utilizzata al fine di aumentare le performance del canale trasmissivo
oppure per evitare un possibile point of failure, dovuto a guasto delle
schede, del cavo o delle porte a cui esse sono collegate.
Sfruttando questo particolare metodo, basato su una proprietà del
kernel di Linux, si ottiene che i pacchetti di una trasmissione dati
vengano inviati attraverso tutte le interacce del pool di bonding
configurato (definite sullo stesso indirizzo IP). Il kernel del sistema
infatti mette a disposizione un device virtuale (tipicamente /dev/bond0)
che viene utilizzato normalmente dalle applicazioni di più alto livello
come un device di comunicazione.
68
Per il funzionamento del bonding sono necessari due pacchetti
particolari iproute e ifenslave che vanno ovviamente installati su
entrambi i nodi attraverso i seguenti comandi:
alpha:~#
alpha:~#
bravo:~#
bravo:~#
apt-get
apt-get
apt-get
apt-get
install
install
install
install
ifenslave
iproute
ifenslave
iproute
Aggiunti i pacchetti necessari al sistema si può procedere con la
configurazione del modulo kernel, necessario per la creazione del
bonding, per farlo si deve modificare /etc/modprobe.d/arch/i386
aggiungendovi le seguenti righe:
alias bond0 bonding
options bonding mode=3 max_bonds=2 miimon=100
downdelay=200 updelay=200
Questo permette al kernel di caricare e configurare il modulo secondo i
parametri che gli vengono passati attraverso la sezione options. Di
seguito verranno illustrate le varie opzioni utilizzate a cominciare da
quella mode che identifica la policy utilizzata dal modulo bonding
secondo la seguente dicitura [25]:

0 – Imposta una policy di tipo round-robin per il bilanciamento
del carico e per il fault tolerance. Le trasmissioni vengono
ricevute e inviate in modo sequenziale, su ogni interfaccia slave
di tipo bonded, iniziando dalla prima disponibile.

1 – Imposta una policy di tipo active-backup per il fault tolerance.
Le trasmissioni vengono ricevute e inviate tramite la prima
69
interfaccia slave di tipo bonded. Un’altra interfaccia slave viene
usata solo se la prima interfaccia non ha un esito sperato.

2 – Imposta una policy di tipo XOR (exclusive-or) per il
bilanciamento del carico e di fault tolerance. Usando questo
metodo l’interfaccia eguaglia l’indirizzo MAC della richiesta in
entrata, con l’indirizzo MAC per uno dei NIC slave. Una volta
stabilito questo collegamento, le trasmissioni vengono inviate in
modo sequenziale iniziando con la prima interfaccia disponibile.

3 – Imposta una policy di trasmissione per il fault tolerance. Tutte
le trasmissioni vengono inviate su tutte le interfacce di tipo slave.

4 – Imposta una policy del tipo IEEE 802.3ad dynamic link
aggregation. Crea gruppi d’aggregazione che condividono la
stessa velocità e impostazioni duplex. Trasmette e riceve su tutte
le interfacce slave nell’aggregator attivo. Questa funzione
necessità di un interruttore compatibile con il protocollo 802.3ad.

5 – Imposta una policy Transmit Load Balancing (TLB) per il
fault tolerance e per il bilanciamento del carico. Il traffico in
uscita viene distribuito a seconda del carico su ogni interfaccia
slave. Il traffico in ingresso viene ricevuto dall’interfaccia slave
corrente. Se la slave ricevente fallisce, un’altra al suo posto
assume il controllo dell’indirizzo MAC.

6 – Imposta una policy Active Load Balancing (ALB) per il fault
tolerance ed il bilanciamento del carico. La ricezione del
70
bilanciamento del carico viene raggiunta grazie ad un ARP
negotiation.
Il parametro miimon invece specifica (in millisecondi) la frequenza con
cui il modulo controlla lo stato del link, quello downdelay definisce
quanto tempo si deve attendere dopo il fallimento del link prima di
disabilitarlo ed infine updalay specifica quanto bisogna attendere prima
di abilitare un link.
Dopo queste modifiche si può procedere con la configurazione del
nuovo device (che verrà generato dal caricamento del modulo) mediante
alcuni cambiamenti nel file /etc/network/interfaces. Nel caso
specifico vanno sostituiti tutti i riferimenti alle interfacce eth2 ed eth3
con le righe seguenti:
# Per il nodo Alpha
auto bond0
iface bond0 inet static
address 141.250.199.23
netmask 255.255.255.192
post-up ifenslave bond0 eth2 eth3
pre-down ifenslave -d bond0 eth2 eth3
# Per il nodo Bravo
auto bond0
address 141.250.199.24
netmask 255.255.255.192
A questo punto un riavvio di entrambi i nodi metterà in funzione le
modifiche apportate e sarà sufficiente lanciare il comando ifconfig
seguito da alcuni ping di prova, per verificare il corretto funzionamento
di quanto configurato:
71
alpha:~# ifconfig bond0
bond0 Link encap:Ethernet HWaddr 00:11:25:41:5D:7C
inet addr:141.250.199.23 Bcast:141.250.199.63 Mask:255.255.255.192
inet6 addr: fe80::211:25ff:fe41:5d7c/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:264 errors:0 dropped:0 overruns:0 frame:0
TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:24350 (23.7 KiB) TX bytes:19998 (19.5 KiB)
root@alpha:~# ping -I bond0 -c 6 141.250.199.62
PING 141.250.199.62 (141.250.199.62) from 141.250.199.23 bond0:
56(84) bytes of data.
64 bytes from 141.250.199.62: icmp_seq=1 ttl=64 time=0.165 ms
--- 141.250.199.62 ping statistics --6 packets transmitted, 6 receivedc, 0% packet loss, time 4999ms
rtt min/avg/max/mdev = 0.165/0.205/0.257/0.033 ms
bravo:~# ifconfig bond0
bond0 Link encap:Ethernet HWaddr 00:50:70:13:11:AA
inet addr:141.250.199.24 Bcast:141.250.199.63 Mask:255.255.255.192
inet6 addr: fe80::250:70ff:fe13:11aa/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:185 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18136 (17.7 KiB) TX bytes:10502 (10.2 KiB)
root@bravo:~# ping -I bond0 -c 6 141.250.199.62
PING 141.250.199.62 (141.250.199.62) from 141.250.199.24 bond0:
56(84) bytes of data.
--- 141.250.199.62 ping statistics --6 packets transmitted, 6 received, 0% packet loss, time 5000ms
rtt min/avg/max/mdev = 0.129/0.190/0.227/0.039 ms
Allo stato attuale di evoluzione, il progetto può essere sintetizzato nello
schema riportato in figura 4-3 che illustra le configurazioni sin qui
effettuate [23][24][26][27].
72
INTERNET / INTRANET
3C16794
Port Status
3C16794
Port Status
ä
Power
1
2
3
4
5
6
7
8
Green = 100M, Yellow = 10M, Flash = Activity
CHANNEL
bond0
BONDING eth2
ä
Power
Office Connect Switch 8
CHANNEL
bond0 141.250.199.24
eth3
eth2 BONDING
141.250.199.23
eth3
RAID 1 Software
1
2
3
4
5
6
7
8
RAID 1 Software
ALPHA
(KUBUNTU 6.06.1)
BRAVO
(KUBUNTU 6.06.1)
Figura 4-3 Schema del progetto dopo l’installazione del channel bonding.
4.3 Configurazione dello storage condiviso
Il sistema di memorizzazione dei dati in un elaboratore elettronico
costituisce un punto nevralgico dell’intero sistema.
È 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
73
problemi legati alla sua gestione. Si pensi ad esempio al fatto che in un
cluster ogni nodo deve avere accesso agli stessi dati, e gli stessi dati
devono essere anche protetti da accessi contemporanei da parte di più
nodi.
Un file system progettato per sistemi cluster deve inoltre 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 throughtput 11 dei dati, che
potrebbero richiedere specifiche particolari, volte ad evitare che il filesystem rappresenti il collo di bottiglia di un sistema cluster.
4.3.1 Tipologie di storage
Si possono individuare due grandi famiglie o filosofie costruttive per i
supporti di memorizzazione dei sistemi cluster, che si differenziano
sostanzialmente per la dislocazione fisica delle memorie di massa:
esterne oppure interne.
STORAGE ESTERNO
Questo tipo di storage permette di risolvere immediatamente il problema
dell’accesso condiviso ai dati da parte di tutti i nodi. Questa tipologia di
device infatti, sono dispositivi esterni ai quali tutti i nodi del cluster
74
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.
Le eventuali funzioni di protezione dei dati, mediante tecniche di
ridondanza e replicazione, sono gestite internamente dal dispositivo di
storage, riducendo in tal modo sia il traffico di rete generato dai
meccanismi di ridondanza che eventuali carichi elaborativi a scapito dei
nodi.
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: lo storage esterno
è infatti spesso realizzato con tecnologie tali da massimizzare questa
capacità. Non è pertanto difficile trovare storage esterni, connessi al
cluster attraverso connessioni dedicate ad alta velocità basati su fibra
ottica, firewire12 o SCSI.
Spesso si parla di SAN (Storage Area Network) per far riferimento a
un insieme di dispositivi di storage di questo tipo, che si avvalgono di
una rete dedicata esclusivamente al traffico di dati e quindi spesso
utilizzando connessioni ad alta velocità per consentire alte prestazioni.
11
Throughput: 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.
12
Firewire: è il nome dato allo standard di collegamento ad alta velocità 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 video e di editing
digitale.
75
Un’altra tecnologia in forte crescita negli storage esterni è iSCSI (SCSI
over IP) in cui il dispositivo è costruito con tecnologia SCSI ma si basa,
per le trasmissioni dati con i nodi, sul protocollo di comunicazione IP.
Il lato negativo maggiormente evidente in questo tipo di soluzioni di
storage, risiede negli ingenti costi da sopportare. Tali dispositivi sono
infatti molto onerosi poiché devono sfruttare tecnologie spesso dedicate e
molte volte proprietarie, per fornire le prestazioni per cui sono stati
costruiti. È da valutare quindi con molta attenzione se l’esigenza di
disporre di dispositivi di questo genere giustifichi l’investimento
necessario.
STORAGE INTERNO E DISTRIBUITO
Questa seconda categoria di storage è invece orientata principalmente ai
cluster di tipo HA, visto che la caratteristica di essere distribuito consente
il recupero dei dati su tutti i nodi del cluster, nel caso in cui uno dei nodi
dovesse momentaneamente rendersi indisponibile.
In questi sistemi la caratteristica di alta velocità è spesso trascurabile
perché un cluster progettato per l’High Avaiability è 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
76
del cluster vi possa accedere. Viene in questo modo costruito un device
astratto che comprende i diversi dischi esportati dai vari nodi e che viene
considerato a tutti gli effetti uno storage condiviso.
Un file system così costruito si definisce file system parallelo e
presenta il suo vantaggio più evidente nella suddivisione dei compiti di
lettura/scrittura dei dati ai diversi dispositivi presenti. Un altro evidente
vantaggio, decisamente non trascurabile, risiede nell’alta affidabilità,
fornita grazie al fatto che questa tecnica può incorporare strategie di
ridondanza sui vari dischi basate su RAID, eliminando un ulteriore single
point of failure rappresentato dal file system di ogni specifico nodo.
Le alternative possibili e maggiormente diffuse per la realizzazione
di un file system basato su dischi interni sono:

Network Block Device (NBD) e RAID software. La combinazione
di queste due tecnologie infatti consente di soddisfare le esigenze
tipiche di un file system per cluster. Il network block device infatti
è un dispositivo che viene aggiunto agli altri già gestiti dal kernel.
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 al dispositivo viene pertanto passato
attraverso la connessione di rete.
Per consentire la replica dei dati necessaria per assolvere alle
caratteristiche di disponibilità viene installato un RAID software
fra il dispositivo remoto (NBD) e quello logico gestendo poi
77
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 molto simile ad
NFS13 ma la differenza è radicale e determinante ai fini della
disponibilità e della capacità di recupero dei dati.
Rispetto ad 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 si blocca 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 richiesta 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.
13
NFS: Network File System. Un server NFS esporta una certa quantità di spazio disco
locale renderlo accessibile a tutti gli host presenti sulla rete i quali possono montarlo
come un file system locale.
78

GPFS (General Parallel File System). Questo file system è stato
sviluppato da IBM e reso disponibile gratuitamente agli ambienti
accademici, viene invece fornito unicamente dietro licenza
proprietaria per le realtà commerciali.
Le caratteristiche che rendono 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 utilizza
infatti una tecnica detta di striping per consentire l’incremento
delle performance e si basa sul fatto che un’operazione di
scrittura/lettura viene svolta parallelamente da tutte le unità disco
presenti nel file system, in quanto ognuna tratta un frammento
differente dei dati; 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.
Maggiore ridondanza genera chiaramente maggiore traffico di
rete, ed è proprio per questo motivo che GPFS è ottimizzato per
soluzioni di rete ad alta velocità.

DRBD (Distributed Replicated Block Device). Sviluppato da
Philipp Resiner è attualmente disponibile sotto licenza GPL e
quindi liberamente distribuibile e modificabile. DRBD è un
dispositivo a blocchi creato esclusivamente per risolvere problemi
tipici inerenti cluster in alta disponibilità. Si basa sul meccanismo
79
della replicazione dei dati fra due dispositivi a blocchi residenti su
due nodi differenti, attraverso una connessione di rete privata.
Semanticamente il suo funzionamento è simile al RAID-1 attuato
però fra dispositivi remoti [28].
Dopo aver analizzato e preso in considerazione le alternative offerte dal
mercato e sin qui menzionate, per il setup del cluster costruito in questo
progetto di tesi la scelta finale è ricaduta sulla tecnologia denominata
DRBD.
Si è ritenuto che DRBD, poiché ideato esclusivamente per risolvere i
problemi di cluster in alta disponibilità, rappresenti il miglior
compromesso fra semplicità di utilizzo e potenza delle funzioni
implementate.
Nonostante le qualità di GPFS queste introducono una complessità
decisamente non giustificata in cluster con solo due nodi. Altre
caratteristiche favorevoli all’uso di DRBD sono il ridotto calo di
performance che il suo utilizzo introduce e la sua completa integrabilità
con la suite Heartbeat,
fondamentale per far sì che la gestione di
eventuali failure del file system sia completamente automatizzata. Infine
si deve sottolineare il fatto che DRBD è open source e gratuito,
caratteristica cruciale per lo sviluppo e la messa in opera di questo
progetto.
80
4.3.2 Caratteristiche di DRBD
DRBD si basa su di un modulo del kernel presente in entrambi i nodi. I
due lavorano in stretta sincronia tra loro ed a dimostrazione di ciò il file
di configurazione, che verrà illustrato più avanti, risulta identico in tutte
le macchine.
Nel momento in cui si decide di costruire un block device basato su
DRBD, ognuno dei due nodi mette a disposizione una partizione del
proprio disco locale che ovviamente non va configurata per un mounting
automatico attraverso il file /etc/fstab.
Leggendo il proprio file di configurazione (/etc/drbd.conf) ogni
copia di DRBD imposta la partizione fisica ivi specificata e la fa entrare
a far parte del block device specificato (/dev/drbd0). Successivamente,
attraverso il canale di comunicazione privato bond1 (che nel setup
corrente è il channel bonding tra eth0 e eth1), si sincronizza con il
modulo DRBD presente nell’altro nodo ed esegue le medesime
operazioni
A questo punto è disponibile il block device /dev/drbd0 sull’intero
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
81
in quanto va inizializzato e poi montato dopo aver creato su di esso il
file-system desiderato.
L’inizializzazione
del
block
device
/dev/drbd0
prevede
l’assegnazione ad uno dei due nodi della capacità di scrittura. Con DRBD
infatti solo un nodo alla volta è in grado di operare attivamente sul block
device onde evitare inconsistenze negli accessi agli stessi dati da parte
dei due nodi. Per questo motivo rispetto a un dato block device, ogni
nodo può assumere il ruolo di primary se possiede la capacità di scrivervi
e secondary nel caso non gli venga accordata. Se un nodo assume il ruolo
di primary, avrà la possibilità di modificare il contenuto del block device
ed il modulo DRBD si occuperò di trasferire e replicare le modifiche
sull’altro nodo. Il trasferimento avviene attraverso la rete privata e sarò il
nodo secondary il responsabile di effettuare le modifiche sulla partizione
destinata a far parte del block device DRBD.
Tutto questo avviene in modo del tutto trasparente per l’utente che
non è in grado di entrare nel merito della gestione delle partizione
destinate al block device, questo perché l’eventuale tentativo di montare
tali partizioni in modo manuale potrebbe produrre errori di grave entità
che potrebbero indurre la perdita della sincronizzazione fra i nodi e
quindi ad inconsistenze nei dati.
82
4.3.2.1
I protocolli di sincronizzazione
DRBD è basato su di un 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, ed integra inoltre tra le sue
specifiche funzionalità di riordinamento dei pacchetti e di controllo di
flusso. Queste caratteristiche rendono possibile la dislocazione remota
dei due nodi per consentire capacità di recupero dei dati estreme, che
possono coprire fino all’ultimo livello di disponibilità, ovvero il disaster
recovery, attraverso la dislocazione geografica della ridondanza.
Il collegamento fra i due nodi può essere reso più o meno
interdipendente in base alla relazione tra la stabilità dell’hardware e
l’affidabilità che si vuole raggiungere. A tale scopo vengono utilizzati tre
differenti protocolli che definiscono al loro interno le caratteristiche che
regolano il funzionamento di DRBD:

Protocollo A. Questo metodo di connessione tra i due nodi
consente il massimo grado di indipendenza. Se il nodo primario
esegue un operazione di I/O14, invia al secondario il comando di
eseguire la stessa operazione. Non appena termina la scrittura sul
dispositivo locale, il nodo primario invia al suo sistema operativo
il segnale di aver terminato l’operazione senza considerare cosa è
avvenuto sul nodo secondario.
83
Risulta evidente che se il primario va in crash dopo aver
segnalato la fine di una scrittura, ma prima che il secondo abbia
effettivamente ricevuto tutti i dati relativi all’operazione di
scrittura, allora la replica dei dati non può essere considerata
speculare e si potrebbero verificare perdite di dati. A volte
tuttavia questo protocollo può rendersi estremamente necessario
nei casi in cui il collegamento alla rete interna presenti un’elevata
latenza. Se non vi fosse questo protocollo, il nodo primario
sarebbe costretto ad attendere il segnale di termine delle
operazioni di sincronizzazione attraverso la rete e ciò
pregiudicherebbe l’efficienza computazionale dell’intero 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, ma cruciale,
differenza che il nodo primario segnala al proprio sistema
operativo (attraverso il quale un’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 egli riceve il comando di scrittura, comando
che provvederà successivamente ad eseguire.
14
I/O: forma abbreviata per indicare Input/Output. Generalmente si riferisce ad
operazioni eseguite su memorie coinvolgenti un flusso di dati.
84
In effetti, pur fornendo una certa sicurezza in più, il protocollo B
è una via di mezzo tra il già citato A ed il successivo C che
garantisce il massimo livello di 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, è mandata solo quando si ha la
garanzia che il nodo secondario abbia terminato la sua operazione
di scrittura, ovvero quando 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 ovviamente
al tempo di latenza del sistema di connessione di rete necessario
al trasporto dei segnali di sincronizzazione relativi alle operazioni
eseguite.
4.3.3 Installazione e configurazione di DRBD
La procedura di installazione del software DRBD segue le classiche
consuetudini sulla compilazione di un pacchetto nei i sistemi linux.
Dopo
aver
navigato
fino
al
sito
internet
del
software
(http://www.drbd.org), scaricare l’ultima versione disponibile, nel caso
85
specifico drbd-0.7.23.tar.gz, copiarla nella directory scelta per la
compilazione e scompattare il contenuto del pacchetto.
alpha:~# cd /usr/local/src
alpha:~# wget http://oss.linbit.com/drbd/0.7/drbd-0.7.23.tar.gz
alpha:~# tar –zxvf drbd-0.7.23.tar.gz
bravo:~# cd /usr/local/src
bravo:~# wget http://oss.linbit.com/drbd/0.7/drbd-0.7.23.tar.gz
bravo:~# tar –zxvf drbd-0.7.23.tar.gz
Una volta decompresso il file si deve entrare nella cartella appena creata
e lanciare i comandi di make per generare i moduli e gli eseguibili. Per
evitare errori di compilazione è importante controllare che nel sistema
siano presenti i sorgenti del kernel (tipicamente un pacchetto denominato
kernel-source).
alpha:~#
alpha:~#
alpha:~#
alpha:~#
cd drbd-0.7.23
make clean all
make tools
make install
bravo:~#
bravo:~#
bravo:~#
bravo:~#
cd drbd-0.7.23
make clean all
make tools
make install
Per completare l’installazione DRBD va aggiunto all’elenco dei
programmi lanciati durante la fase di avvio della macchina. Il wrapper
DRBD è stato inserito, dal processo di installazione, direttamente
all’interno della directory /etc/init.d, per cui è sufficiente eseguire il
comando sysv-rc-conf ed impostarne l’avvio nei runlevel di default
per completare questa fase dell’installazione.
86
Figura 4-4 Impostazione di DRBD per l’avvio al boot.
Come già accennato nei paragrafi precedenti DRBD necessita di un
canale di comunicazione, preferibilmente diretto, tra i due nodi per poter
funzionare correttamente. A questo proposito, come già visto nel
paragrafo 4.2.1, si possono migliorare le performance e il throughtput
attraverso l’adozione di un channel bonding. Anche in questo caso,
quindi, si configurerà un interfaccia di bonding adibita unicamente alla
sincronizzazione dei block device, andando nuovamente a modificare il
file /etc/network/interfaces e restartando successivamente lo stack
di rete per rendere effettive le modifiche.
# Per il nodo Alpha
auto bond1
address 192.168.1.23
netmask 255.255.255.0
87
# Per il nodo Bravo
auto bond1
address 192.168.1.24
netmask 255.255.255.0
alpha:~# /etc/init.d/networking restart
* Reconfiguring network interfaces... [ ok ]
bravo:~# /etc/init.d/networking restart
* Reconfiguring network interfaces... [ ok ]
La fase conclusiva per il funzionamento di DRBD riguarda la
configurazione del file /dev/drbd.conf, al suo interno sono specificate
le risorse che devono essere utilizzate e le modalità con cui DRBD dovrà
utilizzarle.
4.3.3.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 desidera aggiungere
al cluster.
Ogni riga che inizia con la parola chiave resource indica che si sta
configurando un nuovo block device identificato dal nome che segue la
parola stessa. Per ogni risorsa configurata ci sono poi diverse sottosezioni
che definiscono le varie caratteristiche di ogni singolo block device.
Tra le prime direttive da configurare si trova protocol che illustra il
tipo di protocollo con cui DRBD deve effettuare la sincronizzazione sul
device. Nel cluster che si sta costruendo, si utilizza il protocollo C per il
88
particolare orientamento all’alta affidabilità già esposto nel paragrafo
4.3.2.1.
Nell’elenco seguente vengono illustrate le principali sezioni del file
di configurazione, ognuna caratterizzata da una serie di parametri:

startup: qui si definiscono le impostazioni relative all’avvio del
demone. Particolare attenzione meritano il parametro wfc-timeout,
che specifica quanti secondi si deve attendere in fase di boot per
avere un contatto dall’altro nodo e degr-wfc-timeout che specifica
quanti secondi si devono attendere prima di riavviare il nodo in
caso di isolamento dal cluster.

disk: specifica quale comportamento deve tenere DRBD in caso
di errore I/O a basso livello nel device disco.

net: in questa sezione vengono impostati tutti i parametri relativi
alla connessione di rete, come ad esempio on-disconnect per il
comportamento in caso di disconnessione della rete oppure pingint
che specifica l’intervallo di tempo tra i controlli di
connettività.

syncer: riporta i parametri inerenti la sincronizzazione con
particolare riferimento a rate che imposta il limite massimo di
occupazione di banda sulla connessione di rete.
L’ultima parte della sezione resource è quella più importante perché
configura le risorse utilizzate da ogni nodo, identificando le partizioni
fisiche e le interfacce di rete impiegate nel sistema. A tale proposito si
89
noti che durante la fase di installazione del sistema operativo, si è
provveduto a riservare alcune partizioni per la creazione dei block device
DRBD. Tali partizioni hanno tutte la dimensione di 10 GB e sia sulla
macchina denominata alpha che su quella bravo corrispondono ai device
/dev/md6
e /dev/md7.
Di seguito il dettaglio delle due risorse configurate per questo
progetto:
resource drbd0 {
[...]
on alpha {
device
/dev/drbd0;
disk
/dev/md6;
address
192.168.1.23:7788;
meta-disk internal;
}
on bravo {
device
/dev/drbd0;
disk
/dev/md6;
address
192.168.1.24:7788;
meta-disk internal;
}
}
resource drbd1 {
[...]
on alpha {
device
/dev/drbd1;
disk
/dev/md7;
address
192.168.1.23:7789;
meta-disk internal;
}
on bravo {
device
/dev/drbd1;
disk
/dev/md7;
address
192.168.1.24:7789;
meta-disk internal;
}
}
All’interno di ogni sottosezione, che inizia con la parola on seguita dal
nome del nodo che esporta le risorse, si trova innanzitutto la definizione
del device che viene configurato, definito dai file /dev/drbd0 e
90
/dev/drbd1.
Con l’attributo disk viene specificata quale sarà la
partizione reale che deve essere esportata dallo specifico nodo per andare
a far parte del block device condiviso.
L’attributo address si riferisce invece 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.1.23 su
alpha e 192.168.1.24 su bravo. In entrambi i nodi sarà in ascolto sulla
porta 7788 per il device drbd0 e 7789 per quello drbd1. Come si può
notare per ogni risorsa aggiuntiva eventualmente configurata (relativa ad
altri block-device) è necessario specificare una porta differente.
Terminata la fase di configurazione del servizio, si può procedere
con il suo avvio, verificando a posteriori che quanto sin qui realizzato
funzioni in modo corretto e soprattutto che venga effettuata
adeguatamente la sincronizzazione delle partizioni tra i nodi.
Per prima cosa si procede con lo start del demone in entrambi i nodi
attraverso lo script che l’installazione ha posizionato in /etc/init.d e si
controlli tramite lo stesso script lo stato del modulo.
alpha:~#/etc/init.d/drbd start
Starting DRBD resources:
[ d0 d1 s0 s1 n0 n1 ].
alpha:~#/etc/init.d/drbd status
drbd driver loaded OK; device status:
version: 0.7.23 (api:79/proto:74)
SVN Revision: 2686 build by root@alpha, 2007-01-15 13:08:27
0: cs:Connected st:Secondary/Secondary ld:Inconsistent
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
bravo:~#/etc/init.d/drbd start
[ d0 d1 s0 s1 n0 n1 ].
91
bravo:~#/etc/init.d/drbd status
SVN Revision: 2686 build by root@bravo, 2007-01-15 13:12:29
Come si può notare dall’output del comando /etc/init.d/drbd
status,
entrambi i nodi vengono considerati in stato Secondary e la
risorsa risulta Inconsistent; ciò sta ad indicare che la sincronizzazione
non è ancora attiva, questo perché non è stato definito quale delle
partizioni assegnate alla risorsa (e quindi quale nodo) sia da considerare
come master tra le due.
Lanciando il comando di seguito riportato, si imposta il nodo
relativo come primario ed è possibile, controllando lo stato delle risorse,
verificare che sia partita la sincronizzazione [30].
alpha:~# drbdadm -- --do-what-I-say primary drbd0
alpha:~# /etc/init.d/drbd status
0: cs:SyncSource st:Primary/Secondary ld:Consistent
[==>.................] sync'ed:13.7% (8127/9402)M
finish: 0:03:15 speed: 42,580 (38,416) K/sec
bravo:~# /etc/init.d/drbd status
0: cs:SyncTarget st:Secondary/Primary ld:Consistent
[===>................] sync'ed: 16.7% (7840/9402)M
92
bravo:~# drbdadm -- --do-what-I-say primary drbd1
bravo:~# /etc/init.d/drbd status
0: cs:Connected st:Secondary/Primary ld:Consistent
1: cs:SyncSource st:Primary/Secondary ld:Consistent
ns:0 nr:24 dw:24 dr:0 al:0 bm: 1 lo:0 pe:9 ua:0 ap:0
[>...................] sync'ed: 0.7% (9347/9402)M
0: cs:Connected st:Primary/Secondary ld:Consistent
1: cs:SyncTarget st:Secondary/Primary ld:Consistent
[>...................] sync'ed: 3.6% (9073/9402)M
Terminata la sincronizzazione tra i due nodi si può controllare lo stato
finale, verificando che le risorse siano connesse e consistenti.
alpha:~# /etc/init.d/drbd start
[ d0 d1 s0 s1 n0 n1 ].
0: cs:Connected st:Primary/Secondary ld:Consistent
1: cs:Connected st:Secondary/Primary ld:Consistent
A questo punto della configurazione si può procedere con la creazione
del file system sulle risorse, si utilizza il comando mkfs.ext3
/dev/drbd0
per il nodo alpha e mkfs.ext3 /dev/drbd1 per il nodo
bravo. Ultimata la scrittura del file system si può procedere con un test
sul mounting per verificare che tutto funzioni correttamente, ma anche
per accertarsi che se si tenta di utilizzare una risorsa da un nodo
secondary questo viene correttamente impedito dal modulo DRBD.
93
alpha:~# mkfs.ext3 /dev/hda9
[...]
alpha:~# mount /dev/drbd1 /mnt
alpha:~# df -k
Filesystem 1K-blocks Used
Available Use% Mounted on
[...]
/dev/drbd0
9477056 8677256
318384
97% /mnt
bravo:~# mount -t ext3 /dev/drbd0 /mnt/
mount: block device /dev/drbd0 is write-protected,
mounting read-only
mount: /dev/drbd0 already mounted or /mnt/ busy
A questo punto si è conclusa definitivamente la configurazione del
sistema DRBD e si può visionare nello schema seguente lo stato di
avanzamento del progetto di tesi.
INTERNET / INTRANET
3C16794
Port Status
3C16794
Port Status
ä
Power
1
2
3
4
5
6
7
8
CHANNEL
bond0
BONDING eth2
ä
Power
CHANNEL
bond0 141.250.199.24
eth3
eth2 BONDING
141.250.199.23
eth3
/dev/drbd0
/dev/drbd1
eth0
eth0
bond1
DRBD
bond1
192.168.1.23
CHANNEL
BONDING
192.168.1.24
eth1
RAID 1 Software
1
2
3
4
5
6
7
8
eth1
RAID 1 Software
ALPHA
(KUBUNTU 6.06.1)
BRAVO
(KUBUNTU 6.06.1)
Figura 4-5 Schema del progetto dopo l’installazione di DRBD.
94
4.4 Configurazione di Heartbeat
In questo paragrafo si analizza la configurazione e i meccanismi su cui si
basa Heartbeat. Tale software caratterizza il funzionamento di buona
parte del cluster realizzato in questo progetto, in quanto tiene traccia del
funzionamento dei singoli nodi e prende le decisioni opportune laddove
si verifichi un malfunzionamento.
Come ogni software sviluppato per gli ambienti di tipo Unix, ed in
particolare Linux, è una suite composta da un insieme di piccoli moduli
altamente specializzati in una particolare funzione, che interagiscono
costantemente tra loro per raggiungere un obiettivo finale.
Questo stile volto alla modularizzazione consente di rendere molto
snello ed efficiente lo sviluppo del software, in quanto in caso di
manutenzione o aggiunta di nuove funzionalità, le modifiche
coinvolgeranno solo i moduli direttamente interessati e non l’intera suite.
4.4.1 La struttura di Heartbeat
La figura 4.6 mostra che Heartbeat ha un’architettura multiprocesso,
questo è derivato non solo da ragioni storiche, ma anche da motivazioni
95
riconducibili alla sicurezza. Il fatto che ogni processo gestisca
separatamente un particolare aspetto della suite evita che il crash di una
certa funzionalità coinvolga le altre.
Dalla figura si evincono quattro tipologie di processi: primo e più
importante è il Master Control Process (MCP), vengono poi i processi di
lettura (read) e scrittura (write) e il processo di lettura FIFO (FIFO
reader). Oltre a quelli già citati ci sono poi altri processi che possono
essere considerati client, in quanto eseguono speciali operazioni e
chiedono al Master Control Process di reagire conseguentemente. Tra
questi i più importanti sono ipfail e Consensus Cluster Membership
(CCM).
READ
ucast
(eth0)
WRITE
ucast
(eth0)
READ
serial
WRITE
serial
(/dev/ttyS0)
(/dev/ttyS0)
Master Control
Process
FIFO Reader
Client Child
Process
(ipfail)
Client Child
Process
(ccm)
Client Child
Process
(watchdog)
Figura 4-6 Schema dei moduli di Heartbeat.
96
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 relativi ad Heartbeat, a cui invia e da cui riceve i dati necessari a
prendere eventuali decisioni in caso di malfunzionamenti sui nodi.
Scendendo nel dettaglio MCP provvede all’invio dei segnali di
heartbeat attraverso i canali configurati per il collegamento tra i nodi del
cluster, gestisce i time-out sui segnali di heartbeat, attraverso i quali
stabilire se un nodo è effettivamente funzionate, invia pacchetti firmati e
autentica pacchetti ricevuti utilizzando gli appositi algoritmi crittografici
e si occupa infine di avviare o riavviare i diversi processi della suite
relativi alle diverse funzionalità implementate.
Il processo FIFO reader ha l’unico scopo di leggere la coda
attraverso la quale comunicano i diversi processi di Heartbeat accessibili
attraverso il file system al percorso /var/lib/heartbeat/fifo. La
comunicazione fra i processi, attraverso la coda First-In-First-Out, è
utilizzata quando i processi risiedono sulla stessa macchina ed è
implementata aprendo in lettura o scrittura esclusiva la stessa coda. Il
modulo FIFO reader evita che la gestione di tale comunicazione venga
eseguita all’interno del MCP evitandogli inutili sovraccarichi.
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.
97
Poiché i canali di comunicazione possono essere differenti per tipologia e
funzione, è necessario che ci sia un processo di lettura per ogni tipo di
canale da cui ricevere i dati.
I write processes hanno le stesse caratteristiche dei read processes
ma sono adibiti alla trasmissione di dati all’esterno. Anche in questo caso
si hanno processi di scrittura differenti in funzione del canale di
comunicazione utilizzato.
I client processes eseguono operazioni che si possono definire
esterne all’attività del Master Control Process: ad esempio ipfail che
esegue un monitoraggio della connessione fra i nodi e stabilisce quando è
necessario eseguire il failover del gruppo di servizi, richiedendo al MCP
di eseguire materialmente questa operazione. CCM invece, acronimo di
Consensus Cluster Membership, è un client process che 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. Ogni nodo, grazie al
CCM, è consapevole del fatto di essere o meno membro del cluster ed i
nodi parzialmente collegati (per un interruzione dei canali ridondati) non
vengono considerati membri del cluster e non possono accogliere un
eventuale failover. È evidente che questo componente assume
un’importanza crescente all’aumentare del numero dei nodi che
compongono il cluster benché la sua funzione rimane indispensabile
anche con cluster formati da due soli nodi[4].
98
4.4.1.1
I plugin di Heartbeat
I moduli sin qui descritti costituiscono il nucleo della suite e assolvono le
funzioni primarie necessarie al funzionamento del cluster. Questo nucleo
centrale non implementa però alcune funzionalità esterne ed orientate al
contesto operativo in cui verrà collocato il cluster.
Al fine di interfacciarsi con il mondo esterno Heartbeat si appoggia a
dei plugin che vengono utilizzati in modo opportuno in funzione del tipo
di ambiente in cui opera, come illustrato nella figura 4.7 questi possono
essere classificati in tre categorie: plugin di STONITH, plugin di
comunicazione, plugin di autenticazione.
Heartbeat
Heartbeat Plugin Infrastructure
Communication
Plugin
STONITH
Plugin
Heartbeat Client Process
(ccm, ipfail, etc.)
Authentication
Plugin
Resource Script
Figura 4-7 Moduli esterni di Heartbeat.
I plugin di STONITH implementano tutte le funzioni necessarie per far
fronte al problema del brain-splitting. STONITH è l’acronimo di Shoot
99
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 per via di un failover sbagliato, causato per esempio
dall’interruzione simultanea di tutti i canali di comunicazione interna.
Questo plugin sfrutta un dispositivo hardware collegato al cluster,
attraverso la rete ehternet oppure le porte seriali, che è in grado di
comunicare con Heartbeat e ricevere comandi. Tale dispositivo 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. In questo progetto essendo l’erogazione
dell’energia elettrica della sala macchine fornita da un unico gruppo di
continuità non è possibile utilizzare questa funzionalità.
Tutte le comunicazioni verso l’esterno, eseguite da Heartbeat sono
gestite da plugin, i canali supportati per questi scambi di informazioni
comprendono UDP di tipo broadcast, multicast e unicast e le
comunicazioni attraverso 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
100
consentono ai nodi che li ricevono di stabilire se un certo segnale
ricevuto sia autentico ed effettivamente proveniente da un certo nodo.
Tre sono gli algoritmi di crittografia implementi, utilizzabili a seconda
del livello di sicurezza ed il consumo di CPU che si vuole ottenere: il
primo è il CRC semplice ma anche meno sicuro, il secondo è l’algoritmo
MD5 mentre il terzo è SHA1 che offre una codifica difficilmente
reversibile ma richiede un carico di lavoro decisamente supplementare e
superfluo a meno di una comunicazione di sincronizzazione che passi
attraverso segmenti di rete non esclusivamente ad utilizzo dei nodi del
cluster.
I resource script sono componenti esterni di Heartbeat e sono file
eseguibili
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 oppure richiamati dall’amministratore per gestire alcuni
aspetti della suite.
4.4.2 Il Resource Group
Nella logica di Heartbeat si definisce risorsa ogni entità del sistema che
Heartbeat gestisce [29]. Una risorsa può essere ad esempio un indirizzo
101
IP, un servizio come Apache o MySQL, un componente hardware come
un unità disco, una risorsa del kernel come un file system.
Per ogni risorsa gestita da Heartbeat esiste uno script in grado di
eseguirne lo start e lo stop analogamente a quanto succede con gli script
presenti in /etc/init.d.
Si parla di Resource Group per via del fatto che l’operazione di takeover, da un nodo all’altro, interessa tutte le risorse che un certo nodo del
cluster gestisce. Per 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
un ruolo primario ed i servizi forniti sull’indirizzo specificato all’inizio.
Nel momento in cui il nodo dovesse cadere, il resource group viene
interamente migrato sull’altro nodo e le risorse trasferite vengono attivate
così com’erano sul nodo caduto.
4.4.3 Installazione e configurazione di Heartbeat
La procedura di installazione di Heartbeat segue le classiche
consuetudini sulla compilazione di un pacchetto nei i sistemi linux.
Dopo
aver
navigato
fino
al
sito
internet
del
software
(http://www.linux-ha.org), scaricare l’ultima versione disponibile, nel
102
caso specifico heartbeat-2.0.8.tar.gz, copiarla nella directory scelta
per la compilazione e scompattare il contenuto del pacchetto.
alpha:~# wget http://linux-ha.org/download/heartbeat-2.0.8.tar.gz
alpha:~# tar –zxvf heartbeat-2.0.8.tar.gz
bravo:~# cd /usr/local/src
bravo:~# wget http://linux-ha.org/download/heartbeat-2.0.8.tar.gz
bravo:~# tar –zxvf heartbeat-2.0.8.tar.gz
Prima di effettuare la compilazione è necessario eseguire alcune
operazioni
a livello di sistema operativo per preparare l’ambiente:
Heartbeat richiede infatti che siano presenti in entrambi i nodi un utente
ed un gruppo ad esso dedicati.
alpha:~# groupadd hacluster
alpha:~# useradd -g hacluster -d /nonexistent -m hacluster
bravo:~# groupadd hacluster
bravo:~# useradd -g hacluster -d /nonexistent -m hacluster
Una volta creato l’utente e decompresso il file si deve entrare nella
cartella appena creata e lanciare gli opportuni comandi necessari alla
compilazione.
alpha:~#
alpha:~#
alpha:~#
alpha:~#
cd /usr/local/src/heartbeat-2.0.8
./ConfigureMe configure
make
make install
bravo:~#
bravo:~#
bravo:~#
bravo:~#
cd /usr/local/src/heartbeat-2.0.8
./ConfigureMe configure
make
make install
Per completare l’installazione di Heartbeat il suo script di avvio va
aggiunto all’elenco dei programmi lanciati durante la fase di avvio della
macchina. Lo script di avvio di Heartbeat è stato inserito, dal processo di
installazione, direttamente all’interno della directory /etc/init.d, per
103
cui è sufficiente eseguire il comando sysv-rc-conf ed impostarne
l’avvio nei runlevel di default.
Figura 4-8 Impostazione di Heartbeat per l’avvio al boot.
Anche Heartbeat, come ogni software per piattaforma *nix, si configura
attraverso determinati file di configurazione. Nel caso specifico prima di
poterli modificare a piacimento, i file vanno copiati dalla cartella
contenente i documenti in /usr/share/doc/heartbeat-2.0.8/ alla
/etc/ha.d.
alpha:~# cd /usr/share/doc/heartbeat-2.0.8/
alpha:~# cp ha.cf haresources authkeys /etc/ha.d/
alpha:~# chmod 600 authkeys
bravo:~# cd /usr/share/doc/heartbeat-2.0.8/
bravo:~# cp ha.cf haresources authkeys /etc/ha.d/
bravo:~# chmod 600 authkeys
La configurazione di
questi tre file evidenzia le politiche di gestione
delle risorse decise in fase di progetto e le funzioni di recovery e
104
monitoraggio che si è scelto di attivare. Si tenga presente che i file di
configurazione debbono essere identici in entrambi i nodi.
IL FILE “HARESOURCES”
Nel file haresources vengono configurati i resource group per ciascuno
dei nodi coinvolti nel cluster. Questo progetto utilizza una configurazione
Active/Active ed il file conterrà quindi due righe, una per nodo, con
definiti i servizi che dovranno essere erogati da ognuno.
All’inizio di ogni riga si trova l’hostname del nodo (come
specificato dall’output del comando uname -n) che è destinato ad
ospitare inizialmente il resource group.
Per i servizi che si devono erogare, come mostrato nei paragrafi
precedenti, si sono già configurati due device DRBD denominati drbd0 e
drbd1.
Con lo script drbddisk Heartbeat è in grado di dare al nodo il
ruolo di primario per il device specificato, provvedendo inoltre a montare
attraverso lo script Filesystem il device nel percorso definito.
Accertata l’esistenza della cartella per il mounting, ed eventualmente
creandola con il comando mkdir in caso negativo, si può procedere alla
stesura del file utilizzando le seguenti righe di configurazione.
alpha drbddisk::drbd0
Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3
bravo drbddisk::drbd1
Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3
In particolare lo script drbddisk esegue il comando drbdadm primary
drbdX
per rendere primario il nodo e montare il dispositivo, drbdadm
105
secondary drbdX
per rendere il nodo secondario dopo aver smontato il
device ed eseguire eventualmente il takeover del resource group.
A questo punto si possono inserire, di seguito nella riga, i wrapper
dei servizi che si vogliono erogare, ma si vedrà questa fase più avanti nel
capitolo
nella
parte
relativa
all’installazione
del
software
di
virtualizzazione.
IL FILE “HA.CF”
Il file ha.cf viene letto da Heartbeat nel momento in cui se ne effettua
l’avvio 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 che si vuole
realizzare e per soddisfare le politiche di gestione che si sono stabilite in
fase di progetto.
Di seguito si analizzerà questo file, contenuto integralmente in
appendice, illustrandone le principali opzioni utilizzate.

keepalive 2
– specifica il tempo in secondi che intercorre tra
due segnali di heartbeat inviati ai nodi;

deadtime 5
– indica quanto tempo in secondi si deve attendere
dall’ultimo segnale di heartbeat ricevuto per poter dichiarare il
nodo definitamene non funzionante;

initdead 120
– imposta un timing in secondi per il bypass del
parametro di deadtime ed è valido solamente all’avvio del
106
servizio di Heatbeat. Questo è studiato dare tempo al demone di
stabilire le connessioni ed inizializzare i diversi plugin, al fine di
evitare un takeover delle risorse prima ancora che il sistema si sia
completamente inizializzato su tutti i nodi;

auto_failback on
– definisce un particolare comportamento del
cluster in caso di failure di un nodo. Secondo la configurazione
scelta se un nodo rientra nel cluster dopo esserne uscito per un
malfunzionamento o per una eventuale manutenzione, il resource
group configurato per default su tale nodo viene automaticamente
riportato su di esso. È evidente che i servizi torneranno ad essere
erogati da tale nodo solo dopo che il file system condiviso è stato
risincronizzato, ma sarà compito di DRBD verificare il corretto
andamento di questo processo.

baud 19200
e serial /dev/ttyS0 – questi parametri vengono
utilizzati nel caso si decida, per ulteriori motivi di sicurezza, di
utilizzare anche la connessione seriale per il sottosistema di
comunicazione. Questa configurazione prevede che le due
macchine siano collegate tra loro, sulle rispettive porte seriali,
mediante un cavo di tipo null modem. La verifica del corretto
funzionamento del cavo e delle porte è possibile tramite alcuni
semplici comandi riportati di seguito:
bravo:~# cat </dev/ttyS0
alpha:~# echo "Hello World" >/dev/ttyS0
107
nella console della macchina bravo dovrebbe apparire la scritta
"Hello
World",
segnale che la comunicazione si è svolta
correttamente.

bcast bond0
e bcast bond1 – specifica 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 i due canali bond0 e bond1 sono di per sé già ridondati
per i motivi spiegati nel paragrafo 4.2.1;

watchdog /dev/watchdog
– watchdog è uno strumento atto al
reboot del sistema qualora qualcosa non funzioni correttamente.
Ad esempio nel caso in cui il kernel risponda in modo anomalo,
oppure qualche programma occupi il 100% dei cicli di cpu.
L’idea è quella di avere un device /dev/watchdog in cui il sistema
operativo si preoccupi di scrivere ad intervalli di tempo regolari e
ben definiti. Se una delle scritture fallisce il computer viene
riavviato.
Per rendere operativa questa funzionalità è necessario prima
apportare alcune modifiche al sistema operativo, ed in particolare
aggiungere
la
voce
softdog
al
file
/etc/modules
e
successivamente inserire nel file /etc/modprobe.d/arch/i386
la seguente riga:
options softdog nowayout=0
108
L’opzione nowayout=0 indica che il computer non deve essere
rebottato anche nel momento in cui il device viene chiuso. Questo
per evitare noiosi riavvii anche quanto, per esempio, viene fatto lo
shutdown del servizio Heartbeat [31][33];

node alpha
e node bravo – indica i nomi dei nodi del cluster
così come risulta dall’output del comando uname -n;

respawn hacluster /usr/lib/heartbeat/ipfail
– Questa
riga, ed in generale quelle di questo tipo, sono di particolare
importanza in quanto provvedono a far eseguire ad Heartbeat
comandi corrispondenti a plugin appartenenti alla suite o comandi
esterni, che vengono lanciati come processi figli dello stesso
Heartbeat.
Il comando respawn all’inizio della riga, indica che Heartbeat si
occuperà di monitorare costantemente il funzionamento del
processo, preoccupandosi di rilanciarlo nel caso in cui venga
interrotto.
In questo caso, come utente hacluster, viene eseguito il plugin
ipfail che si occupa di monitorare costantemente il collegamento
del nodo con l’esterno. Se il nodo dovesse risultare isolato ed
evidentemente non nelle condizioni di erogare il servizio ipfail
richiederà un failover del resource group;

ping
141.250.199.62
– l’ultima riga analizzata configura
l’indirizzo IP verso cui eseguire il comando ping utilizzato da
109
ipfail per verificare il collegamento del nodo con l’esterno. È
evidente che tale IP deve corrispondere a un host sicuro e sempre
funzionante ed in questo caso è stato scelto il gateway della rete
esterna [32].
IL FILE “AUTHKEYS”
Come analizzato nel paragrafo 4.4.1.1, tutte le comunicazioni che
avvengono fra i nodi sono cifrate e autenticate al fine di 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[4].
Nel file authkeys si configura appunto l’algoritmo crittografico per
le comunicazioni fra i nodi ed in particolare attraverso le seguenti righe,
si specifica al cluster di utilizzare l’algoritmo SHA1.
auth 2
2 sha1 pwd!hacluster
Questa scelta è dovuta al fatto che le comunicazioni fra i nodi avvengono
anche attraverso un canale di rete insicuro ed oltretutto l’overhead
computazionale introdotto dalla codifica con SHA1 rispetto al CRC o
MD5 è assolutamente irrilevante per la potenza di calcolo dell’hardware
in uso.
110
A questo punto può dirsi conclusa anche l’installazione e la
configurazione di Heartbeat, si può avere un quadro complessivo di
quanto realizzato sin qui attraverso la figura 4.9.
INTERNET / INTRANET
3C16794
Port Status
3C16794
Port Status
ä
Power
1
2
3
4
5
6
7
8
CHANNEL
bond0
BONDING eth2
ä
Power
141.250.199.23
CHANNEL
bond0 141.250.199.24
eth3
eth2 BONDING
IPFAIL
eth3
1
2
3
4
5
6
7
8
ttys0
ttys0
HEARTBEAT
/dev/drbd0
/dev/drbd1
eth0
0001
bond1
DRBD
bond1
192.168.1.23
CHANNEL
BONDING
192.168.1.24
eth1
WATCHDOG
eth0
0001
eth1
WATCHDOG
RAID 1 Software
RAID 1 Software
ALPHA
BRAVO
(KUBUNTU 6.06.1)
(KUBUNTU 6.06.1)
UPS SYSTEM
Figura 4-9 Schema del progetto dopo l’installazione di Heartbeat.
111
4.5 Configurazione delle Virtual Machines
Dopo aver configurato lo storage condiviso tramite DRBD ed aver messo
in opera l’alta affidabilità tramite la suite Heartbeat, si può procedere
all’installazione del software necessario per far girare le macchine
virtuali.
Il prodotto scelto per questa fase, come già descritto nei paragrafi
precedenti, è la suite VMware Server, un prodotto gratuito che ha preso il
posto della versione GSX Server. La versione 1.0.1 rilasciata da pochi
mesi ha stupito per le notevoli potenzialità: non si tratta infatti solo di un
prodotto per l’utilizzo di virtual machine in ambito server, ma anche una
soluzione estremamente interessante per chi vuole avvicinarsi al mondo
della virtualizzazione sfruttando un prodotto gratuito.
Anche se non dispone di tutte le funzionalità avanzate offerte dagli
altri prodotti della stessa software house, come Workstation o ESX, offre
certamente grande flessibilità, in particolare per l’utilizzo all’interno di
gruppi di lavoro, grazie soprattutto alle funzionalità di controllo remoto e
di monitoring attraverso la rete.
VMware Server deve essere installato come demone su una
macchina che svolga funzioni di server e che sia dotata di adeguate
risorse hardware. Le macchine virtuali create sfruttano le risorse del
server, questo da il vantaggio di poterle controllare anche da un client
con limitate capacità di calcolo. L’accesso al server ed alle altre funzioni
112
offerte dal prodotto della casa californiana, richiedono ovviamente una
autenticazione che VMware Server permette di integrare con permessi e
criteri di protezione per le macchine virtuali disponibili.
Il client per l’accesso al server è VMware Server Console, un
pacchetto separato ed indipendente, disponibile anch’esso gratuitamente
sul sito di VMware. La console viene utilizzata per gestire le vm presenti
su una qualsiasi macchina dotata di VMware Server, e si può farlo
direttamente dallo stesso server oppure da una qualsiasi workstation
remota. Una feature molto interessante è la possibilità, per diverse
console, di connettersi contemporaneamente ad una virtual machine,
permettendo a più utenti di avere un accesso concorrente.
VMware Server è dotato anche di una interfaccia di gestione via
web, denominata VMware Management Interface (MUI), che non è un
alternativa alla server console, ma offre strumenti di controllo sull’uso
delle risorse da parte delle virtual machine in esecuzione [41][42].
4.5.1 Installazione e configurazione di VMWare
Come illustrato nel paragrafo precedente l’installazione della suite
VMware Server prevede l’utilizzo di tre pacchetti. Dopo aver provveduto
al download dell’ultima versione per Linux dei package, dal sito della
software house (http://www.vmware.com) si può procedere con la loro
113
installazione e configurazione. Tutte le fasi si intendono, dove non
esplicitamente specificato, speculari per entrambi i nodi del cluster.
VMWARE SERVER
Dopo aver scaricato il file VMware-server-1.0.1-29996.tar.gz nella
directory prescelta, si è provveduto alla decompressione dello stesso ed
al posizionamento nella cartella che ha creato.
alpha:~# tar zxvf VMware-server-1.0.1-29996.tar.gz
alpha:~# cd vmware-server-distrib
All’interno della cartella vmware-server-distrib si trova lo script che
è necessario eseguire per avviare l’installazione, tale file è scritto in Perl
ed è quindi indispensabile, per proseguire, che tutti i package relativi a
questo linguaggio siano installati nel sistema operativo.
alpha:~# ./vmware-install.pl
Lo script, nel corso dell’esecuzione, pone alcune domande in relazione ai
path in cui posizionare i vari componenti del programma. Conclusa la
fase di copia dei file viene automaticamente avviato un secondo script
(/usr/bin/vmware-config.pl) per l’impostazione dei parametri di
avvio del programma. È importante ricordare che questo comando sarà
utilizzabile anche in un secondo momento per qualsiasi eventuale
modifica alle configurazioni di VMware Server.
La prima cosa richiesta da vmware-config.pl è l’accettazione della
licenza d’uso del programma mentre la seconda è l’ubicazione dei
sorgenti del kernel.
114
Questo perché il Virtual Machine Monitor, già ampliamente
descritto nel capitolo 3 e che VMware chiama vmmon, viene compilato
appositamente per il kernel in uso in base alla macchina su cui dovrà
andare in esecuzione.
Proseguendo nella configurazione ci si addentra in una delle parti
più cruciali per la virtualizzazione di macchine server: il networking.
Dopo aver risposto in modo affermativo alla domanda sull’utilizzo della
rete da parte della macchine virtuali, si deve scegliere come mappare le
interfacce di rete utilizzate da vmmon, a questo scopo si possono
scegliere tre differenti modalità di funzionamento:

bridged:
è la configurazione di default, oltre che quella
maggiormente utilizzata, con questo sistema la scheda di rete
della macchina virtuale appare come un clone di quella reale e la
vm è come se fosse direttamente connessa alla stessa sottorete
della macchina che la ospita;

host only:
ogni macchina è dotata di una scheda di rete virtuale.
Si realizza in tal modo una sottorete indipendente tra le macchine
virtuali e la macchina host. Con questa modalità, nel caso si
desideri far navigare le vm, è necessario configurare il sistema
operativo ospite come gateway della sottorete attraverso adeguate
regole di routing;

NAT:
questa opzioni è del tutto simile alla host only con l’unica
differenza che la macchina host si occupa automaticamente di
115
effettuare il natting dei pacchetti provenienti dalla sottorete
virtuale.
In questo caso si è scelta l’opzione bridged in modo da poter assegnare
alle macchine virtuali, che fungeranno da server, un indirizzo IP pubblico
attraverso il quale offrire i loro servizi. La scheda di rete reale scelta per
il bridge è chiaramente l’interfaccia bond0.
Terminata la compilazione del modulo kernel relativo all’interfaccia
di rete vmnet0, corrispondente alla scheda virtuale di tipo bridged, va
impostata la porta sulla quale è in ascolto VMware Server ed attraverso
la quale VMware Server Console accede alle macchine virtuali.
Nella parte conclusiva della configurazione viene chiesto in quale
cartella si desidera memorizzare le macchine virtuali, per questa opzione
le soluzioni adottate sono differenti per i due nodi. Essendo il cluster in
configurazione Active/Active, in caso di crash di un nodo l’altro
prenderebbe in carico tutti i servizi, montando di conseguenza tutti i file
system condivisi. Non potendo per ovvi motivi effettuare il mounting di
due device sulla stessa cartella, si ha la necessità di definire un mount
point differente per ogni nodo. Questo ha portato alla scelta della cartella
/var/lib/vmware/VirtualMachinesALPHA
per il nodo alpha e la
directory /var/lib/vmware/VirtualMachinesBRAVO per il nodo bravo.
L’ultima operazione necessaria per finire l’installazione del prodotto
è l’inserimento di un numero seriale. VMware Server rimane comunque
un prodotto gratuito, ma per utilizzarlo liberamente richiede un serial
116
number che la società fornisce gratuitamente dietro la compilazione di un
form informativo presente sul sito web di VMware all’indirizzo
http://register.vmware.com/content/registration.html.
Il messaggio finale di avvio dei servizi sulla macchina host,
garantisce che tutta la procedura si è conclusa correttamente e si può
procedere con l’installazione degli altri componenti.
[...]
Starting VMware services:
Virtual machine monitor
Virtual Ethernet
Bridged networking on /dev/vmnet0
done
done
done
The configuration of VMware Server 1.0.1 build-29996 for
Linux for this running kernel completed successfully.
VMWARE MANAGEMENT INTERFACE
In modo analogo a quanto già fatto per la parte server, dopo aver
scaricato il file VMware-mui-1.0.1-29996.tar.gz in /usr/local/src
si procede alla decompressione e all’avvio dello script di installazione.
alpha:~# tar -zxvf VMware-mui-1.0.1-29996.tar.gz
alpha:~# cd vmware-mui-distrib
alpha:~#./vmware-install.pl
Viene richiesta l’accettazione della licenza d’uso e quali cartelle
utilizzare per i file del pacchetto dopodiché si avvia automaticamente lo
script di configurazione /usr/bin/vmware-config.pl.
Diversamente dal pacchetto Server, la Management Interface non ha
molti parametri di configurazione, è sufficiente definire il solo timeout
delle sessioni web per terminare le impostazioni. L’output finale del
comando ci comunica che tutto si è svolto in modo corretto.
117
[...]
Starting httpd.vmware:
The
configuration
of
completed successfully.
done
VMware
Management
Interface
Anche se tutto è andato a buon fine lo script non si occupa di impostare
l’avvio automatico al boot del sistema del demone relativo alla
Management Interface. Per questo motivo, come già accaduto per DRBD
ed Heartbeat, si deve agire in modo autonomo sul demone
httpd.vmware
tramite il comando sysv-rc-conf.
A questo punto si può aprire un browser qualunque e puntare
all’indirizzo di uno dei nodi, sulla porta 8222 oppure 8333, per
verificarne il funzionamento. Per ovvi motivi di sicurezza il sito utilizza
il protocollo HTTPS e di conseguenza al primo accesso verrà chiesto di
accettare il certificato SSL, che VMware a generato autonomamente,
solo dopo si potrà accedere alla maschera di login.
Figura 4-10 La finestra di login di VMware Management Interface.
VMWARE SERVER CONSOLE
L’ultimo
strumento
che
è
necessario
installare
per
rendere
completamente operativo il nostro virtual server, è anche il più facile e
118
veloce. Per l’installazione è infatti sufficiente effettuare il download del
package necessario nella solita cartella /usr/local/src, decomprimere
il pacchetto e lanciare lo script di installazione vmware-install.pl.
Dopo aver indicato le cartelle di default per la copia dei file ed aver
accettato la licenza d’uso, si avvierà automaticamente lo script
/usr/bin/vmware-config-server-console.pl
che senza porre alcuna
domanda concluderà la configurazione della console.
4.5.2 Installazione delle Virtual Machines
Con l’installazione delle macchine virtuali si entra nel vivo del progetto e
si cominciano a rendere produttivi i software configurati fino ad ora. Nel
corso del paragrafo si mostreranno i passi per la messa in opera di una
macchina virtuale. Nel caso specifico si installerà una distribuzione
SUSE Linux Enterprise Server 9 sul nodo alpha.centrale.unipg.it,
ma è evidente che la medesima procedura può essere adottata per
l’installazione delle altre vm di cui si ha necessità.
La prima cosa da fare è avviare la VMware Server Console la quale
chiede subito se ci si vuole collegare alla macchina locale (localhost)
oppure ad un server remoto tramite autenticazione, avendo effettuato il
login direttamente sul server, in questa situazione, si sceglie la prima
opzione.
119
Appare cosi l’interfaccia della console dalla quale si può partire per
creare una nuova Virtual Machine. Il pulsante al centro ―Create a new
virtual machine‖ è quello da premere per iniziare l’inserimento dei
parametri.
Figura 4-11 La schermata iniziale di VMware Server Console.
Le prime informazioni richieste riguardano la tipologia di sistema
operativo che dovrà essere ospitato (Red Hat, Suse, Windows XP,
Windows 2000 solo per citarne alcuni) e la posizione in cui si desidera
salvare i file. In questo caso la cartella scelta è ovviamente
/var/lib/vmware/VirtualMachinesALPHA
ma poiché il nome scelto
per la VM è echo.centrale.unipg.it ed il sistema operativo è SUSE, la
sottocartella in cui andremo a posizionare i file si chiamerà EchoSUSE.
Questa sequenza di passaggi sono visibili in modo dettagliato negli
snapshot riportati in figura 4.12.
120
Figura 4-12 Fasi iniziali della configurazione di una vm con VMware Server Console.
La parte successiva della configurazione si occupa dei device che il
Virtual Machine Monitor deve emulare, ed in particolare:

il numero dei processori: VMWare Server supporta infatti anche
un’emulazione biprocessore molto utile nei casi di vm con grande
carico di lavoro ed hardware reale compatibile.

la RAM: cruciale per il buon funzionamento di tutte le macchine,
nel caso di una vm deve essere adeguatamente calibrata per
evitare di lasciare l’host oppure la vm a corto di risorse.
In questo caso per definire il quantitativo giusto di RAM si
debbono tenere in considerazione due fattori: il primo riguarda
l’alta affidabilità, nel senso che in caso di crash di un nodo il
rimanente dovrà prendere in carico tutte le macchine virtuali e
121
dovrà quindi essere in grado di offrire sufficiente memoria. Il
secondo riguarda il fatto che alcune delle macchine virtuali che
andremo ad installare, non hanno grandi richieste e si
accontentano di 64 MB di RAM. Alla luce di quanto esposto e
considerando che entrambi i nodi hanno 1 GB di RAM, si è
deciso di assegnare alla macchina echo un quantitativo di RAM
pari 256 MB.

i dischi: considerando lo spazio a disposizione sullo storage
condiviso e lo scopo per cui vengono utilizzate le macchine
virtuali, si è quantificato che 4 GB siano sufficienti per un
corretto funzionamento. È importante notare che è stata
selezionata l’opzione ―Allocate all disk space now‖ per
ottimizzare il traffico sullo storage condiviso, evitando successivi
comandi di ampliamento dei file disco della macchina virtuale.

la rete: fondamentale per far comunicare le virtual machines con
l’esterno, va configurata in modalità bridged sull’interfaccia
bond0
per le motivazioni già spiegate nel paragrafo precedente.
Inserite tutte le informazioni necessarie al processo di creazione, si può
cliccare sul tasto ―Finish‖ e VMWare Server Console provvederà alla
creazione dei dischi virtuali. Conclusa l’allocazione dello spazio
necessario si tornerà alla schermata principale dalla quale premendo il
tasto ―Power On‖ si può avviare la macchina virtuale e procedere con
l’installazione del sistema operativo.
122
Figura 4-13 Configurazione hardware di una vm con VMware Server Console.
Figura 4-14 Installazione del sistema operativo in una macchina virtuale.
Riutilizzando in modo iterativo la procedura descritta in questo
paragrafo, si sono successivamente installate un totale di due macchine
123
virtuali per ogni nodo, secondo le caratteristiche sintetizzate nella tabella
seguente.
Nome Virtual Machines
charlie.centrale.unipg.it
(141.250.199.36)
delta.centrale.unipg.it
(141.250.199.37)
echo.centrale.unipg.it
(141.250.199.38)
foxtrot.centrale.unipg.it
(141.250.199.39)
S.O.
RAM
Disco
Nodo
Windows XP
64
4 GB
alpha
Kubuntu 6.10
256
4 GB
bravo
SUSE ES 9
256
4 GB
alpha
Windows 2000 AS
128
4 GB
bravo
Tabella 4-1 Caratteristiche delle macchine virtuali installate nei nodi.
VMWARE TOOLS
Dopo aver installato il sistema operativo su un qualsiasi computer, la
prima cosa da fare è ovviamente caricare i driver della scheda madre e
delle principali periferiche utilizzate. Allo stesso modo, al termine
dell’installazione di un sistema operativo all’interno di una macchina
virtuale, è quasi sempre necessario installare i driver forniti dal
produttore del software di virtualizzazione, che in questo caso si
chiamano VMware Tools. Questi tools possono essere caricati sul
sistema attraverso una delle voci di menu della console che simulerà
l’inserimento di un CD, con il software da installare, all’interno della
virtual machines.
Sarà sufficiente seguire le semplici indicazioni riportate sul video,
senza la necessità di impostare alcun parametro particolare, per portare a
124
termine l’installare dei driver ed ottenerne i relativi vantaggi nella
compatibilità e nelle prestazioni.
Figura 4-15 Le fasi di installazione dei VMware Tools in una macchina virtuale.
4.6 Integrazione di tutto il sistema
Tutti i software necessari sono stati installati e ciò di cui si ha bisogno a
questo punto del progetto, è una loro corretta integrazione finalizzata al
raggiungimento degli scopi che ci si è prefissati sin dall’inizio.
Per integrare il sistema è necessario fare in modo che heartbeat non
si preoccupi solo di gestire il mounting delle partizioni, come ha fatto
125
fino ad ora, ma sia in grado anche di avviare ed arrestare le macchine
virtuali del cluster.
Come
mostrato
nel
paragrafo
relativo
all’installazione
e
configurazione di heartbeat, per ogni risorsa che deve essere gestita viene
utilizzato
un
apposito
/etc/ha.d/resource.d/.
script
ubicato
nella
cartella
Nella stessa cartella, il pacchetto originale di
heartbeat, fornisce alcuni script preconfigurati per lo start e lo stop dei
servizi maggiormente utilizzati, tra questi si trovano quelli relativi a drbd,
raid ed lvm. In questa cartella, e nella documentazione di heartbeat, non
si fa però alcun riferimento all’utilizzo di questo software in
combinazione con macchine virtuali. Questa mancanza si verifica
principalmente per due motivazioni: la prima per la recente uscita in
versione gratuita di VMware Server e la seconda per l’assoluta novità
che il suo utilizzo con heartbeat rappresenta.
Nel corso di questo paragrafo si descriverà la realizzazione di uno
script apposito per il management delle risorse virtuali, da utilizzare
all’interno di heartbeat. Questo script rappresenta di fatto il fulcro di tutto
il progetto ed il punto di congiunzione di tutti i software di cui si è
parlato sin ora.
Prima di iniziare con la stesura del codice è bene comprendere quali
sono gli strumenti di cui si avrà bisogno. Andando ad operare con le
macchine virtuali di VMware Server è indispensabile avere a
disposizione un comando che consenta di agire direttamente sulle vm in
126
esecuzione. Proprio per venire in contro a queste esigenze, la software
house ha inserito nel suo pacchetto server una serie di comandi, tra i
quali il più interessante è vmware-cmd. Questo eseguibile si occupa di
interfacciarsi con il demone server e di svolgere determinate operazioni
sulle virtual machines, si riportano qui di seguito le principali opzioni
utilizzate nel corso della stesura dello script [39]:

getstate:
restituisce lo stato di esecuzione di una macchina
virtuale, i possibili valori sono on, off, suspended, stuck che
identifica uno stato in cui si richiede l’intervento dell’utente per
l’immissione di un determinato input oppure unknown;

start:
avvia un macchina virtuale precedentemente posta in stato
power-off oppure ne ripristina una sospesa;

suspend:

answer:
sospende una virtual machine;
permette all’utente di rispondere ad eventuali domande
poste dal software di virtualizzazione, relativamente ad una
macchina virtuale che è in attesa di avere informazioni;

getconfig:
restituisce il valore di un determinato parametro
relativo al file di configurazione della vm specificata;

getuptime:
accede alla varibile di uptime del sistema operativo
della macchina virtuale.
Chiarite le opzioni del commando che si andrà ad utilizzare, si può
iniziare la stesura dello script. Al fine di realizzare una procedura in
grado di adattarsi alla maggior parte delle situazioni, si è cercato di
127
renderla il più possibile parametrica sia riguardo alle informazioni di
input che alle funzionalità supportate, in previsione dei possibili utilizzi
all’interno di heartbeat.
Come in qualsiasi listato di un programma, nella parte iniziale si
sono definite ed impostate le variabili. Avendo pensato di introdurre un
certo livello di parametrizzazione si è deciso che la prima informazione
fornita debba indicare il file con estensione vmx associato alla macchina
virtuale sulla quale si vuole operare, mentre la seconda l’obiettivo che si
vuole raggiungere attraverso l’esecuzione dello script. Questi due
parametri sono stati rispettivamente associati alle variabili RISORSA e
COMANDO.
Contestualmente alle variabili associate ai parametri verranno
impostate anche tre costanti VMWARECMD, VM_PATH e ADMIN_MAIL che
identificano rispettivamente il path del comando vmware-cmd, il path
base in cui si trovano tutte le macchine virtuali e l’indirizzo degli
amministratori per i messaggi di notifica che lo script invierà.
VMWARECMD="/usr/bin/vmware-cmd"
VM_PATH="/var/lib/vmware/VirtualMachines"
RES="$1"
CMD="$2"
ADMIN_MAIL="[email protected]"
In funzione dell’operazione che si vuole eseguire sulla virtual machine
passata come parametro, si eseguiranno differenti procedure, è per questo
che il contenuto della variabile COMANDO verrà valutato da un ciclo di tipo
case
in base a due possibilità start oppure stop.
128
Nella fase di start si avvierà la macchina virtuale specificata nella
variabile RISORSA attraverso il comando $VMWARECMD $RISORSA start.
Questo comando non risolve però tutte le problematiche inerenti l’avvio
di una macchina virtuale. In alcuni test di funzionamento dello script
infatti, si sono evidenziate alcune difficoltà che è stato indispensabile
risolvere mediante l’aggiunta di ulteriori istruzioni.
Durante la fase di takeover del cluster, quando cioè le macchine
virtuali passano da un nodo all’altro, VMware Server segnala un errore
relativo all’uuid (Universally Unique Identifier). L’uuid è un codice
univoco che viene generato dal demone VMware ed assegnato ad una vm
sulla base dell’hardware utilizzato della macchina host, serve da un lato
ad identificare in modo univoco la macchina guest e dall’altro per la
creazione di codici unovoci relativi all’harware virtuale, come il MAC
address della schede di rete.
Con il cambio di nodo, l’uuid ricalcolato per la macchina virtuale
ovviamente cambia e VMware si accorge che il codice non è più
corrispondente. Per questo motivo vuole sapere se deve essere mantenuto
oppure si desidera generare un nuovo codice basandosi sull’hardware
della nuova macchina host. Poiché questo tipo di errore è bloccante,
ovvero non permette alla fase di start di procedere in modo autonomo
senza ottenere una risposta, si deve intervenire per risolverlo. La
soluzione adottata è quella di modificare il file di configurazione di ogni
129
virtual machines (il file con estensione vmx) aggiungendo o modificando
il parametro uuid.action nel modo seguente:
[...]
uuid.action = "keep"
L’adozione di questa impostazione fa in modo che l’uuid delle machine
virtuali non venga mai cambiato indipendentemente dalla macchina host
che si occupa della sua esecuzione, un ulteriore vantaggio derivante da
questa scelta è il mantenimento dello stesso MAC address indispensabile
per non pertere le connessioni attive in caso di un takeover graceful.
Un ulteriore problematica riscontrata in questo progetto, ma che si
verifica unicamente in presenza di nodi non perfettamente speculari dal
punto di vista hardware, riguarda il resume di una macchina virtuale
precedentemente sospesa su un nodo con processore differente. Al
verificarsi di questa situazione VMware Server avverte della possibilità
di malfunzionamenti dovuti alle differenze architetturali dei due
processori. Questa difficoltà è stata superata grazie all’opzione answer
del comando vmware-cmd che consente, con gli opportuni accorgimenti,
di rispondere alle eventuali domande poste dal demone. Poiché questa
situazione si verifica solamente in presenza di uno stato stuck della
macchina virtuale, la procedura di risposta è stata inserita in una struttura
condizionale if-fi, in modo da eseguire i comandi solo se richiesto.
if [ $($VMWARECMD $VM_PATH$RES getstate 2>&1 \
| sed 's/getstate() =//g') = "stuck" ]; then
echo 0 | $VMWARECMD $VM_PATH$RES answer
fi
130
Le configurazioni e le scelte si qui effettuate hanno permesso di generare
un ottima procedura per lo start, ma ulteriori test supplementari hanno
messo in evidenza una difficoltà oggettiva imputabile alla potenza dei
nodi.
Quando heartbeat prende in carico le risorse ed avvia gli script
associati, questi vengono lanciati in successione secondo l’elenco
definito nel file haresources. Una macchina virtuale impiega diverso
tempo per portare a termine la fase di boot, ma poichè lo script non
attende la fine di questo processo per passare il controllo allo script
successivo, può accadere che alcune virtual machines vengano avviate
praticamente in contemporanea. Tale situazione mette decisamente in
crisi le non eccessive risorse dei nodi, aumentando in modo significativo
il tempo totale di avvio delle macchine.
Questo problema è stato superato grazie all’idea di non terminare lo
script fino a quando la vm, per la quale è stato mandato in esecuzione,
non abbia completamente terminato la fase di boot. Per fare ciò si è
creato un sistema di attesa attiva, controllando lo stato del parametro
getuptime,
che conclude lo script solamente dopo un determinato lasso
di tempo calcolato sulla base dello stato precedente della macchina
virtuale. È evidente infatti che una macchina in stato suspended
impiegherà di certo meno tempo ad avviarsi di una macchina in stato
off.
131
if [ ${STARTUP_STATE//getstate() =/} = "off" ]; then
TIMER=60
elif [ ${STARTUP_STATE//getstate() =/} = "on" ]; then
TIMER=0
elif [ ${STARTUP_STATE//getstate() =/} = "suspended" ]; then
TIMER=èxpr $($VMWARECMD $VM_PATH$RES getuptime 2>&1 \
| sed 's/getuptime() =//g') + 15`
fi
while [
$($VMWARECMD $VM_PATH$RES getuptime 2>&1 \
| sed 's/getuptime() =//g') –l t $TIMER ]; do
wait
done
Concluso lo sviluppo dello script nella parte di start si è passati ad
analizzare quella di stop, che ha come scopo primario quello di arrestare
le macchine virtuali in caso di takeover graceful.
Al fine di velocizzare il più possibile la transizione delle risorse da
un nodo all’altro e per fare in modo che il takeover non provochi la
perdita delle sessioni stabilite dagli utenti con la macchina virtuale, si è
deciso di adottare la sospensione della virtual machines e non il loro
arresto.
Prima di procedere all’esecuzione del comando per l’ibernazione
della vm è indispensabile, onde evitare errori nell’esecuzione, controllare
che la macchina virtuale sia effettivamente in eseuzione. Questo è
attuabile attraverso un semplice controllo all’interno della cartella
/var/run
utilizzata dal sistema operativo per memorizzare i processi in
esecuzione.
if [ -d /var/run/vmware/ècho $VM_PATH$RES \
| sed 's/\//%2F/g' | sed 's/\./%2E/g'` ]; then
$VMWARECMD $VM_PATH$RES suspend
fi
132
Al termine del ciclo case si è pensato di inviare un messaggio di posta
elettronica agli indirizzi specificati nella variabile ADMIN_MAIL per
inviare alcune informazioni e notificare l’avvenuto avvio o sospensione
delle macchine virtuali sul nodo .
mailx -s "Virtual machine `$VMWARECMD $VM_PATH$RES \
getconfig displayName|sed 's/getconfig(displayName) \
=//g'` $CMD on `hostname`" $ADMIN_MAIL << EOF
Virtual Machine: `$VMWARECMD $VM_PATH$RES getconfig \
displayName | sed 's/getconfig(displayName) =//g'`
Status: `$VMWARECMD $VM_PATH$RES getstate \
| sed 's/getstate() =//g'`
Uptime: `$VMWARECMD $VM_PATH$RES getuptime \
| sed 's/getuptime() =//g'`
Config $VM_PATH$RES
EOF
Terminato lo script necessario all’integrazione tra heartbeat e VMware
Server, è indispensabile apportare alcune modifiche ai file di
configurazione di heartbeat stesso, questo per fare in modo che il codice
realizzato venga utilizzato e che le macchine virtuali possano entrare a
far parte, come risorse attive, del cluster in alta affidabilità scopo di
questo progetto.
Come prima cosa è necessario arrestare manualmente tramite
vmware-server-console
le macchine virtuali eventualmente avviate e
successivamente provvedere all’arresto di heartbeat su entrambi i nodi
del cluster.
alpha:~# /etc/init.d/heartbeat stop
Stopping High-Availability services:
Done.
bravo:~# /etc/init.d/heartbeat stop
Done.
133
A questo punto si deve aprire il file /etc/ha.d/haresources in
entrambi i nodi e modificare le righe relative alle risorse assegnate nel
modo seguente:
alpha drbddisk::drbd0 \
Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3 \
vmmanager::ALPHA/CharlieXP/CharlieXP.vmx \
vmmanager::ALPHA/EchoSUSE/EchoSUSE.vmx
bravo drbddisk::drbd1 \
Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3 \
vmmanager::BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx \
vmmanager::BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx
Concluse le modifiche al file, si può riavviare heartbeat e verificare,
come mostrato nella figura 4.16, che tutte le macchine virtuali
configurate si siano avviate in modo corretto e che i relativi messaggi di
posta elettronica siano stati spediti ai destinatari.
Figura 4-16 Avvio di heartbeat e test di funzionalità dello script realizzato.
134
Con queste ultime operazioni si può dire terminata la realizzazione dello
script per la gestione delle macchine virtuali e contestualmente si può
ritenere concluso anche il progetto sperimentale di integrare l’alta
affidabilità di heartbeat con il sistema di virtualizzazione di VMware
Server.
Nelle due figure seguenti si può osservare lo schema completo del
progetto e la foto delle macchine nella loro configurazione definitiva.
INTERNET / INTRANET
3C16794
Port Status
3C16794
Port Status
ä
Power
CHANNEL
bond0
BONDING eth2
ä
Power
1
2
3
4
5
6
7
8
141.250.199.23
CHANNEL
bond0 141.250.199.24
eth3
eth2 BONDING
IPFAIL
eth3
1
2
3
4
5
6
7
8
VM
VM
Windows XP
ttys0
ttys0
Kubuntu 6.10
(DELTA)
(CHARLIE)
VM
VM
HEARTBEAT
Suse 10.2
Windows 2000
(ECHO)
(FOXTROT)
/dev/drbd0
/dev/drbd1
eth0
0001
eth0
bond1
DRBD
bond1
192.168.1.23
CHANNEL
BONDING
192.168.1.24
eth1
WATCHDOG
0001
eth1
WATCHDOG
RAID 1 Software
RAID 1 Software
ALPHA
BRAVO
(KUBUNTU 6.06.1)
(KUBUNTU 6.06.1)
UPS SYSTEM
Figura 4-17 Schema finale del progetto.
135
Figura 4-18 Foto del cluster nella configurazione definitiva.
4.7 Testing del progetto
La fase di testing del progetto consiste nel simulare due potenziali
situazioni critiche e verificare a posteriori che il comportamento del
cluster configurato sia adeguato alle aspettative.
Nel primo esperimento si effettuerà un takeover graceful, ovvero si
sposteranno tutte le risorse su un unico nodo, imitanto un caso tipico di
intervento programmato da parte dell’amministratore. Nel secondo test
verrà invece simulato un crash completo del sistema, attraverso un
intervento diretto sul cavo di alimentazione di uno dei nodi.
136
TAKEOVER GRACEFUL
Uno spostamento dei resource group effettuato in modo controllato,
prevede l’arresto su uno dei nodi del demone heartbeat, il quale
chiudendosi richiama lo script vmmanager per la sospensione delle
macchine virtuali. Per controllare in modo attento l’evolversi della
situazione e verificarne il corretto andamento, è necessario monitorare in
entrambe le macchine i log generati da heartbeat all’interno del file
/var/log/ha-log.
I comandi ping e ssh possono essere invece
utilizzati per definire l’ammontare del downtime subito dagli utenti nel
corso dell’intervento e per verificare che le sessioni aperte con le
macchine virtuali prima della migrazione non siano andate perdute ma
siano ancora attive e funzionanti.
Come prima cosa si apra una shell sul nodo bravo e si esegua lo
shutdown di heartbeat:
bravo:~# /etc/init.d/heartbeat stop
Done.
Analizzando dettagliatamente i log del nodo bravo riportati nella pagina
seguente, si può notare come le operazioni di rilascio delle risorse
avvengano in sequenza: prima la sospensione delle virtual machines a
carico del nodo tramite vmmanager, successivamente l’unmounting del
file system utilizzato per la memorizzazione delle macchine virtuali, poi
l’arrestato del demone di DRBD ed infine il killing di tutti i processi
heartbeat ancora rimasti.
137
info: Heartbeat shutdown in progress. (6134)
info: Giving up all HA resources.
[...]
info: Releasing resource group: bravo drbddisk::drbd1
Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO:
:ext3 vmmanager::BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx
info: Running /etc/ha.d/resource.d/vmmanager
BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx stop
BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx stop
info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd1
/var/lib/vmware/VirtualMachinesBRAVO ext3 stop
INFO: Running stop for /dev/drbd1 on
/var/lib/vmware/VirtualMachinesBRAVO
INFO: Trying to unmount /var/lib/vmware/VirtualMachinesBRAVO
INFO: unmounted /var/lib/vmware/VirtualMachinesBRAVO successfully
INFO: Success
info: Running /etc/ha.d/resource.d/drbddisk drbd1 stop
info: All HA resources relinquished.
info: killing /usr/lib/heartbeat/ipfail process group 6158 with
signal 15
info: killing HBWRITE process 6138 with signal 15
[...]
info: bravo Heartbeat shutdown complete.
Una successiva analisi dei log di alpha, mostra invece la segnalazione
dello shutdown di heartbeat dall’altro nodo e il conseguente inizio delle
operazioni per la presa in carico delle risorse. Nelle ultime righe si può
notare come la macchina bravo non risponda più ad alcun segnale e
venga pertanto dichiarata dead.
info:
info:
[...]
info:
info:
info:
info:
INFO:
INFO:
info:
Received shutdown notice from 'bravo'.
Resources being acquired from bravo.
Taking over resource group drbddisk::drbd1
Acquiring resource group: bravo drbddisk::drbd1
Running /etc/ha.d/resource.d/drbddisk drbd1 start
Running /etc/ha.d/resource.d/Filesystem /dev/drbd1
/var/lib/vmware/VirtualMachinesBRAVO ext3 start
Running start for /dev/drbd1 on
Success
Running /etc/ha.d/resource.d/vmmanager
BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx start
138
BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx start
info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources
acquired
info: mach_down takeover complete for node bravo.
info: mach_down takeover complete.
WARN: node bravo: is dead
info: Dead node bravo gave up resources.
info: Link bravo:bond0 dead.
info: Link bravo:bond1 dead.
info: Link bravo:/dev/ttyS0 dead.
Come già accennato ad inizio paragrafo, nel corso del takeover si sono
tenute sotto controllo le macchine virtuali del nodo bravo mediante il
comando ping. Come mostra l’output qui di seguito, lo spostamento
delle risorse ha impiegato solo pochi secondi per concludersi ed inoltre le
sessioni aperte dagli utenti prima della sospensione, siano esse ssh, http
oppure ftp, sono rimaste intatte dopo il ripristino, chiaro indice della
totale trasparenza dell’operazione.
[mirco@lillo ~]$ ping -i 5 delta.centrale.unipg.it
PING delta.centrale.unipg.it (141.250.199.37) 56(84) bytes of data.
From 141.250.199.20 icmp_seq=5 Destination Host Unreachable
[mirco@lillo ~]$ ping -i 5 foxtrot.centrale.unipg.it
PING foxtrot.centrale.unipg.it (141.250.199.39) 56(84) bytes of data.
64 bytes from 141.250.199.39: icmp_seq=10 ttl=128 time=1008 ms
139
Figura 4-19 La MUI mostra lo stato delle quattro macchine virtuali sul nodo alpha .
Verificato che il takeover si è svolto correttamente e che le risorse sono
migrate in maniera trasparente per l’utente, si può ripristinare lo stato
iniziale riavviando heartbeat sul nodo bravo. In questo caso il demone
richiede immediatamente le sue risorse ad alpha, il quale, resosi conto
dello stato attivo dell’altro nodo, rilascia il resource group permettendo a
bravo
alpha,
di riportare la
situazione allo stato originale. I log del nodo
qui sotto riportati, mostrano la sequenza degli eventi appena
descritta.
info:
info:
info:
info:
info:
info:
info:
info:
info:
info:
info:
info:
info:
Heartbeat restart on node bravo
Link bravo:/dev/ttyS0 up.
Status update for node bravo: status init
Link bravo:bond0 up.
Link bravo:bond1 up.
Status update for node bravo: status up
all clients are now paused
Status update for node bravo: status active
remote resource transition completed.
alpha wants to go standby [foreign]
all clients are now resumed
standby: bravo can take our foreign resources
give up foreign HA resources (standby).
140
info: Releasing resource group: bravo drbddisk::drbd1
BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx stop
BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx stop
info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd1
/var/lib/vmware/VirtualMachinesBRAVO ext3 stop
INFO: Running stop for /dev/drbd1 on
INFO: Trying to unmount /var/lib/vmware/VirtualMachinesBRAVO
INFO: unmounted /var/lib/vmware/VirtualMachinesBRAVO successfully
INFO: Success
info: Running /etc/ha.d/resource.d/drbddisk drbd1 stop
info: foreign HA resource release completed (standby).
info: Local standby process completed [foreign].
WARN: 1 lost packet(s) for [bravo] [51:53]
info: remote resource transition completed.
info: No pkts missing from bravo!
info: Other node completed standby takeover of foreign resources.
Tutti i passaggi inerenti le macchine virtuali sono visualizzabili sul client
di posta elettronica degli amministratori ove ogni operazione di avvio e
arresto delle macchine virtuali è debitamente segnalato da un messaggio
di posta elettronica inviato dallo script vmmanager.
Figura 4-20 Il client Kmail mostra la sequenza di messaggi di up e down delle vm.
141
CRASH DEL SISTEMA
Questa simulazione è abbastanza dura ma mette realmente alla prova il
cluster che è stato realizzato permettendo di verificarne il funzionamento
in situazioni critiche. Scollegando, a sistema attivo, il cavo di
alimentazione del nodo bravo si simulerà un malfunzionamento
hardware fatale, che costringerà alpha ad accorgersi autonomamente del
problema ed a ripristinare le macchine virtuali nel minor tempo possibile.
WARN:
WARN:
info:
info:
info:
info:
info:
info:
info:
info:
info:
info:
INFO:
INFO:
info:
info:
info:
info:
info:
node bravo: is dead
No STONITH device configured.
Resources being acquired from bravo.
Link bravo:/dev/ttyS0 dead.
Link bravo:bond0 dead.
Link bravo:bond1 dead.
Running /etc/ha.d/rc.d/status status
Taking over resource group drbddisk::drbd1
Acquiring resource group: bravo drbddisk::drbd1
Local Resource acquisition completed.
Running /etc/ha.d/resource.d/drbddisk drbd1 start
Running /etc/ha.d/resource.d/Filesystem /dev/drbd1
/var/lib/vmware/VirtualMachinesBRAVO ext3 start
Running start for /dev/drbd1 on
Success
BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx start
BRAVO/Foxtrot2000AS/Foxtrot2000AS.vmx start
/usr/lib/heartbeat/mach_down: nice_failback: foreign resources
acquired
mach_down takeover complete for node bravo.
mach_down takeover complete.
Nonostante il test effettuato sia un pò drastico, il nodo alpha ha reagito
secondo le aspettative avviando correttamente tutte le macchine virtuali,
mostrando inoltre l’effettiva forza e potenzialità del progetto. I tempi di
ripristino sono leggermente più lunghi rispetto ad un takeover graceful,
142
ma questo è comprensibile trattandosi di un boot della macchina virtuale
a seguito di crash di sistema e non di un meno complesso resume.
Lo schema riportato nella figura di seguito mostra infine lo stato del
progetto in caso di takeover delle risorse sia esso graceful o dovuto ad al
crash di uno dei nodi.
Figura 4-21 Schema del progetto a seguito del crash simulato.
143
————————————————————————————— CONCLUSIONI
Conclusioni
Il presente lavoro di tesi, sviluppato presso la Ripartizione Servizi
Informatici e Statistici dell’Università degli Studi di Perugia, è stato
realizzato con l’obiettivo di migliorare l’efficienza, l’affidabilità e
l’ottimizzazione delle risorse presenti nella sala server attraverso
l’integrazione sperimentale di vari sistemi software.
Molte della macchine utilizzate come server dall’Ateneo, risultano
sovradimensionate rispetto alla potenza di calcolo richiesta dagli
applicativi in esse installati. Questa situazione rappresenta di fatto un
dispendio da vari punti di vista: dal lato economico per gli ingenti
investimenti immobilizzati, da quello delle risorse umane per la necessità
da parte degli amministratori di monitorare numerose macchine ed infine
dal punto di vista dell’utente che, in caso di malfunzionamenti hardware
delle macchine, deve subire fastidiose e spesso prolungate interruzioni
dei servizi.
Tutte queste motivazioni hanno condotto verso la decisione di
sperimentare
un
sistema
che
consentisse
la
virtualizzazione
dell’hardware al fine di ottimizzare le risorse. Nel contempo si è anche
cercato di migliorare il più possibile l’affidabilità complessiva dei sistemi
144
————————————————————————————— CONCLUSIONI
riconfigurati per diminuire di conseguenza l’eventuale discontinuità dei
servizi.
Le diverse problematiche emerse sono state tutte risolte mediante
l’utilizzo di vari software, ognuno dei quali specializzato in un
particolare ambito del progetto: DRBD per la realizzazione e la gestione
dello storage condiviso, Heartbeat per il management dell’alta
affidabilità e VMware Server per la virtualizzazione dell’hardware. Alla
configurazione e messa in funzione dei software si è aggiunto poi un
notevole lavoro di integrazione degli stessi, che ha portato alla
progettazione e alla realizzazione di uno script per la gestione delle
macchine virtuali indispensabile per il corretto funzionamento di tutto il
lavoro.
Ritengo che quanto svolto in questa tesi sia un interessante ed
innovativo
esempio
di
come
l’utilizzo
di
diverse
tecnologie,
adeguatamente integrate tra loro, possa migliorare la qualità e
l’affidabilità dei servizi di rete all’interno di una struttura, garantendo
una relativamente modesta difficoltà di configurazione ed un
considerevole risparmio economico.
Vorrei inoltre aggiungere che l’esperienza acquisita nel corso della
realizzazione di questo lavoro, ha posto le basi per l’avvio di un nuovo
progetto di sperimentazione analogo ma basato su ambiente Microsoft
che porterà alla messa in opera di un secondo cluster.
145
————————————————————————————— CONCLUSIONI
Ciò che tengo infine a sottolineare è che l’implementazione
dell’ambiente oggetto di questa tesi, attraverso l’utilizzo di software
completamente gratuiti, rappresenta forse la prima installazione coerente
e funzionante di cui si abbia una traccia evidente; in altre parole, ad oggi
non si hanno analoghi feedback in internet e nella comunità scientifica di
progetti analoghi che utilizzino gli stessi strumenti.
146
———————————————— APPENDICE A – I FILE DEL SISTEMA OPERATIVO
Appendice A
I file del Sistema Operativo
A-1 I file /etc/network/interfaces
# ALPHA
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0
# The primary network interface
auto bond0
address 141.250.199.23
netmask 255.255.255.192
gateway 141.250.199.62
# The secondary network interface
auto bond1
address 192.168.1.23
netmask 255.255.255.0
network 192.168.1.0
147
# BRAVO
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0
# The primary network interface
auto bond0
address 141.250.199.24
netmask 255.255.255.192
gateway 141.250.199.62
# The secondary network interface
auto bond1
address 192.168.1.24
netmask 255.255.255.0
network 192.168.1.0
148
A-2 Il file /etc/modprobe.d/arch/i386
alias parport_lowlevel parport_pc
alias binfmt-0064 binfmt_aout
alias binfmt-332 iBCS
alias bond0 bonding
alias bond1 bonding
options bonding mode=3 max_bonds=2 miimon=100 downdelay=200
updelay=200
options softdog nowayout=0
149
A-3 Elenco dei pacchetti installati
acpi
acpi-support
acpid
adduser
adept
akregator
alsa-base
alsa-utils
amarok
amarok-xine
anacron
apmd
app-install-data
appres
apt
apt-utils
aptitude
ark
arts
artsbuilder
aspell
aspell-en
at
autoconf
automake1.4
autotools-dev
base-files
base-passwd
bash
bc
beforelight
belocs-locales-bin
bicyclerepair
bind9-host
binutils
binutils-static
bison
bitmap
blt
bluez-cups
bluez-pcmcia-support
bluez-utils
bogofilter
bogofilter-bdb
bogofilter-common
brltty
bsdmainutils
bsdutils
bsh
build-essential
busybox-initramfs
bzip2
ca-certificates
cdparanoia
cdrdao
cdrecord
console-common
console-data
console-tools
coreutils
cpio
cpp
cpp-4.0
cron
cupsys
cupsys-bsd
cupsys-client
cupsys-driver-gutenprint
dbus
dc
debconf
debconf-i18n
debianutils
debtags
defoma
dhcp3-client
dhcp3-common
dictionaries-common
diff
discover1
discover1-data
diveintopython
dmidecode
dmsetup
dnsutils
doc-base
doc-debian
docbook-xml
dosfstools
dpkg
dpkg-dev
dselect
dvd+rw-tools
e2fslibs
e2fsprogs
ed
editres
eject
enscript
esound-common
ethtool
evms
evms-ncurses
example-content
fastjar
fdutils
file
findutils
finger
firefox
firefox-themes-ubuntu
flex
fontconfig
foo2zjs
foomatic-db
foomatic-db-engine
foomatic-db-gutenprint
foomatic-db-hpijs
foomatic-filters
foomatic-filters-ppds
fortune-mod
fortunes-min
freeglut3
fstobdf
ftp
g++
g++-4.0
gamin
gcc
gcc-3.3-base
gcc-4.0
gcc-4.0-base
gcj-4.1-base
gettext
gettext-base
gij-4.1
gnupg
grep
grepmap
groff-base
grub
gs-common
gs-esp
gsfonts
gtk2-engines-gtk-qt
gwenview
gzip
hal
hdparm
hicolor-icon-theme
hostname
hotkey-setup
hpijs
hplip
hplip-data
hplip-ppds
hwdata
iceauth
ico
ifenslave
ifenslave-2.6
ifupdown
ijsgutenprint
imagemagick
imake
info
initramfs-tools
initscripts
inputattach
installation-report
intltool-debian
iproute
iptables
iputils-arping
iputils-ping
iputils-tracepath
irssi
java-common
java-gcj-compat
jfsutils
k3b
kaddressbook
kaffeine
kaffeine-xine
kamera
karm
katapult
kate
kaudiocreator
kcontrol
kcron
kde-guidance
kde-i18n-it
kde-style-lipstik
kde-systemsettings
150
kdeadmin-kfile-plugins
kdebase-bin
kdebase-data
kdebase-kio-plugins
kdebluetooth
kdegraphics-kfile-plugins
kdelibs-bin
kdelibs-data
kdelibs4c2a
kdemultimedia-kfile-plugins
kdemultimedia-kio-plugins
kdenetwork-filesharing
kdenetwork-kfile-plugins
kdepasswd
kdepim-kio-plugins
kdepim-kresources
kdepim-wizards
kdeprint
kdesktop
kdm
kdnssd
keep
kfind
kghostview
khelpcenter
kicker
kio-apt
kio-locate
klaptopdaemon
klibc-utils
klipper
klogd
kmail
kmailcvt
kmenuedit
kmilo
kmix
kmplayer-base
kmplayer-konq-plugins
knetworkconf
knotes
koffice-data
koffice-libs
konq-plugins
konqueror
konqueror-nsplugins
konsole
kontact
konversation
kooka
kopete
korganizer
kpdf
kpf
kppp
krdc
krfb
krita
krita-data
kscd
kscreensaver
ksmserver
ksnapshot
ksplash
ksplash-engine-moodin
ksvg
ksysguard
ksysguardd
ksystemlog
ksysv
ktorrent
kubuntu-artwork-usplash
kubuntu-default-settings
kubuntu-desktop
kubuntu-docs
kubuntu-konqueror-shortcuts
kwalletmanager
kwin
kwin-style-crystal
landscape-client
language-pack-en
language-pack-en-base
language-pack-kde-en
language-pack-kde-en-base
language-pack-kde-it
language-pack-kde-it-base
language-selector-common
language-selector-qt
language-support-en
laptop-detect
laptop-mode-tools
less
lftp
libacl1
libadns1
libakode2
libao2
libapm1
libart-2.0-2
libarts1-akode
libarts1c2a
libartsc0
libasound2
libaspell15
libatk1.0-0
libatm1
libattr1
libaudio2
libaudiofile0
libavahi-client3
libavahi-common-data
libavahi-common3
libavahi-qt3-1
libbind9-0
libblkid1
libblockfile1
libbluetooth1
libbrlapi1
libbz2-1.0
libbz2-dev
libc6
libc6-dev
libc6-i686
libcairo2
libcap1
libcdparanoia0
libcomerr2
libconsole
libcupsimage2
libcupsys2
libcurl3
libcurl3-gnutls
libcurses-perl
libcurses-ui-perl
libdb2
libdb4.3
libdbus-1-2
libdbus-glib-1-2
libdbus-qt-1-1c2
libdevmapper1.02
libdiscover1
libdmx1
libdns21
libdrm2
libedit2
libelfg0
libesd-alsa0
libevms-2.5
libexif12
libexpat1
libflac++5c2
libflac7
libfontconfig1
libfontenc1
libfreetype6
libfribidi0
libfs6
libgadu3
libgamin0
libgc1c2
libgcc1
libgcj-common
libgcj7
libgcj7-jar
libgcrypt11
libgcrypt11-dev
libgd2-noxpm
libgdbm3
libgdk-pixbuf2
libgeoip1
libgl1-mesa
libgl1-mesa-dri
libglade0
libglade2-0
libglib1.2
libglib2.0-0
libglib2.0-dev
libglu1-mesa
libglut3
libgmp3c2
libgnucrypto-java
libgnutls-dev
libgnutls12
libgpg-error-dev
libgpg-error0
libgpgme11
libgphoto2-2
libgphoto2-port0
libgpmg1
libgpod0
libgsl0
libgstreamer-pluginsbase0.10-0
libgstreamer0.10-0
libgtk1.2
libgtk1.2-common
libgtk2.0-0
libgtk2.0-bin
libgtk2.0-common
libgutenprint2
libhal-storage1
libhal1
libhsqldb-java
libice6
libicu34
libid3-3.8.3c2a
libidl0
libidn11
libieee1284-3
libifp4
151
libijs-0.35
libisc11
libisccc0
libisccfg1
libiw28
libjasper-1.701-1
libjasper-runtime
libjaxp1.2-java
libjessie-java
libjline-java
libjpeg-progs
libjpeg62
libk3b2
libkcal2b
libkcddb1
libkdepim1a
libkipi0
libkleopatra1
libklibc
libkmime2
libkonq4
libkpimexchange1
libkpimidentities1
libkrb53
libkscan1
libksieve0
libktnef1
liblcms1
libldap2
liblocale-gettext-perl
liblockdev1
libltdl3
libltdl3-dev
liblwres9
liblzo1
libmagic1
libmagick9
libmdbtools
libmimelib1c2a
libmng1
libmodplug0c2
libmpcdec3
libmusicbrainz4c2a
libmysqlclient15off
libncurses5
libncurses5-dev
libncursesw5
libneon25
libnet1
libnet1-dev
libnetcdf3
libnewt0.51
libnspr4
libnss-mdns
libnss3
libogg0
liboggflac3
libopencdk8
libopencdk8-dev
libopenexr2c2a
libopenobex-1.0-0
liborbit2
libpam-foreground
libpam-modules
libpam-runtime
libpam0g
libpam0g-dev
libpango1.0-0
libpango1.0-common
libpaper1
libparted1.6-13
libpcap0.8
libpcre3
libperl5.8
libpisock8
libpng12-0
libpoppler1
libpoppler1-qt
libpopt-dev
libpopt0
libportaudio0
libpq4
libpythonize0
libqt3-mt
libraptor1
librasqal0
libraw1394-5
librdf0
libreadline5
librecode0
librsync1
libruby1.8
libsamplerate0
libsane
libsasl2
libsasl2-modules
libscim8c2a
libscrollkeeper0
libsdl1.2debian
libsdl1.2debian-alsa
libselinux1
libsensors3
libsepol1
libservlet2.3-java
libsigc++-2.0-0c2a
libskim0
libslang2
libslp1
libsm6
libsmbclient
libsndfile1
libsnmp-base
libsnmp9
libspeex1
libsqlite0
libsqlite3-0
libss2
libssl0.9.8
libstartup-notification0
libstdc++5
libstdc++6
libstdc++6-4.0-dev
libstlport4.6c2
libsysfs2
libtag1c2a
libtasn1-2
libtasn1-2-dev
libtdb1
libterm-readkey-perl
libtext-charwidth-perl
libtext-iconv-perl
libtext-wrapi18n-perl
libtheora0
libtiff4
libtool
libtunepimp2c2a
libtunepimp3
libunicode-string-perl
libuniconf4.2
libusb-0.1-4
libuuid1
libvisual-0.4-0
libvorbis0a
libvorbisenc2
libvorbisfile3
libwpd8c2a
libwrap0
libwvstreams4.2-base
libwvstreams4.2-extras
libx11-6
libxalan2-java
libxau6
libxaw7
libxcomposite1
libxcursor1
libxdamage1
libxdmcp6
libxerces2-java
libxext6
libxfixes3
libxfont1
libxft2
libxi6
libxine-main1
libxinerama1
libxkbfile1
libxml1
libxml2
libxml2-dev
libxmlsec1
libxmlsec1-nss
libxmlsec1-openssl
libxmu6
libxmuu1
libxp6
libxplc0.3.13
libxpm4
libxrandr2
libxrender1
libxslt1.1
libxss1
libxt-java
libxt6
libxtrap6
libxtst6
libxv1
libxvmc1
libxxf86dga1
libxxf86misc1
libxxf86vm1
linux-386
linux-headers-2.6.15-27
linux-headers-2.6.15-27-386
linux-image-2.6.15-27-386
linux-image-386
linux-kernel-headers
linux-restricted-modules2.6.15-27-386
linux-restricted-modules-386
linux-restricted-modulescommon
linux-sound-base
listres
locales
login
logrotate
lsb-base
lsb-release
lshw
lshw-common
152
lsof
ltrace
lvm-common
lvm2
m4
mailx
make
makedepend
makedev
man-db
manpages
mawk
mcpp
mdadm
mdetect
memtest86+
menu-xdg
mesa-utils
mii-diag
mime-support
min12xxw
mkisofs
module-init-tools
mount
mozilla-firefox-locale-en-gb
mtr-tiny
myspell-en-gb
myspell-en-us
mysql-common
nano
ncurses-base
ncurses-bin
net-tools
netbase
netcat
nmap
ntpdate
nvidia-kernel-common
oclock
openoffice.org
openoffice.org-base
openoffice.org-calc
openoffice.org-common
openoffice.org-core
openoffice.org-draw
openoffice.org-help-en-us
openoffice.org-impress
openoffice.org-java-common
openoffice.org-kde
openoffice.org-l10n-common
openoffice.org-l10n-en-gb
openoffice.org-l10n-en-us
openoffice.org-l10n-en-za
openoffice.org-math
openoffice.org-thesaurus-enus
openoffice.org-writer
openssh-client
openssh-server
openssl
parted
passwd
patch
pciutils
pcmcia-cs
pcmciautils
perl
perl-base
perl-modules
perl-suid
pkg-config
pmount
pnm2ppa
po-debconf
poppler-utils
popularity-contest
poster
postfix
powermanagement-interface
powermgmt-base
powernowd
ppp
pppconfig
pppoeconf
procps
psmisc
psutils
pykdeextensions
python
python-adns
python-apt
python-cddb
python-clientcookie
python-crypto
python-egenix-mxproxy
python-egenix-mxstack
python-egenix-mxtexttools
python-egenix-mxtools
python-epydoc
python-eunuchs
python-examples
python-gadfly
python-gd
python-gdbm
python-genetic
python-geoip
python-glade-1.2
python-glade2
python-gnupginterface
python-gtk-1.2
python-gtk2
python-htmlgen
python-htmltmpl
python-id3lib
python-imaging
python-imaging-sane
python-jabber
python-kde3
python-kjbuckets
python-ldap
python-minimal
python-mysqldb
python-netcdf
python-newt
python-numeric
python-pam
python-parted
python-pexpect
python-pgsql
python-pisock
python-pqueue
python-pyao
python-pylibacl
python-pyogg
python-pyopenssl
python-pyorbit
python-pyvorbis
python-pyxattr
python-qt3
python-reportlab
python-simpletal
python-soappy
python-sqlite
python-stats
python-syck
python-tk
python-unit
python-uno
python-xdg
python-xml
python-xmpp
python2.4
python2.4-adns
python2.4-apt
python2.4-cairo
python2.4-clientcookie
python2.4-crypto
python2.4-dbus
python2.4-dev
python2.4-dictclient
python2.4-egenix-mxdatetime
python2.4-egenix-mxproxy
python2.4-egenix-mxstack
python2.4-egenix-mxtexttools
python2.4-egenix-mxtools
python2.4-epydoc
python2.4-eunuchs
python2.4-examples
python2.4-gadfly
python2.4-gd
python2.4-gdbm
python2.4-geoip
python2.4-glade2
python2.4-gobject
python2.4-gtk2
python2.4-htmlgen
python2.4-htmltmpl
python2.4-id3lib
python2.4-imaging
python2.4-imaging-sane
python2.4-jabber
python2.4-kde3
python2.4-kjbuckets
python2.4-ldap
python2.4-librdf
python2.4-libxml2
python2.4-libxslt1
python2.4-minimal
python2.4-mysqldb
python2.4-numeric
python2.4-pam
python2.4-pexpect
python2.4-pgsql
python2.4-pycurl
python2.4-pylibacl
python2.4-pyopenssl
python2.4-pyorbit
python2.4-pyxattr
python2.4-qt3
python2.4-reportlab
python2.4-simpletal
python2.4-sip4-qt3
python2.4-soappy
python2.4-sqlite
python2.4-syck
python2.4-tk
python2.4-unit
python2.4-xml
python2.4-xmpp
qca-tls
153
qobex
radeontool
rdiff-backup
readahead
readline-common
reiser4progs
reiserfsprogs
reportbug
rsync
ruby
ruby1.8
samba-common
scim-qtimm
screen
scrollkeeper
sed
sessreg
sgml-base
sgml-data
sip
skim
slocate
smartdimmer
smbclient
smproxy
speedcrunch
ssh
strace
sudo
swig
sysklogd
sysv-rc
sysv-rc-conf
sysvinit
tar
tcl8.4
tcpd
tcpdump
telnet
thunderbird-locale-en-gb
time
tk8.4
toshset
traceroute
ttf-arabeyes
ttf-arphic-uming
ttf-baekmuk
ttf-bengali-fonts
ttf-bitstream-vera
ttf-dejavu
ttf-devanagari-fonts
ttf-freefont
ttf-gentium
ttf-gujarati-fonts
ttf-indic-fonts
ttf-kannada-fonts
ttf-kochi-gothic
ttf-kochi-mincho
ttf-lao
ttf-malayalam-fonts
ttf-mgopen
ttf-opensymbol
ttf-oriya-fonts
ttf-punjabi-fonts
ttf-tamil-fonts
ttf-telugu-fonts
ttf-thai-tlwg
ubuntu-keyring
ubuntu-minimal
ubuntu-standard
ucf
udev
unzip
usbutils
usplash
util-linux
uuid-dev
vbetool
viewres
vim
vim-common
vim-runtime
vorbis-tools
w3m
wamerican
wbritish
wget
whiptail
wireless-tools
wlassistant
wpasupplicant
wvdial
x-ttcidfont-conf
x-window-system-core
x11-common
x11perf
xauth
xbase-clients
xbiff
xcalc
xclipboard
xclock
xconsole
xcursor-themes
xcursorgen
xditview
xdpyinfo
xdriinfo
xev
xeyes
xf86dga
xfd
xfonts-100dpi
xfonts-75dpi
xfonts-base
xfonts-scalable
xfonts-utils
xfontsel
xfsprogs
xgamma
xgc
xhost
xinetd
xinit
xkbutils
xkeyboard-config
xkill
xload
xlogo
xlsatoms
xlsclients
xlsfonts
xmag
xman
xmessage
xml-core
xmodmap
xmore
xpmutils
xprop
xrandr
xrdb
xrefresh
xresprobe
xrgb
xserver-xorg
xserver-xorg-core
xserver-xorg-driver-all
xserver-xorg-driver-apm
xserver-xorg-driver-ark
xserver-xorg-driver-ati
xserver-xorg-driver-chips
xserver-xorg-driver-cirrus
xserver-xorg-driver-cyrix
xserver-xorg-driver-dummy
xserver-xorg-driver-fbdev
xserver-xorg-driver-glint
xserver-xorg-driver-i128
xserver-xorg-driver-imstt
xserver-xorg-driver-mga
xserver-xorg-driver-neomagic
xserver-xorg-driver-newport
xserver-xorg-driver-nsc
xserver-xorg-driver-nv
xserver-xorg-driverrendition
xserver-xorg-driver-s3
xserver-xorg-driver-s3virge
xserver-xorg-driver-savage
xserver-xorg-driversiliconmotion
xserver-xorg-driver-sis
xserver-xorg-driver-sisusb
xserver-xorg-driver-tdfx
xserver-xorg-driver-tga
xserver-xorg-driver-trident
xserver-xorg-driver-tseng
xserver-xorg-driver-v4l
xserver-xorg-driver-vesa
xserver-xorg-driver-vga
xserver-xorg-driver-via
xserver-xorg-driver-vmware
xserver-xorg-driver-voodoo
xserver-xorg-input-all
xserver-xorg-inputelographics
xserver-xorg-input-evdev
xserver-xorg-input-kbd
xserver-xorg-input-mouse
xserver-xorg-input-synaptics
xserver-xorg-input-wacom
xset
xsetmode
xsetpointer
xsetroot
xsm
xstdcmap
xterm
xtrap
xutils
xvidtune
xvinfo
xwd
xwininfo
xwud
zip
zlib1g
zlib1g-dev
154
—————————————————————— APPENDICE B – I FILE DI DRBD
Appendice B
I file di DRBD
B-1 File drbd.conf
#
#
#
#
#
#
#
#
#
drbd.conf example
parameters you _need_ to change are the hostname, device, disk,
meta-disk, address and port in the "on <hostname> {}" sections.
you ought to know about the protocol, and the various timeouts.
you probably want to set the rate in the syncer sections
#
# NOTE common pitfall:
# rate is given in units of _byte_ not bit
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
increase timeout and maybe ping-int in net{}, if you see
problems with "connection lost/connection established"
(or change your setup to reduce network latency; make sure full
duplex behaves as such; check average roundtrip times while
network is saturated; and so on ...)
Upgrading from DRBD-0.6.x
Using the size parameter in the disk section (was disk-size) is
no longer valid. The agreed disk size is now stored
in DRBD's non volatile meta data files.
NOTE that if you do not have some dedicated partition to use for
the meta-data, you may use 'internal' meta-data.
155
#
THIS HOWEVER WILL DESTROY THE LAST 128M
#
OF THE LOWER LEVEL DEVICE.
#
# So you better make sure you shrink the filesystem by 128M FIRST!
# or by 132M just to be sure... :)
#
skip {
As you can see, you can also comment chunks of text
with a 'skip[optional nonsense]{ skipped text }' section.
This comes in handy, if you just want to comment out
some 'resource <some name> {...}' section:
just precede it with 'skip'.
The basic format of option assignment is
<option name><linear whitespace><value>;
It should be obvious from the examples below,
but if you really care to know the details:
<option name> :=
valid options in the respective scope
<value> := <num>|<string>|<choice>|...
depending on the set of allowed values
for the respective option.
<num>
:= [0-9]+, sometimes with an optional suffix of K,M,G
<string> := (<name>|\"([^\"\\\n]*|\\.)*\")+
<name> := [/_.A-Za-z0-9-]+
}
#
# At most ONE global section is allowed.
# It must precede any resource section.
#
# global {
# use this if you want to define more resources later
# without reloading the module.
# by default we load the module with exactly as many devices
# as configured mentioned in this file.
#
# minor-count 5;
#
#
#
#
#
#
#
#
The user dialog counts and displays the seconds it waited so
far. You might want to disable this if you have the console
of your server connected to a serial terminal server with
limited logging capacity.
The Dialog will print the count each 'dialog-refresh' seconds,
set it to 0 to disable redrawing completely. [ default = 1 ]
dialog-refresh 5; # 5 seconds
# You might disable one of drbdadm's sanity check.
# disable-ip-verification;
# }
#
156
# this need not be r#, you may use phony resource names,
# like "resource web" or "resource mail", too
#
resource drbd0 {
# transfer protocol to use.
# C: write IO is reported as completed, if we know it has
#
reached _both_ local and remote DISK.
#
* for critical transactional data.
#
* for most cases.
# B: write IO is reported as completed, if it has reached
#
local DISK and remote buffer cache.
# A: write IO is reported as completed, if it has reached
#
local DISK and local tcp send buffer. (see also sndbuf-size)
#
* for high latency networks
#
#**********
# uhm, benchmarks have shown that C is actually better than B.
# this note shall disappear, when we are convinced that B is
# the right choice "for most cases".
# Until then, always use C unless you have a reason not to.
#
--lge
#**********
#
protocol C;
# what should be done in case the cluster starts up in
# degraded mode, but knows it has inconsistent data.
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ;
halt -f";
startup {
# Wait for connection timeout.
# The init script blocks the boot process until the resources
# are connected. This is so when the cluster manager starts later,
# it does not see a resource with internal split-brain.
# In case you want to limit the wait time, do it here.
# Default is 0, which means unlimited. Unit is seconds.
#
# wfc-timeout 0;
# Wait for connection timeout if this node was a degraded cluster.
# In case a degraded cluster (= cluster with only one node left)
# is rebooted, this timeout value is used.
#
degr-wfc-timeout 120;
# 2 minutes.
}
disk {
# if the lower level device reports io-err you have the choice of
# "pass_on" -> Report the io-error to the upper layers.
#
Primary -> report it to the mounted f-system.
#
Secondary -> ignore it.
# "panic"
-> The node leaves the cluster doing kernel panic.
# "detach" -> The node drops its backing storage device, and
157
#
#
on-io-error
continues in disk less mode.
detach;
# In case you only want to use a fraction of the available space
# you might use the "size" option here.
#
# size 10G;
}
net
#
#
#
#
#
#
{
this is the size of the tcp socket send buffer
increase it _carefully_ if you want to use protocol A over a
high latency network with reasonable write throughput.
defaults to 2*65535; you might try even 1M, but if your kernel
or network driver chokes on that, you have been warned.
sndbuf-size 512k;
# timeout
# connect-int
# ping-int
60;
10;
10;
# 6 seconds (unit = 0.1 seconds)
# 10 seconds (unit = 1 second)
# 10 seconds (unit = 1 second)
#
#
#
#
#
#
#
Maximal number of requests (4K) to be allocated by DRBD.
The minimum is hardcoded to 32 (=128 kByte).
For high performance installations it might help if you
increase that number. These buffers are used to hold
datablocks while they are written to disk.
#
#
#
#
#
#
#
#
#
#
#
When the number of outstanding requests on a standby (secondary)
node exceeds unplug-watermark, we start to kick the backing
device to start its request processing. This is an advanced
tuning parameter to get more performance out of capable storage
controlers.
Some controlers like to be kicked often, other controlers
deliver better performance when they are kicked less frequently.
Set it to the value of max-buffers to get the least possible
number of run_task_queue_disk() / q->unplug_fn(q) calls.
max-buffers
2048;
unplug-watermark
128;
# The highest number of data blocks between two write barriers.
# If you set this < 10 you might decrease your performance.
# max-epoch-size 2048;
# if some block send times out this many times, the peer is
# considered dead, even if it still answers ping requests.
# ko-count 4;
#
#
#
#
#
if the connection
"reconnect" ->
"stand_alone" ->
"freeze_io" ->
to the peer is lost you have the choice of
Try to reconnect (AKA WFConnection state)
Do not reconnect (AKA StandAlone state)
Try to reconnect but freeze all IO until
the connection is established again.
158
# on-disconnect reconnect;
}
syncer {
# Limit the bandwith used by the resynchronisation process.
# default unit is kByte/sec; optional suffixes K,M are allowed.
#
# Even though this is a network setting, the units are based
# on _byte_ (octet for our french friends) not bit.
# We are storage guys.
#
# Note that on 100Mbit ethernet, you cannot expect more than
# 12.5 MByte total transfer rate.
# Consider using GigaBit Ethernet.
#
# rate 10M;
rate 256M;
# All devices in one group are resynchronized parallel.
# Resychronisation of groups is serialized in ascending order.
# Put DRBD resources which are on different physical disks in one
# group.
# Put DRBD resources on one physical disk in different groups.
#
group 1;
# Configures the size of the active set. Each extent is 4M,
# 257 Extents ~> 1GB active set size. In case your syncer
# runs @ 10MB/sec, all resync after a primary's crash will last
# 1GB / ( 10MB/sec ) ~ 102 seconds ~ One Minute and 42 Seconds.
# BTW, the hash algorithm works best if the number of al-extents
# is prime. (To test the worst case performace use a power of 2)
al-extents 257;
}
on alpha {
device
disk
address
meta-disk
#
#
#
#
#
#
#
#
#
#
#
/dev/drbd0;
/dev/md6;
192.168.1.23:7788;
internal;
meta-disk is either 'internal' or '/dev/ice/name [idx]'
You can use a single block device to store meta-data
of multiple DRBD's.
E.g. use meta-disk /dev/hde6[0]; and meta-disk /dev/hde6[1];
for two different resources. In this case the meta-disk
would need to be at least 256 MB in size.
'internal' means, that the last 128 MB of the lower device
are used to store the meta-data.
You must not give an index with 'internal'.
}
on bravo {
159
device
disk
address
meta-disk
/dev/drbd0;
/dev/hda8;
192.168.1.24:7788;
internal;
}
}
#
# yes, you may also quote the resource name.
# but don't include whitespace, unless you mean it :)
#
resource drbd1 {
protocol C;
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ;
halt -f";
startup {
degr-wfc-timeout 120;
}
disk {
on-io-error
}
# 2 minutes.
detach;
syncer {
rate 256M;
group 1;
al-extents 257;
}
on alpha {
device
disk
address
meta-disk
}
on bravo {
device
disk
address
meta-disk
}
/dev/drbd1;
/dev/md7;
192.168.1.23:7789;
internal;
/dev/drbd1;
/dev/hda9;
192.168.1.24:7789;
internal;
}
160
———————————————————— APPENDICE C – I FILE DI HEARTBEAT
Appendice C
I file di Heartbeat
C-1 File haresources
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
This is a list of resources that move from machine to machine as
nodes go down and come up in the cluster. Do not include
"administrative" or fixed IP addresses in this file.
<VERY IMPORTANT NOTE>
The haresources files MUST BE IDENTICAL on all nodes of the cluster.
The node names listed in front of the resource group information
is the name of the preferred node to run the service. It is
not necessarily the name of the current machine. If you are running
auto_failback ON (or legacy), then these services will be started
up on the preferred nodes - any time they're up.
If you are running with auto_failback OFF, then the node information
will be used in the case of a simultaneous start-up, or when using
the hb_standby {foreign,local} command.
BUT FOR ALL OF THESE CASES, the haresources files MUST BE IDENTICAL.
If your files are different then almost certainly something
won't work right.
</VERY IMPORTANT NOTE>
We refer to this file when we're coming up, and when a machine is
being taken over after going down.
You need to make this right for your installation, then install in
/etc/ha.d
Each logical line in the file constitutes a "resource group".
A resource group is a list of resources which move together from
one node to another - in the order listed. It is assumed that there
161
# is no relationship between different resource groups. These
# resource in a resource group are started left-to-right, and stopped
# right-to-left. Long lists of resources can be continued from line
# to line by ending the lines with backslashes ("\").
#
# These resources in this file are either IP addresses, or the name
# of scripts to run to "start" or "stop" the given resource.
#
# The format is like this:
#
#node-name resource1 resource2 ... resourceN
#
#
# If the resource name contains an :: in the middle of it, the
# part after the :: is passed to the resource script as an argument.
# Multiple arguments are separated by the :: delimeter
#
# In the case of IP addresses, the resource script name IPaddr is
# implied.
#
# For example, the IP address 135.9.8.7 could also be represented
# as IPaddr::135.9.8.7
#
#
THIS IS IMPORTANT!!
#
# The given IP address is directed to an interface which has a route
# to the given address. This means you have to have a net route
# set up outside of the High-Availability structure. We don't set it
# up here -- we key off of it.
#
# The broadcast address for the IP alias that is created to support
# an IP address defaults to the highest address on the subnet.
#
# The netmask for the IP alias that is created defaults to the same
# netmask as the route that it selected in in the step above.
#
# The base interface for the IPalias that is created defaults to the
# same netmask as the route that it selected in in the step above.
#
# If you want to specify that this IP address is to be brought up
# on a subnet with a netmask of 255.255.255.0, you would specify
# this as IPaddr::135.9.8.7/24 .
#
# If you wished to tell it that the broadcast address for this subnet
# was 135.9.8.210, then you would specify that this way:
#
IPaddr::135.9.8.7/24/135.9.8.210
#
# If you wished to tell it that the interface to add the address to
# is eth0, then you would need to specify it this way:
#
IPaddr::135.9.8.7/24/eth0
#
# And this way to specify both the broadcast address and the
# interface:
#
IPaddr::135.9.8.7/24/eth0/135.9.8.210
#
# The IP addresses you list in this file are called "service"
162
# addresses, since they're they're the publicly advertised addresses
# that clients use to get at highly available services.
#
# For a hot/standby (non load-sharing) 2-node system with only
# a single service address,
# you will probably only put one system name and one IP address in
# here. The name you give the address to is the name of the default
# "hot" system.
#
# Where the nodename is the name of the node which "normally" owns the
# resource. If this machine is up, it will always have the resource
# it is shown as owning.
#
# The string you put in for nodename must match the uname -n name
# of your machine. Depending on how you have it administered, it
# could be a short name or a FQDN.
#
#------------------------------------------------------------------#
# Simple case: One service address, default subnet and netmask
#
No servers that go up and down with the IP address
#
#just.linux-ha.org 135.9.216.110
#
#------------------------------------------------------------------#
# Assuming the adminstrative addresses are on the same subnet...
# A little more complex case: One service address, default subnet
# and netmask, and you want to start and stop http when you get
# the IP address...
#
#just.linux-ha.org 135.9.216.110 http
#------------------------------------------------------------------#
# A little more complex case: Three service addresses, default subnet
# and netmask, and you want to start and stop http when you get
# the IP address...
#
#just.linux-ha.org 135.9.216.110 135.9.215.111 135.9.216.112 httpd
#------------------------------------------------------------------#
# One service address, with the subnet, interface and bcast addr
# explicitly defined.
#
#just.linux-ha.org 135.9.216.3/28/eth0/135.9.216.12 httpd
#
#------------------------------------------------------------------#
# An example where a shared filesystem is to be used.
# Note that multiple aguments are passed to this script using
# the delimiter '::' to separate each argument.
#
#node1 10.0.0.170 Filesystem::/dev/sda1::/data1::ext2
#
# Regarding the node-names in this file:
#
163
# They must match the names of the nodes listed in ha.cf, which in
# turn must match the ùname -n` of some node in the cluster. So they
# aren't virtual in any sense of the word.
#
#
#
#
#
Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3
Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3
Filesystem::/dev/drbd0::/var/lib/vmware/VirtualMachinesALPHA::ext3 \
vmmanager::ALPHA/CharlieXP/CharlieXP.vmx \
vmmanager::ALPHA/EchoSUSE/EchoSUSE.vmx
Filesystem::/dev/drbd1::/var/lib/vmware/VirtualMachinesBRAVO::ext3 \
vmmanager::BRAVO/DeltaKUBUNTU/DeltaKUBUNTU.vmx \
164
C-2 File ha.cf
#
# There are lots of options in this file. All you have to have is a
# set of nodes listed {"node ...} one of {serial, bcast, mcast, or
# ucast}, and a value for "auto_failback".
#
#
ATTENTION: As the configuration file is read line by line,
#
THE ORDER OF DIRECTIVE MATTERS!
#
# In particular, make sure that the udpport, serial baud rate
# etc. are set before the heartbeat media are defined!
# debug and log file directives go into effect when they
# are encountered.
#
# All will be fine if you keep them ordered as in this example.
#
#
# Note on logging:
# If any of debugfile, logfile and logfacility are defined then they
# will be used. If debugfile and/or logfile are not defined and
# logfacility is defined then the respective logging and debug
# messages will be loged to syslog. If logfacility is not defined
# then debugfile and logfile will be used to log messges. If
# logfacility is not defined and debugfile and/or logfile are not
# defined then defaults will be used for debugfile and logfile as
# required and messages will be sent there.
#
# File to write debug messages to
debugfile /var/log/ha-debug
#
#
# File to write other messages to
#
logfile/var/log/ha-log
#
#
# Facility to use for syslog()/logger
#
logfacility local0
#
#
# A note on specifying "how long" times below...
#
# The default time unit is seconds
#
10 means ten seconds
#
# You can also specify them in milliseconds
#
1500ms means 1.5 seconds
#
#
# keepalive: how long between heartbeats?
#
keepalive 2
#
# deadtime: how long-to-declare-host-dead?
165
#
#
If you set this too low you will get the problematic
#
split-brain (or cluster partition) problem.
#
See the FAQ for how to use warntime to tune deadtime.
#
deadtime 30
#
# warntime: how long before issuing "late heartbeat" warning?
# See the FAQ for how to use warntime to tune deadtime.
#
warntime 10
#
#
# Very first dead time (initdead)
#
# On some machines/OSes, etc. the network takes a while to come up
# and start working right after you've been rebooted. As a result
# we have a separate dead time for when things first come up.
# It should be at least twice the normal dead time.
#
initdead 120
#initdead 60
#
#
# What UDP port to use for bcast/ucast communication?
#
udpport694
#
# Baud rate for serial ports...
#
baud 19200
#
# serial
serialportname ...
serial /dev/ttyS0
# Linux
#serial/dev/cuaa0
# FreeBSD
#serial /dev/cuad0
# FreeBSD 6.x
#serial/dev/cua/a
# Solaris
#
#
# What interfaces to broadcast heartbeats over?
#
bcast bond0
bcast bond1
#bcast eth0
# Linux
#bcast eth1 eth2
# Linux
#bcast le0
# Solaris
#bcast le1 le2
# Solaris
#
# Set up a multicast heartbeat medium
# mcast [dev] [mcast group] [port] [ttl] [loop]
#
# [dev]
device to send/rcv heartbeats on
# [mcast group]
multicast group to join (class D multicast
address
#
224.0.0.0 - 239.255.255.255)
# [port]
udp port to sendto/rcvfrom (set this value to the
166
#
same value as "udpport" above)
# [ttl]
the ttl value for outbound heartbeats. This effects
#
how far the multicast packet will propagate. (0-255)
#
Must be greater than zero.
# [loop]
toggles loopback for outbound multicast heartbeats.
#
if enabled, an outbound packet will be looped back and
#
received by the interface it was sent on. (0 or 1)
#
Set this value to zero.
#
#
#mcast eth0 225.0.0.1 694 1 0
#
# Set up a unicast / udp heartbeat medium
# ucast [dev] [peer-ip-addr]
#
# [dev]
device to send/rcv heartbeats on
# [peer-ip-addr]
IP address of peer to send packets to
#
#ucast eth2 141.250.199.24
#ucast bond0 192.168.1.24
#ucast eth0 192.168.1.2
#
#
# About boolean values...
#
# Any of the following case-insensitive values will work for true:
#
true, on, yes, y, 1
# Any of the following case-insensitive values will work for false:
#
false, off, no, n, 0
#
#
#
# auto_failback: determines whether a resource will
# automatically fail back to its "primary" node, or remain
# on whatever node is serving it until that node fails, or
# an administrator intervenes.
#
# The possible values for auto_failback are:
#
on
- enable automatic failbacks
#
off
- disable automatic failbacks
#
legacy - enable automatic failbacks in systems
#
where all nodes do not yet support
#
the auto_failback option.
#
# auto_failback "on" and "off" are backwards compatible with the old
#
"nice_failback on" setting.
#
# See the FAQ for information on how to convert
#
from "legacy" to "on" without a flash cut.
#
(i.e., using a "rolling upgrade" process)
#
# The default value for auto_failback is "legacy", which
# will issue a warning at startup. So, make sure you put
# an auto_failback directive in your ha.cf file.
# (note: auto_failback can be any boolean or "legacy")
#
167
auto_failback on
#
#
# Basic STONITH support
# Using this directive assumes that there is one stonith
# device in the cluster. Parameters to this device are
# read from a configuration file. The format of this line is:
#
#
stonith <stonith_type> <configfile>
#
# NOTE: it is up to you to maintain this file on each node in the
#
cluster!
#
#stonith baytech /etc/ha.d/conf/stonith.baytech
#
# STONITH support
# You can configure multiple stonith devices using this directive.
# The format of the line is:
# stonith_host <hostfrom> <stonith_type> <params...>
# <hostfrom> is the machine the stonith device is attached
#
to or * to mean it is accessible from any host.
# <stonith_type> is the type of stonith device (a list of
#
supported drives is in /usr/lib/stonith.)
# <params...> are driver specific parameters. To see the
#
format for a particular device, run:
# stonith -l -t <stonith_type>
#
#
# Note that if you put your stonith device access information in
# here, and you make this file publically readable, you're asking
# for a denial of service attack ;-)
#
# To get a list of supported stonith devices, run
#
stonith -L
# For detailed information on which stonith devices are supported
# and their detailed configuration options, run this command:
#
stonith -h
#
#stonith_host *
baytech 10.0.0.3 mylogin mysecretpassword
#stonith_host ken3 rps10 /dev/ttyS1 kathy 0
#stonith_host kathy rps10 /dev/ttyS1 ken3 0
#
# Watchdog is the watchdog timer. If our own heart doesn't beat for
# a minute, then our machine will reboot.
# NOTE: If you are using the software watchdog, you very likely
# wish to load the module with the parameter "nowayout=0" or
# compile it without CONFIG_WATCHDOG_NOWAYOUT set. Otherwise even
# an orderly shutdown of heartbeat will trigger a reboot, which is
# very likely NOT what you want.
#
watchdog /dev/watchdog
#
# Tell what machines are in the cluster
# node nodename ... -- must match uname -n
#node ken3
#node kathy
168
node alpha
node bravo
#
# Less common options...
#
# Treats 10.10.10.254 as a psuedo-cluster-member
# Used together with ipfail below...
# note: don't use a cluster node as ping node
#
#ping 10.10.10.254
ping 141.250.199.62
#
# Treats 10.10.10.254 and 10.10.10.253 as a psuedo-cluster-member
# called group1. If either 10.10.10.254 or 10.10.10.253 are up
# then group1 is up
# Used together with ipfail below...
#
#ping_group group1 10.10.10.254 10.10.10.253
#
# HBA ping derective for Fiber Channel
# Treats fc-card-name as psudo-cluster-member
# used with ipfail below ...
#
# You can obtain HBAAPI from http://hbaapi.sourceforge.net. You need
# to get the library specific to your HBA directly from the vender
# To install HBAAPI stuff, all You need to do is to compile the common
# part you obtained from sourceforge. This will produce libHBAAPI.so
# which you need to copy to /usr/lib. You need also copy hbaapi.h to
# /usr/include.
#
# The fc-card-name is the name obtained from the hbaapitest program
# that is part of the hbaapi package. Running hbaapitest will produce
# a verbose output. One of the first line is similar to:
#
Apapter number 0 is named: qlogic-qla2200-0
# Here fc-card-name is qlogic-qla2200-0.
#
#hbaping fc-card-name
#
#
# Processes started and stopped with heartbeat. Restarted unless
#
they exit with rc=100
#
#respawn userid /path/name/to/run
respawn hacluster /usr/lib/heartbeat/ipfail
#
# Access control for client api
#
default is no access
#
#apiauth client-name gid=gidlist uid=uidlist
#apiauth ipfail gid=haclient uid=hacluster
#crm yes
###########################
#
#
Unusual options.
169
#
###########################
#
# hopfudge maximum hop count minus number of nodes in config
#hopfudge 1
#
# deadping - dead time for ping nodes
#deadping 30
#
# hbgenmethod - Heartbeat generation number creation method
#
Normally these are stored on disk and incremented as needed.
#hbgenmethod time
#
# realtime - enable/disable realtime execution (high priority, etc.)
#
defaults to on
#realtime off
#
# debug - set debug level
#
defaults to zero
#debug 1
#
# API Authentication - replaces the fifo-permissions-based system
#
#
# You can put a uid list and/or a gid list.
# If you put both, then a process is authorized if it qualifies under
# either the uid list, or under the gid list.
#
# The groupname "default" has special meaning. If it is specified,
# then this will be used for authorizing groupless clients, and any
# client groups not otherwise specified.
#
# There is a subtle exception to this. "default" will never be used
# in the following cases (actual default auth directives noted in
# brackets)
#
ipfail
(uid=HA_CCMUSER)
#
ccm
(uid=HA_CCMUSER)
#
ping
(gid=HA_APIGROUP)
#
cl_status (gid=HA_APIGROUP)
#
# This is done to avoid creating a gaping security hole and matches
# the most likely desired configuration.
#
#apiauth ipfail uid=hacluster
#apiauth ccm uid=hacluster
#apiauth cms uid=hacluster
#apiauth ping gid=haclient uid=alanr,root
#apiauth default gid=haclient
# message format in the wire, it can be classic or netstring,
# default: classic
#msgfmt classic/netstring
# Do we use logging daemon?
# If logging daemon is used, logfile/debugfile/logfacility in this
170
# file are not meaningful any longer. You should check the config file
# for logging daemon (the default is /etc/logd.cf)
# more infomartion can be fould
# in http://www.linux-ha.org/ha_2ecf_2fUseLogdDirective
# Setting use_logd to "yes" is recommended
#
# use_logd yes/no
#
# the interval reconnect to log daemon if the prev connection failed
# default: 60 seconds
#conn_logd_time 60
#
#
# Configure compression module
# It could be zlib or bz2, depending on whether u have corresponding
# library in the system.
#compression bz2
#
# Confiugre compression threshold
# This value determines the threshold to compress a message,
# e.g. if the threshold is 1, then any message with size greater
# than 1 KB will be compressed, the default is 2 (KB)
#compression_threshold 2
171
C-3 File authkeys
#
# Authentication file. Must be mode 600
#
#
# Must have exactly one auth directive at the front.
# auth send authentication using this method-id
#
# Then, list the method and key that go with that method-id
#
# Available methods: crc sha1, md5. Crc doesn't need/want a key.
#
# You normally only have one auth method-id listed in this file
#
# Put more than one to make a smooth transition when changing auth
# methods and/or keys.
#
#
# sha1 is believed to be the "best", md5 next best.
#
# crc adds no security, except from packet corruption.
#
Use only on physically secure networks.
#
auth 2
#1 crc
2 sha1 pwd!hacluster
#3 md5 pwd!hacluster
172
————————————————————— APPENDICE D – I FILE DI PROGETTO
Appendice D
I file di progetto
D-1 Lo script vmmanager
#!/bin/bash
# # # # # # # #
# Written by Mirco PERINI <[email protected]>
# Date February 2007
# Ripartizione Servizi Informatici e Statistici
# Area Servizi Tecnico-Sistemistici
# Universita' degli Studi di Perugia
# Script utilizzato per la gestione delle risorse
# VMware Server all'interno di Heartbeat
# # # # # # # #
VMWARECMD="/usr/bin/vmware-cmd"
VM_PATH="/var/lib/vmware/VirtualMachines"
RES="$1"
CMD="$2"
ADMIN_MAIL="[email protected]"
# Controlla se il file di configurazione della macchina
# virtuale di VMWare Server esiste sul file system del nodo
if [ -e ${VM_PATHRES} ]; then
case "$CMD" in
start)
STARTUP_STATE=$($VMWARECMD $VM_PATH$RES getstate 2>&1)
# Avvio della macchina virtuale
$VMWARECMD $VM_PATH$RES start;
173
if [ $($VMWARECMD $VM_PATH$RES getstate 2>&1 \
| sed 's/getstate() =//g') = "stuck" ]; then
#
#
#
#
#
#
#
#
#
#
Question (id = 994407981) :The features supported by
the processor(s) in this machine are different from
the features supported by the processor(s) in the
machine on which the snapshot was saved. You may
continue to resume this virtual machine, but doing so
may result in unpredictable behavior. Do you wish to
continue resuming this virtual machine?
0) Yes
1) No
Select. Press enter for default <0> : selected 0 : Yes
echo 0 | $VMWARECMD $VM_PATH$RES answer
fi
if [ ${STARTUP_STATE//getstate() =/} = "off" ]; then
# Effettua attesa attiva sulla macchina virtuale pari
# a 60 secondi se lo stato precedente era "off"
TIMER=60
elif [ ${STARTUP_STATE//getstate() =/} = "on" ]; then
TIMER=0
elif [ ${STARTUP_STATE//getstate() =/} = "suspended" ]; then
# Effettua attesa attiva sulla macchina virtuale pari
# a 15 secondi se lo stato precedente era "suspended"
TIMER=èxpr $($VMWARECMD $VM_PATH$RES getuptime 2>&1 \
| sed 's/getuptime() =//g') + 15`
fi
# Attende finchè la macchina virtuale non ha finito lo start
while [ $($VMWARECMD $VM_PATH$RES getuptime 2>&1 \
| sed 's/getuptime() =//g') -lt $TIMER ]; do
wait
done
;;
stop)
# Verifica che la macchina virtuale sia attiva
# controllando l'esistenza della cartella ad essa associata
# in /var/run
174
if [ -d /var/run/vmware/ècho $VM_PATH$RES \
| sed 's/\//%2F/g' | sed 's/\./%2E/g'` ]; then
# Sospensione della macchina virtuale
$VMWARECMD $VM_PATH$RES suspend
fi
;;
*)
# Se non viene fornita nessuna opzione mostra le possibilità
echo "Usage: vmmanager [resource] {start|stop}"
exit 1
;;
esac
# Invia una mail riepilogativa agli amministratori sullo
# stato della macchina virtuale
mailx -s "Virtual machine `$VMWARECMD $VM_PATH$RES \
getconfig displayName|sed 's/getconfig(displayName) \
=//g'` $CMD on `hostname`" $ADMIN_MAIL << EOF
Virtual Machine: `$VMWARECMD $VM_PATH$RES getconfig \
displayName| sed 's/getconfig(displayName) =//g'`
Status: `$VMWARECMD $VM_PATH$RES getstate \
| sed 's/getstate() =//g'`
Uptime: `$VMWARECMD $VM_PATH$RES getuptime \
| sed 's/getuptime() =//g'`
Config $VM_PATH$RES
EOF
fi
exit 0
175
D-2 Storyboard
176
————————————————————————————— BIBLIOGRAFIA
Bibliografia
[1]
Pradeep K. Sinha, Distributed Operating Systems: concept and
design, IEEE Press New York (1997)
[2]
L. Fereira, G. Kettmann, A. Thomasch, E. Silcocks, J. Chen, J.C.
Daunois, J. Ihamo, M. Harada, S. Hill, W. Bernocchi, E. Ford,
Linux HPC Cluster Installation, IBM Redbooks
http://www.ibm.com/redbooks/
[3]
P. Coddington, Distributed High-Performance Computing (2000)
http://www.dhpc.adelaide.edu.au/education/CS7933/2000/distributed.pdf
[4]
S. Calò, Un cluster in alta disponibilità in ambiente linux (2004)
http://www.drbd.org/fileadmin/drbd/publications/HAcluster.pdf
[5]
M. Davini, I. Lisi, Cluster – Linux & C. n.14 Piscopo Editore
[6]
C. Manuali, Implementazione di un ambiente Grid per il calcolo ad
alte prestazioni (2002)
http://www.unipg.it/carlo/Tesi.pdf
[7]
C. Zoffoli, Progettazione, realizzazione ed ottimizzazione di un
cluster ibrido 32/64 bit per HPC altamente affidabile (2005)
http://www.cs.unibo.it/~roffilli/thesis/ZOFFOL05.pdf
177
————————————————————————————— BIBLIOGRAFIA
[8]
A. Singh, An introduction to virtualization (2004)
http://www.kernelthread.com/publications/virtualization
[9]
D.
Sgandurra,
Architetture
di
sicurezza
e
tecnologie
di
virtualizzazione: rilevamento intrusioni con introspezione (2006)
http://www.serra.unipi.it/sicurezza/tesi1.pdf
[10] A. Urbini, Modelli e architetture per la virtualizzazione di sistemi
informatici (2005)
http://www.urbo.altervista.org/it/download/Tesi.pdf
[11] VMware Server
http://www.vmware.com/products/server/
[12] Microsoft Virtual PC
http://www.microsoft.com/windows/virtualpc/default.mspx
[13] PearPC – PowerPC Architecture Emulator
http://pearpc.sourceforge.net
[14] Xen Source
http://www.xensource.com
[15] Intel Virtualization Technology
http://www.intel.com/technology/virtualization/index.htm
[16] AMD Pacifica
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~98372,00.html
[17] Denali
http://denali.cs.washington.edu/
178
————————————————————————————— BIBLIOGRAFIA
[18] Virtuozzo Server Virtualization
http://www.swsoft.com/products/virtuozzo/
[19] Parallels Workstation
http://www.parallels.com/
[20] Kubuntu
http://www.kubuntu.org
[21] Ubuntu
http://www.ubuntu.org
[22] Comunità italiana Ubuntu
http://www.ubuntu-it.org
[23] J. Gifford, How to setup ethernet bonding with LFS (2003)
http://www.linuxfromscratch.org/hints/downloads/files/ethernet-bonding.txt
[24] P. De Bruijn, Ubuntu Bonding (2006)
http://pmjdebruijn.blogspot.com/2006/04/ubuntu-bonding.html
[25] A. Benokraitis, Red Hat ES 4: Parametri Ethernet (2005)
http://www.redhat.com/docs/manuals/enterprise/RHEL-4Manual/it/ref-guide/s1-modules-ethernet.html
[26] Bonding: schede di rete ridondanti e load balancing
http://wiki.gentoo-italia.net/index.php/Bonding:_schede_
di_rete_ridondanti_e_load_balancing
[27] T. Davis, Linux Ethernet Bonding Driver mini-howto (2000)
http://www.kernel.org/pub/linux/kernel/people/marcelo/
linux-2.4/Documentation/networking/bonding.txt
179
————————————————————————————— BIBLIOGRAFIA
[28] DRBD Documentation
http://www.drbd.org/documentation.html
[29] A. Robertson, Linux-HA Heartbeat System Design (2000)
http://www.linuxshowcase.org/2000/2000papers/papers/robertson/robertson.pdf
[30] A. Camozzo, Installazione Cluster Vserver-drbd-heartbeat (2004)
http://homes.stat.unipd.it/mmzz/Papers/NewVserver/Cluster.html
[31] HOWTO Watchdog Timer
http://gentoo-wiki.com/HOWTO_Watchdog_Timer
[32] The High-Availability Linux Project
http://www.linux-ha.org
[33] M. Barr, Introduction to Watchdog Timers (2001)
http://www.embedded.com/columns/showArticle.jhtml?articleID=9900324
[34] Truelite srl, Configurazione di un Cluster HA (2006)
https://labs.truelite.it/truedoc/wiki/SetupClusterHA
[35] D. Krovich, DRBD HOWTO
http://www.slackworks.com/~dkrovich/DRBD/
[36] Alan Wood, Predicting Client/Server Availability – IEEE 1995
http://ieeexplore.ieee.org/iel1/2/8564/00375176.pdf?tp=&isnumber=&arnumber=375176
[37] K. Miers, High Availability with Linux (2004)
http://www.rhic.bnl.gov/hepix/talks/041020am/miers.pdf
[38] S. Reifschneider, Linux High Availability Clusters (2005)
http://www.samag.com/documents/s=9658/sam0505b/
180
————————————————————————————— BIBLIOGRAFIA
[39] VMware Inc, VMware Scripting API – User’s Manual (2006)
http://www.vmware.com/pdf/Scripting_API_23.pdf
[40] D. Diacono, Cluster in alta disponibilità in ambiente Linux (2006)
http://www.ba.infn.it/calcolo/documenti/Cluster.html
[41] F. Meriggia, Computer Virtuali – PC Professionale n.186
[42] VMware Inc, WMware Server Administration Guide (2006)
http://www.vmware.com/pdf/server_admin_manual.pdf
[43] Wei Hou, O. Geoffrey Okogbaa, Reliability and Availability Cost
Design Tradeoffs for HA Systems – IEEE 2005
http://ieeexplore.ieee.org/iel5/9660/30517/01408401.pdf?arnumber=1408401
181

virtualizzazione in un cluster ad alta disponibilità in ambiente linux

Transcript

Documenti analoghi

30.10.2015 - Giorgio Roverato

Lo sviluppo della Stella Italiana prosegue costantemente sui

Diapositiva 1 - Osservatorio Astronomico di Bassano Bresciano

ei grafi! - Francesco Cauteruccio

Mappa - Commissione Divulgazione UAI

Nota MAP per Cluster meningite meningococcica in Europa

comunicato cluster

zanzibar - promoturismo

Nuovi cataloghi in agenzia: ecco l`inverno del Gruppo Alpitour