For example, with a two-node cluster, the cost of an active and/or passive configuration requires twice the hardware for the same capacity, with eight nodes running as seven active and one passive. The additional hardware increases the cost by only fifteen percent.
Windows Clustering makes no distinction between the nodes during a failover. Windows Clustering does not change the failover policy, which is based on the load or the programs that are running (and where these programs are running). This behavior can make it very difficult to manage a hot spare node that can take up the load when a failure occurs. The only way to influence the failover policy is by changing the possible node lists. Because this behavior is performed outside of the Cluster service in an asynchronous manner to other cluster events (such as, node failures), there is no guarantee that a program can successfully ensure that the spare node can be chosen in the event of a failover.
There are programs where this behavior is essential, for example, Microsoft Exchange 2000, where the back-end Exchange database can be partitioned and spread across a number of cluster nodes. However, Exchange can place such a load on the network that in the event of a node failure, it is not recommended to fail over one partition to a node that is already hosting a different partition of the database. The purpose of this enhancement is to ensure that the Cluster service can modify its failover policy to ensure that if there is a node that does not have a partition currently hosted on it, the passive node can be considered before any active nodes that are already hosting a partition. To ensure high availability of the service, if there are no spares, or if for some other reason (such as, multiple failures) there are no spare nodes, the failover policy can revert back to the default. In other words, the failover policy does not fail services if there is no spare node that is available.
The AntiAffinityClassNames PropertyThe Windows Clustering group has a new public property: AntiAffinityClassNames. This property can contain an arbitrary string of characters. In the event of a failover, if a group that is being failed over has a string that is not empty in the AntiAffinityClassNames property, the failover manager can check all other nodes. If there are any nodes (that are in the possible owners list for the resource) that are not hosting a group with the same value in AntiAffinityClassNames, those nodes are considered a preferred target for failover. This value can take higher priority over the Preferred Owners list.
The following two scenarios demonstrate how this property can be used:
- In an "A+Hs" cluster that is running a single program. For example, a cluster that is running Exchange. In this case, Exchange should set up each group that is supporting a partition with the AntiAffinityClassNames property set to some Exchange-specific value (the same value for each group), for example, "Exchange". In the event of a failure, the failover manager can attempt to keep the partitions apart by selecting nodes that are not hosting groups with the same AntiAffinityClassNames value of "Exchange."
- In a server consolidation where there are multiple programs that should be kept apart, if possible. In these cases, the groups that are representing the various programs should be manually modified with the same value in the AntiAffinityClassNames property.
Article ID: 296799 - Last Review: Jun 10, 2009 - Revision: 1