Não existe um número único de VMs por host. A densidade correta é calculada a partir das características do hardware e do perfil de consumo das suas VMs. Subestimar resulta em hardware subutilizado e custo desnecessário. Superestimar cria gargalos, instabilidade e SLA comprometido. Este guia te dá o modelo mental e o exemplo numérico para calcular o número certo para o seu ambiente.
As quatro variáveis que determinam densidade
Antes de qualquer número, você precisa entender que a densidade de VMs num host físico é sempre limitada pelo recurso mais escasso. Pense num funil: de um lado entram CPU, RAM, storage I/O e rede; do outro saem VMs. O gargalo do funil é o recurso que esgota primeiro — e você vai descobrir que, na maioria dos workloads de aplicação e negócio, esse gargalo é RAM.
CPU — o recurso mais sobrecomprometível. Diferente da RAM, a CPU é um recurso temporal: ela processa em ciclos, e os processos competem por esses ciclos. O hypervisor faz scheduling de CPU, dividindo o tempo dos cores físicos entre as vCPUs das VMs. Isso significa que você pode — com cuidado — atribuir mais vCPUs às VMs do que cores físicos existem no host. Esse é o overcommit de CPU.
Ratios de overcommit de CPU de 4:1 a 8:1 são comuns e geralmente seguros para workloads de aplicação de negócio. Um host com 32 cores pode suportar de 128 a 256 vCPUs alocadas, contanto que as VMs não estejam todas usando CPU intensivamente ao mesmo tempo. Para workloads de banco de dados ou processamento contínuo, o overcommit deve ser mais conservador — 2:1 ou 3:1.
RAM — o limitante real na maioria dos ambientes. Memória RAM não pode ser compartilhada da mesma forma que CPU. Cada VM precisa de RAM fisicamente disponível para o que está em uso. O hypervisor tem técnicas como balão de memória (memory ballooning) e transparente huge pages para recuperar RAM de VMs ociosas, mas são mecanismos de alívio, não de overcommit agressivo.
O overcommit de RAM raramente passa de 1,2:1 a 1,5:1 em ambientes saudáveis. Na prática, isso significa que a RAM disponível no host define diretamente quantas VMs cabem, e qualquer cálculo de densidade começa pela memória.
Storage I/O — invisível até virar problema. Muitas VMs lendo e escrevendo em disco ao mesmo tempo criam contenção de I/O. O número de VMs que o storage consegue servir com latência aceitável depende do tipo de storage (SSD NVMe aguenta muito mais operações por segundo do que HDD SATA), da arquitetura (storage local vs SAN vs NFS), e do perfil de I/O de cada VM.
VMs de banco de dados são especialmente intensivas em I/O. Uma única VM Oracle com workload OLTP pesado pode consumir mais IOPS do que 20 VMs de aplicação web. Ao calcular densidade, identifique as VMs com I/O intenso e avalie se o storage consegue servir todas simultaneamente dentro da latência aceitável.
Rede — raramente o gargalo primeiro. Com interfaces de 10 GbE ou 25 GbE nos hosts modernos, a rede raramente é o primeiro recurso a esgotar. Mas em ambientes com muitas VMs de processamento de dados que geram tráfego de rede intenso (replicação de banco, transferência de arquivos grandes, streaming), vale verificar que a capacidade de rede do host não será o gargalo.
A regra do headroom para HA — e por que ela muda o cálculo
Aqui está um aspecto que muitos cálculos iniciais ignoram: se você usa HA (High Availability) no cluster — onde o hypervisor reinicia automaticamente VMs de um host que falhou nos hosts restantes — você precisa manter capacidade ociosa suficiente para absorver o peso de pelo menos um host caindo.
A regra padrão é: num cluster de N hosts, dimensione como se tivesse N-1 hosts. O host “fantasma” é a reserva para HA.
Para um cluster de 4 hosts, você dimensiona para 3. Para um cluster de 8 hosts, dimensiona para 7. Essa reserva de 25% (num cluster de 4) ou 12,5% (num cluster de 8) de capacidade não pode ser usada para VMs normalmente — ela existe para que, quando um host cair, o cluster tenha onde colocar as VMs.
Isso tem impacto direto na densidade máxima que você pode configurar. Se você encher todos os 4 hosts ao máximo, quando um cair, não há onde reiniciar as VMs.
O exemplo numérico concreto
Vamos calcular a densidade de um servidor real em dois cenários.
O hardware: Um host com 2 processadores Intel Xeon, 24 cores físicos cada (48 cores totais), 512 GB de RAM, storage SSD NVMe com 500.000 IOPS, rede 25 GbE.
Cenário A — Workload de aplicação web (Java/Node.js, APIs, frontends):
- Cada VM: 4 vCPUs, 16 GB de RAM, 100 GB de disco
- Overcommit de CPU 6:1 aceito: 48 cores × 6 = 288 vCPUs disponíveis → 72 VMs pela CPU
- RAM sem overcommit agressivo: 512 GB ÷ 16 GB = 32 VMs pelo RAM
- I/O estimado: 500 IOPS por VM → 32 VMs × 500 = 16.000 IOPS necessários (ok para o NVMe)
- Limitante: RAM — 32 VMs por host
- Com headroom de HA (cluster de 4 hosts, reserva 1): 32 × 3 = 96 VMs no cluster — efetivamente 24 VMs por host em operação normal
Cenário B — Workload de banco de dados (PostgreSQL, MySQL):
- Cada VM: 8 vCPUs, 64 GB de RAM, 500 GB de disco
- Overcommit de CPU conservador 2:1: 48 × 2 = 96 vCPUs → 12 VMs pela CPU
- RAM: 512 GB ÷ 64 GB = 8 VMs pelo RAM
- I/O: 5.000 IOPS por VM de banco → 8 VMs × 5.000 = 40.000 IOPS (ok para NVMe, mas precisa validar)
- Limitante: RAM — 8 VMs de banco por host
- Com headroom de HA (cluster de 4 hosts): 8 × 3 = 24 VMs de banco no cluster — efetivamente 6 VMs por host em operação normal
Note a diferença radical: o mesmo hardware suporta 32 VMs de aplicação mas só 8 VMs de banco de dados, porque os bancos de dados consomem muito mais RAM por instância.
Diferença de densidade por tipo de workload
Esta é uma das coisas mais importantes que um arquiteto de infraestrutura precisa entender: não existe “densidade de VMs” genérica. Existe densidade para um perfil específico de workload.
VDI (desktops virtuais): Alta densidade possível porque usuários humanos não usam CPU em paralelo — raramente todos digitam ao mesmo tempo. Um host de 512 GB pode suportar 100 a 150 sessões VDI de usuário de tarefa (2 a 4 GB de RAM cada), mas a CPU precisa ser dimensionada com overcommit conservador porque em momentos de boot storm (quando todos ligam de manhã), o CPU spike é real.
Aplicação web e API: Densidade média-alta. Overcommit de CPU de 4:1 a 6:1 funciona bem porque as VMs têm picos pontuais mas não contínuos. RAM é o limitante.
Banco de dados: Baixa densidade. Alto consumo de RAM, overcommit de CPU conservador, I/O intenso. É a carga de trabalho mais cara por VM em termos de host físico.
Desenvolvimento e labs: Altíssima densidade possível, porque essas VMs ficam ociosas a maior parte do tempo. Overcommit de CPU de 8:1 a 16:1 é aceitável. RAM pode ter overcommit maior. VMs de dev são ideais para aproveitar ao máximo a capacidade de hosts menores.
Os números que você não pode ignorar
Para fechar, os benchmarks de mercado que servem como referência inicial (sempre ajuste para o seu contexto):
Overcommit de CPU de 4:1 a 8:1 para workloads de aplicação geral. Abaixo de 3:1 para bancos de dados. Acima de 8:1 exige análise cuidadosa e monitoramento intenso.
Overcommit de RAM de 1,0:1 a 1,2:1 para produção crítica. Até 1,5:1 para ambientes controlados com monitoramento. Acima de 1,5:1 é território de risco que precisa de justificativa e gestão ativa.
Headroom de HA: planeje sempre com capacidade para N-1 hosts em operação. Não tente economizar nessa reserva — ela existe para o momento mais crítico que você vai enfrentar.
Precisa dimensionar um ambiente de cloud privada para o seu workload? Os arquitetos da Adentro calculam a capacidade certa com base no seu perfil real de VMs. Fale com a gente.