Ligação Linux: 802.3ad (LACP) vs. modo balanceamento

Question

Aqui está a situação. Gostaria de conectar meus servidores Linux a uma única rede usando o link duplo para motivos de tolerância a falhas e balanceamento de carga. Os servidores têm 2 ou mais NICs de 1 gig e eu planejo conectar cada um deles a um switch diferente que resida em uma única pilha (ou seja, um único comutador virtual). Todos os switches são Juniper EX4200 ou EX4500.

Eu sei que posso usar qualquer um dos modos de ligação do Linux e gostaria de saber qual é o melhor. Historicamente, usei o modo de backup ativo porque alguns servidores estavam se conectando a switches não empilhados, mas agora temos uma rede nova e consistente e gostaria de usar um modo de ligação que oferece balanceamento de carga além da tolerância a falhas.

Eu achei que o melhor modo de usar é o 802.3ad (LACP) porque esse é o padrão usado em todos os equipamentos de rede, mas no momento em que eu configuro um conjunto de portas como um canal LACP no lado do switch, a conexão quebra até eu também configurar o lado do servidor corretamente. Isso dificulta muito as tarefas de administração do sistema, porque antes de instalar um novo servidor, é necessário remover a configuração do LACP no switch (porque coisas como inicialização PXE e instalação de rede não funcionam em portas LACP) e após a instalação precisamos mudar o switch configurações novamente, mas somente depois que o servidor foi configurado para usar o LACP ou a conexão morrerá.

Outros modos de ligação, como balance-alb, não exigem nenhuma configuração especial no lado do switch, enquanto no papel fornecem as mesmas vantagens.

Existe algum motivo para escolher 802.3ad em vez de balancear?

    

Answer 1

Eu não estou muito familiarizado com os switches Juniper, mas você não deve configurar o LACP neles; que é o ponto do LACP. Se este não for o caso, algo está errado com a configuração do seu switch.

O LACP especifica apenas um protocolo para agregar portas dinamicamente. Não especifica uma política de agendamento de portas (onde o tráfego é enviado e recebido). Esta política é definida separadamente. Não me lembro do processo no Linux, mas sei que o Linux suporta a especificação de algumas políticas diferentes, provavelmente semelhante ao equilíbrio-alb.

O equilíbrio-alb tem desvantagens específicas. Principalmente que ele seleciona uma porta de saída de forma semi-inteligente para novas conexões, e elas ficam presas a essa porta durante a vida útil da conexão (na verdade é feita pelo MAC, não pela porta, se uma porta falhar, o MAC é atribuído a outra porta , permitindo assim que a conexão continue).

Isso não exatamente "agrega" as portas, já que as conexões não poderão utilizar mais de uma porta. Então, se você tem 2 portas de 1GbE, uma única conexão ainda é limitada a 1GbE. O LACP resolve isso normalmente, embora dependa de sua política de agendamento e do número de portas ativas suportadas em cada extremidade.

    

Answer 2

No equilíbrio-alb, tanto o envio quanto o recebimento de quadros são balanceados por carga usando o truque de alteração do endereço MAC. Isso pode causar problemas nos níveis do aplicativo. Nem todos os aplicativos são amadurecidos para este modo.

Para lidar com seu problema original. Aqui está o que eu costumava fazer.

• Deixe as portas do switch como padrão.
• Execute a instalação do pxe-Kickstart.
• No nível de pós-instalação do KS ou na sua infraestrutura de gerenciamento, "puppet / chef" altera a configuração das portas do switch para o LACP "Supondo que haja um servidor confiável em sua rede por todos os dispositivos"

Chakri -

    

Answer 3

Se você definiu o LACP nas portas onde suas caixas se conectam para usar o LACP, a única configuração "correta" no lado do host é usar o LACP. O EX será balanceado de acordo com os MACs de origem e de destino Ethernet para o tráfego Ethernet e considerará a origem / destino / porta IP para o tráfego IP se você tiver pacotes IP em seus quadros. Por favor, considere a leitura Juniper KB22943 para os detalhes dos algoritmos de hash. Se o seu switch suportar o LACP de pilha cruzada (que é o caso de 4XXX EXs), use o LACP se tiver uma pilha. Também pode ser mais fácil depurar caso você tenha uma topologia L2 mais complexa com loops por VLAN, etc.

    

Answer 4

O LACP é ótimo quando funciona e fornece praticamente o dobro do desempenho de uma única NIC. Se você tem apenas um pequeno número de máquinas com placas de rede conectadas, vá em frente.

Mas, uma das desvantagens é que, se você está com um orçamento apertado e, portanto, usando switches de extremidade inferior, eles tendem a não ter grupos LACP suficientes e nenhum recurso MLAG ou SMLT. No mínimo, a maioria dos comutadores da HP e similares parece oferecer apenas tantos grupos de ligação quantos o número de portas. Alguns oferecem ainda menos. Um switch supermicro de 2k que estávamos usando em apenas um ponto tinha 8 grupos de LACP, apesar de ter 52 portas. Eu estou supondo que esse número é relativamente arbitrário. Ninguém achou que você precisaria de mais de metade do número de portas de switch. Provavelmente é apenas um número codificado no firmware e provavelmente ocupa um pouco mais de memória.

Mas, isso realmente é uma grande limitação se você usar SR-IOV, ligação e máquinas virtuais.

Se você é um provedor que quer hospedar talvez centenas ou milhares de máquinas em um rack, você não necessariamente quer gastar dezenas de milhares de dólares em um switch de ponta que é importante, mas desnecessariamente caro apenas para fornecer redundância. e desempenho para um único rack de máquinas. Eu posso ver porque empresas como o facebook querem criar seus próprios switches.

Então, nesse tipo de cenário, eu iria com um modo diferente, talvez equilibrando-o.