Cluster de virtualização: o que é, componentes e operação

Quando um único host de virtualização falha, dezenas de máquinas virtuais saem do ar ao mesmo tempo. O impacto cresce de forma desproporcional em ambientes consolidados, em que cada servidor físico hospeda cargas críticas de áreas distintas. Por isso, o cluster de virtualização deixou de ser um diferencial e virou requisito básico para infraestrutura corporativa séria.

Este guia mostra o que é cluster de virtualização, como ele difere de cluster genérico, quais componentes garantem alta disponibilidade real, como cada plataforma (VMware vSphere, Hyper-V, Proxmox VE, KVM) implementa o conceito e como monitorar o cluster em produção. Ao final, você terá critério para decidir entre construir, expandir ou abandonar a abordagem em cenários específicos.

A leitura é técnica, mas voltada ao decisor de arquitetura. Em outras palavras, falamos de mecanismos como quórum, fencing e live migration, sem deixar de lado custo, operação e a pergunta honesta: quando vale mais NÃO fazer cluster.

O que é um cluster de virtualização

Cluster de virtualização é um conjunto de hosts físicos (chamados de nós) que executam hipervisores e operam como uma única plataforma lógica para hospedar máquinas virtuais. Os nós compartilham políticas, armazenamento e rede de gerência. Por isso, qualquer VM pode rodar em qualquer nó disponível do agrupamento.

A diferença em relação a um cluster genérico é o nível de abstração. Um cluster genérico pode agrupar bancos de dados, balanceadores de carga ou nós de processamento paralelo (HPC). Já o cluster de virtualização tem um propósito bem definido: manter VMs em execução mesmo quando um nó cai, quando o operador precisa atualizar firmware ou quando há picos de demanda concentrados em uma máquina.

Em síntese, virtualização cria a VM e o cluster fornece a malha de hosts que sustenta essa VM em condições adversas. As duas tecnologias trabalham juntas, mas resolvem problemas diferentes. Inclusive, é comum encontrar VMs rodando fora de cluster (standalone) em ambientes pequenos sem requisito de alta disponibilidade.

Cluster, virtualização e cluster de virtualização: limites conceituais

Vale destacar três conceitos próximos que costumam ser confundidos:

Um cluster, no sentido amplo, é qualquer agrupamento de máquinas que trabalha de forma coordenada. Bancos de dados em replicação síncrona formam cluster. Pods do Kubernetes formam cluster. Um par de balanceadores ativo-passivo também forma cluster.

A virtualização, por sua vez, é a tecnologia que abstrai hardware físico em recursos lógicos. O hipervisor (ESXi, Hyper-V, KVM, Proxmox VE) cria, isola e gerencia VMs sobre o mesmo silício.

Já o cluster de virtualização combina os dois: agrupa hipervisores em um plano de controle único, com a finalidade específica de oferecer alta disponibilidade, balanceamento e mobilidade de VMs entre hosts.

Por que adotar um cluster de virtualização

A motivação principal é resiliência. Em um host único, qualquer falha de hardware (placa-mãe, fonte, controladora) derruba todas as VMs daquele equipamento. Em contrapartida, em um cluster, as VMs do nó falho reiniciam automaticamente em nós saudáveis. O downtime cai de horas para minutos.

Outro driver relevante é manutenção sem janela. Antes de aplicar patches de firmware, atualizar o hipervisor ou trocar hardware, o administrador coloca o nó em manutenção. Em seguida, todas as VMs migram para outros nós sem desligar. Como resultado, a equipe trabalha durante o horário comercial sem impacto para o usuário final.

Vale destacar também a escalabilidade horizontal. Quando o consumo agregado se aproxima do limite, basta acrescentar mais um nó ao cluster. O balanceador automático (DRS na VMware, distribuição manual ou via scripts em Hyper-V e Proxmox) redistribui as VMs. Ainda assim, vale lembrar que cluster não substitui dimensionamento adequado por host individual.

Por fim, há o ganho operacional de alta disponibilidade como contrato. Quando o ambiente tem cluster bem dimensionado, com quórum saudável e fencing configurado, é viável assinar SLA de 99,9% ou superior sem fingir que o risco não existe.

Componentes essenciais de um cluster de virtualização

Independentemente do vendor, todo cluster de virtualização exige cinco componentes operando em harmonia. A ausência de qualquer um deles compromete a alta disponibilidade real e abre caminho para incidentes silenciosos.

Nós

Os nós são os hosts físicos que executam o hipervisor. O número mínimo é de dois nós, mas configurações ímpares (3, 5, 7) são preferíveis porque facilitam o cálculo de quórum. Cada nó deve ter capacidade reserva suficiente para absorver as VMs de pelo menos um vizinho em caso de falha (regra N+1).

Quórum

Quórum é o mecanismo que decide quem manda quando há divergência entre os nós. Em um cluster com 5 nós, o quórum exige maioria (3 nós online) para que o cluster continue tomando decisões. Sem isso, dois subconjuntos de nós isolados por uma falha de rede tentariam escrever no mesmo storage simultaneamente, no cenário clássico de split-brain.

Existem quatro modelos comuns de testemunha (witness):

Maioria de nós usa apenas a contagem de hosts. Adequado para clusters com número ímpar de nós (3, 5, 7).

Testemunha em disco reserva uma LUN dedicada no storage compartilhado como árbitro. Comum em clusters de 2 ou 4 nós.

Testemunha em arquivo usa um share SMB ou NFS externo. Útil quando não há storage dedicado para witness.

Testemunha em nuvem usa um endpoint Azure ou serviço equivalente. Indicada para clusters geograficamente distribuídos sem terceiro datacenter.

Storage compartilhado

Para que uma VM migre entre nós sem copiar dados, todos os hosts precisam ler e gravar no mesmo storage. As três abordagens predominantes são SAN (Fibre Channel, iSCSI), NAS (NFS) e SDS (storage definido por software, como vSAN, Storage Spaces Direct ou Ceph). Em arquiteturas hiperconvergentes, o próprio cluster expõe o storage replicado entre os nós, sem cabine externa.

Rede de heartbeat

Heartbeat é a troca contínua de mensagens entre nós que prova quem está vivo. Em geral, essa malha usa interfaces de rede dedicadas e isoladas do tráfego de produção. Quando o heartbeat para de chegar, o cluster aciona o protocolo de failover para a VM afetada. A latência típica esperada é abaixo de 1 ms entre nós no mesmo rack.

Fencing (STONITH)

Fencing isola um nó com defeito antes de reiniciar suas VMs em outro local. A sigla STONITH (shoot the other node in the head) é usada em ambientes Linux/KVM. Em VMware e Hyper-V, o equivalente é o reset via interface de gerência fora de banda (iLO, iDRAC, IPMI). Sem fencing confiável, há risco real de duas instâncias da mesma VM rodarem em paralelo e corromperem dados.

Live migration entre hosts

Live migration é a transferência de uma VM em execução de um host para outro com downtime imperceptível ao usuário. O processo copia a memória, sincroniza o estado da CPU, transfere o ponteiro de execução e retoma a VM no destino, normalmente em menos de 200 ms de pausa.

Os quatro principais hipervisores corporativos implementam o recurso com nomes e mecanismos próprios. A tabela a seguir resume as diferenças operacionais que mais impactam o dia a dia da equipe de infraestrutura.

A diferença mais relevante para 2026 é o impacto da mudança de licenciamento da VMware após a Broadcom. Como resultado, muitas operações brasileiras estão revisando o custo total e considerando migração para Proxmox VE ou Hyper-V, sobretudo em clusters de borda e ambientes de homologação.

Failover automático e prevenção de split-brain

Failover é o procedimento que executa quando um nó falha. O cluster detecta a perda de heartbeat, isola o nó via mecanismo de fencing, valida que ele realmente saiu (não está apenas particionado da rede de gerência) e reinicia as VMs afetadas em outros nós saudáveis. Todo o processo é orquestrado pelo plano de controle do cluster.

O risco que o failover precisa evitar é o split-brain: dois subconjuntos de nós, isolados por uma falha de rede, acreditam que são o cluster legítimo. Sem quórum nem fencing, ambos tentam ligar a mesma VM. Como ambos escrevem no mesmo disco virtual, o resultado é corrupção de dados garantida. Ademais, o tempo para recuperar pode passar de semanas em casos graves.

A prevenção tem três camadas:

Quórum estrito exige maioria de nós ativos antes de qualquer decisão. Subconjuntos minoritários se autoexcluem e param de atender requisições. Por isso, clusters com 3, 5 ou 7 nós são preferidos sobre 2, 4 ou 6.

Fencing confiável garante que um nó suspeito seja efetivamente desligado antes que o cluster reinicie suas VMs em outro lugar. Em ambientes corporativos, o controle fora de banda (iLO, iDRAC, IPMI) é o padrão.

Witness adequado ao topology resolve empates em clusters com número par de nós ou em arquiteturas distribuídas geograficamente. A testemunha em nuvem (Azure Cloud Witness, por exemplo) é cada vez mais comum em clusters stretched entre dois datacenters.

Para aprofundamento técnico, vale consultar a documentação oficial da Microsoft sobre quórum no Failover Cluster, que detalha cenários de manutenção dinâmica de votos e força do quórum.

Cluster por plataforma de virtualização

Cada hipervisor implementa o cluster com terminologia e ferramentas próprias. Conhecer as diferenças ajuda a decidir tanto na arquitetura nova quanto na migração entre vendors. A escolha raramente depende apenas de tecnologia; em geral, vincula-se a licenciamento, capacitação da equipe e integração com o restante do ecossistema. Compare também o panorama no nosso comparativo VMware vs Hyper-V vs KVM.

VMware vSphere HA + DRS

vSphere é o padrão histórico em ambientes enterprise. O High Availability (HA) reinicia VMs em outros hosts quando um nó cai. O Distributed Resource Scheduler (DRS) balanceia automaticamente as VMs entre nós conforme métricas de CPU e memória. O vMotion executa a migração ao vivo sem downtime perceptível. Em conjunto, esses três recursos sustentam SLAs de 99,99% em datacenters bem dimensionados, ainda que o custo por core tenha aumentado significativamente após a Broadcom.

Microsoft Failover Cluster + Hyper-V

O Microsoft Failover Cluster é o serviço de cluster do Windows Server. Quando integrado ao Hyper-V, ele oferece reinício automático de VMs, Live Migration e Storage Migration. O quórum é configurado via dynamic quorum, que ajusta os votos conforme nós entram e saem do agrupamento. A grande vantagem é integração nativa com o ecossistema Microsoft, especialmente quando a operação já paga licenças Windows Server Datacenter. O Storage Spaces Direct (S2D) viabiliza arquitetura hiperconvergente sem cabine externa.

Proxmox VE Cluster + Ceph

O Proxmox VE tem cluster nativo desde a versão 1.x. A arquitetura suporta de 2 a 32 nós, gerenciados por console web compartilhada que enxerga todas as VMs e containers de qualquer nó. O quórum exige maioria estrita, motivo pelo qual clusters de 3, 5 ou 7 nós são recomendados. O Ceph, integrado ao Proxmox, fornece storage definido por software replicado entre os próprios nós, eliminando dependência de SAN externa. A live migration via qm migrate funciona com storage compartilhado, ao passo que migração offline funciona sem ele.

Para detalhes operacionais avançados, a wiki oficial do Proxmox Cluster Manager documenta procedimentos de adição, remoção e recuperação de nós.

KVM + Pacemaker + Corosync

O KVM (Kernel-based Virtual Machine) é o hipervisor nativo do Linux. Pacemaker + Corosync formam a dupla padrão para cluster nesse ecossistema. O Corosync trata heartbeat e mensageria entre nós. Em paralelo, o Pacemaker administra recursos (VMs, IPs virtuais, filesystems) e orquestra failover. A configuração é declarativa e altamente flexível, mas exige maior maturidade da equipe. Distribuições como Red Hat Enterprise Linux e SUSE Linux Enterprise oferecem suporte comercial com SLAs corporativos, com base na documentação do projeto Pacemaker.

Como monitorar um cluster de virtualização em produção

Construir o cluster é metade do trabalho. A outra metade é mantê-lo saudável ao longo de meses e anos. Em geral, equipes que assumem cluster sem plano de monitoramento descobrem incidentes pela reclamação do usuário em vez do alerta proativo. Em última análise, o monitoramento define se o investimento em alta disponibilidade vai entregar o SLA prometido.

As métricas mínimas que qualquer cluster de virtualização precisa expor são:

Estado do quórum em tempo real, com alerta imediato quando um voto se perde ou quando o cluster opera abaixo do threshold de maioria.

Latência de heartbeat entre nós, com alerta quando o p95 ultrapassa 1 ms ou quando há perda de pacotes na rede dedicada.

Latência de live migration, em especial o downtime efetivo da VM (medido por probe sintético) e o tempo total de transferência.

Saúde do storage compartilhado, com profundidade de fila, IOPS por nó e latência média. Storage saturado é causa frequente de failover desnecessário.

Eventos de fencing, com gravação imediata para auditoria. Cada operação de STONITH ou reset via iLO precisa estar rastreável, com timestamp e nó alvo.

A ferramenta OpMon da OpServices integra coletores nativos para VMware, Hyper-V e Proxmox, com dashboards prontos para cluster health, latência de migração e estado de quórum. Equipes que já monitoram a plataforma virtualizada com OpMon costumam evoluir naturalmente para o monitoramento de cluster sem trocar de ferramenta. Para casos específicos de Hyper-V, vale consultar nosso guia detalhado de monitoramento de Hyper-V.

Quando NÃO fazer cluster de virtualização

Cluster custa caro em hardware, licenças e operação. Por isso, vale fazer a pergunta inversa: existe cenário em que cluster é desperdício? Sim. Ignorar essa pergunta empurra organizações para complexidade sem retorno.

A primeira situação é a de workloads stateless escaláveis horizontalmente. Aplicações web modernas, microsserviços containerizados e funções serverless rodam atrás de balanceadores e morrem sem prejuízo, desde que outra instância suba em segundos. Para esse perfil, escalabilidade horizontal em Kubernetes ou serviço gerenciado em nuvem entrega mais resiliência por menos custo do que cluster de VM.

Outro cenário em que cluster pesa mais do que entrega é o de ambientes pequenos. Para uma operação com 5 ou 10 VMs em uma filial, o overhead de quórum, fencing e storage compartilhado pode superar o ganho prático. Em geral, backup confiável e recovery em até 4 horas resolve melhor o problema. Inclusive, em alguns casos, basta um único host com replicação para um equipamento secundário.

Vale também questionar o uso em cargas tolerantes a downtime planejado. Ambientes de homologação, desenvolvimento, treinamento e laboratório raramente precisam de cluster. Migrar o nó manualmente em janela de manutenção é viável, simples e barato. Como resultado, a equipe direciona o investimento de alta disponibilidade para os ambientes que de fato exigem SLA contratual.

Em resumo, cluster de virtualização é a resposta certa para cargas críticas que não toleram downtime não planejado e cujo custo de indisponibilidade supera o custo de operar o cluster. Fora desse perfil, há alternativas mais leves e mais baratas.

Conclusão

Cluster de virtualização é a base operacional de qualquer ambiente corporativo que precise garantir alta disponibilidade para máquinas virtuais críticas. Ao combinar nós redundantes, quórum estrito, storage compartilhado, heartbeat dedicado e fencing confiável, o cluster sustenta SLAs altos e elimina janelas de manutenção. Cada plataforma (VMware vSphere, Microsoft Hyper-V, Proxmox VE, KVM) implementa o conceito com terminologia própria, mas os fundamentos são os mesmos. A decisão entre vendors depende de licenciamento, capacitação da equipe e ecossistema existente.

Construir o cluster, no entanto, é apenas metade da jornada. Sem monitoramento contínuo do estado de quórum, latência de heartbeat, eventos de fencing e saúde do storage, o investimento em alta disponibilidade não entrega o resultado prometido. Quer estruturar um cluster de virtualização com SLA real e visibilidade operacional ponta a ponta? Fale com um especialista OpServices e descubra como ganhar previsibilidade na sua infraestrutura virtualizada.