Cuando alguien dice que quiere actualizar a VMware Cloud Foundation 9.1, la primera imagen que suele venir a la mente es una línea recta: el entorno actual arriba, VCF 9.1 abajo, una flecha intermedia. La realidad casi nunca funciona así. Y la diferencia entre saberlo de antemano y descubrirlo a mitad de un proyecto es, en muchos casos, la diferencia entre un plan que funciona y uno que se estanca.
Como Broadcom Knight, paso mucho tiempo con clientes, hablando sobre proyectos como actualizar a VCF 9.1, y mi formación y trabajo práctico que hago como Knight me dan la ventaja de saber la diferencia de antemano. El programa Broadcom Knights es solo por invitación. No hay examen, ni curso. Los ingenieros que ostentan este reconocimiento lo llevan porque alguien en Broadcom ha visto su trabajo en el campo y ha decidido que opera a otro nivel. Eso tiene consecuencias prácticas muy concretas para los proyectos en los que participan.
 |
| Foto de amy.johnson@broadcom.com |
No hace mucho me senté con un cliente del sector asegurador que quería hacer exactamente eso: alcanzar el VCF 9.1. El entorno sobre el papel no parecía especialmente complejo: 27 hosts, 3 vCenters, 435 máquinas virtuales. Lo que apareció cuando empezamos a buscar fue otra historia. Cinco generaciones distintas de procesadores coexistiendo en el mismo entorno, desde Haswell desde 2015 hasta Sapphire Rapids desde 2023. Ocho hosts con arquitecturas de CPU que VCF 9.1 simplemente no soporta. Treinta y cuatro dispositivos de terceros en telefonía IP de Cisco, videoconferencias y gestión de red, cuyas versiones instaladas no eran compatibles con ESXi 8 y bloqueaban la actualización de los hosts que los ejecutaban. El entorno también contaba con un host SAP que funcionaba completamente de forma independiente, sin HA, sin DRS, con dos máquinas virtuales críticas para el negocio y sin ninguna resiliencia.
Eso no es un problema tecnológico. Es un problema de visibilidad. Y sin ese nivel de detalle, cualquier plan de mejora es una promesa construida en el aire.
Lo que permite que un proyecto así tenga éxito no es solo conocer la plataforma objetivo. Es saber diseñar una ruta que no ponga al cliente en una posición imposible porque todo no puede avanzar al mismo tiempo. En este caso, la solución fue diseñar una arquitectura de dos velocidades: el 70% del entorno entra en VCF 9.1 desde el primer día, distribuido entre un Dominio de Gestión y dos Dominios de Carga de Trabajo. El 30% restante permanece en un vCenter heredado, completamente funcional, mientras que las dependencias de software que lo bloquean hoy en día se resuelven progresivamente. Nada se tira, nada se rompe, y el cliente avanza con lo que puede moverse ahora en lugar de esperar a que todo esté listo de golpe.
Hay detalles que solo salen a la luz cuando conoces la plataforma desde dentro. Por ejemplo: para el Dominio de Gestión, aprovechamos la convergencia del clúster vSAN existente (tres nodos Dell R660 con procesadores Sapphire Rapids, ya certificados) en lugar de desplegar uno nuevo desde cero, lo que habría requerido un cuarto host que no estuviera dentro del presupuesto. O que tres clústeres, uno de ellos con un host SAP completamente independiente, operando sin alta disponibilidad, ganen HA por primera vez a través del rediseño, sin coste adicional de hardware. Ese tipo de decisiones no vienen de leer documentación. Provienen de haber estado en lugares similares antes, de tener acceso anticipado a cómo funciona la plataforma objetivo y de haber validado las arquitecturas en el laboratorio antes de proponérselas al cliente.
Y luego está el trabajo de secuenciación, que no tiene nada glamuroso pero es donde se ganan o pierden proyectos. Trece fases a lo largo de dieciocho semanas, host por host, teniendo en cuenta qué appliance reside en cada host, qué hosts no tienen HA y requieren que las máquinas virtuales se apaguen antes de poder tocarse, qué clústeres tienen dependencias de vSAN que requieren un orden específico, qué versiones de VMware Tools son lo suficientemente antiguas como para causar problemas durante la actualización. Todo está documentado, validado y entregado al equipo del cliente para que lo ejecuten con confianza, incluso en los pasos en los que no estamos presentes.
Eso es lo que significa trabajar con un equipo que incluye a un Broadcom Knight. No es que la tecnología funcione de forma diferente. Es que alguien ha revisado todo esto antes de que comience el proyecto, haya diseñado la ruta teniendo en cuenta lo que realmente hay y ha dejado un plan que el cliente entiende y puede ejecutar. La infraestructura no miente. Lo que casi siempre falla es el tiempo que se tarda en entenderlo bien. Infórmate más sobre el programa Broadcom Knights.
