You can migrate the NSX-V load balancer to NSX-T Advanced Load Balancer (ALB).

To migrate to ALB, from NSX Manager, go to the System > Migrate screen and select Migrate NSX for vSphere, User-Defined Topology and Configuration Migration. This is the only way to migrate the NSX-V load balancer to ALB. All other migration modes will migrate the NSX-V load balancer to NSX-T load balancer. Only a single-site deployment is supported.

Pre-migration Tasks

Before the migration, perform the following tasks to set up ALB in NSX-T:
  • Deploy Avi Controllers from the NSX Manager UI (navigate to System > Appliances). For more information, see the topic Install NSX Advanced Load Balancer Appliance Cluster in the NSX-T Data Center Installation Guide.
  • Avi Controller configurations:
    • Set up the license mode and upload the required Avi licenses on the Avi Controller using the cross-launch UI.
    • Set up cloud configurations for the corresponding transport zone in NSX-T.
    • Make sure that the management network for the Service Engine (SE) has connectivity to the controller IP.
    • Make sure that ports 22, 443, 8443, and 123 are accessible from SE to the controller.

Supported Topologies

You can migrate load balancers either deployed on VLAN or on overlay. The following deployment types are supported.

Overlay:
  • Inline load balancer without transparent mode
  • One-arm load balancer with a single logical interface (LIF)
  • One-arm load balancer across two LIFs
  • Inline load balancer with a one-arm load balancer
VLAN:
  • One-arm load balancer
  • Inline load balancer without transparent mode
  • Inline nested load balancer

The following diagrams show the topologies before the migration (on the left) and after (on the right). In the diagrams, C stands for client VM, S stands for server VM, and E stands for Edge Services Gateway.

Overlay topologies:

Topology 1: On the left: NSX-V inline LB without transparent mode. On the right: NSX-T single-arm ALB.ALB topology 1

Topology 2: On the left: NSX-V single-arm LB. On the right: NSX-T single-arm ALB.ALB topology 2

Topology 3: On the left: NSX-V. Two single-arm LBs across two LIFs (1, 2) to one LIF (1). On the right: NSX-T single-arm ALB across different LIFs (1, 2).ALB topology 3

Topology 4: On the left: NSX-V inline LB with single-arm LB. On the right: NSX-T inline ALB with single-arm LB.ALB topology 4

VLAN topologies:

Topology 5: On the left: NSX-V single-arm LB. On the right: NSX-T single-arm ALB.ALB topology 5

Topology 6: On the left: NSX-V inline LB with transparent mode. On the right: NSX-T inline ALB with transparent mode.ALB topology 6

Topology 7: On the left: NSX-V inline nested LB. On the right: NSX-T inline nested ALB.ALB topology 7

ALB Mapping File

For the migration, you can prepare a mapping file in JSON format that specifies how Edge Services Gateways (ESGs) should be mapped to SE groups. Providing a mapping file is optional. If you do not provide it, you will be prompted for any required information. The following is an example mapping file for an overlay topology: 
{
  "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"
          }
        ]
      }
    ]
  }
}

You can specify the following fields in the mapping file:

Field Description
alb Top level title
service_engine_group_per_esg
  • If not specified, with a basic license, the default SE group will be cloned if needed to handle the SE groups. With an enterprise license, all ESGs will be mapped to the default SE Group.
  • If set to false, you must specify service_engine_group which will be used for the virtual services belonging to that interface.
  • If set to true, an SE group will be created for every ESG.
esgs The list of ESGs in your environment.
name Name of the ESG.
default_tier1_id If this is set all overlay interfaces of the ESG will be mapped to this tie-1 gateway.
interfaces The list of interfaces on the ESG.
interfaces.name The name of the interface.
interfaces.tier1_id
  • All the virtual services connected to the interface will be mapped to this tier-1 gateway.
  • This setting is for overlay virtual services.
  • This setting overrides the default_tier1_id value.
interfaces.placement_network_subnet
  • This specifies the subnets that are to be configured in the cloud network on Avi controller.
  • This setting is for VLAN virtual services.
interfaces.service_engine_group
  • This specifies the SE group for the virtual services connected to the interface.
  • This setting has precedence over other SE group settings.

Common Issues that Generate Feedback

The migration wizard will check the environment and provide feedback about issues to resolve before migration can proceed. The following table lists the issues and the actions you can take.

Issue Action Example
Missing configuration Update the configuration Missing cloud configuration on Avi Controller
Unsupported object Skip MSSQL Monitor
Unsupported configuration Partially migrated Transparent mode is skipped but the virtual services are migrated.
Missing information in mapping file Provide input Tier-1 or segment mapping missing
Orphan object Skip Pools not referenced in virtual services
Layer-2 dependencies Skip virtual services skipped if the corresponding segment is not migrated

The migration wizard will also provide informational messages about conditions that do not prevent migration. For example, if your environment has a basic license, you will see a message recommending an enterprise license.

Tier-1/Segment Mapping

For an overlay topology:
  • Only single-arm load balancer is supported.
  • The "esgs" section in the mapping file specifies the mapping.
  • All virtual services and their pools will be migrated to the tier-1 specified in the mapping file.
For an VLAN topology:
  • Both single and inline load balancers are supported.
  • The VLAN segment for virtual services is derived from the migrated interface of the corresponding virtual service.
  • For pools, the migration wizard will provide feedback about VLAN segment mapping.

Service Engine (SE) Group Mapping

Default mappings:
  • Basic license
    • Supports only active-standby mode.
    • A new SE group is cloned for every 10th vNIC interface.
    • A new SE group is cloned if the number of virtual services per SE group exceeds the configured limit.
  • Advanced license
    • Mapped to default SE group
In the mapping file, you can specify the following to override the default:
  • Set the parameter "service_engine_group_per_esg" to true or false.
  • Specify specific ESG mapping that will override the "service_engine_group_per_esg" parameter.
Note the following:
  • All virtual services sharing the same VIP are mapped to the same SE group.
  • If the shared virtual service count is greater than the number of virtual services per SE group, feedback will be generated to resolve the issue.