The software-defined data center is made possible by virtualization the key components and functionalities of the datacenter. This started of course with virsualizing compute with the initial virtualization wave.
Next, was the virtualization of the network components. VMware’s NSX-V platform has made tremendous waves in the software-defined data center and has allowed organizations to be truly freed from the underlying hardware network components for data center communication.
VMware’s NSX product has certainly matured over the last several releases with the latest release by the VMware being, NSX-T 2.1. In this blog, we will walk through
- How is NSX-“T” compared to NSX-“V”?
- What are the use cases for each version of NSX? and,
- Architecture changes between NSX-V and NSX-T
VMware NSX-V vs NSX-T Comparison
To understand the use case for NSX-T let’s think about the requirements for NSX-V which would help us to see where NSX-T fits into the VMware SDN ecosystem.
Requirements of NSX-V
NSX-V (NSX for “vSphere”) is designed for vSphere deployments only and is architected so that a single NSX-V manager platform is tied to a single VMware vCenter Server instance. The NSX-V platform is the original NSX platform that has been around for a few years now.
It is specifically designed with VMware virtual machines in mind as that is the legacy virtualization mechanism for workloads that has been around since the onset of server virtualization.
With NSX-V, organizations are able to mobilize network connectivity between virtual machines and allow those workloads to be connected in ways that were otherwise unable to be delivered efficiently by physical networking hardware.
For the most part, if you are wanting to run a software-defined networking infrastructure within the realm of VMware vSphere, NSX-V is the platform that you are most likely to be using.
What is NSX-T and what use case does it serve?
NSX-T (NSX “Transformers”) is designed to address many of the use cases that NSX-V was not designed for, such as the multi-hypervisors. NSX-T is a multi-hypervisor aware SDN stack brought to the likes of vSphere, KVM, OpenStack, Kubernetes, and Docker.
It is designed to address emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. One of the major use cases for NSX-T is with containers. In today’s virtualization, we are seeing more and more applications are running in environments outside of virtual machines.
Important as well when considering the multi-hypervisor support is the fact that NSX-T has been decoupled from VMware vCenter Server. NSX-T is a standalone solution for vCenter and vSphere environments but it can also support KVM, public cloud, containers, and can also be integrated into frameworks like Red Hat OpenShift, Pivotal, and others.
One of the major shifts in focus you will see when comparing the two products is that NSX-T is more cloud focused with forward looking functionality.
It also allows organizations more flexibility in choosing the solution that best fits their use case whether that is including hypervisors, containers, bare metal, and public clouds.
VMware NSX-T is integrated with the VMware Photon Platform which is the cloud centric operating system that VMware developed from the ground up with the likes of the current vCenter server running atop this platform. NSX-T also contains the NSX-T Container Networking interface (CNI) plugin that will allow developers to configure network connectivity for container applications that help deliver Infrastructure as a Service
Architecture Changes
Interestingly, with NSX-T VMware has moved over from the VXLAN based encapsulation that is utilized by NSX-V, and has adopted the newer “Geneve” encapsulation. This architectural difference makes NSX-T and NSX-V incompatible at the moment.
What is the Geneve encapsulation standard as opposed to the more prevalent VXLAN, especially when there are a lot of hardware devices on the market that supports VXLAN?
Geneve is a newly minted encapsulation co-authored by VMware, Microsoft, Red Hat and Intel. Geneve combines the best of the current encapsulation protocols such as VXLAN, STT, and NVGRE into a single protocol. Much has been learned from current network virtualization protocols and as NSX has matured, the need for an even more extensible encapsulation protocol has come to light. Geneve allows inserting metadata as TLV fields which can be used for new features as needed.
Other NSX-T Architecture changes to note:
- Decoupled from vCenter
- NSX-T Manager and NSX-T controllers can be deployed as VMs on either ESXi or KVM
- There is a new “hostswitch” that is utilized for multi-hypervisor support. This is a variant of VMware vSwitch and Open Virtual Switch for KVM
- Utilizes Geneve encapsulation – MTU of 1600 is still recommended for the encapsulation header
- Routing changes – NSX-T utilizes next-generation optimized routing that is multi-tiered with logical separation between the provider router (Tier0 router) and the tenant router function (Tier1 router)
- Standard HTML5 interface for configuration and management
Thoughts
VMware NSX is certainly evolving, especially with the introduction of VMware NSX-T. VMware is showing commitment to the NSX platform moving beyond simply vSphere environments and including KVM, Openstack, and multiple public clouds. This decoupling from vSphere will certainly attract others to VMware’s ever popular network virtualization platform. There are several key points to note with NSX-T including the following.
Key Points of Interest with NSX-T
- Designed to work with multiple hypervisors (ESXi and KVM currently)
- Does not rely on vCenter
- Tiered routing
- HTML5 interface is standard
- Openstack plugin allows developers to build and interact with Infrastructure as Code
- Geneve encapsulation protocol
It will be interesting to see how VMware handles the two product lines between NSX-V and NSX-T and if the two products will remain separate or VMware will attempt to bring both together at some point in the future.
Cloud0ps 