Temos uma nova Synology RS3412RPxs que oferece alvos iSCSI para três caixas do Windows 2008 R2 e NFS para uma caixa do OpenBSD 5.0.
Efetuando login no RS3412 com ssh e lendo / gravando arquivos pequenos e de 6GB usando dd e vários blocksizes mostram um ótimo desempenho de E / S de disco.
Usando dd ou iometer nos clientes iSCSI / NFS, alcançamos até 20Mbps (isso não é um erro de digitação. Vinte Mbps). Nós estávamos meio que esperando fazer um melhor uso das múltiplas NICs Gbit na Synology.
Eu verifiquei que o switch e a configuração da porta NIC estão configurados para gigabit, não para negociação automática. Nós tentamos com e sem Jumboframes sem diferença. Eu verifiquei com o ping que a MTU está atualmente em 9000. Duas atualizações de firmware foram implantadas.
Eu vou tentar link direto entre o alvo iSCSI e o iniciador para descartar problemas de switch, mas quais são minhas outras opções?
Se eu quebrar o wireshark / tcpdump, o que eu procuro?
Como parece ser o tema comum aqui, dê outra olhada nas configurações de controle de fluxo no (s) switch (es). Se o (s) switch (es) tiver (m) estatísticas de contagem de Ethernet, dê uma olhada neles e veja se há um grande número de quadros PAUSE de Ethernet. Se assim for, isso é provavelmente o seu problema. Em geral, desabilitar o QOS no (s) switch (es) resolve esse problema.
Fluxos como esse sugerem para mim que os vários métodos de controle de fluxo do TCP não estão funcionando corretamente. Eu vi alguns problemas com os kernels Linux conversando com as versões do Windows pós-Vista e você obtém throughputs desse tipo. Eles tendem a aparecer muito bem no Wireshark quando você dá uma olhada.
A pior possibilidade absoluta é que o ack TCP atrasado esteja completamente quebrado e você verá um padrão de tráfego que se parece com:
packet
packet
[ack]
packet
packet
[ack]
Eu resolvi esse problema aplicando as atualizações do driver da NIC nos servidores do Windows. As NICs inteligentes que vêm com alguns servidores (broadcom) às vezes podem falhar de maneiras interessantes, e essa é uma delas.
Um padrão de tráfego normal seria um grande número de pacotes seguidos por um pacote Ack.
A outra coisa a procurar são longos atrasos. Valores suspeitos são 0,2 segundos e 1,0 segundos. Isso sugere que um lado não está recebendo o que está esperando e está aguardando um tempo limite para expirar antes de responder. Combine o padrão de pacote ruim acima com um atraso de 200 ms para o ACK e você obterá resultados de 1MB / s colossais.
Esses são os padrões de tráfego ruins fáceis de notar.
Eu não trabalhei com esse tipo de dispositivo NAS, então não sei o quanto é possível consertar o que for encontrado.