In my previous Part 2 of the blog series on NSX ALB Cloud migrator, we discussed the migration scenario for virtual applications from NSX ALB vCenter Cloud account to No-Orchestrator Cloud. Now let’s do the reverse migration. ie, from a No-Orchestrator Cloud to vCenter Cloud. I am reusing the same cloud accounts and virtual applications from the previous article, hence most of the routing configurations in this article are similar to Part 2.
Let’s get started:
Use cases for migration to a vCenter cloud account:
- Leverage the full automation capabilities of NSX ALB with respect to service engine deployment and lifecycle management.
- Dynamic scaling and self healing of service engines. Automatically deploy new service engine to replace failed ones.
- Improved monitoring of service engine’s health based on vCenter metrics (pulled through API by the vCenter cloud connector)
- Dynamic vnic addition on the service engines based on virtual services and backend pools
In the current state we have a No-Orchestrator cloud account “Cloud-NoOrchestrator” which has 5 virtual services hosted. 4 of the virtual services are internal and are on the global VRF context. One virtual service is hosted on DMZ and is on a separate DMZ VRF context (routing domain).
As I am reusing the same applications from the previous article, the application properties, profiles and policies remain the same.
The below sketch shows the current state of virtual application hosting and the traffic flow to virtual services and backend pools.
For this blog post, service engines in both No-Orchestrator cloud and vCenter cloud are deployed in single arm mode. The VIP network is used for client connectivity and L3 routing to the backend pool members. The DMZ virtual service “Gateway4Guest” uses an L3 VIP with static routes to the SNAT interface for reachability.
In the target state, we have all the 5 virtual services migrated to the vCenter Cloud “Cloud-vCenter01”. As discussed in previous articles, necessary routing configurations need to be in place on the target cloud account. As we are deploying SEs in single arm mode and has got L3 VIPs with different SNAT networks, we need to enable Static routes for backend and VIP resolution in the vCenter Cloud account. The below 2 options need to be enabled.
Also, we need a static route for the VIP network with next hop pointing to the SNAT network. This is for the placement of virtual service.
The below sketch shows the target state (post-migration) of virtual application hosting and the traffic flow to virtual services and backend pools.
Now let’s use the NSX ALB Cloud Migrator tool to migrate our virtual applications to the target Cloud Account ‘Cloud-vCenter01’. As in the previous articles, we will do two runs of the tool:
- First run will migrate all the internal virtual services to Cloud Account “Cloud-vCenter01” on VRF “global”
- Second run will migrate DMZ applications to Cloud Account “Cloud-vCenter01” on VRF “DMZ”.
Run 1 – Migrating internal virtual services using NSX ALB Cloud Migrator
The procedure is exactly similar as in the previous articles except that the target cloud account to be selected is “Cloud-vCenter01“. VRF Context and Service engine group also need to be selected from the cloud account “Cloud-vCenter”
Select the Virtual Services to migrate. For this run, we will input VS-Intranet,VS-Booking,VS-FTPUploads,VS-DNS-Intranet
The tool will scan and migrate pools, pool groups, http policy sets and pools or pool groups configured in http policy sets as content switching policies.
Once all the virtual services are migrated, the session is logged off.
Run 2 – Migrating DMZ virtual services using NSX ALB Cloud Migrator
Let’s do the second run to migrate the DMZ Virtual service. The workflow is the same except that the target VRF Context to be selected is “DMZ” and Virtual service is “VS-Gateway4Guest“.
At this moment, the virtual services are successfully migrated to the vCenter cloud account. Perform a quick validation of the virtual services and plan for the cutover.
Disable the virtual service and ARP (“Traffic enabled” option in the virtual service settings) on the source cloud account “Cloud-NoOrchestrator” and enable those settings on the migrated virtual service in the target “Cloud-vCenter01” cloud account.
Let’s do the DMZ virtual service “VS-Gateway4Guest”.
Because this is a Layer3 VIP with static routing, we need to select the placement network (SNAT network)
Failure to select a placement network will throw the below error on the virtual service.
Once the cutover is complete, perform a cleanup of the virtual services in the source cloud account “Cloud-vCenter01”.
Let’s wrap up!!!
We will meet in Part 4 where we migrate virtual services from a vCenter Cloud account to NSX-T VLAN Cloud.
I hope the article was informative. Thanks for reading.
Continue reading? Here are the other parts of this series:
Introduction : https://vxplanet.com/2022/03/16/nsx-alb-cloud-migrator-v1-0-my-first-python-project/
Part 1 : https://vxplanet.com/2022/03/18/nsx-alb-cloud-migrator-part-1-virtual-service-migration-across-vcenter-cloud-accounts/
Part 2 : https://vxplanet.com/2022/07/10/nsx-alb-cloud-migrator-part-2-virtual-service-migration-from-vcenter-cloud-to-no-orchestrator-cloud/