My Python Project – NSX ALB Virtual Service Migrator – Release update v1.2 – Part 2

Welcome back!!! This is a continuation to the previous article on my Python project, NSX ALB Virtual Service Migrator v1.2, and in this article, we are going to perform virtual service migration from vCenter write access and No-Orchestrator cloud accounts to an NSX-T cloud account using the enhancements in version 1.2.

If you were not following along, please check out the previous article below:

Part 1 : https://vxplanet.com/2023/07/08/my-python-project-nsx-alb-virtual-service-migrator-release-update-v1-2-part-1/

Let’s get started:

Current NSX ALB environment

In our home lab environment, we have five virtual services across two cloud accounts – vCenter write access and No-Orchestrator cloud. As part of environment modernization, the infrastructure and workloads are getting transitioned to overlay networking in NSX-T, and so are the virtual services. Because the service engines hosting the virtual services are glued to the specific cloud account, they can’t be migrated to NSX-T cloud. Hence new service engines are deployed under NSX-T cloud account and the virtual services will be migrated to NSX-T cloud.

Below sketch shows the current state of virtual services before migration.

Below table lists the virtual service details. We have L7 and L4 virtual services with pools and pool groups. L7 virtual services has content switching HTTP policies with pools / pool groups, has multiple L7 policies and profiles attached. The backend pool members are reached via L2 and L3.

The target NSX-T cloud is configured, and the service engines are deployed.

The NSX-T cloud has multiple data networks (T1 VRFs) configured, but our destination will be LR-T1-DEV.

The cloud account has both IPAM and DNS profile configured.

The IPAM network corresponds to the data network under the VRF Context LR-T1-DEV.

The NSX-T Cloud has the below sub-domains in the DNS profile which can be used for the migrated virtual services. If the application FQDNs doesn’t need to change, we can add the DNS subdomains from the source cloud accounts. The migration tool will retain the DNS names or create new, if DNS names are not found.

And lastly, we have a service engine group created in NSX-T cloud and new service engines deployed to host the migrated virtual services.

The below table lists the virtual service infrastructure specs at the target NSX-T cloud post migration.

Migrating applications using NSX ALB Virtual Service Migrator v1.2

Now let’s use the NSX ALB Virtual Service Migrator v1.2 to migrate the virtual services to NSX-T Cloud account.

Assuming you have gone through the usage instructions in Part 1, we require a Linux/Windows VM with Python3 and few modules (requests, urllib3, tabulate, pandas) installed.

We will clone the repository and navigate to NsxAlbVirtualServiceMigrator/V1.2/ and launch the help menu.

Let’s review the migrate mode flags.

We will now start the migration by running the tool in migrate mode. Flag description is as below:

-i : NSX ALB Controller cluster IP / FQDN
-u : NSX ALB system admin user name
-p – NSX ALB system admin user password
-t : NSX ALB Tenant. Our applications are currently in “admin” tenant
-a : NSX ALB API version. Our controller is on version 22.1.3
-c : Target cloud account (our NSX-T cloud is “VcDC01-NSXMGR01”)
-r : Target VRF Context (our destination is LR-T1-DEV)
-s : Target SE Group (our destination is SEG-NonProd-SDDC)
-d : List of target application domains
-n : Target IPAM network (our’s is LS-T1-DEV)
-S : Target IPAM subnet (our’s is 192.168.10.0/24)
-P : Prefix for migrated objects (This will be the unique run ID for this migration job)

The tool will now run workflows for initializing class objects and attributes for cloud accounts, VRF contexts, service engine groups, pools, pool groups, HTTP Policy sets, IPAM profiles, VSVIPs and more.

Let’s now select the virtual services for migration.

The tool will scan the selected virtual services for HTTP Policy Sets, then for pools / pool groups in HTTP Policy sets, and will migrate them to target NSX-T cloud.

The tool will then scan selected virtual services for pools, pool groups and VSVIPs and will migrate them to target NSX-T cloud.

Finally, the virtual services are migrated, and the session is logged out.

Migrated objects are tracked in “NsxAlbVirtualServiceMigrator/V1.2/Tracker/obj_track-< RUN_ID>.csv”. Let’s review the file and search for any errors.

At this moment, the migration of applications to the target NSX-T cloud account is successful. We will now login to the NSX ALB controller UI, verify and validate the migrated objects.

Performing application cutover

Once the migrated objects are validated, we should be good to perform the cutover. The existing virtual services are disabled, and the corresponding migrated virtual services are enabled. While performing disabling / enabling of virtual services, make sure to select both flags as shown below (as we also need to disable / enable ARP responses also)

The below shows the application state after the virtual services are successfully cutover to NSX-T cloud.

Performing Prefix removal

Now that the virtual service cutover is completed, we need to run the migrator tool again but in remove_prefix mode to remove the prefixes appended to the objects during migration.

Let’s launch the help menu for remove_prefix mode.

The prefix selected during migration (using the parameter -P ) needs to be unique for each migration job. This prefix will be taken as the runID to perform remove_prefix and cleanup tasks.

Let’s run the migrator and wait for the job to complete.

Job output is tracked in “NsxAlbVirtualServiceMigrator/V1.2/Tracker/obj_prefix_removal_status_<RUN_ID>.csv”. Let’s review the file and search for error, if any.

Let’s login to NSX ALB UI and verify the renaming status of objects.

At this stage, the overall migration status is SUCCESSFUL. The below sketch shows the target application state.

Performing migration cleanup

If at any stage of the migration process, we need to perform a cleanup of the migrated objects (either because the tool encountered an error, or because the post migration validation failed), we can run the tool in cleanup mode.

Note 1 : The “Tracker” directory under NsxAlbVirtualServiceMigrator/V1.2/ needs to be preserved to perform cleanup operation, as it maintains track of objects that are migrated.

Note 2 : As the cleanup task deletes all the migrated objects, this needs to be performed before performing the application cutover. There is no way to recover deleted objects.

Let’s run the cleanup job specifying the runID.

Cleanup status is tracked under “NsxAlbVirtualServiceMigrator/V1.2/Tracker/obj_cleanup_status_<RUN_ID>.csv”. Let’s review the file and search for errors, if any.

Now that’s a wrap!!! There are still many enhancements pending to be incorporated into the tool which I will be working on, in the coming months. If you wish to collaborate or leave a feedback, please reach out to me at hari@vxplanet.com

I hope this article was informative, and don’t forget to buy me a coffee if you found this worth reading.