Use ligação de NIC com comutadores independentes

Question

Estou usando o Debian e gostaria de configurar uma rede HA com alguns servidores.

Esta é minha configuração:

   -----sw1--------------sw2------------ host1
  /    /                    \    \        /
srv1 srv2                  srv3 srv4     /
  \    \                    /    /      /
   -----sw3--------------sw4------------

Eu tenho um monte de servidores ( srv ) conectados a duas redes independentes. Cada servidor tem dois nics. Cada um do nic é conectado a uma das redes usando switches não gerenciados ( sw ). Cada servidor usa as nics para uma interface de ligação com um endereço IP fixo. O host deve ser capaz de alcançar todos os servidores. Tem uma interface de ligação também.

O cenário acima é possível com um dispositivo de ligação do Linux? O host deve ser capaz de contatar todos os servidores, mesmo que um nic de um servidor esteja inativo ou uma das redes esteja inativa. A conexão cruzada das redes não é o que eu quero.

Fiz algumas experiências com os modos de ligação active-backup e broadcast em combinação com o monitoramento ARP . Mas sem sucesso ...

Com os modos acima, consegui criar uma rede funcional, mas, assim que um link falha, a rede está em queda.

Você pode me ajudar? Existem alternativas para alcançar meu objetivo?

Obrigado antecipadamente.

Dieter

    

Answer 1

Não, não é assim que funciona a ligação.

O vínculo usa protocolos como o LACP para agregar vários links de ethernet entre os mesmos dois pedaços de equipamento (2 hosts, 2 switches ou 1 switch e 1 host) e tratá-los como se fossem um único link.

Como as duas interfaces de rede em srv1 , srv2 , srv3 , srv4 e host1 estão conectadas a interfaces Ethernet diferentes , a ligação / LACP não se aplica.

Uma opção é unir as duas interfaces em cada um dos 5 hosts e fazer com que os hosts participem da rede de árvore de abrangência para garantir que não haja loops de camada 2. Infelizmente, desde que você mencionou que os switches não são gerenciados, os loops da árvore e da camada 2 podem ser perigosos em seu cenário porque você não pode configurar os parâmetros da árvore de abrangência nos switches não gerenciados ... ou talvez eles não implementem a árvore de abrangência. Além disso, o STP resolve loops na rede bloqueando completamente as portas, efetivamente levando a uma configuração ativa + em espera, que não é o que você deseja.

Outra opção é tornar as redes "superiores" e "inferiores" redes IP completamente independentes. Em outras palavras, implemente seu balanceamento de carga ou redundância na camada 3 em vez da camada 2.

-----+----------------+---------------+--------------
     |                |               |
     |10.0.1.1/24     |10.0.1.2/24    |10.0.1.3/24
  +------+         +------+        +------+
  | srv1 |         | srv2 |        | srv3 |           etc...
  +------+         +------+        +------+
     |10.0.2.1/24     |10.0.2.2/24    |10.0.2.3/24
     |                |               |
-----+----------------+---------------+--------------

Versão simples :

Para cada servidor, publique os endereços IP no DNS e use o balanceamento de carga baseado em DNS para permitir que um link ou outro seja selecionado.

Pro:

• simples

Con:

• conexões TCP individuais não passarão para o outro link
• longos tempos limite podem ocorrer se um dos links estiver inativo antes que o outro seja tentado
• nem todos os aplicativos entendem como tentar novamente uma conexão com um host em um endereço IP diferente

Versão melhorada :

Adicione um endereço de loopback extra em cada host que não esteja em nenhuma das sub-redes dos links individuais. Por exemplo, 10.0.3.x/32 :

• srv1: 10.0.3.1/32
  • Configurar com ip addr add 10.0.3.1/32 dev lo
• srv2: 10.0.3.2/32
• srv3: 10.0.3.3/32
• etc ...

Os servidores falam um protocolo de roteamento como o OSPF entre si. Use quagga para esse fim. Cada servidor aprenderá através do OSPF como alcançar os endereços de loopback de cada um dos outros servidores através de ambos os links (ou através de apenas um link se apenas um link estiver ativo). Publique apenas os endereços de loopback no DNS.

Com uma configuração adicional cuidadosa da seleção de endereço IP de origem do kernel, você provavelmente pode organizar os endereços de loopback para serem usados como endereços de origem também, o que significa que as conexões TCP individuais irão falhar.