Dimensionar una máquina virtual a ojo suele acabar en dos escenarios costosos: sobreaprovisionamiento que dispara la factura de vCPU y RAM, o infradimensionamiento que provoca swapping y latencia en producción. Esta calculadora de recursos para VM traduce el número de usuarios concurrentes, el tipo de carga (web, base de datos, batch) y el margen de crecimiento deseado en una cifra concreta de vCPU, RAM y disco. El cálculo se hace en el navegador y sirve como punto de partida antes de aprovisionar en VMware, Proxmox, KVM o cualquier nube pública.
vCPU: cuántos núcleos asignar sin sobrecomprometer el host
La mayoría de hipervisores permiten overcommit de CPU, es decir, asignar más vCPU virtuales que núcleos físicos existen, apostando a que no todas las VM piden CPU al mismo tiempo. Un ratio de 2:1 o 3:1 es razonable para cargas web con picos intermitentes; para bases de datos o cargas de cálculo intensivo, mantén 1:1 para evitar contención de scheduler. Como regla de partida: 1 vCPU cubre entre 50 y 150 usuarios concurrentes en una app web ligera con caché, y ese número cae a 20-40 si la app ejecuta lógica de negocio pesada en cada petición.
RAM: separar caché de sistema operativo de memoria de aplicación
La RAM total de una VM se reparte entre el proceso de aplicación, el runtime (JVM, Node, PHP-FPM), la caché de página del kernel y el margen de seguridad para evitar el OOM killer. Una API en Node.js con 500 conexiones concurrentes suele necesitar entre 1 y 2 GB de heap más 512 MB de margen del sistema; un MySQL o PostgreSQL con innodb_buffer_pool o shared_buffers a un 60-70% de la RAM disponible rinde muchísimo mejor que uno infradimensionado que golpea disco en cada consulta. No asignes toda la RAM física del host a una sola VM: deja siempre un 10-15% para el hipervisor.
Disco: IOPS, throughput y tamaño no son lo mismo
Un error habitual es dimensionar sólo por gigabytes libres e ignorar los IOPS que la carga necesita. Una base de datos transaccional con escrituras frecuentes puede necesitar 3000-5000 IOPS sostenidos, algo que un disco SSD de red genérico no siempre garantiza sin aprovisionar IOPS explícitamente (como los volúmenes io2 de AWS o los discos Premium SSD v2 de Azure). Para cargas de solo lectura o logs, el throughput secuencial importa más que la latencia por operación. Reserva siempre un 20-30% de espacio libre adicional al calculado: los sistemas de archivos degradan su rendimiento por encima del 85-90% de ocupación.
Factor de crecimiento y picos estacionales
Dimensionar para el tráfico medio actual es un error si tu negocio tiene campañas, lanzamientos o estacionalidad (Black Friday, matrícula universitaria, cierre fiscal). Aplica un multiplicador de pico de al menos 2x-3x sobre el uso medio para CPU y RAM si no tienes autoscaling, y monitoriza el percentil 95 de uso real durante al menos dos semanas antes de fijar el tamaño definitivo. En entornos con autoscaling horizontal, dimensiona cada instancia para el caso medio y deja que el grupo de escalado absorba los picos añadiendo réplicas.
Overcommit en hipervisores: VMware, Proxmox y KVM
VMware vSphere permite overcommit tanto de CPU como de memoria mediante ballooning y compresión de páginas, pero un ratio de overcommit de memoria superior a 1.5:1 empieza a generar swap a nivel de hipervisor, mucho más lento que el swap dentro del propio guest. Proxmox (basado en KVM/QEMU) expone el mismo mecanismo vía KSM (Kernel Samepage Merging) para deduplicar páginas de memoria idénticas entre VMs, útil cuando corres muchas VMs con el mismo sistema operativo base. Antes de sobrecomprometer memoria en producción, valida con pruebas de carga reales.
De la VM al contenedor: cuándo migrar la carga
Si tu aplicación ya está containerizada o vas a migrarla, los mismos cálculos de CPU y RAM sirven como requests y limits de Kubernetes, pero con matices: en contenedores el overhead de sistema operativo desaparece casi por completo, así que puedes ser más ajustado. Usa el generador de manifiestos de Kubernetes de esta web para traducir directamente estos números a un Deployment con requests/limits bien definidos, y evita el mismo error clásico de contenedores: no poner límites de memoria y sufrir un OOMKill inesperado en producción.
Errores frecuentes al dimensionar una VM
El más común es copiar el tamaño de una VM de otro proyecto sin medir la carga real. El segundo es no dejar margen de disco para logs y backups locales, que crecen de forma silenciosa hasta llenar la partición raíz. El tercero es asignar demasiadas vCPU a una aplicación con baja concurrencia real: más núcleos no aceleran una tarea de un solo hilo, y en cargas con mucho cambio de contexto (context switching) un exceso de vCPU virtuales puede incluso degradar el rendimiento por la sobrecarga del scheduler del hipervisor.
Casos de uso comunes
- Dimensionar una nueva VM antes de solicitarla al equipo de infraestructura o a un proveedor cloud.
- Estimar el coste mensual comparando el resultado con el calculador de coste de servidor.
- Planificar la migración de una app de un VPS pequeño a uno mayor antes de un pico de tráfico previsto.
- Justificar ante dirección el tamaño de instancia solicitado con cifras basadas en usuarios concurrentes.
- Definir requests y limits de Kubernetes a partir del dimensionado equivalente en VM.
Buenas prácticas
- Mide el percentil 95 de uso real durante al menos dos semanas antes de fijar el tamaño definitivo.
- Deja un 20-30% de disco libre adicional; el rendimiento cae por encima del 85-90% de ocupación.
- No comprometas memoria más allá de 1.5:1 en hipervisores de producción críticos.
- Separa el dimensionado de CPU del de IOPS: son cuellos de botella independientes.
- Revisa el tamaño cada trimestre; las cargas de trabajo cambian más rápido de lo que se documenta.