NSX-T Data Center 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.


Una implementación multisitio de recuperación ante desastres

En una implementación activo-activo, todos los sitios están activos y el tráfico de Capa 2 cruza los límites del sitio. En una implementación de recuperación ante desastres, NSX-T Data Center 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.


Una implementación multisitio 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:

Recuperación automática del plano de administración: antes de la recuperación ante desastres

Después de la recuperación ante desastres:

Recuperación automática del plano de administración: 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.

Requisitos:
  • La latencia máxima entre los nodos de Edge 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.

Nota: El modo de conmutación por error de la puerta de enlace de nivel 1 puede ser preferente o no preferente.

Pasos de configuración:
  • Mediante la API, cree dominios de errores para los dos sitios, por ejemplo FD1A-Preferred_Site1 y FD2A-Preferred_Site1. En el parámetro preferred_active_edge_services, establezca true como sitio principal y false como sitio secundario.
    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",
        "description": "Updated NSX configured Test Transport Node",
        "id": "77816de2-39c3-436c-b891-54d31f580961",
        ...
    }
    
    PUT /api/v1/transport-nodes/<transport-node-id>
    {
        "resource_type": "TransportNode",
        "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. En caso de que se produzca un error en uno de los nodos de Edge en el sitio principal, se aplica el mismo principio. Por ejemplo, en el siguiente diagrama, supongamos que el nodo de Edge 1B aloja una prueba de nivel 0 y una prueba de nivel 1, el nodo de Edge 2A aloja el estado en espera de la prueba de nivel 0 y el nodo de Edge 2B aloja la prueba de nivel 1 en espera. Si se produce un error en el nodo de Edge 1B, la prueba de nivel 0 en espera en el nodo de Edge 2A y la prueba de nivel 1 en espera en el nodo de Edge 2B toman el control 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:

Recuperación automática del plano de datos: antes de la recuperación ante desastres

Después de la recuperación ante desastres:

Recuperación automática del plano de datos: después de la recuperación ante desastres

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 continua.

No se requiere vSphere HA ni una VLAN de administración ampliada. Los administradores de NSX-T 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 el siguiente diagrama se muestra la recuperación manual/por script del plano de administración.

Recuperación manual del plano de administración

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 sin sistema operativo. La puerta de enlace de nivel 0 puede estar activa-en espera o activa-activa. Las máquinas virtuales de nodo de Edge se pueden instalar en diferentes instancias de vCenter Server. No se requiere vSphere HA.

Los pasos de recuperación son:
  1. Cree una puerta de enlace de nivel 0 en espera en un clúster de Edge existente en el sitio de recuperación ante desastres (DR).
  2. Use la API para mover las puertas de enlace de nivel 1 que están conectadas a una puerta de enlace de nivel 0 a la puerta de enlace de nivel 0 en el sitio de DR.
  3. Use la API para mover las puertas de enlace de nivel 1 independientes al sitio de DR.
  4. Usando la API, mueva los puentes puertas de nivel 2 al sitio de DR.

En el siguiente diagrama se muestra la recuperación manual/por script del plano de datos.

Recuperación manual del plano de datos

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.
Configuración de NSX Manager
  • La copia de seguridad automática cuando se modifica la configuración de NSX-T Data Center debe estar habilitada.
  • NSX Manager se debe configurar para usar el FQDN.
Recuperación de 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.
  • 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.
Sistema de administración de nube
  • El sistema de administración de nube (Cloud Management System, CMS) debe admitir un complemento de NSX-T Data Center. 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-T Data Center (por ejemplo, VMware SRM 8.1.2 o una versión posterior).