TI industrial y VCF 9: cómo hacer un despliegue mínimo
En el mundo de la TI industrial rige una regla de oro: si funciona bien, no lo actualices hasta romperlo. Sin embargo, con la llegada de VMware Cloud Foundation (VCF) 9 y las exigencias de licenciamiento impuestas por Broadcom, muchos equipos de TI se encuentran ante la obligación de asumir un despliegue de stack completo que jamás pidieron, repleto de NSX, vSAN y un plano de gestión concebido para una nube privada que no necesitan.
Esa es la situación a la que se enfrentan hoy muchas empresas industriales de tamaño medio. Son profesionales pragmáticos obsesionados con la disponibilidad ininterrumpida, y la planta de producción prioriza la estabilidad por encima de complejidades innecesarias. Cuando VVF (vSphere Foundation) empieza a parecer un callejón sin salida y la única alternativa sobre la mesa es VCF, la gran cuestión es saber cuán "mínimo" se puede configurar VCF 9 para seguir operando sin sobresaltos.
El dilema de VCF: ¿todo o nada?
VCF es una solución potente, pensada para organizaciones que buscan una experiencia integral de nube privada. Pero para los equipos de planta que solo intentan mantener sus aplicaciones heredadas y sus sistemas SCADA funcionando las 24 horas del día durante los 7 días de la semana, desplegar VCF puede parecer como utilizar una nave espacial para reparar una bicicleta.
Un usuario lo resumió con acierto: «No necesitamos una "nube privada", necesitamos una plataforma de virtualización estable.»
Ese sentimiento es compartido por todo el sector. Estos equipos no quieren rediseñar su red en torno a NSX ni migrar su almacenamiento a vSAN, porque sus configuraciones con VLAN e iSCSI funcionan a la perfección. Su único objetivo es renovar licencias sin tener que rehacer por completo toda su infraestructura.
Entonces, ¿es posible ejecutar una versión ligera de VCF 9?
La respuesta rápida es sí, aunque, como ocurre en cualquier ámbito de la TI corporativa, tiene sus matices.
Es perfectamente viable desplegar VCF prescindiendo de NSX o vSAN y limitarse a utilizar vSphere y vCenter; de hecho, muchas plantas ya están adoptando este enfoque. Como explicaba un administrador: «Al adquirir VCF recibes licencias para cada producto… De modo que si quieres limitar tu despliegue solo a esto, puedes hacerlo.»
Continuarás necesitando ejecutar el appliance de VCF Operations (VCfOps) para validar el licenciamiento, pero no tienes por qué activar todas las funciones accesorias. Es como comprar una navaja suiza y utilizar únicamente la hoja y el destornillador.
En la práctica, vSphere y vCenter son obviamente indispensables. El appliance de VCF Operations es necesario para la gestión de licencias de los hosts y de vCenter. NSX y vSAN resultan opcionales en el día a día, aunque figuren como la opción "preferida" por Broadcom.
NSX: ¿el mal necesario?
Los debates más encendidos siempre giran en torno a NSX. Hay recelo, dudas y, sinceramente, bastante frustración. Muchos equipos técnicos se preguntan si están obligados a modificar los parámetros de MTU y si necesitan configurar VTEP, VXLAN, túneles Geneve o tramas jumbo en cada switch físico. La realidad es que no hace falta.
Puedes ejecutar port groups tradicionales respaldados por VLAN con NSX sin necesidad de rediseñar toda la red de tu centro de datos, lo que permite cumplir técnicamente con las expectativas de VCF sin poner patas arriba las comunicaciones. Como señalaba un usuario: «Te das cuenta de que puedes ejecutar simplemente port groups tradicionales sobre VLAN con NSX, a menos que se me escape algo.»
Las tramas jumbo siguen siendo aconsejables, por supuesto, y si utilizas NSX Edges probablemente debas ajustar la MTU. Pero si prescindes de la microsegmentación y de las redes superpuestas (overlay), el entorno resulta mucho más manejable.
Esto plantea la duda de por qué desplegar NSX si no vas a aprovechar sus funciones principales. La respuesta reside en el modelo de licenciamiento. Ciertos administradores optan por dejar NSX y vSAN como software en desuso (shelfware), manteniéndolos instalados pero inactivos para continuar con su operativa habitual. No es la solución más elegante, pero resulta plenamente válida.
El caso de uso de Edge: tu arma secreta
Si gestionas plantas pequeñas o sedes distribuidas (fábricas en lugar de grandes centros de datos), VCF Edge puede ser tu vía de escape.
VCF Edge es un SKU más ligero pensado específicamente para estos escenarios. Presenta un coste inferior al paquete completo de centro de datos y asume que no vas a desplegar todo el catálogo de productos. Como comentaba un usuario: «Los cores de VCF Edge son esencialmente lo mismo salvo por diferencias en el EULA.»
Una estrategia sólida de despliegue consiste en centralizar el stack principal de VCF en la sede central, instalar clústeres mínimos o nodos individuales en las plantas remotas y apoyarse en el clúster centralizado de operaciones para la gestión del ciclo de vida y las licencias. Esto permite cumplir formalmente con las exigencias del fabricante sin forzar un despliegue masivo e invasivo de VCF en cada centro remoto.
Entonces, ¿dónde está la trampa?
Incluso un despliegue "mínimo" de VCF acarrea costes. Necesitarás recursos de hardware para los appliances de gestión y tiempo para instalar, configurar y mantener VCF Ops. Y, desde luego, pagarás bastante más que con un entorno tradicional de vSphere y vCenter independientes.
Un profesional dio en el clavo sobre este problema: «Dejar como software en desuso todo salvo ESX, vCenter y el servidor de licencias… pero con facturas mucho más altas.»
Ese es el sobrecoste real de VCF: destinar presupuesto a software que no vas a utilizar únicamente para mantener el soporte y seguir en juego.
Qué está haciendo la comunidad en este momento
En las empresas industriales se están consolidando varios caminos prácticos. Algunos optan por el despliegue mínimo: licencian VCF por cumplimiento normativo, implementan solo vSphere y vCenter y prescinden de NSX y vSAN. Otros aplican la estrategia del software en desuso, instalando NSX y vSAN pero dejándolos inactivos, existiendo únicamente para superar las auditorías de licencias y soporte. Otros recurren al modelo de "VCF Edge centralizado", manteniendo la sobrecarga de gestión en un único punto para que las fábricas sigan operando ligeras. Y otros están planificando escenarios híbridos, preservando su infraestructura actual mientras evalúan alternativas como Hyper-V, Proxmox VE o Nutanix para futuras migraciones.
Conclusiones: resiste al stack y mantén la cordura
En la TI industrial ya tienes bastantes preocupaciones en el día a día: normativas, continuidad de servicio, autómatas programables (PLC) obsoletos y esa máquina virtual con Windows XP que todavía controla la cinta transportadora. Lo último que necesitas es una imposición forzada de conceptos cloud nativos en tu entorno.
VCF 9 puede haberse convertido en la nueva realidad comercial, pero no estás obligado a implementar todo el stack para seguir cumpliendo las reglas. Ejecuta lo que realmente necesitas, ignora lo prescindible y concéntrate en soluciones prácticas y viables que encajen en tu propia planta y no en la hoja de ruta de un proveedor.
Al final, la infraestructura sofisticada importa mucho menos que asegurar que la fábrica siga produciendo y la maquinaria no se detenga. Si para lograrlo hace falta hacer más con menos, adelante con ello.