Sit Right Back and You’ll Hear a Tale
A very important, and sometimes underappreciated, area of vSphere design is the humble cluster. The cluster is a fairly well understood concept. After all, it’s just a grouping of ESXi hosts, right? Well, yes, however you need to consider carefully the types of clusters that will satisfy your design requirements.
Most vSphere designers understand that there are good reasons to separate production from non-production (i.e. development or prototyping) workloads. It follows then that a Production and Non-production cluster meet these needs by restricting these workloads to their appropriate group of hosts. It has also become quite common to dedicate a cluster to Management workloads.
Management workloads typically include vCenter Server, vCenter Operations Manager, Active Directory, DNS, DHCP, etc. Basically any workloads that support infrastructure and whose interruption would cause issues for workloads responsible for business services. Separating these types of workloads allows for various benefits:
Explicit separation of maintenance windows so that Management workloads remain available while workloads in other clusters are being addressed.
Ability to have very clear separation of roles and duties in order to ensure that only those administrators with the proper authorization can attend to the Management workloads.
Resource isolation to ensure that any resource contention among business service workloads doesn’t impact Management workloads, as that would in turn affect all workloads.
If our cluster design were to follow these guidelines, then we might now have a collection of clusters that resembles the diagram below.
This cluster design should satisfy the majority of your workload requirements. Infrastructure and management workloads are placed in the Management Cluster, development and test workloads in the Non-Production Cluster, and all production workloads in the Production Cluster. But how to you handle a set of outlier workloads? Workloads that, due to various reasons, shouldn’t or can’t belong to one of these standard clusters?
The Weather Started Getting Rough
The term Island Cluster was coined within the VMware architecture and design community. It represents any separate vSphere cluster created to support workloads that need to be segregated from the existing clusters. Island Clusters are typically smaller in size as they are purpose built and likely have a limited number of VMs.
As a rule of thumb you want to make sure that your workloads belong to the established clusters within your design, in order to take full advantage of the benefits clusters provide. Segregating workloads into an Island Cluster isn’t a light decision to make and should be treated as an exception to the clustering rule.
So what situations or criteria could provide enough justification for you to consider an Island Cluster?
Strict security requirements that necessitate an enhanced separation between workloads. For example some organizations will not tolerate DMZ and production workloads co-existing on the same host or cluster.
King of Monster VMs may need to rule their own island. Extremely resource intensive workloads may perform best, and impact other workloads the least, if isolated on their own cluster. This could be especially true if there are significant vCPU allocation variations among your workloads. Make sure that your performance testing bears this out before considering it.
Licensing, which is the most common reason to consider Island Clusters. You may want to constrain OS licensing by building clusters dedicated to particular platforms, such as one cluster for Windows Server and another for your favourite licensed Linux distribution. Application licensing constraints tied to server resources are a favourite.
The keen reader has likely already figured out that the Management Cluster mentioned earlier is a type of Island Cluster. In that case a separate cluster was created for both resource and security reasons. If those reasons didn’t exist, then those workloads would be placed in the Production Cluster along with the other production workloads.
Now that we have an idea of the types of things to consider when deciding to design an Island Cluster, how do we determine what that cluster should look like?
This Uncharted Desert Isle
As we discussed earlier, Island Clusters are typically purpose built and smaller in size than your traditional clusters. Expect most clusters to contain only two or three hosts. Of course all clusters need at least two hosts, however if you require high availability for your workloads, even during scheduled maintenance, then it’s recommended that you dedicate at least three. That way you can have two hosts running while you perform maintenance on the third. Otherwise, follow the same guidelines that you normally use when sizing a cluster.
One consideration that may make your Island Cluster hosts look different from the rest is if you need to constrain physical resources. Why would you do this? Most often in response to licensing constraints. Some application vendors tie their licenses to hardware resources. In these cases if we don’t consider an Island Cluster then we may be spending much more than necessary. Let’s use Oracle as a working example.
Oracle licensing is notorious for tying licenses to the total number of CPUs available on the server hardware. In the case of a vSphere cluster, that would mean having to count every core of every processor on every host within the cluster. There is then a CPU multiplier value that Oracle supplies that you have to take into account.
Let’s assume that within your design you have to make sure that you can virtualize the four existing Oracle database servers. For the purpose of simplicity, they’re all standalone, RAC is not in use. Each server currently has two Intel four core processors. Our current Production Cluster has four hosts with two Intel eight core processors.
Okay, so our Production Cluster exceeds the system requirements of the Oracle database servers. Option one is to virtualize the Oracle servers and place them in the Production Cluster. No resource constraints and no security concerns. What does this mean for our licensing?
Turns out that simply virtualizing our existing Oracle database servers into our current Production Cluster doubles the licenses we require. Now what if we were to consider building a dedicated Island Cluster. Let’s call it the Oracle Cluster. We’ll select two hosts with two Intel six core processors. What would our licensing look like then?
Subject to some performance testing to verify that our Oracle database workload needs are being met, we’ve just reduced our Oracle database licenses and potentially justified the use of an Island Cluster.
The specifics of this example are, of course, hypothetical. They do illustrate the fact though, that through careful consideration and diligence in measuring against our requirements, Island Clusters have a place in our designs.
A Three Hour Tour
In summary, Island Clusters can address the outlier workloads that don’t fit into your standard cluster design model. They can save you grief or relieve some pressure on your company’s purse strings. They should, however, always be considered very carefully and treated as a design exception. You need to make sure that your VMs behave like happy holidayers on their island and not forgotten castaways.
![VMware Explore 2022: A New Dawn [Day 2]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277173084%2F27aa6c63-c1ff-4df5-8074-7bf666ef46fd.jpeg&w=3840&q=75)
![VMware Explore 2022: General Session Live [Day 3]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277115028%2F62e1ebe4-7d09-46a8-8ac6-aca2c17e2487.jpeg&w=3840&q=75)
![VMware Explore 2022: The More Things Change [Day 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1737277227689%2Fe6cdc90f-c453-4673-afb3-9dba59700e47.jpeg&w=3840&q=75)
