Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

Università degli Studi di Bologna
FACOLTÀ DI I NGEGNERIA
Corso di Laurea in Ingegneria Informatica
A MMINISTRAZIONE DI RETI DI CALCOLATORI

A NALISI ED IMPLEMENTAZIONE
DI FILE SYSTEM DISTRIBUITI
IN AMBIENTE LINUX

Tesi di Laurea di: Relatore:
R AUL C AFINI D OTT. I NG . M ARCO P RANDINI
Correlatori:
I NG . L UCA G HEDINI

Sessione prima

Anno Accademico 2005/2006

Parole chiave:
File system distribuito
Cluster
Linux
Global File System
Logical Volume Manager

D.E.I.S., Dipartimento di Elettronica, Informatica e Sistemistica.
Università di Bologna.
La tesi è scritta in LTEX 2ε , utilizzando come testo di riferimento [1].
A

La stampa è in P OST S CRIPT.
Le immagini sono create in A DOBE R P HOTOSHOP R E LEMENTS 2.0.
A DOBE R P HOTOSHOP R E LEMENTS è un marchio registrato A DOBE R S YSTEMS I NC .

A chi voglio bene,
a chi me ne vorrà sempre
e a chi non ho ancora incontrato.

Aneddoto

Il poeta romantico John Keats1 alla ﬁne di un pranzo, alzandosi in piedi con il bicchiere in
mano, esclamò:
– Sia biasimata la memoria di Newton! –
Stupore di tutti i commensali.
– Come mai questo strano brindisi? –
Chiese William Wordsworth2 suo collega.
– Perchè – spiegò il poeta inglese – ha distrutto tutta la poesia di un arcobaleno
riducendolo ad un prisma.

1 John Keats (Londra 31 Ottobre 1795 – Roma 23 Febbraio 1821)
2 William Wordsworth (Cumberland 7 Aprile 1770 – Rydal Mount 23 Aprile 1850)

Indice

Frontespizio i

Indice vii

Elenco delle ﬁgure xi

Elenco delle tabelle xiii

Introduzione xv

1 Cluster linux 1
1.1 Che cos’è un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Tipologie di cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 High-Avaiability clusters (HA-Clusters) . . . . . . . . . . . 2
1.2.2 Load-Balancing clusters (LB-Clusters) . . . . . . . . . . . 2
1.2.3 High-Performance clusters (HPC) . . . . . . . . . . . . . . 3
1.3 I cluster Beowulf . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 I cluster e linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Analisi di un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1 Cluster Hardware . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.2 Cluster Software . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Cluster linux: Conclusioni . . . . . . . . . . . . . . . . . . . . . . 5

2 File System locali e distribuiti 7
2.1 Il File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 File System locali o Disk File Systems . . . . . . . . . . . . . . . . 8
2.3 File System distribuiti o Distribuited File Systems . . . . . . . . . . 8
2.3.1 Distribuited Fault Tolerant File Systems . . . . . . . . . . . 9
2.3.2 Distribuited Parallel File Systems . . . . . . . . . . . . . . 9
2.3.3 Distribuited Parallel - Fault Tolerant File Systems . . . . . . 9
2.4 Analisi dei ﬁle system candidati . . . . . . . . . . . . . . . . . . . 9
2.4.1 Red Hat/Fedora GFS (Global File System) . . . . . . . . . 9

viii INDICE

2.4.2 IBM GPFS (General Parallel File System) . . . . . . . . . . 10
2.5 File System locali e distribuiti: Conclusioni . . . . . . . . . . . . . 10

3 Scelta del sistema 11
3.1 Scelta del sistema e del file system: Perchè Red Hat/Fedora GFS? . 11
3.2 GFS: Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Caratteristiche tecniche . . . . . . . . . . . . . . . . . . . . 12
3.2.2 La struttura . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Locking manager . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.6 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7 LAN-free backup . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.8 Diskless shared root clustering . . . . . . . . . . . . . . . . 14
3.3 GFS: Architetture implementabili . . . . . . . . . . . . . . . . . . 14
3.3.1 GFS over SAN . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 GFS over GNBD-SAN . . . . . . . . . . . . . . . . . . . . 15
3.3.3 GFS over GNBD-DAS . . . . . . . . . . . . . . . . . . . . 16
3.4 Scelta del sistema: Conclusioni . . . . . . . . . . . . . . . . . . . . 16

4 Analisi degli strumenti software 17
4.1 Cluster Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 CCS (Cluster Configuration System) . . . . . . . . . . . . . . . . . 17
4.2.1 Il demone /sbin/ccsd: . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Il file /etc/cluster/cluster.conf . . . . . . . . . . . . 19
4.2.3 Il tool ccs_test . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.4 Il tool ccs_tool . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.5 Avvio del servizio ccsd . . . . . . . . . . . . . . . . . . . . 21
4.3 Magma e Magma-plugins . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 CMAN (Cluster MANager) . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 CM (Connection Manager) . . . . . . . . . . . . . . . . . . 22
4.4.2 SM (Service Manager) . . . . . . . . . . . . . . . . . . . . 22
4.4.3 I demoni di cman . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4 Il tool cman_tool . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Fence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 DLM (Distribuited Lock Manager) . . . . . . . . . . . . . . . . . . 25
4.7 RGManager (Resource Group Manager) . . . . . . . . . . . . . . . 26
4.8 GFS (Global File System) . . . . . . . . . . . . . . . . . . . . . . 26
4.9 LVM2 - Cluster (Logical Volume Manager 2) . . . . . . . . . . . . 27
4.9.1 Architettura di un sistema LVM . . . . . . . . . . . . . . . 27

INDICE ix

4.9.2 CLVM (Clustered LVM) . . . . . . . . . . . . . . . . . . . 28
4.10 GNBD (Global Network Block Device) . . . . . . . . . . . . . . . 28
4.10.1 Basic setup . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10.2 Complex setup . . . . . . . . . . . . . . . . . . . . . . . . 30
4.10.3 Il file cluster.conf sotto GNBD . . . . . . . . . . . . . . . . 31
4.11 System-Config-Cluster . . . . . . . . . . . . . . . . . . . . . . . . 32
4.12 Gulm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.13 Perl-net-Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Implementazione in laboratorio 35
5.1 Il cluster del Lab4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.1 Profilo Hardware . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Profilo Software . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Topologia I: GFS over GNBD-DAS . . . . . . . . . . . . . . . . . 37
5.2.1 Gli attori: . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.2 Interconnessione Hardware: Il cluster . . . . . . . . . . . . 38
5.2.3 Interconnessione Software: Il file system distribuito . . . . . 39
5.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.1 Installazione del cluster . . . . . . . . . . . . . . . . . . . . 40
5.4 Installazione del file system distribuito . . . . . . . . . . . . . . . . 46
5.5 Automatismi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1 Caricamento automatico delle componenti GNBD . . . . . 48
5.5.2 Montaggio automatico delle partizioni GFS . . . . . . . . . 49
5.6 Il Cluster Deployment Tool . . . . . . . . . . . . . . . . . . . . . . 49

6 Fault tolerance 51
6.1 Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.1.1 Multipath over SAN . . . . . . . . . . . . . . . . . . . . . 52
6.1.2 Multipath over DAS . . . . . . . . . . . . . . . . . . . . . 53
6.2 Mirroring hardware con RAID . . . . . . . . . . . . . . . . . . . . 56
6.3 Mirroring software con LVM . . . . . . . . . . . . . . . . . . . . . 57
6.4 Channel Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Conclusioni 59
6.5 Risultati ottenuti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.5.1 Analisi della gamma di file system distribuiti . . . . . . . . 59
6.5.2 Creazione del cluster . . . . . . . . . . . . . . . . . . . . . 60
6.5.3 Realizzazione del file system distribuito . . . . . . . . . . . 60
6.5.4 Implementazione della topologia GFS over GNBD-DAS . . 60
6.5.5 Analisi delle tecnologie di fault tolerance . . . . . . . . . . 60
6.6 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

x INDICE

6.6.1 Aggiunta di più server GNBD . . . . . . . . . . . . . . . . 61
6.6.2 Accesso al file system GFS anche dai nodi GNBD . . . . . 61
6.6.3 Realizzazione di un sistema fault tolerance . . . . . . . . . 61
6.6.4 Analisi delle prestazioni . . . . . . . . . . . . . . . . . . . 61
6.7 Un pò di numeri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A Il File System di Linux 63
A.1 Il file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.1 Il File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.2 Struttura interna dei file . . . . . . . . . . . . . . . . . . . 65
A.1.3 Metodi di accesso al file . . . . . . . . . . . . . . . . . . . 65
A.1.4 Il Direttorio . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.1.5 Metodi di Allocazione . . . . . . . . . . . . . . . . . . . . 67
A.2 Il file system in linux a livello hardware . . . . . . . . . . . . . . . 68
A.2.1 Organizzazione fisica . . . . . . . . . . . . . . . . . . . . . 68
A.2.2 Dispositivi: Operazione di Montaggio e Smontaggio . . . . 70
A.3 Il file system in linux a livello software . . . . . . . . . . . . . . . . 71

B Il Logical Volume Manager 73
B.1 Come funziona LVM . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.1.1 I Physical Volume . . . . . . . . . . . . . . . . . . . . . . 74
B.1.2 Il Volume Group . . . . . . . . . . . . . . . . . . . . . . . 74
B.1.3 I Logical Volume . . . . . . . . . . . . . . . . . . . . . . . 74
B.1.4 I Physical Extent e i Logical Extent . . . . . . . . . . . . . 75
B.2 Proprietà di LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.3 Differenze tra LVM e sistemi RAID . . . . . . . . . . . . . . . . . 77
B.4 Limitazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Ringraziamenti 81

Bibliografia 85

Elenco degli acronimi 87

Elenco delle ﬁgure

1 Tux la mascotte del sistema operativo linux. . . . . . . . . . . . . . xvi

1.1 Un sistema cluster della IBM. . . . . . . . . . . . . . . . . . . . . 2

3.1 Topologia GFS over SAN . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Topologia GFS over GNBD-SAN . . . . . . . . . . . . . . . . . . 15
3.3 Topologia GFS over GNBD-DAS . . . . . . . . . . . . . . . . . . 16

4.1 La struttura di CMAN . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Interazione tra Fence DLM e CMAN . . . . . . . . . . . . . . . . . 26
4.3 Architettura del sistema LVM . . . . . . . . . . . . . . . . . . . . . 27
4.4 GNBD - Basic Setup . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 GNBD - Complex Setup . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Cluster Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Il modello di macchine usato in laboratorio . . . . . . . . . . . . . 35
5.2 Dettaglio della macchina . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Topologia GNBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Lab4 - Interconnessioni hardware . . . . . . . . . . . . . . . . . . 38
5.5 Lab4 - Interconnessioni software . . . . . . . . . . . . . . . . . . . 39
5.6 Il tool Cluster Manager . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7 Il Cluster Deployment Tool . . . . . . . . . . . . . . . . . . . . . . 50

6.1 Supporto multipath in architettura SAN - GNBD . . . . . . . . . . 52
6.2 DAS storage in architettura GNBD . . . . . . . . . . . . . . . . . . 53
6.3 Supporto multi-ported in architettura GNBD . . . . . . . . . . . . . 54
6.4 Supporto mirroring in architettura GNBD . . . . . . . . . . . . . . 55
6.5 Mirroring hardware con RAID . . . . . . . . . . . . . . . . . . . . 56
6.6 Mirroring via software con LVM . . . . . . . . . . . . . . . . . . . 57
6.7 Channel Bonding . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

A.1 Organizzazione ﬁsica . . . . . . . . . . . . . . . . . . . . . . . . . 68

B.1 Astrazione del Logical Volume Manager . . . . . . . . . . . . . . . 74

xii ELENCO DELLE FIGURE

B.2 Esempio di mappatura reale . . . . . . . . . . . . . . . . . . . . . . 76
B.3 Snapshot sotto LVM . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.4 Mapping Linear-Striped . . . . . . . . . . . . . . . . . . . . . . . . 77
B.5 Mirroring software con LVM . . . . . . . . . . . . . . . . . . . . . 79

Elenco delle tabelle

4.1 Pacchetti software della suite . . . . . . . . . . . . . . . . . . . . . 18
4.2 Pacchetti software aggiuntivi . . . . . . . . . . . . . . . . . . . . . 18
4.3 Pacchetti software di CMAN . . . . . . . . . . . . . . . . . . . . . 21
4.4 Pacchetti software di DLM . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Pacchetti software di GFS . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Pacchetti software di GNBD . . . . . . . . . . . . . . . . . . . . . 28

5.1 Caratteristiche tecniche . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Software installato . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Partizionamento del GNBD Server: . . . . . . . . . . . . . . . . . 40
5.4 Partizionamento dei Client GFS: . . . . . . . . . . . . . . . . . . . 41
5.5 Settaggio sottorete: . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.6 Utenti del sistema: . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Introduzione

Failure is not an option.

Eugene F. Kranz
(Former flight director, NASA)

Questa tesi si pone l’obiettivo dell’analisi e della implementazione di file system
distribuiti in ambiente linux, dedicando particolare attenzione alle problematiche
presenti nell’implementazione di un sistema reale altamente performante, in termi-
ni di prestazioni, tollerante ai guasti, dedicato all’erogazione di servizi informatici.
Un file system distribuito è, come vedremo meglio in seguito, uno strumento in gra-
do di gestire una piattaforma dati comune tra più macchine distribuendo il contenu-
to informativo globale tra di esse, garantendo la consistenza, l’integrità e l’accesso
concorrente ai dati, anche in caso di guasti.
L’infrastruttura hardware portante su cui è implemetato il file system prende no-
me di cluster. Un cluster (dall’inglese grappolo) è un insieme di computer connessi
tramite una rete telematica. Lo scopo di questa architettura è l’incremento presta-
zionale in termini di calcolo computazionale e/o di risorse distribuite, dedicato alla
risoluzione di un problema (algoritmo) o al supporto di più servizi informatici. La
realizazione di una struttura cluster è teoricamente indipendente dalla piattaforma
hardware o software dei suoi nodes (nodi), ovvero dei calcolatori che la compongo-
no. In particolare però queste soluzioni hanno trovato un forte alleato nel sistema
operativo linux dato che ad oggi la maggior parte di questi sistemi è principalmente
basato su questa piattaforma.
Linux è un sistema operativo open source creato da Linus Torvald nel 1991, de-
rivato da Minix, uno spin-off di Unix a scopo didattico, e distribuito sotto licensa
GNU is Not Unix/General Public License (GNU/GPL). La scelta dell’uso di questo
sistema operativo in questo progetto di tesi, e in particolare della distribuzione Fe-
dora Core release 4, deriva dal largo uso di linux in ambiente accedemico e il nativo
supporto alla costruzione di soluzioni cluster e di distribuited file system per le quali
prevede un’ampia gamma di applicativi software per la gestione ed il set-up.
In questa tesi saranno dunque esaminate tecnologie ed architetture, volte allo
sviluppo di una implementazione di file system distribuito su piattaforma linux.

xvi Introduzione

Verranno esaminati e paragonati i vari software commerciali ed open source dispo-
nibili, sui quali verrà effettuata una scelta motivata da fattori prestazionali e acca-
demici, allo scopo ultimo di realizzare una piattaﬁorma tecnologica di base, per lo
sviluppo di un cluster con ﬁnalità di high avaiability per servizi informatici della
facoltà di Ingegneria dell’Univeristà di Bologna.

Figura 1: Tux la mascotte del sistema operativo linux.

Capitolo 1

Cluster linux

Perché in ultima analisi, il legame
fondamentale che unisce tutti noi é
che abitiamo tutti su questo piccolo
pianeta. Respiriamo tutti la stessa
aria. Abbiamo tutti a cuore il futuro
dei nostri ﬁgli. E siamo tutti solo di
passaggio.

John Fitzgerald Kennedy
(28 Ottobre, 1962)

1.1 Che cos’è un cluster
Come già detto un cluster (dall’inglese grappolo) è un insieme di computer connes-
si tramite una rete telematica e gestiti come un singolo sistema. Lo scopo di questa
architettura è l’incremento prestazionale in termini di calcolo computazionale o di
risorse distribuite dedicate alla risoluzione di un problema o al supporto di più ser-
vizi informatici. I calcolatori che compongono la rete vengono detti nodi del cluster
o semplicemente nodi.

1.2 Tipologie di cluster
I sistemi cluster si categorizzano in varie tipologie:
1. High-Avaiability clusters (HA-Clusters)

2. Load-Balancing clusters (LB-Clusters)

3. High-Performance clusters (HPC o HP-Clusters)

2 Cluster linux

Figura 1.1: Un sistema cluster della IBM.

1.2.1 High-Avaiability clusters (HA-Clusters)

Questa tipologia di cluster, che sarà quella presa in esame in questa tesi di laurea, è
implementata con lo scopo di generare un ambiente fail-safe, a prova di guasto, in
cui la rottura di uno dei componenti hardware, software o di rete non influisca sulla
disponibilità di servizi che la struttura eroga.
Per garantire ciò questa soluzione si basa su di una struttura a nodi ridondanti che
garantiscono il supporto al servizio in caso di un generico guasto ad uno dei no-
di o ad un componente della rete. L’esempio minimo di una tipologia HA-Cluster
prevede due nodi con accesso condiviso su di uno spazio di memoria. All’atto di
una richiesta solo uno dei nodi esegue le istruzioni mentre l’altro rimane in stand-
by pronto in caso in cui il nodo operante subisca un guasto. Se ciò si verifica il
secondo nodo fa sue le risorse di rete e di spazio fisico gestendo la richiesta senza
che l’utente ne sia interessato. Questo procedimento di gestione dei guasti prende il
nome di failover.
La scelta di questa tipologia ricade spesso per applicazioni di file sharing su di una
rete, applicazioni business, servizi web, web-server e commercio elettronico.

1.2.2 Load-Balancing clusters (LB-Clusters)

Questa tipologia di cluster opera gestendo il carico di lavoro, o workload, distri-
buendolo sui vari nodi della struttura. Queste architetture sono principalmente im-
plementate per l’aumento delle prestazioni in ambiti in cui vi è un carico di lavoro
molto grande che tende ad avere tempi di computazione troppo elevati.

1.3. I cluster Beowulf 3

1.2.3 High-Performance clusters (HPC)
Questa tipologia di cluster tende ad incrementare le potenzialità di calcolo computa-
zionale dividendo il lavoro di un singolo processo su diversi nodi. Questa soluzione
trova spazio negli ambiti scientifici e della simulazione di modelli matematici com-
plessi. A questo scopo è possibile consultare il sito http://top500.org che contiene
l’elenco dei 500 supercomputer più potenti del pianeta alcuni dei quali basati su
cluster linux. Inoltre è interessante citare come uno dei calcolatori più potenti al
mondo risieda a Bologna, nella sede del Cineca.

1.3 I cluster Beowulf
Nel 1994 Thomas Sterling e Don Becker crearono per conto della NASA un cluster
composto da 16 nodi realizzato con hardware Commercial-Off-The-Shelf (COTS)
che prese nome di progetto Beowulf, dal titolo del primo poema epico romantico,
finora conosciuto, scritto in lingua inglese.
Un cluster Beowulf non identifica una tipologia, a differenza di quelle sopra elen-
cate, bensì un approccio, una modalità di realizzazione di una struttura cluster con
alcune caratteristiche particolari. Un nodo è preso come server node o head node,
cioè nodo principale, da cui viene gestita l’intera struttura e da cui si ha la visione
d’insieme del cluster, e uno o più client nodes, o nodi secondari, connessi via Ether-
net o altro standard di rete tramite uno switch a completamento del sistema cluster.
A rafforzare l’idea che un cluster Beowulf identifica solo una modalità di realiz-
zazione di un cluster vi è la mancanza di alcun pacchetto software direttamente
riferibile al progetto, ma bensì una serie di software indipendente, compatibile con
questo approccio.

1.4 I cluster e linux
La natura gratuita ed open source di linux e l’alto interesse del mondo accademico
per le soluzioni cluster hanno dato il via ad un connubio fondamentale nella realiz-
zazione delle prime infrastrutture di questo tipo, fino a raggiungere con lo sviluppo
della comunità mondiale, la piena concorrenza in termini di rapporto prezzo/presta-
zioni con le soluzioni proprietarie e dedicate, come i supercomputer, con l’enorme
vantaggio di un costo nettamente contenuto rispetto a quest’ultime.
Al giorno d’oggi le soluzioni cluster linux cominciano ad entrare a far parte degli

4 Cluster linux

apparati governativi ed industriali a livello mondiale, fatto che ne sancisce la loro
afﬁdabilità, potenzialità ed economicità.

1.5 Analisi di un cluster
Analizziamo i principi di funzionamento di una infrastruttura cluster con particolare
attenzione ai suoi componenti hardware e software principali, ai loro ruoli e alla loro
interazione.

1.5.1 Cluster Hardware
I nodi

I nodi di un cluster non sono altro che i computer interconnessi nella rete. I nodi
possono avere una gerarchia, ci possono essere nodi computazionali, di gestione o
di monitoraggio o non avere distinzioni di grado, in questo caso vengono detti nodi
peer.

La rete

La rete, o meglio l’infrastruttura di rete che interconnette i nodi, rappresenta la
spina dorsale del sistema permettendo la comunicazione e l’interscambio di dati ed
informazioni tra i vari nodi.

1.5.2 Cluster Software
Il Sistema Operativo

Il sistema operativo di un sistema cluster provvede a rendere i nodi operativi dal
punto di vista computazionale e garantisce una piattaforma software omogenea dove
elaborare le informazioni. La scelta del sistema operativo ricadrà nel nostro caso,
per i motivi ﬁn quì discussi, su una distribuzione GNU/Linux, ed in particolare sulla
distribuzione Fedora Core release 4. Ecco un elenco di sistemi operativi alla base
di soluzioni cluster:

• GNU/Linux

• AIX

• Microsoft R Windows R

• ...

1.6. Cluster linux: Conclusioni 5

Il Software per la gestione del cluster

Il software per la gestione del cluster è un tool essenziale nella creazione di un si-
stema di questo tipo che permette la costruzione, il mantenimento e l’espansione
della struttura mantenendo la visione d’insieme. Esistono differenti implementa-
zioni di questo tipo di software, alcune open source altre proprietarie. Elencheremo
le principali:
• Red Hat/Fedora Cluster Suite

• IBM CSM (Cluster Systems Management)

• OSCAR (Open Source Cluster Application Resources)

• xCAT (eXtreme Cluster Administration Toolkit)

Un file system ad alte prestazioni

Un cluster è composto da molti nodi che necessitano la condivisione delle infor-
mazioni garantendo però l’affidabilità, la concorrenza e la velocità d’accesso ne-
cessaria a sostenere la gamma di servizi erogati. Per questo una struttura cluster
che aspira a gestire dei servizi in distribuito deve avere una solida base di memoriz-
zazione comune, affidabile e concorrente. I file system orientati a questo supporto
vengono definiti Distribuited File System e nel prossimo capitolo verranno esamina-
ti in dettaglio alla ricerca di una soluzione adatta alla problematica in esame. Ecco
i principali:

• Red Hat/Fedora Global File System (GFS)

• IBM General Parallel File System (GPFS)

• Andrew File System (AFS)

• ...

1.6 Cluster linux: Conclusioni
Abbiamo discorso come le varie tipologie di cluster aderiscono a problematiche di
tipo diverso (potenza di calcolo computazionale, erogazione di servizi e bilancia-
mento di risorse) passando per una analisi delle componenti hardware e software
principali di una architettura di questo tipo. Questi concetti sono alla base del si-
stema che verrà implementato in laboratorio, fornendo una valida base al file sy-
stem distribuito. Nel prossimo capitolo verranno esaminati in dettaglio i file system
distribuiti, analizzando a fondo le caratteristiche di alcuni di questi.

Capitolo 2

File System locali e distribuiti

Non è la libertà che manca.
Mancano gli uomini liberi.

Leo Longanesi
(Giornalista e scrittore italiano)

Dopo aver discusso ed introdotto le tecnologie alla base dei sistemi cluster esa-
miniamo ora, in una panoramica, i file system e la loro natura, con particolare
attenzione rivolta ai file system distribuiti, oggetto di analisi del nostro progetto.

2.1 Il File System
Concettualmente il file system è una collezione di data types astratti che sono imple-
mentati per l’immagazzinamento, l’organizzazione gerarchica, la manipolazione, la
navigazione, la ricerca e l’accesso ai dati.
Concretamente, invece, il file system è quella parte del sistema operativo che si
occupa, ad esempio, della gestione di file e delle directory, assicurando anche la
sicurezza, la coerenza ed il controllo delle operazioni di accesso alle informazioni
da parte dell’utente.
Il file system tipicamente usa dei dispositivi di memorizzazione come hard disk
o CD-ROM che mantengono l’informazione fisicamente, in questo caso si parla di
file system locali o disk file system. Generalmente, però, può rappresentare ed orga-
nizzare l’accesso a qualsiasi tipo di dato, sia che sia immagazzinato fisicamente in
un dispositivo, sia generato dinamicamente. In questo caso il file system è di tipo
virtuale o network file system, cioè esiste solo come strumento per l’accesso e la
gestione di dati non necessariamente provenienti da un supporto fisico permanen-
te, o locale, come ad esempio i dati provenienti da una connesione di rete (ad es.
Network File System (NFS)).

8 File System locali e distribuiti

Un Distribuited File System (DFS) è un file system che supporta la condivisione
di file e risorse tra più client connessi tramite una rete telematica.

2.2 File System locali o Disk File Systems
Come descritto, i file system locali tipicamente usano dei dispositivi di memorizza-
zione fisica come hard disk o CD-ROM che mantengono l’informazione fisicamen-
te e localmente. Esistono varie implementazioni di file system, alcune standard e
supportate da tutti i sistemi operativi come i file system dei CD-ROM, alcune per
i sistemi Unix-like, come Ext2 e ReiserFS, ed altre basate sulle varie versioni di
Windows, come FAT e NTFS.

• Unix-like file systems:

– Ext2
– Ext3
– ReiserFS
– XFS
– ...

• Windows file systems:

– FAT16
– FAT32
– NTFS

• ISO file systems:

– ISO9660
– ...

2.3 File System distribuiti o Distribuited File Systems
Le principali categorie in cui si suddividono i Distribuited File System (DFS) sono:

1. Distribuited Fault Tolerant File Systems

2. Distribuited Parallel File Systems

3. Distribuited Parallel - Fault Tolerant File Systems

2.4. Analisi dei file system candidati 9

2.3.1 Distribuited Fault Tolerant File Systems
Un file system che appartiene a questa tipologia replica i dati tra i nodi che com-
pongono il cluster per il supporto di operazioni offline e di high-availability.

• Red-Hat/Fedora Global File System (GFS)

• Andrew File System (AFS)

• Open (Source) Global File System (OpenGFS)

• Open (Source) Andrew File System (OpenAFS)

2.3.2 Distribuited Parallel File Systems
Un file system che appartiene a questa tipologia esegue uno split dei dati tra i nodi
che compongono il cluster per ottenere performance computazionali migliori ad
esempio per soluzioni HP-Cluster.

• Parallel Virtual File System 2 (PVFS2)

• Lustre

2.3.3 Distribuited Parallel - Fault Tolerant File Systems
Un file system che appartiene a questa tipologia replica i dati tra i nodi che com-
pongono il cluster per il supporto di operazioni offline e di high availability, sup-
portando inoltre l’accesso parallelo di applicazioni ed utenti ai dati.

• IBM General Parallel File System (GPFS)

• Google File System (GFS)

2.4 Analisi dei file system candidati
Analizziamo ora in maniera più approfondita due dei file system distribuiti presen-
tati, candidati per la successiva implementazione in laboratorio.

2.4.1 Red Hat/Fedora GFS (Global File System)
Red Hat/Fedora GFS è un file system distribuito e fault tolerant, recentemente ri-
lasciato in licenza open source sulle distribuzioni Fedora Core a partire dalla re-
lease 4. GFS è stato originariamente sviluppato come parte di un progetto di tesi

10 File System locali e distribuiti

dell’Università del Minnesota per poi approdare per il completo sviluppo alla so-
cietà Sistina Software. Nel 2001 GFS divenne un prodotto commerciale e il relativo
progetto open source, OpenGFS, si divise dall’ultima public release di GFS. Nel
Dicembre 2003 Red Hat acquista Sistina e nel Giugno 2004, rilascia GFS e molte
parti della sua cluster infrastructure sotto licensa GPL. Gli obiettivi attuali di Red
Hat per il proggetto sono garantire lo sviluppo della comunità open source con il
supporto fornito dalla distribuzione Fedora Core. GFS permette di condividere dati
in una piattaforma comune di archiviazione su una struttura cluster linux, massimiz-
zando l’uso dello storage e diminuendo i costi. Inoltre GFS è uno dei pochi cluster
file system nativo a 64-bit con supporto per le architetture x86, AMD64/EM64T, e
piattaforme Itanium. La sua implementazione supporta fino a 256 nodi ed inoltre è
pienamente supportato sulle piattaforme Red Hat Enterprise Linux e Fedora Core
(cioè non richiede patch per il kernel). Le applicazioni tipicamente supportate in un
ambiente GFS includono:

• Databases (Oracle RAC)

• Applicazioni e Web servers (Apache)

• Applicazioni con supporto NFS

• ...

2.4.2 IBM GPFS (General Parallel File System)
Il file system GPFS della IBM è un file system ad alte performance che permette
un accesso ai dati veloce e affidabile, da tutti i nodi, in un ambiente omogeneo e/o
eterogeneo di cluster servers di tipo AIX o linux. GPFS permette accesso simulta-
neo, ad applicazioni parallele, ad una varietà di file o ad un singolo file da qualsiasi
nodo garantendo un alto livello di protezione e controllo sulle operazioni del file
system. Inoltre GPFS può essere configurato per gestire ed eliminare i Single Point
Of Failure (SPOF) ovvero i singoli punti di guasto nella rete, facendo transitare i
dati dalla sorgente alla destinazione tramite diversi percorsi (supporto nativo al mul-
tipath). A questo si aggiungono le funzionalità di logging e di replicazione dati che
garantiscono la consistenza e l’affidabiltà dei dati in caso di guasto.

2.5 File System locali e distribuiti: Conclusioni
Come presentato, i due file system candidati per l’implementazione hanno analogie
e differenze che li caratterizzano. La nostra scelta verterà su uno dei due per i motivi
discussi e analizzati nel seguente capitolo.

Capitolo 3

Scelta del sistema

We chose to go to the moon [. . . ]
and do the other things, not because
they are easy but because they are
hard.

John Fitzgerald Kennedy
(12 Settembre, 1962)

In questo capitolo analizzeremo la scelta di implementare il file system distri-
buito Global File System (GFS) su piattaforma linux Fedora Core release 4, esami-
nando le componenti caratterizzanti il sistema in termini di prestazioni e di fault-
tollerance oltre ad apprendere le varie topologie di realizzazione dei cluster GFS
basati sul sistema operativo linux.

3.1 Scelta del sistema e del file system: Perchè Red
Hat/Fedora GFS?
GFS è uno dei file system distribuiti con le maggiori referenze del settore ed è
in continua crescita ed evoluzione. La recente apertura di questa tecnologia da
parte della società proprietaria Red Hat, verso la comunità open source, rilasciando
la serie di paccchetti di corredo che formano la cluster suite, oltre ai componenti
fondamentali di GFS sotto la distribuzione Fedora Core release 4 lascia intravedere
un futuro molto roseo per questo file system globale. Da qui la nostra scelta dettata
sia dalle necessità prestazionali che GFS è capace di fornire sia con un occhio di
riguardo all’ambiente accademico che ha nell’open source e nei programmi sotto
licenza GPL, la spina dorsale di molti progetti.

12 Scelta del sistema

3.2 GFS: Caratteristiche generali
3.2.1 Caratteristiche tecniche
GFS è il primo file system con sviluppo nativo a 64-bit, permette la connessione di
più server ad un file system comune basato su di una SAN o su di uno storage con-
diviso, utilizzando la semantica standard per i file system UNIX/POSIX. Inoltre è
altamente scalabile in quanto è possibile aggiungere fino a 256 nodi ed è pienamen-
te integrato con Red Hat Enterprise Linux e Fedora Core release 4. Infine, come
anticipato sopra, è recentemente stato rilasciato sotto licenza GPL, il che lo rende
costantemente aggiornato ed ampliato dalla comunità open source.

3.2.2 La struttura
Le macchine del cluster GFS si appoggiano sul sistema operativo linux. Un com-
plesso volume manager, con estensione per la gestione clusterized dei comandi,
virtualizza in locale le storage units aggregandole in un singolo raggruppamento
logico, il Volume Group (VG). I cambiamenti che un nodo applica al volume sono
visibili all’intero cluster. Su questo volume è possibile creare molteplici partizioni
logiche, ognuna con un proprio file system, tipo GFS, accessibile da tutti i nodi.

3.2.3 Journaling
GFS è un file system di tipo journaled il che significa che tutte le operazioni effet-
tuate sul file system dalle applicazioni, o dagli utenti dei vari nodi, vengono regi-
strate in un journal (diario) prima di essere effettivamente trasmesse al file system.
Ogni nodo mantiene quindi il proprio journal e in caso di node failure la consistenza
del file system può essere rispristinata grazie alle informazioni in esso contenute.

3.2.4 Locking manager
Il lock manager coordina le molteplici richieste che giungono dai nodi per l’ac-
cesso concorrente file sullo stesso file system GFS garantendo la consistenza dei
dati. Fin dalla sua creazione GFS è provvisto di un gestore di lock di tipo modula-
re. Nelle prime versioni le lock information venivano scambiate tramite protocollo
SCSI (DLOCK, DMEP). Dalla versione 6.1 è integrato il Distribuited Lock Mana-
ger (DLM) che permette ad ogni server, tramite la comunicazione del sergnale di
heartbeat, il servizio di lock sul file system. Se il server non è in grado di comuni-
care tramite heartbeat allora il lock manager lo rimuoverà fisicamente, disconnet-
tendolo o spegnendolo, dal cluster, un’operazione detta di fencing. GFS supporta
molteplici fencing mechanisms come i network power switch e HP’s ILO interface.

3.2. GFS: Caratteristiche generali 13

In GFS sono disponibili due differenti lock manager, lo storico GULM o il recente
DLM.

3.2.5 Scalability
Un classico sistema per l’IT consiste di servizi e applicazioni che girano su server
singoli. Se l’hardware dedicato a queste particolari applicazioni è limitato può suc-
cedere che, con il tempo, questo non sia più sufficente andando incontro a quello
che si definisce come una capability shortage. A questo punto l’aggiunta di nuovi
componenti (server o storage device) possono essere facilmente implementati ed in-
tegrati nel sistema finchè non si raggiunge la nuova disponibilità di risorse richiesta.
La possibilità di espansione e modifica dei volume group e dei nodi in un sistema
GFS permette questo tipo supporto in modo semplice e altamente supportato.

3.2.6 Availability
La disponibilità o availability del sistema è un aspetto fondamentale della fornitura
di servizi per l’IT. Per raggiungere una class 3 availability (dal 99% al 99.9%)
è necessario eliminare qualsiasi Single Point Of Failure (SPOF). Per una class 4
availability (dal 99.9% al 99.99%) inoltre è necessario avere dei mirrored data e
un data center secondario per un eventuale disaster recovery. I servizi hanno la
possibilità di essere eseguiti su server multipli o differenti e il breakdown di un
server o dell’intero data center non devono causare che un temporanea sospensione
dei servizi, limitata nel tempo. Un GFS cluster può essere connesso ad un central
storage system via SAN con multi-path I/O, mirror e tecnologia RAID per garantire
queste specifiche.

3.2.7 LAN-free backup
Un data backup è generalmente eseguito da un backup client su di una LAN ad un
dedicato backup server tramite un software dedicato o LAN-free dagli application
server direttamente verso il backup device. E’ possibile in GFS convertire un server
in un backup server. Il backup server sarà in grado di effettuare un backup durante
l’esecuzione di operazioni sul file system senza compromettere le operazioni in
corso sugli application server. Inoltre la possibilità di generare snapshots, o cloni di
volumi, per poi montarli in caso di procedure di ripristino estende questa proprietà.
Per garantire ciò GFS include una quiesce capability per garantire la consistenza dei
dati durante le operazioni di backup. Significa tutti gli accessi al file system sono
halted (fermati) dopo una file system sync operation che coinvolge dati e metadati
in uno stato consistente prima della cattura dello snapshot.


3.2.8 Diskless shared root clustering
Server addizionali possono essere aggiunti facilmente, come abbiamo visto, per
aumentare le capacità del cluster. Se i dati condivisi e l’immagine del sistema ope-
rativo sono sullo shared storage il risultato è un diskless shared root cluster dove
nessuno dei server necessita di un hard disk locale ma ognuno può effettuare il boot
direttamente dalla rete SAN. Sia i dati che l’immagine del sistema operativo sono
condivisi il che significa che la partizione di root (/) per tutti i nodi del cluster è
comune. Come conseguenza la gestione è semplificata. I cambiamenti sono così
effettuati una sola volta e si ripercuotono su tutta la struttura.

3.3 GFS: Architetture implementabili
Dopo aver esaminato a fondo le caratteristiche e le peculiarità di GFS, vediamo
ora in dettaglio alcune delle principali topologie e architetture supportate, per lo
sviluppo di un cluster basato sul file system di Red Hat.
Una Storage Area Network (SAN) e una Local Area Network (LAN) si differen-
ziano per molti aspetti, a partire dalle interfacce fisiche delle due reti, Fibre Chan-
nel (FC) per le SAN ed Ethernet per le LAN. Le Fibre Channel (FC) sono molto
costose ma raggiungono migliori performance nella gestione del carico di lavoro
dello storage sulla rete, mentre il protocollo Ethernet è molto economico e garan-
tisce delle performance adeguate, anche se non eccellenti, nel traffico di network
storage workload, oltre ad essere altamente scalabile.
Potendo fare affidamento su queste tecnologie ci si chiede se e come è possibile
fondere questi due tipi di protocolli per raggiungere le migliori prestazioni, il mi-
glior rapporto prezzo/prestazioni o la minor spesa possibile nell’implementazione
di un sistema GFS. In altre parole ci è possibile mantenere i benefici della tecnolo-
gia SAN in quanto a performance ed efficenza con il basso costo e la scalabilità di
una Gigabit Ethernet? Vediamo alcune architetture ed i relativi benefici.

3.3.1 GFS over SAN
Questa architettura permette di ottenere le più alte performance in termini di shared-
file in quanto le applicazioni accedono allo storage direttamente. La configurazione
GFS over SAN garantisce file performance superiori per i file condivisi e per i fi-
le system come GFS. Le applicazioni linux sono in esecuzione direttamente sui
nodi GFS. Senza file protocols (presenti su Ethernet) o storage servers a rallenta-
re il flusso dati, le performance sono simili ad un singolo server con uno storage
direttamante connesso (DAS).

3.3. GFS: Architetture implementabili 15

Figura 3.1: Topologia GFS over SAN

3.3.2 GFS over GNBD-SAN
Molteplici applicazioni client linux possono condividere gli stessi dati della rete
SAN sulla locale LAN. Il blocco di storage SAN è visto dai nodi GFS come dispo-
sitivi di block storage gestiti da diversi GNBD server. Dalla prospettiva di una client
application lo storage è acceduto come se si trattasse di un device locale ma i dati
sono in realtà residenti sulla SAN. Il file locking e le funzioni di condivisione (sha-
ring) sono gestite da GFS per ogni nodo GFS client. GNBD è un software protocol
per la condivisione in rete dei block device, come iSCSI, anch’esso supportato da
GFS. Quando GFS è usato in congiunzione con GNBD o iSCSI esso è eseguito sui
nodi, la rete SAN e i server GNBD rendono disponibili come locali i device fisici
su cui è mappato il file system.

Figura 3.2: Topologia GFS over GNBD-SAN


3.3.3 GFS over GNBD-DAS
La più economica alternativa implementabile prevede come le applicazioni client
linux possano ottenere vantaggio sfruttando una topologia Ethernet esistente in gra-
do di garantire un accesso condiviso allo storage. Il failover di una applicazione è
automaticamente gestito dalla parte di gestione del cluster (Cluster Suite) mentre il
failover di uno dei server GNBD o di un disk device porta a più serie conseguen-
ze. Da notare che questa architettura si pone come obiettivo la massima econo-
micità possibile, in cui soﬁsticati meccanismi di fault tollerance non sono previsti.
E’ però possibile implementare degli accorgimenti particolari per incrementare da
questo punto di vista le performance di questo tipo di architetture. Si rimanda la
discussione di tali migliorie al capitolo 6.

Figura 3.3: Topologia GFS over GNBD-DAS

3.4 Scelta del sistema: Conclusioni
Di seguito realizzeremo un sistema GFS su architettura GNBD-DAS, non prima
però di aver introdotto le componenti software e i vari pacchetti che costituiscono
tale implementazione.

Capitolo 4

Analisi degli strumenti software

Ci sono 10 tipi di persone al
mondo: chi capisce il codice
binario e chi no.

Anonimo

In questo capitolo analizzeremo le varie componenti software aggiuntive, ri-
spetto al solo sistema operativo, per la realizzazione del nostro sistema basato su
piattaforma linux Fedora Core release 4 e Red Hat Global File System.

4.1 Cluster Suite
Questa suite prevede una serie di componenti software per la realizzazione della
nostra architettura cluster su cui verrà implementato il file system distribuito. I
pacchetti sono disponibili in formato source code dal sito del cluster project e anche
dal sito di Fedora, comprendono vari software per la gestione del cluster, per la
realizzazione dei volumi logici per la creazione di file system di tipo GFS.

4.2 CCS (Cluster Configuration System)
Questo pacchetto provvede alla configurazione delle informazioni per la gestione
del cluster, quali il nome dello stesso, i nomi dei nodi che lo compongono, etc. CCS
è lo strumento che permette ai nodi di localizzare le informazioni di cui hanno bi-
sogno. Il pacchetto comprende vari applicativi e file di configurazione, alcuni dei
quali fondamentali che analizzeremo in dettaglio:

1. Il demone /sbin/ccsd

18 Analisi degli strumenti software

Pacchetti software della suite:
CCS: ccs-0.25-0.17.i386.rpm
Magma: magma-1.0-0.pre21.7.i386.rpm
Magma-plugins: magma-plugins-1.0-0.pre18.3.i386.rpm
CMAN: cman-1.0-0.pre33.15.i386.rpm
CMAN-Kernel: cman-kernel-smp-2.6.11.5- [...] .i686.rpm
Fence: fence-1.27-16.i386.rpm
RGManager: rgmanager-1.9.31-3.i386.rpm
DLM: dlm-1.0-0.pre21.10.i386.rpm
DLM-Kernel: dlm-kernel-smp-2.6.11.5- [...] .i686.rpm
GFS: GFS-6.1-0.pre22.6.i386.rpm
GFS-Kernel: GFS-kernel-smp-2.6.11.8- [...] .i686.rpm
LVM2: lvm2-2.01.08-2.1.i386.rpm
LVM2-Cluster: lvm2-cluster-2.01.09-3.0.i386.rpm
GNBD: gnbd-1.0-0.pre14.6.i386.rpm
GNBD-Kernel: gnbd-kernel-smp-2.6.11.2- [...] .i686.rpm
System-Config-Cluster: system-config-cluster-1.0.24-1.0.noarch.rpm
Perl-Net-Telnet: perl-Net-Telnet-3.03-4.noarch.rpm
GULM: gulm-1.0-0.pre30.1.i386.rpm
Repository: http://fedora.redhat.com/
Tabella 4.1: Pacchetti software della suite

Pacchetti software aggiuntivi:
Cluster Deployment Tool: cs-deploy-tool-0.9.7-1.0.noarch.rpm
Repository: http://people.redhat.com/rkenna/gfs-deploy-tool/
Tabella 4.2: Pacchetti software aggiuntivi

2. Il file /etc/cluster/cluster.conf

3. Il tool ccs_test

4. Il tool ccs_tool

4.2.1 Il demone /sbin/ccsd:
Il demone /sbin/ccsd è uno dei servizi attivi sui nodi del cluster. Questo demone
provvede all’interscambio delle informazioni tra i nodi e la loro corretta configura-
zione. E’ possibile monitorare il suo stato eseguendo il comando:

[root@masternode ~]service ccsd status
ccsd (pid 1825) in esecuzione...

4.2. CCS (Cluster Configuration System) 19

4.2.2 Il file /etc/cluster/cluster.conf

<?xml version="1.0"?>
<cluster alias="lab4cluster" config_version="4" name="114890487422">
<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
<clusternodes>
<clusternode name="node1" votes="1">
<fence>
<method name="1">
<device name="manual" nodename="node1"/>
</method>
</fence>
</clusternode>
<fence>
<method name="1">
</method>
</fence>
</clusternode>
<clusternode name="gnbd1" votes="1">
<fence>
<method name="1">
<device name="manual" nodename="gnbd1"/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman/>
<fencedevices>
<fencedevice agent="fence_manual" name="manual"/>
</fencedevices>
<rm>
<failoverdomains>
<failoverdomain name="lab4faildomain" ordered="0" restricted="1">
<failoverdomainnode name="node1" priority="1"/>
<failoverdomainnode name="gnbd1" priority="1"/>
</failoverdomain>
</failoverdomains>
<resources/>
</rm>
</cluster>

Il file /etc/cluster/cluster.conf contiene tutte le informazioni principali
della struttura cluster. La sua estensione .conf indica che è un file di configurazione
ma la sua struttura interna rivela la sua natura di documento XML. Analizziamolo
in dettaglio. La prima riga contiene l’intestazione del documento XML, seguita
dal tag che definisce le informazioni riguardanti il cluster, nome, alias, e versione
del file di configurazione. Segue poi il tag dedicato al demone di fencing, a cui
si accoda la sezione dedicata ai nodi, con nome e voti di quorum degli stessi e le
informazioni relative ad ogni nodo sul proprio sistema di fencing. Chiusa questa
sezione vi è quella relativa ai failover domain, alle risorse ed ai servizi attivi sul
cluster.


4.2.3 Il tool ccs_test

Il comando ccs_test può essere seguito da 7 diversi comandi, visualizzabili esplo-
rando l’help, da console digitando semplicemente ccs_test. I comandi principali
sono connect e disconnect seguiti poi da altri comandi secondari per il recupero
delle informazioni gestite dal CCS. Il comando ccs_tool connect cerca di con-
nettere il nodo al sistema CCS e in caso di successo ritorna il connection descrip-
tor. Il comando ccs_test disconnect comunica al sistema CCS l’intenzione di
disconnettersi.

[root@masternode ~]# ccs_test -h
Usage:

ccs_test [Options] <Command>

Options:
-h Print usage.
-V Print version information.

Commands:
connect <force> <block> Connect to CCS and return connection
descriptor.
disconnect <desc> Disconnect from CCS.
get <desc> <request> Get a value from CCS.
get_list <desc> <request> Get a value from CCS.
set <desc> <path> <val> Set a value in CCS.
get_state <desc> Get the state in the connection.
set_state <desc> <ncwp> Set the current working path

4.2.4 Il tool ccs_tool

Il comando ccs_tool può essere seguito da 2 comandi, update e upgrade. Il co-
mando ccs_tool update comunica al demone ccsd di aggiornare il file XML di
configurazione /etc/cluster/cluster.conf su tutti i nodi della struttura. Il co-
mando ccs_tool upgrade comunica al demone ccsd di aggiornare gli eventuali
vecchi file di configurazione in formato .ccs al più nuovo formato XML (retrocom-
patibilità con vecchie versioni di GFS).

4.3. Magma e Magma-plugins 21

[root@masternode ~]# ccs_tool -h
Usage::
ccs_test [options] <command>

Options:
-h Print this usage and exit.
-V Print version information and exit.

Commands:
help Print this usage and exit.
update <xml file> Tells ccsd to upgrade to new config file.
upgrade <location> Upgrade old CCS format to new xml format.

4.2.5 Avvio del servizio ccsd
In fase di init del runlevel, dopo l’installazione, questo demone viene avviato auto-
maticamente dal sistema operativo. In caso di necessità è possibile avviare, stoppare
e visualizzare lo stato del servizio direttamente da consolle:

[root@masternode ~]# service ccsd start
Starting ccsd: [ OK ]
[root@masternode ~]# service ccsd status
ccsd (pid 1825) in esecuzione...
[root@masternode ~]# service ccsd stop
Stopping ccsd: [ OK ]

4.3 Magma e Magma-plugins
I pacchetti magma e magma-plugins contengono le librerie e le rispettive plugins
per i lock manager del cluster.

4.4 CMAN (Cluster MANager)
Questo pacchetto provvede alla gestione del cluster e dei moduli aggiuntivi per il
kernel.

Pacchetti software di CMAN:
CMAN: cman-1.0-0.pre33.15.i386.rpm
CMAN-Kernel: cman-kernel-smp-2.6.11.5- [...] .i686.rpm
Tabella 4.3: Pacchetti software di CMAN


A livello concettuale CMAN si compone di due sottosistemi, come si evince
dalla figura, il Connection Manager (CM) e il Service Manager (SM) entrambi
approfonditi in seguito.

Figura 4.1: La struttura di CMAN

Il pacchetto comprende vari applicativi e file di configurazione, alcuni dei quali
fondamentali che analizzeremo in dettaglio:

• I demoni di cman

• Il tool cman_tool

4.4.1 CM (Connection Manager)
E’ uno dei sottosistemi di CMAN che gestisce le operazioni di membership dei
nodi del cluster, le operazioni di join/leave, dei livelli di quorum per evitare gli
split-brain, gestisce la sincronizzazione tramite broadcast/multicast con i segnali
di heartbeat, gestisce gli ID dei nodi, effettua le transazioni multi-stage del join/-
leave di un nodo per garantire la consistenza, usando le Application Programming
Interface (API) per la comunicazione dei suoi membri (SM e CLVMD)

4.4.2 SM (Service Manager)
Il secondo dei sottosistemi di CMAN che gestisce quelli che sono i servizi di co-
municazione con il cluster da parte degli applicativi superiori (GFS, DLM, Fence),
implementa il concetto di service group e recovering dei servizi layered.

4.4.3 I demoni di cman
I demoni raccolti sotto il servizio cman sono quattro, cman_comms, cman_memb,
cman_serviced e cman_hbeat. Tutti questi servizi sono gestiti da un unico demo-
ne che li esegue automaticamente insieme all’avvio del sistema. In caso di necessità
è possibile avviare, stoppare e visualizzare lo stato dei servizi direttamente da con-
solle. In realtà tra le fasi di avvio, stato e stop del servizio intercorrono altre fasi,

4.4. CMAN (Cluster MANager) 23

come il join del nodo dopo l’avvio del servizio e lo stop dei sottosistemi attivi prima
dello stop del servizio, come documentato nell’help:

[root@node1 ~]# service cman start
Starting ccsd: [ OK ]
...
[root@node1 ~]# service cman status
Protocol version: 5.0.1
Config version: 3
Cluster name: 114768214408
Cluster ID: 8280
Cluster Member: Yes
Membership State: Cluster-Member
Nodes: 2
Expected_votes: 1
Total_votes: 2
Quorum: 1
Active subsystems: 4
Node name: node1
Node address: 192.168.4.1
...
[root@node1 ~]# service cman stop
Stopping ccsd: [ OK ]

4.4.4 Il tool cman_tool
Il tool cman_tool permette una serie di operazione per la gestione del cluster e
dei suoi nodi. In particolare è possibile fare il join di un nodo al cluster, oppure
eliminarlo dalla struttura con l’operazione leave o altro, come operazioni di report
sul cluster tramite i comandi status, nodes, services.

Operazione join:

Il comando principale dello strumento cman_tool è il join di un nodo nel cluster. Se
non sono speciﬁcate a riga di comando delle opzioni, il join si basa sulle informazio-
ni fornitegli dal CCS ovvero le informazioni del ﬁle /etc/cluster/cluster.conf.
Altrimenti è possibile fornire le informazioni necessarie per il join del nodo diretta-
mente da console, vediamo un esempio:

[root@node1 ~]# cman_tool -d join -X -c <clustername>
-n <nodename>


Operazione leave:

Comunica a CMAN che il nodo intende lasciare il cluster. Questa operazione non
è permessa se ci sono sottosistemi attivi come DLM o GFS. In tal caso occorre
smontare tutti i ﬁlesystem GFS, disattivare DLM, Fenced e qualsiasi altro servizio
o risorsa del nodo che usi CMAN.

[root@node1 ~]cman_tool leave

Operazione kill:

Comunica a CMAN di ”uccidere” kill un’altro nodo nel cluster. Il nodo locale man-
da un segnale di kill ed i sottosistemi di CMAN provvederanno al suo spegnimento
(tramite i fence device).

[root@node1 ~]cman_tool kill -n <nodenames>

Operazione status:

Visualizza lo stato locale del cluster:

[root@node1 ~]cman_tool status
Protocol version: 5.0.1
Config version: 3
Cluster name: 114768214408
Cluster ID: 8280
Cluster Member: Yes
Membership State: Cluster-Member
Nodes: 2
Expected_votes: 1
Total_votes: 2
Quorum: 1
Active subsystems: 4
Node name: node1
Node address: 192.168.4.1

Operazione nodes:

Visualizza lo stato locale dei nodi del cluster:

4.5. Fence 25

[root@masternode ~]cman_tool nodes
Node Votes Exp Sts Name
1 1 1 M node1
2 1 1 M node2

Operazione services:

Visualizza quanti e quali servizi stanno girando sul cluster:

[root@masternode ~]cman_tool services
Service Name GID LID State CODE
"Fence Domain:" default

4.5 Fence
Il pacchetto Fence e il demone fenced rappresentano e gestiscono il sistema di
I/O fencing del cluster, composto da una serie di agenti in grado di connettersi
ai power-switch connessi alla rete per gestire l’accensione e lo spegnimento ﬁsico
delle macchine. Nella nostra implementazione non faremo uso di power-switch e la
gestione del fencing sarà manuale.

4.6 DLM (Distribuited Lock Manager)
DLM è uno dei due sistemi di lock manager di GFS:

Pacchetti software di DLM:
DLM: dlm-1.0-0.pre21.10.i386.rpm
DLM-Kernel: dlm-kernel-smp-2.6.11.5- [...] .i686.rpm
Tabella 4.4: Pacchetti software di DLM

DLM è usato in aggiunta con CMAN. In alternativa il solo GULM svolge
le stesse funzioni. Molti sistemi cluster distribuiti usano DLM per inter-process
synchronization dove i processi possono essere residenti su macchine differenti.
GFS e CLVM sono due esempi particolari: GFS usa il DLM dal kernel e CLVM
dall’userspace


Figura 4.2: Interazione tra Fence DLM e CMAN

4.7 RGManager (Resource Group Manager)
RGManager è un group failover open source dedicato all’high availability che ga-
rantisce la disponibilità di sistemi critical server e applicazioni in caso di previsti o
improvvisi system downtime.

4.8 GFS (Global File System)
Questo pacchetto è la componente del file system distribuito vero e proprio dei suoi
moduli kernel:

Pacchetti software di GFS:
GFS: GFS-6.1-0.pre22.6.i386.rpm
GFS-Kernel: GFS-kernel-smp-2.6.11.8- [...] .i686.rpm
Tabella 4.5: Pacchetti software di GFS

Il Global File System (GFS) è un file system distribuito disponibile per cluster
linux. GFS si differenzia dagli altri file system distribuiti come AFS, Coda, o Inter-
Mezzo perchè richiede che tutti i nodi abbiano un’accesso diretto e concorrente allo
shared storage. Tutti i nodi in una struttura cluster GFS sono peer. I protocolli più
usati per lo shared storage in ambienti cluster GFS sono FC, iSCSI, GNBD o AoE.
GFS inoltre dipende da un lock manager distribuito come GULM or DLM.

4.9. LVM2 - Cluster (Logical Volume Manager 2) 27

4.9 LVM2 - Cluster (Logical Volume Manager 2)
Il Logical Volume Manager è un gestore di volumi logici avanzato che estende il
concetto di disk storage rispetto ai tradizionali concetti di disco e partizione disco.
LVM concede all’amministratore un maggiore ﬂessibilità e dinamicità nella gestio-
ne dello spazio per applicazioni ed utenti. I volumi LVM possono essere ridimen-
sionati e manipolati a piacere dall’amministratore in caso di necessità a differenza
delle normali partizioni linux standard. Un approfondimento particolare al sistema
LVM sarà effettuato nella B.4, mentre in questo capitolo ci limiteremo ad osservare
la sua struttura e la sua gestione in un ambiente clusterized.

4.9.1 Architettura di un sistema LVM

Figura 4.3: Architettura del sistema LVM


4.9.2 CLVM (Clustered LVM)
CLVM è un demone userland che realizza una estensione a livello di cluster dei
comandi di LVM.
• Comandi eseguibili da qualsiasi nodo del cluster

• Stessi comandi di LVM usati sul singolo host

4.10 GNBD (Global Network Block Device)
GNBD è un sistema di import/export di dispositivi a blocchi locali da/sulla rete. Al
suo interno si trovano i tool di supporto a queste operazioni sia per il lato server che
per il lato client. E’ possibile dunque esportare ed importare device locali tra i nodi
che hanno GNBD. Vedremo ora in dettaglio due dei setup tipici dei sistemi GNBD.
Pacchetti software di GNBD:
GNBD: gnbd-1.0-0.pre14.6.i386.rpm
GNBD-Kernel: gnbd-kernel-smp-2.6.11.2- [...] .i686.rpm
Tabella 4.6: Pacchetti software di GNBD

4.10.1 Basic setup
In un setup di questo tipo la macchina server GNBD esporta sulla rete i suoi dischi
locali, che vengono importati dalla rete dai client GNBD. Analizziamo in dettaglio
i componenti di questa architettura:
• 2+ GNBD client machines, con GFS

• 1 GNBD server machine, senza GFS

GNBD Server Machine

• Avvio il gnbd server daemon:
[root@masternode ]# gnbd_serv

Esporto i block devices (Questo comando si può eseguire molteplici volte, per
esportare molteplici block devices):
[root@masternode ~]# gnbd_export -c -e <unique_gnbd_device_name>
-d <local_partition_name>}

4.10. GNBD (Global Network Block Device) 29

Figura 4.4: GNBD - Basic Setup

GNBD Client Machines (GFS Servers)

• Monto sysfs, se non è già in running:

[root@node1 ~]# mount -t sysfs sysfs /sys

• Carico il modulo gnbd:

[root@node1 ~]# modprobe gnbd

• Importo i devices gnbd (Questo comando importa tutti i device gnbd esportati
dal server. I dispositivi gnbd appariranno in /dev/gnbd/...):

[root@node1 ~]# gnbd_import -i <gnbd_server_machine>


4.10.2 Complex setup
Il Complex Setup comprende inoltre la possibilità di gestire queste modalità:

1. Macchina server con incluso GFS.

2. Macchine server che condividono lo stesso shared storage, possibilità di dm-
multipath dei clients.

3. Combinazioni delle precedenti 1 e 2.

Il setup per la modalità 1 è lo stesso del Basic-Setup. Il setup per la modalità 2
invece è il seguente:

Figura 4.5: GNBD - Complex Setup

Server machines

• Avvio il cluster manager (CMAN) e il fencing come da setup di GFS.

• Avvio il gnbd server daemon.

• Esporto i block devices.

4.10. GNBD (Global Network Block Device) 31

Questo comando, come visto, si può eseguire molteplici volte, per esportare
molteplici block devices. Se l’opzione -c caching non è inclusa nel comando il
device è esportato in modalità uncached, il che permette che sia acceduto da altre
macchine o montato dalla stessa macchina senza avere problemi di consistenza dati.
Inoltre tutti i dispositivi gnbd devono avere nomi univoci sulla rete, se vengono
esportati dei device con gli stessi nomi locali da molteplici server.

Clients machines

• Monto sysfs, se non è già in esecuzione.

• Carico il modulo gnbd.

• Avvio il cluster manager.

• Importo i device gnbd.

Come sopra, questo comando si può eseguire molteplici volte, per importare
molteplici block devices da molteplici server.

4.10.3 Il file cluster.conf sotto GNBD
In un setup simple cached non è strettamente necessario includere il server gnbd
nella sezione nodes del file /etc/cluster/cluster.conf. Se questo non viene
fatto il cluster manager non sarà però in grado di gestirlo in caso diventi unrespon-
sive (non risponda). Questo significa che il cluster può rimanere senza acceso allo
shared storage finchè il server gnbd non viene manualmente riavviato.
In un setup complex uncached invece il server gnbd deve essere incluso nella
sezione nodes del file /etc/cluster/cluster.conf. In questa architettura molte-
plici server gnbd gestiscono lo stesso dispositivo dello shared storage per garantire
il multipath. I server gnbd devono essere gestiti da un agente che in realtà fermi
le macchine invece di tagliare semplicemente l’accesso allo shared storage. Per la
gestione di questi eventi è consigliato l’uso di un network power switch al posto del
fencing manuale.

Non-multipathed setup
<fence_devices>
.
. (other fence_devices)
.
<device name="gnbd" agent="fence_gnbd" servers="gnbd_server">
</fence_devices>


Multipathed setup
<fence_devices>
.
. (other fence_devices)
.
<device name="gnbd" agent="fence_gnbd" option="multipath"
servers="gnbd_server_1 ... gnbd_server_m"/>
</fence_devices>

General setup

Per tutti e due i setup la sezione di fencing deve apparire così:
<node name="gnbd_client_1" votes="1" >
<fence>
<method name="single">
<device name="gnbd" nodename="gnbd_client_1"/>
</method>
</fence>
</node>

4.11 System-Config-Cluster
Il pacchetto system-config-cluster fornisce tutti gli strumenti di gestione del cluster
sotto un’unica interfaccia grafica gestibile da ogni nodo:

Figura 4.6: Cluster Manager

4.12. Gulm 33

4.12 Gulm
GULM è uno dei due lock manager per GFS, GNBD e CLVM, ed è una alternativa
a CMAN e DLM. Un singolo server GULM può girare in modalità stand-alone, in-
troducendo così un Single Point Of Failure (SPOF) per GFS. Tre o quattro GULM
server possono essere in esecuzione contemporaneamente così facendo il failure
di uno o più server può essere tollerato. GULM è ancora supportato come lock
manager per GFS per motivi storici e di retrocompatibilità. L’introduzione nell’ul-
tima versione di DLM chiarisce le intenzioni a riguardo del suo uso da parte degli
sviluppatori del progetto.

4.13 Perl-net-Telnet
Questo pacchetto è un modulo perl per le connessioni client a porte TCP o ad
operazioni di I/O su di una rete tramite protocollo telnet.

Capitolo 5

Implementazione in laboratorio

Mai fidarsi di un computer che non
è possibile gettare dalla finestra.

Steve Wozniack
(Co-fondatore della Apple)

Il risultato dell’analisi dei file system distribuiti e delle architetture cluster fin
qui prese in esame si finalizza nell’implementazione di un piccolo sistema con file
sistem distribuito, realizzato nel Laboratorio 4 (LAB4) della facoltà di Ingegneria
dell’Università di Bologna.

5.1 Il cluster del Lab4
Il sistema realizzato si compone di 3 macchine (nodi) interconnesse tra loro tra-
mite una sottorete privata, lab4cluster, della rete interna al laboratorio. Su queste
macchine, con piattaforma software comune (Fedora Core release 4), è distribuito
il Global File System (GFS).

Figura 5.1: Il modello di macchine usato in laboratorio

36 Implementazione in laboratorio

5.1.1 Profilo Hardware
I tre nodi del sistema cluster sono macchine di tipo desktop basate su architettura
AMD64 con le seguenti caratteristiche tecniche:

Caratteristiche tecniche:
Sistema: Hewlett-Packard HP dx5150 MT(PE679AV)
Processore: DualCore AMD Athlon 64 X2 3800+
Memoria Primaria: 512MB (PC3200 DDR SDRAM)
Memoria Secondaria: ST380013AS (80GB, 7200 RPM, SATA)
Scheda Rete: Broadcom Gigabit Ethernet (10-100 MBit/s)
Tabella 5.1: Caratteristiche tecniche

Figura 5.2: Dettaglio della macchina

5.1.2 Profilo Software
I tre nodi del sistema cluster condividono anche alcune componenti software, come
ad esempio il sistema operativo e la serie di pacchetti caratterizzanti la gestione del
software del cluster e del file system distribuito:

Software:
Sistema operativo: Fedora Core release 4
Kernel release: 2.6.11-1.1369_FC4smp
Tabella 5.2: Software installato

5.2. Topologia I: GFS over GNBD-DAS 37

Come abbiamo introdotto nel capitolo 3 la scelta per l’implementazione del
sistema ricade sulla realizzazione di una struttura GFS over GNBD-DAS basata
sull’architettura cluster implementata in laboratorio.

5.2 Topologia I: GFS over GNBD-DAS
Come visto nel capitolo 3 esistono diverse topologie di implementazione di un si-
stema basato su GFS. La prima scelta ricade sulla topologia GFS over GNBD-DAS,
ovvero su di un sistema che prevede l’uso di tre nodi di cui due saranno nodi GFS
e al tempo stesso client GNBD e uno sarà il server GNBD che esporterà tramite il
protocollo una partizione del suo disco interno o Direct Attached Storage (DAS).

Figura 5.3: Topologia GNBD

5.2.1 Gli attori:
• GNBD Server: Il server GNBD è il nodo centrale di condivisione dei block
device. Tramite il protocollo il server rende disponibile, con il comando di
export, uno o più dei suoi block devices sulla rete.

• GFS Node1: Il primo dei nodi GFS nonchè uno dei due GNBD client ov-
vero uno dei nodi che importa, con il comando di import, i block device resi
disponibili dal GNBD server.


• GFS Node2: Il secondo dei nodi GFS nonchè uno dei due GNBD client ov-
vero uno dei nodi che importa, con il comando di import i block device resi
disponibili dal GNBD server.

5.2.2 Interconnessione Hardware: Il cluster
Le interconnessioni ﬁsiche tra le macchine sono mostrate in ﬁgura 5.4. Le tre mac-
chine hanno ognuna un univoco nome e indirizzo IP e appartengono alla stessa
sottorete (lab4cluster). Le loro schede di rete sono connesse tramite cavi Ethernet
cat. 5e al gruppo prese 159-162 del tavolo del laboratorio. Le prese 159, 161 e 162
forniscono accesso alle tre macchine, tramite lo switch, alla sottorete 192.168.4.x
(lab4cluster), mentre la porta addizionale 160, sempre tramite switch, permette la
connessione esterna alla rete Internet (per usi di servizio).

Figura 5.4: Lab4 - Interconnessioni hardware

5.2. Topologia I: GFS over GNBD-DAS 39

5.2.3 Interconnessione Software: Il file system distribuito
Le interconnessioni delle componenti software tra le macchine del cluster sono
mostrate in figura 5.5. Dal basso verso l’alto i dispositivi Direct Attached Sto-
rage (DAS) connessi tramite protocollo SCSI al server GNBD vengono esportati
sulla rete TCP/IP. Qui vengono importati dai nodi GFS come device locali e tramite
i comandi clusterized di LVM, gestiti dal demone CLVMD, viene creata la struttura
dei volumi logici a supporto del file system. Sul Logical Volume (LV) comune è
creato il file system GFS, acceduto contemporaneamente dai due nodi come se fosse
una risorsa locale.

Figura 5.5: Lab4 - Interconnessioni software


5.3 Implementazione
Vedremo ora l’implementazione, passo passo, eseguita in laboratorio. Questa si
compone di due fasi, la prima riguardante la creazione del cluster, la seconda la
generazione su di esso del file system distribuito.

5.3.1 Installazione del cluster
Una volta ottenuto l’accesso al laboratorio, l’assegnazione di uno spazio dedicato
al progetto e delle tre macchine su cui implementare il sistema, si è provveduto alla
realizzazione del cluster.
• Passo 1: Collocazione fisica delle macchine in laboratorio. Collegamento
dei cavi di alimentazione, delle periferiche di Input/Output (I/O) (tastiera,
mouse e schermo), delle periferiche di rete dei nodi alla rete del laboratorio
tramite cavi Ethernet dalle prese delle postazioni allo switch del LAB4.

• Passo 2: Installazione del sistema operativo (Fedora Core release 4) sulle
macchine. Una volta ottenuto il DVD della distribuzione Fedora Core release
4 dal sito ufficiale di Fedora, si provvede ad installare il sistema opertivo sulle
tre macchine, seguendo la procedura grafica guidata.

– Passo 2.1: Creazione delle partizioni per il sistema operativo e per i
dati. Per i due tipi di macchine facenti parte del cluster devo provvedere
a partizionamenti separati che si rispecchieranno poi nella suddivisione
dei ruoli tra GNBD client e server come specificato nella tabella 5.3.

Partizionamento del GNBD Server:
Device Mount point File system Dimensione
/dev/sda1 / ext3 10GB
/dev/sda2 LVM 65GB
/dev/sda3 estesa 1024
/dev/sda4 swap 1024
Tabella 5.3: Partizionamento del GNBD Server:

– Passo 2.2) Settaggio software della sottorete del cluster: Al prossi-
mo passo della installazione verrà chiesto all’utente se desidera settare
i parametri di connessione alla rete locale del proprio sistema. Questa
operazione è possibile anche in seguito, ma in fase di installazione è
consigliato da subito configurare tale interfaccia come elencato nella ta-
bella 5.5. Successivamente verrà chiesto di inserire la password di root
del sistema, quella presente in LAB4 è visibile in tabella 5.6.

5.3. Implementazione 41

Partizionamento dei Client GFS:
Device Mount point File system Dimensione
/dev/sda1 / ext3 78GB
/dev/sda2 estesa 1024
/dev/sda3 swap 1024
Tabella 5.4: Partizionamento dei Client GFS:
Settaggio sottorete:
Nodo Nome IP Subnet mask
gndb1 gnbd1.lab4cluster 192.168.4.254 255.255.255.0
node1 node1.lab4cluster 192.168.4.1 255.255.255.0
node2 node2.lab4cluster 192.168.4.2 255.255.255.0
Tabella 5.5: Settaggio sottorete:

– Passo 2.3) Fine dell’installazione: Una volta completata l’installazio-
ne il sistema si riavvia, una volta eseguito il reboot una seconda fase di
installazione segue chiedendo la registrazione di un utente principale,
per poi permettere di effettuare il login. La lista degli utenti e degli am-
ministratori del sistema e le relative password installate correntemente
nel LAB4 è presente in tabella 5.6

Utenti del sistema:
Utente Password
root piripicchio
pikkio ncc1701d
Tabella 5.6: Utenti del sistema:

• Passo 3: Modifica dei file di sistema. Per permettere il corretto funziona-
mento della cluster suite, è necessario modificare il file di sistema /etc/hosts,
in particolare nella riga riguardante l’indirizzo di loopback, dove inserisco
l’indirizzo di broadcast della sottorete oltre ad aggiungere come know hosts
gli indirizzi e gli alias degli altri nodi componenti il cluster:

# Do not remove the following line, or various programs
# that require network functionality will fail.
192.168.4.255 localhost.localdomain localhost localhost
192.168.4.254 gnbd1.lab4cluster gnbd1 gnbd1
192.168.4.1 node1.lab4cluster node1 node1
192.168.4.2 node2.lab4cluster node2 node2


• Passo 4: Genereazione ed installazione delle chiavi pubbliche. Questo
passaggio non è strettamente necessario alla fine della realizzazione dell’in-
frastruttura cluster, ma torna di estrema utilità nel caso dell’uso del tool di
configurazione grafico GFS Deployment Tool, e per la gestione dell’installa-
zione del software dai pacchetti .rpm da uno solo dei nodi del cluster. Que-
sta procedura permetterà il login tramite Secure SHell (SSH) senza digitare
ogni volta la password della macchina target essendoci registrati come uten-
ti autorizzati. La generazione delle chiavi pubbliche prevede una serie di
comandi:

– Passo 4.1: Generazione coppia chiavi. Dal nodo da cui voglio eseguire
le shell remote, ad esempio il server GNBD, genero una coppia di chiavi
tramite il comando ssh-keygen specificando l’algoritmo di criptazione
RSA.
– Passo 4.2: Installazione delle chiavi. Una volta generata la chiave la
installo tramite SSH sui nodi del cluster.
– Passo 4.3: Login senza pasword. A questo punto è possibile loggar-
si ad uno dei due nodi del cluster dal GNBD server senza digitare la
password di login:

[root@gnbd1 ~] ssh-keygen -t rsa
Generating public/private rsa key pair.
Entering file in wich to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your Identification has been saved in /root/.ssh/id_rsa.
Your public key has neen saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
ea:c5:f8:32:b8:ff:3a:2e:5d:a8:b7:85:12:69:ea:a7
root@gnbd1.lab4cluster
[root@gnbd1 ~] cat /root/.ssh/id_rsa.pub | ssh node1
’mkdir -p /root/.ssh/; cat >> /root/.ssh/authorized_keys’
root@node1’s password:
[root@gnbd1 ~] cat /root/.ssh/id_rsa.pub | ssh node2
’mkdir -p /root/.ssh/; cat >> /root/.ssh/authorized_keys’
root@node2’s password:
[root@gnbd1 ~] ssh node1
[root@node1 ~] exit
node1 session closed.
[root@gnbd1 ~] ssh node2
[root@node2 ~] exit
node2 session closed.


• Passo 5: Creazione del file cluster.conf. A questo punto è necessario
creare il file di configurazione, in formato XML, del cluster. Questa procedu-
ra può essere eseguita tramite il tool grafico di Cluster Management contenuto
nel pacchetto system-config-cluster o manualmente con un banale edi-
tor di testo rispettando però la struttura sintattica del documento XML. Il file
deve essere posto nella cartella /etc/cluster/cluster.conf che va creata
se non esiste e va copiato nella sua forma definitiva su tutti i nodi del clu-
ster. A seguito è mostrato il file cluster.conf della implementazione in
laboratorio:
<?xml version="1.0"?>
<cluster alias="lab4cluster" config_version="4" name="114890487422">
<fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
<clusternodes>
<fence>
<method name="1">
</method>
</fence>
</clusternode>
<fence>
<method name="1">
</method>
</fence>
</clusternode>
<clusternode name="gnbd1" votes="1">
<fence>
<method name="1">
<device name="manual" nodename="gnbd1"/>
</method>
</fence>
</clusternode>
</clusternodes>
<cman/>
<fencedevices>
<fencedevice agent="fence_manual" name="manual"/>
</fencedevices>
<rm>
<failoverdomains>
<failoverdomain name="lab4faildomain" ordered="0" restricted="1">
<failoverdomainnode name="gnbd1" priority="1"/>
</failoverdomain>
</failoverdomains>
<resources/>
</rm>
</cluster>


• Passo 6: Settaggio dei servizi all’avvio. La gerarchia e la comunicazione
all’interno del cluster è gestita da numerosi servizi che all’avvio del siste-
ma comunicano tra loro interscambiando informazioni sullo stato dei nodi e
dei servizi su di loro attivi. Questi vanno settati affinchè all’avvio del siste-
ma vengano lanciati in automatico all’esecuzione del runlevel. I servizi che
devono essere caricati all’avvio sono:

– Il demone ccsd
– Il servizio cman
– Il demone fenced
– Il demone clvmd
– Il servizio gfs
– Il servizio rgmanager

In Fedora Core release 4, per settare un servizio in avvio automatico al cor-
rente runlevel, è possibile eseguire il comando chkconfig <servizio> on,
che equivale a settare nel menù servizi di sistema l’avvio automatico del servi-
zio. Con questo comando, o dal menù, settiamo ad on i servizi sopra elencati.
Questa operazione va effettuata su tutti i nodi del cluster, per quanto riguarda
il servizio gfs*, solo sui nodi GFS.

chkconfig ccsd on
chkconfig cman on
chkconfig fenced on
chkconfig clvmd on
chkconfig gfs on *
chkconfig rgmanager on

• Passo 7: Riavvio del sistema. Procedo al riavvio dei nodi del cluster. Al
riavvio del sistema nella finestra in cui sono elencati i servizi in esecuzione nel
runlevel, vedo apparire i servizi settati in precedenza (ccsd, cman, fenced,
clvmd, gfs e rgmanager) che, se non vi sono stati errori nel settaggio al passo
precedente, partono correttamente segnalando il loro stato con i caratteri di [
OK ]

• Passo 8: Verifica del cluster. Per verificare la riuscita implementazione del
cluster è possibile, oltre ad aver avuto conferma del corretto avvio dei servizi,
eseguire il tool di gestione o Cluster Management da cui è possibile gestire
e monitorare l’attività dei nodi e dei relativi servizi. Come mostrato in figura
5.6 la struttura del cluster è ben definita nella prima finestra, dove appaio-
no i nodes del cluster (node1, node2 e gnbd1), il fence device (manual) e il


failover domain (lab4failover). Da qualsiasi nodo è possibile lanciare il Clu-
ster Manager e modificare la configurazione aggiungendo/eliminando nodi,
dispositivi di fence e domini di failover oltre ad aggiungere risorse e servi-
zi. Una volta modificata la struttura, le modifiche vengono trascritte nel file
/etc/cluster/cluster.conf della macchina locale e tramite il pulsante
send to cluster è possibile trasmettere la nuova configurazione a tutte le mac-
chine facenti parte del cluster. Nella seconda finestra è possibile visualizzare
lo stato corrente del cluster con i nodi membri e l’elenco dei servizi attivi su
di essi.

Figura 5.6: Il tool Cluster Manager


5.4 Installazione del file system distribuito

Una volta conclusa l’installazione delle componenti software che realizzano l’in-
frastruttura cluster è possibile procede alla realizzazione della struttura di volumi
logici sui quali verrà installato il file system distribuito.

• Passo 1: Export dei device tramite GNBD. Questa operazione prevede
una serie di comandi software con lo scopo di rendere disponibile un di-
spositivo a blocchi locale, o block device, via rete ad una serie di GNBD
client. Dal server GNBD carico il modulo del kernel relativo alla estensione
(modprobe gnbd) e lancio il servizio gnbd_serv. A questo punto con il co-
mando di export, rendo disponibile con il nome globale export1, il device
locale /dev/sda2 sulla rete ai possibili GNBD client.

[root@gnbd1 ~]# modprobe gnbd
[root@gnbd1 ~]# gnbd_serv -v
gnbd_serv: startup succeeded
[root@gnbd1 ~]# gnbd_export -v -e export1 -d /dev/sda2
gnbd_clusterd: connected
gnbd_export: created GNBD export1 serving file /dev/sda2
[root@gnbd1 ~]# gnbd_export -v -l
Server[1] : export1
----------------------------
file : /dev/sda2
sectors : 83891430
readonly : no
cached : no
timeout : 60

• Passo 2: Import dei drive GNBD. Dalla parte client GNBD devo importare
i block device resi disponibili dal GNBD Server sulla rete. A questo scopo,
dopo aver anche qui caricato il modulo del kernel relativo alla estensione
GNBD, eseguo il comando di import indicando di importare tutti i device
esportati dal server gnbd1. Questa operazione deve essere effettuata su tutti i
nodi che intendono poi accedere al file system distribuito, ovvero sul node1 e
node2.

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux

Semelhante a Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux (20)

Mais de Raul Cafini

Mais de Raul Cafini (6)

Analisi ed implementazione di file system distribuiti in ambiente GNU/Linux