NSX-T 3.0 Design Bootcamp 1: Overview

This is my first blog in this series.  Using this NSX-T 3.0 Design Bootcamp 1: Overview, let’s start the discussion on some of the considerations and see why that is important.  Clearly, when it comes to networking and security we have two different realms 1) Physical and 2) Virtual.

It is apparent that the supremacy of the bare-metal based offerings is no more – But as a networking and security architect, it is inescapable that you should know the bits and pieces of physical networking – otherwise!!! No way that you can do well in this business and also note NSX is a software-only solution and you still need physical switches to join NSX-T transport nodes.

NSX-T Design Bootcamp part-1
NSX-T Design Reference Topology

In physical realm, you usually have ADC’s, security and routing and switching functions handled by dedicated hardware ASICs or bare metal devices. On the other hand with virtualization all these functions are offloaded to the general purpose x86 boxes. And it is imperative to understand in modern networking our objective is to do no changes at the physical infrastructure, and we should perceive the physical infrastructure as very static & stable infrastructure with no added networking complexity induced. And all your agile networking & security needs are served by your NSX-T and its associated VNF’s

As a result, whether it’s IPS, load balancer, the firewall, or even the analytics and correlation solution, essentially take all of these and you should keep close to the place workloads are being computed. For instance, in the above diagram, you could see the multilayer switching icon and firewall hosted on transport nodes, very close to the VM !!. With this, we’re essentially eliminating racks full of these discrete systems and devices

NSX-T Design building Blocks

Below is the 360 degree observation of the NSX-T and related design blocks.  And let’s walk around each of these little bit in below sections and will have in-depth looks into each of these in upcoming articles.

NSX-T Design Building Blocks
NSX-T Design Building Blocks

NSX-T Manager

It is the three-node cluster solution combining the management, control plane function.  High availability and fault tolerance are part of the software. Also just to note, the vSphere FT feature is not currently supported with NSX-T.

Transport nodes:

In a typical highly virtualization environment the server infrastructure will be mostly dominated by the hypervisors – and the hypervisors nodes hosting NSX-T functions are called transport nodes—– The hypervisors could be ESXi or variety of KVM flavors such as Redhat, Ubuntu, Suse, CentOs etc. 

Edge Nodes:

Edge nodes is where one could host all your edge functions – the edge nodes are primarily for connecting your NSX-T network to the external world. Also from design perspective, it is always better option to create separate cluster for workload and management/edge, however this is a design choice

Compute Manger:

Currently, the only the vCenter is the compute manager option with NSX-T.  Please note that the NSX-T Data Center does not support the same vCenter Server to be registered with more than one NSX Manager

Service Chaining & 3rd party integration:

NSX-T Data Center provides the functionality to insert third-party services for functions such as network security & introspection etc. However, only ESXi hosts are supported to deploy north-south or east-west service VMs. KVM hosts are not supported

Bare metal Services

To use the NSX-T Data Center on bare metal (BM) server, you must install supported third-party packages.

Physical Network:

Physical switching and routing are mainly for connecting different transport nodes and also sending traffic to outside the NSX-T network such as WAN, cloud, Internet, etc.  Apart from the physical cabling topology considerations, the routing protocol and jumbo frame supports are some of the main considerations here.

Correlation and Analytics

NSX-T intelligence is the main solution in this space which is part of the portfolio of NSX.  And the key here is to understand even though NSX-T intelligence comes with its own OVA, the NSX-intelligence UI is part of NSX-T itself – it is not separate. Also, considerations for integrating with IBM Qradar, VMware VRNI, Splunk, etc are also important.

Licensing & Cost:

There is multiple licensing models to aware of. And the features and solution will differ based on the selected licensing tier.

Cloud extension

You can deliver consistent networking and security for your applications running natively in public clouds by extending your on-prem NSX-T capability to the cloud. No more infrastructure silos to drive up complexity and operational expense. NSX Cloud currently supports Microsoft Azure and Amazon AWS, including Azure Government and AWS GovCloud (US) regions.

Disaster Recovery:

When it comes to disaster recovery, the discussion is more about how you can do NSX-T across multiple locations.  There are two options with latest NSX-T 3.0 1) NSX-T multisite and 2) Federation

Performance & Optimization:

For optimum performance, you need to consider the resource requirement for doing networking and security function with NSX-T such as DPDK, Doing GENEVE offload on the NIC and sizing and scaling the edge function, etc. And the replication mechanism considerations are also an interesting topic – we will talk about this in detail, in upcoming articles.

High Availability & FT

This is a huge design topic, the idea is to look at the HA and redundancy capability from active-active or active-standby option with the routing and L4-L7 services and also for each of the other relevant and related components form NSX-T world!!. And when it comes to FT, Here we look at some of the native features of vSphere and KVM for protecting the workload in case of any issues

Security & Compliance:

The native, east-west distributed firewalling, and north-south gateway firewalling are the key topic and additionally the load-balancer placement and considerations

Sizing and Scalability

The NSX-T managers, edge functions, compute nodes sizing, VM density across the transports are some of the considerations here

Summary and Next Steps

The design thinking process is important when you work on an optimized solution for current and future needs of your organization. This blog touch-up on various design elements to consider, hope you enjoyed the read so far – let’s start dive into more details in upcoming sessions. Also for more NSX-T related discusion please refer the section VMware

6 Comments

Add a Comment

Your email address will not be published. Required fields are marked *