Como sincronizar nós no Proxmox com alta latência de rede

Por que nós de cluster caem quando a latência de rede sobe

Quando montamos um cluster de virtualização, esperamos que todos os servidores conversem entre si como se estivessem lado a lado na mesma mesa. No entanto, quando ligamos nós geograficamente separados por links de internet ou fibra de longa distância, a realidade da física bate à porta. A latência, que é o tempo que um pacote leva para ir e voltar, começa a flutuar. Na prática, isso significa que o software que gerencia o grupo de computadores pode achar que um servidor morreu simplesmente porque a resposta demorou alguns milissegundos a mais do que o normal.

Para manter tudo alinhado, o Proxmox utiliza por baixo dos panos uma ferramenta chamada Corosync. O Corosync funciona como um vigia incansável que grita 'você está aí?' para cada máquina do grupo a todo instante. Quando a rede sofre atrasos, esses gritos demoram a voltar, gerando pânico desnecessário e expulsando nós saudáveis do grupo de forma abrupta. Quando isso acontece, a estabilidade de toda a infraestrutura desmorona, afetando máquinas virtuais e serviços críticos que dependem dessa coesão.

Entendendo o papel do Corosync na saúde do seu cluster

O Corosync é o coração invisível da alta disponibilidade em ambientes corporativos e em projetos de homelab avançados. Ele troca mensagens de controle chamadas heartbeats para garantir que todos os servidores concordem sobre quem está vivo e quem está morto. No dia a dia, esse comportamento silencioso passa despercebido, mas se a latência da sua infraestrutura oscila por causa de congestionamentos ou saltos longos de rede, o relógio interno do Corosync pode se perder. Para entender melhor como isolar problemas de infraestrutura antes que eles afetem o cluster, vale a pena conferir nossas dicas sobre como automatizar backups incrementais de VMs no Proxmox, garantindo redundância segura e previsível.

Quando o temporizador interno estoura antes do pacote chegar, o cluster entra em um estado de alerta. Se o problema persistir por alguns segundos, o sistema assume que o servidor remoto falhou e começa a isolá-lo. Na prática, isso gera reinicializações forçadas e migrações caóticas de cargas de trabalho, criando um efeito cascata que degrada a performance global. Ajustar esse comportamento exige mexer em parâmetros fundamentais de tempo e tolerância de perda de pacotes, encontrando o equilíbrio exato entre segurança e flexibilidade operacional.

Ajustes finos de timeouts e tolerância a falhas na rede

Para evitar que picos momentâneos de atraso derrubem seus servidores, precisamos recalibrar os limites de paciência do Corosync. O arquivo de configuração principal fica localizado em um diretório específico do sistema e controla diretamente o tempo que o software espera por uma resposta antes de tomar medidas drásticas. Modificar esses valores de forma incorreta pode deixar o cluster cego a quedas reais, por isso cada milissegundo adicionado deve ser calculado com base na latência média real da sua conexão.

Na prática, o processo envolve editar o arquivo de configuração e ajustar diretivas que controlam o intervalo de envio de mensagens e o número de tentativas perdidas antes de declarar uma falha. Para aplicar essas alterações com segurança em um ambiente de produção, execute os comandos abaixo diretamente no console principal do seu nó gerenciador, lembrando sempre de propagar a mudança para os demais servidores do grupo:

nano /etc/corosync/corosync.conf
# Ajustar tokens e timeouts para redes de alta latência
totem {
  version: 2
  secauth: on
  threads: 0
  token: 5000
  token_retransmits_before_loss_const: 10
}
systemctl restart corosync

Esse ajuste eleva o tempo limite do token para cinco segundos, dando margem para oscilações severas na rede sem que o cluster entre em colapso. Além disso, configurar corretamente a pilha de transporte e monitorar o tráfego com ferramentas adequadas ajuda a manter a estabilidade operacional, tal como detalhado em nossas diretrizes sobre como debugar falhas de rede em containers Docker com tcpdump, que trazem conceitos valiosos de diagnóstico de pacotes.

Prevenção de cenários de split-brain em ambientes distribuídos

Um dos maiores pesadelos de qualquer administrador de sistemas é o temido split-brain. Esse fenômeno ocorre quando a rede se rompe ao meio, criando duas ilhas isoladas de servidores que acreditam ser os únicos sobreviventes. Quando isso acontece, ambos os lados tentam assumir o controle dos mesmos recursos e discos compartilhados, gerando corrupção massiva de dados. Em redes com alta latência, o risco de falsos isolamentos aumenta exponencialmente se o quorum não estiver configurado com redundância adequada de votos.

Para blindar o ambiente contra essa catástrofe, o Proxmox utiliza o mecanismo de quorum baseado em votos e, idealmente, em um dispositivo de testemunha externo ou QDevice. Na prática, o QDevice atua como um árbitro neutro que não roda cargas de trabalho, mas serve como o voto de desempate caso ocorra uma partição na rede. Dessa forma, apenas o lado da rede que conseguir se comunicar com a testemunha continuará operando com permissão de escrita, impedindo que dados conflitantes destruam a integridade do seu armazenamento corporativo. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como proteger relés industriais contra surtos de tensão.

Considerações finais sobre resiliência e estabilidade no Proxmox

Gerenciar nós do Proxmox em redes com alta latência exige um misto de paciência, monitoramento constante e ajustes cirúrgicos no Corosync. Ao esticar os limites de tempo de espera e implementar mecanismos de proteção contra o split-brain, você transforma uma conexão de internet instável em um cluster resiliente e pronto para ambientes corporativos distribuídos. Lembre-se sempre de testar as alterações em laboratório antes de aplicá-las em produção, garantindo que sua infraestrutura continue firme mesmo quando a rede decidir pregar peças.