Failover behavior on clusters of three or more nodes (299631)


The information in this article applies to:

  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, 64-Bit Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
  • Microsoft Windows Server 2003, 64-Bit Datacenter Edition
  • Microsoft Windows Advanced Server, Limited Edition
This article was previously published under Q299631

SUMMARY

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.

MORE INFORMATION

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:
  1. There is a node or resource failure and the Preferred Owner List is set.
  2. There is a node or resource failure and the Preferred Owner List is not set.
  3. Administrator manually moves group to "Best Possible" and the Preferred Owner List is set.
  4. Administrator manually moves group to "Best Possible" and the Preferred Owner List is not set.

Scenario 1

If 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:
  1. NodeA - Preferred Owner number one
  2. NodeC - Preferred Owner number two
  3. NodeE - Preferred Owner number three
  4. NodeB - Second installed Node
  5. NodeD - Fourth installed Node
  6. NodeF - Sixth installed Node
In this scenario, if a Node failure or a failure of a resource were to occur and its restart threshold were hit, the whole Group would fail to the next node down in the Node List. For example, if NodeC contained the resource that failed, the whole Group would fail to NodeE. It would not fail to NodeA even though it is listed first in Preferred Owner List. If NodeE fails, the Group would fail-over to NodeB and not to NodeA.

Scenario 2

If a node or 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 solely 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.
  1. NodeA - First installed Node
  2. NodeC - Second installed Node
  3. NodeE - Third installed Node
  4. NodeB - Fourth installed Node
  5. NodeD - Fifth installed Node
  6. NodeF - Sixth installed Node
For example, this list has the installation order of the different Cluster nodes. If NodeE were to fail, all groups that it owned would fail-over to NodeB and not to NodeF.

Scenario 3

If 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.
  1. NodeA - Preferred Owner number one
  2. NodeC - Preferred Owner number two
  3. NodeE - Preferred Owner number three
  4. NodeB - Second installed Node
  5. NodeD - Fourth installed Node
  6. NodeF - Sixth installed Node
In this example, when Best Possible is selected, the Group always tries to move to NodeA. If the Group is already on NodeA or NodeA is not available, the Group tries to move to NodeC. If a Group is on NodeD and the Administrator chooses to move it to Best Possible, the Group goes to NodeA. If NodeA, NodeC, or NodeE are not active, either NodeB or NodeF is randomly chosen.

Scenario 4

If, 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:

296799 How to configure Windows clustering groups for hot spare support

Modification Type:MinorLast Reviewed:5/24/2006
Keywords:kbenv kbinfo KB299631
©2004 Microsoft Corporation. All rights reserved.