NSX for vSphere, what a cool new shiny technology to start blogging! I guess this is one of those topics that you can easily write hundreds of posts; that said the intention of this series is to cover the installation and configuration aspects of NSX for vSphere, touching all the available features. So let’s get started with a high level introduction 🙂
Warning: at the time of writing this post I haven’t had a change to implement NSX on production environments yet 🙁 however I’ve attended the official 5 days ICM class which has given me a good understanding of the product, after which I thought to start a series on NSX.
Capabilities
NSX, formerly Nicira NVP (Network Virtualization Platform) is doing to networks what we’ve been doing to servers for years: abstract the physical layer from the logical one, in other words, virtualise the network in such a way that all you end up with is software running on the top of your hypervisors which can be programmatically and dynamically configured and updated. In this series I will only cover NSX for vSphere, however NSX is also available for other platform such as Xen or KVM. Ok, gotcha, so what capabilities does it provide to my datacentre?
In summary:
- Logical L2 switching, extending the traditional L2 physical fabric
- Distributed routing, by which we mean routing between subnets without traffic going out (read north) to the physical router
- Distributed firewall, which enables security enforcements at either the kernel or vNIC level
- Logical load balancing, supporting L4 through L7 load balancing with SSL termination
- SSL VPN services, for L2 virtual private network
Mmm…. sounds a lot of stuff and not too crystal isn’t it!? Don’t worry I will cover every single feature and how to implement them throughout the series.
Planes
NSX is built upon three different planes, each having minimal or no effect on the functions of the planes below it, and above all a consumption stack. This diagram is taken from NSX Installation and Upgrade Guide 6.1 official guide.
Data Plane
A classic distributed switch only works at L2 and VMs need to be on the same L2 subnet to communicate. NSX provides new functionalities by installing three VIBs modules at the kernel level so that they hypervisor is capable of the following:
- VXLAN encapsulation
- Distributed logical routing
- Distributed logical firewalling
After these three VIBs are added to the distributed switch it is then referred as a “VMware NSX Virtual Switch”. The forth component, which is not a VIB, is the NSX Edge Services Gateway, which I’ll cover more in detail later on.
Because NSX leverage VXLAN encapsulation, the L2 boundary above-mentioned no longer exists. I will not cover VXLAN in this series so if you’re new to it or want to have a good understanding of VXLAN (which I think you should) Vyenkatesh Deshpande has written a very good primer on VMware vSphere Blog, starting with VXLAN Series – Different Components – Part 1
Control Plane
This plane manages logical networks and runtime states. As the name suggests, it’s controlling (or supervising) the data path where I/O actually happens.
There are three main components:
- NSX Controller: is the central control point for all logical switches within a network and maintains information MAC, ARP and VTEP tables.
- Logical Router Control VM: it’s a virtual machine that is instantiated to handle routing tables information and pass it to the NSX Manager. Why? Because the NSX Virtual Switch does not generate nor handle routing control plane traffic therefore this VM acts on behalf of it.
- UWA (User World Agent): ntcapd and vsfwd daemons running on the ESXi host. Acts as “gateway” or effectively it proxies the communication between NSX Manager and NSX Controller
I know diagrams help when it comes to new concepts so here’s one that summarises what I just described:
NSX Controllers are deployed from NSX Manager as a virtual machine, in odd numbers (3, 5, 7). The main reason for this is to avoid split brain scenarios. The algorithm behind the scenes is Apache ZooKeeper a distributed coordination service for distributed systems (originally developed by Yahoo!).
A ZooKeeper cluster requires a majority to function and it’s best achieved using an odd number of servers. On NSX Controller five roles are available:
- Logical Manager computes policies and network topologies
- Switch Manager pushes the settings to each ESXi host
- Directory Server takes care of the VXLAN and DLR databases (Distributed Logical Routing)
- API Provider provides web-services API consumed by NSX Manager
- Persistence Server ensure data preservation across nodes for data that can’t be lost
The most important points to remember about the NSX Controller are:
- The NSX vSwitch running on ESXi intercept ARP requests, broadcast and unicast traffic from the virtual machines and get answers by querying the NSX Controller; (ARP suppression)
- ESXi populates the NSX Controller cache through UWA (User World Agent). This is a daemon running on ESXi ( /etc/init.d/netcpad )
- Each role requires a master
- A master election determines the NSX Controller instance that is the master for a particular role
- Different roles can have the master running on different hosts
- The NSX Cluster if fully functional when a majority of nodes is active
- Through a “Slicing” process, the workload is distributed across all the available controllers and this allow for workloads redistribution (scale-in&out) as well as failures
Management Plane
NSX Manager communicates with a vCenter Server system and is the interface for the NSX APIs for 3rd party applications that integrate with NSX. The NSX Manager is installed as a virtual appliance on any ESX host in your vCenter Server environment
Consumption Model
CMP aka Cloud Management Platform. The consumption of NSX can be driven directly through the NSX Manager UI, which, in a vSphere environment, is the Web Client. Typically end users tie network virtualisation to their CMP for deploying applications. NSX provides rich integration into virtually any CMP through REST APIs. Out-of-the-box integration is also available through vCAC (vCloud Automation Center now vRealize Automation), vCD (vCloud Director) and OpenStack with the Neutron plug-in for NSX.
So we have an idea of the components, let’s have a look at the resources you would need to get NSX up and running on your own lab, which I’ve covered in the post NSX for Newbies – Part 2: Home lab for NSX
10 Trackbacks