Agregação de links do FreeBSD não mais rápido que o link único

Colocamos uma NIC Intel I340-T4 de 4 portas em um servidor FreeBSD 9.3 ¹ e a configuramos para agregação de link no modo LACP, na tentativa de diminuir o tempo necessário para espelhar 8 a 16 TiB de dados de um servidor de arquivos mestre para 2 4 clones em paralelo. Esperávamos obter até 4 Gbit / s de largura de banda agregada, mas não importa o que tentássemos, ele nunca sai mais rápido que 1 Gbit / s de agregado. ²

Estamos usando iperf3para testar isso em uma LAN inativa. ³ A primeira instância quase atinge um gigabit, como esperado, mas quando iniciamos um segundo em paralelo, os dois clientes diminuem a velocidade para aproximadamente ½ Gbit / s. A adição de um terceiro cliente reduz a velocidade de todos os três clientes para ~ ⅓ Gbit / s, e assim por diante.

Tomamos o cuidado de configurar os iperf3testes de que o tráfego dos quatro clientes de teste entra no comutador central em portas diferentes:

Verificamos que cada máquina de teste tem um caminho independente de volta ao comutador do rack e que o servidor de arquivos, sua NIC e o comutador têm largura de banda para fazer isso, dividindo o lagg0grupo e atribuindo um endereço IP separado para cada um. das quatro interfaces nesta placa de rede Intel. Nessa configuração, alcançamos ~ 4 Gbit / s de largura de banda agregada.

Quando começamos esse caminho, estávamos fazendo isso com um comutador gerenciado SMC8024L2 antigo . (Folha de dados em PDF, 1.3 MB.) Não foi a opção mais sofisticada de sua época, mas deveria ser capaz de fazer isso. Achamos que o switch poderia estar com defeito, devido à sua idade, mas a atualização para um HP 2530-24G muito mais capaz não alterou o sintoma.

O switch HP 2530-24G alega que as quatro portas em questão estão realmente configuradas como um tronco LACP dinâmico:

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

Tentamos o LACP passivo e ativo.

Verificamos que todas as quatro portas da NIC estão recebendo tráfego no lado do FreeBSD com:

$ sudo tshark -n -i igb$n

Estranhamente, tsharkmostra que, no caso de apenas um cliente, o switch divide o fluxo de 1 Gbit / s em duas portas, aparentemente fazendo ping-pong entre elas. (Os comutadores SMC e HP mostraram esse comportamento.)

Como a largura de banda agregada dos clientes se reúne apenas em um único local - no comutador no rack do servidor - apenas esse comutador está configurado para o LACP.

Não importa em qual cliente começamos primeiro ou em qual ordem os iniciamos.

ifconfig lagg0 no lado do FreeBSD diz:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

Aplicamos o máximo de conselhos no guia de ajuste de rede do FreeBSD que faz sentido para a nossa situação. (Muito disso é irrelevante, como as coisas sobre o aumento máximo de DFs.)

Tentamos desativar o descarregamento da segmentação TCP , sem alteração nos resultados.

Não temos uma segunda placa de rede do servidor de 4 portas para configurar um segundo teste. Por causa do teste bem-sucedido com 4 interfaces separadas, assumimos que nenhum hardware está danificado. ³

Vemos esses caminhos adiante, nenhum deles atraente:

1. Compre um switch maior e mais ruim, esperando que a implementação do LACP da SMC seja uma porcaria e que o novo switch seja melhor. (Atualizar para um HP 2530-24G não ajudou.)

2. Observe a laggconfiguração do FreeBSD um pouco mais, esperando que tenhamos perdido alguma coisa. ⁴

3. Esqueça a agregação de links e use o DNS round-robin para efetuar o balanceamento de carga.

4. Substitua a NIC do servidor e alterne novamente, desta vez com 10 itens GigE , a cerca de 4 × o custo de hardware deste experimento LACP.

Notas de rodapé

1. Por que não mudar para o FreeBSD 10, você pergunta? Como o FreeBSD 10.0-RELEASE ainda usa o pool ZFS versão 28, e este servidor foi atualizado para o pool ZFS 5000, um novo recurso do FreeBSD 9.3. A linha 10. x não vai conseguir isso até que o FreeBSD 10.1 seja lançado daqui a um mês . E não, a reconstrução da origem para chegar à borda de sangramento 10.0-STABLE não é uma opção, pois esse é um servidor de produção.

2. Por favor, não tire conclusões precipitadas. Nossos resultados de teste, mais adiante na pergunta, explicam por que isso não é uma duplicata desta pergunta .

3. iperf3é um teste de rede puro. Embora o objetivo final seja tentar preencher esse canal agregado de 4 Gbit / s do disco, ainda não estamos envolvendo o subsistema de disco.

4. Buggy ou mal projetado, talvez, mas não mais quebrado do que quando saiu da fábrica.

5. Eu já fiquei vesga de fazer isso.

Qual é o algoritmo de balanceamento de carga em uso no sistema e no comutador?

Toda a minha experiência com isso é no Linux e Cisco, não no FreeBSD e no SMC, mas a mesma teoria ainda se aplica.

O modo de balanceamento de carga padrão no modo LACP do driver de ligação do Linux e em switches Cisco mais antigos como o 2950, ​​é balanceado com base apenas no endereço MAC.

Isso significa que, se todo o seu tráfego estiver indo de um sistema (servidor de arquivos) para outro MAC (um gateway padrão ou uma Interface Virtual Comutada no comutador), o MAC de origem e destino será o mesmo, portanto, apenas um escravo será ser usado.

No seu diagrama, não parece que você está enviando tráfego para um gateway padrão, mas não tenho certeza se os servidores de teste estão em 10.0.0.0/24 ou se os sistemas de teste estão em outras sub-redes e estão sendo roteados via uma interface de camada 3 no comutador.

Se você estiver roteando no switch, há sua resposta.

A solução para isso é usar um algoritmo de balanceamento de carga diferente.

Novamente, não tenho experiência com BSD ou SMC, mas Linux e Cisco podem se equilibrar com base nas informações L3 (endereço IP) ou L4 (número da porta).

Como cada um dos seus sistemas de teste deve ter um IP diferente, tente fazer o balanceamento com base nas informações L3. Se isso ainda não funcionar, altere alguns IPs e verifique se você altera o padrão de balanceamento de carga.