Estratégia de solução de problemas para desempenho iSCSI / NFS muito ruim

Temos um novo Synology RS3412RPxs que oferece destinos iSCSI para três caixas do Windows 2008 R2 e NFS para uma caixa do OpenBSD 5.0.

O login no RS3412 com ssh e a leitura / gravação de arquivos pequenos e arquivos de 6 GB usando dd e vários tamanhos de bloco mostram excelente desempenho de E / S do disco.

Usando dd ou iometer nos clientes iSCSI / NFS, atingimos até 20 Mbps (isso não é um erro de digitação. Vinte Mbps). Nós meio que esperávamos fazer melhor uso das múltiplas placas de rede Gbit na Synology.

Eu verifiquei o switch e a configuração da porta da NIC está definida para gigabit, não para negociação automática. Tentamos com e sem Jumboframes sem diferença. Eu verifiquei com ping que o MTU é atualmente 9000. Duas atualizações de firmware foram implantadas.

Vou tentar o link direto entre o destino iSCSI e o iniciador para descartar problemas de comutação, mas quais são minhas outras opções?

Se eu interromper o wireshark / tcpdump, o que procuro?

Como parece ser o tema comum aqui, dê uma outra olhada nas configurações de controle de fluxo nos comutadores. Se os comutadores tiverem estatísticas do contador Ethernet, observe-os e verifique se há um grande número de quadros Ethernet PAUSE. Nesse caso, esse provavelmente é o seu problema. Em geral, desabilitar o QOS no (s) switch (s) resolve esse problema.

Fluxos assim sugerem que os vários métodos de controle de fluxo TCP não estão funcionando corretamente. Eu já vi alguns problemas com os kernels do Linux conversando com versões do Windows pós-Vista e você obtém resultados assim. Eles tendem a aparecer muito bem no Wireshark quando você dá uma olhada.

A pior possibilidade absoluta é que o atraso do TCP ack esteja completamente quebrado e você verá um padrão de tráfego parecido com:

packet
packet
[ack]
packet
packet
[ack]

Eu resolvi esse problema aplicando atualizações de driver da NIC aos servidores Windows. Às vezes, as NICs inteligentes que acompanham alguns servidores (broadcom) 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á obtendo o que está esperando e está aguardando o tempo limite expirar antes de responder. Combine o padrão de pacote inválido acima com um atraso de 200 ms para o ACK e você obterá taxas de transferência de 1 MB / s.

Esses são os padrões de tráfego ruins fáceis de perceber.

Como não trabalhei com esse tipo de dispositivo NAS, não sei como é possível corrigir o que for encontrado.