CCR - Frascati 29 settembre 2008 Gruppo storage CCR Status Report Alessandro Brunengo

Test comparativi su soluzioni di storage Test di prestazioni realistico su job di analisi dei dati da parte di utenti di esperimenti LHC Test di prestazioni realistico su job di analisi dei dati da parte di utenti di esperimenti LHC utilizzo del framework dell’esperimento, senza diretto controllo da parte dell’utente (condizioni di produzione)utilizzo del framework dell’esperimento, senza diretto controllo da parte dell’utente (condizioni di produzione) Trovare la migliore configurazione dello storage di un tipico Tier2 LHC Trovare la migliore configurazione dello storage di un tipico Tier2 LHC Valutando in modo verticale tutti gli aspetti di un sistema di storageValutando in modo verticale tutti gli aspetti di un sistema di storage Partendo dall’hardware fino al solftware di gestione dello storage Partendo dall’hardware fino al solftware di gestione dello storage

Strumenti sotto test Hardware: Hardware: SUN: JBOD (J4500) (48 dischi)SUN: JBOD (J4500) (48 dischi) NexSAN: SataBeast (42 dischi), SASBoy (14 dischi)NexSAN: SataBeast (42 dischi), SASBoy (14 dischi) Xryratex: JBOD 2x24 dischi e 16 dischiXryratex: JBOD 2x24 dischi e 16 dischi Sistema operativo: Sistema operativo: SL5, Debian, OpenSolarisSL5, Debian, OpenSolaris File system: ZFS, XFS (e Lustre) File system: ZFS, XFS (e Lustre) Storage Management Software: Storage Management Software: dCache, LUSTRE/StoRMdCache, LUSTRE/StoRM

Stato dei test Tutto l’hardware è stato acquisito Tutto l’hardware è stato acquisito Sono già in corso i test sui diversi sistemi operativi e file-system Sono già in corso i test sui diversi sistemi operativi e file-system Già effettuati diversi test per guadagnare esperienza con LUSTRE Già effettuati diversi test per guadagnare esperienza con LUSTRE Lustre in test anche sul T2 di Torino Lustre in test anche sul T2 di Torino Risultati ancora preliminari (troppo per mostrarli) Risultati ancora preliminari (troppo per mostrarli)

Collaborazione con Hepix Installato il framework di CMS e eseguiti job reali di analisi su dati reali Installato il framework di CMS e eseguiti job reali di analisi su dati reali Risultati molto interessanti presentati ad Hepix a taiwan: Risultati molto interessanti presentati ad Hepix a taiwan: Lustre sembra performare molto meglio degli altri Lustre sembra performare molto meglio degli altri Molto probabile un problema di librerie nei framework di esperimento (vedi note slide precedenti) Molto probabile un problema di librerie nei framework di esperimento (vedi note slide precedenti) Partecipazione al set-up e test nel gruppo dei file- system (coordinato da Andrei Maslennikov ) Partecipazione al set-up e test nel gruppo dei file- system (coordinato da Andrei Maslennikov )

GPFS: problemi su pattern non sequenzizale di molti file piccoli ► Si e’ evidenziato un problema nell’export di aree software via GPFS  accesso a numerosi file di piccole/medie dimensioni ► in compilazione ► in esecuzione: load delle shared libraries (per Atlas e CMS: accesso a > 1 GB di dati sparsi su un grande numero di file) ► La cache di GPFS si riempie e si svuota in continuazione  alto load dovuto ad mmfsd  bassissime prestazioni (peggiori rispetto ad un file system locale ext3 o XFS)

Gestione della cache ► aumentare il pagepool sui client non e’ una soluzione  il client GPFS richiede di allocare la RAM dedicata al caching, che non sara’ piu’ disponibile alle applicazioni  a differenza del caching del kernel, che usa la RAM se disponibile, e la libera se necessario  in condizioni di richieste di RAM eccessive dai job, mmfsd viene ucciso dal kernel, e la macchina si blocca

Possibile soluzione ► Export via NFS della porzione di file system GPFS dedicata al software  GPFS permette di implementare un meccanismo di export via “Clustered NFS” che realizza il failover sul server NFS ► Si possono sfruttare meglio le cache  la cache del kernel sul client  la cache di GPFS opportunamente configurata sul server NFS (client GPFS) ► tuning dei parametri pagepool, maxFilesToCache ed altri sulle macchine del cluster NFS ► NFS server deve essere dedicato

Test in corso ► Prime prove con questa configurazione molto positive a Genova  NFS server con pagepool 2.0 GB, maxFilesToCache  execution time di job di Atlas passano da 653 sec (100 sec user CPU) a 162 sec (100 sec user CPU) ► In corso analisi sul tuning dei parametri di configurazione delle cache per ottenere una soluzione ottimale ► Soluzione attualmente implementata al Tier1  non ho numeri, ma la soluzione e’ dichiarata soddisfacente

Test su 10GE ► I test sono stati sospesi per mancanza di tempo e di hardware ► Si spera di trovare entrambi dopo l’estate  hardware in prestito, in particolare il disco