Solutions
Migration from NSX-V to NSX-T
Migration from NSX-V to NSX-T
Migration to NSX-T is dictated by closing to the End of General Support of NSX for vSphere or NSX-V which is 16th of January 2022.
What this means is the end of general support: NSX-V will be supported but no features, bugs or new version will be released. Following VMware previous versioning and customer satisfaction, it might be that VMware will release some patches in case of mass issues. VMware usually does not just drop their customers. However, migration shall happen no later than January 16th 2023, there will be no support at all, again this might be not the case, depends on the impact and how many customers are migrated already.
Many organizations start looking at how to migrate from NSX-V to NSX-T. There are two main preferred methods or approaches to migrating from NSX for vSphere to NSX-T Data Center, and those are:
- In parallel migration
- In place migration
Let’s go briefly over those migration methods
What is in place migration from NSX-V to NSX-T?
In this approach, NSX-T is installed on the same hardware where NSX-V resides. The best practice is to have a non-used cluster where NSX-T is installed so it does not mix with NSX-V. NSX-T comes with a built-in tool that supports this method of migration. The tool is called Migration Coordinator. The coordinator exports all configs and applies them to NSX-T. There are hard pre-requisites to use migration coordinator:
- NSX-V must be healthy and stable
- NSX-T must not have any workloads (this might change over time)
- Not all configuration is supported (NSX-T edges must not be configured, dual uplink will not be migrated, etc.)
Some 3rd party tools do migration as well and they have their own limitations.
What is in parallel migration from NSX-v to NSX-T?
In this approach, NSX-T infrastructure is deployed alongside the NSX-v infrastructure, but on new hardware. Within Parallel migration two mainstreams are most common:
● Lift and shift to new infrastructure (a.k.a Pets)
● New infrastructure first. All new workloads are deployed on the hardware where NSX-T is installed. Old infrastructure let to reach the end of support
This is commonly used method of migration comes from the cloud. (link to cloud migrations). Why it is coming from the cloud: the main reason was to move customers as soon as possible to the cloud. Cloud Providers have direct busses benefit of this migration and sometimes this is not in the customer’s favour. VMware migration coordinator introduced on NSX-T 3.1.1 promising more options. One of the options is called modular migration where rules are migrated from the NSX-v to NSX-T. Some 3rd party tools can do the same, but it complicates the process. An example, we decided to migrate application A, this application was residing on NSX-v to NSX-T. Application A is segmented, and all rules are applied based on constructs and objects that exist only in NSX-v. Application A has traffic going to application B, but Application B will not be migrated.
Lift and shift
To succeed with lift and shift, during the migration the 3rd party tool must convert objects available in NSX-v to objects in NSX-T. Converting objects between two different platforms are not possible in a 1:1 relation. Hence 3rd party tools must replace some of the NSX-v objects with NSX-T objects. Application B will be converted to raw IP address part of a new security group. If the NSX-v applies to the field that was used, then all the applications to the field will be converted as well to raw IP. What if applied to filed used against a cluster in NSX-v? Well, all the VMs in that cluster must be reassigned as IPs in NSX-T. When application B is moved to a new NSX-T then IPs from the new environment must be removed.
The complexity of changes, objects between NSX-T and NSX-V must be in sync. If a change happened in one of the environments, the other must be updated as well. In other words, achieving lift and shift is a very difficult task with 3rd party tools. Operational wise, lift and shift become a nightmare. Keep two environments in sync are almost impossible and if it’s possible only for the very small environments.
Firewall rules are hard to maintain on a daily basis especially in dynamic environments. Housing keeping is one of the most overseen tasks.
Do we really want to move all garbage with us?
The oblivious answer is no. Having a new environment in place and migrating from NSX-V to NSX-T, gives the organization a chance to clean up rules and make it right this time. The winning strategy is to transfer brownfield environments to greenfield environments. It is way easier to create rather than migrate. In our case, create network infrastructure and firewall rules (segmentation / micro-segmentation). By using AutoNSX organizations can achieve redesigned stable environment with the following approach:
- Deploy all networking and connectivity on NSX-T. Deploying NSX-T networking is straightforward there is no need for actual migration from old NSX-v to NSX-T except in the cases where hundreds of edges are deployed.
- Migrate workloads to NSX-T via vMotion
- Segment Applications as greenfield using AutoNSX (there is no need to migrate old rules)
AutoNSX gives organizations the ability to build and deploy micro-segmentation of the entire Datacenter in a matter of hours. While open and change window during less busy hours (weekends, over the night) and publish all needed segmentations rules and redesigning their NSX-T, to meet new demands and not depend on old NSX-V absolute design.
With this approach migrations from NSX-V to NSX-T become a very simple task. Most of the sync updates and object transfer are not needed. In the end, you will receive complete design, new infrastructure and cleaned up absolute rules.
What to know more? Contact us today and we will give the exact workflow of migration from NSX-V to NSX-T. If you don’t have a design, our VCDX experts can make one right for your need.