Da circa 10 anni il calcolo@LNL fornisce agli utenti dei labs, che ne facciano richiesta, un servizio di storage via NFS. Come T2 viene fornito da qualche anno un servizio storage agli utenti CMS, accedibile dalle UI, via Lustre
Esperienza NFS Rigido, legato alla fisicita delle partizioni => poco pratico nell’ espansione, namespace frammentato; espandibile ma migrazione dati piuttosto onerosa Esperienza Lustre Intimamente legato al kernel delle macchine client: onerosa manutenzione; difficile da integrare in OS non omogenei (noi esperienza solo con RHEL like); manutenzione immagini VM (esperienza WNodes@LNL) Scartando GPFS ancora piu complesso di lustre => candidato naturale GlusterFS: facile integrazione, export sia NFS che SMB, namespace unico e MOLTO altro sulla carta (meno performante di Lustre per quel poco provato da noi). GlusterFS cmqe non e’ la panacea: noti comportamenti ‘bizzarri’ => costringe a sfruttare solo funzionalita “base” [es. no ridondanza] LNL ha mandato in produzione da poco un unico server con 3 partizioni per un totale di 55TB (v3.4.1). Previsione di migrare a step la parte NFS in Gluster. Per ora poca attivita. Abbiamo anche un testbed con 3 server e diverse partizioni per un totale di circa 100TB (attualmente alla 3.3.1) Alternativa possibile: CephFS [il modulo fuse dicono essere pessimo]; pero ad esempio NON supportato SL5
Ma il vero GRANDE PROBLEMA e’ rappresentato dal mapping UID/GID degli utenti: attualmente gestione manuale (no LDAP unico) Questo poi va integrato con le problematiche AAI che si stanno sviluppando