VCF 9.1 Infrastructure Placement Policies: por fin gobernar dónde corren tus VMs de IA

El problema de fondo: hardware heterogéneo y cargas exigentes

Quien lleva tiempo gestionando entornos VMware sabe que el placement de VMs siempre ha sido una cuestión de DRS, afinidad y antiafidad, y esperanza. Con cargas tradicionales eso basta. Pero cuando empiezas a meter workloads de IA —modelos de inferencia, pipelines de entrenamiento, VMs con acceso a GPU pasthrough o vGPU— el modelo clásico se rompe: no todos los hosts tienen GPU, no todas las GPUs son iguales, y una VM que aterrice en el host equivocado sencillamente no arranca o rinde a una fracción de lo esperado.

VCF 9.1 aborda esto de raíz con las Infrastructure Placement Policies, un mecanismo que permite definir de forma declarativa y estricta los requisitos de infraestructura que debe cumplir un host para alojar una VM determinada. No es DRS con reglas blandas: es una restricción dura que el scheduler respeta sin excepciones.

Qué son y cómo funcionan

Las Infrastructure Placement Policies se definen a nivel de workload domain o cluster y asocian características de infraestructura —tipo de GPU, generación de hardware, capacidades de red, etiquetas de rack o zona— con clases de VMs o workloads. Cuando el scheduler de VCF intenta colocar una VM, evalúa primero si el host candidato cumple la política asignada. Si no cumple, el host queda fuera del conjunto elegible, independientemente de su carga o disponibilidad de recursos genéricos.

El resultado práctico: puedes garantizar que tus VMs de inferencia con NVIDIA H100 solo van a hosts con esa GPU, y que ningún DRS las va a migrar a un host sin ella en un momento de presión de recursos. Algo que, hasta ahora, requería workarounds manuales o soluciones de terceros.

Por qué esto importa más allá del marketing de «AI Private Cloud»

Broadcom está vendiendo esto bajo el paraguas de AI Private Cloud, y hay marketing evidente en la narrativa. Pero la funcionalidad en sí resuelve un problema operativo real que muchos ya estamos viviendo. Desde el punto de vista de gobierno de infraestructura —y aquí entra la perspectiva de gestión de riesgos— tener placement no determinista en entornos mixtos CPU/GPU es un riesgo operativo: fallo silencioso, degradación de rendimiento no trazable, y dificultad para cumplir SLAs de carga de IA.

Para entornos con requisitos de cumplimiento o auditoría (ISO 27001, ENS, controles de segmentación de cargas), poder demostrar que las VMs sensibles solo corren en infraestructura certificada o segregada tiene valor real más allá del rendimiento.

Qué revisar si gestionas VCF

Si estás en VCF 9.x o planeas actualizar, estos son los puntos accionables:

  • Inventario de hardware heterogéneo: antes de definir políticas, necesitas etiquetar y documentar qué hosts tienen qué capacidades. VCF 9.1 facilita esto, pero el trabajo previo es tuyo.
  • Revisar reglas DRS existentes: las políticas de placement pueden interactuar o entrar en conflicto con reglas de afinidad/antiafidad previas. Auditar antes de activar.
  • Definir políticas por tier de workload: no todas las VMs necesitan políticas estrictas. Aplicarlas solo donde hay requisitos reales de hardware evita complejidad innecesaria.
  • Testing en entorno no productivo primero: como siempre con cambios de scheduler en VMware, valida el comportamiento con cargas de prueba antes de producción.

Conclusión

Las Infrastructure Placement Policies de VCF 9.1 son una maduración necesaria del modelo de gestión de VMware para entornos con hardware especializado. El envoltorio de «AI Private Cloud» es marketing, pero la funcionalidad es sólida y cubre un hueco real. Si gestionas VCF y tienes o planeas tener cargas de IA o GPU, vale la pena entenderlas antes de que el scheduler te dé una sorpresa en producción. La documentación oficial de Broadcom para VCF 9.1 es el punto de partida.

Fuentes

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *