NSX ALB Cloud Migrator – Part 3 – Virtual Service Migration from No-Orchestrator Cloud to vCenter Cloud

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

Current State

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.

Target State

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.

Traffic 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”.