Evaluación de capacidad en virtualización: métricas que evitan compras innecesarias

Decidir si una infraestructura virtualizada necesita más hardware es una de las preguntas más caras que enfrenta un gerente TI. Ampliar servidores, memoria o storage implica presupuesto, tiempos de implementación y riesgo operacional. Pero la mayoría de las evaluaciones de capacidad se hacen con datos incompletos: se observa el porcentaje de uso del host y se concluye que "faltan recursos". Esa aproximación, aunque común, suele llevar a inversiones que no resuelven el problema real.

La diferencia entre una compra justificada y una compra por síntoma mal diagnosticado está en la calidad de la observación. Evaluar capacidad en un entorno virtualizado no es mirar cuán ocupado está el servidor físico: es entender qué están demandando las máquinas virtuales, cómo compiten entre ellas por los recursos del hipervisor y dónde está el cuello de botella real.

Por qué evaluar capacidad no es lo mismo que medir uso

En un servidor físico tradicional, el uso de CPU, memoria y disco del sistema operativo refleja directamente la carga de las aplicaciones. En un entorno virtualizado, esa relación se rompe. El hipervisor intermedia cada solicitud de recurso, y lo que muestra el host puede no coincidir con lo que experimenta cada máquina virtual.

Un host con CPU al 60% de uso puede tener máquinas virtuales con rendimiento degradado si existe contención en las colas de ejecución. Un servidor con memoria libre puede estar haciendo swapping hacia disco si el hipervisor no logra asignar páginas de forma eficiente. Un storage con IOPS aparentemente suficientes puede presentar latencias altas en momentos de pico que afectan la experiencia de los usuarios finales.

Por eso, evaluar capacidad exige observar tres capas: la demanda de cada VM, la contención en el hipervisor y el comportamiento del storage. Medir solo el host es como revisar la presión del agua en la matriz principal sin mirar si los departamentos reciben caudal suficiente.

Métricas críticas: CPU, memoria y storage en entornos virtualizados

CPU: más allá del porcentaje de uso

El porcentaje de uso de CPU del host es la métrica menos informativa. Lo que realmente importa en plataformas como VMware vSphere o Hyper-V es:

• CPU Ready Time: tiempo que una VM espera para que el hipervisor le asigne un núcleo físico. Valores sostenidos sobre 5-10% indican contención real.
• Co-Stop: en VMs con múltiples vCPUs, el tiempo que los núcleos virtuales esperan sincronizarse. Aparece cuando hay más vCPUs asignadas que núcleos físicos disponibles.
• CPU Entitlement vs. Demand: la diferencia entre lo que la VM tiene garantizado y lo que realmente necesita.

Un host al 80% de uso con ready time bajo puede estar operando correctamente. Un host al 50% con ready time alto tiene un problema de configuración o de sobreasignación de vCPUs.

Memoria: el síntoma clásico de mala evaluación

La memoria es donde más errores se cometen. En virtualización, el hipervisor usa técnicas como ballooning (el driver reclama páginas de memoria a la VM) y swapping hacia archivos en disco. Ambas degradan el rendimiento, pero no siempre se reflejan en el uso de memoria del host.

Señales a observar:

• Ballooning activo: indica que el hipervisor está presionando a las VMs para recuperar memoria.
• Swap del hipervisor: más grave que el ballooning, porque implica escritura a disco.
• Memoria activa vs. asignada: muchas VMs tienen memoria asignada que nunca usan. Ese es el primer candidato a optimización.

Un host con 80% de memoria usada puede estar saludable si no hay ballooning ni swap. Un host al 60% con swap activo tiene un problema que no se resuelve agregando RAM al servidor, sino ajustando reservas o moviendo cargas.

Storage: IOPS, latencia y el efecto "noisy neighbor"

El storage es el recurso más difícil de evaluar porque combina capacidad, rendimiento y latencia. Las métricas clave son:

• IOPS por VM y por host: no basta con el total del array.
• Latencia de lectura y escritura: en VMware, valores sobre 20-30 ms en datastores compartidos indican problemas.
• Queue depth y comandos abortados: señales de saturación en el controlador o el array.

Un storage con 70% de capacidad usada puede estar saturado en IOPS. Uno con 30% de uso puede tener latencias altas por una VM que genera I/O intensivo y afecta a las demás. Ese efecto "noisy neighbor" es la causa más frecuente de diagnósticos erróneos.

Errores frecuentes al evaluar capacidad

Mirar solo el promedio

El promedio oculta los picos. Una infraestructura puede tener un uso promedio de CPU del 40% y aun así presentar ventanas de saturación durante horas críticas. La evaluación debe considerar percentiles (P95, P99) y ventanas de tiempo específicas: horario laboral, procesos batch nocturnos, cierres de mes.

Confundir uso del host con experiencia del guest

El host puede mostrar recursos disponibles mientras las VMs experimentan contención. La única forma de saberlo es correlacionar métricas del hipervisor con métricas dentro de cada VM. Si la VM reporta ready time alto pero el host está al 50%, el problema es de configuración, no de capacidad.

Ampliar por un síntoma mal diagnosticado

Un swap de memoria puede llevar a comprar más RAM cuando el problema real es una VM con memoria asignada excesiva que presiona al hipervisor. Una latencia de storage puede llevar a comprar discos más rápidos cuando el problema es una VM con I/O descontrolado. Ampliar hardware sin identificar la causa raíz es la forma más cara de no resolver el problema.

Ignorar la sobreasignación

La sobreasignación (overcommitment) de vCPU y memoria es normal y deseable en virtualización, pero tiene límites. Evaluar capacidad sin revisar la relación entre recursos asignados y recursos físicos disponibles es incompleto. Una relación de 4:1 en vCPU puede funcionar en cargas livianas y colapsar en cargas transaccionales.

Proceso práctico: de la observación a la decisión

1. Establecer una línea base

Antes de decidir, hay que saber cómo se comporta la infraestructura en condiciones normales. Esto requiere al menos 4-6 semanas de datos con resolución de 5 minutos, no promedios diarios. La línea base debe incluir: uso de CPU por VM, ready time, memoria activa, ballooning, swap, IOPS y latencia por datastore.

2. Correlacionar métricas

El paso siguiente es cruzar métricas del hipervisor con métricas del sistema operativo invitado. Una VM con CPU al 90% dentro del guest y ready time bajo tiene un problema de aplicación, no de capacidad del host. Una VM con CPU al 30% dentro del guest y ready time alto tiene un problema de contención en el hipervisor.

3. Identificar la causa raíz

Clasificar los hallazgos en tres categorías:

• Problemas de configuración: vCPUs sobreasignadas, reservas mal definidas, límites incorrectos.
• Problemas de distribución: cargas mal balanceadas entre hosts, VMs "ruidosas" que afectan a otras.
• Problemas reales de capacidad: todos los hosts del clúster presentan contención simultánea en el mismo recurso.

4. Evaluar optimización antes de comprar

Antes de ampliar hardware, conviene agotar las opciones de optimización:

• Rightsizing: reducir vCPUs o memoria asignada a VMs que no las usan.
• Reclaim de recursos: recuperar memoria inactiva y discos huérfanos.
• Balanceo de cargas: distribuir VMs entre hosts para eliminar puntos calientes.
• Storage optimization: mover VMs de alto I/O a datastores de mejor rendimiento.

5. Decidir con datos

La ampliación de hardware es la respuesta correcta cuando, después de optimizar, la contención persiste en un recurso específico y afecta el rendimiento de las aplicaciones. Ahí sí tiene sentido invertir. Para profundizar en las señales que indican que llegó ese momento, puedes revisar nuestro artículo sobre Capacidad en virtualización: cómo saber si necesitas ampliar hardware.

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

Evaluar capacidad no es un ejercicio puntual: es un proceso continuo que requiere herramientas, metodología y experiencia. En Mister IT trabajamos con gerentes TI que necesitan tomar decisiones de inversión con datos confiables, no con sensaciones. Nuestro servicio de Infraestructura & Virtualización incluye análisis de capacidad, identificación de cuellos de botella y recomendaciones de optimización antes de recomendar cualquier compra.

Si estás evaluando si tu infraestructura virtualizada necesita más hardware, conversemos. Podemos ayudarte a responder esa pregunta con métricas, no con suposiciones.