Available now is the VMware NSX-T Reference Design Guide, a deployment path to adopting NSX with diverse multi-domain workload requirements – multi-cloud (private/public), multi-hypervisor, and multiple application frameworks (VMs, PaaS and containers).

 

Since VMware acquired Nicira almost five years ago, NSX for vSphere has become de-facto standard for private cloud solutions, delivering key use cases in private cloud – namely security, automation and application continuity.  Since then, we’ve witnessed our customers datacenter and workload requirements changing; therefore, the demand for a platform that not only can deliver current private cloud requirements, but now many enterprises are looking for integration with the likes of cloud native apps, public/hybrid cloud, and other compute domains covering multiple hypervisors.

VMware NSX-T Data Center was introduced last year to meet the demands of the containerized workload, multi-hypervisor and multi-cloud. The NSX-T platform is focused on a diverse set of use cases – from private to public, traditional (multi-tiered architecture) to container (microservices architecture) based apps, automation and monitoring of security at IaaS, to programmatic devops workloads in PaaS and CaaS environments.  It is very important to start with an understanding of NSX-T architecture and its components, and some topics (ex. routing) have been discussed in other blog posts (routing pt1 and routing pt2), but today we are pleased to introduce a reference design guide that delivers the best practices and common design practices associated with NSX-T platform.

Key Attributes of NSX-T Architecture

Below are some of the key attributes that make NSX-T architecture suitable for a variety of new workloads and domains:

  • vSphere agnostic yet multi-vCenter supported design
  • Multi-tenant routing with NAT & Load Balancer
  • Line rate forwarding (small to large packet sizes) via DPDK N-S Edge Node
  • Generalized container plug-in architecture
  • Multi-hypervisor micro-segmentation
  • Reduced complexity in routing configurations
  • Scale out distributed controller architecture

NSX-T Reference Design Guide

This is the first revision of the NSX-T Reference Design Guide and is aimed to deliver an architectural baseline.  Readers can expect technical details around deep packet walks for layer 2 & 3, security capabilities, and overall architecture design (ex. the design considerations for ESXi and KVM based environments).  The design chapter uses previously well adopted and understood design practices of NSX for vSphere architecture; however, NSX-T does not assume familiarity with NSX for vSphere and we treat knowledge of the platform independently.  Additionally, the design document covers the deployment guidelines of the bare metal edge node, as well as cluster design covering multi-VC ESXi deployment (including KVM only design).  As more customers deploy the NSX-T architecture and as new features get introduced to the platform, we will continue to update the document (for example, NSX-T 2.1 release supports platform load balancer) to provide design guidance.

Containers and Container Networking for Network Engineers

In addition to the design guide, we are also sharing a container whitepaper covering the container related ecosystem from a technical standpoint, where we discuss a majority of the various offerings in this space – our goal is to provide guidance and education for any networking and security reader to get familiar with overall landscape, and then through that lens, understand the need for the development of NSX Container Plugin (NCP), which we will discuss briefly below.

There are two constants VMware is seeing with our customers in the enterprise that are looking at containers:

  1. Contrary to early perception – containers don’t replace VMs, rather containers are co-existing with BM and VM. This drives the need for consistent networking and security across all along with policy and visibility
  2. The commercial manifestation of container technology usually comes with some form of tools/provisioning/operational framework.  The goal is to uniquely interface with each (ex. Kubernetes, Pivotal Cloud Foundry) such that the provisioning of networking, security and automation becomes part of those tools directly, and not something that’s stitched together after the fact.  This alleviates the IaaS element provisioning into PaaS consistently and instead embeds as part of lifecycle of the PaaS infrastructure

Our goal with NSX is to provide native container networking.  More specifically, the ability to assign a unique IP address per container, the ability to provide routing services to the container, etc. which in the end, leads to a model where containers are promoted and treated the way administrators and operations handle VMs today.  Ultimately, this results in a single NSX network fabric that supports bare-metal, containers, and virtual machines communicating at layer 3.  This type of native container networking is absent from most of the CaaS and PaaS platforms that we mentioned earlier; therefore, in order to enable integration and abstraction across multiple platforms, we developed the NCP (NSX Container Plugin).

Lastly, for customers that are looking for more details beyond containers and want to learn more about some of our cloud offerings, you can now find detail on how NSX-T applies to cloud centric architectures by heading on over to NSX Cloud services, which are part of other cloud services offered by VMware.

 

Get hands on NSX-T experience!

We’ve heard our customers loud and clear.  These requirements for multi-cloud, multi-hypervisor, and multi-app frameworks are simply becoming table stakes driving many of their latest IT projects.  If you’re like me and prefer learning more by taking the hands-on approach, you’re in luck!  The latest NSX-T Hands-on Labs are available in the Hands-on Lab catalog… and don’t forget to let us know why you choose to #RunNSX