VCF 9.0 GA Modelo Mental Parte 5: Patrones de Topología para Sitio Único, Dos Sitios y Multirregión

TL;DR Si quieres que arquitectos, operadores y directivos estén alineados, necesitas un modelo mental de topología que comience con los objetos de VCF y solo luego los asigne a tus sitios físicos. La jerarquía en la que deberías estandarizarte es Fleet -> Instance -> Domain -> Cluster. Tu decisión de topología se reduce principalmente a: cuántas instancias despliegas y cómo se asignan a sitios y regiones; cuántas flotas operas como límites de gobierno, identidad y operaciones. Tres posturas de despliegue práctico: sitio único (ruta más rápida, menor radio de explosión, red más simple); dos sitios en una región (clusters extendidos, mayor resiliencia del sitio, restricciones de latencia más estrictas); multirregión (múltiples instancias, modelo operativo orientado a DR, más dependencias y más control de cambios). Códigos de nivel VCF 9.0 GA referenciados en esta publicación (conjunto de componentes y números de compilación): SDDC Manager 9.0.0.0 build 24703748, vCenter 9.0.0.0 build 24755230, ESX 9.0.0.0 build 24755229, NSX 9.0.0.0 build 24733065, VCF Operations 9.0.0.0 build 24695812, VCF Automation 9.0.0.0 build 24701403, VCF Identity Broker 9.0.0.0 build 24695128. Nota: el BOM de esta versión también indica que se requiere VCF Installer 9.0.1.0 build 24962180 para desplegar todos los componentes de VCF 9.0.0.0. La tabla de contenido incluye: alcance del escenario y alineación de versiones, conceptos clave (mapeo de topología física a flotas e instancias), criterios de decisión que acordar de antemano, desafío de elegir tu postura de despliegue, matriz de compensaciones de arquitectura, una nube privada frente a múltiples flotas, patrones de límites de identidad y SSO, análisis de dominios de fallo, mapa Día 0, Día 1 y Día 2 por topología, quién es responsable de qué, instantánea del runbook operativo, flujo de trabajo de resolución de problemas, antipatrones, mejores prácticas, resumen y conclusiones. Escenario: estás a punto de desplegar VCF 9.0 GA en campo verde y necesitas un lenguaje compartido sobre qué gestiona realmente VCF, dónde dibujas límites de gobierno frente a límites de infraestructura, qué cambia al pasar de un solo sitio a sitios extendidos a múltiples regiones, y cómo el alcance de la identidad y el número de flotas se convierten en decisiones del Día 0 con consecuencias operativas a largo plazo. Alcance y alineación de versiones: esta publicación asume terminología y flujos de trabajo de VCF 9.0.0.0 GA, despliegue en campo verde utilizando VCF Installer, y que despliegas tanto VCF Operations como VCF Automation desde el Día 1, incluso si escalonas el consumo más tarde. La matriz de compatibilidad de versiones sirve como ancla de lo que estamos discutiendo en revisiones de arquitectura y reuniones de CAB. Conceptos clave: mapeo de topología física a flotas e instancias. Las palabras físicas que importan: sitio (tu límite de dominio de falla contenido; energía, refrigeración, conmutadores ToR, enrutamiento ascendente y seguridad física suelen correlacionarse), región (uno o más sitios dentro de latencias de replicación síncrona; cruzar regiones suele ser un proceso de recuperación ante desastres, no un evento de HA). Los objetos VCF que deberías usar en cada discusión de diseño: Fleet (tu gobierno compartido y límite de servicios de plataforma compartidos; aquí centralizas servicios de flota como operaciones y automatización), Instance (un footprint de despliegue VCF discreto; cada instancia contiene su propio dominio de gestión y dominios de carga de trabajo), Domain (el límite de ciclo de vida y aislamiento; parcheas y evolucionas dominios de forma independiente), Management domain (aloja componentes de gestión de instancia), VI workload domain(s) (ejecutan cargas de trabajo de consumidores). Regla práctica: si alguien dice necesitamos otro vCenter, fuerzas la conversación de vuelta a dominio e instancia. Si alguien dice necesitamos separación, preguntas si se refieren a separación de gobierno (fleet) o aislamiento de carga de trabajo (domain). Criterios de decisión que acordar de antemano: son decisiones en tiempo de diseño que son caras de revertir después. Incluyen objetivo de disponibilidad (fallo de host, rack, sitio o zona de disponibilidad, región), capacidad de latencia y tejido de red (latencia entre hosts ESX dentro de clústeres, requisitos de VLAN extendida y adyacencia L2, restricciones de conectividad entre instancias a nivel de flota), objetivo de aislamiento (aislamiento lógico, físico por clúster o dominio, aislamiento de inquilino regulado que requiere identidad y control de cambios separados), madurez del modelo operativo (¿tienes un equipo de plataforma que pueda poseer servicios de flota y ciclo de vida de identidad? ¿Tienes ventanas de cambio estandarizadas y disciplina de parcheo?) y preguntas de realidad del Día 2 (¿puedes apoyar servicios de flota como dependencias compartidas? ¿Puedes operativizar horarios de respaldo, ciclo de vida de certificados y rotación de contraseñas de manera consistente? ¿Puedes solucionar fallos entre sitios sin escalar todo a proveedores?). Desafío: elige tu postura de despliegue. Necesitas una postura que coincida con tu topología física sin crear un modelo de gobierno que no puedas operar. Solución A: Sitio único. Es tu postura inicial por defecto a menos que tengas un impulsor de disponibilidad claro. Se ve así: una flota, una instancia, un dominio de gestión, uno o más dominios de carga de trabajo. El diseño optimiza para tiempo de obtención de valor y simplicidad operativa, manteniendo los requisitos de latencia y red sencillos. Implicaciones operativas: puedes escalar dentro del sitio añadiendo más clústeres a dominios, más dominios de carga de trabajo, potencialmente más instancias si necesitas aislamiento en el límite de instancia; tu postura de DR se convierte en una conversación separada, generalmente respaldo/restauración primero, luego replicación y orquestación. Solución B: Dos sitios en una región. Es la postura de resiliencia del sitio. Generalmente asume construcciones extendidas y restricciones de red más estrictas. Se ve así: una flota, una instancia extendida entre dos sitios en la misma región, un dominio de gestión diseñado para alta disponibilidad entre los dos sitios, dominios de carga de trabajo separados de la gestión. El diseño tolera un fallo completo de sitio o zona de disponibilidad para la gestión y potencialmente las cargas de trabajo, reduce el tiempo de inactividad para incidentes locales. Restricciones duras que debes respetar: los diseños extendidos requieren ingeniería de red disciplinada. VCF indica umbrales máximos de latencia para hosts ESX dentro de un clúster vSphere, hosts que ejecutan nodos NSX Edge dentro del mismo clúster NSX Edge, conectividad de testigo vSAN en diseños extendidos. También heredas problemas de gateway extendido y HA de gateway de primer salto que no son opcionales en cortes reales. Implicaciones operativas: tu flujo de trabajo de parcheo debe comprender la afinidad del sitio y la capacidad de conmutación por error; la resolución de problemas de red se vuelve tan importante como la resolución de problemas de vSphere. Solución C: Multirregión. Es la postura del modelo operativo orientado a DR. Generalmente despliegas múltiples instancias, cada una alineada con una región. Se ve así: una flota, múltiples instancias, cada instancia tiene su propio dominio de gestión y dominios de carga de trabajo, las regiones están conectadas con una red entre regiones para gestión y visibilidad centralizadas. El diseño separa dominios de falla por región, habilita flujos de trabajo de recuperación que sobreviven eventos a nivel de región, dada la capacidad y estrategia de replicación adecuadas. Implicaciones operativas: introduces una cadena de dependencia explícita: los servicios de flota viven en algún lugar (comúnmente la primera instancia) y otras instancias dependen de la conectividad entre regiones para alcanzarlos; el control de cambios se vuelve multirregión por defecto: certificados, identidad y parcheo deben coordinarse entre ubicaciones. Matriz de compensaciones de arquitectura: úsala en juntas de diseño para detener debates circulares. El atributo sitio único tiene como objetivo principal la simplicidad, con recuento típico de instancias 1, complejidad de red baja, sensibilidad a latencia moderada, dependencia de servicios de flota local, sobrecarga operativa baja, impulsores de coste: recuento de hosts, almacenamiento. Dos sitios en una región: objetivo principal resiliencia del sitio, recuento típico 1, complejidad de red alta, sensibilidad a latencia alta, dependencia de servicios de flota local pero extendida, sobrecarga operativa alta, impulsores de coste: tejido extendido, testigo, capacidad de conmutación por error. Multirregión: objetivo principal separación de región y DR, recuento típico 2+, complejidad de red media a alta, sensibilidad a latencia alta, dependencia de servicios de flota entre regiones, sobrecarga operativa alta, impulsores de coste: capacidad duplicada, replicación, ancho de banda. Instantánea del modelo de coste: no es pricing, es lo que realmente mueve tu lista de materiales. Sitio único: footprint de alojamiento de servicios de flota más barato, menor coste de ingeniería de red. Dos sitios en una región: pagas por enlaces entre sitios de mayor calidad, soporte de VLAN extendida, capacidad de conmutación por error adicional. Multirregión: pagas por huellas de gestión duplicadas por región, herramientas de replicación y orquestación de datos, mayor desgaste operativo a menos que automatices fuertemente el Día 2. Una nube privada frente a múltiples flotas: trata nube privada como tu envoltorio organizacional. Los objetos VCF comienzan en fleet. Cuándo una flota es suficiente: cuando quieres observabilidad y automatización centralizadas, puedes aceptar servicios de gobierno compartidos entre múltiples instancias, quieres un modelo operativo estándar entre ubicaciones. Cuándo debes operar múltiples flotas: cuando necesitas proveedores de identidad separados o límites de SSO separados para aislamiento regulado, ventanas de cambio y horarios de parcheo independientes, separación dura del radio de explosión para servicios de flota. Marco práctico: la separación de flotas se trata de gobierno, alcance de identidad y radio de explosión de servicios compartidos; la separación de dominios se trata de aislamiento de carga de trabajo e independencia del ciclo de vida. Patrones de límites de identidad y SSO: la identidad no es una decisión posterior, es una decisión límite. Desafío: unificar acceso o aislar inquilinos. Solución A: SSO en toda la flota. Úsalo cuando quieras un conjunto de credenciales y SSO en todos los componentes de la flota, y puedas tolerar que un impacto del broker de identidad afecte a la flota. Realidad operativa: poderoso para la experiencia del operador, pero aumenta el radio de explosión de los cortes de identidad. Solución B: SSO entre instancias. Úsalo cuando quieras identidad compartida en un subconjunto de instancias, no necesariamente todas, y quieras más control sobre el radio de explosión que una configuración de flota única. Solución C: Límites de SSO por instancia. Úsalo cuando necesites aislamiento regulado o de inquilino, diferentes proveedores de identidad o políticas de autenticación por instancia, y quieras localizar cortes de identidad. Broker de identidad integrado frente a appliance: trata esto como una decisión de escalado y disponibilidad. El broker integrado es más simple pero hereda dependencia de componentes de instancia; el broker appliance añade sobrecarga pero mejora la disponibilidad y el escalado. Restricción de diseño que vale la pena mencionar: hay un número máximo de instancias que pueden conectarse a un solo despliegue de broker de identidad. Análisis de dominio de fallo: aquí es donde la topología se convierte en resultados operativos reales. Los dominios de fallo que deberías modelar incluyen: servicios de flota no disponibles (se pierden observabilidad centralizada, automatización centralizada, flujos de trabajo de gestión de flota y opcionalmente experiencia SSO; las cargas de trabajo existentes y los planos de gestión de instancia continúan funcionando; el equipo de plataforma restaura servicios de flota y valida integraciones), dominio de gestión de instancia deteriorado (se pierden acciones de ciclo de vida de dominio y algunas operaciones de instancia; las cargas de trabajo pueden seguir funcionando pero pierdes control de ciclo de vida seguro y posiblemente algunas funciones de vCenter o NSX; el administrador de VI y el equipo de plataforma coordinan la recuperación), dominio de carga de trabajo deteriorado (las cargas de trabajo en ese dominio se ven afectadas; otros dominios e instancias continúan; el administrador de VI y los equipos de aplicación ejecutan runbooks de recuperación de carga de trabajo). Ejemplos prácticos de RTO y RPO que puedes usar como objetivos iniciales: servicios de flota (VCF Operations, VCF Automation, broker de identidad) RTO 2 a 8 horas, RPO 24 horas; componentes del dominio de gestión de instancia RTO 1 a 4 horas, RPO 24 horas; dominios de carga de trabajo y aplicaciones RTO y RPO específicos de la aplicación. Si no puedes establecer estos objetivos, al menos acuerda el orden de prioridad: identidad y autenticación, SDDC Manager y ciclo de vida, vCenter y NSX, recuperación de cargas de trabajo. Mapa Día 0, Día 1, Día 2 por topología. Día 0: decisiones que debes fijar. Aplican a todas las topologías: recuento de flotas y estándar de nomenclatura, asignación de instancia a sitio o región, estrategia de dominio (el dominio de gestión no es donde ejecutas cargas de trabajo de negocio; los dominios de carga de trabajo se alinean con necesidades de ciclo de vida y aislamiento), plan de red e IP (trata el dimensionamiento de subredes como planificación irreversible), modelo de identidad (límites de flota frente a instancia, integración de IdP corporativo y política de MFA), autoridad de certificados y plan de ciclo de vida de certificados, objetivos de respaldo y propietarios de horarios de respaldo. Día 1: secuencia de puesta en marcha que se ajusta al modelo de objetos. Un flujo típico de campo verde: desplegar appliance VCF Installer, iniciar nuevo despliegue de flota y crear la primera instancia, licenciar y poner en marcha servicios de flota (VCF Operations, VCF Automation), desplegar broker de identidad y configurar VCF SSO con tu directorio, crear dominios de carga de trabajo y establecer patrones de conectividad de red, poner en marcha construcciones de VCF Automation para consumo. Día 2: operaciones que deberías operativizar temprano. Parcheo y ciclo de vida: actualizaciones basadas en dominio y ventanas de mantenimiento, planes de reversión explícitos al actualizar servicios de flota compartidos. Respaldo y restauración: objetivos de respaldo SFTP para componentes de gestión, horarios de respaldo para servicios de flota y componentes de instancia. Ciclo de vida de seguridad: rotación de contraseñas y gestión de cuentas, reemplazo y renovación de certificados. Expansión: añadir dominios de carga de trabajo, clústeres y potencialmente instancias adicionales. Quién es responsable de qué: usa esto para evitar que todos sean dueños y nadie lo sea. La capacidad de ciclo de vida de servicios de flota es propiedad del equipo de plataforma, consulta al administrador de VI, informa a equipos de aplicación y plataforma. Configuración y alertas de VCF Operations: propiedad del equipo de plataforma, consulta al administrador de VI, informa. Configuración del proveedor de VCF Automation: propiedad del equipo de plataforma, consulta al administrador de VI, informa. Broker de identidad y modelo SSO: propiedad del equipo de plataforma, consulta al administrador de VI, informa. Puesta en marcha y salud de instancia: propiedad del administrador de VI, consulta al equipo de plataforma, informa. Operaciones de SDDC Manager: consulta al equipo de plataforma, propiedad del administrador de VI, informa. vCenter y NSX en dominio de gestión: consulta al equipo de plataforma, propiedad del administrador de VI, informa. Creación y ciclo de vida de dominios de carga de trabajo: consulta al equipo de plataforma, propiedad del administrador de VI, informa. Aprovisionamiento de cargas de trabajo mediante automatización: propiedad del equipo de plataforma, consulta al administrador de VI, informa al consumo. Despliegue de aplicaciones y runtime: informa al equipo de plataforma, consulta al administrador de VI, propiedad de equipos de aplicación. Instantánea del runbook operativo: mantenla como página viva en tu wiki de operaciones. Semanal: revisar salud de servicios de flota e integraciones, validar que todas las instancias reporten métricas y logs, confirmar ventanas de expiración de certificados y cola de rotación. Mensual: ejecutar pruebas de restauración de respaldo para servicios de flota y componentes de gestión de instancia, revisar capacidad y supuestos de capacidad de conmutación por error para tu topología. Trimestral: parchear en límites de dominio, no por actualizaciones de componentes ad hoc, revalidar latencia de red entre sitios y pérdida de paquetes, realizar un ejercicio de mesa: corte de servicios de flota, corte de instancia, corte de sitio. Lista de verificación de validación: usar UI y validación de flujo de trabajo antes de declarar éxito. En VCF Operations, confirmar que cada instancia VCF sea visible y esté saludable. Confirmar que tu proveedor de automatización y rutas de acceso de inquilino funcionen con el modelo de identidad elegido. Confirmar que los respaldos se estén ejecutando y almacenados fuera de la plataforma. Flujo de trabajo de resolución de problemas: cuando algo se rompe, solucionar por límite. Fallos de aprovisionamiento: verificar salud de VCF Automation y su integración con VCF Operations, validar conectividad del proveedor de identidad y emisión de tokens, validar conectividad de red entre servicios de flota e instancia objetivo. Fallos de ciclo de vida de instancia: inspeccionar alarmas de SDDC Manager e historial de cambios recientes, validar salud de dominio y disponibilidad de vCenter, verificar desviación de cambios fuera de banda. Rarezas entre sitios: comenzar con validación de latencia y MTU, validar comportamiento de HA de gateway para segmentos extendidos, confirmar reglas de afinidad de sitio para componentes críticos. Antipatrones: evita estos temprano y eliminas mucho desgaste futuro. Tratar un diseño extendido de dos sitios como solo dos centros de datos. Usar una sola flota para inquilinos regulados cuando realmente necesitas límites de identidad y cambio separados. Ejecutar cargas de trabajo significativas en el dominio de gestión porque estaba disponible. Diseñar el espacio IP demasiado ajustado y asumir que puedes redimensionar después. Asumir que multirregión significa activo-activo sin definir replicación, orquestación y capacidad para conmutación por error. Mejores prácticas: estandarizar el vocabulario por escrito: Fleet -> Instance -> Domain -> Cluster. Mantener los servicios de flota altamente disponibles y respaldados como cualquier plataforma Tier 0. Hacer de la identidad un elemento de la junta de diseño, no una casilla de implementación. Usar dominios como tu límite de ciclo de vida: parchear dominios, validar dominios, revertir en límites de dominio. Escribir runbooks de modo de fallo para: servicios de flota caídos, instancia caída, sitio caído, región caída. Resumen y conclusiones: tu postura de topología es una decisión de modelo operativo, no solo un diagrama de arquitectura. Dos sitios en una región generalmente aumenta la disponibilidad pero también aumenta la complejidad de red y del Día 2. Multirregión generalmente mejora la separación de dominios de fallo, pero introduce dependencias entre regiones para servicios de flota a menos que aísles deliberadamente con múltiples flotas. Decide el alcance de la identidad y el recuento de flotas en el Día 0. El costo de cambiar después siempre es mayor que el costo de decidir cuidadosamente ahora. Conclusión: VCF 9.0 GA se vuelve más fácil de diseñar y operar cuando tratas fleet, instance y domain como límites explícitos y luego los asignas a las realidades de sitio y región. Elige la topología más simple que cumpla con tus objetivos de disponibilidad y aislamiento, e invierte temprano en prácticas del Día 2 para identidad, respaldos, ciclo de vida y control de cambios. Fuentes: Documentación de VMware Cloud Foundation 9.0 y posterior. Esta publicación apareció originalmente en Digital Thought Disruption. En Q2BSTUDIO, como empresa de desarrollo de software, aplicaciones a medida y especialistas en inteligencia artificial, ciberseguridad y mucho más, entendemos que la adopción de plataformas como VCF requiere un enfoque estratégico. Ofrecemos soluciones de inteligencia artificial para empresas que pueden integrarse con VCF para optimizar la gestión de cargas de trabajo. Además, nuestros servicios de desarrollo de software a medida ayudan a construir aplicaciones que se ejecutan sobre estas topologías. También proporcionamos servicios cloud en AWS y Azure para complementar despliegues multirregión, y servicios de ciberseguridad y pentesting para asegurar infraestructuras críticas. Nuestra experiencia en Business Intelligence con Power BI permite extraer métricas clave de rendimiento de VCF, y la automatización de procesos mediante agentes IA acelera las operaciones del Día 2. Ya sea que necesites aplicaciones a medida, inteligencia de negocio, agentes IA o servicios cloud, en Q2B STUDIO somos tu aliado tecnológico.