Failover Cluster VM Load Balancing in Windows Server

Windows Server 2016 introduced the Virtual Machine Load Balancing feature for Failover Clusters. This feature optimizes node utilization by redistributing VMs based on memory pressure and CPU utilization. In this blog post, we will explore the command and usage of this feature.

Heuristics for Balancing:

VM Load Balancing considers two heuristics:

• Current Memory pressure: Evaluates the memory usage of each node.
• CPU utilization: Monitors CPU usage averaged over a 5-minute window.

Controlling Aggressiveness of Balancing:

To configure the balancing aggressiveness:

Open PowerShell.
Run (Get-Cluster).AutoBalancerLevel = <value>

AutoBalancerLevel values:

1. (default): Low aggressiveness, moves VMs when host is >80% loaded.
2. Medium aggressiveness, moves VMs when host is >70% loaded.
3. High aggressiveness, averages nodes, and moves VMs when host is >5% above average.

Controlling VM Load Balancing:

To configure when load balancing occurs:
Using Failover Cluster Manager:

1. Right-click on cluster name, select "Properties."
2. Go to the "Balancer" pane and configure desired settings.

Using PowerShell:

1. Open PowerShell.
2. Run (Get-Cluster).AutoBalancerMode = <value>

AutoBalancerMode values:

• 0: Disabled.
• 1: Load balance on node join.
• 2 (default): Load balance on node join and every 30 minutes.

VM Load Balancing vs. SCVMM Dynamic Optimization:

For deployments without SCVMM, VM Load Balancing provides in-box functionality. However, for SCVMM deployments, SCVMM Dynamic Optimization is recommended for load balancing. SCVMM automatically disables VM Load Balancing when Dynamic Optimization is enabled.

Updating Hyper-V Failover Cluster with Cluster-Aware Updating Tool

When you wish to update a failover cluster, I favour the manual process of draining and update each node individually this allows you to catch any issues with the Cluster due to the servers not failover over smoothly.

But there are times when it can be used and should be really as it helps a lot.  The first step is to run the CAU Best Practices Analyzer from within the Cluster-Aware updating Tool with an Administrator account that can admin across all the Nodes of the Cluster.  This will let you know if everything is ready for it to be used.

It should be ran every time there is a change to the nodes that also require Validate a Cluster Wizard to be ran.  it should so be ran if the Nodes updates sources have been changed.

Once everything comes back as ok the following recommendations are also made

1. All other update tools are removed like 3rd part update installers and Windows schedule updates should also be disable.  CAU should be the only tool used for updating on the Nodes and approving updates, this also includes WSUS schedule updating but WSUS can be used as a source
   
   
2. All Nodes must be configured with the same update source
   
   
3.  WSUS must correctly identify the approved updates for the cluster nodes and approve across all Nodes
   
   
4. Sufficient cluster nodes must be online so that the cluster has a quorum and Guest VM can quickly and correctly be drained form a Node with no errors. (If this can not happen it can make CAU fail and get stuck at times)
   
   
5. All cluster nodes must be in the same Active Directory domain and Cluster must be resolvable via DNS
   
   

More Reading 
https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating

Shutting Down a Hyper-V Failover Cluster / Hyper-V Host

Hyper-V Hosts and Failover Clusters are great way to maximums your hardware utilisation or redundancy.  The Failover Clusters and Hyper-V sit at the Infrastructure level.

Hyper-V gives you the ability to run multiple platforms on a single host where as the Failover Cluster allows you to take two or more Hyper-V hosts and build in redundancy of the infrastructure allowing a single or more platform to survive a failure at the infrastructure level, be it Network / Storage / RAM / CPU.

When it comes down to powering down this type of system off the best recommendation is too start at the Software level, then the Platform followed by the Infrastructure not the other way around as this can lead to issues.

Basically shutting down any Applications then the Guest VM then the Physicals.  If you have a Failover Cluster with a single Guest DC, this server should be left running to allow it to move to a paused state meaning that the Failover Cluster GUI will work correctly when the Cluster powers back on.  failing that you will need to PowerShell the Cluster as the GUI may stop working.

The DC can come out of a paused state normally error free but servers that have custom applications / 3rd party software installed may not react well to coming out of this state and reboot will be needed if they ever paused.

Enabling Failover Cluster Shared Volume Caching

Enabling CSV Caching can help with some read heavy workloads, the first thing is to run the following in elevated PowerShell.

(Get-Cluster). BlockCacheSize = 1024

This will set the size of the cache, its recommend to reboot the Host if you change this,  for a normal Hyper-v / Failover Cluster between 512 to 2048 is recommend to start with but if you are using scale-out file server it is recommend high depending on system.  some tuning and looking at the workload is in order.

Once you set this and reboot the Hosts it will take affect, you can disable it per shared volume by running the below

Get-ClusterSharedVolume “Cluster Disk 1” | Set-ClusterParameter  EnableBlockCache 0

Changing "Cluster Disk 1" to the one you wish to disable, once you have done this you will need to bring the Cluster disk offline and back on again.  you can do this by moving it to another hosts.

For more details on setting it up and tuning click here