Multisitio de NSX

NSX admite la implementación multisitio donde puede administrar todos los sitios de un clúster de NSX Manager.

Se admiten dos tipos de implementaciones multisitio:

• Recuperación ante desastres
• Activo-activo

En el siguiente diagrama se muestra una implementación de recuperación ante desastres.

En una implementación de recuperación ante desastres, NSX en el sitio principal controla las redes de la empresa. El sitio secundario permanece inactivo para tomar el relevo si se produce un error grave en el sitio principal.

En el siguiente diagrama se muestra una implementación activo-activo.

Puede implementar dos sitios para la recuperación automática o manual/por script del plano de administración y del plano de datos.

Recuperación automática del plano de administración

Requisitos:

• Un clúster de vCenter ampliado con HA en todos los sitios configurados.
• Una VLAN de administración ampliada.

El clúster de NSX Manager se implementa en la VLAN de administración y se encuentra físicamente en el sitio principal. Si se produce un error en el sitio principal, vSphere HA reiniciará las instancias de NSX Manager en el sitio secundario. Todos los nodos de transporte se reconectarán automáticamente a las instancias de NSX Manager reiniciadas. Este proceso dura unos 10 minutos. Durante este tiempo, el plano de administración no estará disponible, pero el plano de datos no se verá afectado.

Los siguientes diagramas ilustran la recuperación automática del plano de administración.

Antes del desastre:

Después de la recuperación ante desastres:

Recuperación automática del plano de datos

Puede configurar los dominios de errores para los nodos de Edge a fin de lograr la recuperación automática del plano de datos. Puede agrupar los nodos de Edge dentro de un clúster de Edge en diferentes dominios de errores. NSX Manager colocará automáticamente cualquier nueva puerta de enlace de nivel 1 activa en el dominio de errores preferido y la puerta de enlace de nivel 1 en espera en el otro dominio. Tenga en cuenta que un nivel 1 implementado antes de la creación de dominios de errores mantendrá su ubicación original del nodo de Edge, por lo que es posible que no se estén ejecutando donde desea. Para corregir su ubicación, edite el nivel 1 y seleccione manualmente los nodos de Edge para el nivel 1-Activo y el nivel 1-En espera.

Requisitos:

• La latencia máxima entre los nodos de Edge es de 10 ms.
• Si no se puede lograr el enrutamiento asimétrico norte-sur, por ejemplo si se utiliza un firewall físico en dirección norte hacia el nodo NSX Edge, entonces el modo HA de la puerta de enlace de nivel 0 deberá ser activo-en espera y el modo de conmutación por error deberá ser preferente.
• Si el enrutamiento norte-sur asimétrico es posible (por ejemplo, las dos ubicaciones son dos edificios sin ningún firewall físico entre ellos), el modo de alta disponibilidad para la puerta de enlace de nivel 0 puede ser activo-activo.

Los nodos de Edge pueden ser máquinas virtuales o sin sistema operativo. El modo de conmutación por error de la puerta de enlace de nivel 1 puede ser preferente o no preferente, pero se recomienda el uso preferente para garantizar que las puertas de enlace de nivel 0 y 1 estén en la misma ubicación.

Pasos de configuración:

• Mediante la API, cree dominios de errores para los dos sitios, por ejemplo FD1A-Preferred_Site1 y FD2A-Preferred_Site1.
  Nota: Si desea que todos los niveles 1 con T1-Activo en los nodos de Edge y T1-En espera en otros nodos de Edge formen parte del mismo dominio de errores (FD1A-Preferred_Site1 y FD2A-Preferred_Site1), debe crear primero el nivel 1 con la opción preferente y, a continuación, crear el elemento principal del dominio de errores (FD1A-Preferred_Site1) establecido en preferred_active_edge_services = true. Por ejemplo,

  POST /api/v1/failure-domains
  {
  "display_name": "FD1A-Preferred_Site1",
  "preferred_active_edge_services": "true"
  }
  
  POST /api/v1/failure-domains
  {
  "display_name": "FD2A-Preferred_Site1",
  "preferred_active_edge_services": "false"
  }

• Mediante la API, configure un clúster de Edge ampliado a los dos sitios. Por ejemplo, el clúster tiene los nodos de Edge EdgeNode1A y EdgeNode1B en el sitio principal, y los nodos de Edge EdgeNode2A y EdgeNode2B en el sitio secundario. Las puertas de enlace de nivel 0 y 1 activas se ejecutarán en EdgeNode1A y EdgeNode1B. Las puertas de enlace de nivel 0 y 1 en espera se ejecutarán en EdgeNode2A y EdgeNode2B.
• Usando la API, asocie cada nodo de Edge con el dominio de errores del sitio. En primer lugar, llame a la API GET /api/v1/transport-nodes/<transport-node-id> para obtener los datos sobre el nodo de Edge. Utilice el resultado de la API GET como entrada para la API PUT /api/v1/transport-nodes/<transport-node-id>, con la propiedad adicional failure_domain_id configurada correctamente. Por ejemplo,

  GET /api/v1/transport-nodes/<transport-node-id>
  Response:
  {
      "resource_type": "TransportNode",  
      "_revision": 15"
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
  }
  
  PUT /api/v1/transport-nodes/<transport-node-id>
  {
      "resource_type": "TransportNode",
      "_revision": 15"
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
      "failure_domain_id": "<UUID>",
  }

• Usando la API, configure el clúster de Edge para asignar nodos en función del dominio de errores. En primer lugar, llame a la API GET /api/v1/edge-clusters/<edge-cluster-id> para obtener los datos sobre el clúster de Edge. Utilice el resultado de la API GET como entrada para la API PUT /api/v1/edge-clusters/<edge-cluster-id>, con la propiedad adicional allocation_rules configurada correctamente. Por ejemplo,

  GET /api/v1/edge-clusters/<edge-cluster-id>
  Response:
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
  }
  
  PUT /api/v1/edge-clusters/<edge-cluster-id>
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
      "allocation_rules": [
          {
              "action": {
                        "enabled": true,
                        "action_type": "AllocationBasedOnFailureDomain"
                        }
          }
      ],
  }

• Cree puertas de enlace de nivel 0 y 1 mediante la interfaz de usuario de NSX Manager o la API.

En caso de que se produzca un error de sitio principal completo, el modo de espera de nivel 0 y el de nivel 1 en el sitio secundario se retoman automáticamente y se convierten en las nuevas puertas de enlace activas.

Los siguientes diagramas ilustran la recuperación automática del plano de datos.

Antes del desastre:

Después de la recuperación ante desastres:

En caso de que se produzca un error en uno de los nodos de Edge en el sitio principal y no en el sitio completo, es importante tener en cuenta que se aplica el mismo principio. Por ejemplo, en el diagrama "Antes del desastre", supongamos que el nodo de Edge 1B aloja el nivel 1-azul activo y que el nodo de Edge 2B aloja el modo en espera de nivel 1-azul. Si se produce un error en el nodo de Edge 1B, el nivel 1-azul en espera en el nodo de Edge 2B asume el control y se convierte en la nueva puerta de enlace activa de nivel 1 azul.

Recuperación manual/por script del plano de administración

Requisitos:

• DNS para NSX Manager con un TTL corto (por ejemplo, 5 minutos).
• Copia de seguridad de NSX Manager continua.

No se requiere vSphere HA ni una VLAN de administración ampliada. NSX Managers deben estar asociados a un nombre DNS con un TTL corto. Todos los nodos de transporte (hipervisores y nodos de Edge) deben conectarse a NSX Manager usando su nombre DNS. Para ahorrar tiempo, opcionalmente puede preinstalar un clúster de NSX Manager en el sitio secundario.

Los pasos de recuperación son:

1. Cambie el registro DNS para que el clúster de NSX Manager tenga diferentes direcciones IP.
2. Restaure el clúster de NSX Managera partir de una copia de seguridad.
3. Conecte los nodos de transporte al nuevo clúster de NSX Manager.

En los siguientes diagramas se muestra la recuperación manual/por script del plano de administración.

Antes del desastre:

Después del desastre:

Recuperación manual/por script del plano de datos

Requisito: La latencia máxima entre los nodos de Edge es de 150 ms.

Los nodos de Edge pueden ser máquinas virtuales o nativos. Las puertas de enlace de nivel 0 en cada ubicación pueden ser activas-en espera o activas-activas. Las máquinas virtuales de nodo de Edge se pueden instalar en diferentes instancias de vCenter Server. No se necesita vSphere HA.

Los pasos de recuperación son:

• Para todo el nivel 1 en el sitio principal (azul), actualice la configuración del clúster de Edge para que sea el sitio del clúster de Edge secundario.
• Para todos los niveles 1 del sitio principal (azul), vuelva a conectarlos al nivel 0 secundario (verde).

En los siguientes diagramas se muestra la recuperación manual o generada por script del plano de datos con las vistas de red lógica y física.

Antes del desastre (vistas lógicas y físicas):

Después del desastre (vistas lógicas y físicas):

Requisitos para implementaciones multisitio

Comunicación entre sitios

• El ancho de banda debe ser 1 Gbps como mínimo y la latencia (RTT) debe ser inferior a 150 ms.
• La MTU debe ser de al menos 1.600. Se recomienda 9.000.

NSX Manager

• Con recuperación automática del plano de administración con administración de VLAN ampliada entre sitios. vSphere HA en todos los sitios para máquinas virtuales de NSX Manager.
• Con recuperación manual/por script del plano de administración con administración de VLAN extendida entre sitios. VMware SRM para máquinas virtuales de NSX Manager.
• Con recuperación manual/por script del plano de administración sin administración de VLAN extendida entre sitios.
  • Copia de seguridad de NSX Manager continua.
  • NSX Manager se debe configurar para usar el FQDN.

Plano de datos

• Si se debe utilizar el mismo proveedor de Internet cuando las direcciones IP públicas se exponen a través de servicios como NAT o el equilibrador de carga.
• Con recuperación automática del plano de administración
  • La latencia máxima entre ubicaciones es de 10 ms.
  • El modo HA para la puerta de enlace de nivel 0 debe estar activo-en espera, y el modo de conmutación por error debe ser preferente para garantizar que no se produzca un enrutamiento asimétrico.
  • El modo de alta disponibilidad para la puerta de enlace de nivel 0 puede ser activo-activo si el enrutamiento asimétrico es aceptable (por ejemplo, diferentes edificios en una región metropolitana).
• Con recuperación manual/por script del plano de administración
  • La latencia máxima entre ubicaciones es de 150 ms.

Sistema de administración de nube (CMS)

• CMS debe admitir un complemento de NSX. En esta versión, VMware Integrated OpenStack (VIO) y vRealize Automation (vRA) cumplen este requisito.

Limitaciones

• Sin capacidades de salida local. Todo el tráfico norte-sur debe realizarse dentro de un sitio.
• El software de recuperación ante desastres de equipos debe admitir NSX (por ejemplo, VMware SRM 8.1.2 o una versión posterior).
• Al restaurar NSX Manager en un entorno de varios sitios, haga lo siguiente en el sitio secundario/principal:
  • Una vez que el proceso de restauración se pausa en el paso AddNodeToCluster, primero deberá eliminar la VIP existente y establecer la nueva dirección IP virtual desde la página de la interfaz de usuario Sistema > Dispositivos antes de agregar nodos adicionales de Manager.
  • Agregue nodos nuevos a un clúster de un nodo restaurado después de actualizar la VIP.