Let’s continue our virtual service migration scenarios with the NSX ALB Cloud migrator, this is Part 2 and let’s migrate our applications from an NSX ALB vCenter Cloud account to a No-Orchestrator cloud account.
The migration tool, release notes and usage instructions are available in my Github repo at:
Use cases for migration to a No-orchestrator cloud account:
- Customer requirements where the service engines should not be tied to any infrastructure provider and allow migration of service engines across infrastructures (for eg: from one vCenter to another)
- Scenarios where the cloud infrastructure is not supported for write access (like VMC on AWS)
- Corner case scenarios like requirement of guest vlan tagging in the service engines etc.
- Security policies that doesn’t approve API write requests from external service accounts to vCenter server.
In the current state we have a vCenter cloud account “Cloud-vCenter01” 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).
The below table shows the description of Virtual Services, their pools / pool groups, reachability, policies and profiles.
The below sketch shows the current state of virtual application hosting and the traffic flow to virtual services and backend pools.
Service engines are currently deployed in multi-arm mode with L3 reachability to backend pools which are not L2 adjacent. Migration of virtual services is not dependent on the routing topology but on the front end and backend reachability. This means that the target service engines can use L2 adjacency, L3 routing with static or BGP configuration.
In our list of virtual services, all the internal ones are L2 adjacent but the DMZ virtual service uses L3 VIP with a different SNAT network based on static routing. The equivalent routing is already done on the service engines in the No-Orchestrator cloud. Routing configurations depends on scenarios and customers, and is out of scope of this article.
In the target state, we have all the 5 virtual services migrated to the No-Orchestrator cloud account named “Cloud-NoOrchestrator“. Similar routing configuration as in the source cloud account is done with the service engines in No-Orchestrator cloud except that they operate in single-arm mode (just for simplicity of this blog post, because we just need connectivity to the front end and back ends). DMZ will still be on Layer 3 VIPs with a different SNAT network for backend.
In a No-Orchestrator cloud, service engines are deployed and configured manually. As such, the necessary interface IPs, VRF contexts and routes are added manually.
Just FYI, the No-Orchestrator cloud account is configured to use Static routes for backend reachability (for this blog post), hence the service engines will operate in a single arm mode.
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-NoOrchestrator’. We will do two runs of the tool:
- First run will migrate all the internal virtual services to Cloud Account “Cloud-NoOrchestrator” on VRF “global”
- Second run will migrate DMZ applications to Cloud Account “Cloud-NoOrchestrator” on VRF “DMZ”.
Run 1 – Migrating internal virtual services using NSX ALB Cloud Migrator
Start the NSX ALB Cloud Migrator as per the usage instructions in my Github repo or in the introductory article:
Provide the NSX ALB controller URL, admin user (local only) & credentials, NSX ALB tenant and controller version information. Wait for successful authentication.
We will be presented with the list of cloud accounts, select the target cloud account to migrate our virtual applications to. In our case, it will be ‘Cloud-NoOrchestrator‘
We will be presented with the list of VRF Contexts available in the selected cloud account, select the target VRF Context to migrate our virtual applications to. For this run, it will be ‘global‘
We will be presented with the list of Service Engine Groups (SEG) available in the selected cloud account, select the target SEG to migrate our virtual applications to. In our case, it will be “SEG-Intranet-Apps-VC02“
Next, we will be presented with the list of Virtual Services available in the logged in Tenant. 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 selected VS’es for attached pools, pool groups, http policy sets and pools or pool groups configured in http policy sets as content switching policies. Enter a unique suffix for the run. All objects migrated will have this suffix for identification.
Now, the tool will migrate pools, pool groups and HTTP Policy sets of the selected virtual services.
The tool will next migrate pool groups and pools that are directly associated to virtual services.
The tool will next migrate VSVIPs of selected virtual services.
Finally, the tool will migrate all the selected virtual services in this run and will logoff the session.
At this moment, we should see our internal virtual services migrated to the “Cloud-NoOrchestrator” cloud account.
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“.
Now that the DMZ Virtual service has also been migrated successfully to the target cloud account, perform a quick validation of the migrated objects and schedule the application traffic cutover.
Perform a migration validation as mentioned in my previous article (Part 1). Disable the virtual service and ARP (“Traffic enabled” option in the virtual service settings) on the source cloud account “Cloud-vCenter01” and enable those settings on the migrated virtual service in the target “Cloud-NoOrchestrator” cloud account.
Let’s cutover the DMZ virtual service “VS-Gateway4Guest”.
Depending on the routing configuration in place, we may need to put the placement subnet under the virtual service. Since the DMZ VIPs are Layer3 with static routes, we require placement network and lets put the SNAT network as the placement network.
Let’s wrap up and meet in Part 3 where we do the migration in the reverse direction. ie from a No-Orchestrator cloud account to a vCenter cloud account.
I hope the article was informative. Thanks for reading.
Continue reading? Here are the other parts of this series: