General Parallel File System:
caratteristiche, prestazioni ed
esempi di utilizzo in
produzione
Alessandro Brunengo - Sezione INFN di Genova
Workshop CCR
Otranto - maggio 2006
Sommario



Caratteristiche del file system GPFS
Test di affidabilita’, prestazioni e scalabilita’
Esempio di infrastruttura in produzione
meccanismi di export del file system
 configurazione ad alta affidabilita’
 inter-cluster export

2
Caratteristiche

GPFS e’ un file system commerciale sviluppato da IBM
per AIX e portato su linux:




standard POSIX + quota + ACL
ridimensionamento dinamico dei volumi
prestazioni elevate: parallelizzazione degli accessi e
bilanciamento del carico
alta affidabilita’ per



conservazione dei dati tramite repliche di dati e metadati
accesso ai dati grazie a server secondari di volumi che possono
subentrare in failover
esportabilita’ dei volumi via NFS (V3/V4) e samba
3
Cluster

Nodo GPFS: singolo sistema operativo su cui gira il software
GPFS




Cluster GPFS: insieme di nodi che condividono le configurazioni
e l’accesso ai file system, che possono avere funzioni di



moduli del kernel
utility di management del file system
utility di management del cluster
manager/client
quorum/non quorum
Quorum type:


quorum nodes (quorum soddisfatto con la meta’ piu’ uno dei quorum node)
tie-breaker disks (quorum soddisfatto quando almeno un quorum node vede
la meta’ piu’ uno dei tiebreaker disk)
4
Cluster management

E’ definito un primary configuration server, ed un
secondary configuration server opzionale


in caso di inaccessibilita’ di configuration server saranno
precluse le modifiche di configurazione al cluster, e lo startup
di GPFS sui nodi
Tutti i nodi del cluster devono poter eseguire comandi
privilegiati su ciascun altro nodo, senza introdurre
password



e’ possibile utilizzare rsh o ssh
tecnologia che limita la sicurezza e complica il management
del cluster
si possono adottare work-around per limitare l’accesso
reciproco al solo file transfer dei file di configurazione
5
Network Shared Disk


Ogni partizione che dovra’ contenere dati viene configurata
come NSD (ha un nome ed un device file)
Le informazioni relative all’NSD vengono scritte anche sullo
stesso NSD


L’accesso al singolo NSD avviene:



il riconoscimento di un NSD non dipende dal device file name della
partizione fisica, ed e’ riconosciuto da tutti i nodi che hanno accesso
diretto al device
direttamente se il nodo vede il device fisico associato all’NDS
indirettamente tramite export GPFS di un NSD server
Ridondanza per l’accesso all’NSD

il singolo NSD puo’ essere esportato da un server secondario, che in caso
di necessita’ subentra al primario senza perdita di continuita’ di servizio
6
File System

Il file system GPFS e’ costituito da uno o piu’ NSD





POSIX: l’applicativo accede tramite standard file I/O, con
supporto di quota ed ACL (GPFS o compatibili con NFS V4)
a livello di file
rapido recovery: GPFS e’ un logging file system che registra
le operazioni sui metadati
parallelizzazione: le operazioni di I/O vengono realizzate in
striping sugli NSD disponibili, mettendo a disposizione la
banda aggregata e bilanciando il carico tra gli NSD server
dinamicita’: NSD possono essere aggiunti al - e rimossi dal file system on line
affidabilta’: possibilita’ di replicare dati e metadati su diverse
NSD senza punti critici in comune
7
Configuration Manager, File System
Manager e locking distribuito

Il configuration manager viene eletto tra i quorum node
attivi e si occupa di




Il file system manager ha le funzioni di:





controllare il quorum e la consistenza delle configurazioni
recovery dei dischi in seguito a node failure
definizione del file system manager (per ogni fs)
aggiunta/rimozione di dischi
recovery del file system
disk space allocation e quota
definire i token manager
Entrambe le funzionalita’ possono migrare senza
perdita di operativita’ in caso di failure di un manager
8
Locking distribuito

Consistenza di dati e metadati tramite locking
distribuito, mantenuto tramite meccanismi di token





l’accesso al file viene permesso tramite la concessione di un
token, il cui stato risiede sul nodo e sul token manager
un nodo chiede al token manager (attraverso il file system
manager) un token per accedere ad un file
il token manager concede il token o comunica al nodo la lista
dei nodi che hanno un token in conflitto
il nodo contatta i nodi che impediscono l’accesso per
chiedere il rilascio del token
Come per gli altri, anche le funzioni di token manager
possono migrare su altre macchine senza perdita di
funzionalita’
9
File System Export


GPFS nativo: l’accesso al file system per nodi non connessi alla
SAN avviene attraverso i singoli NSD server
Inter-cluster export




NFS export


i volumi di un cluster possono essere esportati a client di altri cluster
si richiede uno scambio di chiavi GPFS (non e’ richiesto l’accesso
privilegiato reciproco)
e’ possibile limitare l’accesso per file system (non per nodi del cluster
remoto) e rimappare l’UID 0
il file system puo’ essere esportato via NFS V3 o NFS V4 (richiede
l’utilizzo di ACL opportuni)
Samba export
10
Layout test di affidabilita’
11
Failure del controller
12
Failure dello switch FC
13
Failure del disk server
14
Upgrade on line



La ridondanza e’ stata sfruttata per operare un upgrade di
versione di GPFS e di kernel senza perdita di funzionalita’
L’infrastruttura costituita da 3 NSD server (e quorum node), con
tutte le NSD esportate via primario e secondario, circa 40 client
GPFS “accetta” la dissincronizzazione delle versioni nello stesso
cluster


il GPFS team di IBM suggerisce caldamente di non protrarre questa
situazione a lungo
La migrazione effettuata con un nodo per volta (con rimozione
dal cluster e successivo reinserimento) non ha portato a perdita
di funzionalita’: ciascun nodo ha mantenuto sempre la visibilita’
dei file system - con la sola eccezione del proprio reboot
15
Test di prestazioni


Sono stati effettuati numerosi test di prestazioni
nell’ambito del gruppo storage di CCR
Sono state confrontate le prestazioni
rispetto ad altri file system (Ext3, Lustre) (solo su
kernel 2.4)
 in configurazioni differenti (parallelizzazione e
distribuzione del carico)

16
Client I/O (write)
MB/s
140.00
NFS (ext3)
NFS (GPFS, 1 srv, 1 NSD)
GPFS (1 srv, 1 NSD)
120.00
121.60
120.00
GPFS (2 srv, 2 NSD)
103.00
100.00
89.40
89.00
88.00
80.00
60.00
40.00
54.80
39.00
42.00
42.80
38.00
32.70
20.00
0.00
1 client
2 clients
4 clients
server e clients: dual Xeon 3 GHz SLC3 GPFS 2.3.0-3
Client I/O (read)
MB/s
250.00
NFS (ext3)
200.00
210.00
209.00
NFS (GPFS, 1 srv, 1 NSD)
GPFS (1 srv, 1 NSD)
GPFS (2 srv, 2 NSD)
150.00
114.00
113.00
116.50
114.60
108.00
100.00
67.00
60.20
50.00
50.00
46.00
46.00
0.00
1 client
2 clients
server e clients: dual Xeon 3 GHz SLC3 GPFS 2.3.0-3
4 clients
Early Parallel File System Test-bed
IBM xseries 346
dual Xeon, 2 GB RAM
4 TB, 2 LUN
17x250 GB
Raid-5 array
IBM
FastT 900
4 TB, 2 LUN (DS 4500)
17x250 GB
Raid-5 array
IBM
FastT 900
4 TB, 2 LUN (DS 4500)
17x250 GB
Raid-5 array
4 TB, 2 LUN
17x250 GB
Raid-5 array
IBM
FastT 900
4 TB, 2 LUN (DS 4500)
17x250 GB
Raid-5 array
3 disk storage
24 TB, 12 LUN
client node
dual Xeon, 2 GB RAM
IBM xseries 346
dual Xeon, 2 GB RAM
Brocade
Fiber
Channel
Switch
IBM xseries 346
dual Xeon, 2 GB RAM
IBM xseries 346
dual Xeon, 2 GB RAM
IBM xseries 346
dual Xeon, 2 GB RAM
IBM xseries 346
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
Gigabit
Ethernet
Switch
client node
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
500 client nodes
4 TB, 2 LUN
17x250 GB
Raid-5 array
client node
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
client node
dual Xeon, 2 GB RAM
6 file system server
thanks to V.Vagnoni
19
4
3,5
GPFS 1 MB x 1000 write
3
GPFS 1 MB x 1000 read
2,5
GPFS 10 MB x 100 write
GPFS 10 MB x 100 read
2
GPFS 100 MB x 10 write
1,5
GPFS 100 MB x10 read
1
GPFS 1GB x 1 write
0,5
GPFS 1 GB x 1 read
80
10
0
12
0
60
40
20
9
7
5
3
0
1
Effective average throughput (Gb/s)
Native GPFS with different file sizes
# of simultaneous read/writes
thanks to V.Vagnoni
20
PHASE 2: Realistic analysis
(II)



8.1 TB of data processed in 7 hours, all 14000 jobs completed
successfully. 500 jobs running simultaneously.
> 3 Gbit/s raw sustained read throughput from the file servers with GPFS
(about 320MByte/s effective I/O throughput).
Write throughput of output data negligible (1 MB/job).
thanks to V.Vagnoni
21
Problemi

Problemi funzionali



GPFS evidenzia un problema di memory map e problemi
legati ad NFS sui kernel 2.4: devono essere installate patch
opportune. I kernel 2.6 sono a posto.
GPFS release > 2.3.0-3 su kernel 2.4 manifesta un problema
nell’export via NFS: l’NFS server non puo’ essere up-to-date,
o deve avere il kernel 2.6.
Prestazioni non brillanti per NSD server con kernel 2.6; altri
problemi di funzionalita’ evidenziati in occasione del recovery
dopo un disk failure.

poca esperienza: analisi da approfondire
22
Problemi-2

Problemi di sicurezza

GPFS richiede la condivisione di accesso privilegiato senza
password tra i nodi di un cluster; sono stati utilizzati due
work-around:



utilizzo di un wrapper sopra ssh per limitare l’accesso dei nodi del
cluster ai soli file di configurazione di GPFS
raggruppamento delle macchine di esperimento in un cluster
separato, ed utilizzo dell’inter-cluster export di GPFS
Problemi di management

La condivisione delle chiavi ssh richiede un meccanismo di
distribuzione delle chiavi ssh attraverso una gestione
centralizzata dei file authorized_keys e known_hosts

** attenzione alle reinstallazioni **
23
Note sulla installazione

Distribuito tramite pacchetti rpm, ma:



richiede l’installazione di release <= 2.3.0-3 prima di fare
upgrade alla release corrente
richiede la compilazione dei moduli GPL dopo editing di un
file di configurazione
Automazioni sviluppate in casa:


“quattorizzazione”: realizzato un rpm per i moduli GPL
precompilati, ed un rpm per aggirare la necessita’ di fare
upgrade
realizzazione di un source rpm per la generazione rapida del
pacchetto rpm dei moduli GPL
24
GPFS @ INFN
Tape Library

INFN-CT






GPFS in produzione sui volumi di
esperimento e volumi GRID
disco FC con 20 TB, due NSD server
3 box con controller 3ware da 1.2 TB/cad
120 GPFS client (WN)
GPFS release 2.3.0-10 su kernel 2.4
Infortrend FC-FC
Infortrend FC-SATA
SAN Switch
Storage Servers
GPFS/NFS/Castor
INFN-TS





GPFS sui volumi della farm centrale e
GRID
disco FC con 22 TB, tre NSD server
connessi alla SAN
30 GPFS client
GPFS release 2.3.0-10 su kernel 2.4
Export dei volumi via NFS
Mail Cluster
AFS Server
Switch Ethernet
Switch Ethernet
Switch Ethernet
FARM
25
GPFS@INFN - 2

INFN-GE






Volumi di farm, esperimento, servizi centrali (home dir, web),
GRID, backup
Disco FC 20 TB + 2 box controller 3ware (6 TB)
Tre cluster (centrale, di esperimento, backup), 5 +2 NSD
server
40 GPFS client sul cluster centrale
Export dei volumi via inter-cluster GPFS, NFS e samba
GPFS release 2.3.0-11 su kernel 2.4 e kernel 2.6 (32 e 64 bit)
sul cluster centrale
26
GPFS @ INFN Genova - schema
27
Accessibilita’ e risorse

GPFS e’ un prodotto commerciale di IBM




last release: 3.1 (aprile 2006)
distribuito per AIX e linux RH/SUSE
Fornito gratuitamente (assieme ad altro: DB2, Tivoli, Rational, CSM,
…) attraverso il programma “IBM University”
(http://www.ibm.com/university)
Distribuzione via rete
http://techsupport.services.ibm.com/server/gpfs/download/home.html
a partire dalla release 2.3.0-7, installabili solo come upgrade


per l’installazione e’ necessario iscriversi al programma University e
richiedere ad IBM i CD della release base 2.3.0-1
Risorse



IBM fornisce contratti di supporto sotto condizioni stringenti: in corso il
tentativo di definire un contratto di manutenzione per (le) installazioni
INFN
Disponibili ampia documentazione e FAQ in rete
Esiste una mailing list abbastanza attiva del San Diego Super Computing
(https://lists.sdsc.edu/mailman/listinfo.cgi/gpfs-general)
28
Conclusioni

GPFS si presenta come una soluzione interessante





Buone prestazioni, che migliorano grazie alla parallelizzazione
che puo’ fornire con semplicita’ anche il bilanciamento di
carico
Ottime caratteristiche di affidabilita’, che si sfruttano al
meglio in una infrastruttura SAN
POSIX I/O: puo’ essere utilizzato dalle applicazioni senza
adattamenti
scalabile: supportato da IBM fino a 1024 nodi, ma esistono
gia’ in produzione installazioni di oltre 2000 nodi
Funzionalita’ come la duplicazione di dati e metadati,
supporto per ACL e quota ne fanno una soluzione
interessante anche per file system general purpose (home dir)
29