Alessandro Tirel - Sezione di Trieste Storage servers & TCP Tuning Proposta di studio delle problematiche connesse alla fornitura di servizi di storage.

Presentazione sul tema: "Alessandro Tirel - Sezione di Trieste Storage servers & TCP Tuning Proposta di studio delle problematiche connesse alla fornitura di servizi di storage."— Transcript della presentazione:

1 Alessandro Tirel - Sezione di Trieste Storage servers & TCP Tuning Proposta di studio delle problematiche connesse alla fornitura di servizi di storage basati sul protocollo Tcp/Ip

2 Frascati - Workshop CCR WGs2 10 dicembre 2007 Premessa Con la diffusione oramai totale di schede gigabit ethernet è venuta a mancare la differenza di prestazioni tra server e client. L’utilizzo sui server di schede a 10 gigabit comportano costi importanti in termini di aggiornamento di infrastruttura. Tuttavia in ambienti come le attuali farm di calcolo diviene indispensabile aumentare la capacità dei server di trasferire le potenzialità dei sistemi di storage verso i client.

3 Frascati - Workshop CCR WGs3 10 dicembre 2007 Bonding Per aumentare le capacità di trasferimento dati dei server esiste una soluzione a costo zero rappresentata dalla possibilità di accorpare due o più interfacce gigabit per creare un’ unica interfaccia virtuale. In ambiente linux questa operazione prende il nome di bonding. Questo modulo del kernel permette di utilizzare vari algoritmi per la gestione del traffico di rete

4 Frascati - Workshop CCR WGs4 10 dicembre 2007 LACP o 802.3ad Uno degli algoritmi utilizzabili è il Link Aggregation Control Protocol (802.3ad). Questo algoritmo viene consigliato nel caso di impiego con NSD servers (GPFS) o iSCSI target. La sua prerogativa è di minimizzare il numero di pacchetti out-of-order poiché nella trasmissione del traffico applica la seguente formula: ((MAC source) XOR (MAC destination)) MOD n. slave Questo fa si che il ‘colloquio’ tra il server ed il client avvenga utilizzando sempre la stessa interfaccia del bonding. Per ottenere il massimo risultato sono stati modificati i MAC address in modo da renderli consecutivi. Tuttavia dall’esperienza fatta sembra che lo switch ed il modulo di bonding ottengano risultati diversi nell’applicare la formula??

5 Frascati - Workshop CCR WGs5 10 dicembre 2007 Descrizione del testbed Il testbed costruito per effettuare i test di iSCSI/GPFS è formato da 16 client (gcltxx), due NSD server (gsrvxx) ed un target iSCSI (iscsi-tg). Sono macchine principalmente con Xeon 5xxx, solo quattro client (gclt13-16) utilizzano processori AMD Opteron. Il kernel utilizzato è il 2.6.9-55.0.9.ELsmp sui nodi del cluster mentre l’iSCSI target utilizza una distribuzione chiamata Openfiler con kernel 2.6.19.7-0.3.smp. Tutte le macchine hanno almeno 4 GB di memoria. Le schede ethernet sono Intel ad eccezione dei client con Opteron e della scheda aggiuntiva sul server gsrv01, che sono Broadcom. Le aggregazioni sono state create sui due nodi dotati di risorse di storage (gsrv01 e iscsi-tg). Sul primo sono state accorpate due distinte schede costituite dalle due porte Intel sulla scheda madre più le due presenti sulla scheda Broadcom. Sul secondo invece le quattro porte risiedono su una scheda Intel 1000 PT Quad. Lo switch Summit X450e-48p (XOS 12.0.1.11) a cui è connesso l’intero sistema è stato configurato opportunamente creando le VLAN, configurando le porte con il supporto jumbo frame e definendo gli aggregati.

6 Frascati - Workshop CCR WGs6 10 dicembre 2007 Testbed

7 Frascati - Workshop CCR WGs7 10 dicembre 2007 Test effettuati Per poter valutare le prestazioni in termini di I/O di GPFS ho pensato che fosse opportuno conoscere prima quelle della rete, in particolare in caso di trasferimento concorrenti per questo ho utilizzato iperf per effettuare i test. Nello specifico i comandi utilizzati sono stati i seguenti: Test unidirezionale iperf –c server –t 60 –l 256K –r Test bidirezionale iperf –c server –t 60 –l 256K –d Nel primo caso con unidirezionale si intende prima in un verso e poi nell’altro, mentre nel secondo i due flussi sono contemporanei. Il flag –l indica la grandezza del buffer da trasferire, poiché stiamo parlando di I/O, i blocchi da trasferire sono solitamente ‘importanti’ ed inoltre permette di osservare anche il comportamento nel caso di utilizzo di diverse MTU.

8 Frascati - Workshop CCR WGs8 10 dicembre 2007 Risultati ottenuti

9 Frascati - Workshop CCR WGs9 10 dicembre 2007

10 Frascati - Workshop CCR WGs10 10 dicembre 2007 Modifica dei parametri del kernel I varie pubblicazioni relative a GPFS ed iSCSI viene consigliato di modificare i parametri del kernel relativi ai buffer di rete ed in particolare del tcp. Come prova sono stati applicati i seguenti parametri: gsrv01: net.core.rmem_default = 262144 net.core.rmem_max = 8388608 net.core.wmem_default = 262144 net.core.wmem_max = 8388608 net.ipv4.tcp_rmem = 8192 262144 4194304 net.ipv4.tcp_wmem = 8192 262144 4194304 iscsi-tg: net.core.rmem_default = 1048576 net.core.rmem_max = 1048576 net.core.wmem_default = 1048576 net.core.wmem_max = 1048576 net.ipv4.tcp_rmem = 1048576 1048576 1048576 net.ipv4.tcp_wmem = 1048576 1048576 1048576 net.ipv4.tcp_mem = 1048576 1048576 1048576 Nel caso del target iSCSI è lo stesso script del daemon che provvede alla modifica dei parametri.

11 Frascati - Workshop CCR WGs11 10 dicembre 2007 Risultati ottenuti 2

12 Frascati - Workshop CCR WGs12 10 dicembre 2007

13 Frascati - Workshop CCR WGs13 10 dicembre 2007 Applicazione del modello a GPFS Uno dei punti definiti nella scheda del progetto iSCSI era quello di testare il protocollo quando si utilizza GPFS come filesystem. In particolare si volevano chiarire i seguenti punti: funzionalità scalabilità performance

14 Frascati - Workshop CCR WGs14 10 dicembre 2007 Fibre Channel* vs iSCSI In questo test si sono messi a confronto le due tipologie del cluster GPFS ovvero quella con lo storage direttamente connesso ai client (iSCSI) e quella che utilizza i server NSD (Fibre Channel). Per effettuare i test è stato utilizzato gpfsperf-mpi, fornita come software accessorio al pacchetto GPFS.

15 Frascati - Workshop CCR WGs15 10 dicembre 2007

16 Frascati - Workshop CCR WGs16 10 dicembre 2007

17 Frascati - Workshop CCR WGs17 10 dicembre 2007

18 Frascati - Workshop CCR WGs18 10 dicembre 2007

19 Frascati - Workshop CCR WGs19 10 dicembre 2007 Conclusioni In gioco ci sono molti fattori che determinano le performance del sistema e cioè: caratteristiche della scheda ethernet (funzioni di tcp off-loading, buffer interni) algoritmo di bonding (efficienza, conformità allo standard*) TCP (window size, congestione, pacchetti ACK, buffer) E` chiaro che non si riuscirà ad ottenere trasferimenti perfettamente bilanciati e vicino alle velocità teoriche ma cercare di ottenere risultati migliori, si spera, sia sempre possibile. Per quanto riguarda implementazione di iSCSI in ambiente GPFS appare evidente che la soluzione con NSD server tradizionali garantisce prestazioni migliori ed inoltre e` supportata dal filesystem.