Back in 2013, VMware released its Software Defined Network offering, NSX for vSphere. Since then the product has matured greatly, been updated with many features and allowed for multiple integrations with other products, being within the VMware suite or third-party.
However, due to the constantly evolving world of IT, application requirements are changing, and new solutions are needed to keep up with an ever-demanding market. The three main drivers that constitute this shift are:
- Delivery times of applications. Developers are under great pressure to deliver applications as quickly as possible. This requirement drives developers to use public clouds or open source technologies, which allow them to speed up the process.
- Diversity. It shouldn’t matter what type of workload is used, and where it is used. Ideally, there should be a single place to manage the workloads and allow for the consumption of required services.
- Cloud deployments. Hybrid cloud, multi-cloud, or just cloud – you need to be able to get to it, whether the goal is to protect against a disaster, allow applications to scale in times of congestion or migrate existing applications from the on-premises data centre to the cloud completely.
In order to satisfy these requirements, it is important to provide a robust networking and security solution that can provide connectivity and protection to any workload, regardless of its resting place. This is where NSX-T comes in. As a solution designed from the ground up to support diverse workloads deployed on a variety of hypervisors residing in on-premises data centres as well as in the cloud.
Planning for NSX-T
As NSX for vSphere was not designed for the use cases described above, customers who are using NSX for vSphere will need to migrate to NSX-T. It is also important to note, that NSX for vSphere is scheduled to go End of Support in January 2022, which means that eventually, regardless if the additional features are needed, migration to NSX-T will be inevitable.
There is a fantastic quote that can be applied to the migration process – “give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Planning is everything and this no different (perhaps even more important) when it comes to an NSX migration. So before starting the actual migration consider the following steps:
- Discovery – find out what the actual use cases for NSX-T are, even if the answer is to just simply future proof your environment.
- Proof of Concept – deploy NSX-T in the lab deployment.
- Training – understand your way around NSX-T, it is after all, very different than its predecessor.
- Co-exist – run both versions of NSX together and figure out operational implications of the new solution.
- Prepare for migration – schedule maintenance windows, backup your environment, plan for accidental rollback.
- Migrate – move your workloads to the new environment and validate they are working as expected.
There are three general approaches to migration from NSX for vSphere to NSX-T. The decision for which one to choose will be dependent on a multitude of factors specific to your environment. However, the most important ones to consider are – acceptable downtime and available capacity. Below are more in-depth descriptions of the main migration methods.
In this approach both NSX versions, (NSX for vSphere and NSX-T) co-exist in the environment. Depending on the types of workload, ‘disposable cattle or precious pets’, they can either age out in NSX for vSphere and be rebuilt as new workloads in NSX-T or they can be migrated. The observed balance in typical data centre is at around 80 percent cattle and 20 percent pets.
It is important to note that NSX for vSphere and NSX-T cannot run on the same hypervisor at the same time. As we install NSX per vSphere Cluster, that means that one vSphere Cluster equals one NSX version. If there is only one vSphere Cluster in the environment, it will need to be split into two vSphere Clusters to allow for co-existence. If the vSphere Cluster does not have enough ESXi Hosts in it to provide required availability (to run two vSphere clusters each managed by different NSX), or does not have enough resources to justify splitting a single vSphere cluster , in-place migration leveraging NSX-T Migration Coordinator will need to be used.
The co-existence approach supports the use of Cloud Management Platforms like vRealize Automation, Openstack and vCloud Director. The last two can share the same vCenter.
This involves the deployment of a new environment, on new hardware, or hardware ‘borrowed’ from the old environment. In this scenario you can design and build the entire NSX-T solution, and once you are ready, migrate the workloads to NSX-T. Maintenance windows need to be taken into consideration as migration can take a considerable amount of time, which could equate to a considerable amount of downtime. This is especially true in cold migrations where workloads are shut down, migrated to a new environment, and brought back up again. To minimise downtime warm migration would be recommended where networking between environments is stretched. Using NSX Layer 2 Bridges or VMware HCX between NSX-V and NSX-T deployments can be used to minimise downtime.
3. In place migration with Migration Coordinator
This is an excellent in-place solution that will allow you to re-use existing hardware by swapping the managing solutions from NSX for vSphere to NSX-T. It is a great option if there is limited or no budget for new hardware or there are not enough resources to split the vSphere Cluster. It provides an easy to follow UI “step by step” approach and minimises the Data Plane outage on both ESXi and Edge levels. It also has a built in Migration Check to ensure successful migrations. However, there is a lot to consider, as it is a very complex process to migrate from one product to another. The fact that this option even exists is impressive.
In order to leverage Migration Coordinator there are some pre-requisites:
- Install NSX-T (Migration Coordinator is a tool built into NSX-T)
- Install NSX-T Edges (but do not configure them)
- Provide a TEP pool for Edge Nodes
- Create Compute Manager pointing to the vCenter connected to NSX-V
- Ensure NSX-V is in a stable healthy state with no pending changes since no changes are allowed during the migration phase
- Minimum NSX-V version is 6.4.4
- Soft limit of 64 ESXi Hosts recommended
Supported networking topologies:
- ESG with High Availability and L4-L7 Services
- ESG with ECMP
- ESG with ECMP + ESG with L4-L7 Services below it
- ESG with ECMP + One-Armed Load Balancer below it
- VLAN-Backed Micro-Segmentation
Unsupported NSX features when migrating from one product to another:
- Guest Introspection
- Network Introspection
- Endpoint Protection
- Cross-vCenter NSX with Universal Objects
- L2 Bridges
- OSPF North of ESGs
- SSL VPN
- Layer 7 firewall
- Identity Firewall
- NSX Data Center for vSphere with a Cloud Management Platform, Integrated Stack Solution, or PaaS Solution
A full list of what is and isn’t supported while using Migration Coordinator can be found here:
To summarise, this is a good time to consider the migration from NSX for vSphere to NSX-T. The tools and documentation are available and many customers have already successfully migrated to NSX-T. NSX for vSphere is planned to be end of service by January 2022, which gives you ample amount of time to start the conversations and prepare for the switch.
Ready to start the conversation? Xtravirt have a wealth of experience and knowledge in network virtualisation solutions and technologies including the VMware NSX products and also have achieved the VMware Master Services Competency for network virtualisation. If you need help on this journey, get in touch https://www.xtravirt.com/contact-us/