Como posso implantar um cluster haproxy escalável e confiável no Amazon EC2?

Question

Precisamos de algumas funcionalidades mais avançadas do que a ELB (principalmente a inspeção L7), mas não é óbvio como lidar com coisas como pulsação e alta disponibilidade com algo como o haproxy usando o EC2. Há uma grande probabilidade de precisarmos de 3 ou mais nós haproxy no cluster, portanto a pulsação simples entre dois nós não funcionará.

Parece que ter uma camada heartbeat'd na frente dos nós haproxy seria o caminho a percorrer, possivelmente usando IPVS, mas manipulando as alterações de configuração conforme o cluster EC2 é alterado (seja por alterações intencionais, como expansão ou não intencionais, como perder um nó EC2) parece não-trivial.

De preferência, a solução abrangeria pelo menos duas zonas de disponibilidade.

Em resposta a Qs: Não, as sessões não são fixas. E sim, precisaremos de SSL, mas isso poderia, em teoria, ser tratado por outra configuração completamente - podemos direcionar o tráfego SSL para um local diferente do tráfego não-SSL.

    

Answer 1

OK, eu nunca construí uma solução de balanceamento de carga da AWS com tráfego nos níveis do SmugMug, mas pensando apenas em teoria e nos serviços da AWS, algumas idéias vêm à mente.

A pergunta original está faltando algumas coisas que tendem a afetar o design de balanceamento de carga:

1. Sessões pegajosas ou não? É muito preferível não usar a sessão persistente, e apenas permitir que todos os balanceadores de carga (LB's) usem round robin (RR) ou seleção aleatória de backend. As seleções de back-end RR ou aleatórias são simples, escalonáveis e fornecem distribuição de carga uniforme em todas as circunstâncias.
2. SSL ou não? Se o SSL está em uso ou não, e sobre qual porcentagem de solicitações, geralmente tem um impacto no design de balanceamento de carga. Geralmente, é preferível encerrar o SSL o mais cedo possível, simplificar o processamento de certificados e manter a carga da CPU SSL longe dos servidores de aplicativos da Web.

Estou respondendo da perspectiva de como manter a camada de balanceamento de carga altamente disponível. Manter o HA dos servidores de aplicativos acaba de ser feito com as verificações de integridade incorporadas nos balanceadores de carga do L7.

OK, algumas ideias que devem funcionar:

1) "O caminho da AWS":

• A primeira camada, na frente, usa o ELB no modo L4 (TCP / IP).
• Segunda camada, use instâncias do EC2 com o balanceador de carga L7 de sua preferência (nginx, HAProxy, Apache, etc.).

Benefícios / ideia: Os balanceadores de carga L7 podem ser EC2 AMI bastante simples, todos clonados a partir da mesma AMI e usando a mesma configuração. Assim, as ferramentas da Amazon podem lidar com todas as necessidades de alta disponibilidade: o ELB monitora os balanceadores de carga L7. Se um L7 LB morre ou não responde, ELB & Cloudwatch juntos geram uma nova instância automaticamente e a trazem para o pool de ELB.

2) "O DNS round robin com o modo de monitoramento:"

• Use round robin de DNS básico para obter uma distribuição de carga de baixa granularidade em alguns endereços IP. Digamos que você publique três endereços IP para o seu site.
• Cada um desses 3 IPs é um endereço IP elástico da AWS (EIA), vinculado a uma instância do EC2, com um balanceador de carga L7 de sua escolha.
• Se um EC2 L7 LB morre, um agente de usuário compatível (navegador) deve usar apenas um dos outros IPs em vez disso.
• Configure um servidor de monitoramento externo. Monitore cada um dos 3 EIPs. Se alguém não responder, use as ferramentas de linha de comando da AWS e alguns scripts para mover o EIP para outra instância do EC2.

Benefícios / ideia: Os agentes de usuário em conformidade devem alternar automaticamente para outro endereço IP se um não responder. Assim, no caso de uma falha, apenas 1/3 dos seus usuários devem ser afetados, e a maioria deles não deve perceber nada, já que o seu UA falha silenciosamente em outro IP. E sua caixa de monitoramento externo notará que um EIP não responde e corrigirá a situação dentro de alguns minutos.

3) DNS RR para pares de servidores de HA:

Basicamente, esta é a sugestão do próprio Don de pulsação simples entre um par de servidores, mas simplificada para vários endereços IP.

• Usando o DNS RR, publique vários endereços IP para o serviço. Seguindo o exemplo acima, digamos que você publique 3 IPs.
• Cada um desses IPs vai para um par de servidores do EC2, portanto, 6 instâncias do EC2 no total.
• Cada um desses pares usa o Heartbeat ou outra solução de HA juntamente com as ferramentas da AWS para manter 1 endereço IP ativo, em uma configuração ativa / passiva.
• Cada instância do EC2 tem seu balanceador de carga L7 escolhido.

Benefícios / ideia: No ambiente totalmente virtualizado da AWS, na verdade, não é tão fácil raciocinar sobre os serviços L4 e os modos de failover. Ao simplificar para um par de servidores idênticos, mantendo apenas 1 endereço IP ativo, fica mais simples raciocinar e testar.

Conclusão: Novamente, não tentei nada disso na produção. Apenas do meu pressentimento, a opção 1 com o ELB no modo L4 e instâncias do EC2 autogerenciadas como L7 LBs parecem mais alinhadas com o espírito da plataforma da AWS, e onde a Amazon provavelmente irá investir e expandir mais tarde. Esta provavelmente seria minha primeira escolha.

    

Answer 2

Se você não estiver fazendo sessões fixas ou se estiver usando o estilo tomcat / apache (anexe o ID do nó ao sessionid, em vez de armazenar o estado no LB), use o ELB na frente de um grupo de haproxies. O ELB tem um healthcheck embutido, para que você possa monitorar as haproxies e tirar as de baixo da piscina. Muito menos para configurar do que o failover de pulsação.

No que diz respeito à propagação de alterações, não tenho uma resposta excelente. O Puppet é ótimo para configuração inicial e implementação de alterações, mas para adicionar / remover nós, você tende a querer uma resposta mais rápida do que seu intervalo de pesquisa de 30 minutos.

    

Answer 3

Eu não usei isso sozinho, mas eu vi muitas pessoas mencionarem o uso do fantoche para lidar com esses problemas no EC2