Errar o hardware de um ambiente Proxmox custa nos dois sentidos: compra-se de menos e o ambiente engasga na primeira carga real; ou compra-se de mais e o dinheiro fica parado em capacidade ociosa. O caminho certo é dimensionar pela carga real — e conhecer qual recurso vai limitar primeiro.

Meça antes de estimar

Dimensionamento honesto começa com dado, não com a planilha de alocação do ambiente antigo. Quase todo parque virtualizado tem VMs com o dobro da CPU que usam e metade do disco que precisam. Antes de cotar servidor, colete por pelo menos duas semanas — incluindo o pico do mês, se o negócio tem sazonalidade:

• CPU realmente usada por VM, com os picos, não só a média.
• Memória em uso versus memória alocada.
• IOPS e throughput de disco, separando leitura e escrita.
• Latência de disco percebida dentro da VM, que é o que o usuário sente.
• Tráfego de rede por VM e o total agregado por host.

Duas semanas de medição evitam meses de arrependimento. Sem esse retrato, qualquer número é palpite com aparência de projeto.

Comece pela pergunta certa: qual é o gargalo?

Em ambientes de virtualização densos, o recurso que quase sempre limita primeiro é a RAM. Você raramente fica sem CPU antes de ficar sem memória. Então, antes de olhar clock de processador, some a memória que as suas VMs realmente consomem — e planeje folga.

RAM: a fronteira do ambiente

• Some a RAM alocada de todas as VMs e containers previstos.
• Reserve memória para o próprio host (e, se usar Ceph, para os OSDs — o Ceph consome RAM por OSD, tipicamente alguns gigabytes cada).
• Se usar ZFS, reserve memória para o cache ARC. Ele acelera muito a leitura, mas ocupa RAM que você precisa contabilizar em vez de descobrir depois.
• Deixe margem para HA: se um nó cai, os outros precisam de RAM livre para receber as VMs órfãs. Um cluster que roda a 95% de memória não tem para onde migrar em caso de falha.

Regra prática: dimensione para que a perda de um nó ainda caiba no restante do cluster.

Sobre o tipo de memória, a recomendação é direta: use ECC. Servidor de virtualização concentra o risco de dezenas de sistemas em um único hardware, e memória que corrige erro é um dos itens de melhor custo-benefício do projeto. Se o storage é ZFS ou Ceph, ECC deixa de ser recomendação e passa a ser requisito de sanidade.

CPU: núcleos, não só GHz

Virtualização se beneficia de muitos núcleos mais do que de clock altíssimo. Considere:

• Total de vCPUs previstas e a taxa de overcommit aceitável (mais vCPUs virtuais que físicas, dentro do razoável, para cargas que não picam ao mesmo tempo).
• Recursos das cargas: bancos de dados e aplicações sensíveis a latência pedem menos overcommit; ambientes de VPS genéricos toleram mais.
• Topologia NUMA: VMs grandes que atravessam sockets pagam pedágio de latência de memória. Manter cargas críticas dentro de um nó NUMA compensa mais que adicionar núcleos.
• Reserve capacidade para o próprio host — Ceph, backup e criptografia consomem CPU de verdade, especialmente durante recuperação e janelas de backup.

Uma referência de overcommit por perfil de carga, para calibrar expectativa:

Um sinal objetivo de que o overcommit passou do ponto: tempo de espera de CPU crescendo dentro das VMs. Quando o sistema convidado reporta que passou tempo pronto para executar sem receber processador, a densidade venceu o hardware.

Storage: o que define desempenho percebido

O disco é onde a experiência do usuário mais aparece. Decisões-chave:

• NVMe/SSD para cargas de produção. Disco mecânico só faz sentido para arquivamento e backup.
• SSD de datacenter, com proteção contra perda de energia. Este item é o erro mais caro do dimensionamento amador: SSD de consumo sem capacitor de proteção entrega desempenho péssimo em escrita síncrona — exatamente o padrão de Ceph e ZFS — além de arriscar o dado numa queda de energia. Um cluster inteiro pode ficar lento por causa dessa única escolha.
• Endurance compatível. Verifique a resistência de escrita do modelo frente ao volume diário esperado. Disco barato que morre em um ano não foi economia.
• Se for Ceph: rede dedicada, número adequado de OSDs por nó e banco de metadados do BlueStore em dispositivo rápido quando houver discos de capacidade no pool.
• Se for ZFS local: planejar a topologia (mirror versus RAIDZ), memória para o ARC e, quando faz sentido, um special vdev em SSD para metadados. Mirror entrega mais IOPS e recuperação mais rápida; RAIDZ entrega mais capacidade útil. Para discos de VM, mirror costuma ser a escolha certa.

Vale lembrar da conta de capacidade útil: em Ceph com três réplicas, o espaço aproveitável fica em torno de um terço do bruto, com folga adicional para recuperação. Em ZFS mirror, metade. Dimensionar sobre a capacidade bruta é o caminho conhecido para descobrir, seis meses depois, que o storage já está cheio.

Rede: o recurso mais subestimado

Rede mal planejada estraga um hardware ótimo. Princípios:

• Segregue os tráfegos: gestão do cluster (corosync), armazenamento (Ceph) e dados das VMs em redes distintas. Corosync é sensível a latência; Ceph é faminto por banda.
• 10 GbE (ou mais) para armazenamento em ambientes com Ceph. 1 GbE aqui é gargalo garantido. Com pools de NVMe, 25 GbE deixa de ser exagero.
• Redundância de links para os caminhos críticos, com agregação configurada nos dois lados.
• Mais de um link de cluster para o corosync, de modo que a perda de uma interface não isole o nó.
• Quadros grandes na rede de armazenamento ajudam no throughput, desde que a configuração seja consistente em todo o caminho. Meia configuração aqui gera problema intermitente difícil de achar.

Quantos nós: o cálculo do N+1

Cluster de virtualização se dimensiona para operar com um nó a menos. Três nós é o piso para quórum e para Ceph, mas três nós cheios não têm onde acomodar a carga do que caiu. Duas saídas: manter cada nó em torno de dois terços de ocupação, ou partir para quatro ou cinco nós, o que dilui melhor o impacto de uma perda.

A regra vale para todos os recursos ao mesmo tempo — RAM, CPU, disco e capacidade de rede. Ter memória sobrando mas storage no limite não é redundância.

Um exemplo para tornar concreto

Suponha um ambiente com 60 VMs de porte médio, 240 vCPUs alocadas, 480 GB de RAM em uso real e exigência de HA com Ceph. Um desenho plausível seria:

• Cinco nós, para que a perda de um represente 20% da capacidade, não 33%.
• RAM por nó dimensionada para acomodar a carga do cluster dividida por quatro nós sobreviventes, mais o consumo do host, dos OSDs e do ARC.
• CPU com contagem de núcleos que sustente o overcommit escolhido no cenário de nó a menos, não no cenário ideal.
• NVMe de datacenter distribuído entre os nós, com capacidade bruta cerca de três vezes o dado útil desejado, mais folga de recuperação.
• Rede com 25 GbE para o Ceph, links redundantes e rede de cluster separada.

Os números concretos mudam conforme a medição real — o que não muda é o método: dimensione o cenário degradado, não o cenário perfeito.

Planejamento de capacidade: pense no crescimento

Dimensionar só para hoje é dimensionar para refazer daqui a seis meses. Projete o crescimento esperado e escolha uma arquitetura que escala adicionando nós — a beleza do modelo hiperconvergente. Assim, expandir é somar servidores, não trocar tudo.

Defina também os gatilhos de expansão antes de precisar deles: qual percentual de ocupação de RAM, de storage ou de banda dispara a conversa sobre o próximo nó. Com gatilho definido, a compra acontece com prazo de entrega confortável, em vez de virar emergência.

Checklist antes de fechar a compra

1. Medição de carga real em mãos, cobrindo pelo menos um pico.
2. Cenário N+1 calculado para RAM, CPU, storage e rede.
3. SSD/NVMe de datacenter com proteção de energia, endurance conferida.
4. Memória ECC, com folga para host, OSDs e ARC.
5. Rede segregada, redundante, com switch compatível com o que foi planejado.
6. Servidor de backup dimensionado — não a sobra de hardware do rack.
7. Nós distribuídos entre circuitos elétricos e switches diferentes.
8. Gatilhos de expansão definidos e documentados.

O erro mais comum

Copiar o hardware do ambiente antigo (VMware, Hyper-V) sem revisar. Cada plataforma tem seu comportamento; Ceph, em especial, muda completamente a equação de disco e rede. Dimensione para o Proxmox, não para o que rodava antes.

Onde a Solvefy/Cloud entra

Fazemos consultoria de hardware antes de qualquer recomendação de compra: analisamos suas cargas, projetamos CPU, RAM, storage e rede na medida, e entregamos um plano de capacidade que aguenta o crescimento. Somos parceiros oficiais Proxmox.

Vai montar ou expandir um ambiente? Diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.