Creación del cluster vSAN VMware extendido

Con todas las configuraciones de requisitos completadas, ahora puede continuar para crear el cluster ampliado de vSAN VMware. Este paso formaliza la conexión entre los hosts de OCI Dedicated Region A y OCI Dedicated Region B, así como el nodo Witness desplegado en una tercera región.

Puede utilizar el asistente de inicio rápido o navegar directamente a: Cluster, Configure, vSAN, Fault Domains and Stretched Cluster en la interfaz de usuario VMware vCenter.

Configure lo siguiente durante este proceso:

  • Asignar región dedicada de OCI a hosts al dominio de errores 1
  • Asignar hosts de región dedicada de OCI B al dominio de errores 2
  • Especificar el host testigo (anteriormente agregado) para el quórum

Para obtener más información, consulte Requisitos de cluster extendido y VMware vSAN Stretched Cluster Guide.

Después de crear el cluster ampliado:

  • Ejecute vSAN Health Checks para validar la integridad del cluster.
  • Abordar cualquier error relacionado con la red (por ejemplo, falta de coincidencia de MTU o problemas de enrutamiento).

Note:

Es posible que encuentre objetos vSAN obsoletos en ciertos hosts desde sus clusters originales. Consulte esta guía para eliminarlos: Cómo suprimir objetos inaccesibles en el almacén de datos de vSAN

Cuando haya finalizado, el cluster debe informar una puntuación de estado de vSAN en el valor 90s superior, lo que indica una configuración extendida correcta.

Configurar NSX

Con el cluster de vSAN VMware extendido, actualice VMware NSX para admitir redes de superposición entre sitios. Este paso garantiza que los hosts ESXi de ambas regiones se puedan comunicar a través de túneles NSX mediante sus respectivas zonas de transporte.

Clonar configuración de NSX TEP
  • Copie el grupo de IP de TEP de NSX del NSX Manager de OCI Dedicated Region B en el NSX Manager de OCI Dedicated Region.
  • Para evitar conflictos de IP con el host de gestión ESXi que aún está presente en OCI Dedicated Region B, configure el nuevo pool de IP en OCI Dedicated Region A para que empiece desde .10.

    Ejemplo: en OCI Dedicated Region, un gestor de NSX, cree un pool de TEP con un rango de .10–.20 para los hosts de OCI Dedicated Region B para garantizar que no se solapen con las IP existentes.

Creación de un perfil de enlace ascendente de OCI Dedicated Region B en OCI Dedicated Region A
  • En OCI Dedicated Region, un NSX Manager, defina un nuevo perfil de enlace ascendente específicamente para los hosts de OCI Dedicated Region B.
  • Utilice el ID de VLAN correcto y asegúrese de que la orden de enlace superior coincida con la configuración de OCI Dedicated Region B.
Preparar hosts para NSX
  • Use OVERLAY-TZ y VLAN-TZ como zonas de transporte.
  • Durante la preparación del host, asigne el perfil de enlace superior adecuado en función de si el host es de OCI Dedicated Region A o OCI Dedicated Region B.

    Nota: En algunos escenarios, especialmente después de un evento de failover, es posible que las interfaces de túnel de NSX no aparezcan correctamente. Para resolver esto:

    • Reinicie el host ESXi afectado o
    • Ejecute el reinicio services.sh mediante SSH en el host.

    Esto garantiza que todos los servicios NSX se inicien en el orden correcto y restauren la estabilidad del túnel.

Crear segmentos de superposición de NSX
  • Cree cuatro segmentos de superposición de NSX.
  • Asegúrese de que estos segmentos estén visibles y sincronizados en todos los hosts ESXi de ambos sitios.
Configuración de DHCP (opcional)
  • Opcionalmente, configure valores de DHCP para los nuevos segmentos de superposición.
  • La configuración de DNS ya se ha configurado anteriormente en esta guía y no es necesario repetirla aquí.
Validar conectividad de superposición completa
  • Despliega cuatro máquinas virtuales, colocando una en cada host en ambas regiones.
  • Asigne a cada máquina virtual una dirección IP estática dentro del rango de segmentos correspondiente.
  • Hacer ping en los gateways de segmento y entre máquinas virtuales para validar la conectividad de superposición L3 en el entorno ampliado.

Activar conectividad externa para máquinas virtuales de superposición

Para permitir que las máquinas virtuales de superposición de NSX VMware accedan a redes externas, configure reglas de NAT y enrutamiento para las VLAN relevantes.

En VCN-MGMT-Active y VCN-MGMT-Failover, actualice la configuración de NAT para la VLAN 1 de enlace superior de NSX Edge:

  • Utilice las mismas IP de acceso externo en ambas regiones, que coincidan con las utilizadas durante el despliegue de OCI Dedicated Region.
  • Confirme que la IP utilizada sea la VIP de alta disponibilidad para los nodos de NSX Edge, visible en NSX Manager.

Actualice también las reglas de acceso externo para las VLAN vSphere:

  • Configure reglas NAT para vcenter-vip, nsxt-manager-vip y HCX-manager-vip (si se utiliza HCX) en ambas redes virtuales en la nube.

Soporte de reenvío de DNS

Las máquinas virtuales de superposición suelen utilizar un reenviador de DNS (por ejemplo, 192.168.253.253) definido en NSX-T. Para enrutar estas consultas DNS:

  1. Cree una tabla de rutas dedicada para el gateway de NAT.
  2. Defina una ruta estática:
    • Destino: 10.x.x.x (subred de VM)
    • Destino: gateway de NAT
    • IP de reenviador de DNS: 192.168.253.253

Esta configuración se debe replicar en ambos sitios. Asocie la nueva tabla de rutas al gateway de NAT para un comportamiento consistente.

Reasignar VLAN de host ESXi a la VCN flotante

En la configuración actual, cada host ESXi se aprovisiona con dos NIC físicas, cada una asociada a un juego por defecto de VLAN configuradas mediante asociaciones de VNIC a VCN-Primary (Región dedicada de OCI A) y VCN-Secondary (Región dedicada de OCI B). Estas VNIC se configuran mediante el bloque de CIDR secundario (172.45.0.0/16) asociado a las respectivas VCN.

Para completar la transición hacia una configuración ampliada, todas las VLAN con etiquetas 200 y superiores (por ejemplo, para vSphere, HCX, NSX Edge, etc.) se deben migrar a las VCN flotantes:
  • VCN-MGMT-Active en OCI Dedicated Region A
  • VCN-MGMT-Failover en OCI Dedicated Region B

Migración de VNIC a la VCN flotante

Siga estos pasos para cada host ESXi en ambos SDDC:
  1. Acceda a los detalles de host de ESXi: en la consola de OCI, vaya a Recursos informáticos, hosts de ESXi.
  2. Suprimir asociaciones de VNIC existentes: para cada host, suprima las VNIC asociadas a las VLAN 201 y superiores de la VCN principal o la VCN secundaria.

    Note:

    Este paso es obligatorio porque no se puede crear una nueva VNIC para la misma VLAN mientras exista la anterior.
  3. Vuelva a crear las VNIC en la VCN flotante:
    • Cree una nueva VNIC para cada VLAN de la VCN flotante correspondiente:
      • Utilice VCN-MGMT-Active en OCI Dedicated Region A
      • Utilizar VCN-MGMT-Failover en OCI Dedicated Region B
    • Seleccione la VLAN etiquetada con el sufijo -NEW adecuado para distinguirla del original.

    Repita este proceso para ambas VNIC por host. Recomendamos un enfoque sistemático: comience con vnic0 y vnic1 para la VLAN 201, complete las sustituciones y, a continuación, continúe con la siguiente VLAN.

    Consideraciones especiales para hosts de sitios secundarios

    Después de migrar las VNIC para los hosts en el sitio principal, repita el proceso para todos los hosts en el sitio secundario. Sin embargo, tenga en cuenta un detalle clave:

    • Los componentes de gestión vSphere del sitio secundario se desplegaron inicialmente en una VLAN temporal (por ejemplo, VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Esta VLAN temporal puede permanecer en su lugar durante la transición. No afecta a la funcionalidad de vSAN ampliada y ofrece acceso de reserva a los componentes vCenter y NSX si es necesario.

    La retención de esta VLAN temporal garantiza un acceso de gestión ininterrumpido durante el flujo de trabajo de migración de VNIC y red.

    Impacto y recuperación de la conectividad

    Durante las actualizaciones de VNIC, se espera la pérdida temporal de conectividad a los hosts vCenter, NSX Manager o ESXi. Para garantizar la recuperación:

    1. Verifique las asociaciones de DRG: confirme que las CN de gestión adecuadas (tanto activas como de failover) estén conectadas a sus respectivos gateways de enrutamiento dinámico (DRG).
    2. Actualizar tablas de rutas:
      • Actualice la tabla de rutas maestras de cada VCN de gestión para que apunte al DRG.
      • Actualice las tablas de rutas de subred de Bastion para garantizar que el tráfico de gestión se enrute correctamente entre las redes virtuales en la nube y entre regiones.
    3. Validar acceso:
      • Después de actualizar las rutas, se debe restaurar el acceso a todas las interfaces de gestión desde el host de Bastion.
      • Si no se puede acceder a ningún recurso, compruebe dos veces las reglas del NSG y la propagación de rutas entre las redes virtuales en la nube.

    Limpieza posterior a la migración de vNIC

    Una vez finalizada la migración de VNIC:

    • Elimine todas las VLAN no utilizadas de VCN-Primary y VCN-Secondary que pertenecen al bloque de CIDR 172.45.0.0/16.
    • Desasocie el CIDR secundario (172.45.0.0/16) de VCN-Primary porque ya no está en uso.

    OCI permitirá la desasociación de CIDR solo cuando no la utilice ningún recurso activo (VNIC, subredes o VLAN).

    • Puede observar los indicadores de advertencia en la página de recursos del SDDC de la consola de OCI, lo que se espera, ya que el servicio Oracle Cloud VMware Solution ya no realiza un seguimiento de los componentes que se desplegaron inicialmente en VCN-Primary.

    Actualización del enrutamiento para nuevas asociaciones de VCN

    1. Asocie VCN-MGMT-Active al DRG en la región dedicada de OCI A.
    2. Actualizar tablas de rutas:
      • Para VCN-MGMT-Active: apunte la ruta por defecto (0.0.0.0/0) al DRG.
      • Para la subred de bastión en VCN-Primary: actualice su tabla de rutas para que apunte al DRG a fin de asegurarse de que aún puede acceder a VMware vCenter y VMware NSX Manager.

    Después de realizar estos cambios, se debe poder acceder a VMware vCenter y VMware NSX Manager en OCI Dedicated Region A desde el host Bastion, aunque sus interfaces subyacentes ahora residan en una VCN diferente.

Configuración de reglas de afinidad de DRS, HA y política de almacenamiento de vSAN VMware

Una vez que el cluster estirado esté completamente operativo y la red sea estable en ambos sitios, configure el programador de recursos distribuidos (DRS), la alta disponibilidad (HA) y asigne una política de almacenamiento vSAN VMware compatible con el sitio a las máquinas virtuales (VM) de gestión y carga de trabajo.

Estas configuraciones garantizan una ubicación óptima de las máquinas virtuales en los dominios de errores y permiten la recuperación automática durante los fallos del sitio.

Migración de VM al cluster estirado

Comience por migrar todas las máquinas virtuales de gestión y las máquinas virtuales de carga de trabajo de prueba al cluster extendido recién creado:

  • Utilice vMotion para mover las máquinas virtuales de sus clusters específicos del sitio originales al cluster ampliado.
  • Si todo está configurado correctamente (redes, almacenamiento, grupos de puertos), la migración de VM se debe completar sin ningún problema.

Si existen reglas predeterminadas de NSX DRS y se establecen en MUST, elimínelas. Esto puede interferir con las operaciones de alta disponibilidad y evitar el failover de los nodos de NSX Edge y las máquinas virtuales de NSX Manager.

Crear grupos de hosts y máquinas virtuales

Defina grupos de afinidad para la colocación de la carga de trabajo:

  1. Crear grupos de hosts:
    • Agrupe los hosts que pertenecen al sitio principal.
    • Agrupe los hosts que pertenecen al sitio secundario.
  2. Crear grupos de máquinas virtuales:
    • Máquinas virtuales de gestión de grupos que deben residir en hosts de cada sitio (como vCenter, NSX Managers, nodos NSX Edge, HCX Manager y otros, si corresponde).
    • Del mismo modo, agrupe todas las máquinas virtuales de carga de trabajo (en nuestro caso, todas las máquinas virtuales de prueba).

Definir reglas de afinidad de VM/host

Una vez definidos los grupos:

  • Cree reglas de afinidad de VM a host para mantener las VM ubicadas en los hosts en el sitio deseado.
  • Utilice las reglas Ejecutar máquinas virtuales en hosts para permitir la flexibilidad de alta disponibilidad en escenarios de failover.
  • Cree dichas reglas para los grupos de máquinas virtuales de gestión y de carga de trabajo.

Esta configuración garantiza que durante el funcionamiento normal, cada sitio aloje las cargas de trabajo previstas, pero permite la recuperación automática en caso de fallo del host o del sitio.

Habilitar alta disponibilidad (HA)
  • Asegúrese de que HA esté activado en el nivel de cluster después de que se hayan establecido las reglas de afinidad.
  • La opción por defecto para reiniciar máquinas virtuales tras un evento de fallo de host garantiza el reinicio de la máquina virtual durante fallos inesperados, incluidas las interrupciones completas del sitio.

Creación y aplicación de una política de almacenamiento de vSAN extendida

Para garantizar la redundancia de datos en ambos sitios en una configuración ampliada, defina una nueva política de gestión de políticas basadas en almacenamiento (SBPM) de vSAN. Esta política controlará cómo se distribuyen los datos de la máquina virtual entre los dominios de errores y el sitio del testigo.

Configure las siguientes reglas de colocación en la política:

  • Tipo de almacenamiento: vSAN
  • Site Disaster Tolerance: creación de reflejo de sitio: cluster ampliado
  • Fallos para tolerar: sin redundancia de datos
  • Número de segmentos de disco por objeto: 1
  • Límite de IOPS para objeto: 0

Deje todas las demás opciones con sus valores por defecto.

Una vez que se ha creado la política:

  1. Aplique la política a todas las máquinas virtuales de prueba y gestión del cluster estirado.
  2. Vaya a Monitor, vSAN, Resyncing Objects (Supervisar, vSAN, Resyncing Objects) para observar y realizar un seguimiento del proceso de resincronización.
  3. Una vez finalizada la resincronización, verifique la ubicación de objetos para confirmar que la política funciona como se esperaba:
    • Un objeto de réplica se encuentra en el sitio principal
    • Un segundo objeto de réplica se encuentra en el sitio secundario
    • El componente de testigo reside en la región de testigo remota.

Todas las máquinas virtuales aparecerán inicialmente como no compatibles. Seleccione cada máquina virtual o un grupo de máquinas virtuales y asigne manualmente la política ampliada recién creada para cumplirla.

Además, vaya a Supervisión, vSAN, Resincronización de objetos y objetos virtuales. Una vez que se haya completado el proceso de resincronización, debe observar que los objetos virtuales de cada VM se distribuyen correctamente en el nodo Primary Site, Secondary Site y Witness, lo que valida el cumplimiento completo con el diseño de cluster ampliado.