Baixo desempenho, iSCSI e AoE

Estamos à procura de um armazenamento de velocidade razoável. Por causa do baixo orçamento, decidimos usar os alvos iSCSI ou AoE do software. Antes de alterar nossa infraestrutura 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
• Switch gerenciado de 1 GBit do NetGear
• placas de rede integradas (Broadcom com TOE), placas de rede EdiMax, placas de rede Broadcom com TOE - todos com 1 GB
• O servidor de destino está usando um controlador QLogic com 6 unidades WD Blue SATA de 2 TB.
• os sistemas operacionais de destino e de iniciador são o Ubuntu 16.04 LTS com todas as atualizações. O switch é dedicado para fins de armazenamento. Testamos vínculos e caminhos múltiplos.

Nosso problema é a baixa velocidade de leitura. Para o teste, usamos ddum arquivo de 40 a 100 GB.

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

Tentamos ietd, aoetools, LIO. Utilizamos títulos de 2 NICs: balance-rr e LACP, caminhos múltiplos com rr. Frames normais e jumbo usados. Finalmente, fizemos conexão direta via Ethernet entre o destino e o host (sem comutador).

Todos os testes apresentam mais menos os mesmos resultados (é claro que o uso de NICs comuns sem TOE e iSCSI deu 20-30% de resultados piores).

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

Como não tivemos sorte, decidimos usar uma terceira placa de rede (ambos os lados, é claro). Os resultados foram estranhos:

• 2 placas de rede - 50 MB / s cada
• 3 placas de rede - 33 MB / s cada

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

O que fazemos de errado?

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

AOE (ATA sobre Ethernet) é antigo e é uma merda. Já nos livramos da Coraid anos atrás. Estamos usando o StarWind https://www.starwindsoftware.com/ como o iSCSI já faz um bom tempo e o StarWind nos pediu para migrar do Coraid para qualquer armazenamento que pudéssemos fazer.

Portanto, neste momento, somos muito bons com o iSCSI fornecido pela StarWind e usando o Windows, ESX e SCST http://scst.sourceforge.net/ no Linux como iniciadores. Com o RDMA / iSER, ele é de até 10 Gbit, muito feliz até agora.

Sua expectativa de como a agregação de link Ethernet funciona está incorreta.

Todos os métodos de agregação, exceto balance-rr (ou seja, todos os métodos cujo modo> 0) não oferecem uma maior taxa de transferência de conexão única; em vez disso, 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 superior ao que você normalmente pode ter em uma única interface é balance-rr , que distribui pacotes de maneira round-robin. Você tinha que definir o equilíbrio entre rr em ambos o iniciador e o alvo. No entanto, um grande problema é que isso depende muito do switch.

De qualquer forma, se você definir o alvo e o iniciador para balance-rr, a conexão direta das duas máquinas deverá aumentar o desempenho. Caso contrário, você pode postar um iperfcom balance-rr e as duas máquinas conectadas diretamente (sem chave)? Além disso, poste o ddcomando exato que você usou para o benchmarking.

Nota: Estou falando apenas do iSCSI aqui. Não tenho experiência com o AoE além de ler sobre ele e não o implementaria em nenhuma nova infraestrutura (é praticamente extinta).

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

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

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

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

A maioria das respostas no AoE é totalmente incorreta, contrafactual e mostra falta de conhecimento e experiência no AoE. Primeiro, não está extinto. A CORAID é o fornecedor por trás da AoE e eles foram reiniciados como "SouthSuite", mantendo a marca comercial da CORAID. Eles são os mesmos desenvolvedores também. Eles estão criando novos produtos e apoiando a maioria dos antigos. Eles também estão impulsionando o desenvolvimento do AoE, como mostram claramente suas listas de discussão técnicas abertas. Verifique o site, está tudo atualizado e conta toda a história na página de histórico.

Alguém disse que o AoE não se beneficiaria com os jumbo-frames e também estava errado. Foi suportado depois que a versão 13 do 'vbladed' foi 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 é TCP. Isso fornece uma correção de erro (devido às somas de verificação no TCP) e permite rotear o tráfego sobre IP na camada 3. É aí que as vantagens do iSCSI param. Seu desempenho no mundo real é absolutamente terrível quando você o compara de maneira justa com algo como FCP, AoE ou FCoE. Convido você a pesquisar no Google "comparação de desempenho iscsi" para o programa de terror.

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

A agregação 802.3ad não aumentará muito a taxa de transferência de fluxo único, mesmo em um cenário de rodízio. Isso também complicará sua configuração de rede e oferecerá algumas novas oportunidades de dar um tiro no pé, descascando os intervalos da PDU ou configurando incorretamente o link do Cisco VPC para suportar o estado ativo-ativo. Não use o LACP com o AoE, deixe-o lidar com seus próprios caminhos e multiplexação. Versões posteriores do AoE lidam com isso lindamente e, na maioria dos casos, com mais elegância do que o FCP, já que é tudo automático. Portas Ethernet adicionais oferecem mais largura de banda e maior resiliência. Se você distribuir as portas Ethernet do host e do iniciador por vários comutadores, isso poderá fornecer ainda mais redundância. Não há necessidade de configurar um modo de ligação. Além disso, não execute o IP nas mesmas interfaces usadas para o AoE.

Em suma, não ouça os opositores do AoE, eles parecem não ter muita experiência e estão apenas surfando ondas cerebrais da moda. Evite o rebanho. Vá configurar uma loja de suporte com pré-busca ajustada à mão e você provavelmente verá o aumento da taxa de transferência de leitura. Abandone o uso de protocolos de agregação e execute os gritos 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'. Esses dão resultados muito mais confiáveis.

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

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

Gravando no destino iSCSI:
dd se = / dev / zero de = / mnt / zero.bin bs = contagem de 1M = 2000
2000 + 0 registro przeczytanych - w
2000 + 0 registro zapisanych
- w 2097152000 bytes (2,1 GB, 2,0 GiB) copiados , 10.1093 s, 207 MB / s

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

Velocidade da rede:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Cliente conectando a 172.16.10.80,
tamanho da janela TCP da porta TCP 5001 : 325 KByte (padrão)
--------------------------------------------- ---------------
[3] porta 172.16.10.70 local 37024 conectada à porta 172.16.10.80 5001
[ID] Largura de banda de transferência de intervalo
[3] 0,0-10,0 s 2,30 GBytes 1,98 Gbits / s O

teste com quadros iperf e jumbo deu 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 96MB / s.
Meu objetivo é atingir uma velocidade de leitura de cerca de 200MB / s.

EDIT:
1. Nós não usamos LACP - foi um teste único.
2. Os testes com balance-rr e MPIO fornecem exatamente os mesmos resultados. Os caminhos múltiplos foram testados com NICs em diferentes sub-redes.
3. A adição de mais NICs não aumenta a velocidade de leitura, mas reduz a utilização de cada NICs.
4. Achamos que o problema é alguma limitação (driver, módulo?) Que não permite a leitura mais rápida. Mas não tenho certeza, se é o alvo ou o lado do iniciador.


EDIT 2: Acabei de fazer um teste adicional: configurei o mesmo host como alvo e iniciador para se livrar dos problemas de hardware de rede. Fiquei chocado: exatamente a mesma velocidade de leitura! 130 MB / s! A escrita é 227 MB / s.

Como você configurou o seu nic's são todos os buffers configurados corretamente, você alocou RAM suficiente para os buffers de rede. também não use ligação aqui, você pode usar 2 canais iscsi e os caminhos múltiplos no iniciador, o mesmo com o ATAoE, o caminho múltiplo através do ID de prateleira e lun em qualquer caminho.