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.
  • Si el enrutamiento 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.

Nota: 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. 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. 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 requiere vSphere HA.

Los pasos de recuperación son:
  1. Con la API, mueva las puertas de enlace de nivel 1 que están conectadas a la puerta de enlace de nivel 0 principal (azul en el siguiente diagrama) a la puerta de enlace de nivel 0 secundaria (verde).
  2. Con la API, mueva las puertas de enlace de nivel 1 independientes al sitio secundario.
  3. Con la API, mueva los puentes de capa 2 al sitio secundario.

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.
NSX Manager
  • Con recuperación automática del plano de administración
    • Administración de VLAN extendida 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
    • Copia de seguridad 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
  • 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).