Capacity planning no Proxmox: quando comprar o próximo nó

Existem duas formas de descobrir que o cluster está cheio. A primeira é um relatório mensal que mostra a tendência e diz que o limite chega em quatro meses. A segunda é uma VM que não sobe, um cliente esperando provisionamento, ou um nó que cai e o cluster não consegue realocar as máquinas dele.

A diferença entre as duas não é sofisticação de ferramenta. É ter definido, antes, qual é o número que dispara a compra.

A capacidade que você tem não é a que está instalada

O erro conceitual que orienta todo o resto: um cluster precisa sobreviver à perda de um nó. Isso não é um detalhe de redundância — é a razão de existir do cluster.

Se um nó cai, as VMs dele precisam caber nos que sobraram. Logo, a capacidade utilizável é a capacidade total menos um nó.

Repare que o custo relativo da redundância cai conforme o cluster cresce. Em três nós, um terço da capacidade é reserva; em oito, um oitavo. É um argumento concreto a favor de crescer em nós em vez de nós maiores — assunto que volta adiante.

E se o requisito for sobreviver à perda de dois nós — para manutenção planejada em um enquanto outro falha —, a conta é sobre N-2, e clusters pequenos ficam inviáveis rapidamente.

Os quatro recursos, e qual acaba primeiro

Capacidade não é um número só. Quatro recursos independentes, e o cluster está cheio quando qualquer um deles chega ao limite.

Memória. Acaba primeiro em quase todos os ambientes. É o recurso menos compressível — não se pode servir 100 GB de VM com 64 GB de RAM sem degradação imediata e severa. Overcommit de memória entre cargas de produção não é uma alavanca disponível.

Storage. Acaba segundo, e é o que precisa de mais antecedência: comprar disco, instalar e deixar o storage distribuído redistribuir os dados leva tempo. Com Ceph, há uma sutileza importante — a capacidade utilizável é a bruta dividida pelo fator de replicação, e é preciso manter folga suficiente para a recuperação de um nó perdido, o que consome espaço temporariamente.

CPU. Costuma ser o mais folgado, porque tolera overcommit. Mas isso tem limite: o sinal de saturação é o tempo de espera por CPU subindo, e ele degrada todas as VMs do nó ao mesmo tempo. Monitore essa métrica, não o percentual de uso.

Rede. Raramente é o gargalo de capacidade de cluster, mas é fácil de subestimar em ambientes com storage distribuído e muita migração.

Faça a projeção dos quatro separadamente. O primeiro que cruzar o limiar define a compra.

O que medir ao longo do tempo

Capacity planning é uma função da tendência, não do instantâneo. O que precisa estar registrado com histórico de pelo menos seis meses:

• Memória alocada às VMs contra a memória utilizável do cluster (total menos um nó).
• Storage em uso contra a capacidade utilizável, considerando replicação e folga de recuperação.
• Tempo de espera por CPU, por nó.
• Uso das interfaces de storage e de cluster no pico.
• Número de VMs e memória média por VM — o segundo revela mudança de perfil de carga.
• Crescimento mensal de cada um desses, em valor absoluto e em percentual.

E dois números que não são técnicos e decidem tudo:

• Prazo de aquisição. Quanto tempo leva entre decidir comprar e ter o nó em produção: cotação, aprovação, compra, entrega, instalação, configuração, entrada no cluster. Em muitas empresas, quatro meses é otimista.
• Ciclo de aprovação orçamentária. Se o orçamento é anual, o pedido precisa entrar no ciclo certo, e perder a janela significa esperar o ano seguinte.

O gatilho de compra

Com esses números, o gatilho deixa de ser opinião:

Gatilho = limiar de uso − (crescimento mensal × prazo de aquisição em meses) − margem de segurança

Um exemplo concreto. O cluster tem limiar utilizável de 75% de memória. O crescimento é de 3% ao mês. O prazo de aquisição é de 4 meses. A margem de segurança é de 5%.

Gatilho = 75% − (3% × 4) − 5% = 58%.

Ou seja: ao atingir 58% de memória alocada, inicia-se o processo de compra. Parece cedo. Não é — é o que garante que o nó novo entre antes de o limite ser alcançado.

A maioria dos ambientes que enfrenta crise de capacidade tinha o número na tela e nenhuma regra ligada a ele.

Vale também definir um gatilho de emergência — o ponto em que se para de aceitar novas cargas até a capacidade chegar. É desagradável e muito melhor que descobrir que um nó caiu e não há onde realocar.

Nó novo ou nó maior?

Quando chega a hora, a decisão tem mais camadas do que parece.

Adicionar um nó aumenta a capacidade total, reduz o custo relativo da redundância (de 1/3 para 1/4, e assim por diante), aumenta a tolerância a falha e, com storage distribuído, melhora o desempenho ao espalhar mais os dados.

Aumentar os nós existentes — mais memória, mais disco — é mais barato por unidade de recurso e não muda o custo relativo da redundância. Tem limite físico e exige parada de cada nó.

Um ponto que merece destaque: nós muito grandes concentram risco. Se cada nó tem 1 TB de memória, a queda de um exige 1 TB de folga distribuída nos outros. Em cluster pequeno, isso é caro. Nós de porte médio em maior número costumam produzir uma operação mais tranquila e mais barata em redundância.

A regra que usamos: cluster pequeno cresce em número de nós; cluster grande pode crescer em densidade.

Uma terceira opção frequentemente ignorada: recuperar capacidade sem comprar nada. Antes de qualquer aquisição, verifique:

• VMs superdimensionadas — memória alocada muito acima do uso real.
• VMs desligadas há meses ocupando disco.
• Snapshots esquecidos consumindo storage.
• Backups locais que deveriam estar no PBS.
• VMs de projetos encerrados.
• Templates e ISOs antigos.

Uma limpeza dessas costuma devolver de 10% a 20% da capacidade em ambientes que nunca passaram por revisão. É o nó mais barato que você pode adicionar.

O relatório mensal

Documento curto, uma página, que transforma dados em decisão:

1. Uso atual de memória, storage, CPU e rede, contra a capacidade utilizável.
2. Crescimento nos últimos 6 e 12 meses.
3. Projeção de quando cada recurso atinge o limiar.
4. Distância até o gatilho de compra.
5. Capacidade recuperável identificada (VMs superdimensionadas, ociosas, snapshots).
6. Recomendação: nenhuma ação, limpeza, ou iniciar processo de compra.

Esse relatório é também o que sustenta a conversa de orçamento. "Precisamos de mais um servidor" é um pedido; "no ritmo atual, ficamos sem capacidade de memória em julho, e o prazo de aquisição é de quatro meses" é um fato com data.

Erros comuns

• Planejar com a capacidade instalada em vez da utilizável.
• Esquecer a folga para a queda de um nó.
• Olhar só memória, e ser surpreendido pelo storage.
• Com Ceph, não considerar o fator de replicação nem a folga de recuperação.
• Monitorar percentual de uso de CPU em vez de tempo de espera.
• Não ter histórico, e projetar a partir do instantâneo.
• Não conhecer o prazo real de aquisição.
• Perder a janela orçamentária.
• Nenhum gatilho definido, e a compra vira reação.
• Comprar sem antes recuperar a capacidade desperdiçada.
• Crescer em nós gigantes, concentrando risco e encarecendo a redundância.
• Tratar capacity planning como tarefa eventual em vez de rotina mensal.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, implantamos capacity planning como rotina: coleta com histórico dos quatro recursos, cálculo da capacidade utilizável considerando redundância e replicação, projeção de crescimento, gatilho de compra calculado com o seu prazo de aquisição real, e o relatório mensal de uma página que serve tanto para a operação quanto para a conversa de orçamento. Começamos pela identificação de capacidade recuperável — que frequentemente adia a compra em meses e paga o trabalho.

Você sabe em que mês o seu cluster fica sem capacidade? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.