haproxy e keepalived no Amazon EC2

Question

O novo serviço Amazon Opsworks usa haproxy em vez do balanceador de carga elástico muito limitado da Amazon, então comecei a investigar o haproxy como uma opção melhor para balanceamento de carga de nossos servidores de aplicativos web, fornecendo failover de sessão etc. sem problemas com um servidor haproxy e vários servidores de aplicativos da web, mas eu gostaria de evitar o SPOF.

A minha pergunta é, eu preciso configurar uma segunda placa de rede em cada servidor haproxy possivelmente com o mesmo endereço IP interno 10.0.0.x? Como a atribuição de um endereço externo (IP elástico) e o encaminhamento do tráfego para o IP interno são feitos pela Amazon, não tenho certeza de como configurá-lo.

Acho que descobri e estou testando agora - você usa o IP interno do servidor principal para keepalived em ambos os servidores.

    

Answer 1

Eu também uso o haproxy para nosso balanceamento de carga porque, no momento do design, o Elastic Load Balancing (ELB) da Amazon não suportava servidores dentro de um VPC. Eles têm esse recurso agora (eu acredito, não usei desde haproxy está funcionando muito bem para nós).

Não tentamos manter o serviço ativo por dois motivos:

1. Nós duvidamos que pudéssemos mudar o IP privado no servidor sem passar pelo AWS (console ou API). Além disso, a AWS não permite que dois servidores dentro da mesma VPC tenham o mesmo endereço IP interno.
2. Precisamos de uma configuração multi-AZ para alta disponibilidade. O IP interno do servidor dentro de um VPC é baseado na sub-rede VPC e cada sub-rede pode pertencer a apenas 1 VPC. Portanto, não podemos ter dois hosts em dois AZs diferentes dentro da mesma sub-rede.

Portanto, a solução que implementamos foi:

• Configurar o haproxy em dois servidores (um em cada AZ)
• Divida também nossos servidores de backend (por exemplo, da Web) em dois ou mais AZs
• Defina o Elastic IP para um dos servidores haproxy (no AZ "primário" de nossa escolha). Esse é o VIP que os clientes da Web acessarão.
• Monitore o VIP de uma fonte externa (fora dessa região da AWS). No caso de uma falha (instância ou o AZ inteiro), remapear o Elastic IP para o servidor haproxy secundário (supondo que os testes estejam passando nesse host).
  • EIP Ref: link
  • Nota: Estamos fazendo isso manualmente por enquanto (muito raramente necessário - uma ou duas vezes por ano para interrupções de AZ), mas isso pode ser facilmente roteirizado usando APIs da AWS e fazer com que o servidor de monitoramento ative a alternância na condição de falha.
  • Observe também que há um custo para os remapicos de EIP (US $ 0,10 por remapeamento sobre os 100 remapeamentos gratuitos por mês). Como as interrupções do AZ são relativamente raras, não acho que isso seja um problema.

Um risco potencial é que, no momento de interrupções importantes da AWS, às vezes percebemos que o console da AWS e a API começarão a falhar (completamente ou com mais frequência do que o normal). Isso pode impactar as tentativas de remapear o IP elástico.