Hay un tipo de proyecto que pocas veces sale en las keynotes con foco de cañón, pero que es del día a día de cualquiera que trabaje con clientes con muchas ubicaciones: ¿qué hacemos con esa tienda, esa delegación o esa nave industrial que apenas tiene sitio para un servidor, y mucho menos presupuesto para un cluster de alta disponibilidad? Pues bien, VMware Cloud Foundation (VCF) 9.1 tiene una respuesta para esto, y me parece de las soluciones más elegantes que he visto últimamente: un modelo de distribución pensado para funcionar con un **único host físico por ubicación**, con **vSphere Supervisor** habilitado directamente sobre él.
Este modelo de despliegue está pensado específicamente para lo que en el mundo VCF llamamos el "Far Edge", es decir, el extremo más lejano de la infraestructura. A diferencia de los despliegues tradicionales de VCF, que piden varios nodos tanto para el dominio de gestión como para el de carga de trabajo, aquí cada sitio remoto se construye con un único servidor físico. Y lo mejor: ese mismo patrón se puede replicar, tal cual, en decenas o cientos de ubicaciones sin reinventar nada cada vez.
Pero lo que realmente me parece la parte buena de este modelo es que ese único host no se queda en "solo virtualización clásica". Al llevar vSphere Supervisor hasta ahí, las organizaciones consiguen exponer una API declarativa de Kubernetes incluso en el servidor más remoto que tengan, lo que permite desplegar contenedores (vSphere Pods) y máquinas virtuales de forma unificada, sin tener que montar una plataforma de contenedores aparte en cada sitio.
La idea de fondo es sencilla de explicar, aunque no tan sencilla de construir: gestión centralizada, ejecución descentralizada.
- Gestión central: un "vCenter central", normalmente alojado en el centro de datos principal o en un dominio de gestión regional, es quien administra todos los sitios remotos desde un único punto.
- Infraestructura local: el host físico de cada ubicación usa vSphere Distributed Switch (vDS) para la red, y admite tanto almacenamiento local como externo compartido, según lo que tengas disponible en cada sitio.
- Tolerancia de red: y aquí viene el detalle que de verdad lo hace viable en el mundo real: el modelo soporta hasta 100ms de latencia y un ancho de banda mínimo de apenas 10mbps hacia el centro de gestión. Nada de exigir fibra dedicada para cada tienda o nave.
Para que no os quedéis solo con mis palabras, aquí tenéis la estructura lógica tal y como aparece en los diagramas de diseño oficiales de VCF:
¿Y para qué sirve esto en la vida real?
Aquí no hablamos solo de ahorrar unos euros en hardware, que también, sino sobre todo de "agilidad operativa". Al estandarizar el borde bajo el modelo de VCF Fleet, te asegura que las políticas de seguridad y el ciclo de vida son consistentes en toda la flota, tengas diez sitios o quinientos.
Este enfoque le viene especialmente bien a organizaciones con mucha dispersión geográfica, donde cada delegación, sucursal o instalación tiene poco espacio físico y, muchas veces, un único servidor disponible para todo. Así a vuelapluma, estos son algunos casos donde más sentido tiene:
- Retail: tiendas individuales que necesitan correr aplicaciones de inventario o punto de venta con capacidades de contenedores, pero sin sitio para un rack complicado.
- Telecos: despliegues en torres de telefonía móvil, donde el consumo energético y el espacio disponible son siempre lo primero que se mira.
- Empresas con redes de sucursales o delegaciones: compañías con decenas o cientos de ubicaciones remotas (oficinas regionales, plantas de producción, almacenes, pequeñas sedes locales) que necesitan ejecutar aplicaciones de forma local, pero gestionada de manera centralizada, sin tener que replicar infraestructura compleja en cada sitio.

No hay comentarios:
Publicar un comentario
¡Gracias por colaborar en este blog con tus comentarios! :)