Cluster File System

Cluster File System
Andrea Chiffi
matr. 10059634
<andrea.chiffi@gmail.com>
Esame di Sistemi di Elaborazione e Progetto I

Prof. Giovanni Aloisio
Dott. Osvaldo Marra
Corso di laurea specialistica in Ingegneria Informatica

Università del Salento
Lecce, 24 luglio 2008
Sommario
Questo documento descrive i cluster file system: nel primo capitolo vengono illustrate le motivazioni che hanno portato al loro sviluppo ed utilizzo nel settore dellHigh Performance Computing
(HPC), partendo da unintroduzione alle varie tipologie di file system. Viene, inoltre, descritta
nel dettaglio la terminologia utilizzata per descrivere le funzionalità di questa tipologia di file
system.
Nel secondo capitolo, vengono illustrate le varie soluzioni di cluster file system attualmente
disponibili, incluso larchitettura e le caratteristiche del parallel file system PVFS2.
Nel terzo capitolo viene descritta in dettaglio la realizzazione di un minicluster composto
R
R
da nodi Intel
Itanium
2, partendo dallinstallazione di una distribuzione GNU/Linux, fino
allinstallazione, configurazione e messa in opera di PVFS2.

Nella parte finale di questo documento, viene inoltre descritta la fase di benchmarking di
questo parallel file system, comparandolo con il file system distribuito NFS.
Cluster File System by Andrea Chiffi is licensed under a Creative Commons

AttribuzioneNon commercialeCondividi allo stesso modo 2.5 Italia License.
Sources: http://www.salug.it/~much0/cluster-file-system/
License: http://creativecommons.org/licenses/by-nc-sa/2.5/it/
ii
Indice
Indice
1 Introduzione ai cluster file system
1.1
1.2
Introduzione ai file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1
File system locali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2
File system distribuiti o di rete . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3
File system virtuali o per compiti speciali . . . . . . . . . . . . . . . . . .
File system e applicazioni in ambiente cluster . . . . . . . . . . . . . . . . . . . .
1.2.1
Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Cluster file system: le soluzioni disponibili
10
2.1
IBM GPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2
LUSTRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3
Red Hat GFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4
HDFS (Hadoop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5
GlusterFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.6
PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7
Confronto delle soluzioni analizzate . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 Installazione e test di un parallel file system

3.1
3.2
3.3
3.4
45
Realizzazione di un minicluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1
Distribuzione Rocks Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2
Architettura del cluster leonardo . . . . . . . . . . . . . . . . . . . . . . 46
3.1.3
Installazione di Rocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Compilazione e installazione di PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2.1
Requisiti software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2
Compilazione e installazione . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configurazione e avvio di PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3.1
Configurazione dei server . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3.2
Avvio dei server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.3
Configurazione dei client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.4
Avvio dei client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Benchmark di PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Capitolo 1
Introduzione ai cluster file system

Negli ultimi anni la tecnologia VLSI1 ha fatto grandi passi avanti, con un conseguente
aumento delle performance dei processori e delle memorie RAM; qualcosa di simile non è per`
o
avvenuto per le memorie di massa, che stanno gradualmente diventando i componenti pi`
u lenti
di un calcolatore. In molte applicazioni reali, soprattutto nellambito della ricerca scientifica, è
necessario manipolare una notevole mole di dati, che non può essere contenuta completamente
nelle memorie principali; è dunque necessario trasferire questi dati dalla memoria centrale ai
dispositivi di massa e viceversa, con una notevole calo delle prestazioni dovuto ai tempi di accesso
ai dischi. In simili contesti il sistema di I/O rappresenta a tutti gli effetti un collo di bottiglia
che limita le prestazioni dellintero sistema, rappresentando, ad esempio, un fattore di riduzione
dellaccuratezza di simulazioni scientifiche. Lutilizzo di file system progettati appositamente
per questi ambiti (cluster file system) costituisce uno dei possibili approcci al problema.
1.1
Introduzione ai file system
Un file system è un meccanismo con il quale i file sono immagazzinati e organizzati su un

dispositivo di archiviazione (storage), come un hard disk o un CDROM. Pi`
u formalmente, un
file system è linsieme dei tipi di dati astratti necessari per la memorizzazione, lorganizzazione
gerarchica, la manipolazione, la navigazione, la ricerca, laccesso e la lettura dei dati.
Nel corso della storia informatica, sono stati ideati una moltitudine di file system. I sistemi operativi moderni sono in grado di accedere a diversi file system spesso semplicemente
installando un apposito modulo o driver.
I file system possono essere classificati in diverse tipologie:
file system locali;
file system di rete o distribuiti;
file system per compiti speciali;
1
Very large scale integration (VLSI) è una denominazione generica che indica unelevata integrazione di
transistor allinterno di un singolo chip.
Capitolo 1. Introduzione ai cluster file system

file system utilizzati in ambienti cluster (cluster file system).
1.1.1
File system locali
I file system locali accedono a dispositivi di storage direttamente collegati alla macchina.
I dispositivi di archiviazione non sono condivisi, pertanto non vi è la necessità di prevedere
funzionalità di condivisione nella progettazione di questa tipologia di file system, che, quindi, si
occupa solo della gestione fisica dei file e directory sul dispositivo di memorizzazione, fornendo
un livello di astrazione per tutte le applicazioni che necessitano dellaccesso e la manipolazione
dei dati. In questa categoria rientrano i ben noti ext3 (una versione di ext2 con supporto
al journaling), ReiserFS, XFS, JFS (IBM journaling file system), ISO 9660 (utilizzato per
i CDROM), FAT, NTFS (utilizzato dalle recenti versioni di Windows), HFS+ (utilizzato da
Mac OS X) ed il pi`
u recente ZFS di Sun Microsystems. Oltre a questi ne esistono altri ottimizzati
per luso con dispositivi di memorizzazione particolari, come JFFS2, utilizzato per le memorie
FLASH.
1.1.2
File system distribuiti o di rete
Un file system distribuito o network file system permette di accedere ai file contenuti su un
computer remoto tramite rete, potenzialmente in simultanea da diversi computer. A differenza
dei file system citati in precedenza, i dati non vengono letti o archiviati su di un dispositivo
locale, ma, attraverso un meccanismo client/server, su dispositivi remoti, collegati in maniera
trasparente alla propria gerarchia di file. Inoltre, un file system distribuito deve poter gestire i
file in maniera trasparente e concorrente e, di solito, è dotato di sistemi di autenticazione e, a
volte, di cifratura.
NFS (network file system), introdotto nel 1985 da Sun Microsystems, è il file system distribuito pi`
u diffuso ed utilizzato in ambienti UNIX. Oltre a questo, particolarmente apprezzati sono
anche AFS (Andrew file system), che utilizza un meccanismo di caching nei client e Kerberos
per lautenticazione, CODA, sviluppato dalla Carnegie Mellon University e fault tolerant (attraverso la replicazione dei dati e lutilizzo in modalità disconnessa), e CIFS (noto anche come SMB
o Samba) utilizzato nelle reti Windowsbased. Oltre a questa tipologia di file system, esistono
anche recenti implementazioni di file system distribuiti basati sul paradigma di comunicazione
peertopeer .
1.1.3
File system virtuali o per compiti speciali
Alcuni file system vengono utilizzati per compiti speciali che non rientrano direttamente
nelle prime due categorie. Molti non hanno alcuna relazione con un supporto di memorizzazione
permanente dei dati, ma vengono utilizzati dal sistema operativo per dare accesso ad alcune
funzionalità. Alcuni esempi presenti in ambiente GNU/Linux sono:
procfs : file system virtuale contenente tutti i dati relativi allo stato del sistema e dei processi;
1.2. File system e applicazioni in ambiente cluster
tmpfs : file system temporaneo basato sulla memoria di sistema;

sysfs : introdotto con il kernel linux 2.6, sostituisce procfs per quanto riguarda linterazione
del kernel con luserspace;
FUSE : file system in userspace;
UnionFS : permette di sovrapporre file e directory di file system separati, in maniera trasparente alle applicazioni.
1.2
File system e applicazioni in ambiente cluster
Il termine cluster file system rappresenta un file system distribuito che non consiste di un
singolo server e di un set di client (come NFS ), ma di un cluster di nodi server che, cooperando
insieme, forniscono a tutti i client un servizio ad alte performance. Questo servizio viene fornito
in maniera del tutto trasparente ai nodi client del cluster: è il file system stesso che si occupa
della distribuzione delle varie richieste agli elementi che compongono lo storage cluster.
Il design di un cluster file system differisce, quindi, da quello di un file system locale poiche
enfatizza gli aspetti relativi alla condivisione, connettività e caching (lato client). A differenza
di quello che accade nei file system locali, nei cluster file system tutte risorse relative al file
system (inclusi i metadati2 ) sono distribuite nellintero sistema di storage [2].
Un cluster file system permette ai nodi allinterno del cluster di leggere e scrivere simultaneamente file e directory. I dati di un cluster file system, infatti, non appartengono ad una porzione
del file system o a particolari nodi, ma sono estesi allintero cluster. In definitiva, lobiettivo
finale di un cluster file system moderno consiste nella creazione di un sistema software scalabile,
attraverso applicazioni multiple in esecuzione su diversi server, tutte facenti riferimento allo
stesso pool di storage condiviso in rete.
Per raggiungere la condivisione dinamica delle operazioni di I/O attraverso tutti i server e i
nodi di storage, un cluster file system deve effettuare sofisticati controlli su quale nodo possiede
i diritti di accesso ad una certa porzione di dati in un determinato istante di tempo. La tecnologia che si occupa di gestire laccesso ai dati viene denominata Distribuited Lock Manager
(DLM) e, se ben progettata, permette al cluster file system di scalare su decine o centinaia di
nodi, assicurando alte performance e la coerenza dei dati in ogni istante di tempo [5].
Prima di illustrare pi`
u in dettaglio le caratteristiche e larchitettura di un cluster file system,
è necessario, comunque, introdurre la terminologia che verrà utilizzata in seguito, iniziando
col chiarire brevemente cosè un cluster e quali sono i vari ambiti applicativi nei quali viene
utilizzato.
2
I metadati sono informazioni che descrivono un insieme di dati. La funzione principale di un sistema di
metadati è quella di consentire operazioni quali la ricerca, la localizzazione, la selezione, la gestione delle risorse e
la diponibilit`
a. Alcuni file system memorizzano i metadati in strutture dati come le directory o gli inode o anche
nei nomi dei file. I metadati possono spaziare dai semplici timestamp e permessi di un file, a commenti di testo,
icone o altre informazioni specifiche di una particolare implementazione.
1.2.1
Terminologia
Dal punto di vista dello storage, la maggior parte dei cluster è costituito da 2 componenti
fondamentali (Fig. 1.1):
i nodi, connessi tra di loro attraverso una qualsiasi tecnologia di interconnessione;
il cluster file system, ovvero lo strato software che permette ai nodi del cluster di condividere i dati e lavorare insieme come una singola entità.
n0
n1
n2
n3
n4
n5
n6
Cluster Network
s0
s1
s2
s3
s4
Figura 1.1: Nodi server di I/O (s0. . . s4) e nodi di calcolo (n0. . . n6) di un cluster.
In generale, le applicazioni di un cluster possono essere suddivise in varie tipologie [2]:
1. High performance clusters, chiamati anche computational cluster systems, sono i sistemi
normalmente utilizzati per la ricerca scientifica, in quanto forniscono unelevata potenza
di calcolo, in genere eseguendo calcolo parallelo su volumi di dati molto grandi. In questi
ambienti, il cluster file system si occupa di distribuire i dati da processare ai nodi di
calcolo, consentendo ad ogni nodo di accedere agli stessi file in maniera concorrente;
2. High availability (HA) clusters, che implementano tecniche di tolleranza ai guasti e ridondanza dei dati, per assicurare unalta disponibilità del servizio, spesso per fornire
tipologie di servizi come File Server o Database Server. In genere, è costituito essenzialmente da 2 server identici, ciascuno dei quali è costruito in maniera tale da ridondare
quelle componenti hardware il cui guasto potrebbe risultare fatale al funzionamento del
sistema;
3. Load balancing clusters, sono sistemi che distribuiscono il carico delle richieste applicative
tra i vari server (webserver o applicationserver ), ad esempio con lintroduzione di un
sistema di code, e solitamente sono dotati di vari strumenti amministrativi che permettono
un controllo fine sullutilizzo delle risorse, la gestione dellaccounting ed il monitoraggio
del cluster;
4. Storage cluster systems, che vengono utilizzati tra i componenti della Storage Area Network 3 e i sistemi server dotati di diversi sistemi operativi. Il loro scopo consiste nel fornire
un accesso condiviso ai blocchi di dati di un sistema di storage;
5. Database cluster systems, che inserisce molte delle caratteristiche del cluster file system a
livello applicativo (ad esempio Oracle Real Application Clusters (RAC) permette ai diversi
nodi che eseguono simultaneamente il software Oracle RDBMS, di accedere ad un singolo
database).
Come già accennato, la distinzione tra le varie tipologie applicative dei cluster non è rigida, anzi, molto spesso, un sistema cluster fornisce, contemporaneamente, pi`
u di un servizio applicativo.
Per quanto riguarda i cluster file system è utile introdurre la seguente terminologia:
1. Il termine distribuited file system indica una generica definizione di file system di rete o
client/server. In questo scenario, a differenza dei file system locali, i dati non sono locali
allhost system. In questa categoria rientrano i già citati NFS e CIFS ; vi è tuttavia da
notare il fatto che la relazione tra i vari client ed il server è di cardinalità N:1, per cui, in
questa configurazione, il server NFS rappresenta un singolo point of failure;
2. Global file system è un termine che si riferisce allo spazio dei nomi (namespace): ogni file
ha lo stesso nome e risulta raggiungibile attraverso lo stesso percorso da tutti i nodi. Il
World Wide Web (WWW) è un ottimo esempio di utilizzo di un global namespace: ogni
risorsa (pagina web, immagine, file audio, ecc.) è referenziata univocamente, a livello
mondiale, attraverso un URL (Uniform Resource Locator );
3. Con il termine SAN file system viene indicato un file system capace interagire con dispositivi di memorizzazione di massa attraverso una Storage Area Network (SAN): un
file system di questo tipo monta nativamente lo storage su di un nodo e distribuisce
gli indirizzi dei vari blocchi agli altri nodi del cluster, connettendo tutti i nodi a quello
storage. In figura 1.2 viene visualizzato uno schema comparativo tra le tecnologie DAS
(Direct Access Storage), NAS (Network Access Storage) e SAN (Storage Area Network ).
Alcuni SAN file system pi`
u popolari, ad oggi, sono GPFS (General Parallel File System)
di IBM o GFS (Global File System) di Red Hat;
4. Il termine symmetric file system è utilizzato per indicare un file system nel quale i metadati
sono distribuiti tra i vari nodi client. Il codice per la gestione dei metadati rappresenta un
punto critico per le performance complessive di un file system di questo tipo, in quanto
introduce un ulteriore overhead sui nodi client. Questa metodologia è seguita dai file
system GFS e GPFS citati precedentemente;
3
La Storage Area Network (SAN) è una rete ad alta velocit`

a (Gigabit/s) il cui scopo principale è il trasferimento
di dati tra sistemi di computer ed elementi di storage, e tra elementi di storage. Una rete SAN consiste di
uninfrastruttura di comunicazione (Fibre channel e iSCSI ) che fornisce connessioni fisiche, e un livello di gestione
che organizza connessioni, elementi di storage e sistemi di computer in modo da garantire un trasferimento di
dati sicuro e robusto.
DAS
NAS
SAN
Application
software
Application
software
Application
software
Network
File System
File System
File System
FC/GbE
Storage
Storage
Storage
Figura 1.2: Confronto tra DAS (Direct Access Storage), NAS (Network Access Storage) e SAN
(Storage Area Network ).
5. Al contrario, con asymmetric file system viene indicato un file system che presenta uno
o pi`
u metadata server dedicati, che gestiscono gli elementi strutturali del file system
e la struttura del disco associata ad esso. Alcuni file system che incorporano questa
caratteristica sono Lustre o NFS e CIFS ;
Come gi`
a accennato in precedenza, i cluster file system possono essere utilizzati in combinazione con una Storage Area Network . Una SAN permette il raggruppamento delle risorse di
storage, ma non definisce le regole tramite le quali i server possono accedere a queste risorse:
ciascun file system accede ad un sottoinsieme dello storage. Invece, lutilizzo combinato di un
cluster file system ed una SAN effettua un raggruppamento delle risorse di storage e delle applicazioni di I/O in maniera tale da permettere a qualsiasi server di accedere a qualsiasi dato
presente nellintero ambiente storage [5].
Una specializzazione dei cluster file system, appositamente ideata per supportare applicazioni parallele (come le applicazioni scientifiche basate sul linguaggio MPI ) è data dai parallel file
system. Utilizzando un parallel file system, tutti i nodi del cluster possono accedere agli stessi
file nello stesso istante di tempo, attraverso richieste read() e write() concorrenti. Questa
tipologia di file system è stata progettata per fornire alti rate di I/O al verificarsi di un accesso
simultaneo da parte di molti processi (parallel I/O).
Larchitettura dei parallel file system è generalmente suddivisa in 2 strati: lo strato client e
lo strato server. Lato client, il parallel file system si occupa di generare un namespace globale
distribuito su tutti i nodi e di creare una singola vista del file system. Siccome esso genera
un unico grande file system, lo strato client consente ai nodi di effettuare le richieste di I/O
che sono eseguite dallo strato server. Lo strato server di un parallel file system, quindi, è
responsabile di tutte le operazioni di I/O, e può estendersi anche a molti client in cluster molto
grandi. Dal punto di vista dello storage, lo strato server è identico, a livello funzionale, allo
strato di storage. Questo poiche ogni parallel file system è progettato in maniera tale che ogni
singolo server fisico si prenda carico delle proprie risorse di storage. A differenza dei cluster file
system, comunque, in un parallel file system lo storage non è direttamente condiviso dagli altri
server. Per questo motivo, un parallel file system non necessita di una SAN per lo storage.
Come già accennato per i cluster file system, un parallel file system fa uso di diversi daemon
tra i nodi, metadati e meccanismi di controllo, per assicurare che i dati memorizzati siano
accessibili da un singolo client alla volta, garantendo in questo modo la coerenza dei dati.
Mentre alcuni parallel file system fanno uso di un gestore di lock centralizzato e di vari server
per i metadati, per gestire il controllo del traffico delle varie richieste, altre implementazioni
utilizzano approcci non gerarchici o una gestione segmentata dei lock, per raggiungere una
scalabilità molto elevata. Il risultato consiste in architetture di file system ottimizzate per
enormi volumi di traffico tra i vari nodi.
Daltro canto, molti parallel file system risultano inefficienti nella gestione di I/O random,
tipici di ambienti come i database [5]. Alcuni esempi di parallel file system, di cui si discuter`
a
in seguito, sono General Parallel File System (GPFS) di IBM, Lustre e PVFS2.
I cluster file system risultano ben progettati per installazioni in ambienti enterprise, con
relativamente pochi nodi. A causa della loro integrazione con le strutture SAN e la loro estrema
focalizzazione circa lalta disponibilit`
a ed il recupero immediato dei dati, un cluster file system
risulta molto adatto in ambienti con database distribuiti o server applicativi allinterno di uno
storage in rete. Inoltre, i cluster file system in ambienti enterprise vengono utilizzati sempre pi`
u
in accoppiamento con protocolli NAS (NFS, CIFS) per creare ambienti NAS scalabili basati su
SAN. In definitiva, i cluster file system dovrebbero essere tenuti in considerazione quando sono
assolutamente necessari requisiti quali lalta disponibilità ed il recupero dei dati per applicazioni
particolarmente critiche.
I parallel file system continuano a dominare nel settore dellHigh Performance Computing.
Questo perche non richiedono lintegrazione con una SAN e sono ottimizzati per I/O altamente
parallelo. Inoltre, questa categoria di file system risulta sempre pi`
u diffusa tra le offerte di
NAS scalabile. Tipicamente, queste offerte si basano sullarchitettura dei parallel file system
per realizzare cluster plugandplay, dove ogni nodo, non appena viene aggiunto, agisce come una singola entit`
a atomica, contribuendo ad aumentare la potenza di calcolo e lo storage
allintero sistema. Alcune di queste offerte permettono di raggiungere dimensioni teoriche del
file system dellordine di 100 TB e mostrano impressionanti velocità di flussi di dati. Pertanto,
soluzioni basate sui parallel file system dovrebbero essere utilizzate quando i requisiti obbligatori
riguardano le performance dei client ed un elevato I/O parallelo [5].
1.2.2
Motivazioni
Molto spesso la capacit`

a di memorizzazione richiesta da un cluster HPC supera di gran
lunga quella che pu`
o essere gestita da un singolo server. Questo introduce il problema di gestire
molti (anche centinaia) di server per la memorizzazione dei dati. Molte installazioni usano
ancora diversi server NFS, delegando la gestione agli utenti e gli amministratori del cluster,
e non al software (file system). Il tempo impiegato nelle operazioni di I/O spesso degrada
significativamente le prestazioni globali di un cluster.
In figura 1.3 viene visualizzato il tipico flusso temporale di eventi di sottomissione ed
esecuzione di un job su un cluster parallelo.
Figura 1.3: Sottomissione ed esecuzione di un job sul cluster: flusso temporale di eventi.
Il modello pi`
u comune di inputoutput consiste in unazione di I/O collettiva da parte di
tutti i nodi che eseguono il job; questo comportamento si ha, ad esempio, quando un unico file
viene utilizzato dallintero job. Il secondo pattern pi`
u comune consiste in un singolo nodo che
legge e scrive i dati. Larchitettura del cluster terrà in conto della totale larghezza di banda
disponibile, che, a seguito di una corretta configurazione, risulterà essere pari alla somma della
larghezza di banda di tutti i server. Inoltre, la bandwidth disponibile ad un singolo nodo non è
generalmente limitata da quella dei server, ma da quella della rete di interconnessione e del file
system.
Una situazione estremamente comune consiste nella necessità di un continuo incremento
della capacit`
a dello storage di un cluster, successivamente alla sua messa in opera. Le varie
soluzioni per lo storage, quindi, devonono consentire questo aumento, attraverso laggiunta di
server ed il resizing del file system, che non dovrebbe introdurre limitazioni sulla dimensione
massima di un file o del file system stesso.
Inoltre, molte soluzioni per lo storage funzionano bene con un basso numero di client, ma
poche risultano performanti allaumentare di questo numero. Le problematiche tipiche in questo
contesto consistono nel garantire delle performance stabili quando molti client creano dei file
nella stessa directory, e la capacit`
a del file system di gestire una moltitudine di operazioni di I/O
o richieste di metadati, che possono essere avviate simultaneamente da tutti i client. Quindi, la
scalabilità rappresenta uno dei principali motivi di scelta di un determinato file system.
Un cluster file system dovrebbe gestire, in maniera completamente trasparente ai client,
gli eventuali reboot dei server o malfunzionamenti degli stessi, mediante un meccanismo ad
alta disponibilit`
a, come, ad esempio, il failover 4 . Lassenza di un failover robusto può, infatti,
portare al blocco o la terminazione dei job, o alla necessità di reboot del cluster, entrambe
situazioni estremamente gravi per la gestione di un cluster.
Unultima caratteristica gradita in un cluster file system consiste nellinteroperabilità tra le
diverse versioni software, che permetterebbe di effettuare gli upgrade del cluster file system su
cluster attivi [3].
4
Il failover è una tecnica utilizzata per assicurare il massimo della disponibilit`
a su rete a seguito di un cedimento
di una componente dellhardware.
10
Capitolo 2. Cluster file system: le soluzioni disponibili
Capitolo 2
Cluster file system: le soluzioni

disponibili
In questo capitolo ci soffermeremo sui principali cluster file system e parallel file system
attualmente disponibili sul mercato, esaminandone larchitettura e le caratteristiche salienti e
valutando pregi e difetti di ciascuno.
I candidati scelti per la nostra analisi sono GPFS di IBM, Lustre di Sun Microsystems,
GFS di Red Hat, HDFS (Hadoop), Gluster e PVFS2.
2.1
IBM GPFS
Il General Parallel File System (GPFS) di IBM è un parallel file system dedicato ai sistemi di
High Performance Computing e permette laccesso ad alta velocità ad applicazioni che operano
su pi`
u nodi di un cluster Linux o AIX. Tra gli ambiti duso, vi sono lengineering, il digital media,
il data mining, lanalisi finanziaria, lelaborazione di dati sismici e la ricerca scientifica. GPFS
è un parallel file system proprietario progettato ed ottimizzato specificamente per funzionare
su cluster di Storage Server IBM ; la filosofia di fondo è stata quella di realizzare un parallel
file system quanto pi`
u possibile affidabile e performante, al prezzo di costi di messa in opera
` un parallel file system dalle prestazioni elevate e con dischi condivisi per
piuttosto elevati. E
cluster AIX 5L e Linux, in grado di gestire fino a 4096 dischi da massimo 1 TB ciascuno, per
un totale di 4 PB di file system. GPFS, inoltre, implementa la gestione interna del file system
a 64 bit, consentendo una dimensione massima per un file pari a 263 1 byte [9].
Architettura e caratteristiche
Questo file system si compone di un insieme di dischi, che contengono i dati del file system,
un insieme di nodi, che usano e gestiscono il file system, ed un insieme di interconnessioni di
rete, che consentono la comunicazione tra i nodi e lo storage (Fig. 2.1). GPFS consente a tutti
i nodi di calcolo, che montano il file system, di avere una visione coerente di tutto lo storage,
ed un accesso concorrente ad esso [2].
2.1. IBM GPFS
11
GPFS File System
Switching fabric
Shared disks
Figura 2.1: Architettura di GPFS: ambiente shared disk.

Alcune delle caratteristiche di GPFS sono elencate di seguito [10]:
standard POSIX 1 , supporto alle quote ed alle Access Control List (ACL);
ridimensionamento dinamico dei volumi;
prestazioni elevate: parallelizzazione degli accessi e bilanciamento del carico;
alta affidabilit`
a per la conservazione dei dati tramite repliche di dati e metadati;
alta disponibilit`
a per laccesso ai dati grazie a server secondari di volumi che possono
subentrare in failover ;
esportabilit`
a dei volumi via NFS (v3/v4) e Samba.
Unaltra interessante caratteristica di GPFS consiste nella possibilità di esportare i volumi
di un cluster a client di altri cluster (inter-cluster export Fig. 2.2).
Su sistemi Linux GPFS pu`
o operare in due modalità distinte [2]:
1. SAN DirectAttached Disk
2. Network Shared Disk (NSD)
Nella configurazione pi`
u semplice, tutti i nodi sono connessi direttamente allo storage tramite
una Storage Area Network (questo tipicamente richiede che tutti i nodi siano provvisti di una
scheda fiber channel ) e tra di loro attraverso una rete privata (LAN) (Fig. 2.3). In questa
modalità ciascun nodo funge da Metadata Server per se stesso, e le comunicazioni fra i client
e i nodi avvengono tramite TCP/IP. I dati utilizzati dalle applicazioni sono trasmessi tramite
la SAN, mentre le informazioni di controllo tra le istanze di GPFS sono trasferite tramite la
LAN [2].
1
Lo standard POSIX (Portable Operating System Interface) deriva da un progetto iniziato nel 1985 dallIEEE
(Institute of Electrical and Electronic Engineers). Formalmente noto come IEEE-IX, il termine è stato coniato
da Richard Stallman e si riferisce ad una famiglia di standard che definiscono le API (Application programming
interface) per i software sviluppati per le diverse varianti dei sistemi operativi UNIX.
12
Figura 2.2: GPFS: configurazione multicluster.
IP Network
Application
Application
Application
Application
Application
Application
GPFS
GPFS
GPFS
GPFS
GPFS
GPFS
FC Interface
FC Interface
FC Interface
FC Interface
FC Interface
FC Interface
GPFS
Nodes
SAN (with/without switch)
Disk
Subsystem
Figura 2.3: Modalit`

a SAN DirectAttached Disk di GPFS.
2.1. IBM GPFS
13
Nella seconda modalit`

a solo un sottoinsieme dei nodi è collegato direttamente allo storage:
tali nodi prendono appunto il nome di NSD Network Shared Disk (Fig. 2.4). In questo genere
di configurazione i nodi NDS forniscono un punto di accesso allo storage tramite TCP/IP su
Ethernet o Myrinet ed, inoltre, svolgono a tutti gli effetti il ruolo di metadata server. Un client
che voglia effettuare unoperazione di I/O contatterà un NSD primario, oppure il secondario nel
caso in cui il primo non sia disponibile, ed invierà la richiesta; sarà poi compito del NSD eseguire
loperazione di I/O per conto del client e restituire al client stesso un messaggio di conferma di
avvenuta operazione [6].
Application
Application
Application
Application
Application
Application
GPFS
GPFS
GPFS
GPFS
GPFS
GPFS
NSD
NSD
NSD
NSD
NSD
NSD
GPFS
Compute
Nodes
Interconnect
NSD
Disk Interface
GPFS
IO Nodes
NSD
Disk Interface
Disk
Subsystem
Figura 2.4: Modalit`

a Network Shared Disk (NSD) di GPFS.
In questa configurazione, solo un sottoinsieme di nodi del cluster ricopre il ruolo di I/O
server, solo quelli direttamente connessi allo storage: ogni I/O server è connesso ad una porzione dello storage (Fig. 2.5). Inoltre, il fatto che le operazioni di I/O avvengano in remoto è
del tutto trasparente alle applicazioni che effettuano le chiamate di sistema al file system. In
questa modalit`
a, sia i dati, sia le informazioni di controllo sono traferite tramite la rete privata di interconnessione dei nodi (LAN). Naturalmente, tecnologie di interconnessione a pi`
u
alte performance, quali IBM HPS o InfiniBand consentono di raggiungere maggiori velocit`
a
allaumentare del carico di I/O [2].
La scelta tra le 2 diverse configurazioni riguarda sia le performance che è necessario ottenere, sia i costi che è possibile sopportare. La modalità Network Shared Disk (NSD) risulta
sicuramente pi`
u economica rispetto ad una soluzione basata su una Storage Area Network , che,
daltro canto, offre maggiori performance [2].
Le performance ottenute da GPFS sono il risultato delluso di svariate metodologie [8]:
1. la suddivisione (striping) dei dati sui vari dischi, direttamente connessi a diversi nodi
14
Figura 2.5: GPFS: I/O server.

(Fig. 2.6);
2. un meccanismo efficiente di caching lato client, attraverso luso di tecniche come il read
ahead o il writebehind ;
3. lutilizzo di dimensioni dei blocchi di dati (block size) configurabili;
4. lutilizzo di tecniche di locking, basate su una complessa gestione dei token, che fornisce la
consistenza dei dati anche in presenza di accessi multipli allo storage da parte dei diversi
nodi di calcolo.
Locking e caching
Come gi`
a accennato, GPFS utilizza un sistema di locking distribuito basato sui token [9].
Larchitettura prevede un Lock Manager centrale operante in collaborazione con Lock Manager
locali residenti sui singoli nodi. Un nodo che voglia accedere ad una data risorsa può mandare
un messaggio al Lock Manager centrale, il quale gli restituirà un token; esso garantisce al Lock
Manager locale il diritto di concedere privilegi di accesso, relativi alla risorsa in questione, ai
processi residenti su quel nodo, fino alla rimozione del token stesso da parte del Manager centrale
(Fig. 2.7). In questo modo richieste consecutive da parte di uno stesso nodo verso una data
risorsa possono essere gestite con un solo scambio di messaggi sulla rete. Se il Lock Manager
rileva un conflitto fra due richieste concorrenti da parte di nodi distinti, può procedere al ritiro
del token di uno dei due nodi coinvolti, in modo da assicurare la consistenza dei dati.
` possibile specificare il byte range al quale si è interessati, in modo da permettere laccesso
E
concorrente di pi`
u nodi a parti distinte di uno stesso file. Daltra parte se ogni nodo richiedesse
2.1. IBM GPFS
15
Figura 2.6: GPFS: accesso parallelo ai dischi (striping dei file).
Figura 2.7: GPFS: gestione dei token.
16
un token esclusivamente per il byte range al quale è interessato per la successiva operazione
di read/write e provvedesse al suo rilascio immediatamente dopo la conclusione delloperazione
si genererebbe un overhead significativo. Per questo motivo GPFS utilizza un protocollo che
cerca di minimizzare il numero di comunicazioni necessarie con il Lock Manager. In particolare
ciascun nodo, allatto di una richiesta di lock, tenterà di ottenere i diritti sullintero file, in modo
da coprire anche eventuali accessi futuri; solo se ad un istante successivo due nodi dovessero
contendersi la stessa risorsa quello dei due che aveva ottenuto in precedenza i permessi dal Lock
Manager centrale rilascer`
a la porzione di file necessaria allesecuzione della nuova richiesta.
Lutilizzo di un Lock Manager centralizzato basato sui token ha diversi vantaggi. In primo
luogo è un meccanismo relativamente scalabile, perche evita continue ritrasmissioni di richieste
di locking fra i nodi periferici ed il Lock Manager centrale. Inoltre, sebbene la concessione dei
token sia centralizzata, il locking vero e proprio viene effettuato localmente sui nodi interessati.
Infine tramite il sistema dei token è possibile realizzare un efficace meccanismo di caching locale;
il possesso di un token garantisce, infatti, che non vi siano altri client interessati allaccesso concorrente su quella risorsa, e pertanto si può provvedere al caching locale anche per le operazioni
di scrittura. Allatto del ritiro del token da parte del Lock Manager (che può avvenire perche
le operazioni su quel blocco sono terminate o per il rilevamento di un conflitto) si provveder`
a
ad aggiornare lo storage con il contenuto della cache (writeback caching). Ciò permette di
incrementare notevolmente le performance del parallel file system nelle operazioni di scrittura.
Tolleranza ai guasti
Rilevazione dei guasti
Allo scopo di rilevare eventuali condizioni di malfunzionamento, GPFS utilizza un Group
Services Layer, incaricato di effettuare il monitoraggio dei nodi e dei link di comunicazione
tramite messaggi periodici chiamati heartbeat (pulsazioni); esso inoltre implementa un protocollo
di Group Membership tra i processi. Quando il Group Service Layer si accorge dellesistenza
di un problema (perche ad esempio non riceve pi`
u lheartbeat di un particolare nodo) esso
informa i restanti nodi di una modifica nella Group Membership; questo evento fa scattare le
procedure di ripristino. I gruppi di appartenenza dei nodi giocano inoltre un ruolo fondamentale
nel ripristino del sistema in seguito a partizionamenti della rete [9].
Guasti ad un nodo
Alla caduta di un nodo, il sistema dovrà provvedere a riportare in uno stato consistente i
metadati sui quali il nodo stava operando, rilasciare le risorse assegnate in precedenza a tale
nodo (in particolare i token di locking) ed eleggere un sostituto per ogni eventuale ruolo speciale
che quel nodo ricopriva: NSD, token manager, allocation manager, . . . (Fig. 2.8).
Le operazioni di ripristino sono facilitate dai log che il nodo manteneva sullo spazio condiviso;
grazie ad essi è possibile individuare e correggere quelle operazioni che sono rimaste in sospeso in
seguito al guasto. Inoltre il sistema di locking distribuito ci assicura che nessun altro nodo possa
2.1. IBM GPFS
17
Figura 2.8: GPFS: Alta disponibilità (HA).

accedere ai metadati che si trovano in uno stato potenzialmente inconsistente; daltra parte i
token relativi al nodo guasto verranno rilasciati solo al termine delle operazioni di ripristino,
quando il sistema sar`
a pronto per entrare nuovamente a regime. Considerazioni speciali valgono
nel caso di un fallimento del Lock Manager centrale; in tal caso il nodo che verrà designato
come nuovo Lock Manager dovr`
a provvedere ad interrogare tutti i nodi superstiti circa i token
in loro possesso. Durante questa fase tutte le richieste di nuovi token verranno ovviamente
scartate, poiche il Manager non è in grado di stabilire correttamente lesistenza di eventuali
conflitti. In maniera analoga esistono specifici protocolli di fencing e di ricostruzione tramite
query per il ripristino degli altri ruoli speciali previsti per i nodi di GPFS [9].
Guasti ad un link di comunicazione

Dal punto di vista del Group Service Layer non cè modo di distinguere un problema di
comunicazione su rete da un vero e proprio guasto ad un nodo. Daltra parte, problemi ad un
cavo o ad uno switch potrebbero isolare alcuni nodi o addirittura partizionare la rete in due o
pi`
u zone. Scenari di questo tipo sono pericolosi perche ciascuna delle due partizioni potrebbe
pensare di essere lunica parte superstite di un guasto e tentare di procedere con le operazioni
di ripristino sopra indicate in maniera indipendente luna dallaltra, con conseguenze disastrose
per la coerenza del sistema. Per questo motivo si decide di permettere laccesso al file system
solo alla partizione che contiene la maggioranza dei nodi del cluster; i nodi della partizione di
minoranza dovranno attendere di riunirsi alla partizione dominante prima di poter accedere
nuovamente al file system. Poiche, daltra parte, non ci sono garanzie sul tempo necessario al
protocollo di Group Membership per notificare ai nodi di minoranza la loro esclusione, GPFS
prevede la separazione (fencing) di tali nodi mediante linvocazione di apposite primitive che
18
vietano laccesso ai dischi condivisi a quei nodi esclusi dal gruppo dominante [9].
Guasti ad un disco
In sistemi composti da svariate centinaia di dischi per lo storage, la possibilità che uno di
essi subisca un guasto diventa decisamente non trascurabile; si rendono pertanto necessari meccanismi che evitino conseguenze disastrose per il file system. A tal scopo, è possibile utilizzare
controller RAID che provvedano autonomamente alla replicazione e al ripristino dei dati. Dato
il costo sempre pi`
u contenuto di queste tecnologie, la soluzione con controller RAID sta diventando oggi di gran lunga la pi`
u diffusa. In passato, tuttavia, si sono sviluppate strade alternative
che includessero le funzionalit`
a del RAID allinterno del file system stesso, quali il sistema di
`
replicazione di GPFS. E infatti possibile configurare il file system in modo che ciascun dato e/o
metadato venga replicato automaticamente su due o pi`
u dischi distinti. Alloccorrenza di un
guasto sarà il sistema stesso ad occuparsi del reindirizzamento delle richieste di accesso ad una
risorsa verso il disco di backup, cos` come del ripristino della coerenza fra le due copie, allatto
delleventuale riparazione del disco malfunzionante. Il prezzo da pagare per la realizzazione di
questi meccanismi tramite il file system stesso è una perdita in termini di prestazioni dovuta al
maggiore carico necessario alla duplicazione dei dati [9].
Vantaggi e svantaggi
In definitiva, GPFS si presenta come uninteressante soluzione per cluster con relativamente
pochi nodi [10]:
buone prestazioni, che migliorano grazie alla parallelizzazione che può fornire con semplicità anche il bilanciamento di carico;
ottime caratteristiche di affidabilità, che si sfruttano al meglio in una infrastruttura SAN;
POSIX I/O: pu`
o essere utilizzato dalle applicazioni senza adattamenti;
scalabile: supportato da IBM fino a 1.024 nodi, ma esistono già in produzione installazioni
di oltre 2.000 nodi;
funzionalit`
a come la duplicazione di dati e metadati, supporto per le ACL e le quote ne
fanno una soluzione interessante anche per file system general purpose (home directory);
sono disponibili in rete unampia documentazione e le FAQ (esiste anche una mailing list
abbastanza attiva del San Diego Super Computing);
Tra gli svantaggi:
la sua natura di software proprietario non permette in alcun modo la personalizzazione,
lo studio o lottimizzazione del codice;
2.2. LUSTRE
19
IBM fornisce contratti di supporto sotto condizioni stringenti [10];

messa in opera del file system non molto semplice;
il costo (anche se il software viene fornito gratuitamente attraverso il programma IBM
University).
2.2
LUSTRE
Lustre è un cluster file system scalabile, sicuro, robusto e ad alta disponibilità. Lobiettivo
principale consiste nello sviluppo di una nuova generazione di cluster file system in grado di
operare su cluster con decine di centinaia di nodi, gestire petabyte di storage e permettere lo
spostamento di centinaia di GB di dati al secondo, attraverso uninfrastruttura di gestione e
sicurezza allavanguardia [11].
` un progetto originariamente sviluppato da Cluster File System Inc. (dal 2 Ottobre 2007
E
parte di Sun MicroSystems) ed è considerato uno dei prodotti pi`
u promettenti nel campo dei
cluster file system; il nome deriva dalla fusione delle parole Linux e Cluster. Lustre è una
soluzione completa interamente realizzata via software rilasciato sotto i termini della GNU
General Public License (GPL) ed è POSIX compliant. Attualmente, il file system Lustre viene
utilizzato dai computer pi`
u potenti al mondo: il 50% dei cluster nella lista TOP30 e il 15% nella
TOP500 [13].
Il file system Lustre si compone di 3 unità fondamentali (Fig. 2.9), le cui caratteristiche sono
riassunte nella tabella 2.1 [14]:
i Metadata Server (MDS), che gestiscono i metadati del file system;
gli Object Storage Server (OSS), che forniscono il servizio di I/O;
i client del file system, che accedono ed utilizzano i dati.
Un singolo MetaData Target (MDT) per file system si occupa della memorizzazione dei
metadati, quali i nomi dei file, le directory, la loro creazione e cancellazione, la manipolazione
degli attributi e la gestione del global namespace, sul MetaData Server (MDS) [12].
Le operazioni di I/O vere e proprie, invece, sono demandate ad uno o pi`
u Object Storage
Target (OST) che memorizzano i dati su uno o pi`
u Object Storage Server (OSS). A seconda
della dotazione hardware, un OSS tipicamente riesce a servire da 2 a 25 OST, ed ogni target
fino a 8 TB di dimensione. La capacità totale del file system risulta la somma delle capacit`
a
servite dagli OST [14].
Gli OST, a loro volta, si interfacciano agli Object-Based Disk (OBD) tramite appositi driver.
In realtà, Lustre è in grado di simulare le funzionalità di un OBD a partire da dischi tradizionali a
blocchi: in particolare, esso è attualmente in grado di operare sulla maggior parte dei file system
20
MDSdisk storage containing

Metadata Targets (MDT)
OSSservers
1-1000s
Pool of clustered MDSservers

1-100
MDS1
(active)
OSS1
MDS2
(standby)
CommodityStorage
Elan
Myrinet
InfiniBand
OSS2
Simultaneous
support of multiple
networktypes
Lustre clients
1-100,000
OSSstorage with object

storage targets (OST)
OSS3
Router
Shared storage
enables failover OSS
OSS4
OSS5
GigE
OSS6
=Failover
OSS7
Enterprise-Class
Storage Arrays and
SAN Fabric
Figura 2.9: Architettura di LUSTRE.
Numero tipico
di sistemi
Performance
Richiede dispositivi di storage
Caratteristiche
hardware
desiderate
Client
1100.000
1 GB/s di I/O,
1.000 operazioni al
secondo sui metadati
No
Nessuna
OSS
11.000
5002.5 GB/s
Dimensione totale
del file system/ numero di OSS
Una buona
larghezza di banda
del bus di
comunicazione
MDS
2 (in futuro 2100)
3.00015.000 operazioni al secondo

sui metadati
12% della dimensione totale del file

system
Unadeguata
potenza di CPU
(raccomandati
almeno 4 core) e
RAM in
abbondanza
Tabella 2.1: Caratteristiche delle 3 unità fondamentali di Lustre.
2.2. LUSTRE
21
Linux che supportano il journaling, quali ext3, ReiserFS e JFS (Fig. 2.10). Esistono ovviamente
anche driver specifici per lutilizzo di OBD proprietari di terze parti.
locking
OSC
OSC
caching
1
MDS
2
1 open
2 create
striping
Metadata
OSS
OSS
OSS
stripe
OST
3 IO
OSC: Object Storage Client
MDS: Metadata Server
OSS: Object Storage Server

OST: Object Storage Target
Figura 2.10: Componenti di LUSTRE.

Per realizzare lo scambio di messaggi fra i diversi componenti dellarchitettura, Lustre utilizza una vatiante del Portals networking layer, originariamente sviluppato al Sandia National
Laboratory.
Per quanto riguarda le reti di interconnessione dei nodi, Lustre ne supporta di diverse,
incluse il TCP/IP su Ethernet, InfiniBand, Myrinet, Quadrics ed altre tecnologie proprietarie,
consentendo anche il routing tra di esse. Inoltre, Lustre può far uso del Remote Direct Memory
Access (RDMA), quando disponibile, per migliorare il throughput e ridurre luso della CPU [14].
I client Lustre comunicano con i MDS e gli OSS e forniscono un accesso standard al file
system (POSIX), consentendo accessi concorrenti in lettura e scrittura. La struttura tipica di
un client Lustre è visibile in figura 2.11.
User Space
Application
LLITE
LOV
OSC
NAL
Figura 2.11: Moduli di un client Lustre.

Le applicazioni in esecuzione su di un nodo vedono, quindi, un file system che supporta le
22
semantiche POSIX per leggere e scrivere i file. Una volta effettuata una system call del kernel,
questultimo passa il controllo al livello llite. Questo livello traduce le chiamate al Virtual
File System (VFS) in comandi per il resto del sistema e comunica direttamente con i moduli
MetaData Client (MDC) ed il Logical Object Volume (LOV). Il livello LOV è responsabile
dellinvio delle richieste dati al set di Object Storage Clients (OSC) che risultano disponibili;
questo effettua il lavoro basandosi sulle informazioni di striping ottenute dal MetaData Server
(MSD). Il livello OSC raggruppa le richieste e le invia al nodo OSS, che si occupa di gestire
lObject Storage Target (OST) specificato, attraverso il livello di comunicazione Portals Network
Abstraction Layer (NAL).
Gli Object Storage Servers (OSS) gestiscono, quindi, un insieme di OST (Fig. 2.12). Questi
target fanno direttamente riferimento al file system fisico sottostante. Il livello OST riceve le
richieste dal NAL e le passa al filtro OBD; questultimo ha il compito di astrarre il file system
sottostante (ad es. ext3) in modo da esser visto allesterno come un Object Based Disk [15].
NAL
OST
OBDfilter
The PC accesses the input
ext3
Figura 2.12: Moduli di un OSS Lustre.

La peculiarit`
a di Lustre è la sua visione a oggetti del file system, in contrapposizione alla
tradizionale visione a blocchi. Infatti, directory e file sono visti come oggetti dotati di un
certo numero di attributi (quali il tipo di file, il proprietario, i permessi, ma anche le propriet`
a
di striping). I file system UNIX tradizionali usano strutture chiamate inode, che contengono
una lista di blocchi dove sono memorizzati i dati del file a cui punta linode. In maniera simile,
per ogni file del file system Lustre esiste un corrispondente inode sul MTD, ma non punta a
blocchi di dati, ma ad uno o pi`
u oggetti associati ai file (Fig. 2.13). Questa visione di alto livello
garantisce una notevole flessibilit`
a: diventa ad esempio possibile specificare per ciascun file non
solo il numero di nodi sul quale esso verrà distribuito, ma anche il livello di ridondanza richiesto.
Scalabilit`
a
La scalabilit`
a del file system Lustre riduce la necessità di impiegare diversi file system separati, come uno per ogni cluster o, nel caso peggiore, uno per ogni server NFS. Questo porta
a numerosi vantaggi e, ad esempio, evita di mantenere copie multiple dei dati su differenti file
system. Effettivamente, i maggiori centri di dati HPC richiedono molto meno spazio di storage aggregato, utilizzando Lustre come cluster file system, rispetto ad altre soluzioni. Inoltre, il
2.2. LUSTRE
23
File on MDT
Extended
Attributes
Ordinaryext3File
obj1
oss1
obj2
oss2
obj3
oss3
Direct
Data Blocks
Data
Block
ptrs
Indirect
inode
Double
Indirect
inode
Indirect
Data Blocks
Figura 2.13: Visione a oggetti dei file in Lustre.

throughput di I/O o la capacit`
a del file system può essere modificata semplicemente aggiungendo
nuovi server, anche in maniera dinamica dopo linstallazine del cluster [14].
Locking e caching
Lustre punta a mantenere una stretta semantica della coerenza attraverso un rigido sistema di locking distribuito. La gestione dei lock è demandata allMDS interessato nel caso di
operazioni sui metadati, e allOST che ospita loggetto richiesto nel caso di operazioni di I/O.
Esistono diversi tipi di lock, corrispondenti a diversi livelli di limitazioni imposte agli altri processi interessati allaccesso concorrente a quella risorsa; in particolare si va dal pi`
u stringente
Exclusive Lock (EX), che vieta laccesso in lettura e scrittura a tutti gli altri processi, al pi`
u
blando Null Lock (NL), che implica solo un generico interesse verso quella risorsa e non pone
vincoli.
Se un client cerca di accedere ad una risorsa in una modalità non compatibile con lo stato
di locking corrente della stessa, il sistema provvede a creare una struttura di lock request e a
metterla in coda per il possesso della risorsa.
Per quanto riguarda il caching, attualmente esso presenta funzionalità limitate; sia per i
MDS che per gli OST è infatti prevista solo una cache di tipo write-through. Viene adottata
una rigida semantica della coerenza, ed il contenuto della cache viene invalidato al momento
` tuttavia in fase di sviluppo per le prossime release
del rilascio del lock sulla risorsa in uso. E
una cache write-behind sia per i dati che per i metadati; ciò permetterebbe di incrementare
notevolmente le performance del sistema nelle operazioni di scrittura. Si sta inoltre lavorando
ad un sistema di Collaborative Caching nel quale il caching di dati richiesti da un gran numero
di client venga distribuito su pi`
u nodi, in modo da alleviare il traffico diretto verso lOST che
24
ospita i dati in questione. Una tipica situazione in cui questa tecnica potrebbe fare la differenza
è quella in cui pi`
u nodi vengano riavviati contemporaneamente in seguito ad una manutenzione;
essi tenterebbero di accedere concorrentemente allOST sul quale risiedono i binari necessari al reboot, creando un affollamento che potrebbe essere evitato se i client potessero essere
reindirizzati verso altri nodi che hanno già effettuato il caching di quei dati.
Rilevazione dei guasti
Come tutti i file system che memorizzano lo stato del sistema (in particolare sul MDS e sugli
OST) Lustre adotta specifici protocolli di recovery, necessari ad evitare che operazioni rimaste
in sospeso a causa di guasti possano lasciare il sistema in uno stato inconsistente; ad esempio
potrebbe accadere che durante la cancellazione di un file il MDS provveda con successo alla
rimozione del relativo inode ma che lOST subisca un guasto prima di eliminare i dati ad esso
relativi.
Allo scopo di individuare simili inconsistenze e facilitare le operazioni di ripristino, Lustre
utilizza alcuni parametri, che, unitamente al sistema di journaling fornito dal filesystem locale
sottostante, permettono di rilevare e rimuovere eventuali inconsistenze. Essi vengono inoltre
utilizzati per realizzare il fencing, ovvero il rifiuto di nuove richieste di operazioni verso i nodi
non disponibili durante la fase di ripristino. Le condizioni di malfunzionamento sono tipicamente
individuate mediante appositi meccanismi di timeout.
Guasti ad un nodo
Parlando dellarchitettura di Lustre si è accennato al fatto che allo stato attuale esso prevede
un unico MDS per lintero file system; per ovviare a questo possibile punto critico del sistema
è però prevista la replicazione del MDS principale in una configurazione active/failover.
In pratica un client che si accorga di un problema al MDS attivo può contattare un server LDAP e chiedergli la locazione del MDS di backup, che prenderà il posto del server
malfunzionante.
Anche per gli OST è previsto qualcosa di simile; ciascun OST può essere dotato di una sua
replica, con la sostanziale differenza che anche in condizioni di funzionamento regolare entrambi
gli OST sono attivi e servono le richieste dei client. Dunque alloccorrenza del crollo di uno degli
OST sarà necessario instradare tutto il traffico diretto verso il nodo malfunzionante sullOST
replicato; viceversa in seguito al ripristino del sistema sarà necessario suddividere ugualmente
le richieste dei client sui due OST per bilanciare il carico di lavoro (Fig. 2.14).
Guasti ad un link di comunicazione
Abbiamo accennato al fatto che eventuali malfunzionamenti vengono rilevati tramite appositi meccanismi di timeout. Poiche è in generale impossibile distinguere eventuali problemi
transitori nella rete dai veri e propri guasti ai server, è previsto sempre almeno un tentativo di
2.2. LUSTRE
25
Shared storage partitions

for OSS targets (OST)
Shared storage partition

for MDS target (MDT)
Target 1
Target 2
OSS1
OSS2
OSS1 active for target 1, standby for target 2

OSS2 active for target 2, standby for target 1
MDS1
MDS2
MDS1 active for MDT

MDS2 standby for MDT
Figura 2.14: Configurazione failover per i server OSS e MDS in Lustre.

ritrasmissione della richiesta in seguito al primo timeout. Se il tentativo di riconnessione non
dovesse andare a buon fine si provvederà allavvio delle procedure di ripristino.
Guasti ad un disco
Lustre non presenta alcun tipo di meccanismo interno specificamente progettato per la protezione da guasti ai dispositivi fisici di memorizzazione; tipicamente i cluster che adoperano
Lustre utilizzano configurazioni RAID per affrontare simili evenienze.
Funzionalit`
a aggiuntive
Oltre alle caratteristiche descritte precedentemente, Lustre presenta ulteriori funzionalità [14]:
Interoperabilit`
a : Lustre pu`
o essere eseguito su molte architetture (Intel a 32 o 64 bit e
PowerPC), ed i client/server sono interoperabili tra le diverse piattaforme. Inoltre, Lustre
fornisce interoperabilit`
a tra versioni software di release consecutive.
Access Control List (ACL) : Lustre supporta questa tecnica di sicurezza;
Quota : possono essere definite quote per utenti e gruppi;
Aggiunta di OSS : la capacit`
a di aggregazione di Lustre della bandwidth del cluster può essere
incrementata senza interrompere le operazioni, semplicemente aggiungendo nuovi OSS;
Striping controllato : la dimensione ed il numero degli stripe può essere controllato in diversi
modi;
Snapshot : è possibile creare degli snapshot dei dati utilizzando la tecnologia LVM (Logical
Volume Manager );
26
Tool di backup : la versione 1.6 di Lustre contiene due tool di backup; il primo usa la tecnica
di backup incrementale ed il secondo può effettuare il backup ed il ripristino dei dati degli
stripe di Lustre.
2.3
Red Hat GFS
Global File System (GFS) è un file system a dischi condivisi implementato per cluster Linux
e originariamente sviluppato da Sistina Software (ora acquisita da Red Hat). Esso è attualmente
disponibile con la suite Red Hat Cluster.
GFS consente la condivisione dei dati e fornisce una singola e consistente visione del namespace
del file system tra i nodi del cluster. Inoltre, come per i cluster file system precedentemente
descritti, è completamente trasparente alle applicazioni (POSIX compliant) ed implementa le
feature tipicamente richieste in ambienti enterprise, come, ad esempio, il supporto alle quote.
Questo cluster file system è rilasciato con licenza libera GNU GPL e fa uso di logging, locking
e algoritmi di recovery simili a quelli utilizzati da GPFS di IBM. Limplementazione attuale del
GFS supporta anche il journaling del file system ed il recupero rapido degli errori [20].
GFS prevede 3 tipologie di architettura:
1. client GFS direttamente connessi allo storage tramite una Storage Area Network (Fig. 2.15);
2. client che accedono ai dati tramite i server Global Network Block Device (GNBD), connessi
alla SAN (Fig. 2.16);
3. client che accedono ai dati tramite i server GNBD, sui quali sono direttamente connessi i
dispositivi di storage (Fig. 2.17).
La prima modalit`
a, nella quale le applicazioni sono in esecuzione direttamente sui nodi GFS,
è quella che offre maggiori performance ed una migliore scalabilità.
Nella seconda modalit`
a, invece, lo storage della SAN viene presentato ai client dai server
GNBD. Dal punto di vista di unapplicazione in esecuzione su di un client, si effettua un accesso
storage come se fosse direttamente connesso al server GNBD. Il cluster file system provvede alle
funzionalità di locking e condivisione per ciascun client.
Nella terza modalit`
a, i client possono avvantaggiarsi delluso di una topologia Ethernet per
guadagnare laccesso a tutti i dispositivi di storage. I dati presenti sul file system sono, infatti,
condivisi tra tutti i client GFS [16].
I nodi di un cluster GFS condividono gli stessi dispositivi di storage, accedendo a questi
ultimi a livello block anzichè a livello di file o directory. Come già accennato, la condivisione dei
dispositivi di storage pu`
o avvenire attraverso luso di collegamenti Fiber Channel, dispositivi
SCSI condivisi o i Global Network Block Devices (GNBD). Per questo motivo, GFS richiede
lutilizzo di driver per i dischi a basso livello invece che daemon tradizionali client/server che
2.3. Red Hat GFS
27
Applications
GFS
SAN
Fabric
Shared Files
Figura 2.15: GFS su Storage Area Network .
Clients
Applications
GFS
LAN
GNBD
servers
SAN
Fabric
Shared Files
Figura 2.16: GFS: server GNBD connessi alla Storage Area Network .
28

Clients
Applications
GFS
LAN
GNBD
servers
Shared Files
Disk
A
Disk
B
Disk Disk
D
C
Disk
E
Disk
F
Figura 2.17: GFS: server GNBD direttamente connessi allo storage.

lavorino a livello di file e directory. Un file system GFS appare come locale su ogni nodo e
GFS si occupa della sincronizzazione dellaccesso ai file attraverso il cluster. Un file system
implementato su device condivisi offre diversi vantaggi rispetto alla tradizionale architettura
client/server [20]:
Disponibilit`
a del file system : risulta aumentata grazie al fatto che non esiste pi`
u un unico
pointoffailure. Se uno o pi`
u host diventano indisponibili, il file system e i suoi dati sono
ancora accedibili agli host rimanenti;
Load Balancing : il carico viene distribuito tra i vari client che accedono al disco;
Pooling : la possibilit`
a di raggruppare logicamente in un unico volume i dispositivi di storage
diminusce la complessit`
a di amministrazione;
Scalabilit`
a : GFS pu`
o scalare fino a 300 client, garantendo le stesse performance di un singolo
nodo [21].
GFS, in maniera simile al file system ext3, utilizza un proprio formato per le strutture
di metadati, in maniera tale da supportare un accesso scalabile allo storage condiviso. Le
strutture dei metadati sono distribuite nei diversi dischi per incrementare laccesso parallelo ad
essi. Questo approccio, inoltre, riduce il tempo di contesa dei vari server che accedono agli stessi
metadati del file system. Inoltre, ogni nodo che effettua il mount del file system GFS possiede il
suo journal, in modo che le operazioni di journaling dei nodi possano procedere in parallelo [21].
Locking e caching
Con GFS, il server NFS viene effettivamente rimpiazzato dalla Storage Area Network e da
un accesso condiviso allo storage. Siccome tutti i server possono leggere e scrivere contempora-
2.3. Red Hat GFS
29
neamente dati e metadati del file system, GFS fa uso di uninfrastruttura di cluster membership,
locking e fencing (condivisa con il Red Hat Cluster Manager ) per coordinare laccesso condiviso
a queste strutture.
Ad esempio, prima che un nodo scriva su un file per la prima volta, GFS deve ottenere un
write lock per quel file. Se unaltro nodo (ad esempio, il nodo 2) sta leggendo o scrivendo sullo
stesso file, il lock manager deve informare il nodo 2 di rilasciare il suo lock per il file. Una volta
che il nodo 2 ha rilasciato il suo lock, il lock manager può assegnare un write lock al nodo in
attesa, in modo che questo possa iniziare le sue operazioni di scrittura.
Esistono 3 diverse architetture di locking:
1. Grand Unified Lock Manager (GULM): unarchitettura di lock client/server;
2. Distributed Lock Manager (DLM), il quale, a differenza di GULM, non richiede nessun
nodo configurato come gestore dei lock ;
3. Nolock, utilizzato solo per operazioni di un singolo nodo.
Le nuove versioni di questo cluster file system consentono di utilizzare un ditribuited lock
manager esterno, ma effetuano ancora il locking di singoli blocchi di dati da 4 o 8 KB. Per
questo motivo, laccesso a file di grosse dimensioni tramite GFS comporta un maggiore overhead nel locking, rispetto alla soluzione basata su intervalli di byte adottata da GPFS di
IBM.
Inoltre, come ogni file system ben progettato, GFS utilizza il journaling ed il caching dei
file per migliorare la robustezza e le performance [21].
Striping
Lo striping in GFS viene effettuato nel Network Storage Pool ; una volta creato, comunque,
lo stripe non pu`
o essere modificato (è possibile aggiungere nuovi subpools, ma lo striping resta
confinato nei subpool creati, cioè GFS non effettua lo striping tra subpools) [9].
Linfrastruttura del cluster controlla le operazioni di un nodo per assicurarsi il suo funzionamento. Se un nodo o la sua connessione di rete subisce un down in modo tale da disconnetterlo
dal resto del cluster, il membership layer ne viene a conoscenza ed inizia loperazione di fencing.
Questa operazione si occupa di isolare il nodo dallo storage condiviso e di resettarlo. Successivamente, viene recuperato il suo journal ed il nodo isolato viene ricollegato automaticamente
al cluster. Loperazione di fencing, comunque, può durare decine di secondi [21].
30
2.4
HDFS (Hadoop)
Il progetto Hadoop, supportato da Apache Software Foundation, consiste nellimplementazione di software per il calcolo distribuito, affidabile e scalabile, e si compone di [22]:
Hadoop core : il sottoprogetto pi`
u importante, che fornisce il file system distribuito Hadoop
File System (HDFS) ed il supporto per il paradigma map/reduce del calcolo distribuito;
HBase : un database distribuito e scalabile costruito su Hadoop core.
Il principale sviluppatore di Hadoop, Doug Cutting, lavora per Yahoo!, ed è proprio questultima
società che utilizza HDFS su un cluster composto da pi`
u di 10.000 core e uno storage di pi`
u
di 5 PB complessivi. Altre societ`
a che fanno uso di Hadoop sono Amazon2 , Google ed IBM,
Facebook, Last.FM, ImageShack, Wikia, solo per citarne alcune [23].
Hadoop nasce originariamente come infrastruttura per un motore di ricerca libero (Nutch),
sempre ad opera dello stesso sviluppatore. Attualmente, entrambi Hadoop e Nutch sono parte
del progetto Apache Lucene.
HDSF ha molte affinit`
a con gli esistenti file system distribuiti, anche se presenta alcune
significanti differenze. Questo file system è progettato per essere utilizzato su hardware lowcost,
è fault tolerant ed è implementato interamente in Java.
Ispirato al Google File System, HDFS fornisce un accesso ai dati ad alto throughput ed
è appropriato per applicazioni che lavorano su grandi set di dati (idealmente di dimensione
maggiore di 64 MB). Inoltre, esso riduce alcuni requisiti POSIX per permettere laccesso in
streaming ai dati del file system [22].
HDFS è composto da una serie di Data Node, ognuno dei quali fornisce blocchi di dati
attraverso la rete di interconnessione utilizzando un protocollo a blocchi, specifico del file system.
Inoltre, questo file system pu`
o fornire i dati attraverso il protocollo HTTP, consentendo, quindi,
laccesso ai dati da un browser web. I Data Node comunicano tra di loro per ribilanciare i dati,
per spostare delle copie tra di loro e mantenere unalta replicazione dei dati [24].
Come gi`
a accennato, Hadoop implementa un paradigma computazionale chiamato map/reduce, dove lapplicazione è divisa in piccole unità di lavoro, ognuna delle quali può essere eseguita
o rieseguita su qualunque nodo del cluster (Fig. 2.18).
Sia la tecnica map/reduce che il file system distribuito sono stati progettati in maniera
tale che i problemi che possono insorgere sui nodi siano gestiti direttamente dal framework in
maniera trasparente.
In maniera simile al map/reduce di Hadoop, HDFS presenta unarchitettura master/slave.
Uninstallazione HDFS consiste di un singolo nodo, il Name Node: un server principale che
gestisce lo spazio dei nomi del file system e regola laccesso ai file da parte dei client. Inoltre,
2
Amazon utilizza Hadoop per i suoi Web Services: Elastic Compute Cloud (EC2) e Simple Storage Service (S3).
Il New York Times ha utilizzato 100 istanze Amazon EC2 e unapplicazione Hadoop per processare unimmagine
TIFF da 4 TB (memorizzata in S3 ), ottenendo 1,1 milione di PDF in sole 24 ore [24].
2.4. HDFS (Hadoop)
31
Figura 2.18: Paradigma map/reduce.
sono presenti un certo numero di Data Node, uno per ogni nodo del cluster, che gestiscono lo
storage direttamente connesso al nodo dove sono in esecuzione (Fig. 2.19).
In maniera analoga ad un metadata server, il Name Node gestisce il namespace del file
system e le operazioni, come lapertura, la chiusura, la ridenominazione, ecc., di file e directory,
disponibili tramite uninterfaccia RPC3 . Inoltre, esso determina il mapping dei blocchi sui Data
Node. Questi ultimi sono responsabili delle richieste di lettura e scrittura da parte dei client del
file system, ed, inoltre, eseguono compiti come la creazione, rimozione e replicazione dei blocchi,
su comando del Name Node (Fig. 2.20).
HDFS, comunque, non è limitato a job map/reduce; questo file system, infatti, può essere
utilizzato anche per altre applicazioni come, ad esempio, database (HBase) ed operazioni su
matrici. Lunica caratteristica che le diverse applicazioni hanno in comune consiste nella modalità di lavoro batchoriented anziche interattiva, realtime, dataintensive o capace di lavorare
su porzioni di dati in parallelo [24]. Viene posta maggiore enfasi sullalto throughput di accesso
ai dati, invece di una bassa latenza.
Il calcolo richiesto da unapplicazione è molto pi`
u efficiente se eseguito vicino ai dati sul
quale opera. Questo è vero ancor di pi`
u se i dati sono di dimensione molto grande. Lassunzione
di HDFS consiste nel comprendere che spesso risulta pi`
u efficiente avvicinare il calcolo ai dati,
piuttosto che spostare i dati dove lapplicazione è in esecuzione. HDFS, quindi, prevede delle
interfacce per consentire alle applicazioni di spostarsi pi`
u vicino ai dati, minimizzando, in questo
modo, la congestione della rete ed incrementanto il throughput complessivo del sistema [25].
Tutti i protocolli di comunicazione di HDFS sono stratificati in cima allo stack TCP/IP. Un
client stabilisce una connessione verso una porta TCP (configurabile) sul Name Node, utilizzando
il protocollo ClientProtocol. I Data Node, invece, fanno uso del protocollo DatanodeProtocol per
comunicare col Name Node. Inoltre, per come è stato progettato, il Name Node non inizia mai
3
Lespressione Remote Procedure Call (RPC) o chiamata di procedura remota si riferisce allattivazione di
una procedura o funzione da parte di un programma, nel caso in cui tale funzione venga attivata su un computer
diverso da quello sul quale il programma stesso viene eseguito. In altre parole, lRPC consente a un programma
di eseguire funzioni a distanza su computer remoti (accessibili per`
o attraverso una rete).
32
C luster
NameNode
Secondary
NameNode
Client
Cluster
Data Nodes
Figura 2.19: Architettura di HDFS.
Figura 2.20: Architettura di HDFS in dettaglio.
2.4. HDFS (Hadoop)
33
nessuna chiamata di procedura remota (RPC); egli risponde solo alle richieste ricevute dai Data
Node o dai client.
Locking
Le applicazioni HDFS necessitano di un modello di accesso ai file di tipo writeonceread
many (scritto una volta sola, letto molte volte). Una volta che un file viene creato, scritto e
chiuso, non dovrebbe essere modificato. Questa assunzione semplifica i problemi di coerenza dei
dati e permette un accesso agli stessi ad alto throughput. Unapplicazione map/reduce o uno
spider web sono perfetti per questo modello. Comunque, è in fase di considerazione laggiunta
di un accesso in scrittura ai file di tipo appendingwrite [25].
Essendo progettato per essere utilizzato su hardware lowcost, uno dei principali obiettivi
di HDFS consiste nella gestione dei failure hardware, che rappresentano la norma, invece che
leccezione [25]. Un istanza di HDFS può consistere di centinaia o migliaia di macchine, ognuna
contenente una parte del file system. Il fatto che esista un numero molto grande di componenti e
considerato che ogni componente ha una probabilità non bassa di guastarsi implica che qualche
componente di HDFS sar`
a sempre non funzionante. Per questo motivo, la rilevazione di errori
ed il recupero automatico e veloce degli stessi risulta una degli obiettivi principali di HDFS [25].
Laffidabilit`
a viene raggiunta non attraverso il RAID dello storage su un singolo host, ma
attraverso la replicazione dei dati su molti nodi (Fig. 2.21) [24].
HDFS memorizza ogni file come una sequenza di blocchi: tutti blocchi in un file, eccetto
lultimo, sono della stessa dimensione. Come accennato precedentemente, laffidabilità è ottenuta replicando i blocchi di dati; quella di default (pari a 3) consente ad HDFS di cercare e
memorizzare i dati in zone separate: una replica sul nodo locale e le 2 rimanenti su un rack
remoto [24]. La dimensione dei blocchi ed il fattore di replicazione sono configurabili per ogni
file.
I 3 tipi di failure pi`
u comuni sono [25]:
il failure del Name Node;
il failure del Data Node;
il partizionamento della rete.
Ogni Data Node invia periodicamente dei messaggi di heartbeat al Name Node. Il partizionamento della rete pu`
o causare la perdita della connessione col Name Node da parte di alcuni
Data Node. Il Name Node rileva questa condizione dallassenza dei messaggi di heartbeat e
marca come fuoriuso i Data Node privi di recenti heartbeat. Ogni Data Node che viene marcato
non è pi`
u parte del file system. Questo evento può causare la diminuzione del fattore di replicazione dei blocchi di dati. Il Name Node, pertanto, individua costantemente quali blocchi di
dati necessitano di ulteriore replicazione e la effettua quando necessario.
34
Figura 2.21: Replicazione dei dati nei Data Node di HDFS.

Larchitettura di HDFS è anche compatibile con il ribilanciamento dello spazio disponibile
sullo storage. Questo potrebbe essere necessario quando lo spazio disponibile su un Data Node
si abbassa sotto una determinata soglia, oppure quando un file è richiesto da molti client; in
questultimo caso HDFS dovrebbe aumentare il numero di repliche dei blocchi di quel file in
modo da renderlo maggiormente disponibile. Questi tipi di ribilanciamento, però, non sono
ancora stati implementati [25].
Per assicurare lintegrit`
a dei dati, HDFS esegue il calcolo del checksum di tutti i blocchi
associati ai file e memorizza le informazioni in file nascosti nel namespace del file system stesso.
Limitazioni
HDFS richiede ununico Name Node, che, quindi, rappresenta un singolo pointoffailure: se
il Name Node subisce un down, il file system risulta fuoriuso. Attualmente, il restart automatico
ed il failover del Name Node verso unaltra macchina non è ancora supportato [25]. Per ridurre
limpatto in questa evenienza, alcune installazioni fanno uso di un Name Node secondario per
consentire una qualche forma di failover [24].
Unaltro limite di HDFS consiste nel non poter essere direttamente montato dal sistema
operativo esistente; lo spostamento dei dati, da e verso HDFS, spesso deve essere eseguito
prima e dopo lesecuzione di un job. Per ovviare a questo inconveniente, è stato implementato,
almeno per sistemi Unixlike, un file system in userspace (utilizzando FUSE ) [24].
2.5. GlusterFS
2.5
35
GlusterFS
GlusterFS è un cluster file system capace di scalare fino a diversi peta byte. Questo cluster
file system effettua unaggregazione dei diversi nodi di storage (chiamati bricks) su interconnessioni InfiniBand RDMA o TCP/IP ottenendo un unico grande file system di rete parallelo. Una
delle particolarit`
a di GlusterFS è che esso presenta un design modulare in userspace, senza che
le performance risultino compromesse. I nodi di storage possono essere composti da commodity hardware, come, ad esempio, server x8664 con dischi SATAII RAID ed interconnessione
InfiniBand HBA [26].
Sviluppato da una societ`
a indiana (Z Research Inc.), GlusterFS è attualmente utilizzato
da una trentina di societ`
a/organizzazioni tra cui il National Center for Supercomputing Applications (NCSA) dellUniversit`
a dellIllinois, soprattutto per lesecuzione di benchmark essendo
un progetto relativamente giovane, ma viene utilizzato anche in ambienti di High Performance
Computing o in server farm che gestiscono hosting mail e web o ancora per clustered database
con MySQL e PostgreSQL.
Alcune delle caratteristiche di GlusterFS sono elencate di seguito [26]:
Elegante progettazione : GlusterFS è facile da installare, estendibile, portabile, indipendente dal kernel, a rapido sviluppo e feature avanzate, come la replicazione automatica o
scheduler di I/O pluggabili;
Ad alte performance e scalabile : GlusterFS può scalare fino a diversi peta byte e 100
secondi di GB/s di throughput; GlusterFS può sostenere 1 GB/s per nodo di storage su
InfiniBand RDMA. Le performance subiscono un incremento semplicemente aggiungendo
altri bricks;
Tollerante ai guasti : GlusterFS ha la capacità di guarire da solo. Non esiste fsck. Lo storage è accessibile direttamente come file e directory (nello stile di NFS). Se la replicazione
viene abilitata, GlusterFS è in grado di gestire i failure hardware;
Free Software : GlusterFS è Software Libero, rilasciato con licenza GNU GPLv3. Questo
significa che pu`
o essere eseguito, copiato, distribuito o migliorato liberamente.
Larchitettura di GlusterFS, visibile nelle figure 2.22 e 2.23, si compone di:
il modulo server e client;
i transport module;
i translator ;
gli scheduler module.
tS
id
e
36
Compatibility with
MS Windows
and other Unices
Cl
ie
n
Storage Clients
Cluster of Clients (Supercomputer, Data Center)
GLFS Client
GLFS Client
Clustered
Vol Manager
GlusterFS
Client
Clustered Vol Manager
Clustered
I/O Scheduler
Clustered
Vol Manager
Clustered I/O Scheduler
GigE
GLFS Client
GLFS Client
Clustered
Vol Manager
GlusterFS
Client
Clustered Vol Manager
Clustered
I/O Scheduler
Clustered
Vol Manager
NFS / SAMBA
over TCP/IP
Storage Gateway
Storage
Gateway
Storage
Gateway
NFS/Samba
NFS/Samba
NFS/Samba
GLFS Client
GLFS Client
GLFS Client
RDMA
RDMA
InfiniBand RDMA (or) TCP/IP
Se
rve
r
Sid
e
RDMA
GlusterFS Clustered Filesystem on x86-64 platform
Storage Brick 1
Storage Brick 2
Storage Brick 3
GlusterFS
Volume
GlusterFS
Volume
GlusterFS
Volume
GLFSD4
Storage Brick
GLFSD
Volume
GlusterFS
Volume
Volume
Figura 2.22: Architettura di GlusterFS.
nt
lu
S
rF
te
l ie
C
VFS
Read Ahead
I/O Cache
GlusterFS
Unify
Client
Client
Client
TCP/IP GigE, 10GigE / InfiniBand - RDMA

GlusterFS Server
GlusterFS Server
GlusterFS Server
Server
Server
Server
POSIX
POSIX
POSIX
Ext3
Ext3
Ext3
Brick 1
Brick 2
Brick n
Figura 2.23: Architettura a strati di GlusterFS.
2.5. GlusterFS
37
Il server di storage esegue il daemon glusterfsd mentre i client possono effettuare il mount
del file system utilizzando glusterfs (questi ultimi, comunque, necessitano del supporto FUSE
nel kernel). Attualmente il server GlusterFS è stato testato su Linux, FreeBSD e OpenSolaris,
mentre i client vengono eseguiti solo su macchine Linux. La recente versione 1.3.9 di GlusterFS
consente di eseguire sia il client che il server su Mac OS X Leopard.
GlusterFS è uno dei pochi progetti che supporta differenti protocolli di comunicazione
(attraverso differenti transport module):
TCP/IP
IBverbs InfiniBand userspace verbs
IBSDP InfiniBand socket direct protocol
Una particolarit`
a di GlusterFS è che molte sue funzionalità sono implementate come translator,
da unidea derivata dal progetto GNU Hurd4 .
I translator sono un meccanismo molto potente fornito da GlusterFS per estendere le funzionalità del file system attraverso uninterfaccia ben definita. Le interfacce dei translator di
entrambi server e client sono compatibili, permettendo quindi di eseguire gli stessi translator da
entrambe le parti. I translator sono librerie binarie condivise (.so) caricate a runtime.
Le varie tipologie di translator di GlusterFS sono elencate di seguito:
performance translator, che si occupano di aspetti relativi alle performance ed implementano tecniche, quali il readahead e il writebehind ;
clustering translator, che, invece, gestiscono lo striping di file di grandi dimensioni su diversi nodi di storage e la replicazione automatica degli stessi. Un translator in particolare,
chiamato unify, si occupa di aggregare i diversi bricks fornendo una visione ed un accesso
globale a tutto lo storage. Sotto questo punto di vista, GlusterFS è differente rispetto ai
cluster file system descritti precedentemente, poiche non fa uso di nessun metadata server,
ma, attraverso unify, gestisce un unico namespace che viene modificato dinamicamente
quando, ad esempio, un server di storage subisce un down improvviso;
scheduling translator, che vengono utilizzati da unify per decidere con quale modalit`
a
distribuire i dati nellintero storage (Fig. 2.24); tra questi troviamo:
Adaptive Least Usage (ALU);
Non-uniform file system architecture (NUFA);
Random;
4
GNU Hurd sostituisce il kernel Unix, allinterno del progetto GNU della Free Software Foundation. Hurd
è un insieme di server che vengono eseguiti su un microkernel per implementare file system, protocolli di rete,
controlli di accesso ai file, e altre caratteristiche che sono implementate nei kernel UnixLike (come Linux).
`
Un translator è semplicemente un particolare server che implementa una determinata funzionalit`
a di Hurd. E
chiamato translator poiche traduce le chiamate a lui destinate, in chiamate di sistema, in maniera simile al
Virtual File System (VFS) di Linux.
38

RoundRobin;
Switch.
storage translator, che si interfacciano con i file system locali dei dischi, ad esempio ext3;
in questo modo GlusterFS pu`
o gestire diversi tipi di file system locali a patto che seguano
gli standard POSIX;
altri translator (client, server, POSIX locks, ROT13, debugging tools, ecc.); tra questi ultimi vi è bdb che fa uso di un Berkeley database per memorizzare un numero estremamente
grande di file di piccole dimensioni (molto utile, ad esempio, per un server web).
2007 Z RESEARCH
GlusterFS Client
Unified Volume
(Unify / RoundRobin scheduler)
B1A1
B1A2
B1A3
B2A1
B2A2
B2A3
AFR
AFR
AFR
AFR
AFR
AFR
B1D1V1+B2D1V1
B1D2V1+B2D2V1
B1D3V1+B2D3V1
B2D1V2+B1D1V2
B2D2V2+B1D2V2
B2D3V2+B1D3V2
GlusterFS Server
Brick 1
B1D1V1
POSIX
B1D2V1 B1D3V1
POSIX
POSIX
B1D1V2 B1D2V2 B1D3V2

POSIX
POSIX
POSIX
GlusterFS Server
Brick 2
B2D1V1
POSIX
B2D2V1 B2D3V1
POSIX
POSIX
B2D1V2 B2D2V2 B2D3V2

POSIX
POSIX
POSIX
B1D1V1 Brick 1 Disk 1 Volume 1

B1A1 Brick 1 AFR 1
AFR Automatic File Replication
Figura 2.24: Layout del volume GlusterFS.

Una delle funzionalit`
a future di GlusterFS (versione 1.4) permetterà anche di aggiungere
e rimuovere i nodi di storage dinamicamente (a runtime), attraverso uninterfaccia web (è in
sviluppo un modulo per il server web Apache).
2.6. PVFS2
2.6
39
PVFS2
In questa sezione ci soffermeremo sullanalisi di Parallel Virtual File System v2 (PVFS2),

frutto di una collaborazione tra la Clemson University e lArgonne National Laboratory.
Una caratteristica fondamentale di questo parallel file system opensource consiste nella
totale assenza di meccanismi di ridondanza dei dati o di protezione dai guasti; PVFS2 è stato
infatti progettato con lobiettivo dichiarato di massimizzare le prestazioni in operazioni di I/O
parallelo, a scapito di altri aspetti, quali una semantica pi`
u rigida o una maggiore affidabilità.
Dal punto di vista architetturale PVFS2 non si differenzia molto dagli altri file system
paralleli finora esaminati. Anche in questo caso abbiamo una separazione sul piano logico
fra Data Server e MetaData Server ; essi sono entrambi implementati mediante il processo
Unix pvfs2-server, che si specializza in una delle due diverse funzioni in base ad appositi file di
` altres` possibile configurare un nodo affinche esso svolga contemporaneamente
configurazione. E
entrambi i ruoli. In ogni caso è attualmente possibile configurare pi`
u MetaData Server allo scopo
di permettere una distribuzione del carico di lavoro relativo ai metadati.
Lato client, invece, esiste un processo utente chiamato pvfs2-client il cui compito è quello
di tradurre i comandi ricevuti dallutente in messaggi della system interface, unAPI di basso
livello che implementa le operazioni fondamentali del file system. Inoltre, un modulo del kernel
viene caricato dai client per utilizzare i comandi nativi Unix (come, ad esempio, ls, rm, mv,
cp, mkdir, ecc.) sul mountpoint PVFS2. Il metodo di accesso al file system da parte dei client
PVFS2 viene esaminato in dettaglio nel capitolo seguente (cfr. sez. 3.3.4).
Per quanto riguarda le interfacce di rete supportate, PVFS2 prevede un apposito livello di
astrazione denominato Buffered Messaging Interface (BMI), il cui compito è quello di mascherare le differenti tipologie di rete sottostanti esportando uninterfaccia omogenea. Attualmente
esistono implementazioni di BMI funzionanti su TCP/IP, InfiniBand e Myrinet.
In figura 2.25 viene visualizzata larchitettura di PVFS2.
PVFS2 supporta linterfaccia UNIX standard, sebbene alcune delle operazioni da essa previste perdano gran parte del loro significato in un ambiente distribuito. Viene invece caldamente
consigliato luso dellinterfaccia MPIIO nellimplementazione ROMIO; in effetti molte delle
caratteristiche del PVFS2 derivano proprio dalla volontà di sfruttare al massimo le potenzialità di questa interfaccia, realizzando uno stretto accoppiamento fra il file system e le funzioni
MPIIO. In particolare i principali requisiti individuati dai progettisti per realizzare questo
accoppiamento sono [31]:
il supporto ad efficienti operazioni di I/O non contigue;
una semantica della consistenza vicina al modello MPIIO;
lassenza di tecniche di caching dal lato client;
lutilizzo di riferimenti ai file indipendenti dai client.
40
Figura 2.25: Architettura di PVFS2.
Con il primo punto si vogliono rendere efficienti quelle operazioni di accesso a dati strutturati
ma non sequenziali (ad esempio blocchi di array multidimensionali) che sono piuttosto diffuse
nelle applicazioni scientifiche. Esso viene realizzato mediante lutilizzo dei datatype, speciali
costrutti di MPIIO che permettono di definire accessi strutturati in un unico messaggio di
richiesta. Ad esempio, si immagini unapplicazione che necessita di leggere la colonna di una
matrice memorizzata in un file. Per ottenere quel dato, lapplicazione dovrebbe usare un grande
numero di letture scattered di piccole dimensioni. Invece, se potesse chiedere al file system tutti
gli elementi non contigui con una singola operazione, otterrebbe sicuramente una maggiore
efficienza (Fig. 2.26).
Un altro problema è quello della semantica della consistenza adottata, dal punto di vista dei
client. I progettisti di PVFS2 ritenevano che implementare la rigida semantica POSIX richiedesse un costo troppo elevato in termini di prestazioni, per via della necessità di sincronizzare i
diversi processi operanti in concorrenza su una stessa risorsa. Daltra parte uno dei cardini progettuali di PVFS2 è quello di realizzare un file system stateless, al fine di facilitare il ripristino
del sistema in situazioni critiche; chiaramente ciò è in contrasto con le esigenze della semantica
POSIX.
Per lo stesso motivo non è possibile implementare un sistema di locking distribuito che permetta il caching dei dati sui client, sebbene sia previsto il caching della struttura gerarchica
delle directory per una finestra di tempo di durata configurabile. In ogni caso niente assicura
2.6. PVFS2
41
x
y=0
x=0...8
y=1
x=0...8
...
Array View of Data
Data as Stored in File
Figura 2.26: Accesso non contiguo ai dati.

che due client non abbiano una visione differente del file system per un breve lasso di tempo:
la semantica adottata garantisce esclusivamente che operazioni di scrittura, che non si sovrappongono fra loro, siano eseguite in maniera atomica. Operazioni di scrittura concorrenti su una
stessa regione genereranno invece un risultato indefinito.
Per lo stesso motivo si pone il problema della consistenza della struttura gerarchica del
file system in presenza di operazioni concorrenti conflittuali. La soluzione adottata è quella di
suddividere ciascuna operazione in pi`
u passi atomici che lascino il sistema in uno stato sicuro.
Per chiarire le idee, ad esempio, la creazione di un nuovo file in PVFS2 richiede le seguenti
microoperazioni:
1. creazione degli oggetti atti alla memorizzazione dei dati per il nuovo file;
2. creazione dei metadati per il nuovo file;
3. collegamento dei metadati con gli oggetti creati;
4. creazione di una nuova voce nella struttura della directory che punti ai metadati creati.
` chiaro che, seguendo una simile strategia, linterruzione delle operazioni prima del termine
E
previsto provoca solo uno spreco di risorse, ma non mette in pericolo la coerenza del sistema:
il file esiste ed è accessibile, oppure non figura affatto nella struttura del file system. Questapproccio al problema pu`
o rendere pi`
u complessa limplementazione delle operazioni del parallel
file system e richiede lesecuzione di meccanismi di rollback per il recupero delle risorse andate
perse, ma è comunque pi`
u efficiente di un sistema di locking distribuito.
Per quanto riguarda lultimo dei punti nominati, ovvero lutilizzo di riferimenti ai file indipendenti dai client, bisogna chiarire che sono utilizzate delle handle, ottenute dai client mediante
una richiesta al MetaData Server e trasferibili fra un cliente laltro tramite un semplice messaggio MPI. In questo modo è possibile realizzare lapertura di uno stesso file da parte di pi`
u
client mediante una singola interrogazione del MetaData Server ed un successivo broadcast della handle cos` ottenuta. Il risultato di questi accorgimenti è il raggiungimento di prestazioni
invidiabili in contesti che richiedono un massiccio utilizzo di operazioni di I/O parallelo.
42

Le scelte progettuali di PVFS2 permettono a questo parallel file system di avere ottime
performance in ambienti paralleli, ma, al contempo, di non offrire le stesse prestazioni di un file
system locale, se, ad esempio, impiegato per memorizzare le home directory degli utenti. Senza
il caching dei metadati lato client, le operazioni di stat, tipicamente, impiegano molto tempo
per essere eseguite, poiche le informazioni devono essere recuperate interrogando tutti i server,
attraverso la rete di interconnesione. Unoperazione come il listing dei file (tramite il comando
ls), infatti, pu`
o richiedere pi`
u tempo di quello che ci si aspetti.
A causa di questo tipo di limitazioni, PVFS2 risulta, quindi, pi`
u adatto per applicazioni che
richiedono un intenso I/O. PVFS2, inoltre, è ottimizzato per la lettura e scrittura efficiente di
dati di grosse dimensioni, e, quindi, risulta particolarmente utile per applicazioni scientifiche [4].
2.7
Confronto delle soluzioni analizzate
I file system a dischi condivisi sono stati introdotti in maniera predominante nei cluster
VAX/VMS della Digital nei primi anni 80. Essi fanno affidamento sulle tecnologie Fibre Channel , iSCSI o InfiniBand, basate sulle Storage Area Network (SAN). In questa categoria rientrano
General Parallel File System (GPFS) di IBM e Global File System (GFS) di Red Hat.
Larchitettura di questi cluster file system rispecchia quella dei file system locali e le performance per un singolo client sono estremamente buone. Sebbene la concorrenza viene penalizzata
da unarchitettura che non è ottimizzata per la scalabilità, questi sistemi offrono il failover con
vari gradi di robustezza. GPFS ha molto successo per cluster fino a poche centinaia di nodi.
Tipicamente, le performance di una SAN su Fibre Channel è ragionevole, ma certamente non
può competere con client che fanno uso di reti InfiniBand, Quadrics o Myricom con protocolli
nativi [14].
Per limitare i problemi di scalabilità dei file system a dischi condivisi, GPFS e GFS sono
spesso utilizzati in sottocluster che esportano lo storage via NFS (ogni nodo esporta il file
system attraverso NFS versione 2 o 3). Nella versione 4 di NFS, invece, gli export risultano
molto complessi a causa della necessit`
a di condividere le informazioni di stato tra i server NFS.
Sebbene la scalabilit`
a di NFS migliori, questa stratificazione introduce una degradazione delle
performance ed il failover di NFS raramente risulta completamente trasparente alle applicazioni.
NFS, inoltre, non offre ne buone performance, ne segue la semantica definita dagli standard
POSIX [14].
Lustre, pertanto, sembrerebbe unottima soluzione perchè progettato fin dallinizio per supportare una maggiore scalabilit`
a ed, infatti, viene attualmente utilizzato in cluster dotati di
migliaia di nodi. Daltro canto, GPFS di IBM sembra ottenere buone prestazioni per cluster
con relativamente pochi nodi, mentre PVFS2 risulta particolarmente adatto per dotare il cluster
di uno spazio di scratch molto veloce, per applicazioni scientifiche che lavorano su file di grandi
dimensioni, come quelle tipicamente utilizzate in ambienti High Performance Computing.
2.7. Confronto delle soluzioni analizzate
43
In tabella 2.2 vengono messi a confronto i cluster file system descritti precedentemente,
evidenziando sinteticamente le loro caratteristiche (dal confronto sono stati esclusi i cluster
file system HDFS e GlusterFS, che, dato il loro recente sviluppo e la relativamente minor
documentazione, non permettono di valutarne in dettaglio le caratteristiche).
44

GPFS
Lustre
GFS
PVFS2
Licenza
Proprietario
Open Source
(GPL)
GPL (Linux
Kernel)
Open Source
(GPL)
Tipo di
soluzione
Di solito legato
ad hardware
IBM
Software
Software
(distribuito in
Red Hat
Enterprise
Suite)
Software
Scalabilit`
a
(numero di
client)
fino a 1.024
>25.000
300
Reti
supportate
Ethernet,
InfiniBand
Ethernet,
InfiniBand,
Myrinet,
Quadrics ed
altre tecnologie
proprietarie
Ethernet
Ethernet,
InfiniBand e
Myrinet
Architettura
Architettura
tradizionale
VAX cluster file
system
Architettura di
storage a
oggetti
Cluster File
System
Parallel File
System
Nodi
direttamente
connessi allo
storage
nodi NSD
oppure tutti i
nodi, nella
modalit`
a SAN
OST
tutti i nodi nella

modalità SAN,
oppure solo i
nodi GNBD
PVFS2 I/O
server
Tipo di
storage
SAN, RAID
SAN, RAID,
SCSI
SAN, SCSI
RAID, SCSI,
IDE
Metadata
server
nodi NSD
oppure tutti i
nodi, nella
modalit`
a SAN
MDS
metadati
distribuiti su
tutti i nodi
PVFS2
metadata server
Comunicazione TCP/IP
tra daemon
Portals Network
Abstraction
Layer (NAL)
TCP/IP
Buffered
Messaging
Interface (BMI)
Installazione
e amministrazione
IBM Redbook
Difficoltosa
Ben
documentata
Ben
documentata
Ridondanza
(tolleranza ai
guasti)
Replicazione di
dati e metadati,
failure groups
Replicazione
degli OST,
failover di MDS
Limitata
(journaling
distribuito e
tecniche di
fencing)
Limitata
(RAID)
Feature
particolari
Interoperabilit`
a
AIXLinux
Intentbased
locking
ROMIO
(MPIIO)
Tabella 2.2: Tabella comparativa dei cluster/parallel file system.
45
Capitolo 3
Installazione e test di un parallel file

system
In questo capitolo viene descritta in dettaglio linstallazione ed il benchmarking del parallel
file system PVFS2. Per raggiungere questo scopo, è stato realizzato un minicluster composto
da 7 nodi (connessi tra loro attraverso una rete Gigabit Ethernet) su cui sono state installate le
distribuzioni GNU/Linux Rocks [33] e CentOS [34].
3.1
Realizzazione di un minicluster
3.1.1
Distribuzione Rocks Cluster
Come gi`
a accennato, la distribuzione GNU/Linux individuata per la messa in opera del
cluster è la Rocks: una distribuzione opensource sviluppata dal Rocks Cluster Group del San
Diego Supercomputer Center (Università della California), che permette di configurare e gestire
un cluster in maniera semplice e automatizzata. Rocks 4.2.1 (Cydonia) è a sua volta basata
sulla distribuzione CentOS 4.3 (Final) e prevede linstallazione e la configurazione del software
pi`
u comunemente utilizzato in ambito cluster, attraverso il sistema dei roll.
Un roll consiste di una serie di pacchetti software ed una collezione di programmi e
script per la configurazione degli stessi. Segue una lista di alcuni dei roll presenti in questa
distribuzione:
base : contiene linsieme dei pacchetti software che formano il sistema base
kernel : contiene il kernel linux
ganglia : un sistema di monitoraggio del cluster
hpc : compilatori e librerie per lHigh Performance Computing
area51 : tool e servizi usati per analizzare lintegrità dei file del cluster (come Tripwire e
chkrootkit)
46
Capitolo 3. Installazione e test di un parallel file system
webserver : server web apache

La scelta è ricaduta su questa particolare distribuzione per la sua semplicità di installazione e
gestione dei nodi di un cluster, e, soprattutto, perchè una delle poche a supportare larchitettura
IA-64 (almeno fino alla versione 4.2.1, su cui si basa questo documento).
In figura 3.1 è visualizzata larchitettura tipica di un cluster Rocks: questa si compone di
un nodo di login (denominato frontend ) e di diversi nodi di calcolo (compute nodes) connessi
tra loro attraverso una rete di interconnessione (tipicamente Ethernet). Il frontend è, inoltre,
dotato di uninterfaccia di rete aggiuntiva direttamente connessa ad Internet e fornisce una serie
di servizi, tra cui il monitoraggio del cluster tramite ganglia, lexport via NFS delle home degli
utenti ed i servizi di rete (firewall, NAT, . . . ).
Figura 3.1: Architettura tipica di un Rocks cluster.
3.1.2
Architettura del cluster leonardo
Il cluster realizzato si compone di 7 nodi HP Integrity rx2600 Server (Fig. 3.2) originariamente appartenenti al cluster HP XC6000 Sigma. I nodi HP rx2600 sono dotati delle seguenti
caratteristiche:
R
R
Processore: 2 CPU Intel
Itanium
2 a 1.4GHz
Memoria: 2GB RAM DDR

Harddisk: fino a 3 x 36GB/73GB/146GB dischi hotplug Ultra320 SCSI
Interfacce di rete: Gigabit Ethernet e 10/100 Mbps
3.1. Realizzazione di un minicluster
47
Figura 3.2: HP Integrity rx2600 Server.
Figura 3.3: Architettura del cluster leonardo.

In figura 3.3 è visualizzata larchitettura del cluster realizzato (leonardo). I 7 nodi che lo
compongono sono suddivisi in:
1 nodo di login o frontend : leonardo;
2 nodi di calcolo: c0-0 e c0-2;
4 nodi di I/O: io37, io38, io39 e io40.
48
/dev/sda /dev/sdb
/dev/sda /dev/sdb
/dev/sda /dev/sdb
/dev/sda /dev/sdb
io37
io38
io39
io40
Gigabit Ethernet
leonardo
c0-0
c0-2
/dev/sda /dev/sdb /dev/sdc
/dev/sda
/dev/sda
compute nodes
System disk: 36.4GB Ultra320 SCSI
login node (front-end)

I/O nodes
Storage disk: 73 .4GB Ultra320 SCSI
Figura 3.4: Organizzazione dello storage in leonardo.

Dal punto di vista dello storage (Fig. 3.4), ogni nodo del cluster è provvisto di un disco
di sistema (36.4GB Ultra320 SCSI), mappato dal sistema operativo in /dev/sda, sul quale è
installato il sistema operativo:
Rocks 4.2.1 (Cydonia) sul frontend (leonardo) ed i nodi di calcolo (c0-0 e c0-2);
CentOS 4.6 sui nodi di I/O (io37, io38, io39 e io40).
Oltre al disco di sistema, tutti nodi di I/O (io37...40) sono provvisti di un secondo disco pi`
u
capiente (73.4GB Ultra320 SCSI), mappato dal sistema operativo in /dev/sdb e utilizzato per
lo storage PVFS2: questi nodi, infatti, assumono il ruolo di I/O server per PVFS2. Il frontend,
invece, possiede altri 2 dischi aggiuntivi di uguale capienza (73.4GB Ultra320 SCSI):
lunica partizione sul secondo disco (/dev/sdb1) è utilizzata per lo storage PVFS2 (questo
nodo assume il ruolo di metadata server );
lunica partizione sul terzo disco (/dev/sdc1) viene esportata via NFS a tutti i nodi di
calcolo e sar`
a utilizzata per effettuare i test per il benchmark (cfr. sezione 3.4).
Il partizionamento dei dischi, descritto in dettaglio nella sezione 3.1.3, è schematizzato nelle
tabelle 3.2, 3.3 e 3.4, mentre il ruolo assunto dai diversi nodi del cluster, riguardo PVFS2, è
schematizzato nella tabella 3.1.

hostname
49
ruolo nel cluster
ruolo in PVFS2
leonardo
frontend
metadata server
io37
I/O node
I/O server
io38
I/O node
I/O server
io39
I/O node
I/O server
io40
I/O node
I/O server
c0-0
compute node
client PVFS2
c0-2
compute node
client PVFS2
Tabella 3.1: PVFS2: ruolo assunto dai nodi del cluster.
3.1.3
Installazione di Rocks
La prima fase consiste nellinstallazione di Rocks sul nodo frontend. Nella schermata iniziale
(Fig. 3.5) digitare frontend al prompt di ELILO, per avviare uninstallazione su tale nodo.
Figura 3.5: Rocks: schermata di avvio.

Nella seconda schermata (Fig. 3.6) scegliamo CD/DVDbased Rolls come sorgente dellinstallazione.
Nella schermata successiva (Fig. 3.7) verranno visualizzati tutti i rolls disponibili sul DVD
di installazione. Per il cluster leonardo sono stati selezionati i rolls base, kernel, os, hpc, java,
ganglia e webserver (non sono stati selezionati grid ed sge). Una volta premuto il tasto Submit
verranno visualizzati i rolls da installare (Fig. 3.8).
Successivamente verranno inserite le informazioni relative al cluster (Fig. 3.9). In questo
caso sono state inserite le seguenti informazioni:
50
Figura 3.6: Rocks: selezione della sorgente dellinstallazione.
Figura 3.7: Rocks: selezione dei rolls.

Fully qualified host name : leonardo.unile.it
Cluster name : Leonardo
Certificate organization : University of Lecce
Certificate locality : Lecce
Certificate state : Italy
Certificate country : IT
URL : http://leonardo.unile.it
51
Figura 3.8: Rocks: roll selezionati.
Figura 3.9: Rocks: inserimento informazioni sul cluster.
Nelle due successive schermate (Fig. 3.10) verranno inseriti i dati relativi alla configurazione
delle interfacce di rete del nodo frontend.
Configurazione della rete privata (interfaccia eth0):
52
Figura 3.10: Rocks: configurazione della rete.

IP address : 172.16.1.1
Netmask : 255.255.255.0
Configurazione della rete pubblica (interfaccia eth1):
IP address : 193.204.74.236 (corrispondente a leonardo.unile.it)
Netmask : 255.255.255.192
Gateway : 193.204.74.194
DNS server : 193.204.64.3
Alla schermata di selezione del metodo di partizionamento (Fig. 3.11) si è scelto Manual
partitioning, in modo da dimensionare opportunamente le varie partizioni.
Figura 3.11: Rocks: partizionamento manuale del nodo frontend.

Durante la fase di partizionamento manuale, si è scelto di partizionare il nodo frontend seguendo lo schema illustrato nelle tabella 3.2: in particolare la partizione /export/home conterr`
a
le home degli utenti del cluster, esportate via NFS a tutti i compute node.

harddisk
53
device
file system
/dev/sda1
vfat
/boot/efi
/dev/sda2
ext3
/dev/sda3
swap
/dev/sda4
ext3
/var
/dev/sda5
ext3
/export
18GB
73.4GB Ultra320 SCSI
/dev/sdb1
ext3
/mnt/pvfs2
68GB
/dev/sdc1
ext3
/export2
68GB
mountpoint
dimensione
500MB
8GB
4GB
4GB
Tabella 3.2: Partizioni del frontend.

Completata la fase di configurazione Rocks provvederà a creare e formattare le partizioni ed
installare automaticamente tutti i pacchetti software sul nodo di frontend.
Dopo aver completato linstallazione del frontend sarà necessario effettuare linstallazione
di Rocks sui nodi di calcolo: questultima avviene in maniera completamente automatica utilizzando un apposito tool fornito dalla distribuzione. Al prompt di bash del frontend baster`
a
digitare insert-ethers per avviare lo script di installazione automatica, scegliendo Compute
come tipologia di nodo da preparare (Fig. 3.12).
Figura 3.12: Rocks: scelta della tipologia di nodo da installare.

A questo punto, sar`
a necessario effettuare il boot dal DVD di installazione di Rocks, collegato
al compute node, premendo semplicemente INVIO al prompt della schermata iniziale (Fig. 3.5).
Rocks, in esecuzione sul nodo di calcolo, effettuerà una richiesta di installazione al nodo
frontend, che la intercetter`
a (tramite insert-ethers) visualizzando la schermate in figura 3.13.
54
Figura 3.13: Rocks: installazione automatica del nodo di calcolo compute-0-0.

A questo punto sar`
a eseguita la fase di installazione in maniera completamente automatizzata. Ovviamente, sar`
a necessario ripetere i passi necessari per linstallazione anche sul secondo
compute node. Il partizionamento automatico del disco di sistema del compute node è descritto
nella tabella 3.3.
harddisk
device
file system
mountpoint
/dev/sda1
vfat
/boot/efi
/dev/sda2
ext3
/dev/sda3
swap
/dev/sda4
ext3
dimensione
500MB
8GB
4GB
/var
4GB
Tabella 3.3: Partizioni dei compute nodes.

A differenza dei nodi frontend e di calcolo, sui 4 nodi di I/O si è deciso di installare la
distribuzione CentOS, essendo questi nodi completamente indipendenti dal cluster. Linstallazione è avvenuta singolarmente su ogni nodo, seguendo lo schema di partizionamento visibile in
tabella 3.4.
harddisk
device
file system
mountpoint
/dev/sda1
vfat
/boot/efi
/dev/sda2
ext3
/dev/sda3
swap
/dev/sdb1
ext3
dimensione
500MB
30GB
4GB
/mnt/pvfs2
Tabella 3.4: Partizioni degli I/O nodes.
68GB
3.2. Compilazione e installazione di PVFS2
3.2
55
Compilazione e installazione di PVFS2
3.2.1
Requisiti software
Dipendenze software [32]:

Compilatore gcc 2.96 o maggiore (raccomandato gcc 3.x). Utilizzata la versione 3.4.5
(Red Hat 3.4.5-2);
GNU make (utilizzata la versione 3.80);
Berkeley DB (utilizzata la versione 4.2.527.3.el4) il server PVFS2 utilizza un database
per memorizzare le informazioni sullo storage;
supporto aio e pthreads.
Software raccomandato:
GNU Libc (glibc) 2.3.2 o maggiore (utilizzata la versione 2.3.4);
Linux kernel headers ver. 2.6.0 o maggiore (utilizzata la versione 2.6.942.0.3.EL) o 2.4.19
(o maggiore) NOTA: non è necessario per un PVFS2 server, ma solo per un modulo del
kernel utilizzato dai client;
MPICH2 0.96p2 o maggiore, sebbene sia consigliato la versione pi`
u aggiornata di MPICH2;
OpenMPI 1.0 o maggiore (utilizzata la versione 1.1), sebbene potrebbe non avere tutte le
features o i bug fixes di MPICH2.
Software opzionale:
Myricom MX;
InfiniBand.
3.2.2
Compilazione e installazione
Di seguito, sono indicati i passi necessari per la compilazione e linstallazione di PVFS2 sul
frontend leonardo [29]:
[ root@leonardo ~]# cd / usr / src
[ root@leonardo src ]# wget http :// mirror . anl . gov / pub / pvfs2 / pvfs -2.7.1. tar . gz
[ root@leonardo src ]# tar xvzf pvfs -2.7.1. tar . gz
[ root@leonardo src ]# ln -s pvfs -2.7.1 pvfs2
[ root@leonardo src ]# cd pvfs2
[ root@leonardo pvfs2 ]# ./ configure \\
-- with - kernel =/ lib / modules / uname -r / build / -- disable - kernel - aio
***** Displaying PVFS2 Configuration Information *****
-----------------------------------------------------PVFS2 configured to build karma gui
: no
PVFS2 configured to use epoll
: yes
56
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
PVFS2
configured to perform coverage analysis

configured for aio threaded callbacks
configured for the 2.6. x kernel module
configured for the 2.4. x kernel module
configured for using the mmap - ra - cache
configured for using trusted connections
configured for a thread - safe client library
will use workaround for redhat 2.4 kernels
will use workaround for buggy NPTL
server will be built
:
:
:
:
:
:
:
:
:
:
no
yes
yes
no
no
no
yes
no
no
yes
PVFS2 version string : 2.7.1

[ root@leonardo pvfs2 ]# make
[ root@leonardo pvfs2 ]# make install
` necessario effettuare alcune osservazioni:

E
lopzione --disable-kernel-aio è stata utilizzata per consentire il funzionamento del
modulo su questa particolare versione del kernel (2.6.942.0.3.EL), e non dovrebbe essere
specificata in future compilazioni;
solo per i client PVFS2, è possibile saltare la compilazione della parte server, aggiungendo
lopzione --disable-server al lancio del ./configure;
è possibile specificare il percorso di installazione di PVFS2 aggiungendo
--prefix=/install/path (/usr/local di default) al lancio di ./configure.
Ripetere la stessa compilazione per i client PVFS2: in questo caso, i compute node c0-0 e c0-2.
Solo per i client inoltre, è necessaria la compilazione e installazione aggiuntiva di un modulo del
kernel:
[ root@c0 -0 pvfs2 ]# make kmod
[ root@c0 -0 pvfs2 ]# make kmod_install
In questa installazione, il modulo si trova in /lib/modules/2.6.9-42.0.3.EL/kernel/fs/pvfs2/pvfs2.ko

Per aggiornare le dipendenze tra i moduli è sufficiente eseguire il seguente comando:
[ root@c0 -0 ~]# depmod - ae
Per verificare la corretta installazione del modulo basta lanciare il seguente comando:
[ root@c0 -0 ~]# modprobe -l | grep pvfs2
/ lib / modules /2.6.9 -42.0.3. EL / kernel / fs / pvfs2 / pvfs2 . ko
3.3. Configurazione e avvio di PVFS2
3.3
3.3.1
57
Configurazione e avvio di PVFS2

Configurazione dei server
Il primo passo consiste nel generare il file di configurazione dei server PVFS2 (/etc/pvfs2-fs.conf )
tramite il comando pvfs2-genconfig:
[ root@leonardo ~]# pvfs2 - genconfig / etc / pvfs2 - fs . conf
**********************************************************************
Welcome to the PVFS2 Configuration Generator :
This interactive script will generate configuration files suitable
for use with a new PVFS2 file system . Please see the PVFS2 quickstart
guide for details .
**********************************************************************
You must first select the network protocol that your file system will use .
The only currently supported options are " tcp " , " gm " , " mx " , " ib " , and " portals ".
( For multi - homed configurations , use e . g . " ib , tcp ".)
* Enter protocol type [ Default is tcp ]:
Choose a TCP / IP port for the servers to listen on . Note that this
script assumes that all servers will use the same port number .
* Enter port number [ Default is 3334]:
Choose a directory for each server to store data in .
* Enter directory name : [ Default is / pvfs2 - storage - space ]:
Choose a file for each server to write log messages to .
* Enter log file location [ Default is / tmp / pvfs2 - server . log ]:
/ var / log / pvfs2 - server . log
Next you must list the hostnames of the machines that will act as
I / O servers . Acceptable syntax is " node1 , node2 , ..." or " node {# -# ,# ,#}".
* Enter hostnames [ Default is localhost ]: io37 , io38 , io39 , io40
Now list the hostnames of the machines that will act as Metadata
servers . This list may or may not overlap with the I / O server list .
* Enter hostnames [ Default is localhost ]: leonardo
Configured a total of 3 servers :
4 of them are I / O servers .
1 of them are Metadata servers .
* Would you like to verify server list ( y / n ) [ Default is n ]? y
58
****** I / O servers :
io38
io37
io40
io39
****** Metadata servers :
leonardo
* Does this look ok ( y / n ) [ Default is y ]? y
Writing fs config file ... done
Il passo successivo consiste nel copiare il file di configurazione appena creato (/etc/pvfs2-fs.conf )
in tutti i nodi server, ovvero leonardo, io37, io38, io39, io40:
[ root@leonardo ~]# for SERVER in io37 io38 io39 io40 ; do \\
scp / etc / pvfs2 - fs . conf $ { SERVER }:/ etc / \\
done
3.3.2
Avvio dei server
La prima volta che si avvia il server, bisogna prima inizializzare lo storage su tutti i metadata
e I/O server (nel nostro caso: leonardo, io39, io40) con il seguente comando:
[ root@leonardo ~]# pvfs2 - server -f / etc / pvfs2 - fs . conf
[ S 06/30 19:38] PVFS2 Server on node leonardo version 2.7.1 starting ...
pvfs2 - server (10885): unaligned access to 0 x2000000001632467 , ip =0 x40000000000b3fb1
[ D 06/30 19:38] PVFS2 Server : storage space created . Exiting .
[ root@io37 ~]# pvfs2 - server -f / etc / pvfs2 - fs . conf
[ S 06/30 19:39] PVFS2 Server on node io37 version 2.7.1 starting ...
59
Successivamente, si avviano i server PVFS2:

[ root@leonardo ~]# pvfs2 - server / etc / pvfs2 - fs . conf
[ S 06/30 19:41] PVFS2 Server on node leonardo version 2.7.1 starting ...
[ root@io37 ~]# pvfs2 - server / etc / pvfs2 - fs . conf
Durante lesecuzione dei server verranno mantenuti i log in /var/log/pvfs2-server.log, come

specificato durante la configurazione precedente.
Per avviare il server PVFS2 in maniera automatica allavvio della macchina, bisogna utilizzare
lo script di init fornito nei sorgenti di PVFS2:
[ root@leonardo ~]# cp / usr / src / pvfs2 / examples / pvfs2 - server . rc \\
/ etc / rc . d / init . d / pvfs2 - server
[ root@leonardo ~]# chmod + x / etc / rc . d / init . d / pvfs2 - server
[ root@leonardo ~]# cd / etc / rc runlevel | cut -d -f2 . d /
[ root@leonardo rc3 . d ]# ln -s ../ init . d / pvfs2 - server S50pvfs2 - server
[ root@leonardo ~]# cd / etc / rc0 . d /; ln -s ../ init . d / pvfs2 - server K50pvfs2 - server
[ root@leonardo ~]# cd / etc / rc6 . d /; ln -s ../ init . d / pvfs2 - server K50pvfs2 - server
Ora è possibile avviare i server PVFS2 semplicemente tramite il seguente comando:

[ root@leonardo ~]# service pvfs2 - server start
Starting PVFS2 server :
OK
Ovviamente, è necessario ripetere i suddetti comandi su tutti i server PVFS2 (in questo caso su
io37, io38, io39 e io40).
3.3.3
Configurazione dei client
Il primo passo consiste nel caricare il modulo del kernel pvfs2.ko:

[ root@compute -0 -0 ~]# modprobe pvfs2
[ root@compute -0 -0 ~]# lsmod | grep pvfs2
pvfs2
244556 0
Successivamente si crea il mountpoint di PVFS2 ed il file pvfs2tab:

[ root@compute -0 -0 ~]# mkdir / mnt / pvfs2
[ root@compute -0 -0 ~]# touch / etc / pvfs2tab
[ root@compute -0 -0 ~]# chmod a + r / etc / pvfs2tab
60
Nel file pvfs2tab, vengono memorizzati i vari mountpoint PVFS2, seguendo la stessa sitassi del
file /etc/fstab:
# PVFS2 I / O server ######### mountpoint # file system type # options
tcp :// leonardo :3334/ pvfs2 - fs / mnt / pvfs2
pvfs2
defaults , noauto 0 0
3.3.4
Avvio dei client
Per avviare un client PVFS2 è sufficiente eseguire il seguente comando:

[ root@compute -0 -0 ~]# pvfs2 - client -L / var / log / pvfs2 - client . log / mnt / pvfs2 /
Una volta avviato il daemon client di PVFS2, occorre montare il file system:
[ root@compute -0 -0 ~]# mount -t pvfs2 tcp :// leonardo :3334/ pvfs2 - fs / mnt / pvfs2
[ root@compute -0 -0 ~]# mount | grep pvfs2
tcp :// leonardo :3334/ pvfs2 - fs on / mnt / pvfs2 type pvfs2 ( rw )
Per verificare il corretto funzionamento del sistema, si può utilizzare il tool pvfs2-ping:
[ root@compute -0 -0 ~]# pvfs2 - ping -m / mnt / pvfs2
(1) Parsing tab file ...
(2) Initializing system interface ...
(3) Initializing each file system found in tab file : / etc / mtab ...
PVFS2 servers : tcp :// leonardo :3334
Storage name : pvfs2 - fs
Local mount point : / mnt / pvfs2
/ mnt / pvfs2 : Ok
(4) Searching for / mnt / pvfs2 in pvfstab ...
PVFS2 servers : tcp :// leonardo :3334
Storage name : pvfs2 - fs
Local mount point : / mnt / pvfs2
meta servers :
tcp :// leonardo :3334
data servers :
tcp :// io37 :3334
tcp :// io38 :3334
tcp :// io39 :3334
tcp :// io40 :3334
(5) Verifying that all servers are responding ...
meta servers :
61
tcp :// leonardo :3334 Ok

data servers :
tcp :// io37 :3334
tcp :// io38 :3334
tcp :// io39 :3334
tcp :// io40 :3334
Ok
Ok
Ok
Ok
(6) Verifying that fsid 25712395 is acceptable to all servers ...

Ok ; all servers understand fs_id 25712395
(7) Verifying that root handle is owned by one server ...
Root handle : 1048576
Ok ; root handle is owned by exactly one server .
=============================================================
The PVFS2 filesystem at / mnt / pvfs2 appears to be correctly configured .
NOTA: per la diversa configurazione dei nodi io37, io38, io39 e io40 (equipaggiati con CentOS
4.6 ), è stato necessario modificare i file /etc/hosts di tutti i nodi del cluster, aggiungendo gli
hostname mancanti.
Un tool per verificare lo spazio disponibile nei vari server di PVFS2 è pvfs2-statfs:
[ root@compute -0 -0 ~]# pvfs2 - statfs -H -m / mnt / pvfs2 /
aggregate statistics :
--------------------------------------fs_id : 25712395
total number of servers ( meta and I / O ):
handles available ( meta and I / O ):
handles total ( meta and I / O ):
bytes available :
bytes total :
5
9223372036854775790
9223372036854775800
109.0 G
109.0 G
NOTE : The aggregate total and available statistics are calculated based
on an algorithm that assumes data will be distributed evenly ; thus
the free space is equal to the smallest I / O server capacity
multiplied by the number of I / O servers . If this number seems
unusually small , then check the individual server statistics below
to look for problematic servers .
meta server statistics :
--------------------------------------server : tcp :// leonardo :3334
62

RAM total
:
RAM free
:
uptime
:
load averages
:
handles available :
handles total
:
bytes available :
bytes total
:
mode : serving only
4.2 G
3.5 G
6 hours , 47 minutes
448 992 7072
1844674407370955150
1844674407370955160
4.4 G
7.8 G
metadata
I / O server statistics :
--------------------------------------server : tcp :// io37 :3334
RAM total
:
RAM free
:
uptime
:
load averages
:
handles available :
handles total
:
bytes available :
bytes total
:
mode : serving only
4.2 G
4.0 G
0 0 672
1844674407370955160
1844674407370955160
27.2 G
29.4 G
I / O data
server : tcp :// io38 :3334

RAM total
:
RAM free
:
uptime
:
load averages
:
handles available :
handles total
:
bytes available :
bytes total
:
mode : serving only
4.2 G
4.0 G
0 0 32
1844674407370955160
1844674407370955160
27.2 G
29.4 G
I / O data

RAM total
:
RAM free
:
uptime
:
load averages
:
handles available :
handles total
:
bytes available :
bytes total
:
mode : serving only
4.2 G
4.0 G
0 0 0
1844674407370955160
1844674407370955160
27.3 G
29.4 G
I / O data

RAM total
RAM free
: 4.2 G
: 4.0 G
3.4. Benchmark di PVFS2

uptime
:
load averages
:
handles available :
handles total
:
bytes available :
bytes total
:
mode : serving only
3.4
63
0 0 0
1844674407370955160
1844674407370955160
27.3 G
29.4 G
I / O data
Benchmark di PVFS2
Per valutare le performance di PVFS2, è necessario effettuare del benchmarking, che per`
o
risulta particolarmente complesso, in quanto riguarda lanalisi di file system e sistemi di storage.
Complesse interazioni tra i dispositivi di I/O, cache, kernel ed altri componenti del sistema
operativo hanno come risultato un comportamento che spesso risulta difficile da analizzare.
Inoltre, i sistemi hanno diverse caratteristiche ed ottimizzazioni, per cui, spesso, nessun singolo
benchmark risulta appropriato. A questa difficoltà, si aggiunge anche il fatto che i sistemi,
durante lutilizzo di tutti i giorni, sono sottoposti ad una grande varietà di carico.
Nonostante ci`
o, negli anni sono stati sviluppati numerosi tool per il benchmarking dei file
system. Fra quelli comunemente utilizzati in ambienti Unixlike vi sono [35]:
Bonnie++
IOR (Interleaved or Random)
IOzone
Bonnie++ è una suite di benchmark che permette di eseguire diversi semplici test per misurare le performance di file system e harddisk. Questo tool permette di eseguire 2 tipologie
di operazioni: la prima viene utilizzata per misurare il throughput di I/O simulando luso di
unapplicazione che opera su database, mentre la seconda effettua dei test di creazione, lettura
e rimozione di molti file di piccola dimensione. Sebbene molto diffuso, Bonnie++ risulta utile
solo per testare file system locali e non risulta molto adatto per il benchmarking di cluster o
parallel file system.
IOR, al contrario, viene utilizzato per misurare le performance di parallel file system, visto
che è in grado di simulare diversi pattern di accesso ai dati ed utilizza MPI per la sincronizzazione
dei processi. Inoltre, lI/O viene eseguito utilizzando le estensioni MPIIO.
IOZone è un tool per il benchmarking di file system che genera una moltitudine di operazioni
sui file. Questo tool misura le performance di I/O per le seguenti operazioni: read, write, re
read, rewrite, read backwards, read strided, fread, fwrite, random read/write, pread/pwrite
variants, aio read, aio write ed mmap.
Oltre ai tool precedentemente citati, ne esistono diversi altri, ognuno volto a misurare particolari caratteristiche di un file system. In questo documento, comunque, si è scelto di effettuare
una serie di test su PVFS2 ed NFS, ispirandosi agli stessi utilizzati in [35].
64

Sono stati implementati numerosi bashscript, volti ad automatizzare lesecuzione del bench-
mark ed uno script di gestione centralizzata di PVFS2 (pvfs2-manage) per automatizzare il

restart dei client e dei server PVFS2 durante le varie fasi del benchmarking.
I test sono stati eseguiti sul cluster Leonardo, la cui realizzazione è descritta in dettaglio
nella precedente sezione 3.1.
Segue lelenco dei test effettuati per i 2 file system analizzati:
1 client PVFS2, 2 I/O server PVFS2;
1 client NFS (singolo server);
2 client NFS (singolo server).
Nel caso dei test su 2 client, questi sono stati eseguiti contemporaneamente sui 2 compute node.
Il benchmark di PVFS2 è stato effettuato nella directory /mnt/pvfs2, mentre quello su NFS è
stato eseguito su /export2.
Inoltre, prima di eseguire il benchmarking è stato effettuato lo stop dei servizi crond, atd
e anacron sui compute node (c0-0 e c0-2) e sugli I/O server (io37, io38, io39, io40) al fine
di evitare che eventuali processi eseguiti da tali servizi potessero falsare i risultati. Inoltre,
tutti i test sono stati rieseguiti 5 volte e sono state effettuate le medie dei risultati al fine di
minimizzare lerrore nelle misurazioni.
In tabella 3.5 sono elencati i 22 test utilizzati per il benchmarking.
Nelle pagine seguenti sono visualizzati i grafici ottenuti dallesecuzione dei test realizzati:
sullasse delle ascisse è indicato il numero del test effettuato, mentre sullasse delle ordinate
viene indicato il tempo di esecuzione del test (in secondi).
In tutti i grafici un tempo minore corrisponde a maggiori performance.
Come ci si aspettava, PVFS2 non offre performance migliori di NFS nelluso standard del
file system, specialmente nelle operazioni con molti file di piccole dimensioni. Al contrario,
offre migliori prestazioni di NFS nella manipolazione di file di grandi dimensioni: a questo
proposito, infatti, si confrontino i risultati ottenuti nei grafici 3.22 e 3.23 relativi ai test da 13
a 18 (operazioni di lettura e scrittura con file da 1 e 10 GB).
Un comportamento anomalo rilevato è, invece, la leggera degradazione delle performance
nelluso di 4 PVFS2 I/O server, rispetto agli stessi test con 2 server, probabilmente dovuto al
numero estremamente basso di client PVFS2 utilizzati (solo 2). Allaumentare del numero di
nodi client PVFS2, le prestazioni dovrebbero aumentare, sebbene questo andrebbe verificato
effettuando ulteriori test.
no test
Descrizione
Creazione di 10.000 file con touch in una directory
Esecuzione di find in quella directory
Rimozione della directory contenente 10.000 file
Creazione di 10.000 directory con mkdir in una directory
Esecuzione di find in quella directory
Rimozione della directory contenente 10.000 directory
Copia del tarball del kernel da una partizione esterna alla partizione di test
Copia del tarball del kernel dalla partizione di test in /dev/null
Decompressione del tarball del kernel sulla partizione di test
10
Compressione del tarball del kernel sulla partizione di test
11
Rimozione dellalbero dei sorgenti del kernel
12
Copia 10 volte del tarball del kernel generato nel test no 10
13
Creazione di un file di 1 GB da /dev/zero
14
Copia del file di 1 GB sulla stessa partizione
15
Lettura con dd del file da un 1 GB in /dev/null
16
Creazione di un file di 10 GB da /dev/zero
17
Copia del file di 10 GB sulla stessa partizione
18
Lettura con dd del file di 10 GB in /dev/null
19
Split di un file di 10 MB in blocchi da 1024 byte
20
21
22

Tabella 3.5: Elenco dei test per il benchmarking di NFS e PVFS2.
65
66
NFS (1 client) vs. PVFS (1 client - 2 I/O servers)

1080
NFS
1020
PVFS2
960
900
840
780
720
Tempo [s]
660
600
540
480
420
360
300
240
180
120
60
0
1
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
Figura 3.14: Benchmark tra NFS e PVFS2 (2 I/O server) con 1 client.
67

1140
1080
NFS
1020
PVFS2
960
900
840
780
Tempo [s]
720
660
600
540
480
420
360
300
240
180
120
60
0
1
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
68
Tempo [s]

1680
1620
1560
1500
1440
1380
1320
1260
1200
1140
1080
1020
960
900
840
780
720
660
600
540
480
420
360
300
240
180
120
60
0
NFS
PVFS2
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
69
Tempo [s]

1740
1680
1620
1560
1500
1440
1380
1320
1260
1200
1140
1080
1020
960
900
840
780
720
660
600
540
480
420
360
300
240
180
120
60
0
NFS
PVFS2
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
70
PVFS2 (1 client) - 2 vs. 4 I/O server

1140
1080
PVFS2 - 2 I/O server
1020
960
900
840
780
Tempo [s]
720
660
600
540
480
420
360
300
240
180
120
60
0
1
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
Figura 3.18: Benchmark tra PVFS2 (2 o 4 I/O server) con 1 client.
71
Tempo [s]
PVFS2 (2 client) - 2 vs. 4 I/O server

1740
1680
1620
1560
1500
1440
1380
1320
1260
1200
1140
1080
1020
960
900
840
780
720
660
600
540
480
420
360
300
240
180
120
60
0

10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
Figura 3.19: Benchmark tra PVFS2 (2 o 4 I/O server) con 2 client.
72
1 client: NFS, PVFS2 (2 I/O server), PVFS2 (4 I/O server)

1140
1080
NFS
1020

960
900
840
780
Tempo [s]
720
660
600
540
480
420
360
300
240
180
120
60
0
1
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
Figura 3.20: Benchmark tra NFS, PVFS2 (2 o 4 I/O server) con 1 client.
73
Tempo [s]
2 client: NFS, PVFS2 (2 I/O server), PVFS2 (4 I/O server)

1740
1680
1620
1560
1500
1440
1380
1320
1260
1200
1140
1080
1020
960
900
840
780
720
660
600
540
480
420
360
300
240
180
120
60
0
NFS
10 11 12 13 14 15 16 17 18 19 20 21 22
Num. Test
Figura 3.21: Benchmark tra NFS, PVFS2 (2 o 4 I/O server) con 2 client.
74
1 client: NFS, PVFS2 (2 I/O server), PVFS2 (4 I/O server) - Test 13..18
600
NFS
540

480
420
Tempo [s]
360
300
240
180
120
60
0
13
14
15
16
17
18
Num. Test
Figura 3.22: Benchmark tra NFS, PVFS2 (2 o 4 I/O server) con 1 client: particolare dei test
13..18.
75
2 client: NFS, PVFS2 (2 I/O server), PVFS2 (4 I/O server) - Test 13..18
1080
1020
NFS
960

900
840
780
720
Tempo [s]
660
600
540
480
420
360
300
240
180
120
60
0
13
14
15
16
17
18
Num. Test
Figura 3.23: Benchmark tra NFS, PVFS2 (2 o 4 I/O server) con 2 client: particolare dei test
13..18.
76
Bibliografia
Bibliografia
[1] Wikipedia: List of file systems
http://en.wikipedia.org/wiki/List_of_file_systems
[2] D.A. Heger, An Introduction to File System Technologies in a Cluster Environment,
Fortuitous Technology, Austin, TX, 2006
[3] Cluster File Systems, Inc., Selecting a Scalable Cluster File System, Nov 2005
[4] R. Latham, N. Miller, R. Ross, P. Carns, A NextGeneration Parallel File System
for Linux Clusters, Linux World, Gen 2004
[5] B. ONeill, File Systems: The state of the art, Storage Magazine, Nov 2005
[6] M.W. Margo, P.A. Kovatch, P. Andrews, B. Banister, An Analysis of Stateof
theArt Parallel File Systems for Linux, University of California, San Diego, CA, 2004
[7] IBM General Parallel File System (GPFS)
http://www-03.ibm.com/systems/clusters/software/gpfs/index.html
[8] S. Fadden, An Introduction to GPFS Version 3.2, IBM, Set 2007
[9] F. Schmuck, R. Haskin, GPFS: A Shared-Disk File System for Large Computing
Clusters, Proceedings of the FAST 2002 Conference on File and Storage Technologies,
Monterey, CA, Gen 2002
[10] A. Brunengo, General Parallel File System: caratteristiche, prestazioni ed esempi di
utilizzo in produzione, Presentazione al Workshop CCR, Otranto, Mag 2006
[11] Sun Microsystems LUSTRE wiki
http://wiki.lustre.org
[12] Wikipedia: Lustre file system
http://en.wikipedia.org/wiki/Lustre_%28file_system%29
[13] P. Braam, Lustre, Sun HPC Consortium, Nov, 2007
[14] Lustre File System White Paper, Dic, 2007
Bibliografia
77
[15] E. J. Felix, K. Fox, K. Regimbal, J. Nieplocha, Active Storage Processing in a Parallel File System, 6th LCI International Conference on Linux Clusters: The HPC Revolution,
North Carolina, Apr, 2005.
[16] Red Hat Global File System for RHEL 4.6, Nov, 2007
http://www.redhat.com/docs/manuals/csgfs/pdf/Global_File_System-4_6.pdf
[17] GFS 6.1 Administrators Guide, Mar, 2006
http://www.redhat.com/docs/manuals/csgfs/pdf/rh-gfs-en-6_1.pdf
[18] S. Liang, W. Yu, D. K. Panda, High Performance Block I/O for Global File System
(GFS) with InfiniBand RDMA, International Conference on Parallel Processing, Aug, 2006.
[19] K. W. Preslan, A. P. Barry, J. Brassow, R. Cattelan, A. Manthei, E. Nygaard, S. Van Oort, D. Teigland, M. Tilstra, M. OKeefe, G. Erickson, M.
Agarwal, Implementing Journaling in a Linux Shared Disk File System, Seventeenth
IEEE Symposium on Mass Storage Systems, pag. 351378, Mar, 2000
[20] M. Davini e I. Lisi, Cluster: uno sguardo ai filesystem distribuiti, Linux&C. #15, pag. 40
45, Apr, 2001
[21] M. OKeefe, P. Kennedy, Enterprise data sharing with Red Hat Global File System,
Red Hat Magazine #9, Lug, 2005
[22] Apache Hadoop Project
http://hadoop.apache.org/
[23] Hadoop Wiki
http://wiki.apache.org/hadoop/
[24] Wikipedia: Hadoop
http://en.wikipedia.org/wiki/Hadoop
[25] D. Borthakur, The Hadoop Distributed File System: Architecture and Design, 2007
[26] GlusterFS webpage
http://www.gluster.org
[27] GlusterFS User Guide v1.3
http://www.gluster.org/docs/index.php/GlusterFS_User_Guide_v1.3
[28] Clusters with GlusterFS video
http://videolectures.net/dc08_marinov_gfs/
[29] PVFS2 Development Team, A Quick Start Guide to PVFS2, 16 Apr 2008
[30] Parallel Virtual File System, version 2
http://www.pvfs.org/pvfs2/pvfs2-guide.html
78
Bibliografia
[31] R. Latham, R. Ross, R. Thakur, The Impact of File Systems on MPI-IO Scalability, in
Proceedings of the 11th European PVM/MPI Users Group Meeting, Budapest, Hungary,
2004
[32] PVFS2 download page
http://pvfs.org/download/
[33] Distribuzione Rocks Cluster
http://www.rocksclusters.org
[34] Distribuzione CentOS
http://www.centos.org
[35] J. Piszcz, Benchmarking Filesystems Part II,
http://linuxgazette.net/122/piszcz.html

Lingua

Benvenuto in Scribd!

Cluster File System

Caricato da

Informazioni sul documento

Descrizione:

Data di caricamento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

Cluster File System

Caricato da

Descrizione:

Copyright:

Formati disponibili

Titoli correlati

Cluster File System

Esame di Sistemi di Elaborazione e Progetto I

Corso di laurea specialistica in Ingegneria Informatica

allinstallazione, configurazione e messa in opera di PVFS2.

Cluster File System by Andrea Chiffi is licensed under a Creative Commons

Introduzione ai file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

File system locali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

File system distribuiti o di rete . . . . . . . . . . . . . . . . . . . . . . . .

File system virtuali o per compiti speciali . . . . . . . . . . . . . . . . . .

File system e applicazioni in ambiente cluster . . . . . . . . . . . . . . . . . . . .

2 Cluster file system: le soluzioni disponibili

Red Hat GFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Confronto delle soluzioni analizzate . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3 Installazione e test di un parallel file system

Distribuzione Rocks Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Architettura del cluster leonardo . . . . . . . . . . . . . . . . . . . . . . 46

Compilazione e installazione di PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . 55

Configurazione e avvio di PVFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Configurazione dei server . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Avvio dei server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Configurazione dei client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Avvio dei client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Introduzione ai cluster file system

Introduzione ai file system

Un file system `e un meccanismo con il quale i file sono immagazzinati e organizzati su un

Capitolo 1. Introduzione ai cluster file system

File system locali

File system distribuiti o di rete

File system virtuali o per compiti speciali

1.2. File system e applicazioni in ambiente cluster

tmpfs : file system temporaneo basato sulla memoria di sistema;

File system e applicazioni in ambiente cluster

Capitolo 1. Introduzione ai cluster file system

1.2. File system e applicazioni in ambiente cluster

La Storage Area Network (SAN) `e una rete ad alta velocit`

Capitolo 1. Introduzione ai cluster file system

1.2. File system e applicazioni in ambiente cluster

Capitolo 1. Introduzione ai cluster file system

Molto spesso la capacit`

1.2. File system e applicazioni in ambiente cluster

Capitolo 2. Cluster file system: le soluzioni disponibili

Cluster file system: le soluzioni

2.1. IBM GPFS

Figura 2.1: Architettura di GPFS: ambiente shared disk.

Capitolo 2. Cluster file system: le soluzioni disponibili

Figura 2.2: GPFS: configurazione multicluster.

SAN (with/without switch)

Figura 2.3: Modalit`

2.1. IBM GPFS

Nella seconda modalit`

Figura 2.4: Modalit`

Capitolo 2. Cluster file system: le soluzioni disponibili

Figura 2.5: GPFS: I/O server.

2.1. IBM GPFS

Figura 2.6: GPFS: accesso parallelo ai dischi (striping dei file).

Figura 2.7: GPFS: gestione dei token.

Capitolo 2. Cluster file system: le soluzioni disponibili