Article ID: 299631 - View products that this article applies to.
This article was previously published under Q299631
This article documents the logic by which groups fail from one node to another when there are 3 or more cluster node members. The movement of a group can be caused by an administrator who manually moves a group or by a node or resource failure. Where the group moves depends on how the move is initiated and whether the Preferred Owner list is set.
Information about the Preferred Owner list is covered in the Help file under "Server Clusters," including information about planning and optimizing server clusters. This article documents the following four possible scenarios:
Scenario 1If a node or resource fails and the Preferred Owner List has been defined, the Cluster Service fails the Group to the next available node in the Node List. The Node List is composed of the Preferred Owners List followed by the remaining nodes arranged by their Node ID. The Node ID is defined when a node is joined to a cluster or if a node is evicted or and re-added.
You can view the Node ID order by examining the registry under the \HKEY_LOCAL_MACHINE\Cluster\Nodes key.
For example, suppose we have a six node Cluster and that the nodes were installed and joined the Cluster in the following order: NodeA, NodeB, NodeC, NodeD, NodeE, and NodeF. Assume that a Group has NodeA, NodeC, and NodeE listed as the Preferred Owners.
Having this information, the Node List for the Group would then be the following:
Scenario 2AIf a resource fails and the Preferred Owner List is not set, the Group follows a Node List much like it did in Scenario 1. The Node List is built only from the Node ID. Upon a node or resource failure, resources follow a downward path failing to the subsequent node in the Node List. When it reaches the last listed node in the Node List, it starts with the first node in the Node List.
Scenario 2BIf a node fails and the Preferred Owner List is not set for a group on that node, then an available node will be selected randomly for the group to be moved to. This will distribute the groups among the available nodes.
Scenario 3If a Cluster administrator manually chooses Move group and selects Best Possible and the Preferred Owner List is configured, the Group will always start at the top of the Node List. As in Scenario 1, the Node List is composed of the Preferred Owner List and the installation order.
Scenario 4If, as Cluster administrator, you manually choose Move group and you select Best Possible and the Preferred Owner List is not configured, an active node is chosen randomly to host the group. Without the Preferred Owner List configured, it is possible that a Group may move to a Node that is already running several other Groups.
We recommend that you configure the Preferred Owner list on a large node cluster if the load between nodes is significantly different or if the nodes are not homogeneous.
Note The exception to the failover behavior that is mentioned here is with the default Group that holds the Quorum resource that is named the Cluster Group. The Cluster Group does not follow the typical Preferred Owner list behavior. Instead, if the owner of the Quorum resource fails, the new owner will be the previous group that successfully owned the Quorum resource.
The AntiAffinityClassNames public property can also affect where a Group will fail over to. For more information about AntiAffinityClassNames, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/296799/ )How to configure Windows clustering groups for hot spare support
Article ID: 299631 - Last Review: February 10, 2009 - Revision: 8.0