☰

Como fazer balanceadores de carga redundantes?

tag-icon • tag-icon nginx load-balancing redundancy load-balance
Como fazer balanceadores de carga redundantes?

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

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

Isso pressupõe que você não esteja usando nenhum serviço de terceiros, como AWS ELB ou algo semelhante. O que fazer se você estiver usando apenas o Nginx?

Responder1

Existem algumas maneiras de obter HA (alta disponibilidade) de um balanceador de carga - ou de 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ê deseja fazer é separar o IP de uma 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 Unix são (u)carp e keepalived, alguns dos mais complexos são, por exemplo, RedHat Cluster Suite ou Pacemaker.

Vamos tomar o keepalived como exemplo - dois serviços keepalived - cada um rodando em sua própria caixa - e eles se comunicam entre si. Essa comunicação costuma ser chamada de batimento cardíaco.

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

Se um keepalived parar de responder (ou o serviço cai por qualquer motivo, ou a caixa salta ou desliga) - o keepalived em outra caixa notará batimentos cardíacos perdidos e presumirá que outro nó está morto e executará ações de failover. Essa ação no nosso caso será trazer à tona o IP flutuante.

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

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

Outra armadilha dessa configuração é a divisão do cérebro - quando ambas as 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 isolamento (reserva de SCSI, reinicialização de IPMI, corte de energia da PDU inteligente, ...) ou um número ímpar de nós que exigem que a maioria dos membros do cluster esteja ativa para que o serviço seja iniciado.

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

Softwares de gerenciamento de cluster mais complexos (como o Pacemaker) podem mover todo o serviço (por exemplo: pará-lo em um nó e iniciá-lo em outro) - e é assim que a HA para serviços como bancos de dados pode ser alcançada.

Outra maneira possível - se você estiver controlando roteadores próximos aos balanceadores de carga, é utilizar o ECMP. Essa abordagem também permite dimensionar horizontalmente os balanceadores de carga. Isso funciona com cada uma de suas duas caixas comunicando BGP com seu (s) roteador (es). Cada caixa deve anunciar o IP virtual (192.168.100.100) e o roteador irá balancear a carga do tráfego via ECMP. Se uma máquina morrer, ela deixará de anunciar VIP, o que, por sua vez, impedirá que os roteadores enviem tráfego para ela. A única coisa que você precisa cuidar nesta configuração é parar de anunciar o IP se o próprio balanceador de carga morrer.

Responder2

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 nginx

Em teoria, se você tiver um ambiente de alta disponibilidade, vários balanceadores de carga agrupados deverão permitir a manutenção do serviço caso um deles falhe.

Espero que isto ajude.

Responder3

Os balanceadores de carga de hardware suportam configurações "ativas/passivas" ou "ativas/ativas" há anos; em ambos os casos, eles são configurados em paralelo a partir de uma perspectiva de camada 1/2... ativo/passivo usa mecanismos de monitoramento/manutenção de atividade, conforme descrito , ativo/ativo pode ser implementado de várias maneiras. Para aparecer como um único IP no frontend, dois ou mais balanceadores podem, desde que estejam todos/ambos online, fazer coisas como:

  • responder seletivamente a solicitações ARP para o IP compartilhado com base no endereço MAC ou IP de origem quando os clientes estão na mesma rede
  • negociar entre si quem lida com o tráfego de uma determinada nova conexão TCP
  • deixe o tráfego duplicado ou errôneo das camadas 3 a 7 acontecer de forma imprudente e confie nas pilhas TCP do cliente/roteador para resolver o problema

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

no lado do back-end:

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

informação relacionada