Quando alguém pede "alta disponibilidade entre dois datacenters" no Proxmox, o desenho imaginado quase sempre é um cluster único com nós dos dois lados. É intuitivo e é a pior escolha possível. O cluster estirado entre sites não aumenta a disponibilidade: ele cria um modo de falha novo, mais grave que o problema original, e o transforma em ponto único. O caminho certo é outro — clusters separados, replicação assíncrona e um plano de recuperação que alguém já testou.
Por que não estirar o cluster
O Proxmox usa Corosync para decidir quais nós estão vivos e quem tem quórum. Corosync foi projetado para rede local: ele espera latência de menos de um milissegundo e não tolera variação. Um enlace entre datacenters, mesmo bom, tem latência maior e — o que é pior — variável.
O que acontece na prática é o seguinte. O enlace oscila por alguns segundos. Cada lado deixa de ver o outro. Cada lado conclui que o outro morreu. Se houver quórum de ambos os lados, os dois tentam ligar as mesmas VMs, e você tem a mesma VM escrevendo no mesmo storage a partir de dois lugares — corrupção de dado, o pior desfecho possível.
O mecanismo que impede isso é o quórum, e ele traz a segunda consequência: o quórum precisa de maioria. Com dois sites simétricos, a queda do enlace deixa os dois lados sem maioria e as VMs param nos dois datacenters. Você acaba de somar as probabilidades de falha em vez de dividi-las: o cluster inteiro passou a depender também do enlace entre os sites.
Existem desenhos que mitigam isso, com um terceiro site apenas para o voto de desempate e enlace dedicado de baixíssima latência. Eles são caros, delicados e só se justificam em requisitos muito específicos. Para praticamente todo mundo, a resposta certa é não estirar.
O desenho que funciona
Dois clusters independentes, cada um com o seu próprio quórum, mais replicação assíncrona entre eles. Nenhum dos dois depende do enlace para funcionar.
A troca é explícita e honesta: você abandona o failover automático e sem perda de dado, e ganha um desenho que não se autodestrói quando a rede entre os sites oscila. A recuperação passa a ser uma decisão — humana ou automatizada com cuidado — de ativar o site secundário, aceitando a perda do intervalo de replicação.
É importante nomear isso corretamente para não vender o que não existe. Dentro de um site, com Ceph ou com replicação entre nós, você tem alta disponibilidade. Entre sites, com clusters separados, você tem recuperação de desastre. São objetivos diferentes, com custos e resultados diferentes.
RPO e RTO, decididos antes da tecnologia
Todo o resto depende de dois números que são de negócio, não de infraestrutura:
- RPO é quanto dado você aceita perder, medido em tempo. Se a replicação roda a cada quinze minutos, o RPO é quinze minutos.
- RTO é quanto tempo você aceita ficar fora até o serviço voltar no site secundário.
Definir esses dois números antes de escolher ferramenta evita as duas frustrações clássicas: gastar com um desenho de RPO quase zero para um serviço que toleraria uma hora, ou prometer recuperação em minutos com um processo que leva meio dia.
Faça esse levantamento por serviço, não para o ambiente inteiro. O sistema que fatura tem exigência diferente do ambiente de homologação, e tratar tudo igual encarece sem necessidade.
As opções de replicação
| Mecanismo | RPO típico | RTO típico | Complexidade | Melhor para |
|---|---|---|---|---|
| Sincronização remota do PBS | Horas | Horas | Baixa | Base de tudo; retenção longa e site secundário |
| ZFS send/receive agendado | Minutos | Minutos a uma hora | Média | VMs críticas com storage local |
| Espelhamento de RBD no Ceph | Segundos a minutos | Minutos | Alta | Ambiente Ceph grande, RPO exigente |
| Replicação na camada da aplicação | Segundos | Minutos | Média | Banco de dados, o melhor RPO por real |
Vale destacar a última linha, porque é a mais subestimada. Para banco de dados, a replicação do próprio banco — streaming replication no PostgreSQL, por exemplo — entrega RPO de segundos com um custo muito menor do que qualquer replicação de bloco. Replicar a VM inteira para proteger o banco que está dentro dela é, quase sempre, a forma mais cara de atingir um resultado pior.
O desenho que recomendamos com mais frequência combina camadas: PBS sincronizando para o site secundário como base para tudo, ZFS send/receive nas VMs de infraestrutura que precisam voltar rápido, e replicação nativa nos bancos de dados.
A sincronização remota do PBS é o alicerce
Se você vai implantar uma coisa só, implante esta. O Proxmox Backup Server permite que uma instância sincronize o conteúdo de outra, e isso resolve muito com pouco esforço:
- O dado sai do site principal, atendendo à regra de manter uma cópia fora do local.
- A transferência é incremental e deduplicada, então o consumo de banda é uma fração do volume total.
- A criptografia é feita na origem, o que torna aceitável guardar a cópia em infraestrutura que você não controla inteiramente.
- A verificação roda no destino, confirmando que o que chegou é restaurável.
- O modelo de puxar é mais seguro: o destino busca o dado da origem, e não o contrário. Origem comprometida tem mais dificuldade de destruir a cópia remota.
Para muitos ambientes, PBS remoto com um Proxmox modesto do outro lado é um plano de recuperação completo e barato. O RTO é maior — você restaura em vez de ligar o que já está lá —, mas o dado está protegido, e isso é o que não se recupera de outra forma.
A parte que ninguém documenta: o plano de virada
Aqui está o motivo mais frequente de um plano de recuperação falhar. A replicação está impecável, o dado está do outro lado, e ninguém sabe o que fazer no dia. Um plano precisa responder, por escrito:
- Quem decide ativar o site secundário, e com base em qual critério. Sem isso, a primeira hora do incidente é gasta em reunião.
- Como o tráfego chega ao novo site. DNS com TTL curto configurado antes, endereço flutuante, balanceador externo. Descobrir no incidente que o TTL do registro é de 24 horas é um clássico.
- Endereçamento das VMs no destino. Sub-rede diferente exige reconfiguração; planeje isso antes, ou use faixa compatível.
- A ordem de subida. Banco antes da aplicação, autenticação antes de tudo, serviço de fila antes dos consumidores.
- O que fica de fora. Nem todo serviço precisa subir. Declarar isso antecipadamente evita esforço no pior momento.
- Como voltar para o site principal depois, sem perder o que foi gravado no secundário durante a operação. O retorno é, com frequência, mais delicado que a ida.
Banda: a conta que decide o RPO possível
Antes de prometer um RPO, verifique se o enlace sustenta. A conta é direta: volume de dado alterado por dia dividido pelo tempo disponível para transferir. Se as suas VMs geram 200 GB de alteração diária e a janela é de oito horas, você precisa de aproximadamente 60 Mbps sustentados só para a replicação — sem contar o tráfego de produção.
Dois cuidados. A primeira sincronização é o volume total, não o incremental; planeje uma carga inicial, eventualmente por transporte físico de disco, se o volume for grande. E limite a banda da replicação, para ela não competir com a produção — replicação que degrada o serviço acaba desligada por alguém, e um mês depois ninguém lembra que o site secundário parou de receber dado.
Teste, senão não existe
Plano de recuperação não testado é documento, não capacidade. O teste não precisa ser dramático nem arriscado: restaure as VMs principais no site secundário, numa rede isolada, ligue na ordem prevista e confirme que a aplicação funciona e que o dado está coerente.
Faça isso a cada seis meses, no mínimo, e sempre depois de mudança relevante de arquitetura. Cada teste encontra alguma coisa — uma dependência esquecida, um certificado que só existe no site principal, um serviço que ninguém sabia que era necessário. É exatamente esse o valor do exercício, e é muito melhor descobrir num sábado planejado do que numa terça de crise.
Erros comuns
- Cluster único estirado entre datacenters, com quórum dependendo do enlace.
- Vender "alta disponibilidade entre sites" quando o que existe é recuperação de desastre.
- Não definir RPO e RTO por serviço antes de escolher a tecnologia.
- Replicar a VM inteira para proteger um banco que replica sozinho melhor.
- TTL de DNS longo, descoberto durante o incidente.
- Endereçamento incompatível entre os sites, exigindo reconfiguração manual.
- Replicação sem limite de banda, competindo com a produção até alguém desligar.
- Nenhum plano escrito de quem decide a virada.
- Nunca ter testado uma restauração completa no site secundário.
Onde a Solvefy/Cloud entra
Recuperação de desastre é um dos temas em que mais somos chamados para corrigir desenho: encontramos clusters estirados prontos para corromper dado e planos de recuperação que existem só no discurso. Como parceiros oficiais Proxmox, levantamos o RPO e o RTO de cada serviço, escolhemos a combinação de mecanismos que atende com o menor custo, implantamos a replicação e — a parte que faz diferença — escrevemos e executamos o teste de virada junto com a sua equipe.
Quer um plano de recuperação que alguém já testou? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.