Vous pouvez utiliser trois méthodes pour migrer votre commutateur hôte vers vSphere Distributed Switch.

Lors de l'utilisation de N-VDS comme commutateur hôte, NSX-T est représenté comme un réseau opaque dans vCenter Server. N-VDS possède une ou plusieurs des interfaces physiques (pNIC) sur le nœud de transport et la configuration du port est effectuée à partir de NSX-T Data Center. Vous pouvez migrer votre commutateur d'hôte vers vSphere Distributed Switch (VDS) 7.0 pour une utilisation optimale de la PNIC et gérer la mise en réseau d'hôtes NSX-T à partir de vCenter Server. Lors de l'exécution de NSX-T sur un commutateur VDS, un segment est représenté comme un groupe de ports virtuels distribués NSX-T. Les modifications apportées aux segments sur le réseau NSX-T sont synchronisées dans vCenter Server.

Pour migrer vos hôtes N-VDS sur ESXi vers NSX sur VDS choisissez :

Conditions préalables

Les exigences suivantes doivent être satisfaites pour migrer vers un commutateur hôte VDS 7.0 :

  • vCenter Server 7.0 ou une version ultérieure

  • ESXi 7.0 ou une version ultérieure

  • NSX-T n'est plus représenté comme un réseau opaque après la migration. Vous devrez peut-être mettre à jour vos scripts pour gérer la représentation migrée des hôtes NSX-T.

  • Dans NSX-T 3.1, la migration de N-VDS vers vSphere Distributed Switch n'est pas prise en charge pour un environnement de cluster réduit basé sur N-VDS. Elle est prise en charge dans NSX-T 3.1.1 sans l'association nommée.

  • Vous pouvez faire monter la migration en migrant en parallèle des hôtes qui sont en mode de maintenance via vSphere Lifecycle Manager ou manuellement via des API. Par défaut, 64 hôtes par cluster avec une taille de pool de threads de 22 par gestionnaire dans un cluster peuvent être migrés en mode parallèle. Assurez-vous que la taille du lot pour la correction parallèle est limitée à 4 nœuds. Pour la migration via vSphere Lifecycle Manager, l'état « En file d'attente » s'affiche pour tous les hôtes en attente d'un thread disponible. Pour la migration via l'API, toute demande sur la migration active 64 est rejetée.

  • La fonctionnalité de correction parallèle nécessite vCenter Server 7.0 Update 2 ou version ultérieure. Cette fonctionnalité n'est pas prise en charge pour NSX-T Data Center 3.1 et ne doit pas être activée pour les clusters en cours de migration.

  • La migration de N-VDS vers NSX-T Data Center sur VDS est déclenchée uniquement pour les mises à niveau d'ESX supérieures à la version 7.0.2 (X.Y.Z-U.P). La migration ne sera pas déclenchée pour les mises à niveau « U.P » (mise à niveau-correctif). La version d'ESX est spécifiée en tant que X.Y.Z-U. P, où

    • X = Majeure

    • Y = Mineure

    • Z = Maintenance

    • U = Mise à jour

    • P = Correctif

  • L'outil de migration N-VDS vers VDS n'est pas disponible dans NSX-T Data Center 3.2.0. Si vous souhaitez migrer vos charges de travail de N-VDS vers VDS dans cette version, vous devrez le faire manuellement.

Note :

Ne modifiez pas la configuration de NSX-T Data Center tant que tous vos commutateurs d'hôtes n'ont pas été migrés correctement.

Option 1 : utiliser l'API pour migrer le commutateur d'hôte vers vSphere Distributed Switch

Vous pouvez utiliser l'API NSX-T Data Center pour migrer un commutateur hôte vers un vSphere Distributed Switch (VDS).

Pour migrer votre commutateur d'hôte à l'aide d'appels d'API, procédez comme suit.

Procédure

  1. Vérifiez les conditions requises pour effectuer une migration vers un commutateur d'hôte VDS 7.0 dans la section Conditions préalables.
  2. Pour vérifier que les hôtes sont prêts pour la migration, effectuez l'appel d'API suivant et exécutez une vérification préalable.
    POST https://<nsx-mgr>/api/v1/nvds-urt/precheck
    API de stratégie :
    PUT /policy/api/v1/infra/nvds-urt/precheck

    Exemple de réponse :

    { "precheck_id": "166959af-7f4b-4d49-b294-907000eef889" }
  3. Corrigez les incohérences de configuration et exécutez de nouveau la vérification préalable. L'exécution de la vérification préalable après la résolution des incohérences de configuration n'affichera pas à nouveau des configurations incohérentes dans la réponse.
    À partir de la version 3.2.1, une vérification préalable n'échoue pas en cas de configurations incompatibles entre les nœuds de transport au sein d'un environnement NSX-T Data Center. Pour les configurations incompatibles d'UplinkProfile, LLDPProfile et NIOCProfile, la vérification préalable génère des problèmes de configuration. Vous pouvez vérifier les configurations incompatibles et déterminer si vous souhaitez appliquer la topologie ou aligner les configurations entre les nœuds de transport et réexécuter la vérification préalable. Définissez la valeur du paramètre tolerate_different_configurations selon que vous souhaitez ou non que la topologie inclut toutes les combinaisons de différentes configurations. Pour plus d'informations, reportez-vous au Guide de l'API de NSX-T Data Center. La valeur par défaut de tolerate_different_configurations est true.
    La vérification préalable créera également des VDS pour chaque combinaison de configurations différentes. Les topologies recommandées incluront toutes les combinaisons de différentes configurations de nœuds de transport au sein du même NSX-T Data Center (ou du même cluster en cas de VCF). Un VDS spécifique sera généré pour les nœuds de transport avec UplinkProfile, LLDPProfile et NIOCProfile équivalents.
  4. Vérifiez l'état de la vérification préalable. Les profils incohérents seront affichés comme un avertissement au lieu d'une erreur dans la réponse.
    GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>
    API de stratégie :
    GET /policy/api/v1/infra/nvds-urt/status-summary/<precheck-id>

    Exemple de réponse :

    {
        "precheck_id": "165a592d-a94f-4614-978c-9ca003cda278",
        "precheck_status": "PENDING_TOPOLOGY",
        "precheck_issue": [
            {
                "component": "Uplink profile",
                "objid": "nsxvswitch1",
                "warning": "Found inconsistent profiles: [b63afe90-ce04-46e4-a238-d7b63deada36, 0520a955-06cd-4498-883a-d534e8d7724c]. Uplink profile mismatch. Mtu mismatch. ",
                "recommendation": "Keep profiles consistent among transport nodes in the same NVDS",
                "_protection": "NOT_PROTECTED"
            }
        ]
    }
  5. Pour les hôtes sans état, nommez l'un des hôtes en tant qu'hôte source et lancez la migration.
  6. Pour récupérer la topologie recommandée, procédez à l'appel d'API suivant :
    GET https://<nsx-mgr>/api/v1/nvds-urt/topology/<precheck-id>
    API de stratégie :
    GET /policy/api/v1/infra/nvds-urt/topology/<precheck-id>

    Exemple de réponse :

    {
        "topology": [
            {
                "nvds_id": "e70a0fc2-7ec3-483e-9036-4eed170f0ecf",
                "nvds_name": "nsxvswitch1",
                "compute_manager_topology": [
                    {
                        "compute_manager_id": "13127ee9-ea71-4c66-810e-c604d4f67fc4",
                        "dvswitch": [
                            {
                                "data_center_id": "datacenter-4",
                                "vds_name": "VDS-nsxvswitch1-datacenter-4-0",
                                "vmknic": [],
                                "transport_node_id": [
                                    "7af27ad7-4e45-4b36-95a2-d73413aea181"
                                ],
                                "id": "190125b2-d469-4bea-915b-6ffeb9e7b542",
                                "_protection": "NOT_PROTECTED"
                            },
                            {
                                "data_center_id": "datacenter-4",
                                "vds_name": "VDS-nsxvswitch1-datacenter-4-1",
                                "vmknic": [],
                                "transport_node_id": [
                                    "dca9568e-9587-4572-9001-c637960dbdae"
                                ],
                                "id": "9f039516-5318-4e14-8fd4-769d54560bcb",
                                "_protection": "NOT_PROTECTED"
                            },
                            {
                                "data_center_id": "datacenter-22",
                                "vds_name": "VDS-nsxvswitch1-datacenter-22-2",
                                "vmknic": [],
                                "transport_node_id": [
                                    "ebe67bdf-bb9c-4b92-8c81-cdb6ec2d8559",
                                    "32058d07-dbba-4042-92f7-69ece1cc9680"
                                ],
                                "id": "9a389bf0-af53-4ace-b7d3-29b534fbab58",
                                "_protection": "NOT_PROTECTED"
                            }
                        ]
                    }
                ],
                "id": "62f2fe60-1138-454d-99f2-8319255d8119",
                "_protection": "NOT_PROTECTED"
            }
        ]
    }
  7. Effectuez l'appel d'API suivant pour créer un VDS avec la topologie recommandée :
    POST https://<nsx-mgr>/api/v1/nvds-urt/topology?action=apply
    API de stratégie :
    PUT /policy/api/v1/infra/nvds-urt/topology?action=apply

    Notez que vous pouvez uniquement renommer le VDS dans la topologie recommandée avec un nouveau nom et que vous ne pouvez pas utiliser le nom d'un VDS existant.

    Exemple d'entrée :

    {
      "topology": [
        {
          "nvds_id": "c8ff4053-502a-4636-8a38-4413c2a2d52f",
          "nvds_name": "nsxvswitch",
          "compute_manager_topology": [
            {
              "compute_manager_id": "fa1421d9-54a7-418e-9e18-7d0ff0d2f771",
              "dvswitch": [
                {
                  "data_center_id": "datacenter-3",
                  "vds_name": "test-dvs",
                  "transport_node_id": [
                    "65592db5-adad-47a7-8502-1ab548c63c6d",
                    "e57234ee-1d0d-425e-b6dd-7dbc5f6e6527",
                    "70f55855-6f81-45a8-bd40-d8b60ae45b82"
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  8. Pour suivre l'état de la migration, effectuez l'appel d'API suivant :
    GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>

    Lorsque l'hôte est prêt pour la migration, l'élément precheck_status passe de APPLYING _TOPOLOGY à READY et l'état de l'hôte est défini sur UPGRADE_READY.

    Consultez le guide Guide de l'API de NSX-T Data Center pour plus d'informations sur les paramètres API.

  9. Placez l'hôte ESXi en mode de maintenance à partir de vCenter.
  10. Pour lancer la migration de N-VDS vers VDS, effectuez l'appel d'API suivant :
    POST https://<nsx-mgr>/api/v1/transport-nodes/<tn-id>?action=migrate_to_vds

    Les hôtes sont migrés de manière asynchrone. Vous pouvez mettre à niveau plusieurs nœuds de transport en parallèle en appelant l'API pour un ensemble d'hôtes souhaité. Les services tels que DRS continuent de fonctionner comme prévu pendant le processus de migration.

  11. Effectuez l'appel d'API suivant pour suivre l'état de la migration :
    GET https://<nsx-mgr>/api/v1/nvds-urt/status-summary/<precheck-id>

    host migration_state passe de UPGRADE_IN_PROGRESS à SUCCESS après une migration réussie.

    Exemple de réponse :

    {
      "precheck_id": "c306e279-8b75-4160-919c-6c40030fb3d0",
      "precheck_status": "READY",
      "migration_state": [
        {
          "host": "65592db5-adad-47a7-8502-1ab548c63c6d",
          "overall_state": "UPGRADE_READY"
        },
        {
          "host": "e57234ee-1d0d-425e-b6dd-7dbc5f6e6527",
          "overall_state": "UPGRADE_READY"
        },
        {
          "host": "70f55855-6f81-45a8-bd40-d8b60ae45b82",
          "overall_state": "SUCCESS"
        }
      ]
    }

    En cas de pannes, overall_state passe à FAILED, indiquant la raison de l'échec de la migration. Exécutez l'action migrate_to_vds pour réexécuter la tâche de migration.

  12. Pour les hôtes sans état :
    1. Extrayez un profil d'hôte depuis un hôte migré et attachez-le au cluster.
    2. Redémarrez les hôtes restants dans le cluster.

Que faire ensuite

Une fois la migration terminée, vous pouvez effectuer votre mise à niveau.

Option 2 : utiliser l'interface de ligne de commande pour migrer le commutateur d'hôte vers vSphere Distributed Switch

Vous pouvez utiliser l'interface de ligne de commande NSX-TNSX-T pour migrer un commutateur hôte vers un vSphere Distributed Switch (VDS).

Pour migrer votre commutateur d'hôte à l'aide d'appels d'interface de ligne de commande, procédez comme suit.

Procédure

  1. Vérifiez les conditions requises pour effectuer une migration vers un commutateur d'hôte VDS 7.0 dans la section Conditions préalables.
  2. Pour vérifier que les hôtes sont prêts pour la migration, exécutez la commande suivante et exécutez une vérification préalable :
    vds-migrate precheck

    Exemple de résultat :

     Precheck Id: 0a26d126-7116-11e5-9d70-feff819cdc9f
  3. Corrigez les incohérences de configuration et exécutez de nouveau la vérification préalable.
  4. Pour récupérer la topologie recommandée, exécutez la commande suivante :
    vds-migrate show-topology

    Exemple de résultat :

    Precheck Id: 137d2a87-0544-4914-829d-d8b7e33b13f2
           NVDS: nvds1(19cca902-9455-4316-92e2-65f4f5b4b138)                          
           Compute Manager Topology:                                                  
           [                                                                          
               {                                                                      
                   "compute_manager_id": "fd37ed6e-0eae-4d65-b29a-d40eee1d5d47",      
                   "dvswitch": [                                                      
                       {                                                              
                           "transport_node_id": [                                     
                               "4d011ade-a010-4eea-b45a-b2569c0bb9ad"                 
                           ],                                                         
                           "data_center_id": "datacenter-3",                          
                           "vmknic": [],                                              
                           "vds_name": "VDS-nvds1-datacenter-3"                      
                       }                                                              
                   ]                                                                  
               }                                                                      
           ]
  5. Exécutez la commande suivante pour créer un VDS avec la topologie recommandée :
    vds-migrate apply-topology
  6. Connectez-vous à vCenter Server et vérifiez que le VDS est créé.
  7. Pour lancer la migration de N-VDS vers VDS, exécutez la commande suivante :
    vds-migrate esxi-cluster-name <cluster-name>

    Exemple de résultat :

     VDS Migration Done:                                                     
       3 Transport-Nodes Migrate Successfully          
       0 Transport-Nodes Migrate Failed

    Vous pouvez également utiliser l'ID de nœud de transport pour lancer la migration :

    vds-migrate tn-list <file-path>

    <file-path> inclut les ID de nœud de transport.

    Exemple de résultat :

    nsx-manager-1> vds-migrate tn-list /opt/tnid
           VDS Migration Done:
           3 Transport-Nodes Migrate Successfully
           0 Transport-Nodes Migrate Failed

Que faire ensuite

Une fois la migration terminée, vous pouvez effectuer votre mise à niveau.

Option 3 : utiliser l'interface utilisateur pour migrer le commutateur d'hôte vers vSphere Distributed Switch

Vous pouvez utiliser NSX Manager pour préparer vos hôtes pour la migration, puis effectuer la migration vers VDS dans le cadre de la mise à niveau du système d'exploitation de l'hôte, à l'aide de vSphere Update Manager.

Pour migrer votre commutateur d'hôte à l'aide de l'interface utilisateur, procédez comme suit.

Note : Les hôtes ESXi doivent être mis à niveau dans les versions de mise à jour ESXi pour déclencher cette migration. Par exemple,
  • Mise à niveau d'ESXi 7.0 vers ESXi 7.0 U2 : la migration du commutateur peut être déclenchée.
  • Mise à niveau d'ESXi 7.0 U2 vers ESXi 7.0 U2a : la migration de commutateur ne peut pas être déclenchée, car la mise à niveau se trouve dans la même version de mise à jour ESXi.

Procédure

  1. Vérifiez les conditions requises pour effectuer une migration vers un commutateur d'hôte VDS 7.0 dans la section Conditions préalables.
  2. Connectez-vous en tant qu'utilisateur admin local à un dispositif NSX Manager sur https://nsx-manager-ip-address/login.jsp?local=true.
  3. Sélectionnez Système > Démarrage rapide.
  4. Cliquez sur Commencer pour préparer vos hôtes pour la migration de N-VDS vers VDS.
  5. Cliquez sur Vérification préalable pour vérifier si les hôtes sont prêts pour la migration.
  6. Corrigez les incohérences de configuration et exécutez de nouveau la vérification préalable.
  7. Vérifiez la topologie réseau recommandés.
  8. Cliquez sur Créer pour préparer les hôtes sélectionnés pour la migration en créant un commutateur VDS correspondant dans vCenter Server.
  9. Connectez-vous à vCenter Server et mettez à niveau vos hôtes ESXi à l'aide de vSphere Update Manager. La migration du commutateur est terminée lorsque la mise à niveau du système d'exploitation de l'hôte est terminée.
  10. Surveillez la progression de la migration à partir de l'onglet Surveillance.

Que faire ensuite

Facultatif : faites sortir les hôtes migrés du mode de maintenance. Cette étape n'est pas requise pour la migration d'un commutateur hôte dans le cadre de la mise à niveau de l'hôte à l'aide de vSphere Update Manager.