NSX Architecture & Manager
In order to move data traffic and manage the network there are three different types of planes working on any device. These three different types of planes are as follows:
- Management Plane
- Control plane
- Data Plane
Management plane: Management Plane are those who are responsible for management traffic of any device .It helps in configuration and management of any network device. Management plane instruct control plane, to enable control plane to provide support for data plane traffic.
Control Plane: Control plane is used to make data traffic flow from source to destination , It is the control plane who build 2 MAC address table at Layer 2 or Routing table at Layer 3 with help of various routing protocol like OSPF, EIGRP, BGP etc. Control plane supports data plane, all the Routing table are present in RIB table of Network device.
Data Plane: When RIB is populated, the content of RIB is copied to FIB table which is used by Network device to forward traffic, with the help of data plane any network device send the traffic at exit interface after consultation of FIB.
In short, Management plane instruct the network device “what “it will be doing, Control plane says “how “ it will is going to perform or do that and finally data plane is used by network device to perform or execute the operation.
NSX Architecture is also composed of the three above planes, the following are the NSX main components which are based on three planes and are well shown in below figure:
The component of NSX are:
- NSX Manager
- NSX Controller
- NSX vSwitch
- NSX Edge Service Gateway
NSX Manager: NSX manager is in Management plane of NSX. In NSX vCenter communicates with NSX manager via HTTPS (SSL, TCP Port 443).
NSX Controller: NSX Controller along with Distributed Router Control VM is present in NSX Control Plane. The NSX Controller contains the Layer 2 Control plane and with the help of Control VM it also able to handle Layer 3 Control Plane.
NSX vSwitch: It is present in NSX Data plane, and is integrated in kernel code of ESXi host. It is used to handle logical switch, Distributed Logical Router, and Distributed Firewall. This switches receives the Layer 2 and Layer 3 control plane information from NSX controller and also receives the security information directly from NSX Manager.
NSX Edge: It is the virtual appliance used to provide service like IPSEC VPN, NAT, and Load Balancing as these service are not available to NSX vSwitch. This appliance work in Layer 2, Layer 3 and Layer 4 state full firewall and it never communicated with NSX Controller.
NSX manager performs the following task when deployed:
- It installs Network & Security vSphere Web Client plugin
- It installs the NSX components in control and data planes.
- It autogenerates the certificates in order to do secure communication with NSX Components
- It pushes the configuration to NSX Controller, distributed router Control VM, NSX Edge and vSwitch.
- Via NSX API it provides external access for management and configuration
- Via vSphere Web Client user interface, it provides access for management and configuration.
Whatever configuration needs to be done in NSX Domain is done by NSX Manager and then it contact all other component to apply and execute those configuration.
NSX Manager can be deployed via OVA file by vSphere Web Client provide by VMWare and it requires following system configuration:
- 4 vCPU for Normal deployment and 8vCPU for Larger deployment
- 12 GB Memory for Normal deployment and 24 GB for Larger deployment
- 60 GB for disk space.
It is recommended that NSX manager should always be deployed in cluster which is configured with DRS and HA.
NSX verification can be done by two method:
- NSX Commands: used to make changes in NSX manager
- NSX central Commands: Provides information about state of NSX components.
NSX Manager Base Configuration:
A single NSX Manager will always communicates with Single vSphere and vice versa, this is also called as Standalone mode, however if you want to do cross vCenter NSX, vCenter version must be 6.0 or higher.
vCenter is required because NSX Manager does not acknowledge any ESXi Cluster. So NSX Manager Integration with vCenter is required once NSX Manager is deployed. Once this integration is done, NSX Manager starts seeing vSphere infrastructure inventory such as host, vDS. With this integration, it also helps to install Network & Security plugin in vSphere Web Client due to which we can manage the NSX Manager via vSphere Web Client.
The following option need to be configured while configuration of NSX Manager on Manage Appliance Setting:
- Syslog Server
- NTP Server
- NSX Manager IP setting
- SSL Certificates for external connectivity to NSX Manager
- Backup & restore NSX Manager
- NSX Manager Update
- Integrate NSX Manager with vSphere
Cross vCenter NSX:
With Cross vCenter NSX, we can use two or more NSX manager and up to 8 , and each one is associated with its own vCenter , centrally managed and exchanging Management Plane information with each other.
In this method, one of the NSX Manager is configured as primary and rest all are manually configured as secondary. Cross vCenter NSX integration helps to extend some NSX feature among multiple environment manages by separate vCenter but maintains single point of management via primary NSX Manager.
Cross vCenter deployment scenarios:
- Multi-vCenter cloud deployment environment
- Application to be deployed across multiple vCenter
- VDI environment
- Scaling up of virtual environment beyond limit of single vCenter
- Also helpful in dynamic DR scenarios.
Following are the responsibilities of Primary NSX Manager:
- It assigns the secondary role to other NSX Manager
- It configures and deploy all NSX services provided to VM of its associated vCenter
- It configures all NSX services in VM in vCenter associated with secondary NSX Managers.
- It configures and deploy all universal NSX services provided to all VM in all vCenter
- Configures universal controller cluster where all secondary NSX manager controller cluster needs to be removed.
All cross vCenter NSX features are configured via Primary NSX Manager which in turn replicates them to all secondary NSX Manager via a service called NSX universal synchronization service, However secondary NSX manager cannot make changes to any cross vCenter NSX features however NSX feature that are local to vCenter continue to be done by NSX manager which is paired with corresponding vCenter.
In case, Primary NSX manager is unavailable, any secondary NSX Manager can be manually premed to primary.