Preparing a vSphere cluster for NSX does two things:
- It installs NSX Kernel modules on each ESXi host, which is a member of the vSphere cluster
- It builds the NSX control-plane and management-plane fabric
NSX Kernel modules are packaged as VMware installation bundles (VIBs) and provide functionality such as distributed routing, distributed firewall, and VXLAN bridging.
To get ready for installation, ensure that the following prerequisite tasks have been completed:
- DNS forward and reverse names have been created for all ESXi hosts and are resolvable
- Firewall Ports between all management components are open
- vCenter Update Manager Service, if in use, is operational
- Ensure that the EAM service is operational
- Ensure that the NTP settings are checked across all ESXi hosts and are updating time correctly
Note
ESXi stateless modeIf you are using ESXi in stateless mode, you must download the NSX VIBs manually and integrate them into the host image. Refer to VMware Knowledge Base Article 2041972 (https://kb.vmware.com/kb/2041972) for more information. Download paths of NSX VIBs change with each release. To check the paths for your NSX release, use the following URL: https://<NSX_MANAGER_IP>/bin/vdn/nwfabric.properties.
Perform the following steps to start the installation of the NSX VIBs onto your first vSphere cluster; we will be enabling it on vSphere Cluster RegionA01-COMP01 to begin with:
- In the vCenter Web Client, navigate to
Networking & Security|Installation|Host Preparation - Select the vSphere Cluster
RegionA01-COMP01 - Click on the COG wheel and select
Install:
Each ESXi host in the cluster will now download the VIBs from vCenter Server, where they were downloaded from NSX Manager and cached when NSX was registered as a solution. Depending on the number of hosts in the vSphere cluster, this process will take a few minutes to complete. Once the installation has completed, you will be presented with a screen like the one shown in the following screenshot:
The following figure depicts the management, control, and data plane components that make up an NSX implementation. Each has an important part to play in enabling ESXi for the Distributed Firewall and VXLAN. In this section, we will explore the interaction among the various components:
- vCenter server: This is the management component of the vSphere environment and is where the networking and security components of an NSX environment are all managed from.
- NSX Manager: This is the management plane of the NSX implementation. It integrates directly with vCenter and manages both the NSX controller cluster and the ESXi hosts. The NSX Manager is also responsible for pushing distributed firewall rules to each host that is prepared for the distributed firewall. In addition, the NSX Manager is also the API entry point for NSX operations via the REST protocol.
- ESXi Agency Manager (EAM): This is part of the vCenter deployment; it is responsible for installing the VIBs to each of the hosts.
When you prepare a vSphere cluster for NSX, the VIBs are copied directly from NSX Manager and cached by EAM. The EAM will then track the installation of each VIB onto each host in the vSphere cluster. If the VIB is not present, it is installed without the ESXi host requiring a reboot, and if it is present, a reboot is required to complete the upgrade.
Once the installation of VIBs has been completed, each ESXi host will have active TCP connections to the NSX Manager and NSX controller cluster. The connection to the NSX Manager is from the vsfwd daemon running on the ESXi host via the RabbitMQ message bus. The connection to the NSX Controller cluster is from the netcpa daemon running on the ESXi host via an SSL connection (TCP Port 1234). It is important that both channels of communication are active and can be checked via the communication channel health from each host, which is covered in a subsequent section:
When enabling a vSphere cluster for NSX in a brownfield environment, it is important to be cognizant that any preconfigured DFW firewall rules have the potential to impact virtual machines on the newly-configured vSphere cluster. Therefore, it is extremely important to ensure that the default Distributed Firewall rule remains as allow any any. Changing to deny before defining rules for allowing legitimate traffic from/to virtual machines will cause traffic blackholing.
As a best practice, vCenter server and virtual machines that require promiscuous mode should be excluded from the DFW if you are not planning to protect them. To learn how to exclude virtual machines from the DFW, refer to Chapter 6, Configuring VMware NSX Distributed Firewall (DFW) and SpoofGuard.