Compute, Storage, and vSphere Infrastructure

Before you deploy the NSX Managers you first need to determine what the underlying infrastructure is. Sometimes you have the luxury that the underlying Compute, Storage, and vSphere Infrastructure is not deployed yet, and with this, you will be able to shape your design better based on the requirements.

The recommended way of designing and deploying vSphere is to separate your Management and domains (and clusters). Your workloads and applications are a more dynamic environment that might need other operational rules and different rules around availability, manageability, performance, recoverability, and security. By separating Management from Workload, you do not put all your “eggs” in the same basket. This means that if there is an issue with one environment this will not impact the other.

You can deploy NSX on:

1. A vSphere Collapsed Cluster

2. Separated Management and Workload vSphere Clusters with multiple NSX Implementations

3. Separated Management and Workload vSphere Clusters with a single NSX Implementation

Let me go through the three options in more detail.

A vSphere Collapsed Cluster

One way of deploying NSX is by doing this on top of a Collapsed vSphere Cluster. This means you are performing the following actions using a single vSphere Cluster:

1. Deploy the NSX Manager Nodes on the cluster (managed by a single vCenter Server)

2. Deploy the Virtual Edge Transport Nodes on the cluster

3. Prepare the Host Transport Nodes (part of the cluster) with NSX

In Figure 1 you will see the illustration of what this looks like. By only looking at the picture you immediately see that this all is one big failure domain.
When you place your management components on top of Host Transport Nodes that are prepared for NSX and your Host Transport experience an issue with NSX this means you cannot log in to the NSX Manager to “fix” things from the management plane, and your domino effect of other issues is inevitable.
For this reason, you would only design and implement your NSX infra when you have limited (host) resources available in a development or test (Proof of Concept) environment.

Figure 1:

When you have more (host) resources available, and you only want to deploy one vCenter server you can always choose to deploy multiple vSphere Clusters (see Figure 2):

• Management vSphere Cluster
  • Here you deploy all your management components like your vCenter Server and your NSX Manager Nodes.

• Edge vSphere Cluster
  • Here you deploy the Edge Transport nodes.

• Workload vSphere Cluster
• Here you deploy your workloads (applications).
• The Host Transport Nodes in this cluster would be prepared for NSX.

With the use of only one vCenter Server managing your Management, Edge, and Workload environment this is still a bit risky when you look at it from an operations perspective, but much better than using one single vSphere Cluster for everything.

You can also use multiple vCenter Servers in your deployment to fully separate Management from the workload environment.

Figure 2:

Separated Management and Workload vSphere Clusters with multiple NSX Implementations

When using multiple vCenter Servers you can fully separate the Management from the Workload environment. Figure 3 will illustrate that you have multiple NSX deployments where one is dedicated to the Management environment and the other to the workload environment.

By splitting the NSX deployments you can now use all network and security services that NSX has to offer also within the management environment without affecting the workload environment or vice versa. One of the main advantages is that you can configure Distributed Firewall Rules on the management and workload environment without one can impact the other.

In Figure 3 you will see that we have split the management and workload environment, but the Virtual Edge Transport Nodes are still hosted on the same clusters as the (application) Workloads. In Figure 4 I have also split this to make a more robust design.

Figure 3:

Figure 4:

Separated Management and Workload vSphere Clusters with a single NSX Implementation

When you do not want to use the NSX network and security services in the management domain it is still good practice to separate the Management and Workload environments with different clusters and vCenter Servers.

Figure 5 is like Figure 3 with the exception that the Management environment does not have an NSX implementation for itself. The same applies to figure 6 and Figure 4.

Figure 5:

Figure 6:

Continue with the next section >> NSX Managers