Como fazer balanceadores de carga redundantes?

Question

Entendo que o objetivo dos balanceadores de carga é equilibrar a carga entre os servidores e acompanhar a integridade da instância, etc. Mas, e se o balanceador de carga falhar? Como você configura balanceadores de carga redundantes? (balanceamento de carga balanceamento de carga?)

Eu pude ver como as verificações de integridade do DNS podem ser úteis, mas obviamente há problemas importantes de latência, não é?

Isso presume que você não está usando serviços de terceiros, como o AWS ELB ou algo semelhante. O que fazer se você está apenas usando o Nginx?

    

Answer 1

Existem algumas maneiras de obter alta disponibilidade (HA) de um balanceador de carga - ou em relação a qualquer serviço. Vamos supor que você tenha duas máquinas, com endereços IP:

• 192.168.100.101
• 192.168.100.102

Os usuários se conectam a um IP, então o que você quer fazer é separar o IP da caixa específica - por exemplo, criar um IP virtual. Esse IP será 192.168.100.100.

Agora, você pode escolher o serviço HA que cuidará do failover / failback automático do endereço IP. Alguns dos serviços mais simples para o unix são (u) carpa e keepalived, alguns dos mais complexos são, por exemplo, RedHat Cluster Suite ou Pacemaker.

Vamos considerar o keepalived como um exemplo - dois serviços keepalived - cada um executando em sua própria caixa - e eles se comunicam juntos. Essa comunicação é freqüentemente chamada de pulsação.

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

Se um keepalived parar de responder (o serviço fica inativo por qualquer motivo, ou a caixa é rejeitada ou desligada) - keepalived em outra caixa notará pulsações perdidas e presumirá que outro nó está inativo e executará ações de failover. Essa ação no nosso caso estará trazendo o IP flutuante.

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

O pior caso que pode acontecer nesse caso é a perda de sessões para os clientes, mas eles poderão se reconectar. Se você quiser evitar isso, dois balanceadores de carga devem ser capazes de sincronizar os dados da sessão entre eles, e se eles puderem fazer isso, os usuários não notarão nada, exceto talvez um pequeno atraso.

Outra armadilha dessa configuração é dividir o cérebro - quando as duas caixas estão online, mas o link é cortado, e ambas as caixas trazem o mesmo IP. Isso geralmente é resolvido por meio de algum tipo de mecanismo de proteção (reserva SCSI, reinicialização IPMI, corte de energia de PDU inteligente, ...) ou um número ímpar de nós que exigem que a maioria dos membros de cluster esteja ativa para que o serviço seja iniciado.

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

Um software de gerenciamento de clusters mais complexo (como o Pacemaker) pode mover todo o serviço (por exemplo: pará-lo em um nó e iniciá-lo em outro) - e é assim que HA para serviços como bancos de dados pode ser alcançado.

Outra maneira possível - se você estiver controlando roteadores próximos aos balanceadores de carga, é utilizar o ECMP. Essa abordagem também permite dimensionar balanceadores de carga horizontalmente. Isso funciona para cada uma das suas duas caixas falando BGP para o (s) seu (s) roteador (s). Cada caixa tem que anunciar o IP virtual (192.168.100.100) e o roteador carregará o tráfego do contrapeso através do ECMP. Se uma máquina morrer, ela interromperá a publicidade VIP, o que, por sua vez, impedirá que os roteadores enviem tráfego para ela. A única coisa que você precisa resolver nessa configuração é parar de anunciar o IP se o balanceador de carga morrer.

    

Answer 2

Usar o Nginx como seu balanceador de carga deve permitir que você siga o redirecionamento detalhado nesta postagem, alterando sua configuração para detectar um tempo limite sem resposta:

balanceamento de carga de failover automático do nginx

Em teoria, se você tiver um ambiente de alta disponibilidade, vários balanceadores de carga em cluster devem permitir que o serviço seja mantido se um deles falhar.

Espero que isso ajude.

    

Answer 3

Os balanceadores de carga de hardware têm suportado configurações "ativo / passivo" ou "ativo / ativo" por anos, em ambos os casos eles são configurados em paralelo a partir de uma perspectiva de camada 1/2 ... monitoramento de uso ativo / passivo / keepalive mecanismos como descrito, ativo / ativo pode ser implementado de várias maneiras. Para aparecer como um único IP no frontend, dois ou mais balanceadores podem, contanto que sejam todos / ambos on-line, fazer coisas como:

• atende seletivamente as solicitações ARP ao IP compartilhado com base em um has do endereço MAC ou IP de origem quando os clientes estão na mesma rede
• negocie entre si quem lida com o tráfego de uma determinada nova conexão TCP
• permite que o tráfego duplicado ou incorreto da camada 3-7 aconteça de forma imprudente e dependa das pilhas TCP do cliente / roteador para resolvê-lo

Em seguida, altere seu modo para aceitar todo ou mais tráfego quando a comunicação com o dispositivo / parceiro for perdida.

no lado de backend:

• cada um dos balanceadores pode, em operação normal, usar apenas um sub-conjunto de servidores de aplicativos
• ou, solicitações duplicadas podem ser simplesmente geradas aqui também ...
• ou, negociação entre balanceadores pode ser feita