Keepalived e HAProxy no Debian 13 formam a base clássica de alta disponibilidade em VPS: o Keepalived gerencia o IP virtual (VIP) via VRRP e o HAProxy faz o balanceamento e os health checks dos backends. Sem estado compartilhado ou replicação de dados, o failover só move o tráfego. Para montar HA com Keepalived e HAProxy no Debian 13, siga estes passos:
- Prepare dois nós Debian 13 idênticos, rede e sysctl para VIP
- Instale e configure o HAProxy com health check HTTP/TCP
- Instale o Keepalived e defina MASTER/BACKUP com o mesmo VIP
- Ajuste firewall, script de checagem e prioridade VRRP
- Valide o VIP, o balanceamento e o failover controlado
- Documente failback, monitoramento e sincronização de dados
Pré-requisitos
- Dois VPS Debian 13 (ou mais) na mesma rede L2 ou com unicast VRRP suportado pelo provedor
- Acesso root ou sudo em ambos os nós e SSH estável entre eles
- IPs fixos de exemplo: nó A 203.0.113.10, nó B 203.0.113.11, VIP 203.0.113.100
- Aplicação web escutando em cada nó (porta 8080 neste guia) ou backend TCP equivalente
- Pacotes oficiais: keepalived e haproxy do repositório Debian 13
- Relógio sincronizado (chrony/systemd-timesyncd), hostname distinto e DNS A apontando ao VIP quando for expor o serviço
- Plano de replicação de banco ou storage compartilhado — o VIP sozinho não replica dados
Se ainda está escolhendo o tipo de máquina, vale reler o material Compreendendo o Servidor VPS: O que é e Como Funciona! e o fluxo de acesso em Acessando servidores VPS Linux da AviraHost.
Keepalived e HAProxy no Debian 13: arquitetura do cluster
O desenho mais usado em produção pequena e média coloca HAProxy em cada nó, atrás de um VIP anunciado pelo Keepalived. O cliente fala sempre com 203.0.113.100; o nó MASTER detém o VIP e o HAProxy local distribui (ou encaminha) para os backends saudáveis. Em modo ativo-passivo simples, o HAProxy do MASTER aponta preferencialmente para o app local e usa o outro nó como backup; em ativo-ativo, ambos recebem tráfego conforme o algoritmo e o VIP migra só se o MASTER falhar.
Alta disponibilidade de aplicação exige três camadas alinhadas: rede (VIP/VRRP), proxy (HAProxy com checks) e dados (replicação MariaDB/PostgreSQL, object storage ou volume sincronizado). Sem a terceira camada, um failover “bem-sucedido” pode servir estado velho ou erro de sessão. Padronize kernel sysctl, regras de firewall e versões de pacote nos dois Debian 13 para evitar split behavior no failback.
Long-tails naturais neste cenário incluem failover VRRP Debian, IP virtual Keepalived, balanceamento HAProxy backend down e checklist HA VPS Linux. Mantenha a mesma interface de rede nos configs (eth0 ou o nome real via ip -br link) e reserve o VIP exclusivamente para o cluster — não reutilize o endereço em outro serviço.
Instalar HAProxy e preparar health checks
Balanceamento de carga com checagem de backend é o papel do HAProxy; instale-o de forma idêntica nos dois nós antes de subir o VIP, para que qualquer MASTER já tenha proxy funcional.
sudo apt update
sudo apt install -y haproxy
haproxy -v
sudo systemctl enable haproxyOutput esperado:
HA-Proxy version 2.x.x-1+deb13u1 ...
Crie um backend de exemplo escutando na 8080 em cada nó (nginx, app Node, PHP-FPM atrás de um listener local, etc.). Em seguida edite /etc/haproxy/haproxy.cfg com frontend no VIP/porta 80 e servers apontando aos IPs reais:
global
log /dev/log local0
maxconn 4096
user haproxy
group haproxy
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5s
timeout client 50s
timeout server 50s
option forwardfor
option http-server-close
frontend fe_web
bind 203.0.113.100:80
default_backend be_app
backend be_app
balance roundrobin
option httpchk GET /health
http-check expect status 200
server app1 203.0.113.10:8080 check inter 2s fall 3 rise 2
server app2 203.0.113.11:8080 check inter 2s fall 3 rise 2Atenção: o bind no VIP só aceita conexões quando o endereço estiver configurado na interface (Keepalived sobe o VIP). Em testes isolados do HAProxy, use temporariamente bind *:80 ou o IP do nó e volte ao VIP antes da produção.
sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl restart haproxy
sudo systemctl status haproxy --no-pagerOutput esperado:
Configuration file is valid
Active: active (running)Exponha um endpoint /health que reflita dependências críticas (processo up e, se possível, leitura no banco). Check genérico em “/” mascara falha de aplicação. Confira sockets com ss -lntp | grep -E '80|8080'. Para HTTPS na borda, termine TLS no HAProxy ou em proxy à frente e mantenha o health check coerente com o modo (mode http vs mode tcp).
Configurar Keepalived VIP e failover VRRP
IP virtual e eleição MASTER/BACKUP ficam a cargo do Keepalived. Instale e habilite o serviço nos dois Debian 13:
sudo apt install -y keepalived
sudo systemctl enable keepalivedNo nó A (MASTER), use prioridade maior e o mesmo virtual_router_id do BACKUP. Ajuste a interface com o nome real da NIC:
sudo tee /etc/keepalived/keepalived.conf > /dev/null <<'EOF'
vrrp_script chk_haproxy {
script "/usr/bin/killall -0 haproxy"
interval 2
weight -20
fall 2
rise 2
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass S3nhaVRRP_Troque
}
virtual_ipaddress {
203.0.113.100/24
}
track_script {
chk_haproxy
}
}
EOFNo nó B, copie o arquivo trocando state BACKUP e priority 100 (ou 130 se quiser failback menos agressivo). A senha VRRP e o virtual_router_id devem ser iguais no cluster e únicos na LAN.
sudo systemctl restart keepalived
ip -br addr show eth0
sudo journalctl -u keepalived -n 30 --no-pagerOutput esperado (MASTER):
eth0 UP 203.0.113.10/24 203.0.113.100/24
... Entering MASTER STATE ...
Se o provedor bloquear multicast VRRP, configure unicast_peer com os IPs dos nós — recurso comum em clouds. Libere no firewall o protocolo VRRP (IP 112) entre os membros e as portas do HAProxy expostas ao cliente. Sysctl úteis em ambos:
echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/99-ha.conf
sudo sysctl --systemip_nonlocal_bind permite ao HAProxy fazer bind no VIP antes dele existir na interface, reduzindo janela de recusa na transição. Valide com curl -sS -o /dev/null -w '%{http_code}\n' http://203.0.113.100/health a partir de um terceiro host. Para zona DNS do serviço público, o registro A deve apontar ao VIP; o guia Guia de zona DNS: registros A, MX, CNAME e TXT do zero ajuda a não misturar apex e www na hora do corte.
Testar failover, failback e sincronização
Teste de comutação controlada evita surpresa em incidente real. Em janela curta, no MASTER atual:
sudo systemctl stop haproxy
# ou: sudo systemctl stop keepalived
ip -br addr show eth0
sudo journalctl -u keepalived -n 50 --no-pager | egrep 'MASTER|BACKUP|FAULT'No BACKUP você deve ver transição para MASTER e o VIP 203.0.113.100 aparecer na interface. Do cliente:
curl -sS http://203.0.113.100/health
ping -c 4 203.0.113.100Output esperado:
200
64 bytes from 203.0.113.100: icmp_seq=1 ttl=64 time=0.x ms
Reative o serviço no nó original e observe a política de failback: com prioridade fixa maior, o antigo MASTER retoma o VIP; se preferir estabilidade, equalize prioridades ou use nopreempt conforme a versão e a política do time. Monitore show stat do socket do HAProxy se habilitado, e alertas de CPU/rede nos dois VPS.
Lembre: escalabilidade horizontal de app stateless combina com roundrobin; sessões em disco local exigem sticky session (balance source ou cookie) ou preferencialmente sessão em Redis/DB replicado. HA de e-mail ou banco é outro desenho — não reutilize este VIP sem replicação adequada. Se serviços systemd falharem ao subir após o boot, o artigo Como solucionar problemas de inicialização de serviços no VPS Linux: Guia Completo complementa o diagnóstico de unit files.
Problemas comuns e como resolver
Sintoma: VIP não aparece em nenhum nó
Causa: interface errada no keepalived.conf, VRRP bloqueado, IDs/senhas divergentes ou serviço inativo.
Solução: confira ip -br link, systemctl status keepalived, logs e conectividade IP 112 entre nós. Unifique virtual_router_id e auth_pass. Teste unicast se multicast for filtrado.
Sintoma: VIP migra sem parar (flapping)
Causa: script chk_haproxy instável, prioridade com weight que inverte eleição a cada check, ou rede com perda de advert.
Solução: aumente interval/fall com critério, garanta HAProxy estável, revise peso negativo e latência entre nós. Evite scripts pesados no track_script.
Sintoma: VIP no MASTER mas HTTP falha no cliente
Causa: HAProxy bind só no VIP sem ip_nonlocal_bind, backend down, firewall na 80/443 ou health check exigindo path inexistente.
Solução: valide haproxy -c, ss -lntp, curl local na 8080, logs em /var/log/haproxy.log e regras nftables/ufw. Ajuste httpchk ao endpoint real.
Sintoma: failover ok, dados inconsistentes
Causa: app com arquivos locais ou banco single-node sem réplica.
Solução: implemente replicação de banco, storage compartilhado ou deploys idênticos com sessão externa antes de declarar HA de produção.
Perguntas frequentes sobre Keepalived e HAProxy no Debian 13
O que é necessário para alta disponibilidade em VPS Linux?
Você precisa de pelo menos dois nós com a mesma stack de aplicação, um IP virtual (VIP) gerenciado por Keepalived ou equivalente, balanceamento com HAProxy ou similar, health checks e sincronização de dados (replicação de banco ou storage compartilhado). Sem estado compartilhado ou replicação, o failover só troca o tráfego e a aplicação pode ficar inconsistente.
Keepalived e HAProxy fazem a mesma coisa?
Não. O Keepalived costuma cuidar do VIP e do failover via VRRP, elegendo qual nó anuncia o endereço. O HAProxy faz balanceamento de carga e checagem de backends HTTP/TCP. Em cenários de HA costumam ser usados juntos: VIP no Keepalived e distribuição de requisições no HAProxy.
Posso ter alta disponibilidade com um único VPS?
Não de forma real. Um único servidor elimina o ponto único de falha de software pontual com restart e monitoramento, mas não cobre queda de hardware, hypervisor ou rede do nó. HA exige redundância de instâncias e caminho de failover testado.
Como testar o failover sem derrubar produção o dia inteiro?
Em janela controlada, pare o HAProxy ou o Keepalived no nó master, ou bloqueie a porta do health check, e confira se o VIP migra e se o backend saudável responde. Monitore logs do Keepalived, status do HAProxy e o IP no cliente. Depois reative o nó e valide o failback se a política permitir.
Qual distribuição usar para esse checklist em 2026?
Debian 13 é uma base estável e atual para Keepalived e HAProxy com pacotes do repositório oficial. O importante é padronizar a mesma versão nos nós, manter relógio sincronizado e documentar sysctl, firewall e scripts de health check iguais em todos os membros do cluster.
Conclusão
- Deixe HAProxy saudável e com
/healthreal nos dois nós antes de confiar no VIP do Keepalived. - Trate VRRP, firewall e
ip_nonlocal_bindcomo parte do mesmo checklist — rede quebrada invalida o proxy perfeito. - Automatize um teste de failover periódico e só chame de HA se dados e sessões sobreviverem à comutação.
Leia também
- Solucionar problemas de resolução de nomes DNS em VPS Linux e servidor dedicado
- Solucionar problemas de limitação de portas no Linux para aplicações web em VPS e servidor dedicado
- Como solucionar problemas de rede em VPS Linux: Guia Completo
Precisa de ajuda com Keepalived e HAProxy no VPS?
Um cluster HA bem desenhado reduz downtime, mas exige rede, proxy e dados alinhados. Se quiser nós Debian prontos para montar VIP e balanceamento com previsibilidade, avalie um VPS dimensionado para redundância real.
