New Features of Windows Server 2022 Failover Clustering

Greetings again Windows Server and Failover Cluster fans!!  John Marlin here and I own the Failover Clustering feature within the Microsoft product team.  In this blog, I will be giving an overview of the new features in Windows Server 2022 Failover Clustering.  Some of these will be talked about at the upcoming Windows Server Summit.  One note that I will say is that this particular blog post will not cover the new features for Azure Stack version 21H2.  That is another blog for another time.

So let's get this started.

Clustering Affinity and AntiAffinity

Affinity is a rule you would set up that establishes a relationship between two or more roles (i,e, virtual machines, resource groups, and so on) to keep them together. AntiAffinity is the same but is used to try to keep the specified roles apart from each other.  In Azure Stack version 20H2, we added this and now brought it over to Windows Server as well.  In previous versions of Windows Server, we only had AntiAffinity capabilities. This was with the use of AntiAffinityClassNames and ClusterEnforcedAntiAffinity.  We took a look at what we were doing and made it better.  Now, not only do we have AntiAffinity, but also Affinity.  You can configure this new Affinity and AntiAffinity with PowerShell commands and have four options.

  1. Same Fault Domain
  2. Same Node
  3. Different Fault Domain
  4. Different Node


The below doc discusses the feature in more detail including how to configure it.

Cluster Affinity

For those that still use AntiAffinityClassNames, we will still honor it.  This means, upgrading to Windows Server 2022


AutoSites is another feature brought over from Azure Stack .  AutoSites is basically what it says.  When you configure Failover Clustering, it will first look into Active Directory to see if Sites are configured.  For example:


If they are and the nodes are included in a site, we will automatically create site fault domains and put the nodes in the fault domain they are a member of.  For example, if you had two nodes in a Redmond site and two nodes in a Seattle site, it would look like this once the cluster is created.


As you can see, we will create the site fault domain name the same as what it is in Active Directory.

If sites are not configured within Active Directory, we will then look at the networks to see if there are differences as well as networks common to each other.  For example, say you had the nodes with this network configuration:

  • Node1 = with subnet
  • Node2 = with subnet
  • Node3 = with subnet
  • Node1 = with subnet

We will see this as multiple nodes in one subnet and multiple nodes in another.  Therefore, these nodes are in separate sites and it will configure sites for you automatically.  With this configuration, it will create the site fault domains with the names of the networks.  For example:


This will make things easier when you want to create a stretched Failover Cluster.  Please note that Storage Spaces Direct cannot be stretched in Windows Server 2022 as it can be in Azure Stack HCI.

Granular Repair

Since we just mentioned Storage Spaces Direct, one of the talked-about features of it is repair.  As a refresher, as data is written to drives, it is spread throughout all drives on all the nodes.


When a node goes down for maintenance, crashes, or whatever the case may be, once it comes back up, there is a “repair” job run where data is moved around and onto the drives, if necessary, of the node that came back.  A repair is basically a resync of the data between all the nodes.  Depending on the amount of time the node was down, the longer it could take for the repair to complete.  A repair in previous versions would take the extent (block of data) that is normally 1 gigabyte or 256 megabytes in size and resync it in its entirety.  It did not matter how much of the extent was changed (for example 1 kilobyte), the entire extent is copied.

In Windows Server 2022, we have changed this thinking and now work off of “sub-extents”.  A sub-extent is only a portion of the entire extent.  This is normally set at the interleave setting which is 256 kilobytes.  Now, when 1 kilobyte of a 1-gigabyte extent is changed, we will only move around the 256-kilobyte sub-extent.  This will make repair times much faster and quicker to complete.

One other thing we considered was, when a repair/resync occurs, it can affect production due to the CPU resources it must use.  To combat that, we also added the capability to throttle the resources up or down, depending on when it may be done.  For example, if you need a repair/resync to run during production hours, you need to keep performance of your production needs to remain up.  Therefore, you may want to set it on low so it more runs in the background.  However, if you were to do it overnight on a weekend, you can afford to crank it up to a higher setting so it completes faster.

The storage speed repair settings are:

Setting Queue depth Resource allocation
Very low 1 Most resources to active workloads
Low 2 More resources to active workloads
Medium (default) 4 Balances workloads and repairs
High 8 More resources to resync and repairs
Very high 16 Most resources to resync and repairs

For more information regarding resync speeds, please refer to the below article: Adjustable storage repair speed in Azure Stack HCI and Windows Server

Cluster Shared Volumes and Bitlocker

Cluster Shared Volumes (CSV) enable multiple nodes in a Windows Server Failover Cluster or Azure Stack HCI to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume.  BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.

on volumes within a cluster are managed based on how the cluster service “views” the volume to be protected.  will unlock protected volumes without user intervention by attempting protectors in the following order:

  1. Clear Key
  2. Driver-based auto-unlock key
  3. ADAccountOrGroup protector
    • Service context protector
    • User protector
  4. Registry-based auto-unlock key

Failover Cluster requires the Active Directory-based protector option (#3 above) for a cluster disk resource or CSV resources.  The encryption protector is a SID-based protector where the account being used is Cluster Name Object (CNO) that is created in Active Directory.  Because it is Active Directory-based, a domain controller must be available in order to obtain the key protector to mount the drive.  If a domain controller is not available or slow in responding, the clustered drive is not going to mount.

With this thinking, we needed to have a “backup” plan.  With Windows Server 2022, when a drive is enabled for Bitlocker encryption while it is a part of Failover Cluster, we will now create an additional key protector just for the cluster itself.  By doing this, it will still go out to a domain controller first to get the key.  If the domain controller is not available, it will then use the locally kept additional key to mount the drive.  The default will always be to go to the domain controller first.  We have also built in the ability to manually mount a cluster drive using new PowerShell cmdlets and passing the locally kept recovery key.

Another thing about this is that it now opens up the ability to Bitlocker drives that are a part of a workgroup or cross-domain cluster where a Cluster Name Object does not exist.

SMB Encryption

Windows Server 2022 SMB Direct now supports encryption.  Previously, enabling SMB encryption disabled direct data placement, making RDMA performance as slow as .  Now data is encrypted before placement, leading to relatively minor performance degradation while adding AES-128 and AES-256 protected packet privacy.  You can enable encryption using Windows Admin Center, Set-SmbServerConfiguration, or a Universal Naming Convention (UNC) Hardening group policy.  Furthermore, Windows Server Failover Clusters now support granular control of encrypting intra-node storage communications for Cluster Shared Volumes (CSV) and the storage bus layer (SBL). This means that when using Storage Spaces Direct and SMB Direct, you can decide to encrypt the east-west communications within the cluster itself for higher security.

New Cluster Resource Types

Cluster resources are categorized by type. Failover Clustering defines several types of resources and provides resource DLLs to manage these types.  In Windows Server 2022, we have added three new resource types.

HCS Virtual Machine

Building a great management API for was important for Windows Server Containers. There's a ton of really cool low-level technical work that went into enabling containers on Windows, and we needed to make sure they were easy to use. This seems very simple, but figuring out the right approach was surprisingly tricky. Our first thought was to extend our existing management technologies (e.g. WMI, PowerShell) to containers. After investigating, we concluded that they weren't optimal for , and started looking at other options.

After a bit of thinking, we decided to go with a third option. We created a new management service called the Host Compute Service (HCS), which acts as a layer of abstraction above the low-level functionality. The HCS was a stable API could build upon, and it was also easier to use. Making a Windows Server Container with the HCS is just a single API call. Making a Hyper-V Container instead just means adding a flag when calling into the API.

Looking at the architecture in Linux:

Looking at the architecture in Windows:

HCS Virtual Machine lets you create a virtual machine using the HCS APIs rather than the Virtual Machine Management Service (VMMS).

NFS Multi-Server Namespace

If you are not familiar with an NFS Multi-Server Namespace, think of a tree with several branches.  An NFS Multi-Server Namespace allows for the single namespace to extend out to multiple servers by the use of a referral.  With this referral, you can integrate data from multiple NFS Servers into a single namespace.  NFS Clients would connect to this namespace and be referred to a selected NFS Server from one of its branches.

Storage Bus Cache

In all things transparent, this one is a little bit of a reach, but Failover Clustering is needed (sort of).

The storage bus cache for Storage Spaces on standalone servers can significantly improve the read and write performance while maintaining storage efficiency and keeping the operational costs low. Similar to its implementation for Storage Spaces Direct, this feature binds together faster media (for example, SSD) with slower media (for example, HDD) to create tiers. By default, only a portion of the faster media tier is reserved for the cache.

What makes this the bit of a reach is that in order to use storage bus cache, the Failover Clustering feature must be installed but the machine cannot be a member of a Cluster.  I.E. Add the feature and move on.

More information on Storage Bus Cache can be found here: Tutorial: Enable storage bus cache with Storage Spaces on standalone servers

John Marlin
Senior Program Manager
Twitter: @Johnmarlin_MSFT


This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.