With the release of Windows Server 2019, there have been some pretty exciting improvements to both hyper-converged and cluster technology in general. With Windows Server 2016 and Storage Spaces Direct, Microsoft introduced the first major step into software-defined storage and being able to run virtual machine workloads on top of this new software-defined storage.
However, there were certain limits to Storage Spaces Direct in Windows Server 2016 and the mobility of virtual machines between clusters. With Windows Server 2019, as mentioned, certain limitations have been removed that allow even more flexibility, resiliency, and scalability in running production virtual machine workloads on top of Storage Spaces Direct and Hyper-V.
Let’s take a look at Windows Server 2019 Cluster Sets Improved VM Mobility to see how this new Storage Spaces Direct and Cluster functionality allows Hyper-V virtual machines to be better able to transition between multiple environments without losing resiliency.
Windows Server 2016 Storage Spaces Direct Limitations
As we know, Windows Server 2016 was the introduction of hyper-converged technology into the Windows Server platform, allowing software-defined storage to be truly possible with the Windows Server platform. Storage Spaces Direct allows aggregated locally attached storage in multiple servers to form logical, software-defined storage across the cluster hosts. Storage Spaces Direct successfully integrates the storage features and functionality into the Windows Server cluster platform itself with the ability to manage, provision, and configure storage from the Windows Server platform. Storage Spaces Direct or S2D allows using more commodity class hardware locally attached to the server itself for running production workloads. This can save on costs and flexibility in the overall solution.
However, there have been certain limitations with the initial iteration in Windows Server 2016 of Storage Spaces Direct technology. In a Hyper-V stretched cluster in Windows Server 2016 you could have 64 hosts in total. However, this does not improve resiliency. Additionally, you could not install the File Server Role along with a Hyper-V server running on top of Storage Spaces Direct since there was a limitation of being able to use the UNC pathing structure due to the Cluster Shared Volume unified path that is presented to the file system, located at c:\clusterstorage.
With both of these limitations, using interesting configurations with Windows Server 2016 and Scale-out File System to create more resilient configurations was just not possible.
However, this has changed with Windows Server 2019 with the new Cluster Set technology.
- What are cluster sets?
- How do they improve resiliency and mobility of virtual machines?
Windows Server 2019 Cluster Sets
First of all,
What are cluster sets in Windows Server 2019?
The new cluster set in Windows Server 2019 is a new cloud scale-out technology that allows increasing cluster node count in a single software-defined datacenter. It allows aggregating together multiple Windows Server Failover Cluster hosts into a logical set of clusters. This opens up a multitude of new functionality in thinking about Hyper-V virtual machines and their mobility across the infrastructure.
This creates the opportunity for the following advantages when grouping clusters together into the cluster set:
- Allows greatly increasing the scale by being able to combine multiple Windows Server Failover Cluster hosts into a logical grouping and at the same time keeping the fault domains intact with each single cluster
- Migrate virtual machines easily across clusters which allows fluidity across the environment by enabling the ability to much more easily retire and introduce new clusters into the aggregated cluster set fabric
- It allows easily bringing in new compute resources into the cluster set fabric which enables changing the compute to storage ratio easily
- Allows a high level of granularity when configuring fault domains in the environment
- Different generations of CPU hardware can be mixed and matched into the same cluster fabric. It allows lessening the challenge and effect of bringing in new hardware at a later time than current cluster hosts
The cluster set is made possible by configuring a cluster head that serves as a unified namespace which aggregates the cluster namespaces together into a single environment.
When considering the benefits of the Windows Server 2019 Cluster Set, there are certainly advantages to being able to aggregate additional clusters together into the same fabric. What are the considerations and potential use cases with cluster sets in Windows Server 2019?
Windows Server 2019 Cluster Sets Considerations and Use Cases
Let’s now take a look at the considerations that need to be made when implementing Windows Server 2019 cluster sets as well as the potential use cases for the technology.
First of all, it is good to consider questions that need to be asked to determine whether cluster sets are a good fit for your environment.
Cluster sets may certainly be a solution to consider if you have the following:
- You are at the limits in scaling your current HCI environment. You may have run into compute or storage limits
- You may have a different compute or storage that is not the same
- You have the need to Live Migrate virtual machines between clusters
- You would like to configure Azure-like compatibility sets and fault domains across multiple clusters
- If you have multiple HCI clusters deployed, you may currently look at available resources across your clusters to decide where a virtual machine needs to be housed
The above considerations lead to a good discussion on the various use cases for Windows Server 2019 cluster sets. There are three main reasons to consider using cluster sets in your infrastructure – scalability, resiliency, and VM mobility.
Let’s look at each of these three and see how cluster sets solve these very real business and technology problems.
When thinking about scalability and a single hyper-converged cluster, when you run out of either compute or storage resources, your options are fairly limited without major impact on production workloads. It can prove to be tricky to add storage to a Storage Spaces Direct cluster as you have to be careful to add the same make, model, and firmware drive as the other drives contained in the HCI cluster. If you are doing this perhaps two years later, it can be a challenge to find the exact same drives. Rebuild times of the S2D cluster storage need to also be taken into consideration.
Memory slots may be full in current hosts, so simply adding new RAM to existing hosts may not be relevant or possible.
When adding additional compute nodes, you have the similar considerations as when you add additional storage as in the hyper-converged model, compute and storage are connected. This may lead some to provisioning an entirely new S2D cluster and migrating workloads to the new cluster for added capacity.
All of these options may not make sense from a fiscal standpoint and may not represent the most efficient approach to take when considering increasing the scale of the environment.
Cluster sets allow you to simply aggregated clusters together into the cluster set fabric. This allows making use of compute or storage on a different cluster and aggregating these resources together without making additional hardware purchases.
What about resiliency?
Let’s see how a cluster set is superior from a resiliency standpoint.
When thinking about resiliency and comparing the cluster set with a traditional hyper-converged cluster, the cluster set allows aggregating resiliency of each cluster together. If you simply scale up a large Storage Spaces Direct cluster, your resiliency does not scale with the numbers. In a 16-node Storage Spaces Direct cluster, if you lose 4 hosts your cluster data will not be available. However, if you have (4) 4-node clusters in a cluster set, you can lose up to 2 nodes in each cluster and your data will still be available. This provides a much more resilient approach than configuring a single large Storage Spaces Direct cluster.
What about the mobility or fluidity of Hyper-V virtual machines?
In thinking about moving virtual machines between traditional S2D clusters, this was not especially easy as you can’t Live Migrate virtual machines between clusters. The cluster serves as the boundary for Live Migration. This presents difficulty when thinking about the mobility, lifecycle, and fluidity of virtual machines between environment resources.
With cluster sets, however, you can Live Migrate virtual machines between clusters as this effectively removes the boundary to VMs only being Live Migrated between cluster hosts. When Live Migrating virtual machines between cluster sets, this only Live Migrates the compute and not the storage. However, storage can be moved between cluster sets as well.
It also allows utilizing different CPU generations between cluster sets for VMs that are moved between clusters. The CPU compatibility feature can be used to allow successful migration between different CPU generations.
The new Windows Server 2019 cluster set technology takes the capabilities of Storage Spaces Direct to the next level by aggregating multiple Windows Server Failover Clusters into a single logical cluster. This provides many tremendous benefits to scalability, resiliency, and VM mobility. By easily allowing clusters to be aggregated, scale can be scaled with each new cluster that is added to the cluster set. This negates the complexities involved with upgrading existing compute or storage. Cluster sets allow aggregating the resiliency of each individual cluster to the cluster set instead of having the limitation of the resiliency being limited to one large Storage Spaces Direct cluster. VM Mobility is greatly improved when using cluster set.
By using the cluster set, Live Migrations can happen between clusters and even between different CPU generations. This allows easily migrating production workloads between clusters to perform maintenance or even decommission a Windows Server cluster.