Status report Alessandro Brunengo Gruppo storage Status report Alessandro Brunengo 05/10/2010 CCR ottobre 2010 - Roma

Attivita’ 2009/2010 Analisi di configurazione storage per un sito Grid basato su StoRM/GPFS al fine integrare lo storage Grid con lo storage destinato ad una facility di analisi (nello specifico al Tier3 di Atlas), e test di prestazioni (Genova, Milano, Trieste). Analisi delle problematiche connesse all'utilizzo di server di disco connessi a 10GE in funzione dei limiti sulle risorse hardware degli switch di rete (Genova, Pisa, Trieste). Analisi delle prestazioni comparative tra file system (GPFS, Lustre, AFS) in condizioni di accesso realistico (applicazioni di esperimenti LHC) in collaborazione con lo Storage Working Group di HEPiX (Bari). Analisi della possibilita' di utilizzare il file system distribuito hadoop per una piccola facility di analisi tipo Tier3 (Bari). Organizzazione corso di formazione su interfacce SRM (CNAF, Genova, Bari). Technology tracking e supporto alle commissioni referee per il dimensionamento dei finanziamenti per lo storage. 05/10/2010 CCR ottobre 2010 - Roma

Storage per il T3 (Atlas) Lavoro svolto in collaborazione con il gruppo di studio T3 task force di Atlas Italia Esigenze sullo storage: disponibilita’ di area software condivisa con ambiente Grid accesso in lettura agli space token di nodi di interattivo e di batch locale (dedicati al T3) disponibilita’ sui nodi di interattivo delle utility di management dei dati (DQ2/SRM client) 05/10/2010 CCR ottobre 2010 - Roma

Implementazione L’utilizzo di file system distribuito (GPFS) e StoRM permette di soddisfare le esigenze in modo semplice unico file system per space token, aree locali e area software (fileset con controllo di quota) space token (gestiti via StoRM) dotati di ACL per l’accesso RO al gruppo di utenti T3 parametro di configurazione del back end di StoRM user replicati dal database di sezione area software esportata via CNFS a tutti i nodi (grid e locali) con update automatico (De Salvo) 05/10/2010 CCR ottobre 2010 - Roma

Layout accesso allo storage 05/10/2010 CCR ottobre 2010 - Roma

More features (integrazione) Utenti del T3 (locali) hanno account replicato sulle macchine grid i job Grid con certificato di utente locale vengono mappati su tali account in questo modo i job Grid “possono” accedere alle aree locali (non Grid) del T3 via posix L’utente T3 puo’ quindi sottomettere indifferentemente batch locale o via Grid i WN per Grid e per il batch locale sono identici le risorse possono essere spostate da una all’altra funzione via LSF (sharing dinamico, statico, o misto) Le user interface per l’interattivo hanno uguale accesso allo storage, e sono client del batch system e user interface di Grid 05/10/2010 CCR ottobre 2010 - Roma

Stato dell’arte Test di funzionalita’ completati con successo Da fare nessun problema di accesso ai volumi sia in locale che via job Grid Da fare test di prestazioni (queste dipendono dal sistema di storage sottostante) con batch job locali e via HammerCloud test di prestazioni per l’interattivo (con Proof) 05/10/2010 CCR ottobre 2010 - Roma

Disk server 10 GE Numerosi problemi hanno rallentato i test scheda Intel su server DELL PowerEdge R710 ha limite artificiale in uscita a ~700 MB/s imposto con particolare configurazione del BIOS da DELL per prevenire un problema della scheda che manda in crash il sistema ci sono voluti 4 mesi di interazione con il supporto DELL per avere la sostituzione con schede Broadcom ed acquisto di una licenza RHEL! problemi preoccupanti di prestazioni verso client connessi a 1 GE 05/10/2010 CCR ottobre 2010 - Roma

Layout dei test Slide di A.Tirel 05/10/2010 CCR ottobre 2010 - Roma

Collo di bottiglia e controllo di flusso TCP Un flusso da server a 10GE verso client a 1 GE attraversa un collo di bottiglia nel nostro caso, dentro lo switch X350 La perdita di pacchetti determina lato client la richiesta di ritrasmissione il server ritrasmette ed abbatte la finestra di congestione, ripartendo con l’algoritmo slow start in diverse modalita’ in funzione dell’algoritmo di controllo della congestione (/proc/sys/net/ipv4/tcp_congestion_control) Mediamente il flusso si deve attestare ad un valore pari a quasi 1 Gbps 05/10/2010 CCR ottobre 2010 - Roma

GPFS e finestre TCP ampie La configurazione ottimale (suggerita) per l’utilizzo di schede 10 GE e’ simile a quella suggerita per l’utilizzo di GPFS: ampie finestre per il TCP In questa configurazione, lasciando gli altri parametri al default, si misurano prestazioni bassissime nel throughput server-client variabili tra i 50 ed i 500 Mbps 05/10/2010 CCR ottobre 2010 - Roma

Trasferimento verso singolo client 05/10/2010 CCR ottobre 2010 - Roma

Timeout TCP: perche’ L’evento che abbatte le prestazioni e’ la perdita completa di una finestra TCP nello switch il client dopo l’ultimo riscontro non riceve piu’ nulla il server ha esaurito la finestra ed aspetta un riscontro la comunicazione riprende dopo un timeout di 0.2 secondi, con il server che ritrasmette da capo questo evento puo’ accadere anche piu’ volte al secondo durante l’attesa non passano dati L’utilizzo di jumbo frame peggiora la situazione rende gli eventi piu’ frequenti Puo’ essere un problema dello switch o del TCP 05/10/2010 CCR ottobre 2010 - Roma

Timeout: dettaglio 05/10/2010 CCR ottobre 2010 - Roma

Soluzioni (o work-around?) Tcp Segmentation Offload da disabilitare senza TSO gli eventi di timeout si riducono drasticamente Alternativa: utilizzo di diverso algoritmo di controllo della congestione (vegas, ma meno perfomante su LAN) Si evidenzia un comportamento anormale degli switch X350 interazione con il supporto molto evanescente dopo 3 mesi hanno detto che e’ normale perdere pacchetti... puo’ essere un limite di gestione della congestione nei buffer interni allo switch si devono fare test significativi utilizzando switch di altri vendor per premere su Extreme Networks E’ un problema di rete: appuntamento con il netgroup... 05/10/2010 CCR ottobre 2010 - Roma

Effetto della disattivazione del TSO 05/10/2010 CCR ottobre 2010 - Roma

Hadoop: test Geographical distributed Storage Element Hadoop provides: automatic replica management and storage distribution rack awareness advanced (and pluggable) placement policies good monitoring features Why don’t we try to use it on a WAN environment to see how it works? The concept of rack is used to identify a Site We need a performant WAN link between site It could provide good reliability of data... also in case a whole site become temporarily unavailable

Hadoop: test Geographical distributed Storage Element Bari Naples

Hadoop test WORK IN PROGRESS Geographical distributed Storage Element Remote test: Network bandwidth: ~600 Mbit/s during a read operation the user do no see errors also if the whole Naples site goes down suddenly Writing & Replicating data (2 clients): ~40MB/s sustained Reading data (2 Client): ~100MB/s sustained Local test: CPU efficiency is low with CMS analysis jobs (~ 50-60%) Performance test will be carried on, to try to improve CPU efficiency in CMS analysis jobs xrootd-to-hadoop interface recent version on kernel and fuse module (the standard SLC5 kernel is not the right choice for fuse)

Attivita’ 2011 Completamento dei lavori in corso: storage per il Tier3 problemi sul flusso tra server 10GE e client ad 1 Ge Prosecuzione della collaborazione con lo storage working group di HEPiX per lo studio delle prestazioni dei file system E' prevista una nuova attivita' sull'analisi di funzionalita' e prestazioni di dischi in tecnologia SSD. Si prevede di organizzare almeno due corsi di formazione, uno specifico su GPFS e l'altro piu' generale sulle tecnologie di storage per Grid. Proseguira' l'attivita' di technology tracking e supporto per chiunque ne abbia bisogno. 05/10/2010 CCR ottobre 2010 - Roma

Test tecnologia SSD Sperimentazione da realizzare a Bari Diverse opzioni per l’utilizzo dei dischi SSD intero file system (solo a scopo comparativo per i test successivi) area SSD dedicata ai metadati (per i file system che supportano la separazione) area SSD come cache del file system attualmente supportata solo su opensolaris/ZFS in corso di sviluppo moduli opportuni per il kernel di linux Si vuole inizialmente realizzare un testbed con un server di disco e 6-8 HD SSD da 256 GB chiesti 8 Keuro di finanziamento 05/10/2010 CCR ottobre 2010 - Roma