Strategia di risoluzione dei problemi per prestazioni iSCSI / NFS molto scadenti

Abbiamo un nuovo Synology RS3412RPxs che offre target iSCSI a tre box Windows 2008 R2 e NFS a un box OpenBSD 5.0.

Accedere a RS3412 con ssh e leggere / scrivere sia piccoli file che file da 6 GB usando dd e varie dimensioni di blocco mostra grandi prestazioni di I / O del disco.

Usando dd o iometer sui client iSCSI / NFS, raggiungiamo fino a 20 Mbps (non è un errore di battitura. Venti Mbps). Speravamo in qualche modo di sfruttare meglio le schede di rete multiple Gbit in Synology.

Ho verificato lo switch e la configurazione della porta NIC è impostata su gigabit, non sulla negoziazione automatica. Abbiamo provato con e senza Jumboframes senza alcuna differenza. Ho verificato con ping che l'MTU è attualmente 9000. Sono stati implementati due aggiornamenti del firmware.

Proverò il collegamento diretto tra la destinazione iSCSI e l'iniziatore per escludere problemi di commutazione, ma quali sono le altre opzioni?

Se rompo wirehark / tcpdump, cosa cerco?

Come sembra essere il tema comune qui, dai un'altra occhiata alle impostazioni di controllo del flusso sugli interruttori. Se gli switch hanno statistiche contatore Ethernet, guardali e vedi se c'è un gran numero di frame PAUSE Ethernet. Se è così, questo è probabilmente il tuo problema. In generale, la disabilitazione di QOS sugli switch risolve questo problema.

Flussi del genere mi suggeriscono che i vari metodi di controllo del flusso TCP non funzionano correttamente. Ho riscontrato alcuni problemi con i kernel Linux che parlano con le versioni di Windows post-Vista e si ottengono throughput del genere. Tendono a presentarsi abbastanza bene a Wireshark quando dai un'occhiata.

La possibilità peggiore è che TCP ritardato ack sia completamente rotto e vedrai un modello di traffico simile a:

packet
packet
[ack]
packet
packet
[ack]

L'ho risolto applicando gli aggiornamenti del driver NIC ai server Windows. Le NIC intelligenti fornite con alcuni server (broadcom) a volte possono fallire in modi interessanti, e questo è uno.

Un normale modello di traffico sarebbe un gran numero di pacchetti seguiti da un pacchetto Ack.

L'altra cosa da cercare sono i lunghi ritardi. I valori sospetti sono 0,2 secondi e 1,0 secondi. Ciò suggerisce che una parte non sta ottenendo ciò che si aspetta e sta aspettando che scada un timeout prima di rispondere. Combina il modello di pacchetto non valido sopra con un ritardo di 200 ms per l'ACK e otterrai una velocità di trasmissione di 1 MB / s enorme.

Questi sono i cattivi schemi di traffico che si notano facilmente.

Non ho lavorato con quel tipo di dispositivo NAS, quindi non so quanto sia modificabile riparare tutto ciò che viene trovato.