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

It’s been few months since I made updates to my first Python project called NSX Advanced Load Balancer Virtual Service Migrator (formerly NSX ALB Cloud Migrator). Because I learned new topics around object oriented programming (classes and objects) and few others, I made my third release to the migration tool, which is version 1.2. I added new enhancements around IPAM and DNS profiles that addresses few more migration scenarios across NSX ALB cloud accounts.

This two-part blog series is an announcement of version 1.2 along with a demo of virtual service migration between two cloud accounts using the enhancements in version 1.2.

Part 1 covers an overview of the migration toolkit, usage instructions, different modes of the tool (migrate, remove_prefix and cleanup), migration workflow, new capabilities and known limitations.

Part 2 covers a virtual service migration demo from a vCenter and No-Orchestrator cloud account to an NSX-T Cloud account.

The project is available in my Github repository:

Repository : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator

ReadMe : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator/blob/main/README.md

Release Notes : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator/blob/main/RELEASENOTES.md

Let’s get started.

NSX ALB Virtual Service Migrator Overview

NSX ALB Virtual Service Migrator will migrate Virtual Services (and it’s dependencies – pools, poolgroups, HTTPPolicySets and VSVIPs) across NSX ALB Cloud Accounts, VRF Contexts, Service Engine Groups and NSX-T T1 gateways. Currently the below NSX ALB cloud accounts are supported:

vCenter Cloud
NSX-T VLAN cloud
NSX-T Overlay cloud
No-Orchestrator cloud

This NSX ALB Virtual Service Migrator supports the below migration scenarios for Virtual Services and dependencies within the same NSX ALB Tenant:

Migration across Cloud Accounts

Migration from vCenter Cloud Account to No-Orchestrator Cloud
Migration from No-Orchestrator Cloud to vCenter Cloud Account
Migration from one vCenter Cloud Account to another vCenter Cloud Account
Migration from vCenter Cloud Account to NSX-T VLAN Cloud Account
Migration from NSX-T VLAN Cloud Account to vCenter Cloud Account
Migration from No-orchestrator Cloud to NSX-T VLAN Cloud Account
Migration from NSX-T VLAN Cloud Account to No-orchestrator Cloud
Migration from vCenter Cloud Account to NSX-T Overlay Cloud
Migration from No-Orchestrator Cloud to NSX-T Overlay Cloud
Migration from NSX-T VLAN Cloud Account to NSX-T Overlay Cloud

Migration across VRF Contexts (Routing Domains)

Migration from one VRF Context to another in vCenter Cloud accounts
Migration from one VRF Context to another in No-Orchestrator Cloud accounts
Migration from one VRF Context to another in NSX-T VLAN Cloud accounts
Migration from one VRF Context (T1 Gateway) to another in NSX-T Overlay Cloud accounts
Migration to VRF Contexts within the same or across cloud accounts – vCenter, No-Orchestrator, NSX-T VLAN and Overlay cloud accounts

Migration across Service Engine Groups

Migration from one Service Engine Group to another in vCenter Cloud accounts
Migration from one Service Engine Group to another in No-Orchestrator Cloud accounts
Migration from one Service Engine Group to another in NSX-T VLAN Cloud accounts
Migration from one Service Engine Group to another in NSX-T Overlay Cloud accounts

Note: This NSX ALB Virtual Service Migrator supports only migration within the same NSX ALB Tenant. Cross Tenant migration is currently not supported.

Usage Instructions

Make sure that the target cloud account to which the Virtual Services need to be migrated is configured. This includes the cloud connector configuration, VRF Contexts, networks & routing configuration and service engine configuration under the Service Engine Group.

The necessary routes (default routes / static routes to the pool members) need to be available on the target VRF context before migrating the VS / Pools.

Make sure that the target cloud account / VRF context doesn’t have a conflicting VSVIP object (VIP) compared to the objects being migrated from the source cloud account. If it has, perform migration with IPAM profiles attached.

A linux VM with connectivity to NSX ALB controllers is required to perform the migration.

Install Python3 on the linux VM. On CentOS or RHEL systems, run -> yum install -y python3

Install git -> yum install -y git

Install the below python modules:
- requests -> python3 -m pip install requests
- urllib3 -> python3 -m pip install urllib3
- tabulate -> python3 -m pip install tabulate
- pandas -> python3 -m pip install pandas

Clone repository and navigate to NsxAlbVirtualServiceMigrator/V1.2/ -> git clone https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator.git && cd NsxAlbVirtualServiceMigrator/V1.2/

The migration tool has three modes:
- Migration mode -> This mode will perform migration of virtual services to same or different NSX ALB Cloud account.
- Remove Prefix mode -> This mode will perform automated removal of prefixes appended to the migrated objects. This needs to be done post cutover of virtual services.
- Cleanup mode -> This mode will perform cleanup of migrated objects incase the tool encounters an error or if post migration validation fails. This needs to be done before the Remove Prefix mode.

The migration workflow will create a tracking directory (NsxAlbVirtualServiceMigrator/V1.2/Tracker/) which has the tracking information for each job. DO NOT DELETE this directory, as this is required for cleanup and remove_prefix jobs.

Logs for each job is saved in NsxAlbVirtualServiceMigrator/V1.2/logs/

Migration mode

Run ./main.py with the “migrate” subcommand. -> python3 main.py migrate –help

This will launch NSX ALB Virtual Service Migrator help menu for the migrate mode. Follow instructions on the screen.

python3 main.py migrate -i <CONTROLLER_IP/FQDN> -u <.USERNAME> -p <.PASSWORD> -a <API_VERSION> -t <NSX_ALB_TENANT> -c <TARGET_CLOUD> -r <TARGET_VRF_CONTEXT> -s <TARGET_SERVICE_ENGINE_GROUP> -d <TARGET_APPLICATION_DNS_DOMAINS> -n <TARGET_IPAM_NETWORK_NAME> -S <TARGET_IPAM_SUBNET> -P <OBJECT_PREFIX/RUN-ID>

where

CONTROLLER_IP/FQDN -> This is the NSX ALB Controller cluster IP/FQDN [MANDATORY]
USERNAME -> This is the local “system-admin” user account to login to the NSX ALB Controller cluster. SAML authentication is currently not supported.[MANDATORY]
PASSWORD -> This is the password of the above user account to login to the NSX ALB Controller cluster.[MANDATORY]
API_VERSION -> This is the API version of the controller cluster. This is also the controller version (Eg:22.1.4) [MANDATORY]
NSX_ALB_TENANT -> This is the NSX ALB Tenant where the migration needs to be performed. [MANDATORY]
TARGET_CLOUD -> This is the target NSX ALB Cloud connector name [MANDATORY]
TARGET_VRF_CONTEXT -> This is the target VRF Context (under the target cloud connector) [MANDATORY]
TARGET_SERVICE_ENGINE_GROUP -> This is the target Service Engine Group (under the target cloud connector) [MANDATORY]
TARGET_APPLICATION_DNS_DOMAINS -> This is a comma separated list of DNS subdomains to create the application DNS records. These subdomains should be a avaialble in the DNS profile attached to the target cloud connector. [OPTIONAL]
TARGET_IPAM_NETWORK_NAME -> This is the name of the network used for VIP auto-allocation. This network should be available in the IPAM profile attached to the target cloud connector. [OPTIONAL]
TARGET_IPAM_SUBNET -> This is the subnet available on the network for VIP auto-allocation. This subnet should have IP pools defined for VIP allocation.[OPTIONAL]
OBJECT_PREFIX/RUN-ID -> This is the prefix that will be attached to the migrated objects. This prefix should be unique for each migration job as this will be used for job tracking and cleanup mode.[MANDATORY]

Remove prefix mode

Run ./main.py with the “remove_prefix” subcommand. -> python3 main.py remove_prefix –help

This will launch NSX ALB Virtual Service Migrator help menu for the remove_prefix mode. Follow instructions on the screen.

python3 main.py remove_prefix -i <CONTROLLER_IP/FQDN> -u <.USERNAME> -p <.PASSWORD> -r <OBJECT_PREFIX/RUN-ID>

This will automate the removal of prefixes attached to the migrated objects. This needs to be done after the virtual service cutover.

Cleanup mode

Run ./main.py with the “cleanup” subcommand. -> python3 main.py cleanup –help

This will launch NSX ALB Virtual Service Migrator help menu for the cleanup mode. Follow instructions on the screen.

python3 main.py cleanup -i <CONTROLLER_IP/FQDN> -u <.USERNAME> -p <.PASSWORD> -r <OBJECT_PREFIX/RUN-ID>

This will cleanup all the migrated objects if the tool encounters an error or if post validation fails.

Note: Cleanup if any, needs to be performed before running the “remove_prefix” mode.

Migration Workflow

The below flowchart depicts the migration workflow of NSX ALB Virtual Service Migrator.

What’s new in Version 1.2

NSX ALB Cloud Migrator is now NSX ALB Virtual Service Migrator
Added support till NSX ALB version 22.1.3
Added support for virtual service migration with IPAM profiles
- Supports VIP auto-allocation for the migrated virtual services based on the target cloud’s IPAM profile
- Supports migration of virtual services having IPAM profiles at the source cloud connector
- Validation checks for target IPAM networks and subnets before migration
- Supports VIP allocation based on VRF context
Added support for virtual service migration with DNS profiles
- Supports adding DNS names for the migrated virtual services based on the target cloud’s DNS profile
- Supports migration of virtual services having DNS profiles at the source cloud connector
- Validation checks for target DNS subdomains before migration
Supports virtual service cloning within the same cloud account (using IPAM profiles)

Known Limitations

The below NSX ALB features are not yet tested with NSX ALB Virtual Service Migrator and hence migration of below features may or may not work as expected. These limitations will be addressed in upcoming releases.

NSX ALB Controllers with SAML / LDAP configured. Currently only local accounts are supported
Virtual Services with VIP sharing
TLS SNI based Virtual Service Hosting (Parent – Child VS)
Enhanced Virtual Hosting (EVH)
Any datascripts with mention of pools / pool groups need to be manually updated post migration
GSLB Applications are not updated with migrated virtual services information
For NSX-T VLAN backed clouds, the placement networks for each virtual service need to be manually added. This is a NSX ALB Cloud limitation
Migration from NSX-T Overlay Cloud to vCenter Cloud succeeds but requires additional manual intervention for VIP connectivity.
Doesn’t support cross-tenant migration

References

Repository : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator

ReadMe : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator/blob/main/README.md

Release Notes : https://github.com/harikrishnant/NsxAlbVirtualServiceMigrator/blob/main/RELEASENOTES.md

Archives: https://vxplanet.com/2022/03/16/nsx-alb-cloud-migrator-v1-0-my-first-python-project/

Please stay tuned for Part 2 where we perform a demo of virtual service migration from vCenter and No-Orchestrator cloud accounts to an NSX-T cloud account using the enhancements in version 1.2

I hope this community contribution is going to be useful, please reach out to me if you like to collaborate or have any questions.

Also don’t forget to buy me a coffee if you found this post useful.