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 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.
  • Si le routage nord-sud asymétrique n'est pas réalisable, par exemple un pare-feu physique est utilisé en direction du nord vers le nœud NSX Edge, le mode VMware HA de la passerelle de niveau 0 doit être actif-en veille et le mode de basculement doit être préemptif.
  • Si le routage nord-sud asymétrique est possible, par exemple, les deux emplacements sont deux bâtiments sans pare-feu physique entre eux, le mode VMware HA de la passerelle de niveau 0 peut être actif-actif.

Les nœuds Edge peuvent être des machines virtuelles ou Bare Metal. 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 de 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.

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

En cas de panne de l'un des nœuds Edge du site principal et pas d'une panne totale du site, il est important de noter que le même principe s'applique. Par exemple, dans le diagramme « Avant le sinistre », supposons que le nœud Edge 1B héberge le niveau 1 bleu actif et que le nœud Edge 2B héberge le niveau 1 bleu en veille. Si le nœud Edge 1B échoue, la passerelle bleue de niveau 1 en veille sur le nœud Edge 2B prend le relais et devient la nouvelle passerelle active de niveau 1 bleue.

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

Configuration requise :
  • DNS pour NSX Manager avec une durée de vie courte (par exemple, 5 minutes).
  • Sauvegarde NSX Manager 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.

Les schémas suivants illustrent la récupération manuelle/basée sur un script du plan de gestion.

Avant le sinistre :

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

Après le sinistre :

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

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 :
  • Pour tous les niveaux 1 du site principal (bleu), mettez à jour leur configuration de cluster Edge pour qu'elle soit le site de cluster Edge secondaire.
  • Pour tous les niveaux 1 du site principal (bleu), reconnectez-les au site secondaire de niveau 0 (vert).

Les schémas suivants illustrent la récupération manuelle/basée sur un script du plan de données avec les vues de réseau logique et physique.

Avant le sinistre (vues logique et physique) :

Vue logique avant la récupération manuelle du plan de données de récupération d'urgence

Vue physique avant la récupération manuelle du plan de données de récupération d'urgence

Après le sinistre (vues logique et physique) :

Vue logique après la récupération manuelle du plan de données de récupération d'urgence

Vue physique après la récupération manuelle du plan de données de récupération d'urgence

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 NSX Manager 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.
  • Lors de la restauration de NSX Manager dans un environnement multisite, procédez comme suit sur le site secondaire/principal :
    • Une fois que le processus de restauration s'est arrêté à l'étape Ajouter un nœud à un cluster, vous devez d'abord supprimer l'adresse IP virtuelle existante et définir la nouvelle adresse IP virtuelle à partir de Système > Dispositifs de l'interface utilisateur avant d'ajouter des nœuds de gestionnaire supplémentaires.
    • Ajoutez de nouveaux nœuds à un cluster à un nœud restauré après la mise à jour de l'adresse IP virtuelle.