Skip to Content

Designing a 2 Node VMware Cluster

We are going to take a look at a very hot topic when it comes to virtualization, and that is the VMware 2 node cluster.  We’ll learn about when we should use it, as well as the design considerations you need to keep in mind.  Fun fact, my first VMware design ever was a 2 node vSphere cluster!

Why use a VMware 2 node cluster?

There are many reasons to use a 2 node cluster.  One of the scenario I come across all the time is for remote and branch offices.  Another is just a small business who doesn’t need a lot of capacity and runs just a few servers.  

Some have a business need to isolate a specific application.  Last but not least is to have a rescue cluster on hand in case of a ransomware attack.

Designing a 2 node vSphere Cluster

No matter why you’re building a 2 node vSphere cluster, there are some important things to remember when you are designing it.

The main purpose of a two node cluster is to provide hardware failure protection.  This reduces the risk of having a single node deployment.  If one node fails, then the virtual machines will restart on the surviving node.

This means our sizing activities become very important.  We need to make sure that we do not use the capacity of more than one host, or we will see degraded performance after failover.

We want to size everything to fit on a single host.  The second host is just our insurance policy.

One other thing to think about is the operational impacts of this cluster, especially if you are designing it for a small business client, or a remote site.

Remember, there are two very important external connections for most vSphere clusters – networking and storage.  Of course, you will need two switches wherever you deploy this cluster for networking redundancy.

There is a very interesting design decision to be made when it comes to storage.  Local storage is not an option if we want one host to pick up for another, since vSphere clusters need to have shared storage.

Of course, we can go buy an external storage array, but that adds cost and operational complexity to the configuration.

Hands down my favorite way to solve this problem is to use a vSAN 2 node cluster.

What is a vSAN 2 node cluster?

A vSAN 2 node cluster can be handy for any number of use cases.  Did you know you can have a 2 node vSAN deployment?  Many don’t realize this because of the way they may be using vSAN in a larger environment.

In the case of a 2 node vSAN cluster, we can deploy the vSAN witness appliance or a physical vSAN witness host.  Personally, I prefer the appliance model for simplicity, but VMware supports both configurations.

VMware has an excellent guide to walk you through deploying a 2 node vSAN cluster.

The big thing when it comes to vSAN is of course making sure you are using a supported configuration by checking the VMware Compatibility Guide.

vSAN does have some networking dependancies, which is why deploying a pair of switches along with. your hosts is essential.  There’s no point in even bothering to deploy a two node cluster if they are connected to a single switch.  Remember, we want to design for multiple failure scenarios.

The big thing to think about is latency between the 2 node cluster, and the witness appliance or host.  The requirement is to keep it under 500ms round trip.

Be sure to take a look at the full vSAN 2 node cluster design guidance here.

Final Thoughts

The 2 node VMware cluster model has many practical applications and use cases.  One of the most important thing to consider when looking at this deployment model is to keep things simple.  

vSAN is a great way to simplify storage, and can be deployed in a 2 node model.

The other big consideration is sizing.  Remember you want all of your workloads to fit on a single node in the cluster, so you do not have performance issues after a hardware failure.  

This sizing also accounts for operational activities like putting your host into maintenance mode to do vSphere upgrades.

One last suggestion is to try to keep the configuration uniform across sites.  Standardize on a specific server configuration when at all possible to make operations more simple.