Proxmox VE se consolidou como plataforma de virtualização corporativa por combinar maturidade técnica e ausência de licenciamento por soquete. Mas instalar Proxmox em três servidores não significa ter alta disponibilidade. Este artigo detalha o que compõe um cluster capaz de sobreviver à perda de um nó sem intervenção manual.
Quórum: a base de tudo
Um cluster precisa decidir, sozinho, quais nós estão vivos. Isso é feito por votação, e votação exige maioria. Por isso clusters de produção têm número ímpar de nós — três, cinco, sete — ou um dispositivo de desempate quando há apenas dois servidores.
Sem quórum, o cluster entra em modo protetivo e não movimenta máquinas virtuais, justamente para evitar o cenário mais perigoso da virtualização: a mesma máquina virtual ligada em dois nós, gravando no mesmo disco.
Storage compartilhado e redundante
Para que uma máquina virtual reinicie em outro nó, o disco dela precisa estar acessível a partir desse nó. Isso é feito com storage compartilhado — Ceph distribuído entre os próprios nós, ou um storage externo com múltiplos caminhos de rede.
A redundância precisa existir em todas as camadas: discos em RAID ou em réplica distribuída, mais de uma controladora e caminhos de rede independentes. Um único ponto de falha em qualquer dessas camadas anula o investimento feito nas demais.
- Número ímpar de nós ou dispositivo de desempate
- Rede dedicada para comunicação do cluster
- Storage compartilhado com réplicas em nós distintos
- Isolamento de nó com desligamento forçado configurado
- Capacidade reservada para absorver a carga do nó perdido
Capacidade reservada: o detalhe que derruba clusters
Se três nós operam a noventa por cento de uso e um deles falha, os dois restantes não têm como absorver a carga. As máquinas virtuais sobem, competem por recursos e o desempenho degrada a ponto de a operação ficar inviável — tecnicamente disponível, na prática parada.
Por isso dimensionamos clusters com folga suficiente para perder um nó inteiro sem impacto perceptível. É um custo adicional que se justifica na primeira falha de hardware.
Snapshots e replicação não substituem alta disponibilidade
Snapshot protege contra erro lógico recente. Replicação protege contra perda de um site inteiro. Alta disponibilidade protege contra falha de hardware sem intervenção humana. São camadas diferentes, com propósitos diferentes, e um ambiente maduro tem as três.
Nos ambientes que operamos, snapshots são programados conforme a criticidade, a replicação alimenta o plano de recuperação de desastres e a alta disponibilidade do cluster cuida das falhas do dia a dia.
Conclusão
Alta disponibilidade é resultado de projeto, não de configuração. Quórum correto, storage redundante, rede dedicada e capacidade reservada precisam existir juntos. É assim que a infraestrutura da MasterCloud é construída e é o que permite manter cargas críticas em operação contínua.