Quanto custa um cluster Proxmox de 3 nós: a conta com hardware real

É a pergunta que abre quase toda conversa de projeto, e a resposta honesta não é um número — é uma estrutura de conta. Preço de hardware varia por fornecedor, por câmbio e por mês; o que não varia é quais itens precisam estar na lista e como dimensionar cada um.

Este texto é essa lista, com as ordens de grandeza relativas entre os itens e os três lugares onde o orçamento quase sempre erra.

Por que três nós

Antes do hardware, o número. Três não é escolha estética:

• Quórum. Cluster precisa de maioria para decidir quem está vivo quando a rede se parte. Com dois nós, cada lado tem metade e não há maioria possível — a queda de um degrada o ambiente em vez de ser absorvida.
• Storage distribuído. Ceph precisa de três nós para manter réplicas com segurança e sobreviver à perda de um sem perder dado.

Dois nós com um árbitro externo funciona e tem ressalvas sérias. Se o orçamento alcança três, alcance três — a diferença de custo costuma ser menor que a complexidade evitada.

A lista de materiais

Processador

O que importa, em ordem: número de núcleos, geração, e só então frequência.

Virtualização tolera overcommit de CPU — você pode alocar mais vCPUs do que existem núcleos físicos, porque nem todas as VMs usam o processador ao mesmo tempo. Uma relação de 3 ou 4 vCPUs por núcleo físico é confortável para carga mista; carga intensiva pede mais perto de 1:1.

Um ponto que afeta migração: se o cluster vai crescer com hardware comprado em momentos diferentes, escolher uma família de processador coerente evita o problema de VM que não migra entre nós de gerações distintas. Vale pensar nisso na primeira compra.

Um socket por nó costuma bastar em servidores modernos, que já trazem muitos núcleos. Dois sockets aumentam densidade e trazem a complexidade de NUMA.

Memória — o item que acaba primeiro

É o recurso que esgota antes de todos os outros, em praticamente todo ambiente. Memória não é compressível: não dá para servir 100 GB de VM com 64 GB de RAM sem degradação imediata.

Dimensionamento:

• Some a memória de todas as VMs previstas.
• Divida pela folga de redundância: em três nós, cada um deve operar em torno de 60–65% para que a queda de um caiba nos outros dois.
• Reserve memória para o próprio host — e, se usar ZFS, para o cache dele, que é generoso de propósito.
• Adicione margem de crescimento para pelo menos 18 meses.

Na prática: se as VMs somam 192 GB, você não quer três nós de 64 GB. Quer três de 128 GB, no mínimo.

É o item em que menos vale economizar, e o que mais frequentemente é subdimensionado no primeiro orçamento.

Discos

Dois grupos distintos:

Disco de sistema — dois discos pequenos em espelho, só para o Proxmox. Separar o sistema dos dados simplifica reinstalação e manutenção. Não precisa ser grande nem rápido.

Discos de dados — aqui está a decisão. Com Ceph ou ZFS, use SSD ou NVMe com resistência de escrita para servidor. Este é o erro mais caro e mais comum da lista: SSD de desktop em carga de servidor falha prematuramente, e em storage distribuído a falha vem acompanhada de recuperação que estressa os discos restantes.

Dimensionamento com Ceph: a capacidade utilizável é a bruta dividida pelo fator de replicação — com três cópias, um terço. E é preciso manter folga adicional para a recuperação quando um nó cai, porque os dados dele são redistribuídos. Quem calcula capacidade pela soma bruta dos discos descobre o problema tarde.

Mais discos menores costumam ser melhores que poucos discos grandes: a recuperação é mais rápida e a distribuição mais equilibrada.

Rede — onde o orçamento mais erra

Esta é a seção mais importante do artigo.

Storage distribuído vive de rede. Todo dado escrito atravessa a rede para as réplicas. Cluster com rede subdimensionada entrega desempenho ruim de forma constante e inexplicável — e a correção depois custa mais do que ter feito certo.

O desenho mínimo:

E dois switches, não um. Switch único é ponto único de falha de todo o cluster — se ele cai, não cai uma VM, cai tudo. Com dois switches e bonding, a queda de um é absorvida.

O Corosync merece nota: ele é sensível a latência, não a banda. Compartilhar a rede do quórum com o tráfego pesado de storage é uma causa clássica de cluster que perde quórum sob carga e reinicia nós sozinho.

Energia

Nobreak dimensionado para desligamento ordenado, não para manter o ambiente rodando o dia inteiro. Com comunicação com os nós, para que eles desliguem graciosamente antes de a bateria acabar — queda abrupta em storage distribuído é a melhor forma de transformar uma falta de luz em corrupção.

Fontes redundantes nos servidores, idealmente em circuitos distintos.

A estrutura da conta

Em ordem decrescente de peso típico no orçamento:

1. Servidores (chassi, processador, memória) — a maior fatia.
2. Discos de dados — segunda maior, e sobe rápido com resistência de escrita adequada.
3. Rede (switches redundantes, placas 10 Gbps, cabos e transceptores) — subestimada com frequência; transceptores sozinhos surpreendem.
4. Nobreak.
5. Rack, trilhos, organização.
6. Subscription Proxmox — opcional, por socket, por ano. Diante do resto, é pequena.

E o que não entra no custo: licença de hipervisor, licença de storage definido por software, licença de backup. O Proxmox VE, o Ceph, o ZFS e o Proxmox Backup Server são abertos e sem custo de licença. É a linha que mais muda a conta em relação a alternativas proprietárias, especialmente ao longo de três anos.

Os três erros de orçamento

1. Calcular capacidade sem a folga de redundância. Três nós preenchidos até o limite não absorvem a queda de um. A capacidade vendável — ou utilizável — é a total menos um nó.

2. Economizar na rede depois de investir nos servidores. É a troca de pior retorno possível. Servidor forte com rede fraca entrega desempenho de rede fraca.

3. Esquecer o backup. Backup não pode morar no mesmo storage da produção. É preciso um destino separado — outro servidor com discos, um equipamento dedicado, ou storage externo —, mais a cópia em outro local. Projeto que termina no cluster e deixa backup "para depois" está incompleto.

Dimensionar antes de orçar

A sequência que evita comprar errado:

1. Inventarie as VMs: vCPU, memória e disco de cada uma, com o pico medido, não o alocado. Ambiente existente quase sempre tem superdimensionamento acumulado.
2. Some, e aplique a folga de redundância.
3. Projete o crescimento para 18 a 24 meses.
4. Escreva o RPO e o RTO — eles decidem se o storage é local com replicação, distribuído ou externo, e isso muda o hardware.
5. Só então peça cotação, com a lista fechada.

O passo 1 costuma devolver uma surpresa agradável: o parque usa bem menos do que foi alocado, e o cluster necessário é menor que o imaginado.

Erros comuns

• Planejar dois nós e descobrir o problema de quórum depois.
• Subdimensionar memória, que é o recurso que acaba primeiro.
• SSD de desktop em carga de servidor.
• Calcular capacidade de Ceph pela soma bruta dos discos.
• Rede de 1 Gbps para storage distribuído.
• Switch único, ponto único de falha do cluster inteiro.
• Corosync dividindo interface com o tráfego de storage.
• Nobreak sem comunicação com os nós.
• Esquecer backup e a cópia externa no orçamento.
• Dimensionar pelo alocado em vez do pico medido.
• Misturar gerações de processador sem planejar a compatibilidade de migração.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, fazemos o dimensionamento antes da cotação: inventário com medição real de pico, cálculo da capacidade utilizável com a folga de redundância, projeção de crescimento e a lista de materiais fechada — incluindo rede e backup, que são as duas linhas mais esquecidas. Comparamos o TCO de três anos contra a alternativa proprietária com os seus números, e implantamos o cluster com teste de queda de nó e de restauração cronometrados.

Quer a lista dimensionada para o seu ambiente antes de pedir orçamento? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.