Rivedere la topologia NSX-V e decidere come mapparla alla topologia del NSX-T. Durante la migrazione, il passaggio "Definisci topologia" richiederà la mappatura.

Se si esegue NSX-T 3.2.0 o 3.2.1, è possibile eseguire la migrazione di un bilanciamento del carico di NSX-V in NSX-T Advanced Load Balancer (ALB). A partire da NSX-T 3.2.2, è possibile eseguire la migrazione di un bilanciamento del carico di NSX-V solo in un bilanciamento del carico di NSX-T.

In particolare, determinare il numero di cluster Edge NSX-T necessari e la mappatura dei gateway dei servizi Edge (ESG) e dei router logici distribuiti (DLR) ai gateway in NSX-T. I gateway ESG northbound senza alcun servizio L4-L7 devono essere ignorati. Si tratta in genere di gateway ESG in peering con router northbound e presenti nel percorso ECMP. Se si utilizza la VPN in un ESG northbound, è consigliabile eseguire la migrazione al livello 0 attivo-standby. In altri casi, è consigliata la migrazione degli ESG/DLR al livello 1. Un ESG e un DLR possono essere uniti in un'unica voce di mappatura nel file di mappatura.

Non è possibile mappare più gateway di livello 1 senza un cluster Edge o un gateway di livello 1 solo DR in un gateway di livello 0 principale a DLR. Non è inoltre possibile mappare il gateway di livello 0 principale a un DLR se si esegue la mappatura a un gateway di livello 1 solo DR. Se la topologia richiede la mappatura di più DLR, è necessario utilizzare un gateway di livello 1 attivo-standby con un cluster Edge assegnato.

Se si dispone di un server DHCP configurato su un ESG e di un server di inoltro DHCP configurato su DLR, è necessario mappare ESG e DLR allo stesso gateway di NSX-T.

Esempio di file di mappatura che mappa gli ESG a un gateway di livello 0: 
[
  {
    "name":"nsxv-to-nsxt-mapping",
    "v_edges_to_policy_gateways_mappings":[
      {
        "v_edges":[
          "edge-1",
          "edge-2"
         ],
         "policy_gateway_name": "tier0-gateway"
         "policy_gateway_path": "/infra/tier-0s/tier0-gateway"
      }
    ]
  }
]
Se si esegue NSX-T 3.2.0 o 3.2.1 e si esegue una migrazione della configurazione, la mappatura indicata sopra non viene utilizzata per Advanced Load Balancer (ALB). Esiste invece un'altra mappatura facoltativa che è possibile specificare per ALB. Per specificare tale mappatura, è necessario caricare un file JSON. Esempio di file di mappatura che mappa gli ESG ai gruppi dei motori di servizio: 
{
  "alb": {
    "service_engine_group_per_esg": false,
    "esgs": [
      {
        "name": "edge-4",
        "interfaces": [
          {
            "name": "mgmt",
            "tier1_id": "London_Tier1Gateway1"
          },
          {
            "name": "vnic1",
            "placement_network_subnet": "172.16.1.10/16",
            "service_engine_group": "Test-SE-group"
          }
        ]
      }
    ]
  }
}

Per ulteriori informazioni sulla creazione di un file di mappatura per il bilanciamento del carico, vedere Migrazione del bilanciamento del carico di NSX-V all'Advanced Load Balancer.

A partire da NSX-T 3.2.1 è possibile eseguire la migrazione di un ambiente Cross-vCenter a federazione di NSX. Di seguito è disponibile un file di mappatura di esempio per tale migrazione: 
[
  {
    "name": "site-GM",
    "nsxv_id": "20.20.0.131",
    "nsxt_site_id": "",
    "v_edges_to_policy_gateways_mappings": [
      {
        "v_edges": [
          "edge-3",                                          <== Dhcp server
          "edge-1b4b70c4-27da-4ee9-91cb-bd6389dadca2"        <== Dhcp Relay
        ],
        "policy_gateway_name": "tier0_1_global",
        "policy_gateway_path": "/global-infra/tier-0s/tier0_1_global"
      },
      {
        "v_edges": [
          "edge-a529c168-56c0-4e1a-98e4-e1f0312d82a4"
        ],
        "policy_gateway_name": "tier1_0_global",
        "policy_gateway_path": "/global-infra/tier-1s/tier1_0_global".     <== mapping corresponding to UDLR
      },
      {
        "v_edges": [
          "edge-5"
        ],
        "policy_gateway_name": "tier0_2_global",
        "policy_gateway_path": "/global-infra/tier-0s/tier0_2_global"
      }
    ]
  },
  {
    "name": "london",
    "nsxv_id": "20.20.0.131",
    "nsxt_site_id": "23790eb0-201a-48c3-8e34-8a03be03b61a",
    "v_edges_to_policy_gateways_mappings": [
      {
        "v_edges": [
          "edge-4"
        ],
        "policy_gateway_name": "site0_tier1_0",
        "policy_gateway_path": "/infra/tier-1s/site0_tier1_0"
      }
    ]
  },
  {
    "name": "paris",
    "nsxv_id": "20.20.0.132",
    "nsxt_site_id": "27db83d3-aa10-4a40-b15c-bf6e234b9e74",
    "v_edges_to_policy_gateways_mappings": [
      {
        "v_edges": [
          "edge-1",
          "edge-5"
        ],
        "policy_gateway_name": "site1_tier0_1_local",
        "policy_gateway_path": "/infra/tier-0s/site1_tier0_1_local"
      }
    ]
  }
]
Se si sta eseguendo la migrazione di un ambiente Cross-vCenter a federazione di NSX, tenere presente quanto segue:
  • Ai gateway di livello 0 creati in Local Manager deve essere assegnato un cluster Edge.
  • I gateway di livello 1 creati in Local Manager devono disporre di un cluster Edge assegnato o essere connessi a un gateway di livello 0 a cui è assegnato un cluster Edge.
  • I gateway di livello 0 e di livello 1 creati in Global Manager devono includere tutti i siti.
  • Nel file di mappatura, quando si specificano gli attributi per il Global Manager, nsxt_site_id deve essere una stringa vuota.
  • Il DLR universale (UDLR) non deve essere unito ad altri ESG.
  • I ESG diretti a nord con peering dei servizi L4-L7 con UDLR devono essere mappati al gateway di livello 0 attivo-standby di un sito locale.