Alta Disponibilidade (VIP / Keepalived)
Esta página descreve o desenho e a operação do VIP usado no homelab para manter o endpoint de entrada estável durante falhas de nó.
🎯 Objetivo
Section titled “🎯 Objetivo”- manter um IP único de entrada para os serviços publicados
- reduzir impacto de falha de um nó do proxy
- padronizar diagnóstico de estado MASTER/BACKUP
📋 Resumo operacional
Section titled “📋 Resumo operacional”Topologia
Section titled “Topologia”| Componente | RPi | NAS | Endereço |
|---|---|---|---|
| keepalived | participa do cluster | participa do cluster | VIP 192.168.1.20 |
| status HA | :9080/status.json | :9080/status.json | estado por nó |
Fonte da verdade
Section titled “Fonte da verdade”- definição de arquitetura de VIP nesta página
- operação diária referenciada pelos runbooks de NPM
Dependências
Section titled “Dependências”- conectividade L2/LAN entre os nós
- keepalived ativo nos dois hosts
- NPM operacional nos dois nós para failover útil
- DNS interno apontando serviços publicados para
192.168.1.20
Comandos de validação
Section titled “Comandos de validação”curl http://192.168.1.20:9080/status.jsoncurl http://192.168.1.11:9080/status.jsoncurl http://192.168.1.10:9080/status.jsonip addr | grep 192.168.1.20arp -a | grep 192.168.1.20Limitações
Section titled “Limitações”- VIP não sincroniza configuração de aplicação
- VIP ativo não garante backend saudável
- split brain é possível com configuração/cluster incorretos
Última validação
Section titled “Última validação”- 20/04/2026
🧱 Como funciona
Section titled “🧱 Como funciona”O keepalived mantém uma eleição entre os nós:
- um nó fica como MASTER e anuncia o VIP
- outro nó fica como BACKUP
- em falha do MASTER, o BACKUP assume o VIP
Resultado esperado:
- clientes continuam usando o mesmo destino (
192.168.1.20) - não há mudança de DNS durante failover
🔁 Comportamento esperado
Section titled “🔁 Comportamento esperado”| Situação | Estado esperado |
|---|---|
| Operação normal | RPi MASTER, NAS BACKUP |
| Queda do RPi | NAS assume MASTER |
| Retorno do RPi | retorno ao estado normal definido pela política |
⚠️ Riscos operacionais
Section titled “⚠️ Riscos operacionais”- Split brain: ambos os nós se anunciam MASTER
- flapping: troca constante de MASTER/BACKUP
- falso positivo: VIP ativo com NPM ou backend quebrado
Mitigação:
- usar apenas um cluster keepalived ativo
- validar estado por
status.json - validar caminho fim a fim via domínio (não só VIP)
🧪 Checklist de verificação
Section titled “🧪 Checklist de verificação”- VIP responde (
192.168.1.20) - apenas um nó está MASTER
- DNS resolve domínios para o VIP
- acesso via domínio funciona após failover
- retorno ao estado esperado ocorre sem intervenção manual