La migración de VMware Cloud Foundation (VCF) desde la versión 5.2.x a la 9.1 representa uno de los procesos más complejos y críticos en la gestión de infraestructuras virtualizadas. Lejos de ser una simple actualización de componentes, esta transición implica una reestructuración profunda de las capas de gestión, orquestación y red, donde cada paso debe ejecutarse en un orden estricto para evitar bloqueos o pérdida de servicio. En este runbook detallamos la secuencia exacta, las dependencias obligatorias y los tiempos de inactividad esperados, incorporando recomendaciones prácticas que todo arquitecto de TI debe considerar.
Contexto y retos del upgrade
VCF 5.2.x a 9.1 no es una ruta directa ni trivial. Broadcom, tras la adquisición de VMware, ha redefinido la arquitectura del producto, introduciendo nuevos servicios como VCF Management Services y reubicando el rol de Aria Operations como VCF Operations. La principal dificultad reside en preservar la cadena de dependencias mientras múltiples planos de control (gestión de ciclo de vida, red, cómputo, almacenamiento) cambian bajo el mismo entorno. Un error en el orden puede dejar la infraestructura en un estado inconsistente, sin posibilidad de retroceso sencillo.
Secuencia obligatoria según dependencias
El orden establecido por Broadcom coloca los componentes de operaciones antes que el núcleo de VCF. Esta jerarquía no es un capricho administrativo: VCF Operations se convierte en parte del camino de control necesario para continuar la gestión del ciclo de vida en VCF 9.1. Por tanto, la secuencia es:
1. Verificación de elegibilidad de la versión origen: No todas las versiones 5.2.x tienen una ruta soportada. Broadcom proporciona caminos para 5.2.0 a 5.2.3, pero 5.2.4 está actualmente bloqueado. Antes de descargar cualquier bundle, hay que confirmar con la herramienta VCF Upgrade Planner que la combinación exacta de build y BOM es válida.
2. Operaciones (Aria Operations a VCF Operations): Este es el primer paso productivo. Se debe actualizar el clúster de Aria Operations, asegurando la continuidad de métricas, alertas y dashboards. La salud del clúster después del upgrade es condición necesaria para avanzar.
3. SDDC Manager: Una vez que VCF Operations está operativo, se actualiza SDDC Manager a 9.1. Es el punto de control central del dominio.
4. VCF Management Services: Servicio obligatorio en 9.1 que incluye Fleet Lifecycle, identidad, licencias y depósito de software. Antes de desplegarlo hay que reservar al menos 12 direcciones IP y asegurar registros DNS directos e inversos.
5. NSX Federation (si existe) y NSX Local Managers: La red debe actualizarse antes que vCenter y ESX. Los Global Managers lideran la transición.
6. vCenter Server: Se actualiza a través de Fleet Lifecycle. La indisponibilidad de vCenter afecta a aprovisionamiento, DRS y automatizaciones, pero las máquinas virtuales en ejecución continúan.
7. Migración de clusters a vLCM image: Los clusters gestionados por baselines deben convertirse a imágenes antes de la remediación de hosts.
8. Hosts ESX y vSAN: Actualización secuencial de hosts, respetando las restricciones de evacuación y sincronización vSAN. Los witness hosts en clusters stretch se actualizan antes que los data hosts.
9. NSX Edge Nodes: El plano de datos norte-sur se actualiza al final, con posible pérdida breve de paquetes durante la convergencia de rutas.
10. Servicios post-core: Identity Broker, Logs, Orchestrator y otros productos condicionales completan la transición.
Dependencias críticas y puntos de parada
Cada etapa tiene condiciones de entrada que, si no se cumplen, deben detener el proceso. Por ejemplo, si VCF Operations no recoge datos correctamente después del upgrade, no se debe pasar a SDDC Manager. Si la validación DNS de Management Services falla, hay que resolverla antes de seguir. Broadcom recomienda no forzar un camino no soportado, como intentar actualizar 5.2.4 a 9.1. En la práctica, muchas organizaciones se encuentran con bloqueos por no haber verificado la compatibilidad de hardware, el espacio en bootbank de ESX o la presencia de VIBs personalizados que entran en conflicto con la imagen objetivo.
Estimación de downtime y ventanas de mantenimiento
No existe un número único para el tiempo total. Depende de la cantidad de dominios de carga de trabajo, número de hosts, velocidad de evacuación, resincronización vSAN y pruebas de aplicación. Sin embargo, es posible separar cuatro relojes: tiempo de ejecución, tiempo de estabilización, tiempo de validación y buffer de decisión. Una ventana de mantenimiento que solo cubra la ejecución es incompleta. Por ejemplo, la actualización de VCF Operations puede parecer estancada durante largos periodos mientras se realizan trabajos de base de datos; monitorear los logs activos es más fiable que la barra de progreso. Las máquinas virtuales suelen permanecer disponibles durante la mayor parte del proceso, pero las operaciones de gestión (aprovisionamiento, red, observabilidad) sí se ven afectadas.
Validación y evidencia
Cada etapa debe generar un paquete de evidencia: versiones de origen y destino, logs de tarea, salud del servicio, capturas de pantalla de validación. La validación debe ir desde la salud interna del componente hasta el comportamiento de servicios de negocio representativos. Por ejemplo, después de actualizar vCenter, verificar que las integraciones con herramientas de backup, monitorización y automatización funcionan. Un green en la tarea de ciclo de vida no es suficiente; se necesita la confirmación del propietario de la aplicación.
Estrategia de rollback
No hay un único botón de deshacer para todo el upgrade. A medida que se avanza en la secuencia, la capacidad de revertir disminuye. Antes de la actualización de Operations, un restore soportado del clúster puede ser viable. Una vez que se despliega VCF Management Services, el rollback se vuelve mucho más complejo y requiere asistencia de Broadcom. La regla general es: si falla una etapa, reparar o reintentar antes que intentar una reversión independiente que podría crear un desajuste de versiones.
Recomendaciones desde la experiencia de Q2BSTUDIO
En Q2BSTUDIO, especialistas en desarrollo de software a medida y transformación digital, hemos acompañado a numerosas organizaciones en migraciones complejas de infraestructura. La planificación de un upgrade de VCF no es solo un ejercicio técnico; requiere integrar herramientas de automatización, inteligencia artificial para analizar logs y predecir fallos, y estrategias de ciberseguridad para proteger los planos de gestión durante la ventana de cambio. Además, la integración con plataformas cloud como AWS o Azure permite mantener copias de seguridad externas y facilitar la continuidad del negocio. En nuestros proyectos, aplicamos metodologías de Business Intelligence (Power BI) para monitorizar el progreso en tiempo real y generar dashboards de evidencia. También desplegamos agentes de IA que analizan el estado de los componentes y sugieren puntos de parada antes de que se conviertan en incidentes.
Conclusión
Actualizar VCF 5.2.x a 9.1 es un proyecto que debe abordarse con la misma rigurosidad que una migración de centro de datos. La secuencia es innegociable: Operations, SDDC Manager, Management Services, NSX, vCenter, ESX, Edge. Cada paso necesita condiciones de entrada, validación y evidencia. El downtime no es absoluto, pero sí existen riesgos operativos en gestión, red y almacenamiento. Con una planificación cuidadosa, herramientas adecuadas y el apoyo de expertos como los de Q2BSTUDIO, la transición puede realizarse con éxito, minimizando el impacto en el negocio y sentando las bases para una infraestructura moderna, escalable y segura.
