Você acha que ter três servidores Proxmox rodando em um cluster garante automaticamente que seus serviços não cairão? Engano perigoso. Sem uma configuração precisa do quorum, você não tem alta disponibilidade; você tem um sistema fadado ao split-brain ou, pior, à paralisação total diante de qualquer falha de rede isolada. A maioria das empresas que migra para virtualização sobestima esse detalhe técnico, tratando o cluster como uma caixa preta mágica em vez de um mecanismo de votação crítico.

Neste post:

A alta disponibilidade (HA) não é uma feature que se liga com um interruptor. Ela é o resultado de decisões arquiteturais tomadas antes do primeiro VM ser inicializada. O coração dessa arquitetura é o mecanismo de consenso distribuído. Se os nós não concordarem sobre quem está vivo e quem está morto, a proteção desaparece.

O que é Quorum e por que ele define a vida ou a morte do seu cluster

O quorum é, essencialmente, o número mínimo de votos necessários para que um nó considere o cluster "saudável" e capaz de tomar decisões. No contexto do Proxmox VE (PVE), que utiliza o sistema de gerenciamento de clusters Corosync, o quorum não é apenas uma preferência; é uma condição de segurança obrigatória.

Imagine que você tem um grupo de quatro sócios. Para abrir a conta bancária e transferir dinheiro, a regra diz: "é necessário o voto de pelo menos 3 sócios". Se dois sócios estiverem em viagem (falhas) e apenas dois estiverem no escritório, eles não podem autorizar nenhuma transação. O sistema trava para evitar que um grupo minoritário tome decisões que contradigam o restante da empresa.

No Proxmox, essa lógica previne a corrupção de dados. Se um nó acredita que é o único vivo (porque perdeu conexão com os outros), mas na verdade apenas houve um corte de rede, ele não deve assumir o controle das VMs sozinho. Se ele assumisse, poderia escrever dados em um storage compartilhado enquanto o outro nó (que ainda está ativo do seu lado da falha) também escreve. O resultado seria uma corrupção irreversível dos discos virtuais.

Portanto, configurar o quorum não é burocracia; é a garantia de que sua infraestrutura não fará nada até ter certeza absoluta de que está agindo em nome da maioria.

O pesadelo do Split-Brain: quando a rede falha

O cenário mais temido em clusters distribuídos é o split-brain (cérebro dividido). Ele ocorre quando a comunicação entre os nós é interrompida, mas ambos continuam operando. Sem um mecanismo de quorum robusto, cada lado do cluster acredita que possui a autoridade para gerenciar os recursos.

"O split-brain é a única situação em que 'alta disponibilidade' se transforma em 'disponibilidade corrompida'. Melhor parar tudo do que salvar dados inconsistentes."

No Proxmox, o serviço pve-cluster monitora constantemente a saúde do cluster. Se um nó percebe que perdeu o quorum, ele entra em um estado de espera ou desliga os serviços de HA para proteger a integridade dos dados. Isso pode parecer frustrante para quem espera que as VMs continuem rodando "de qualquer jeito", mas é a única forma de garantir que, quando a rede voltar, você não encontre arquivos corrompidos.

Para evitar que o split-brain paralise sua operação inteira devido a uma simples falha de switch ou cabo de rede, precisamos ajustar as regras de votação. É aqui que a configuração correta do quorum entra em jogo, permitindo resiliência real contra falhas isoladas.

Estratégias de Votação: de 2 a N nós

A configuração do quorum depende diretamente do tamanho do seu cluster. O Proxmox utiliza um algoritmo baseado em votos (votes) e quórum (quorum). Entender essa matemática é crucial para planejar sua infraestrutura.

Vamos analisar as configurações mais comuns:

  • Cluster de 2 Nós: Cada nó tem 1 voto. O quorum padrão é calculado como (Total de Votos / 2) + 1. Isso resulta em 2 votos necessários para o quorum. Ou seja, ambos os nós precisam estar online e comunicando-se. Se um cair, o outro fica sem quorum e desliga as VMs de HA. Isso é seguro, mas não oferece tolerância a falhas se um nó falhar completamente.
  • Cluster de 3 Nós: Este é o padrão ouro para pequenas e médias empresas. Cada nó tem 1 voto. O quorum necessário é 2. Se um nó falhar, os outros dois mantêm o quorum e continuam operando normalmente. As VMs nos nós saudáveis continuam rodando e podem ser migradas ou reiniciadas automaticamente se necessário.
  • Cluster de 4 Nós: Com 4 votos, o quorum necessário é 3. Se dois nós falharem simultaneamente, o cluster perde o quorum e para. Isso exige uma rede mais robusta e redundante.

Muitos administradores tentam usar clusters de 2 nós esperando que a HA funcione como em sistemas tradicionais de banco de dados com espelhamento síncrono. No Proxmox, sem um tie-breaker, o cluster de 2 nós é frágil contra partições de rede.

A solução para clusters ímpares ou para melhorar a resiliência em clusters pares é o uso do Arbitration Device (Dispositivo de Arbitragem), também conhecido como QDevice.

Como configurar corretamente o Quorum no Proxmox

A configuração manual via linha de comando pode ser arriscada se não houver compreensão prévia. O Proxmox Web Shell oferece uma interface poderosa, mas direta, para gerenciar esses parâmetros.

Passo 1: Verificar o Status Atual

Antes de alterar qualquer configuração, verifique como o cluster está se comportando atualmente. No terminal de cada nó, execute:

corosync-cfgtool -s
crm_verify -L -V

Observe a saída. Você verá quantos votos cada nó possui e qual é o estado atual do quorum. Se houver avisos de "lost quorum", sua configuração atual não está protegendo seus serviços adequadamente.

Passo 2: Utilizando o QDevice para Resiliência

O QDevice é um serviço leve que roda em um terceiro servidor (que pode ser uma VM leve ou um hardware dedicado). Ele não hospeda VMs; ele apenas emite votos. Isso permite que clusters pares (como 2 ou 4 nós) tolerem falhas de um nó sem perder o quorum.

Para configurar:

  1. Instale o Proxmox em um terceiro servidor dedicado.
  2. No nó principal do cluster, execute: pvecm add [IP_DO_QDEVICE].
  3. O assistente configurará automaticamente o serviço corosync-qdevice.
  4. O QDevice agora atua como juiz. Se houver empate de votos (ex: 1 nó contra 1 nó), o QDevice decide quem fica com a autoridade.

Isso transforma um cluster de 2 nós em um sistema verdadeiramente tolerante a falhas. Se um dos nós principais cair, o QDevice vota junto com o nó restante, mantendo o quorum (2 votos: Nó A + QDevice) e permitindo que as VMs continuem rodando.

Passo 3: Ajuste Fino de Timeout

Em ambientes com latência de rede variável, o timeout padrão do Corosync pode ser muito agressivo. O arquivo de configuração /etc/pve/corosync.conf permite ajustar os parâmetros totem. Valores como token e token_retransmits_before_loss_const podem ser aumentados para evitar que o cluster declare um nó como "morto" prematuramente durante picos de tráfego.

Contudo, aumente esses valores com cautela. Tempos de detecção muito longos atrasam a recuperação automática em caso de falhas reais.

Monitoramento e Alertas de Saúde do Cluster

Configurar o quorum é apenas metade da equação. Você precisa saber quando ele está sendo comprometido. O Proxmox possui um sistema de alertas integrado, mas ele deve ser calibrado para não gerar fadiga de notificações.

Configure monitoramento específico para:

  • Estado do Corosync: Alertas imediatos se o status mudar de "Active" para "Inactive" ou "Partial".
  • Perda de Pacotes de Rede: O Corosync depende de multicast (geralmente na porta 5405). Perda de pacotes multicast é o sinal número um de problemas de switch ou configuração de VLAN incorreta.
  • Divergência de Configuração: Se os nós não sincronizarem o banco de dados do cluster, o quorum pode ser perdido silenciosamente.

Ferramentas como Zabbix, Prometheus ou até mesmo o monitoramento nativo do Proxmox devem ser usadas para rastrear a latência entre os nós. Uma latência alta e inconsistente entre os nós é um indicador precoce de que o quorum pode ser perdido antes mesmo da falha ocorrer.

Componente Importância para Quorum Ação Recomendada
Rede (Multicast) Crítica Use VLANs dedicadas, sem QoS agressivo que bloqueie multicast.
Storage (Shared) Alta Garanta acesso simultâneo consistente (ex: Ceph, NFS com flock).
QDevice Opcional, mas recomendado Use para clusters pares ou para aumentar a tolerância a falhas.
Relógio (NTP) Moderada Sincronização precisa evita problemas de timestamp no cluster.

Perguntas frequentes sobre HA e Quorum

O que acontece se eu perder o quorum?

Quando um nó do cluster Proxmox percebe que perdeu o quorum, ele assume que não pode mais confiar no estado global do sistema. Para proteger os dados, ele desliga automaticamente todas as VMs configuradas com HA (Alta Disponibilidade). Isso evita a corrupção de dados por acesso simultâneo inconsistente. As VMs sem HA continuam rodando, mas o serviço de failover para.

Posso usar um cluster de 2 nós sem QDevice?

Tecnicamente sim, mas não é recomendado para ambientes de produção crítica. Sem o QDevice, se um dos dois nós falhar, o restante perde o quorum e para. Você precisará do QDevice (um terceiro nó leve) para atuar como juiz de votos e manter o cluster vivo caso um dos nós principais caia.

Como saber se meu QDevice está funcionando?

No terminal, execute corosync-qdevice-tool status. Ele deve indicar que o serviço está ativo e conectado ao cluster. Além disso, verifique os logs em /var/log/syslog ou use a interface web do Proxmox na aba "Corosync" para verificar se o nó do QDevice aparece como um membro válido com votos atribuídos.

O Quorum afeta a performance das VMs?

O mecanismo de quorum em si tem impacto de performance desprezível. No entanto, a configuração de rede necessária para manter o quorum (tráfego multicast do Corosync) deve ser priorizada. Evite congestionar a mesma interface de rede com backups pesados ou transferência de VMs enquanto as VMs estão rodando. Dedique uma VLAN ou interface física exclusiva para a comunicação do cluster.

Posso ajustar o tempo de espera do Quorum?

Sim, editando o arquivo /etc/pve/corosync.conf. Os parâmetros token (tempo em milissegundos para um token circular) e token_retransmits_before_loss_const controlam a sensibilidade. Aumentar esses valores torna o cluster mais tolerante a instabilidade de rede, mas aumenta o tempo para detectar falhas reais. Teste cuidadosamente em ambiente de homologação.

Conclusão: Segurança começa pela votação

Configurar o quorum no Proxmox não é uma etapa opcional de "checklist". É a fundação sobre a qual toda a sua estratégia de alta disponibilidade repousa. Ignorar a matemática dos votos e a necessidade de um tie-breaker (como o QDevice) expõe seu negócio ao risco de corrupção de dados ou paralisia total diante da primeira falha de rede.

A regra é clara: para ter HA real, você precisa de quorum. Comece com 3 nós ou implemente um QDevice em clusters de 2. Monitore a saúde do Corosync diariamente e trate alertas de perda de multicast como emergências. Uma infraestrutura bem configurada não apenas sobrevive a falhas; ela as ignora.

A Toda Solução entende que a complexidade da infraestrutura moderna exige parceiros que dominam esses detalhes técnicos. Se você busca uma hospedagem ou cloud onde a estabilidade do seu cluster é garantida por design e não por sorte, fale com nossos especialistas. Não deixe o quorum para depois; garanta a continuidade do seu negócio hoje.