Estou trabalhando em uma infraestrutura onde o tráfego http é proxy reverso por servidores httpd. Gostaríamos de continuar no httpd (em vez de considerar, por exemplo, o Nginx) porque temos muitos hosts virtuais configurados nesta plataforma.
Agora gostaria de adicionar recursos de HA e balanceamento de carga à parte do proxy reverso. Se eu criar um cluster ativo-ativo, preciso de uma solução como o DNS round robin, que não gostaria de considerar como minha primeira opção (porque é complicado de obter).
Seria uma boa solução configurar um cluster ativo-passivo HAProxy (com ip flutuante), balanceamento de carga (em modo tcp, nível 4) um cluster ativo-ativo httpd, fazendo o proxy reverso http(s) real? Desta forma eu alcançaria o seguinte:
- HA. HAProxy é tolerante a falhas, assim como o httpd
- Balanceamento de carga. Httpd são balanceados em carga (ativo-ativo). O HAProxy não é (um único host está ativo), mas presumo que ele será melhor dimensionado que o httpd no tratamento do tráfego, com um nó sendo suficiente
- Tendo balanceamento de carga HAProxy no tcp, posso deixar toda a configuração http e https no lado httpd.
Há alguma desvantagem nessa abordagem ou soluções melhores?
Responder1
Sai,
Parece que você encontrou uma solução sensata. Você está descrevendo uma implantação típica de balanceador de carga de alta disponibilidade para um cluster de aplicativos. O HAProxy oferece muita flexibilidade se e quando você precisar, e o modo de passagem TCP é agradável e simples.
O único problema é a complexidade adicional de manter de forma confiável um cluster HAProxy. Presumo que você usará Keepalived?
Aqui no Loadbalancer.org atualmente usamos Heartbeat (HA-Linux), mas em breve mudaremos para nosso próprio sistema Pulse HA com suporte ativo/ativo em vários balanceadores de carga.