The NSX Advanced Load Balancer supports easy migration of virtual services from one Service Engine to another, as would be needed when an SE needs to be deactivated for maintenance or upgrade. Using the steps provided in this topic, the virtual services on an SE can be migrated to another SE.

The migration is transparent to the end users of the virtual service, and designed to deliver no perceptible degradation in performance. If the SE group is redefined to use more powerful hardware, performance must increase, as opposed to remain unchanged.

Note:

Migration is not supported on a legacy active/standby SE group.

Migrating an Individual Virtual Service

  1. Navigate to Applications > Virtual Services.

  2. Click the name of the virtual service to be migrated.



  3. Hover the mouse over the name of the virtual service to display the quick edit menu for the virtual service.

  4. Click Migrate.



  5. By default, the NSX Advanced Load Balancer will choose the best SE for placing the virtual service. Alternatively, you can manually select an SE from the SE list displayed. If you are migrating to new hardware and none of the existing SEs are acceptable, click Create Service Engine check box and select the host on which the SE needs to be created.



The NSX Advanced Load Balancer shows the progress of the migration:



Migrating All Virtual Services

  1. Navigate to Infrastructure > Clouds.

  2. In the Service Engine page, select the check box next to the SE to be deactivate.

  3. Click Disable.



The NSX Advanced Load Balancer replaces all virtual services from the SE marked for disablement onto other SEs. Depending on prevailing conditions. For example, for high client loads, a new SE might be auto-created and this process can take several minutes. After all the virtual services have been placed on one or more SEs, the original SE is disabled and its health icon turns to grey. To view the virtual services that are on other enabled SEs, including any migrated virtual services, click the plus sign at the end of the row (not on the SE name).

Note:

For more information on disabling SEs, see Disabling SE.

Infrastructure Upgrades

In both the above scenarios, no mention was made on changing the definition of the SE group prior to initiation of migration. Barring such changes, migrated virtual services are replaced on pre-existing or newly spun-up SEs with identical hardware configuration. If migration to new hardware is required, the administrator needs to change the properties of the SE group prior to undertaking any virtual service migration. Changing the SE group definition has no effect on SEs that are already running. The new SE group definition comes into effect only when new SEs are spun up.

Virtual services placed thereafter find themselves:

  • Placed on SEs whose servers are:

    • Attached to potentially different networks (but reachable by clients, back-end servers, and Controllers), and

    • Equipped with more or lesser powerful CPUs having different memory and disk configurations.

  • Assigned more or lesser number of vCPUs and different virtual disk and memory capacities.