HAProxy load balancing: guia passo a passo

HAProxy load balancing distribui requisições entre vários servidores usando um frontend que recebe conexões e um backend que agrupa os servidores reais. Configura-se no arquivo haproxy.cfg, com modo tcp ou http, algoritmo de balanceamento e health checks para remover instâncias indisponíveis automaticamente.

Este guia parte de uma instalação limpa e chega a um balanceador funcional em poucos passos. Pré-requisitos: HAProxy instalado (versão estável do repositório da distribuição), pelo menos dois servidores de aplicação acessíveis na rede, e permissão para editar arquivos em /etc/haproxy. O resultado esperado é um endpoint único que distribui tráfego e retira da rotação qualquer backend que pare de responder.

Passo 1: Entenda a estrutura do haproxy.cfg

O arquivo se divide em global, defaults, frontend e backend. O bloco global define processos e logs; defaults estabelece timeouts; frontend escuta a porta; backend lista os servidores. Sem timeouts explícitos, conexões lentas podem consumir recursos indefinidamente. Erro comum: deixar timeout client e timeout server com valores muito altos, o que mascara falhas de aplicação.

Passo 2: Configure o frontend

No frontend, defina bind na porta 80 ou 443 e mode http (ou tcp para protocolos não-HTTP). Exemplo de diretiva: bind *:80 seguido de default_backend app_servers. A dica é separar frontends por porta ou domínio desde o início, evitando reescrever a configuração quando surgir um segundo serviço.

Passo 3: Monte o backend e escolha o algoritmo

No backend, aponte server linhas para cada instância, com nome, IP e porta. O algoritmo roundrobin distribui em sequência; leastconn favorece quem tem menos conexões e costuma render melhor com requisições de duração desigual. Um contraexemplo prático: em sessões longas, roundrobin pode concentrar carga em um servidor recém-adicionado.

Passo 4: Ative health checks

Adicione option httpchk e uma linha check em cada server. O HAProxy passa a testar periodicamente e remove da rotação quem falha. Ajuste inter e fall para não gerar falsos positivos em picos de latência. Erro comum: usar apenas check sem definir a URL de verificação, o que testa a porta e não a aplicação.

Passo 5: Valide e recarregue

Antes de aplicar, rode haproxy -c -f /etc/haproxy/haproxy.cfg para checar a sintaxe. Depois, recarregue com systemctl reload haproxy, que preserva conexões ativas. Teste com curl repetido no endpoint e confirme a alternância entre backends.

Checklist final

• Frontend com bind e mode definidos
• Backend com todos os servers nomeados
• Algoritmo escolhido conforme o perfil de tráfego
• Health check ativo com URL de verificação
• Timeouts explícitos em defaults
• Sintaxe validada antes do reload

FAQ

O que é HAProxy load balancing?

É a distribuição de requisições entre múltiplos servidores por meio do HAProxy, um proxy reverso que atua como ponto único de entrada. Ele recebe conexões no frontend, encaminha ao backend conforme o algoritmo configurado e retira da rotação servidores que falham nos health checks.

Qual algoritmo de balanceamento usar?

Depende do perfil. Roundrobin serve para requisições curtas e homogêneas. Leastconn é mais indicado quando as conexões duram tempos diferentes. Source mantém a mesma origem no mesmo servidor, útil quando não há sessão compartilhada entre as instâncias.

Como testar se o balanceamento está funcionando?

Execute curl várias vezes contra o endpoint e observe qual backend responde. Com health check ativo, derrube um servidor de teste e confirme que ele sai da rotação. O log do HAProxy registra cada requisição e o servidor escolhido.

Preciso reiniciar o HAProxy para aplicar mudanças?

Não. O comando systemctl reload haproxy recarrega a configuração sem encerrar conexões em andamento, desde que a sintaxe esteja válida. Reiniciar só é necessário em alterações que afetam o processo principal.

O que acontece se todos os backends falharem?

Sem servidores disponíveis, o HAProxy retorna erro 503 ao cliente. Para mitigar, configure um backend de fallback com uma página estática ou um servidor de reserva, acionado quando nenhum membro do backend principal passa no health check.