written by Billy Downing
The intention of either solution
NSX product suite, whether T or V, is meant to provide a software-defined network fabric for which virtual machines, containers, and bare metal assets can consume. NSX offers the ability to instantiate tangible network services such as load balancing, NAT, VPN, extended layer 2 networks via overlays, distributed firewalling for micro-segmentation, and IPAM all through software. This gives operators the agility needed to provision resources on a per-application basis without having to re-architect their environment by adding hardware into the data plane. NSX affords engineers the abstraction from their physical network infrastructure to simplify the underlay network while still providing complex solutions over the top. NSX also provides a means for deeper integration into the virtual machine or container environment. This creates objects directly in the kernel of the hypervisor or deploys container network interface compliant pods (specific to NSX-T) that translate more granular control over traffic flows. Traffic flows like service chaining and visibility translate into flow patterns. Overall, NSX (both T or V) provides a suite of tools to easily operate a network utilizing a common set of tools that are defined by software, quick to change, and effective in their implementation.
Reasons to Migrate
If either solution provides all the tangible benefits, why chose one over the other? For context, NSX for vSphere, or NSX-V, was around first. It was meant as a solution that directly integrated into vSphere through vCenter connections. NSX-V was meant for a vSphere-centric world when the idea of ‘hybrid cloud’ or agnostic vendor selection was less of a priority. Due to that mindset, NSX-V was limited in its capabilities for expansion outside of vSphere. New environments required a level of flexibility that NSX-V could not provide. Next came NSX Data Center, or NSX-T. Built from the ground-up, NSX-T provides the same overarching benefits of NSX-V as described above but adds flexibility in what and how it manages systems. Rather than relying on proprietary VIBs installed directly in the ESXi kernel, or utilization of the virtual distributed switch, NSX-T takes on constructs of abstraction by creating new objects and managing more openly distributed tools. Tools like Open vSwitch and the like. This means NSX-T can manage objects outside and totally independent of vSphere. NSX-T can manage KVM hosts, containers, vSphere, and cloud objects all at the same time. Here is a list of direct benefits of NSX-T over NSX-V (this is not a comprehensive list).
NSX-T Benefits
- Disaggregated from vCenter
- Manages multiple vCenters at a given time
- Can manage KVM hosts through open vSwitch
- Edge nodes can run on bare metal to improve performance
- Ability to integrate directly into the Kubernetes container environment through NCP (NSX Container Plugin)
- Aggregation of control and management planes into a single 3 node cluster (less management VM’s)
- Ability to create federated controllers by the site for multi-site management
- Enhanced security capabilities that are continually improving, such as IDP/IPS and Layer 7 functionality
- Ability to integrate with advanced load balancer capabilities using the NSX Advanced Load Balancer (AVI networks acquisition)
- Declarative API driven management
– This provides several benefits, such as robust SDKs, Terraform providers, PowerCLI tools and so on
Most importantly NSX-T has VMware’s engineering focus. This is made apparent in VMware Cloud Foundation’s 4.0 release and subsequent VMware Validated Designs (VVDs) where NSX-V is removed even from the management cluster (or management workload domain for VCF). In the end, NSX-T provides numerous benefits over NSX-V mostly spawning from its independence from vSphere as a solution and its modular approach.
Types of Migration
Generally, there are two types of migration from NSX-V to NSX-T. Each is held accountable to the requirements above. In either case, the overall goal is to build an NSX-T environment ‘somewhere’ and use the built-in migration coordinator to import NSX-V configurations, to finally migrate data plane objects.
- In-place migration using the same platform
– In this scenario, the NSX-T control cluster is deployed on the same hardware as the NSX-V manager and control cluster. Additionally, the same ESXi hosts running NSX-V will be prepared by NSX-T as Transport Nodes. This is the case where NIC availability and resource contention becomes important
– This option is enticing as it does not require any additional spend or management effort for new equipment. It comes at the cost of complexity and increased risk of impacting the existing environment - A new platform in place to migrate
– Here, there is a new set of hardware to provide as a platform for NSX-T as the target zone for the migration. The NSX-T control cluster can still be deployed alongside the NSX-V control components. The nodes controlled by NSX-V will not be prepared or managed by NSX-T. Only the new nodes within the system will be a part of the NSX-T fabric.
– This method provides the cleanest migration path with reduced risk of impacted the existing environment during setup but comes at the cost of requiring new equipment to support.
Big Picture
Prerequisites
Now that we have set the scene and gone over the benefits and longevity of NSX-T, we need to start considering migration steps away from NSX-V.
- Understanding the terms within NSX-T Compared to NSX-V
– ESG’s become Edge Transport Nodes hosting T0’s and T1’s
– DLR’s become either T1’s or T0’s. Each of which has their own respective Distributed Router (DR) and Services Router (SR)
– Logical Switches become Segments
– Host Preparation become applying host profiles to transport nodes
– VXLAN becomes GENEVE (totally different overlay protocols) - Knowing the supported topologies/features for migration. Here’s a list of supported features: VMware Docs for NSX-T 2.5.
– Subsequently, remove any features that are unsupported. OSPF is a good example of this as NSX-T only supports static routing or BGP. - Becoming familiar with, as they apply, Migration Coordinator limitations listed here: migration coordinator limitations
- Verify running support software for migration
– NSX-V 6.4.4 or newer
– vDS version 6.5 or newer - Availability of NICs for NSX-T to prepare as TEPs (NSX-T will own these NICs and must not be associated with an existing vDS or vSS)
- The capability of deploying the resources required for NSX-T
– 3 Management/Control nodes
– 1 Edge node per ESG (2 Edge nodes per ESG in High Availability)
High-Level Process Flow
Refer to the resources for version-specific instructions or commands.
- Verify Perquisites are met.
- Build a new NSX-T Environment based on one of the two typical migration methods
– It is important to note that this environment ought to be a greenfield deployment of NSX-T and not used for any production services as during the migration all edge node interfaces will restart therefore impacting any services that may be utilizing them.
– Deploy edge nodes from OVA and not from the manager because the manager would need to configure whereas we want the migration tool to take care of that portion.
– Connect the existing vCenter to be migrated to NSX-T as a Compute Resource to gain inventory insight into the environment.
– Outside of deploying the controller cluster with edge nodes and connecting the vCenter as a compute resource all other work will be done by the Migration Coordinator. - Enable the migration coordinator.
– This is done through the CLI in NSX-T Version 2.5 and is disabled by default for resource conservation. - Import the NSX-V configurations to NSX-T to run against a verification checklist.
– During this process, it is likely there will be several errors in the existing environment. This is the opportunity to mitigate any issues before moving forward. This portion of the migration is simply importing and verifying the configuration can be migrated to the NSX-T environment. - Resolve any problems during the migration pre-checks.
- Migrate the configuration.
– This portion builds the actual constructs within the NSX-T environment that will sync IP groups, DFW rules, segments, and so forth. - Migrate ESG’s to NSX-T Edge Nodes (North/South traffic and Services)
– Here the migration tool configures each Edge Node based on the NSX-V ESG buildouts. - Migrate VM’s and hosts.
– Hosts are prepared for NSX-T by having the vDS interfaces released from NSX-V and attached to a newly deployed N-VDS - Verify functionality.
– Run application-specific testing to ensure all assets are functioning as expected within the new environment.
Overall, there are several guides and resources walking step-by-step through the process but, are typically version-specific. Here we discussed not only the general process flow and prerequisites but more importantly, some reasons why migration is necessary in the first place.
Resources: