O que você realmente precisa saber sobre floating sandbox na prática
Eu perdi três dias inteiros porque um floating sandbox não assumia o IP quando o nó primário caía. O cluster ficava ali, parado, sem fazer failover. O logs mostravam que o resource estava marcado como "down" mas ninguém pegando. Depois de raspar a cabeça por horas, descobri que era um conflito entre o floating IP e as regras de ARP do firewall no nó standby. A solução foi mais simples do que eu esperava — desativar o arp_ignore e colocar o arp_announce em 3, mas isso já era tarde para o deploy que eu tinha para entregar. O conceito de floating sandbox em si é basicamente uma técnica de virtualização onde recursos de rede ou IPs flutuam entre nós de um cluster sem precisar de configuração manual de failover. Você define qual é o proprietário atual e o sistema transfere automaticamente quando algum nó cai ou fica sobrecarregado. Parece direto até você tentar implementar em ambiente de produção.
Configurando um floating sandbox do zero
Você começa escolhendo a stack. Os mais usados hoje são corosync com pacemaker, HAProxy com keepalived, ou soluções nativas de cloud como as AWS elastic IPs e Google Cloud internal HTTP(S) load balancing. Se estiver em VMs sobre VMware ou Proxmox, o próprio gerenciador já vem com suporte a floating IPs embutido. A configuração base segue esse padrão: dois ou mais nós, um IP virtual compartilhado, um agente de health check rodando em cada nó monitorando o serviço, e um mecanismo de eleição. O node com status ativo ganha o IP. Quando ele para de responder nos intervalos configurados, o próximo em prioridade assume. Isso tudo acontecendo tipicamente em 2 a 5 segundos dependendo dos timeouts.
Veja um exemplo prático com keepalived num par de servidores web. O arquivo de configuração no nó primário seria algo como: global_defs que rod = 200
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication { auth_type pass auth_pass sua_senha_aqui }
virtual_ipaddress { 192.168.1.200/24 }
}
No standby, tudo igual exceto state BACKUP e priority 90. O IP 192.168.1.200 é o floating que vai migrar entre os nós. Quando o MASTER cai, o BACKUP detecta em 3 ciclos de advertisement (3 segundos) e começa a responder ARP pelo endereço flutuante. Clientes não percebem a interrupção se o timeout deles for maior que isso. O problema é que na prática quase nada funciona exatamente como o tutorial mostra. A primeira coisa que quebra são conflicts de MAC address. Quando dois nós tentam anunciar o mesmo IP simultaneamente durante uma transição mal sincronizada, switches learning engines entram em looping e a rede inteira perde conectividade por alguns segundos. A correção é ajustar o nopreempt no VRRP — assim o nó original não rouba o IP de volta quando volta, evitando essa oscilação. É contra-intuitivo porque parece que você está abrindo mão da alta disponibilidade, mas na verdade estabiliza o comportamento do cluster.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro detalhe que ninguém menciona: firewall rules. Regras de iptables ou nftables que permitem tráfego para o IP flutuante precisam estar presentes em TODOS os nós, não só no atual proprietário. Se o standby não tiver as regras configuradas, quando o IP migrar ele não vai aceitar conexões novas até que alguém corrija isso manualmente.
Limitações e cenários onde floating sandbox simplesmente não funciona
Existem situações em que essa abordagem falha completamente. A principal é quando você precisa de stateful persistence entre sessões. Floating sandbox gerencia IPs e conectividade, mas não sincroniza estado de aplicação. Se um usuário estava logado no nó A e o IP migra para o nó B, a sessão SomeSessionData está perdida. Você precisa de shared storage ou session replication separada para resolver isso, e isso complica a arquitetura toda. Performance também é um ponto cego. Cada failover introduce latency porque há um período de transition onde o IP está "voando" entre nós. Em aplicações sensíveis a delay como trading systems ou jogos multiplayer, esses 2 a 5 segundos de interrupção são inaceitáveis. Nesse caso, load balancing ativo-passivo com health checks mais agressivos ou arquiteturas active-active são alternativas mais adequadas.
Também tem o problema de split-brain. Se a rede entre os nós falla mas ambos continuam up, cada um pode ficar achando que é o único saudável e ambos pegarem o IP flutuante. Isso causa colisão de IP e corrupted data em shared storage. O quorum é essencial — configure um witness node ou use disk-based quorum para garantir que apenas um nó tenha direito a eleger-se como ativo. Se o seu cenário envolve múltiplos serviços com dependências cruzadas (banco de dados, cache, message queue), gerenciar floating sandbox individualmente para cada um gera coordenação complexa. O banco de dados sobe primeiro, depois o cache, depois a application server. Se todos flutuarem independentemente, você pode terminar com a app pointando para um banco em outro nó que ainda não finalizou o recovery. Orchestradores como Kubernetes resolvem isso com ordered startup e affinity rules, mas aí você abandonou o conceito puro de floating sandbox.
O que eu recomendo na maioria dos casos reais é começar simples: um par de nós com keepalived para o serviço mais crítico, validar o failover manualmente várias vezes antes de colocar em produção, e documentar cada timeout e threshold que você ajustou. Quando o problema acontecer — e vai acontecer — você vai saber exatamente qual linha do arquivo de configuração mexer em vez de gastar horas.debugando logs aleatórios.
