La migració de VMware Cloud Foundation (VCF) des de la versió 5.2.x a la 9.1 és un dels processos més complexos i crítics en la gestió d’infraestructures virtualitzades. Lluny de ser una simple actualització de components, aquesta transició implica una reestructuració profunda de les capes de gestió, orquestració i xarxa, on cada pas s’ha d’executar en un ordre estricte per evitar bloquejos o pèrdua de servei. En aquest runbook detallem la seqüència exacta, les dependències obligatòries i els temps d’inactivitat esperats, incorporant recomanacions pràctiques que tot arquitecte de TI hauria de considerar.
Context i reptes de l’actualització
VCF 5.2.x a 9.1 no és una ruta directa ni trivial. Broadcom, després de l’adquisició de VMware, ha redefinit l’arquitectura del producte, introduint nous serveis com VCF Management Services i reubicant el rol d’Aria Operations com a VCF Operations. La principal dificultat rau a preservar la cadena de dependències mentre múltiples plans de control (gestió del cicle de vida, xarxa, còmput, emmagatzematge) canvien sota el mateix entorn. Un error en l’ordre pot deixar la infraestructura en un estat inconsistent, sense possibilitat de retrocés senzill.
Seqüència obligatòria segons dependències
L’ordre establert per Broadcom col·loca els components d’operacions abans que el nucli de VCF. Aquesta jerarquia no és un caprici administratiu: VCF Operations es converteix en part del camí de control necessari per continuar la gestió del cicle de vida a VCF 9.1. Per tant, la seqüència és:
1. Verificació d’elegibilitat de la versió origen: No totes les versions 5.2.x tenen una ruta suportada. Broadcom proporciona camins per a 5.2.0 a 5.2.3, però 5.2.4 està actualment bloquejat. Abans de descarregar qualsevol bundle, cal confirmar amb l’eina VCF Upgrade Planner que la combinació exacta de build i BOM és vàlida.
2. Operacions (Aria Operations a VCF Operations): Aquest és el primer pas productiu. Cal actualitzar el clúster d’Aria Operations, assegurant la continuïtat de mètriques, alertes i dashboards. La salut del clúster després de l’actualització és condició necessària per avançar.
3. SDDC Manager: Un cop VCF Operations està operatiu, s’actualitza SDDC Manager a 9.1. És el punt de control central del domini.
4. VCF Management Services: Servei obligatori a 9.1 que inclou Fleet Lifecycle, identitat, llicències i dipòsit de programari. Abans de desplegar-lo cal reservar almenys 12 adreces IP i assegurar registres DNS directes i inversos.
5. NSX Federation (si existeix) i NSX Local Managers: La xarxa s’ha d’actualitzar abans que vCenter i ESX. Els Global Managers lideren la transició.
6. vCenter Server: S’actualitza a través de Fleet Lifecycle. La indisponibilitat de vCenter afecta el provisionament, DRS i automatitzacions, però les màquines virtuals en execució continuen.
7. Migració de clústers a vLCM image: Els clústers gestionats per baselines s’han de convertir a imatges abans de la remediació de hosts.
8. Hosts ESX i vSAN: Actualització seqüencial de hosts, respectant les restriccions d’evacuació i sincronització vSAN. Els witness hosts en clústers stretch s’actualitzen abans que els data hosts.
9. NSX Edge Nodes: El pla de dades nord-sud s’actualitza al final, amb possible pèrdua breu de paquets durant la convergència de rutes.
10. Serveis post-core: Identity Broker, Logs, Orchestrator i altres productes condicionals completen la transició.
Dependències crítiques i punts de parada
Cada etapa té condicions d’entrada que, si no es compleixen, han d’aturar el procés. Per exemple, si VCF Operations no recull dades correctament després de l’actualització, no s’ha de passar a SDDC Manager. Si la validació DNS de Management Services falla, cal resoldre-la abans de continuar. Broadcom recomana no forçar un camí no suportat, com intentar actualitzar 5.2.4 a 9.1. A la pràctica, moltes organitzacions es troben amb bloquejos per no haver verificat la compatibilitat de hardware, l’espai a bootbank d’ESX o la presència de VIBs personalitzats que entren en conflicte amb la imatge objectiu.
Estimació de downtime i finestres de manteniment
No existeix un nombre únic per al temps total. Depèn de la quantitat de dominis de càrrega de treball, nombre de hosts, velocitat d’evacuació, resincronització vSAN i proves d’aplicació. No obstant, és possible separar quatre rellotges: temps d’execució, temps d’estabilització, temps de validació i buffer de decisió. Una finestra de manteniment que només cobreixi l’execució és incompleta. Per exemple, l’actualització de VCF Operations pot semblar estancada durant llargs períodes mentre es fan treballs de base de dades; monitoritzar els logs actius és més fiable que la barra de progrés. Les màquines virtuals solen romandre disponibles durant la major part del procés, però les operacions de gestió (provisionament, xarxa, observabilitat) sí es veuen afectades.
Validació i evidència
Cada etapa ha de generar un paquet d’evidència: versions d’origen i destinació, logs de tasca, salut del servei, captures de pantalla de validació. La validació ha d’anar des de la salut interna del component fins al comportament de serveis de negoci representatius. Per exemple, després d’actualitzar vCenter, verificar que les integracions amb eines de backup, monitorització i automatització funcionen. Un green a la tasca de cicle de vida no és suficient; es necessita la confirmació del propietari de l’aplicació.
Estratègia de rollback
No hi ha un únic botó de desfer per a tota l’actualització. A mesura que s’avança en la seqüència, la capacitat de revertir disminueix. Abans de l’actualització d’Operations, un restore suportat del clúster pot ser viable. Un cop es desplega VCF Management Services, el rollback es torna molt més complex i requereix assistència de Broadcom. La regla general és: si falla una etapa, reparar o reintentar abans que intentar una reversió independent que podria crear un desajust de versions.
Recomanacions des de l’experiència de Q2BSTUDIO
A Q2BSTUDIO, especialistes en desenvolupament de programari a mida i transformació digital, hem acompanyat nombroses organitzacions en migracions complexes d’infraestructura. La planificació d’una actualització de VCF no és només un exercici tècnic; requereix integrar eines d’automatització, intel·ligència artificial per analitzar logs i predir fallades, i estratègies de ciberseguretat per protegir els plans de gestió durant la finestra de canvi. A més, la integració amb plataformes cloud com AWS o Azure permet mantenir còpies de seguretat externes i facilitar la continuïtat del negoci. En els nostres projectes, apliquem metodologies de Business Intelligence (Power BI) per monitoritzar el progrés en temps real i generar dashboards d’evidència. També despleguem agents d’IA que analitzen l’estat dels components i suggereixen punts de parada abans que es converteixin en incidents.
Conclusió
Actualitzar VCF 5.2.x a 9.1 és un projecte que s’ha d’abordar amb la mateixa rigurositat que una migració de centre de dades. La seqüència és innegociable: Operations, SDDC Manager, Management Services, NSX, vCenter, ESX, Edge. Cada pas necessita condicions d’entrada, validació i evidència. El downtime no és absolut, però sí hi ha riscos operatius en gestió, xarxa i emmagatzematge. Amb una planificació acurada, eines adequades i el suport d’experts com els de Q2BSTUDIO, la transició pot realitzar-se amb èxit, minimitzant l’impacte en el negoci i establint les bases per a una infraestructura moderna, escalable i segura.
