Cuando los equipos migran desde VMware o escapan de la lotería de los niveles de VPS compartido, suelen traer consigo sus viejos hábitos de dimensionamiento. El instinto es comprensible: si 8 vCPU mantenían la estabilidad en un host compartido ruidoso, ¿por qué reducir la asignación en un VDS que promete recursos reservados? Porque la lógica que impulsaba el sobreaprovisionamiento en infraestructura compartida juega activamente en tu contra en un servidor virtual dedicado, y la penalización de rendimiento es real.
Un VDS reserva su asignación completa de núcleos y memoria a nivel del host. Esa garantía elimina el problema del ruido de los vecinos que hacía razonable el sobredimensionamiento en un VPS, pero no cambia cómo el hipervisor planifica los hilos ni cómo el sistema operativo invitado gestiona la presión de memoria. La garantía de recursos está en la capa de asignación, no en la de aislamiento de metal desnudo. Las decisiones de dimensionamiento siguen siendo importantes y, en un VDS, importan más, porque estás pagando por una asignación específica y el hipervisor trabaja exactamente con lo que le diste.
Los dos modos de fallo son imagen especular el uno del otro: si asignas de menos, el workload se queda sin recursos; si asignas de más, introduces sobrecarga de planificación, desperdicio de memoria y, en algunas configuraciones, regresiones de latencia reales. Ambos son frecuentes durante las primeras semanas tras una migración.
La trampa del sobrecompromiso de CPU
Las instancias VDS corren sobre hipervisores, normalmente KVM, Xen o Hyper-V. El hipervisor planifica las vCPU frente a los núcleos físicos, y la proporción entre ambos determina si esa planificación es transparente o una fuente de contención. La documentación de Red Hat para RHEL 9 sitúa la proporción segura en aproximadamente 5 vCPU por núcleo físico para workloads que operan por debajo del 100% de utilización, y advierte explícitamente contra superar las 10 vCPU por núcleo físico en cualquier entorno de producción. Las guías orientadas a VMware son coherentes en términos generales: proporciones superiores a 3:1 empiezan a mostrar degradación medible, y en 6:1 la degradación significativa pasa a ser la norma esperada.
Lo contraintuitivo ocurre cuando asignas más vCPU de las que el workload realmente usa. La propia documentación de XenServer afirma que, para obtener el mejor rendimiento, el número de vCPU asignadas no debería superar el número de CPUs físicas disponibles para la VM. El motivo es la planificación: una VM con 8 vCPU exige que el hipervisor encuentre 8 ranuras de hilo físico simultáneas antes de poder ejecutar un evento planificado. Una VM con 2 vCPU ejecutando el mismo workload se planificará con frecuencia más rápido, con menor latencia en operaciones individuales. La sobreasignación no añade margen; añade deuda de planificación.
Asignar más vCPU de las que consume un workload no añade margen. Añade sobrecarga de planificación y, en un workload con poca carga, puede aumentar la latencia de forma medible.
El hyperthreading complica aún más la ecuación. La ganancia de rendimiento que aporta es real pero acotada: la guía oficial sitúa el techo en torno al 30%, y depende en gran medida de la aplicación. Un workload limitado por CPU con alta contención de hilos puede no obtener ninguna mejora, o incluso sufrir una regresión, si el planificador está llenando los hilos físicos con demanda de vCPU en competencia.
Lee el steal time antes de redimensionar
Si estás migrando desde un VPS compartido y sospechas que tu host anterior vendía capacidad en exceso, el steal time es la métrica que debes revisar antes de replicar la asignación antigua en tu nuevo VDS. El steal time, que se reporta como %st en la sección de CPU de top en guests Linux, mide el porcentaje de tiempo que el proceso de la VM espera en la CPU física para obtener su turno. Es una señal directa de contención a nivel del host.
Los umbrales publicados convergen en torno al mismo panorama: por debajo del 5% es normal y aceptable; entre el 5 y el 10% merece seguimiento; por encima del 10% es probable que haya ralentizaciones notables y la asignación o la ubicación del host necesitan atención. Un VDS de 4 núcleos en un host sobrevendido puede quedar por detrás de una máquina de 2 núcleos bien aprovisionada ejecutando el mismo workload. El número de núcleos sobre el papel no significa nada si el steal time es elevado.
Una advertencia importante: las herramientas de reporte estándar del sistema operativo no fueron diseñadas para entornos virtualizados, y las lecturas de steal time pueden ser en ocasiones falsos positivos, especialmente cuando el guest está prácticamente inactivo. La señal fiable es un steal time sostenido y elevado combinado con un porcentaje de inactividad cercano a cero. Si ambas condiciones se mantienen durante una ventana de observación significativa, el workload está siendo retrasado genuinamente a nivel del host. En un VDS correctamente aprovisionado, un steal sostenido por encima del 5% debería ser infrecuente; si no lo es, la conversación debe trasladarse a la ubicación del host, no solo al dimensionamiento del guest.
Memoria: primero el working set, luego la sobrecarga
La guía de rendimiento de VMware vSphere 8.0 plantea el dimensionamiento de memoria con claridad: asigna suficiente memoria para contener el working set de las aplicaciones que corren en la VM, y no más. La memoria que supera el working set acaba siendo utilizada por el sistema operativo invitado como caché del sistema de archivos, lo cual no es inútil, pero tampoco es el motivo por el que dimensionaste la instancia. Cuando la presión de memoria del host aumenta, el hipervisor recuperará esa memoria de caché mediante ballooning antes de tocar la memoria de las aplicaciones, pero sobreasignar desde el principio eleva la sobrecarga de memoria de la VM e incrementa el riesgo de swapping bajo carga pico.
El objetivo práctico según la guía de vSphere: mantener el compromiso en torno al 90% de la memoria asignada, en lugar del 100%, lo que deja al hipervisor margen para gestionar la presión sin activar el swap. La distribución NUMA también es relevante aquí. En hosts con varios sockets, los accesos a memoria que cruzan fronteras NUMA llevan asociada una penalización de latencia. Una VM dimensionada para caber dentro de un único nodo NUMA verá una latencia de memoria más consistente que una que abarca varios nodos, y vale la pena preguntar al respecto al seleccionar un nivel de instancia para workloads sensibles a la latencia.
Un flujo de trabajo práctico para migraciones a VDS
La secuencia correcta para la asignación de recursos en un VDS es: medir primero, asignar después y verificar antes de fijar el tamaño.
- Perfila el workload en el host antiguo. Recopila utilización de CPU, working set de memoria y steal time durante al menos una semana, cubriendo cualquier trabajo por lotes o pico de tráfico. Este es el baseline para el que realmente estás dimensionando, no el pico que temías en un host compartido.
- Empieza de forma conservadora con las vCPU. Ajusta el número de vCPU a la utilización real de hilos en pico, no a lo que tenías antes. Un workload que llega al 60% en 4 vCPU es candidato a 4 vCPU, no a 8. Puedes escalar hacia arriba; el coste de la sobreasignación se paga de forma continua.
- Dimensiona la memoria según el working set, no según la RAM instalada en el host antiguo. Comprueba la actividad del balloon driver y el uso de swap en el entorno anterior. Si el ballooning nunca se activó, la asignación ya era generosa. Ajusta al working set observado más un margen razonable, apuntando a un compromiso del 90%.
- Verifica con
%sty métricas de presión de memoria tras el despliegue. Ejecuta el workload durante al menos 48 horas bajo carga realista antes de dar el dimensionamiento por definitivo. Un steal time sostenido por encima del 5%, o actividad de swap bajo carga normal, son señales para revisar tanto la asignación como la ubicación del host.
Dónde la ubicación importa tanto como la asignación
Las decisiones de asignación de recursos no existen de forma aislada respecto a dónde corre realmente el VDS. Para workloads financieros e industriales en la región DACH, ubicamos las instancias VDS sensibles a la latencia en MUC1, en Múnich, donde el clúster está construido específicamente en torno a ese perfil de cliente y la densidad física se gestiona en consecuencia. La misma asignación en un host mal adaptado al tipo de workload rendirá de forma diferente que en uno optimizado para él. Esto no es una característica de ningún nivel de VDS en particular; es consecuencia de cómo se planifica la capacidad del host y qué workloads comparten una máquina física.
La disciplina de la asignación de recursos en un VDS es, en última instancia, la disciplina de conocer lo que tu workload hace realmente, no lo que hacía en una infraestructura diseñada para compensar vecinos impredecibles. Los recursos reservados solo son tan valiosos como la precisión de la asignación. Mide el perfil real, dimensiona en función de él, y la diferencia de rendimiento respecto a un nivel de VPS compartido se hace inmediatamente visible en las métricas que importan: latencia p99, tiempo de espera del planificador y presión de memoria bajo carga.
