Virtualização do zero: hipervisor, VM, cluster e storage explicados

Virtualização é a base de praticamente toda infraestrutura moderna, e é um assunto que muita gente opera sem nunca ter visto explicado por inteiro. Dá para administrar VMs por anos sem entender por que o cluster precisa de três nós ou por que o storage decide tanta coisa — até o dia em que uma decisão de arquitetura precisa ser tomada e falta o mapa.

Este texto é o mapa. Sem pressupor conhecimento prévio, e sem simplificar a ponto de ficar inútil.

O problema que a virtualização resolve

Antes dela, uma aplicação por servidor físico. Isso criava três desperdícios:

• Capacidade ociosa. O servidor era dimensionado para o pico e passava a maior parte do tempo em 10% de uso.
• Rigidez. Precisar de mais memória significava desligar, abrir e trocar hardware.
• Acoplamento ao hardware. O sistema instalado conhecia aquela placa, aquela controladora. Trocar o servidor era reinstalar tudo.

A virtualização quebra a ligação entre o sistema operacional e o hardware físico. Um servidor passa a hospedar vários computadores independentes, e cada um enxerga um hardware padronizado que não corresponde ao que existe de fato.

O hipervisor

O hipervisor é a camada que faz isso. Ele intercepta o que as máquinas virtuais pedem — processador, memória, disco, rede — e distribui o hardware real entre elas, mantendo cada uma isolada das outras.

Classicamente se fala em dois tipos:

• Tipo 1, que roda direto sobre o hardware. É o que se usa em servidor.
• Tipo 2, que roda como um programa dentro de um sistema operacional comum. É o que se usa para testar algo no notebook.

Na prática a fronteira é mais borrada do que a classificação sugere. O Proxmox, por exemplo, é Linux com o módulo de virtualização do kernel: tecnicamente há um sistema operacional completo por baixo, e funcionalmente ele se comporta como tipo 1, com desempenho próximo do nativo. A classificação importa menos que a pergunta prática: isso é feito para rodar produção, ou para rodar no seu desktop?

VM e container: a diferença que decide muita coisa

São as duas formas de isolar carga, e confundi-las leva a decisões ruins de segurança.

Máquina virtual tem o próprio kernel. É um computador completo: liga, dá boot, tem sistema operacional inteiro. O isolamento é forte, porque a VM não compartilha o núcleo do sistema com ninguém.

Container compartilha o kernel do host. É um processo isolado que carrega as próprias dependências. Sobe em segundos, ocupa muito menos recurso, e o isolamento é menor — existe uma superfície compartilhada.

A regra que vale como arquitetura: carga de terceiro roda em VM. Enquanto todos os containers são administrados por você, o risco é gerenciável. No momento em que existe acesso privilegiado de outra pessoa lá dentro, uma falha de escalonamento no kernel deixa de ser problema daquele container e passa a ser de todos que dividem o nó.

Container é excelente para os seus próprios serviços. Não é a fronteira que isola clientes.

Por que existe cluster

Um servidor virtualizado tem um problema evidente: se ele cai, caem todas as VMs juntas. Consolidar aumentou a eficiência e concentrou o risco.

Cluster é a resposta: vários servidores administrados como um conjunto, capazes de mover cargas entre si. Isso entrega três coisas:

1. Manutenção sem parada. Esvazia-se um nó, faz-se o serviço, devolvem-se as VMs — durante o expediente.
2. Sobrevivência à falha. Se um nó morre, as VMs dele reiniciam em outro automaticamente.
3. Equilíbrio de carga. Nó pesado pode ser aliviado.

O problema do quórum

Aqui está o conceito que mais confunde e o mais importante.

Quando a rede entre os nós se parte, cada lado vê o outro sumir. E cada um precisa responder à mesma pergunta: "o outro morreu, ou fui eu que me isolei?".

Se ambos concluírem "o outro morreu" e assumirem as mesmas VMs, você tem a mesma máquina rodando em dois lugares, escrevendo no mesmo disco. O resultado é corrupção de dado, não indisponibilidade — e corrupção silenciosa é muito pior que uma parada.

A proteção é a maioria: um lado só age se tiver mais da metade dos votos. Com três nós, dois formam maioria e o isolado se cala. Com dois nós, cada lado tem exatamente metade — não existe maioria possível.

É por isso que o número mínimo para um cluster com failover automático é três. Com dois, é obrigatório um terceiro elemento de voto, que pode ser uma máquina pequena fora dos dois servidores.

A folga que quase ninguém calcula

Consequência direta e frequentemente ignorada: se um nó cai, as VMs dele precisam caber nos que sobraram.

Um cluster de três nós operando a 90% de uso não consegue absorver a queda de um. A capacidade realmente utilizável é a total menos um nó — cerca de dois terços em um cluster de três, 80% em um de cinco. Encher o cluster até o limite transforma uma falha prevista de hardware em indisponibilidade real.

O storage é metade da decisão

Para uma VM reiniciar em outro nó, o disco dela precisa estar acessível lá. Isso define o desenho inteiro.

Storage local — discos dentro de cada servidor. Rápido e barato; o disco só existe naquele nó. Para o failover funcionar, é preciso replicar os dados para outro nó periodicamente — o que significa que, em uma falha, você perde o que mudou desde a última replicação.

Storage compartilhado — um equipamento externo que todos os nós enxergam. O failover é imediato, porque o disco já está disponível em qualquer nó. Transfere o ponto único de falha para o array, que então precisa ser redundante.

Storage distribuído — os discos ficam nos próprios servidores, e um software espalha cópias de cada dado entre vários nós. Sem ponto único de falha, e escala adicionando nós. Exige no mínimo três nós e uma rede dedicada competente, porque todo o tráfego de dados passa por ela.

Essa última opção — chamada de hiperconvergência — é o que torna viável montar uma operação séria sem comprar um array dedicado. E é também onde se erra mais: storage distribuído vive de rede, e economizar nos switches produz lentidão constante e inexplicável.

Os dois números que você precisa escrever

Toda a discussão acima converge para duas perguntas de negócio, não de tecnologia:

• RPO — quanto dado o negócio aceita perder? Se a resposta é "nada", storage compartilhado ou distribuído; se são aceitáveis 15 minutos, replicação resolve e custa menos.
• RTO — quanto tempo aceita ficar fora do ar? Isso define se você precisa de failover automático ou se restaurar um backup é suficiente.

Esses dois números precisam estar escritos e acordados com quem responde pelo resultado. A maior parte dos projetos de infraestrutura mal dimensionados nasce de nunca tê-los definido — a arquitetura acaba sendo escolhida por preferência técnica, e a conta aparece no primeiro incidente.

O que virtualização não resolve

Para encerrar sem vender ilusão:

• Não substitui backup. Cluster protege contra falha de hardware. Não protege contra exclusão acidental, corrupção lógica, ransomware ou perda do datacenter.
• Não conserta aplicação mal feita. Aplicação que não escala continua não escalando em VM.
• Não elimina licença do sistema convidado. Virtualizar Windows não dispensa licenciar Windows.
• Não dispensa operação. Alguém continua precisando atualizar, monitorar e testar restauração.

Erros comuns

• Montar dois nós esperando failover automático.
• Encher o cluster sem deixar folga para a queda de um nó.
• Economizar na rede de storage distribuído.
• Entregar container a terceiros em vez de VM.
• Confiar em snapshot como se fosse backup.
• Não escrever RPO e RTO antes de escolher a arquitetura.
• Storage externo único, sem redundância, virando o novo ponto de falha.
• Dimensionar pelo uso médio em vez do pico sustentado.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, começamos exatamente por essa conversa: qual carga você tem, quanto tempo e quanto dado o negócio tolera perder, e qual desenho de nós, storage e rede atende isso pelo menor custo. Projetamos, implantamos e sustentamos — com teste de queda de nó e de restauração feitos junto com você, porque é o que transforma arquitetura no papel em proteção verificada.

Quer avaliar se a sua infraestrutura aguenta o que você espera dela? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.