Dimensionar CPU, RAM y disco para virtualizar: cómo evitamos sobre y subcomprar

Si hay un lugar donde se tira dinero en infraestructura, es al dimensionar hardware para virtualizar —y se tira en las dos direcciones—. Comprar de más "por si acaso" deja capital dormido depreciándose; quedarse corto estrangula todas las VMs a la vez y obliga a recomprar en un año. El punto medio no se adivina: se calcula, y cada recurso se calcula distinto.

CPU: el overcommit es tu amigo (con criterio)

La virtualización permite overcommit de CPU —asignar más vCPUs que núcleos físicos— porque no todas las VMs trabajan al mismo tiempo. Con cargas mixtas de oficina, una proporción de varias vCPU por núcleo físico suele funcionar sin problema. Pero en exceso aparece la contención: el temido "CPU steal", las VMs haciendo fila por el procesador, y todo se arrastra. El overcommit ahorra; el overcommit ciego, no.

RAM: mucho más cuidado que la CPU

Aquí la regla cambia. La memoria se sobreasigna con mucha más prudencia: quedarse sin RAM es más grave que sin ciclos de CPU, porque el sistema empieza a usar disco como memoria (swap) y el rendimiento se desploma de golpe. El margen de RAM se respeta; no se apuesta con él como con la CPU.

Disco: el error de mirar GB e ignorar IOPS

El error más común y más caro: comprar almacenamiento por capacidad ("necesito 10 TB") e ignorar el rendimiento. Pero las VMs no sienten los gigabytes; sienten los IOPS, las operaciones por segundo. Ejemplo concreto: veinte VMs sobre un disco mecánico grande pero lento se estrangulan compitiendo por IOPS, mientras el mismo espacio en SSD las respira sin problema. La capacidad dice cuánto guardas; los IOPS dicen qué tan rápido, y eso es lo que se nota.

Cómo lo dimensionamos

Partimos del consumo real de las cargas actuales —no de estimaciones al alza—, proyectamos un crecimiento razonable, y calculamos CPU, RAM e IOPS por separado, con la calculadora de dimensionamiento Proxmox. El objetivo: pagar por lo que necesitas más un margen sensato, ni más ni menos. Y de cuántas VMs terminarás poniendo encima hablamos en densidad de VMs.

Un ejemplo rápido de dimensionamiento

Para aterrizarlo: supón 20 VMs que en conjunto usan de verdad ~120 GB de RAM y picos de ~8 núcleos simultáneos. La RAM se dimensiona con poco margen de sobreventa: necesitas del orden de 128 GB físicos reales más cabecera para el hipervisor, no "los 320 GB que suman sus asignaciones máximas". La CPU sí admite overcommit: esos 8 núcleos de pico real caben con holgura en, digamos, 16 físicos, aunque las VMs tengan asignadas muchas más vCPU en papel. Y el disco se elige por IOPS: si esas 20 VMs generan carga aleatoria, un arreglo con SSD manda sobre uno de mayor capacidad pero mecánico. El número que importa nunca es la suma de las etiquetas.

La pregunta que conviene hacerse

Antes de cotizar, la pregunta no es "¿cuántos GB y GHz compro?", sino ¿conozco el consumo real de mis cargas —incluidos los IOPS— o estoy comprando por la etiqueta? Ese cálculo es parte de cómo diseñamos servidores de alto rendimiento.