Capacidad en virtualización: cómo saber si necesitas ampliar hardware

Cuando una plataforma virtualizada empieza a mostrar lentitud, errores intermitentes o tiempos de respuesta erráticos, la primera reacción suele ser la misma: "necesitamos más hardware". Esa conclusión, muchas veces apresurada, puede traducirse en inversiones innecesarias que no resuelven el problema de fondo.

La pregunta correcta no es "¿cuánto hardware compro?", sino "¿cómo sé que el problema es realmente de capacidad?". Responderla exige un proceso de diagnóstico que combine métricas, correlación y contexto operacional. Este artículo entrega criterios técnicos para hacer esa evaluación antes de comprometer presupuesto.

¿Qué significa realmente "capacidad" en un entorno virtualizado?

En infraestructura física, capacidad es un concepto relativamente directo: un servidor tiene tantos núcleos, tanta memoria y tanto storage. En un entorno virtualizado, la ecuación cambia porque los recursos se comparten, se abstraen y se asignan dinámicamente entre múltiples cargas de trabajo.

CPU, memoria y storage no operan como silos independientes. Una VM que satura storage genera latencia que afecta el rendimiento general del hypervisor. Un host con memoria presionada comienza a hacer swapping, lo que consume CPU y degrada todo lo que corre sobre él. Por eso, evaluar capacidad exige mirar el sistema completo, no solo el recurso que muestra la alerta.

Además, la capacidad útil de un host no es la suma de sus recursos físicos. El hypervisor consume una porción, las reservas de alta disponibilidad restan capacidad disponible y las sobreasignaciones (overcommit) crean una diferencia entre lo que está "asignado" y lo que realmente se puede entregar. Evaluar capacidad es, en gran parte, entender esa diferencia.

Señales técnicas de que la capacidad se está agotando

Existen métricas específicas que indican, con bastante precisión, si un recurso está llegando a su límite real. Estas son las más relevantes:

CPU ready (tiempo de espera de CPU): Mide el tiempo que una VM espera para acceder a un núcleo físico. En VMware, valores sostenidos sobre 5-10% indican contención real de CPU. En Hyper-V, la métrica equivalente es "CPU wait time per dispatch". Si una VM muestra CPU ready alto pero el host tiene CPU libre, el problema puede ser de distribución de carga o de límites de reserva mal configurados.

Co-stop (solo VMware): Ocurre cuando VMs con múltiples vCPU en el mismo socket esperan simultáneamente por ciclos de CPU. Es una señal de sobreasignación de vCPU por núcleo físico, no necesariamente de falta de hardware.

Presión de memoria: El swapping y el ballooning son mecanismos del hypervisor para recuperar memoria cuando hay presión. Si ves swapping activo en las VMs o ballooning constante en los hosts, la memoria física está llegando a su límite. Los contadores "memory swap rate" y "ballooned memory" son los indicadores a observar.

Latencia y IOPS de storage: La métrica clave es la latencia, no el throughput. En VMware, valores sobre 20-30 ms en "total latency" indican problemas serios. En storage compartido, la saturación de colas (queue depth) y la latencia por IOPS son señales de que el backend de almacenamiento no da abasto.

Saturación de colas de red: Aunque menos mencionada, la red también es capacidad. Colas de transmisión llenas, drops de paquetes y latencia creciente en el vSwitch son señales de que el tráfico supera la capacidad del enlace o del procesamiento de red del host.

Errores frecuentes al evaluar capacidad

El diagnóstico de capacidad está lleno de trampas. Estos son los errores más comunes que llevan a decisiones equivocadas:

Confundir uso promedio con picos: Un host que promedia 40% de CPU puede tener picos diarios de 95% durante la jornada laboral. Si solo miras promedios, nunca verás el problema real. La evaluación debe considerar percentiles (P95, P99) y ventanas de tiempo específicas.

Ampliar hardware cuando el problema es de configuración: Una VM con CPU ready alto puede tener demasiadas vCPU asignadas (por ejemplo, 8 vCPU para una carga que usa 2). El hypervisor pierde eficiencia al coordinar vCPU ociosas. Reducir vCPU puede resolver el problema sin tocar el hardware.

Ignorar la relación entre recursos: Un problema de storage puede manifestarse como lentitud general percibida como "falta de CPU". Si no correlacionas métricas entre recursos, puedes ampliar el componente equivocado.

No considerar la distribución de carga: Un cluster con dos hosts donde uno concentra el 80% de las VMs críticas no tiene un problema de capacidad total, sino de balanceo. Migrar cargas puede ser más efectivo que comprar hardware.

Método práctico para evaluar capacidad antes de ampliar hardware

Un proceso de evaluación riguroso debería seguir estos pasos:

1. Medir durante un ciclo completo. Recolecta métricas durante al menos 30 días, cubriendo ciclos de negocio completos (inicios de mes, cierres contables, campañas). Las ventanas de 24 horas no son suficientes.

2. Correlacionar métricas entre recursos. Cuando veas una alerta de CPU, revisa simultáneamente memoria, storage y red. Pregúntate: ¿la latencia de storage sube antes que el CPU ready? ¿El swapping comienza antes que la contención de CPU? La secuencia temporal revela la causa raíz.

3. Comparar contra una línea base. Necesitas saber qué es "normal" en tu entorno. Si el CPU ready siempre ha estado en 3% y ahora está en 8%, hay un cambio. Si siempre ha estado en 8% y las VMs funcionan bien, quizás ese es tu punto de equilibrio.

4. Probar antes de comprar. Antes de ampliar hardware, simula el cambio: migra VMs, ajusta reservas, redistribuye carga. Muchas veces, el "problema de capacidad" se resuelve con rebalanceo o ajuste de configuración.

5. Documentar y decidir con datos. La decisión de ampliar hardware debe basarse en un informe que muestre: qué recurso está saturado, durante cuánto tiempo, en qué percentiles, y qué se intentó antes de llegar a la conclusión de que falta capacidad física.

Cuándo la ampliación de hardware es realmente necesaria

Existen escenarios donde la ampliación es legítima e inevitable:

• Saturación sostenida de CPU ready por encima del 10-15% en múltiples hosts, con VMs correctamente dimensionadas y carga balanceada.
• Presión de memoria constante con swapping activo incluso después de ajustar reservas y límites.
• Latencia de storage que no mejora con optimización de configuración, deduplicación o cambios en la distribución de discos.
• Crecimiento estructural de la demanda: el negocio está creciendo y el consumo de recursos aumenta de forma consistente mes a mes, no como un pico puntual.

En estos casos, la ampliación es una respuesta a una necesidad real, no una reacción a un síntoma mal diagnosticado.

Cómo Mister IT puede ayudarte a evaluar tu infraestructura virtualizada

Evaluar capacidad no es un ejercicio teórico: requiere herramientas, experiencia y un método probado. En Mister IT, nuestro equipo de Infraestructura & Virtualización trabaja con gerentes TI y jefaturas de operaciones para diagnosticar plataformas virtualizadas antes de que se tomen decisiones de inversión.

Realizamos análisis de capacidad que incluyen: recolección de métricas en ventanas de tiempo relevantes, correlación entre recursos, identificación de problemas de configuración y recomendaciones accionables. El objetivo es que sepas con certeza si necesitas ampliar hardware o si el problema se resuelve con ajustes de configuración, rebalanceo o rediseño de la plataforma.

Si estás viendo señales de agotamiento de capacidad en tu infraestructura virtualizada y no quieres invertir basándote en suposiciones, conversemos sobre cómo evaluar tu entorno antes de la próxima compra de hardware.