General Parallel File System: caratteristiche, prestazioni ed esempi di utilizzo in produzione

1. General Parallel File System: caratteristiche, prestazioni ed esempi di utilizzo in produzione Alessandro Brunengo - Sezione INFN di Genova Workshop CCR Otranto - maggio 2006

2. 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

3. 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

4. Cluster • Nodo GPFS: singolo sistema operativo su cui gira il software GPFS • moduli del kernel • utility di management del file system • utility di management del cluster • Cluster GPFS: insieme di nodi che condividono le configurazioni e l’accesso ai file system, che possono avere funzioni di • 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)

5. 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

6. 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 • 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 • L’accesso al singolo NSD avviene: • 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

7. 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

8. Configuration Manager, File System Manager e locking distribuito • Il configuration manager viene eletto tra i quorum node attivi e si occupa 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) • Il file system manager ha le funzioni di: • 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

9. 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’

10. 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 • 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 • NFS export • il file system puo’ essere esportato via NFS V3 o NFS V4 (richiede l’utilizzo di ACL opportuni) • Samba export

11. Layout test di affidabilita’

12. Failure del controller

13. Failure dello switch FC

14. Failure del disk server

15. 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

16. 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)

17. server e clients: dual Xeon 3 GHz SLC3 GPFS 2.3.0-3

18. server e clients: dual Xeon 3 GHz SLC3 GPFS 2.3.0-3

19. IBM xseries 346dual Xeon, 2 GB RAM 4 TB, 2 LUN17x250 GBRaid-5 array 4 TB, 2 LUN17x250 GBRaid-5 array 4 TB, 2 LUN17x250 GBRaid-5 array IBM FastT 900 (DS 4500) IBM FastT 900 (DS 4500) IBM FastT 900 (DS 4500) IBM xseries 346dual Xeon, 2 GB RAM 4 TB, 2 LUN17x250 GBRaid-5 array 4 TB, 2 LUN17x250 GBRaid-5 array 4 TB, 2 LUN17x250 GBRaid-5 array IBM xseries 346dual Xeon, 2 GB RAM IBM xseries 346dual Xeon, 2 GB RAM IBM xseries 346dual Xeon, 2 GB RAM IBM xseries 346dual Xeon, 2 GB RAM Early Parallel File System Test-bed client nodedual Xeon, 2 GB RAM client nodedual Xeon, 2 GB RAM client nodedual Xeon, 2 GB RAM 500 client nodes client nodedual Xeon, 2 GB RAM BrocadeFiberChannelSwitch client nodedual Xeon, 2 GB RAM GigabitEthernetSwitch client nodedual Xeon, 2 GB RAM client nodedual Xeon, 2 GB RAM client nodedual Xeon, 2 GB RAM client nodedual Xeon, 2 GB RAM 3 disk storage24 TB, 12 LUN 6 file system server thanks to V.Vagnoni

20. Native GPFS with different file sizes Effective average throughput (Gb/s) # of simultaneous read/writes thanks to V.Vagnoni

21. 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

22. 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

23. 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 **

24. 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

25. GPFS @ INFN • 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 • 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

26. 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

27. GPFS @ INFN Genova - schema

28. 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 retehttp://techsupport.services.ibm.com/server/gpfs/download/home.htmla 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)

29. 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)