NSX-T Management Cluster Deployment: Part 1

NSX-T Management Cluster
Deployment: Part 1
Source : Part -1 - https://shuttletitan.com/nsx-t/nsx-t-management-cluster-deployment-part-1/

Part - 2 - https://shuttletitan.com/nsx-t/nsx-t-management-cluster-benefits-roles-
ccp-sharding-and-failure-handling/
As discussed in one of my previous blog NSX-T Architecture (Revamped): Part 1,

the release of NSX-T v2.4 brought simplicity, flexibility and scalability for the
management plane. If you are not familiar with the architecture of the NSX-T, I would
highly recommend checking out both parts of the architecture blogs, along with
the NSX-T Management Cluster: Benefits, Roles, CCP Sharding and failure
handling.
As I like to split some topics of discussion, this topic is another one divided in two
parts, for easier understanding and context:
1. NSX-T Management Cluster Deployment: Part 1 (this blog) – shares the general
requirements which are common across the deployment options discussed in
Part 2.
2. NSX-T Management Cluster Deployment: Part 2 – uncovers the deployment
options and their relevant use cases.
At first, I thought about writing one blog relevant to NSX-T Management Cluster
deployment options, but there were quite a few requirements that were common
across the deployment options, which led me to split this topic in two parts. This Blog
is Part 1 and talks about i.e. general requirements of NSX-T Management Cluster:
1. NSX-T Manager deployment is hypervisor agnostic and is supported on vSphere
and KVM based hypervisors:
Hypervisor Version (for NSX-T v2.5) Version (for NSX-T v2.4) CPU Memory
Cores
vSphere vCenter v6.5 U2d (and vCenter v6.5 U2d (and 4 16

later), ESXi v6.5 P03 (or later), ESXi v6.5 P03 (or
later) later)
vCenter 6.7U1b (or later), vCenter 6.7U1b (or later),

ESXi 6.7 EP06 (or later) ESXi 6.7 EP06 (or later)
RHEL KVM 7.6, 7.5, and 7.4 7.6, 7.5, and 7.4 4 16
Centos KVM 7.5, 7.4 7.4 4 16
SUSE Linux 12 SP3 12 SP3, SP4 4 16

Enterprise Server
KVM
Ubuntu KVM 18.04.2 LTS* 18.04 and 16.04.2 LTS 4 16

* In NSX-T Data Center v2.5, hosts running Ubuntu 18.04.2 LTS must be upgraded
from 16.04. Fresh installs are not supported.
2. The maximum network latency between NSX Manager Nodes in the cluster
should be 10ms.
3. The maximum network latency between NSX Manager Nodes and Transport
Nodes should 150ms
4. NSX Manager must have a static IP address and you cannot change the IP
address after installation.
5. The maximum disk access latency should be 10ms
6. When installing NSX Manager, specify a hostname that does not contain invalid
characters such as an underscore or special characters such as dot “.”. If the
hostname contains any invalid character or special characters, after deployment
the hostname is set to nsx-manager.
7. The NSX Manager VM running on ESXi has VMTools installed – Remove or
upgrade of VMTools is not recommended
8. Verify that you have the IP address and gateway, DNS server IP addresses,
domain search list, and the NTP server IP address for the NSX Manager to use.
9. Appropriate Privileges to deploy OVF Template
10. The Client Integration Plug-in must be installed.
11. NSX Manager VM Resource requirements:
Appliance Size Memory vCPU Disk Space VM Hardware Version Support
Extra Small 8 2 200 Gb 10 or later “Cloud Service

Manager” role only
Small 16 4 200 Gb 10 or later Proof of Concepts or Lab
Medium 24 6 200 Gb 10 or later Upto 64 Hosts
Large 48 12 200 Gb 10 or later Upto 1024 Hosts
For further information on maximum configuration details please see the link here
General Best Practices:
• The NSX-T Manager VMs are deployed on shared storage

• DRS Anti-affinity rules configured to manage NSX-T Manager VMs across hosts
• When deploying NSX-T service VMs as a high-availability pair, enable DRS to
ensure that vMotion will function properly.
NSX-T Management Cluster:
Benefits, Roles, CCP Sharding and
failure handling
In versions prior to NSX-T v2.4, four appliances were deployed based on roles i.e.
one management appliance and three controller appliances, that were to be
managed for NSX. From v2.4 – The NSX manager, NSX policy and NSX controller
role were consolidated in a single unified appliance which can now be scaled to a
three-node cluster for redundancy and high availability. The desired stated is
replicated in the distributed persistence database, all configuration or operations can
be performed on any appliance:
Benefits of having a unified appliance cluster:

1. Less Management Overhead with reduced appliances.
2. Potential reduction in the compute resources required.
3. Simplified Installation and Upgrades.
4. High availability and scalability of all services, including UI and API consumption.
NSX Manager Node performs several functions and essentially there are three roles,
besides the Distributed Persistence Database:
Management Plane
Policy Role:
Provides Network and Security Configuration across the environment and is
addressed from the new “Simplified UI” for achieving the desired state of the system.
NSX Manager Role is responsible for:
• Receiving and validating the configuration from the NSX Policy (Role).
• Stores the configuration in the distributed persistent database (CorfuDB).
• Publishes the configuration to the Central Control Plane.
• Installs, manages and monitors the data plane components.
Central Control Plane
The CCP (Central Control Plane) maintains the realized state of the system and is
responsible for:
• Providing control plane functions i.e. Logical switching, routing and distributed
firewall.
• Computes all ephemeral runtime states received from the management plane.
• Pushes stateless configuration to the Local Control Plane (LCP) daemons
running on Transport node which in turn propagates down to the forwarding
engines.
For more information on NSX Agent/services communication, please refer my other

blog NSX-T Architecture (Revamped): Part 2
Centra Control Plane (CCP) Sharding
The CCP uses a sharding mechanism to distribute the load between the controller
nodes i.e. each Transport node is assigned to a single controller node for L2, L3 and
distributed firewall configuration. However, each controller node receives
configuration updates from the management and data planes irrespectively, but only
applicable information is maintained, as illustrated in the image below:
Note: The “TN1, TN2, TN3, etc.” in the Image above are the Transport Nodes.
The Transport Node to Controller node mapping is done via an internal hashing
algorithm. When a controller node fails, the sharding table is re-calculated and the
load is re-distributed between the remaining controllers, the data plane traffic
continues to operate without disruption as illustrated in the image below:
The Transport Node TN3 and TN7 are now distributed to Manager 1 and Manager 2
controller plane respectively.

NSX-T Management Cluster Deployment: Part 1

Uploaded by

Copyright:

Available Formats

NSX-T Management Cluster Deployment: Part 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NSX-T Management Cluster Deployment: Part 1

Uploaded by

Copyright:

Available Formats

NSX-T Management Cluster

Source : Part -1 - https://shuttletitan.com/nsx-t/nsx-t-management-cluster-deployment-part-1/

As discussed in one of my previous blog NSX-T Architecture (Revamped): Part 1,

vSphere vCenter v6.5 U2d (and vCenter v6.5 U2d (and 4 16

vCenter 6.7U1b (or later), vCenter 6.7U1b (or later),

Centos KVM 7.5, 7.4 7.4 4 16

SUSE Linux 12 SP3 12 SP3, SP4 4 16

Ubuntu KVM 18.04.2 LTS* 18.04 and 16.04.2 LTS 4 16

Appliance Size Memory vCPU Disk Space VM Hardware Version Support

Extra Small 8 2 200 Gb 10 or later “Cloud Service

Small 16 4 200 Gb 10 or later Proof of Concepts or Lab

Medium 24 6 200 Gb 10 or later Upto 64 Hosts

Large 48 12 200 Gb 10 or later Upto 1024 Hosts

• The NSX-T Manager VMs are deployed on shared storage

Benefits of having a unified appliance cluster:

NSX Manager Role is responsible for:

Central Control Plane

For more information on NSX Agent/services communication, please refer my other

Centra Control Plane (CCP) Sharding

You might also like