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

Test storage su 10GE ► Scopo: valutare la capacita’ di un singolo server di servire un flusso concomitante a 10 Gbps da/verso il disco e da/verso la rete ► Misure di  test di rete (RAM-to-RAM)  test locale di accesso al disco  test remoto di accesso a disco, via GPFS e dCache CCR - Frascati 29 settembre

CCR - Frascati 29 settembre GE: layout del testbed

10 GE: configurazione hardware ► Server  biprocessore dual core AMD GB RAM – SLC4  8 processori dual core AMD GB RAM – SLC4 ► Client  17 biprocessor dual core AMD GB RAM – SLC4 ► Disco  2 Infortrend Eonstore S16F-R1430-M5, 32 * 750 GB HD SATA2 cad. ► HBA FC: 2 * QLE2462 (dual head 4 Gbps) ► HBA 10GE: Myrinet ► Switch: Extreme Networks Summit 400 con interfaccia 10 GE CCR - Frascati 29 settembre

10 GE: test rete (MTU)

10GE: GPFS read remoto Test in lettura via GPFS da WN: a sinistra il throughput (MB/s), a destra la CPU del server (%) I primi 4 test con 2, 4, 8 e 12 flussi contemporanei; seguono tre test non significativi, quindi nuovi test con 8, 10 e 12 flussi concomitanti dopo aver modificato le impostazioni dei parametri del kernel (come da manuale GPFS, essenziamente buffer). La modifica migliora notevolmente le prestazioni (fino a MB/s) con scarico sulla CPU (che resta sempre 40% idle)

10GE: GPFS write remoto Test in scrittura via GPFS da WN con 8, 10 e 12 flussi concomitanti. Le prestazioni sono costanti intorno ai 500 MB/s, e sono equivalenti alle prestazioni che si ottengono in scrittura locale. La CPU non e’ mai satura.

10 GE: test con dCache 1.test con ddcp, con 150 movers e 150 processi client 2.idem, con 150 movers ma solo 20 processi client 3.cmssw (150 job) senza output, con accesso al FS locale (quindi via GPFS) 4.come 3, ma con accesso via dcap (che trasferisce solo una parte dei dati letti) 5.come 3, ma scrive una replica del file di dati in locale (quindi prima copia tutto il file) 6.come 4, ma scrive in locale una replica 7.come 6 ma facendo girare il btagging (fa un po’ di CPU) 8.replica del test 5, prolungata nel tempo

10 GE: note sul test con dcache ► Nel test 1 si vede che, con molti processi, il throughput verso lo storage sia molto piu’ elevato rispetto a quello verso la rete; con soli 20 job non accade. In entrambi i casi si fanno ~ 600 MB/s di throughput utile verso i WN. Comportamento da capire. ► Il confronto tra 3 e 4 mostra come, non dovendo occuparsi di buttare tutto sulla rete, il server abbia un accesso piu’ elevato verso i dischi (sembra che nei casi precedenti gli accessi vadano in competizione)  in 4 l’evento viene letto, ma poi viene passato all’applicativo solo la porzione dati di interesse; se l’accesso avviene via dcap sulla rete passano pochi dati, mentre se l’accesso avviene tramite file (GPFS) ovviamente tutto il file arriva al WN su cui gira l’applicativo) ► I test 5 e 6 sembrano andare come 3 e 4, e 7 come 6. ► In 3 e 5 il throughput e’ un po’ piu’ basso (~500 MB/s) ma la CPU e’ scarica (perche?)

10 GE: analisi andamento anomalo Primo test: lanciati 150 job con 20 movers attivi; poi sono stati incrementati i movers gradualmente Secondo test: 150 job con 150 mover; poi sono stati uccisi job gradualmente, fino a lasciarne circa 45 (numero per il quale non di manifesta il comportamento strano) Terzo e quarto test: non significativo (disabilitata la funzione read ahead su dcache) Quinto test: eseguiti iperf bidirezionali contemporanei, quindi uccisi i processi che generano traffico entrante

10 GE: considerazioni ► I test hanno mostrato alcune cose  a 10 GE l’MTU a 1500 e’ limitante (troppi Iops): si devono utilizzare i jumbo frame  (non mostrato): l’accesso bidirezionale abbassa le prestazioni (~ 6+7 Gbps) in modo asimmetrico  le operazioni di I/O da disco e verso la rete vanno in competizione: qualche limite di risorse, da indagare (vedi anche punto precedente)  l’accesso al file system parallelo offre circa 500 MB/s in scrittura (limite del disco) e 700 MB/s in lettura, mentre in locale va oltre i 1000 MB/s (problemi di ottimizzaione di GPFS?)  l’accesso via dCache raggiunge i MB/s con ~50 processi concomitanti; oltre si manifesta un problema che riduce le prestazioni (pre-fetching non ottimale di GPFS?) CCR - Frascati 29 settembre

Disk server e bonding ► Alternativa all’utilizzo della tecnologia 10GE ► Aumento del throughput del disk server via link aggregation (bonding)  le N interfacce GE del server utilizzate come unica interfaccia virtuale a N Gbps ► Valutare le funzionalita’ e le prestazioni su infrastruttura che utilizza GPFS  aumento di prestazioni e failover sul gruppo di interfacce aggregate CCR - Frascati 29 settembre

Protocolli ed algoritmo ► Protocolli: bonding statico vs 802.3ad link aggregation  il secondo e’ un vero protocollo che protegge la rete da errori di configurazione ► Algoritmi: scelta dell’interfaccia di uscita del frame  round robin: bilanciamento ottimo ma potenziale mancanza di ordinamento dei frame  XOR sugli indirizzi L2: potenziale sbilanciamento (sempre per connessioni ruotate)  XOR su indirizzi (L2 e L3) o (L2, L3 e L4): soluzioni migliori per garantire ordinamento e bilanciamento CCR - Frascati 29 settembre

bonding testbed CCR - Frascati 29 settembre Test sulla infrastruttura in produzione a Genova Due server in bonding (2 * 1 GE cad.) su core switch Black Diamond 8810 ed N client connessi in GE sul core switch Sistema disco connesso via SAN (2 link FC a 4 Gbps per server), 4 file system GPFS costituiti da 2 NSD ciascuno serviti in modo bilanciato su path differenti risultati:  prestazioni OK (traffico unidirezionale)  failover OK  bilanciamento OK

bonding: prestazioni in lettura CCR - Frascati 29 settembre ► Uno sbilanciamento della dimensione degli NSD (esempio di sinistra) comporta una diminuzione dell’efficienza ► Con 4 accessi e bilanciamento degli NSD si raggiungono i 400 MB/s (~3.2 Gbps, su un massimo teorico di 4 Gbps)

bonding: aggregato e cache CCR - Frascati 29 settembre ► A sinistra: aggregato di accesso da 16 client verso 4 file system serviti dai due server ► A destra: sedici accessi concomitanti sullo stesso file (di un file system con NSD simmetrici): il caching migliora le prestazioni da 450 a 475 MB/s (quindi prima un limite sul disco?)

bonding: considerazioni ► la tecnologia e’ valida, sia per prestazioni che per funzionalita’ di bilanciamento e failover  si raggiunge quasi il limite teorico di 2 Gbps su ciascun server ► la scelta dell’algoritmo di selezione della interfaccia deve essere opportuno per poter bilanciare (non solo L2!) ► la configurazione del file system (parallelo) deve essere opportuna per non perdere di prestazioni  bilanciamento di path verso la SAN, verso la rete, dimensione degli NSD CCR - Frascati 29 settembre

Test sui file system ► In collaborazione con lo storage group di HEPiX  attualmente numeri poco indicativi (test su sistemi ad 1 Gbps) presentati all’ultimo meeting  sono in corso test piu’ significativi CCR - Frascati 29 settembre

ZFS: Thumper ► Sono in corso test si prestazioni via dCache su ZFS sul Thumper (con Solaris)  test effettuati con job di analisi di CMS ► rilevante differenza rispetto ad accessi puramente sequenziali ► evidenza di accesso parzialmente randomico e non ottimizzato che limitano le prestazioni  numeri non eccellenti (100 MB/s contro i 300 MB/s promessi dal Thumper)  richiede una ottimizzazione di configurazizone del file system ancora non pienamente compresa ► numero di volumi Raid (software), block size per il read ahead,... CCR - Frascati 29 settembre

Altre attivita’ ► Technology tracking ► Documento su architetture per T2 ► Documento costi ► Consulenze generiche  in procinto di acquisti mi telefonano... ► ► Corso su installazioni SRM CCR - Frascati 29 settembre

Attivita’ future ► bonding: verifica prestazioni su accesso bidirezionale  prove gia’ fatte (Tirel) mostrano potenziali cali di prestazioni: da indagare ► 10 GE: effettuare prove per evidenziare e capire i limiti  serve uno storage non limitante  vanno approfonditi i problemi evidenziati con molti movers di dCache (problema di GPFS? altro?) ► Thor (Thumper++): promette molto, in particolare e’ interessante  analizzare piu’ a fondo i limiti trovati con job di analisi (non e’ stato possibile provare configurazioni ottimizzate)  provare dischi SSD utilizzabili come cache di secondo livello per ZFS CCR - Frascati 29 settembre