Cluster Aware Update. Preffered Owner?

[Gongalong]

Hi folks,

 

Our 2019 servers were setup by a contractor to have cluster aware updating - we have a two host cluster. I'm fairly sure that when the updating happens that one set of servers default to one host, and another set default to the second host. Is this controlled by preferred owner? If so, the odd thing is that preferred owner has not been set, so I'm wondering if it's controlled by something else.

 

The reason for asking is that we want to install a cloud backup client on each of the hosts. The backup client isn't cluster aware, so it will always be expecting the same VMs on each host to backup, so I need to ensure after a cluster aware update that the same VMs end up on each host, if that makes sense.

 

I have found this (https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating-faq), which suggests that if no preferred owner is set it falls back to whathever the previous role distribution was, but is this accurate?

 

"Does CAU load balance the clustered roles?

CAU doesn't load balance the clustered nodes, but it attempts to preserve the distribution of clustered roles. When CAU finishes updating a cluster node, it attempts to fail back previously hosted clustered roles to that node. CAU relies on clustering APIs to fail back the resources to the beginning of the pause process. Thus in the absence of unplanned failovers and preferred owner settings, the distribution of clustered roles should remain unchanged."

 

Thanks

[jthompson]

On the properties of a VM in Failover Cluster Manager, the General tab will let you select the preferred owners, but the Failover tab will give you some more options about whether the role actually fails back to a preferred owner or not, and if it does, whether it does it so immediately or just within a set time range. I reckon those options should allow you to keep your VMs distributed as you want them, as much as possible. You'll probably want to have your CAU runs happening a decent time away from the cloud backups, to give the cluster plenty of time to settle back to how you want it.