NSX-T Data Center prend en charge les déploiements multisites dans lesquels vous pouvez gérer tous les sites d'un cluster NSX Manager.

Deux types de déploiements multisites sont pris en charge :
  • Récupération d'urgence
  • Actif-Actif

Le schéma suivant illustre un déploiement de récupération d'urgence.


Déploiement de récupération d'urgence multisite

Dans un déploiement actif-actif, tous les sites sont actifs et le trafic de couche 2 dépasse les limites du site. Dans un déploiement de récupération d'urgence, NSX-T Data Center sur le site principal gère la mise en réseau de l'entreprise. Le site secondaire est prêt à prendre le relais en cas de défaillance irrémédiable sur le site principal.

Le schéma suivant illustre un déploiement actif-actif.


Déploiement actif-actif multisite

Vous pouvez déployer deux sites pour une récupération automatique ou manuelle/basée sur un script du plan de gestion et du plan de données.

Récupération automatique du plan de gestion

Configuration requise :
  • Un cluster vCenter étendu avec HA sur les sites configurés.
  • Un VLAN de gestion étendu.

Le cluster NSX Manager est déployé sur le VLAN de gestion et se trouve physiquement dans le site principal. En cas de panne d'un site principal, vSphere HA redémarrera les instances de NSX Manager sur le site secondaire. Tous les nœuds de transport se reconnectent automatiquement aux instances de NSX Manager redémarrées. Ce processus dure environ 10 minutes. Pendant ce temps, le plan de gestion n'est pas disponible, mais le plan de données n'est pas affecté.

Les diagrammes suivants illustrent la récupération automatique du plan de gestion.

Avant le sinistre :

Récupération automatique du plan de gestion : avant la récupération d'urgence

Après la récupération d'urgence :

Récupération automatique du plan de gestion : après la récupération d'urgence

Récupération automatique du plan de données

Vous pouvez configurer des domaines de pannes pour les nœuds Edge afin d'obtenir une récupération automatique du plan de données. Vous pouvez regrouper des nœuds Edge dans un cluster Edge dans différents domaines de pannes. NSX Manager placera automatiquement toutes les nouvelles passerelles de niveau 1 actives dans le domaine de pannes préféré et la passerelle de niveau 1 en veille dans l'autre domaine.

Configuration requise :
  • La latence maximale entre les nœuds Edge est de 10 ms.
  • Le mode HA pour la passerelle de niveau 0 doit être actif-en veille et le mode de basculement doit être préemptif.
  • Si le routage asymétrique est possible (par exemple, les deux emplacements sont deux bâtiments sans pare-feu physique entre eux), le mode HA de la passerelle de niveau 0 peut être actif-actif.

Remarque : le mode de basculement de la passerelle de niveau 1 peut être préemptif ou non. Toutefois, le mode préemptif est recommandé pour garantir le même emplacement pour les passerelles de niveau 0 et de niveau 1.

Étapes de configuration :
  • À l'aide de l'API, créez des domaines de panne pour les deux sites, par exemple FD1A-Preferred_Site1 et FD2A-Preferred_Site1. Définissez le paramètre preferred_active_edge_services sur true pour le site principal et définissez-le sur false pour le site secondaire.
    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"
}
  • À l'aide de l'API, configurez un cluster Edge étendu sur les deux sites. Par exemple, le cluster dispose de nœuds Edge EdgeNode1A et EdgeNode1B dans le site principal, et des nœuds Edge EdgeNode2A et EdgeNode2B dans le site secondaire. Les passerelles de niveau 0 et de niveau 1 actives s'exécuteront sur EdgeNode1A et EdgeNode1B. Les passerelles de niveau 0 et de niveau 1 en veille s'exécuteront sur EdgeNode2A et EdgeNode2B.
  • À l'aide de l'API, associez chaque nœud Edge au domaine de pannes du site. Appelez d'abord l'API GET /api/v1/transport-nodes/<transport-node-id> pour obtenir les données sur le nœud Edge. Utilisez le résultat de l'API GET comme entrée pour l'API PUT /api/v1/transport-nodes/<transport-node-id>, avec la propriété supplémentaire, failure_domain_id, définie de manière appropriée. Par exemple,
    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>",
}
  • À l'aide de l'API, configurez le cluster Edge pour allouer des nœuds en fonction du domaine de pannes. Appelez d'abord l'API GET /api/v1/edge-clusters/<edge-cluster-id> pour obtenir les données sur le cluster Edge. Utilisez le résultat de l'API GET comme entrée pour l'API PUT /api/v1/edge-clusters/<edge-cluster-id>, avec la propriété supplémentaire, allocation_rules, définie de manière appropriée. Par exemple,
    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"
                      }
        }
    ],
}
  • Créez des passerelles de niveau 0 et de niveau 1 à l'aide de l'API ou de l'interface utilisateur NSX Manager.

En cas de panne complète d'un site principal, les passerelles de niveau 0 et de niveau 1 en veille dans le site secondaire prennent automatiquement le relais et deviennent les nouvelles passerelles actives. En cas de panne de l'un des nœuds Edge dans le site principal, le même principe s'applique. Par exemple, dans le diagramme ci-dessous, supposons que le nœud Edge 1B héberge Niveau 0-test et Niveau 1-test, le nœud Edge 2A héberge Niveau 0-test en veille et le nœud Edge 2B héberge Niveau 1-test en veille. Si le nœud Edge 1B échoue, Niveau 0-test en veille sur le nœud Edge 2A et Niveau 1-test en veille sur le nœud Edge 2B prennent le relais et deviennent les nouvelles passerelles actives.

Les diagrammes suivants illustrent la récupération automatique du plan de données.

Avant le sinistre :

Récupération automatique du plan de données : avant la récupération d'urgence

Après la récupération d'urgence :

Récupération automatique du plan de données : après la récupération d'urgence

Récupération manuelle/basée sur un script du plan de gestion

Configuration requise :
  • DNS pour les instances de NSX Manager avec une durée de vie courte (par exemple, 5 minutes).
  • Sauvegarde continue

Ni vSphere HA ni un VLAN de gestion étiré n'est requis. Les gestionnaires NSX-T doivent être associés à un nom DNS avec une durée de vie courte. Tous les nœuds de transport (nœuds Edge et hyperviseurs) doivent se connecter au NSX Manager à l'aide de leur nom DNS. Pour gagner du temps, vous pouvez éventuellement pré-installer un cluster NSX Manager sur le site secondaire.

Les étapes de la récupération d'urgence sont les suivantes :
  1. Modifiez l'enregistrement DNS pour que le cluster NSX Manager possède différentes adresses IP.
  2. Restaurez le cluster NSX Manager depuis une sauvegarde.
  3. Connectez les nœuds de transport vers le nouveau cluster NSX Manager.

Le schéma suivant illustre la récupération manuelle/basée sur un script du plan de gestion.

Récupération manuelle du plan de gestion

Récupération manuelle/basée sur un script du plan de données

Configuration requise :
  • La latence maximale entre les nœuds Edge est de 150 ms.

Les nœuds Edge peuvent être des machines virtuelles ou Bare Metal. Les passerelles de niveau 0 à chaque emplacement peuvent être actives-en veille ou actives-actives. Les machines virtuelles de nœuds Edge peuvent être installées sur des serveurs vCenter différents. Aucun vSphere HA n'est requis.

Les étapes de la récupération d'urgence sont les suivantes :
  1. À l'aide de l'API, déplacez les passerelles de niveau 1 connectées à la passerelle de niveau 0 principale (bleue dans le diagramme ci-dessous) vers la passerelle de niveau 0 secondaire (verte).
  2. À l'aide de l'API, déplacez les passerelles de niveau 1 autonomes vers le site secondaire.
  3. À l'aide de l'API, déplacez les ponts de couche 2 vers le site secondaire.

Le schéma suivant illustre la récupération manuelle/basée sur un script du plan de données.

Récupération manuelle du plan de données

Configuration requise pour les déploiements multisites

Communication entre les sites
  • La bande passante doit être supérieure ou égale à 1 Go/s et la latence (RTT) doit être inférieure à 150 ms.
  • Le MTU doit être supérieur ou égal à 1 600. Un MTU de 9 000 est recommandé.
NSX Manager
  • Avec récupération automatique du plan de gestion
    • Gestion de VLAN étendue entre les sites.
    • vSphere HA sur les sites pour les VM NSX Manager.
  • Avec la récupération manuelle/basée sur un script du plan de gestion
    • Sauvegarde continue.
    • NSX Manager doit être configuré pour utiliser le nom de domaine complet.
Plan de données
  • Le même fournisseur internet doit être utilisé si les adresses IP publiques sont exposées via des services tels que NAT ou l'équilibreur de charge.
  • Avec récupération automatique du plan de gestion
    • La latence maximale entre les emplacements est de 10 ms.
    • Le mode HA pour la passerelle de niveau 0 doit être actif-en veille et le mode de basculement doit être préemptif pour garantir l'absence de routage asymétrique.
    • Le mode HA de la passerelle de niveau 0 peut être actif-actif si le routage asymétrique est acceptable (par exemple, différents bâtiments dans une région métropolitaine).
  • Avec la récupération manuelle/par script du plan de gestion
    • La latence maximale entre les emplacements est de 150 ms.
Système de gestion de cloud
  • Le système de gestion de cloud (CMS) doit prendre en charge un plug-in NSX-T Data Center. Dans cette version, VMware Integrated OpenStack (VIO) et vRealize Automation (vRA) répondent à cette exigence.

Limitations

  • Aucune capacité de sortie locale. Tout le trafic nord-sud doit se produire au sein d'un site.
  • Le logiciel de récupération d'urgence de calcul doit prendre en charge NSX-T Data Center, par exemple, VMware SRM 8.1.2 ou version ultérieure.