Preferred Owners in a Cluster

Preferred Owners in a Cluster

Rate This
  • Comments 4

A recent email conversation I had prompted me to write this entry about Preferred Owners.  The Preferred Owners setting for a resource group is one of those things which has an inherent counter-intuitiveness to it.

The feature is described very well in KB 299631 (, so I won’t give a thorough explanation.  The key point I want to make is that, when you set the preferred owners for a group to a subset of the nodes in a cluster, you’re not saying “I want the group to failover only to these nodes”.  What you’re effectively saying is, “please reorder the nodes such that these are at the front of the list.”  The rest of the cluster nodes will be appended to the list, and the group will still failover to every node in the cluster before going back to the first node in the preferred owners list. 

In other words, in a 4 node cluster, when an administrator sets the preferred owners for a group to {3, 4}, I have a feeling that they are thinking that, if the group is on node 3, it will failover to node 4 as long as node 4 is up, and if it’s on node 4, it will similarly failover to node 3 if possible, and only failover to nodes 1 or 2 if node 3 is down. 

Just remember that the rest of the nodes are added to the end of the preferred owners list.  So internally, the preferred owners list is {3, 4, 1, 2}.  If the group is on node 4 and fails, it will move to node 1, not node 3.

Ultimately, it’s about availability.  If the group fails on node 3, and then also fails on node 4, it’s probably better to try the other nodes, instead of retrying on node 3. 

(The case is different for planned or manual group moves.  If you move the group without specifying a specific target node, then it will always move to a node in the preferred owners list.)

The other two means of controlling group movement provide progressively stronger assurances that the group will move only within a subset of nodes:

·         Anti-Affinity Keywords: will failover to a node where there is no other group with the same anti-affinity keyword, if possible.  If no such node is available, then it will failover to any available node.

o   Details:

·         Possible Owners: will absolutely, positively not come online on a node that is not a possible owner.  If no possible owner nodes are up, then the group will still failover to a node that’s not a possible owner, but it will not come online.

o   Details:

If your are noticing unusual behavior on your Server 2008 cluster, you may want to apply this hotfix: 

I hope this clears things up.

Jonathan Fischer
Senior Software Development Engineer
Clustering & High Availability

Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post
  • One the confusing thing in Windows cluster is the terminology of "Preferred owners" and "possible owners"

    The first one is at the group level when the second one is at the resource level.

    I usually use only one node in the "Preferred owners" list and set up a timing (by night) for the failback.

    This way, I balance my active/active SQL Server architecture

  • I have a query.. If no preferred owner is selected in the cluster group which contains cluster IP ,Quorum disk..

    On that time if the node fails whether failover will happen or not..

  • How does the prefered node work with Dynamic RAM?

    Will it move to the node where ram is free, or reduce the amount of ram the vm has keeping it on a prefered node?

  • From your description, it sounds more like a "round-robin," staring at the 1st preferred node or, in the case of a service already being on the 3rd node, then it would go next to #4, instead of #1 - is that correct?

Page 1 of 1 (4 items)