Cluster su sistemi Linux per un servizio di condivisione NFS

11 Capitolo 1 - Introduzione 
1 - INTRODUZIONE 
 
Il presente documento descrive la realizzazione di un cluster di sistemi Linux per 
l’erogazione di un servizio NFS attraverso l’uso di una tecnologia sviluppata da Red 
Hat. Tutto questo è stato implementato in ambito virtuale, utilizzando come 
hypervisor KVM. 
 
Lo sviluppo di questo progetto è avvenuto durante un periodo di stage, della durata di 
quattro mesi, svolto nella sede centrale del Consiglio Nazionale delle Ricerche. Lo 
svolgimento di codesto stage è stato necessario per il conseguimento della laurea 
triennale in Ingegneria Informatica presso l’università di Roma ‘La Sapienza’. 
L’obiettivo dello stage è stato l’acquisizione di esperienza nella progettazione e 
realizzazione d’infrastrutture complesse di elaborazione in ambito gestionale. Il suo 
svolgimento ha previsto una fase iniziale di apprendimento delle tecnologie da 
utilizzare (Linux, KVM, Clustering, NFS) cui è seguita successivamente analisi, 
progettazione, implementazione e testing del sistema. 
 
Lo sviluppo di questo progetto ha riguardato, prima di tutto, lo studio dei sistemi 
Linux così da ottenere una maggiore familiarità con essi. Si è studiato in particolare 
il funzionamento della shell Linux. Dopodiché sono stati creati e configurati i sistemi 
virtuali e, su di essi, sono state affrontate delle problematiche relative alla rete, quali 
la configurazione delle interfacce di rete e la gestione del traffico dei dati tra le 
macchine virtuali. Dopo uno studio approfondito del concetto di cluster, e in 
particolare della tecnologia sviluppata da Red Hat, si è configurato l’ambiente 
virtuale in modo da poter lavorare in cluster. Il cluster non è altro che un sistema di 
due o più macchine che cooperano per fornire uno o più servizi. In questo progetto si 
è sviluppato un cluster di sole due macchine che lavorano in modalità Active – 
Passive. Di conseguenza solo una di esse eroga il servizio NFS mentre l’altra rimane 
in attesa di prenderlo in carico nell’eventualità che il primo vada in errore. Questo 
porta all’associazione del concetto di alta affidabilità al cluster sviluppato. Con alta 
affidabilità s’intende un sistema informatico che fornisce un servizio in maniera
12  
continuativa o comunque con un minimo di downtime. L’obiettivo di un tale sistema 
è di rendere il servizio costantemente utilizzabile dagli host che lo richiedono. Il 
servizio offerto quindi, si basa sul paradigma client-server. Il cluster, in particolare, è 
visto come un'unica entità da parte degli host cioè come una singola macchina. Il 
sistema operativo installato nelle macchine è stato CentOS, una distribuzione di Red 
Hat, che mantiene un’alta compatibilità con essa. Di conseguenza è stato possibile 
utilizzare la tecnologia sviluppata da Red Hat per il clustering, la Red Hat Cluster 
Suite. In base ad essa si è riuscito a configurare, tramite interfaccia web, il servizio di 
NFS. NFS sta per “Network File System” ed è un protocollo di rete utilizzato per 
condividere un file system (o una sua parte) tra più computer che appartengono a una 
stessa rete. E’ un protocollo che si basa sul paradigma client- server. In questo caso il 
cluster è il server che implementa tale protocollo. In questa maniera, tutti gli host che 
richiedono il servizio NFS (e che quindi sono i client del protocollo), possono 
accedere al filesystem esportato in rete come se fosse locale a essi e condividere tra 
loro file o directory. 
La struttura che si è data al presente documento è la seguente: Nel secondo capitolo 
viene data una prima spiegazione del concetto di clustering, viene descritto 
l’obiettivo che si vuole raggiungere, i problemi intrinsechi in un sistema di questo 
genere e le relative soluzioni. Infine viene analizzato il progetto più da vicino, 
specificando la struttura della rete e dello storage su cui il cluster si basa per fornire il 
proprio servizio. Nel terzo capitolo sono stati specificati i sistemi operativi installati 
nelle macchine virtuali e la conseguente tecnologia utilizzata per sviluppare il 
cluster. Nel quarto capitolo viene descritto, in maniera più specifica, quali sono i 
componenti software che fanno parte della tecnologia utilizzata per creare il cluster, 
il loro funzionamento e come si relazionano tra di loro. Nel quinto capitolo vengono 
descritti i vari passi che sono stati fatti per configurare l’ambiente virtuale in modo 
tale da poter lavorare in cluster. Nel sesto capitolo viene descritta la metodologia con 
cui il cluster deve essere creato e configurato tramite l’interfaccia web resa 
disponibile dalla tecnologia di Red Hat. Nel settimo capitolo vengono descritte le 
prove utilizzate per testare il cluster e i risultati ottenuti. Infine, nell’ottavo capitolo, 
viene descritto l’uso che verrà fatto di questo progetto da parte del Consiglio 
Nazionale delle Ricerche. In appendice si trova il file di configurazione del cluster. 
Esso rappresenta la situazione finale in cui si trova.
13 Capitolo 2 – Descrizione del progetto 
2 - DESCRIZIONE DEL PROGETTO 
 
2.1.  Scenario applicativo e obiettivo del progetto 
 
Il progetto sviluppato descrive la realizzazione di un cluster su sistemi Linux il cui 
scopo è di offrire un servizio di condivisione file via rete. 
Con il termine cluster s’intende un sistema di due o più computer, connessi tramite 
una rete locale, che lavorano congiuntamente come se rappresentassero un singolo 
sistema. 
Esistono varie tipologie di cluster che si differenziano in base di diversi criteri. 
 In base alle funzionalità offerte si distinguono: 
o Cluster per l’alta affidabilità (HA, High Availability) 
Per alta affidabilità s’intende la capacità di un sistema informatico di 
erogare un determinato servizio in modo continuo e quindi di essere 
costantemente utilizzabile dai propri utenti. 
o Cluster per il bilanciamento del carico (LB, Load Balancing) 
In questo caso l’obiettivo è di aumentare il throughtput del servizio 
cioè servire il maggior numero di richieste da parte degli utenti che si 
connettono al cluster. Il cluster è impostato in modo tale che, in base 
al numero di richieste ricevuto, distribuisce il carico di lavoro tra i 
vari computer in modo da farli lavorare in concomitanza
1
. 
o Cluster per alte prestazioni (HPC, High Performance Computing) 
E’ un cluster che esegue processi computazionalmente complessi e 
che richiedono molto tempo di elaborazione (calcoli scientifici o 
computer graphics). In tal caso, il processo è suddiviso in più sotto-
                                                 
 
1
 Cioè è svolto attraverso l’uso di vari algoritmi, ognuno con politiche diverse per la scelta della 
distribuzione del carico.
14 2.1 Scenario applicativo e obiettivo del progetto 
processi e ognuno di essi sarà eseguito in parallelo da un computer del 
cluster
2
. 
Un cluster può anche fornire una combinazione tra le suddette tipologie. 
 In base all’architettura hardware/software dei computer che lo compongono, 
si distinguono: 
o Cluster con architettura omogenea (hw/sw identico) 
o Cluster con architettura eterogenea (hw/sw diverso) 
 In base al tipo di storage che utilizzano, si distinguono: 
o Cluster shared-everything 
Tutta l’infrastruttura lavora su un’area comune di storage (es. SAN). 
In particolare, nel cluster è presente un componente software che si 
occupa esclusivamente di regolare l’accesso concorrente ai dati da 
parte dei computer, per evitare l’inconsistenza dei dati stessi. 
o Cluster shared-nothing 
Ogni computer lavora su una propria area di storage. In tal caso il 
componente software del cluster, adibito al controllo dell’accesso allo 
storage, si occuperà di mantenere aggiornati i dati tra i vari computer 
così da renderli sempre coerenti. 
Nel nostro caso il raggruppamento di questi computer, che in particolare sono 
chiamati nodi del cluster, ha come scopo quello di poter fornire un servizio ad alta 
disponibilità (cluster HA). 
Gli host che si connettono a un cluster per usufruire dei servizi che esso offre, sono 
indicati più comunemente come client del cluster. 
L’obiettivo del progetto è stato la realizzazione di un cluster che fornisse un servizio 
di NFS (Network File System) ad alta disponibilità. L’utente che richiede il servizio 
deve poter usufruire di esso in ogni momento, per tutto il tempo necessario e 
possibilmente senza interruzioni. Se per vari motivi il servizio non risulta 
disponibile, esso verrà ripristinato il prima possibile dal cluster stesso. 
                                                 
 
2
 Molti studi sono incentrati sulla teoria del calcolo parallelo e sulla sua ottimizzazione.
15 Capitolo 2 – Descrizione del progetto 
Lo scopo del cluster, infatti, è quello di far percepire il meno possibile la mancanza 
del servizio al client che lo ha richiesto. Il cluster interviene e risolve il problema 
senza rendere visibile questa disfunzione all’utente. 
Il funzionamento di un cluster HA può essere così riassunto. In generale, se un 
cluster è formato da N nodi, ognuno di essi può fornire un certo servizio. 
I servizi che un cluster può offrire sono molteplici. Oltre a quello di uno storage 
condiviso in rete, altri possono essere ad esempio: 
 Server Web 
 Server Mail 
 FTP 
 E-commerce 
 Caching dei nomi (associati agli utenti, agli IP, ecc.) 
 Database 
 Simulatori 
 Calcoli scientifici 
 Rendering, computer graphics 
Se uno di questi nodi ha un problema e non riesce più a fornire il servizio a lui 
assegnato, tale servizio è semplicemente spostato su un altro nodo il quale 
provvederà a fornire entrambi i servizi (il suo e quello preso in carico). 
Questo processo di spostamento del servizio tra due nodi è detto failover. In 
particolare, dal punto di vista del nodo che prende in carico il servizio, tale processo 
è detto più precisamente takeover. 
Ogni servizio si basa sull’utilizzo di varie risorse che possono essere ad esempio un 
indirizzo IP, un filesystem condiviso o locale, uno script, un database MySQL, ecc. 
Per consentire al cluster di eseguire il failover, queste risorse devono essere gestite 
dal cluster stesso e non dal sistema operativo dei nodi. 
Ci possono essere casi in cui alcuni nodi del cluster forniscono dei servizi mentre 
altri non ne forniscono nessuno. Questi ultimi, detti in particolare nodi di standby, 
rimangono in attesa di prendere in carico i servizi eseguiti dai nodi che 
eventualmente incontreranno dei problemi. 
I nodi che invece eseguono dei servizi, ed eventualmente sono pronti a compiere il 
takeover di altri, sono detti nodi di backup.
16 2.1 Scenario applicativo e obiettivo del progetto 
Quando è risolto il problema su un nodo che era andato in errore, si può decidere se 
il servizio che è stato spostato in precedenza debba tornare a essere eseguito sul nodo 
“originale” oppure continuare a essere fornito dal nodo che l’ha preso in carico. Il 
processo per cui un servizio torna a essere eseguito sul nodo originale è detto 
failback. 
Il processo di failover e di failback, così come tutte le altre operazioni svolte nel 
cluster, sono eseguite da un software di gestione del cluster. In base alle diverse 
tecnologie utilizzate per la realizzazione del cluster, il software di gestione è 
composto da diverse componenti che lavorano insieme rispettando determinate 
modalità d’interazione. 
L’approccio più comune con cui s’inizia ad affrontare il concetto del clustering è di 
creare cluster formati da soli due nodi. Questo perché è la dimensione minore che 
permette la ridondanza dei servizi
3
 e mantiene una semplicità di gestione del cluster. 
In genere però i cluster sono formati da molti più nodi, secondo le esigenze da 
soddisfare. 
Nel caso di cluster di due nodi, esistono due possibili tipi di configurazioni dette 
Active – Passive o Active – Active. La prima indica che un nodo è attivo, cioè 
fornisce uno o più servizi mentre l’altro è in standby. La seconda invece indica che 
entrambi i nodi che formano il cluster forniscono uno o più servizi. 
Come già è stato detto, il servizio offerto dal cluster è un filesystem condiviso in rete 
secondo la tecnologia NFS. Essa si basa sul fatto che uno dei nodi del cluster 
“monta” nel proprio sistema un filesystem che risiede in uno storage condiviso da 
entrambi (il cluster quindi è in configurazione shared-everything). Tale filesystem 
sarà reso accessibile ai client attraverso la rete. Ogni client, per accedere al 
filesystem e utilizzarlo per i propri scopi, deve collegarsi al cluster attraverso 
l’indicazione di un indirizzo IP
4
. Collegandosi a tale IP riesce a utilizzare il 
filesystem come se fosse locale al proprio sistema
5
. 
                                                 
 
3
 Cioè se il servizio non può essere fornito da un nodo, ne esiste almeno un altro pronto a farlo al suo 
posto. 
4
 Essendo l’NFS un servizio basato sulla rete. 
5
 Questo è uno dei motivi principali per cui si utilizza la tecnologia NFS.
17 Capitolo 2 – Descrizione del progetto 
In realtà, il client non si connette propriamente al nodo che fornisce il servizio NFS 
(detto in particolare nodo server) ma al cluster in generale
6
. Questo perché il client 
non conosce l’infrastruttura che c’è dietro alla fornitura del servizio richiesto, non sa 
come funziona e quale nodo sta fornendo il servizio. Esso pensa di interagire con una 
singola macchina e non con un insieme di macchine messe in cluster. Per questo il 
cluster, dal lato del client, è percepito come fosse una singola entità
7
. 
 
                                                 
 
6
 Ciò sarà spiegato più dettagliatamente nel paragrafo 2.4. 
7
 Tale proprietà del cluster è detta SSI (Single System Image).
18 2.2 Problematiche e successive considerazioni 
2.2 Problematiche e successive considerazioni 
 
Il sistema informatico da realizzare deve fornire la capacità di fault-tolerance 
nell'erogazione di un servizio. L'obiettivo (teorico) di un sistema ad alta affidabilità è 
di garantire la disponibilità del servizio 24x7 (24 ore su 24, 7 giorni su 7). Nella 
realtà ciò non è del tutto possibile. Attraverso ingenti investimenti economici è 
possibile avvicinarsi a tale obiettivo ma comunque ci sarà sempre qualche caso in cui 
il servizio potrebbe interrompersi. 
Ad esempio, ciò potrebbe avvenire a causa di: 
 Guasti dell’hardware 
 Malfunzionamenti del Sistema Operativo o delle applicazioni 
 Interventi di manutenzione (pianificati o no) 
 Errori umani 
In genere i requisiti che un sistema ad alta affidabilità deve soddisfare sono legati al 
tempo di disponibilità di un servizio, alle prestazioni globali del sistema e alla sua 
economicità. 
Naturalmente il requisito sulla disponibilità è quello che maggiormente caratterizza 
un sistema informatico altamente disponibile. 
2.2.1 I livelli di disponibilità 
Essi potrebbero essere schematizzati in livelli concentrici, dall’implementazione più 
semplice a quella più complessa. Ad esempio: 
 Livello 1: Disponibilità normale 
L'unica protezione contro l'interruzione del servizio è data dal backup dei dati, 
fatta a discrezione dell'amministratore del sistema. In caso di errore, la ripresa 
dell'erogazione del servizio avverrà solamente dopo il ripristino dei dati del 
backup. Inoltre è possibile che siano ripristinati dati relativamente aggiornati e 
ciò dipende dalla frequenza con cui si esegue l'operazione di backup. Il tempo 
che intercorre tra l'interruzione del servizio e il suo riavvio dipende quindi dai 
"tempi umani" legati all'attività dell'amministratore di sistema.
19 Capitolo 2 – Descrizione del progetto 
 Livello 2: Mirror dello storage 
In tal caso, lo scopo del sistema è la protezione dei dati "nel miglior 
aggiornamento possibile" cioè riguardo quelli più recenti. Ciò è realizzato 
attraverso il mirroring fisico dei dischi utilizzando la tecnologia RAID. Essa è 
una delle soluzioni più economiche per aumentare la tolleranza all'errore per 
l'accesso ai dati. Utilizzando questo livello di disponibilità, il sistema riesce a 
mantenere sempre aggiornati i dati e a ripristinarli (anche a “caldo”) nel caso di 
danni su un dispositivo di memorizzazione. 
 Livello 3: Cluster HA 
Questo livello garantisce la protezione del sistema e dell'erogazione dei servizi. 
 Livello 4: Disaster recovery 
Questo livello è un'evoluzione dell'HA e risulta lo "sforzo massimo" per ottenere 
la continuità di un servizio. Prevede la completa replica del sistema in un'altra 
area geografica più o meno distante dalla prima (ad esempio nello stesso edificio 
o in un altro), a seconda del livello di fault-tolerance che si vuole implementare. 
Con tale soluzione in breve tempo si è di nuovo operativi. 
Naturalmente, più la soluzione è complessa e più la sua implementazione è costosa. 
La scelta di quale soluzione utilizzare dipende dalle esigenze dell’azienda 
nell'erogazione dei propri servizi
1
. 
Il nostro caso naturalmente riguarda il livello 3. 
2.2.2 Storage e integrità dei dati 
Lo storage comprende i dispositivi e i filesystem utilizzati per la memorizzazione dei 
dati condivisi dai nodi. 
I dispositivi di storage, come già è stato descritto, possono essere: 
                                                 
 
1
Ad esempio, se la maggior parte degli introiti di un’azienda sono dati dalla pubblicità, un fermo di un 
ora gli porterebbe via molto denaro. In tal caso per l'azienda ha senso spendere molti soldi (anche di 
più di quelli che perde per l'indisponibilità del servizio) per strutturare un livello di fault-tolerance 
adeguato.
20 2.2 Problematiche e successive considerazioni 
 Locali ai singoli nodi, con replicazione dei dati in tempo reale o a intervalli 
regolari di tempo 
 Condivisi, fisicamente
2
 o tramite rete 
Uno storage condiviso solitamente è preferibile a uno storage replicato. Per quelli 
che si basano sulla rete, le tecnologie utilizzabili sono NAS (Network-Attached 
Storage) e SAN (Storage Area Network). Le SAN possono essere realizzate con 
Fiber Channel, con ISCSI (Internet SCSI) o IFCP (Internet Fiber Channel Protocol) 
oppure attraverso una rete Ethernet basata sul protocollo AoE (Ata Over Ethernet). 
I dispositivi di storage in genere sono utilizzati in configurazione ridondata per 
poterne aumentare l’affidabilità (configurazioni RAID). 
Per quanto riguarda i filesystem invece è possibile utilizzare filesystem tradizionali, 
filesystem di rete (NFS o CIFS) o addirittura filesystem pensati esclusivamente per i 
cluster (Veritas, GFS, StoreNext). 
Per semplificare la loro gestione spesso si utilizzano sistemi di gestione dei volumi 
logici. Tramite essi è possibile facilitare l’aggregazione, il ridimensionamento, la 
replicazione ed il backup delle aree di storage (volumi). 
Infine per quanto riguarda l’integrità dei dati, aspetto molto importante 
indipendentemente dall’HA o meno, a livello di filesystem il pericolo di 
danneggiamento dei dati può essere risolto tramite il journaling, che consente di 
ripristinare una situazione consistente in seguito ad un crash del sistema, oppure 
tramite il locking, che consente di ridurre i rischi di inconsistenza relativi ad accesi 
concorrenti sui dati dello storage. 
Il cluster utilizza un meccanismo di locking. 
Il progettare bene un sistema HA sta anche nello studio preventivo di tutte queste 
problematiche. Ciò permette di definire bene le attese e il reale utilizzo che si farà del 
sistema. 
                                                 
 
2
 Tipico per un cluster di due nodi perché altrimenti i collegamenti fisici sarebbero molti.
21 Capitolo 2 – Descrizione del progetto 
2.2.3 Misura della disponibilità 
Il concetto di disponibilità di un servizio può essere formalizzato attraverso la misura 
di vari aspetti. Con MTBF (Mean Time Between Failure) s’indica il tempo medio di 
funzionamento di un sistema prima che avvenga un guasto, cioè indica la sua 
affidabilità. Con MTTR (Mean Time To Repair) s’indica il tempo medio di 
downtime (periodo in cui il servizio non è in funzione) a seguito di un 
malfunzionamento del sistema. Detto ciò, la disponibilità di un sistema, indicata con 
A, si può formalizzare come: 
  
    
         
 con A ∈ [0,1] 
In pratica, A misura il tempo di corretto funzionamento di un sistema (uptime). La 
certezza di ottenere un servizio totalmente affidabile (A=1) non può esserci per i vari 
motivi descritti in precedenza. Nella realtà si ha che un servizio è disponibile per 
A=0.9, A=0.99, ecc. Questo introduce un altro tipo di misura che si basa sul numero 
dei 9. Essa indica la percentuale di uptime annuale di un servizio. Tale percentuale si 
ottiene moltiplicando A per 100. Ad esempio: 
Tabella 2.2.33.1 Misura della disponibilità di un servizio HA 
n° di 9 Uptime Tempo di downtime associato 
1 90,00000% 37 giorni 
2 99,00000% 3,7 giorni 
3 99,90000% 8,8 ore 
4 99,99000% 53 minuti 
5 99,99900% 5,3 minuti 
6 99,99990% 32 secondi 
7 99,99999% 3 secondi 
 
Il compito di chi crea un cluster altamente affidabile è quello di rendere 
l'infrastruttura in grado di ottenere il minimo tempo di disservizio possibile. Per fare 
ciò bisogna conoscere bene quali sono i problemi che intervengono negativamente 
nell'erogazione dei servizi, nella gestione dell'infrastruttura e nell'utilizzo delle 
risorse. 
La strategia che consente di raggiungere un elevato livello di disponibilità consiste 
innanzitutto nell'eliminazione degli SPOF.