NSX Components - The Basics

TIP: If you are a Networking professional, the odds are you don’t know much about Web services, and RESTful API everyone is mentioning all the time is your confusion point. REST has gained widespread acceptance across the Web as a simpler alternative to SOAP and WSDL-based Web services. RESTful systems communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.

NSX uses the Management plane, Control plane, and Data plane models. Components on one plane have minimal or no effect on the functions of the planes below. The functional diagram presented in the VMworld 2014 is presented below:

Consumption Model, as a self-service portal and the Cloud management. vCloud, OpenStack or vCAC platform can be integrated with the NSX Management plane via REST API.

Management Plane: Serves as the main point of configuration and includes the REST API for third-party applications that integrate with NSX and UI interface. NSX Manager is the only component of this plane, and it integrates directly as a Plug-In into the vCenter. The Management Plane talks to the Control Plane to initiate the changes, and its components are:

•     vCenter Server,
•     NSX Manager, talks to the NSX Controllers
•     Message Bus, way that these thigs communicate, not the VM but the function.

NSX Manager, which is the only thing you deploy as the Administrator as a virtual appliance. It’s an .OVA file, which can be downloaded, at this moment still only from the Nicira page. All the other components are sequentially deployed. It will later act as the Management Interface for the NSX. It receives instructions from vCenter, RESTfull API, but it’s NOT in the Data Plane. You should deploy ONE Manager per vCenter (this is a current version limitation, and if you have various vCenters be aware that the NSX Managers wont talk to each other). If you shut down the Manager, there is no impact to the service. You need 4 CPUs and 12GB of RAM with 60GB of Storage. It’s highly recommended to have a separate Management Cluster, in order not to mix your Management plane components with the control plane. 3 Hosts are usually enough, you don’t need a huge Management Cluster. NSX Manager acts as the Management interface for NSX. It can receive the instructions from:

•         vCenter
•         RESTful API
•         Other Cloud Management Platform

NSX Manager is completely out of Control and Data plane, and it can be shut down, and THE SERVICES CONTINUE, there is no down time; there is just no management layer. You need to protect it using the vSphere HA.

Control Plane: Manages Logical Networks, but doesn’t sit in the data path. The logical router control virtual machine handles routing network relationships. This virtual machine gives the routing table to the NSX Manager instance.

NSX Control Plane is the component that actually performs the changes, telling the Router and the Firewall what to do and etc.

•     NSX Controllers that do Logical Switching, ARP Broadcasts, VXLAN support etc.
•     UWA (User World Agent), which gets installed on each vSphere and control the actual correspondence between the Controller and the Data plane (ESXi hosts).
•     Logical Router Control VM is the components in charge of the Routing Tables and other control functions.

NSX Controllers are the Control Plane of NSX, and they are deployed in ODD number of sets (most common number is 3 to avoid Split Brain because the 2 that agree on the config fail the 3^rd one when it’s different, or 5 because they use VOTING and an IP pool for IP Addressing assignments) from the vCenter interface done by the manager. You need to deploy them in a Cluster arrangement. These provide VXLAN “directory services”, such as MAC and ARP and VTEP table. There is no Broadcast traffic and no dependency of Multicast for VXLAN Functionality. Controllers handle the “roles” and an ELECTION is held to find a Master, which is a new controller. NSX Controllers represent the Control Plane of the NSX, and unline the NSX Manager – the architecture cannot work without these. They are deployed in the Cluster Arrangement (ODD numbers, because they use Voting Quorum), and they provide several VXLAN directory services (MAC, ARP, VTEP table), and it removes the dependency on Multicast.

Remember that the NSX controllers are NOT in the Data Path, but if they fail the Control Plane might start giving problems. From the NSX Manager you can deploy the Controllers, and all must be in the same vCenter.

Roles of the NSX Cluster:

-        VXLAN functions.

-        Distributed Router.

-        An election is held to determine the Master.

-        Every Job is divided up in to SLICES (spread across available nodes).

-        Data is MIRRORED, so when one controller from the cluster failes – the data is automatically used from the mirror.

NSX Controller interaction is through CLI, and configuration operations are available through NSX API. NSX Controller stores four types of tables:

•         The ARP table
•         The MAC table
•         VTEP table
•         Routing table

NSX Controller uses the UWA (User World Agent) daemons to communicate from the hosts management address. The UWA includes two daemons that run on the host. The UWA is responsible for communication between NSX Controller and ESXi host for layers 2 and 3, and for VXLAN communications.

Data Plane: The distributed switch (VDS) defines the Data Plane. The distributed switch does only Layer 2 switching. Hosts have to be on the same layer 2 networks so that virtual machines on each host can communicate with virtual machines on the other host.

NSX Data Plane - the things that move bits, actually doing the work, and there are 3 big components:

•     Kernel Modules, such as VXLAN, and Distributed Routing and Firewall functions
•     vSphere Distributed Switch (VDS), which handles all the L2 Switching Functionalities.
•     Edge Service Appliances, which handle the NAT, VPN and other Edge services.

Be sure not to confuse the Distributed Firewall and the EDGE Services Router:

-        The Distributed Router in the hypervisor handles East-West traffic routing.

-        North-South traffic (to the External Networks/Other Data Centers) flows through the NSX Edge services router.

There are only a few components, they are all VIRTUAL, and the issue is correctly integrating them. NSX installs three vSphere Installation Bundles (VlB) that enable NSX functionality to the host. One VlB enables the layer 2 VXLAN functionality, another VlB enables the distributed router, and the final VlB enables the distributed firewall. The basic components of the NSX Ecosystem are:

Workload Slicing (Slicing Method) is used to spread the workload. The concept is to divide every Job into Slices, so when the new controller is added – slices need to be redistributed. NSX Manager deploys the Controllers. Each one has 4 CPUs, and 4GBs of RAM. You need controllers to be deployed in same vCenter that NSX manager is talking to.

Host Kernel Extensions for some features, and User World Agents (UWA), which does the communication between the Controller and the Host.

Network Service Appliances:

•     Edge Service Gateways
•     Distributed Router Controllers

Security and Authentication: It’s all protected using SSL. In the entire communication between the Manager and the Hosts, and there is a mutual authentication. NSX Manager creates certificates and stores them in a database. NSX Manager pushes these certificates to the NSX Controller instances as they are deployed.