Baixo desempenho tanto do iSCSI quanto do AoE

8

Estamos à procura de um armazenamento de velocidade razoável. Devido ao baixo orçamento, decidimos usar alvos de software iSCSI ou AoE. Antes de mudarmos nossa infra-estrutura de produção, estamos fazendo alguns testes para escolher a melhor tecnologia.

Para testes, usamos:

  • Fujitsu Siemens RX200 S4 como alvo
  • Fujitsu Siemens RX200 S4 como iniciador
  • NetGear gerenciado com 1GBit
  • NICs onboard (Broadcom com TOE), NICs EdiMax, NICs Broadcom com TOE - todos com 1GBit
  • O servidor de destino
  • está usando um controlador QLogic com 6 drives WD Blue SATA de 2 TB.
  • os sistemas operacionais alvo e iniciador são o Ubuntu 16.04 LTS com todas as atualizações. O switch é dedicado para fins de armazenamento. Testamos vínculos e multipathing.

Nosso problema é baixa velocidade de leitura. Para testes, usamos dd e um arquivo de 40 a 100 GB.

  • leitura e gravação local em um servidor de destino é superior a 300MB / s.
  • escrever para o servidor por iSCSI ou AoE é superior a 200MB / s, o que nos satisfaz.
  • a leitura do servidor é sempre de 95 a 99MB / s.

Nós tentamos o ietd, aoetools, LIO. Nós usamos títulos de 2 NICs: balance-rr e LACP, multipathing com r-r. Utilizou quadros normais e jumbo. Finalmente, fizemos até mesmo uma conexão ethernet direta entre o target e o host (sem switch).

Todos os testes fornecem menos os mesmos resultados (claro que usar NICs comuns sem TOE e iSCSI deram 20-30% de resultados piores).

Testar rede com iperf mostrou transferências de cerca de 200MB / s (2GBit). Observar o uso das NICs no alvo com bmon mostrou uma utilização igual dos dois dispositivos (cada um com cerca de 50 MB / s para leitura, cerca de 100 MB / s para gravação).

Como não tivemos sorte, decidimos usar um terceiro NIC (ambos os lados, é claro). Os resultados foram estranhos:

  • 2 NICs - 50MB / s cada
  • 3 NICs - 33MB / s cada

Existe algum limite no software de destino que desabilita a saída superior a 1GBit / s?

O que fazemos de errado?

    
por Sebastian Biniecki 25.11.2016 / 12:21

6 respostas

10

Para extrair o máximo desempenho do armazenamento conectado iSCSI, você deve usar Jumbo Frames e MPIO (não LACP). O RDMA / iSER é recomendado se você puder fazer isso.

AOE (ATA over Ethernet) é antigo e é uma merda. Já nos livramos de Coraid anos atrás. Nós já estamos usando o StarWind link como alvo do iSCSI já há algum tempo e o StarWind nos pediu para migrar do Coraid para qualquer armazenamento que pudéssemos fazer.

Então, agora, somos muito bons com o iSCSI fornecido pela StarWind e usando o link do Windows, ESX e SCST no Linux como iniciadores. Com RDMA / iSER faz até 10 Gbit, muito feliz até agora.

    
por 25.11.2016 / 14:23
6

Sua expectativa sobre como a agregação de links Ethernet está incorreta.

Todos os métodos de agregação diferentes de balance-rr (ou seja: todos os métodos cujo modo > 0) fazem não fornecem uma maior taxa de transferência de conexão única; em vez disso, eles aumentam a largura de banda total disponível quando várias conexões são estabelecidas de / para os hosts afetados. Em outras palavras, o LAG / LACP não oferecerá nenhum benefício para esse cenário de conexão única.

O único método de agregação que pode fornecer uma taxa de transferência de sessão única maior do que normalmente é possível em uma única interface é balance-rr , que distribui pacotes de maneira round-robin. Você tinha que definir balance-rr em ambos o iniciador e o alvo. No entanto, uma captura grande é que isso depende muito do switch.

De qualquer forma, se você definir ambos, target e initiator para balance-rr, conectar diretamente as duas máquinas deve aumentar o desempenho. Se não, você pode postar um iperf com o saldo-rr e ambas as máquinas conectadas diretamente (sem chave)? Além disso, poste o comando dd exato que você usou para o benchmarking.

    
por 25.11.2016 / 15:44
3

Nota: estou falando apenas do iSCSI aqui. Eu não tenho experiência com o AoE além de ler sobre isso, e eu não iria implementá-lo em qualquer nova infraestrutura de qualquer maneira (é praticamente extinta).

Não use o balance-rr para nada além de alguns protocolos ponto-a-ponto muito específicos. Tem um desempenho horrível quando está sob quase qualquer tipo de carga real, e provoca uma série de problemas de rede (como um monte de jitter). Definitivamente não use com um interruptor.

Use o MPIO sem nenhuma ligação no lado do iniciador para realizar balanceamento de carga e tolerância a falhas. Para garantir que seus caminhos não fiquem "confusos" enviando todo o tráfego para um único caminho, coloque caminhos individuais (NICs gigabit entre o destino e o iniciador, no seu caso) em sub-redes separadas.

Sinta-se à vontade para vincular o lado de destino com o LACP por caminho (como em duas ligações para dois caminhos para um total de quatro NICs, como uma configuração de porta de destino de exemplo). Isso funciona muito bem e pode equilibrar várias conexões de iniciador que usam os mesmos caminhos. Use também jumbo frames e iSER, se possível. Usar o LACP no destino equilibrará as conexões para cada caminho entre várias NICs.

O uso do LACP no iniciador só será eficaz se estiver fazendo várias conexões de portal de destino com uso simultâneo (não é comum para praticamente qualquer carga de trabalho). Mesmo se você fosse efetivamente implementar o LACP por caminho no iniciador, ele rapidamente se tornaria um pesadelo de cabeamento para usar (por exemplo) quatro tecidos adicionais em cada caixa. Se você precisar de mais de ~ 2Gib / s de taxa de transferência para um único iniciador, considere 10GiB / s ethernet.

    
por 26.11.2016 / 14:34
1

A maioria das respostas sobre a AoE são totalmente incorretas, contrafactuais e mostram uma falta de conhecimento e experiência da área de influência. Primeiro, não é extinto. O CORAID é o fornecedor por trás do AoE e eles reiniciaram como “SouthSuite”, mantendo a marca registrada CORAID. Eles são os mesmos desenvolvedores também. Eles estão fazendo novos produtos e suportando a maioria dos antigos. Eles estão empurrando o desenvolvimento de AoE também, como mostram claramente suas listas de discussão técnicas abertas. Verifique o site, está tudo atualizado e conta toda a história em sua página de histórico.

Alguém disse que a AoE não será beneficiada com jumbo frames e também está errada. Foi suportado após a versão 13 do "vbladed" ter sido lançada. Você precisa ajustar seu MTU para suportar o novo tamanho de quadro, mas, caso contrário, ele funciona muito bem.

O iSCSI é executado na camada 5 do modelo OSI. É o transporte usual é o TCP. Isso lhe dá alguma correção de erro (devido a somas de verificação no TCP) e permite rotear o tráfego sobre IP na camada 3. É sobre onde as vantagens do iSCSI param. Seu desempenho no mundo real é extremamente ruim quando você realmente compara isso a algo como FCP, AoE ou FCoE. Convido você para o google "iscsi performance comparison" para o show de horror.

O problema de velocidade de leitura pode ter sido devido a um erro de configuração da rede, desligue o controle de fluxo e certifique-se de usar um buffer de soquete grande o suficiente. Você também não mencionou se o sistema de arquivos subjacente foi ajustado para pré-busca de leitura ou não. Com base no seu cenário, isso pode ajudá-lo muito, mas tenha cuidado para não usá-lo com determinados bancos de dados que exigem que o armazenamento em cache seja desabilitado.

A agregação 802.3ad não aumentará muito a taxa de transferência de seu fluxo único, mesmo em um cenário de round-robin. Isso também complicará sua configuração de rede e oferecerá a você algumas novas oportunidades de se atirar no pé ao incompatibilizar os intervalos de PDU ou configurar incorretamente o seu link do Cisco VPC para suportar o estado ativo-ativo. Não use o LACP com o AoE, deixe-o lidar com o próprio multipathing e multiplexação. As versões posteriores do AoE lidam com isso de maneira excelente e, na maioria dos casos, com mais graça do que o FCP, já que tudo é automático. Portas Ethernet adicionais oferecem mais largura de banda e mais resiliência. Se você espalhar o host & portas Ethernet do iniciador através de múltiplos switches, que podem fornecer ainda mais redundância. Não há necessidade de configurar um modo de ligação. Além disso, não execute IP nas mesmas interfaces que você usa para AoE. Isso é conhecido por ser problemático para o desempenho, às vezes também.

Em suma, não ouça os pessimistas da AoE, eles dizem que não têm muita experiência e estão apenas surfando ondas da moda. Evite o rebanho. Vá configurar uma loja de apoio com pré-busca sintonizada manualmente e você provavelmente verá sua taxa de transferência de leitura subir. Elimine o uso de protocolos de agregação e execute screaming a partir do iSCSI. Uma última coisa, pare de usar "dd", não é um ótimo teste e está sujeito a efeitos de cache ruins. Use uma ferramenta de referência real como "fio", "iozone" ou "dbench". Aqueles dão resultados muito mais confiáveis.

    
por 12.01.2017 / 00:49
1

Eu sei que o LACP é para várias conexões. Testando foi um ato de desespero :)

Todos os testes foram feitos com o balance-rr e dois NICs.

Escrevendo para o destino iSCSI:
dd se = / dev / zero de = / mnt / zero.bin bs = contagem de 1M = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB, 2,0 GiB) copiados, 10,1093 s, 207 MB / s

Lendo do destino iSCSI:
dd se = / mnt / zero.bin de = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB, 2,0 GiB) copiados, 16,1684 s, 130 MB / s

Velocidade de rede:
iperf -c 172.16.10.80
-------------------------------------------------- ----------
Cliente conectando-se a 172.16.10.80, porta TCP 5001
Tamanho da janela TCP: 325 KByte (padrão)
-------------------------------------------------- ----------
[3] porto 37024 local 172.16.10.70 conectado com 172.16.10.80 porta 5001
[ID] Largura de banda de transferência de intervalo
[3] 0.0-10.0 seg 2.30 GBytes 1,98 Gbits / seg

Testes com iperf e jumbo frames deram os mesmos resultados.

Eu ganhei alguma velocidade de leitura, executando no iniciador:
hdparm -a 2048 / dev / dm-1
Anteriormente, era 256 e a velocidade de leitura era de 96MB / s
Meu objetivo é atingir velocidade de leitura de cerca de 200MB / s.

EDIT:
1. Nós não usamos LACP - foi um teste de tempo.
2. Testar com o balance-rr e o MPIO fornece exatamente os mesmos resultados. O multicaminho foi testado com NICs em diferentes sub-redes.
3. Adicionar mais NICs não aumenta a velocidade de leitura, mas apenas reduz a utilização de cada NIC.
4. Achamos que o problema é alguma limitação (driver, módulo?) Que não permite ler mais rápido. Mas não tenho a certeza se é alvo ou lado do iniciador.


EDIT 2: Fiz apenas alguns testes adicionais: configurei o mesmo host como um alvo e iniciador para me livrar dos problemas de hardware de rede. Fiquei chocado: exatamente a mesma velocidade de leitura! 130 MB / s! Escrever é 227 MB / s.

    
por 26.11.2016 / 13:24
-2

como você tem o seu nic configurado são todos os buffers configurados corretamente, você alocou ram suficiente para os buffers de rede. também não use bonding aqui você pode usar 2 canais iscsi e multipath eles no iniciador, mesmo com ATAoE o iniciador multipaths via prateleira e lun ID em qualquer caminho.

    
por 10.03.2017 / 18:58