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


9

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?


O controle de fluxo está ativado? Que tipo de opção está no meio?
precisa

@SpacemanSpiff: o controle de fluxo não está ativado. Você esperaria que isso fizesse diferença? É um ZyXEL GS2200.
precisa

Uma espécie de backplane fracote, mas o suficiente para obter um desempenho melhor do que isso. Curioso para ver o que o cabo crossover oferece para você em termos de desempenho.
precisa

Respostas:


4

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.


Eu dei outra olhada. O controle de fluxo foi desativado e os contadores PAUSE foram zero em todas as interfaces. A ativação do controle de fluxo fez com que os contadores PAUSE disparassem em 25% da contagem de pacotes. Identificamos algum hardware que não mostra o mesmo desempenho fraco, agora estamos procurando atualizar drivers de nic e substituir determinadas placas de rede por outras mais capazes. A QoS já estava desativada no comutador. Obrigado pela sua contribuição.
Alex Holst

Fico feliz em ajudar ...
joeqwerty

3

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.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.