É possível usar vários balanceadores de carga para redirecionar o tráfego para meus servidores de aplicativos?

Eu sou novo no balanceamento de carga e estou pensando se é possível usar vários balanceadores de carga para redirecionar o tráfego para meus servidores de aplicativos. Eu realmente não entendo como isso pode ser feito. Um nome de domínio não deve corresponder um a um com o endereço IP de um determinado servidor (nesse caso, o IP de um balanceador de carga)? Se cada servidor de balanceamento de carga tiver um IP diferente, como a solicitação pode ser recebida pelos dois balanceadores de carga (ou por 10 balanceadores de carga ou 50 ou 100)?

O uso do DNS round round não é tão bom para alta disponibilidade - se um servidor ficar offline, os clientes ainda tentarão se conectar a ele e aguardarão o tempo limite.

Existem outras maneiras de conseguir isso.
1) Balanceadores de carga ativos / passivos
Basicamente, um balanceador de carga lida com todo o tráfego para um endereço IP.
Se esse balanceador cair, o nó passivo entra em ação e assume o IP.
Lembre-se de que os balanceadores de carga são apenas o tráfego de encaminhamento, portanto, para sites pequenos e médios, isso pode funcionar bem.

2) Balanceadores de carga ativos / ativos
O mesmo IP de tráfego é configurado em ambos (ou muitos mais) balanceadores de carga.
O tráfego de entrada é enviado a todos os balanceadores de carga, mas um algoritmo escolhe qual balanceador deve responder; todos os outros descartam esse tráfego.
Maneira simples de pensar nisso, você tem dois balanceadores de carga:
quando o IP solicitante termina com um número par, o balanceador de carga A responde, caso contrário, o balanceador de carga B responde.

É claro que sua infraestrutura deve suportar isso e há sobrecarga devido ao tráfego ser enviado, mas descartado.
Mais informações, por exemplo, aqui: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

A alta disponibilidade com balanceadores de carga é geralmente implementada usando um protocolo de endereço IP virtual (VIP) que permite que vários hosts (ou seja, balanceadores de carga) respondam a um endereço IP comum de uma das várias maneiras possíveis (variações de ativo / passivo, ativo / ativo) .

Há um bom número desses protocolos, os que eu mais vi nos balanceadores de carga regulares são VRRP e NLB (além de vários protocolos em caixa preta não descritos em dispositivos). Expandindo para roteadores e firewalls, também é possível encontrar CARP , HRSP , GLSP , por exemplo.

Essa estratégia possui vários benefícios sobre o balanceamento de carga do DNS, que é uma estratégia mais simples (e tratada em outra resposta).

O balanceamento de carga do DNS está sobrecarregado, por exemplo, com:

• a lenta rotatividade dos mecanismos de cache do DNS
• algoritmos de balanceamento de carga limitados (geralmente apenas round-robin)
• a terceirização da decisão de balanceamento de carga para o cliente (através do armazenamento em cache do registro DNS)
• Drenagem lenta das filas de serviço quando um servidor (ou seja, um balanceador de carga) é retirado de rotação (com base em TTLs de registro DNS conforme manipulado por ISPs e clientes )
• Failover lento na falha do balanceador de carga

Usando um protocolo IP virtual para HA, pode-se escolher, por exemplo:

• Escolha do algoritmo de balanceamento de carga entre os balanceadores de carga
• Decisões de balanceamento de carga centralizadas no servidor (facilitando, por exemplo, medidas e roteamento com base na integridade do serviço)
• Drenagem mais rápida das filas de serviço quando um balanceador de carga é retirado de rotação.
• Failover instantâneo na falha do balanceador de carga

Somente você sabe qual estratégia e protocolo se encaixa melhor no seu cenário.

Os requisitos: ter uma solução prática que funcione para nuvem ou qualquer tipo de ambiente em que não haja acesso a balanceadores de carga de hardware, protocolos BGP e tudo mais.

O número de solicitação de renda de um aplicativo é desconhecido, mas deve ser alto o suficiente para atender a uma expectativa de carga aumentada sem medo.

Vamos encontrar um aplicativo com natureza semelhante de carga, por exemplo, loja de log e aplicativo de pesquisa. Eu encontrei um .

O que eles querem:

1. Equilibre a carga entre os coletores
2. Oferecer tolerância a falhas, permitindo continuar a ingestão de dados se um dos coletores morrer ou estiver com problemas
3. Dimensione horizontalmente com o crescimento de nossos volumes de log

O que eles tentaram e aprenderam sobre o ELB:

1. Não funciona como esperado
2. Problemas de latência devido ao aumento de carga
3. Instalação de monitoramento insuficiente
4. Limitação demais (número de portas e protocolos abertos)

Por que eles escolheram com o Route53:

1. "O round robin é um balanceamento de carga bastante básico, mas funciona bem para nós do ponto de vista da eficiência"
2. "Aproveitamos as verificações de integridade de failover da Rota 53".
3. "Se houver um problema com um colecionador, o Route 53 o retirará automaticamente do serviço; nossos clientes não verão nenhum impacto".
4. Não é necessário pré-aquecimento com o Route 53

A rota 53 acabou sendo a melhor maneira de a Loggly tirar proveito de nossos coletores de alto desempenho, dados nossos enormes volumes de toras, variações imprevisíveis e crescimento constante em nossos negócios. Ele se alinha aos principais objetivos dos coletores: coletar dados na velocidade da linha de rede com perda zero e nos permite beneficiar da elasticidade de todos os serviços da AWS que usamos na Loggly.

Esse exemplo em particular mostra que, em alguns cenários (coletor de logs, serviço de anúncios ou similar), o balanceador de carga é redundante e a "solução de rodízio de verificação de integridade do DNS" faz seu trabalho muito bem.

Vamos ver o que a AWS diz sobre o failover de DNS:

Com o Failover de DNS, o Route 53 pode detectar uma interrupção do seu site e redirecionar seus usuários finais para locais alternativos ou de backup que você especificar. O Failover de DNS da rota 53 depende de verificações de integridade - fazendo regularmente solicitações da Internet para os terminais de seus aplicativos de vários locais ao redor do mundo - para determinar se cada terminal de seu aplicativo está ativo ou inativo.

Essa técnica também torna o ELB (não obrigatório, apenas para uma observação) mais robusto, mais uma vez, é baseado no RR + Health Check:

O failover de DNS da rota 53 lida com todos esses cenários de falha, integrando-se ao ELB nos bastidores. Uma vez ativado, o Route 53 configura e gerencia automaticamente verificações de integridade de nós ELB individuais.

Vamos agora ver como funciona nos bastidores. A pergunta óbvia é como lidar com o cache do DNS:

No entanto, o cache do DNS ainda pode ser um problema aqui (consulte nossa postagem anterior, onde o problema da "cauda longa" é abordado) se o TTL não for respeitado por todas as camadas entre o cliente e o Route 53. Você poderá aplicar uma técnica de "impedimento de cache": envie uma solicitação para um domínio único

("http://<unique-id>.<your-domain>") 

e defina um Recurso Curinga

Record "*.<your-domain>" to match it.

A Algolia introduziu a "estratégia de nova tentativa do cliente", que funciona muito bem se o seu cliente (JS no seu caso) puder lidar com isso:

Acabamos implementando uma estratégia básica de repetição em nossos clientes de API. Cada cliente da API foi desenvolvido para poder acessar três máquinas diferentes. Três registros DNS diferentes representavam cada usuário: USERIDID-1.algolia.io, USERID-2.algolia.io e USERID-3.algolia.io. Nossa primeira implementação foi selecionar aleatoriamente um dos registros e tentar novamente com outro diferente em caso de falha.