After planning the cluster deployment strategy, correct deployment of that cluster ensures high availability of your servers that run Microsoft Exchange Server 2003. Although deploying Exchange in a cluster resembles deploying Exchange in a non-clustered organization, there are important differences you must consider. Therefore, to fully understand how to deploy Exchange Server 2003 in a cluster, read this topic together with the previous topics in this guide.

Specifically, this topic provides the following information:

• Cluster Requirements
  This section discusses the necessary requirements for installing Exchange Server 2003, including Microsoft Windows and Exchange version requirements, software requirements, and network configuration requirements.
• Deployment Scenarios
  This section includes the following configuration and procedural information about how to deploy Exchange Server 2003 clusters:
  • Four-node cluster scenario
  • Deploying a new Exchange Server 2003 cluster
  • Upgrading an Exchange 2000 Server cluster to Exchange Server 2003
  • Migrating an Exchange Server 5.5 cluster to Exchange Server 2003
  • Upgrading mixed Exchange 2000 Server and Exchange Server 5.5 clusters

Before continuing with the deployment procedures listed in this topic, follow these steps:

• Read the section “Using Server Clusters” in the guide Planning an Exchange Server 2003 Messaging System ( http://go.microsoft.com/fwlink/?LinkId=47584).
• Create a Windows 2000 Server or Microsoft Windows Server™ 2003 cluster. To create a Windows 2000 or Windows Server 2003 cluster, see the following resources:
  • Windows Server 2003 For information about how to create a Windows Server 2003 cluster, see Checklist: Preparation for installing a cluster ( http://go.microsoft.com/fwlink/?linkid=16302).
  • Windows 2000 For information about how to create a Windows 2000 cluster, see Step-by-Step Guide to Installing Cluster Service ( http://go.microsoft.com/fwlink/?LinkId=83053).

Shared Disk Requirements

The following are the minimum shared disk requirements for installing Exchange Server 2003 on a Windows 2000 or Windows Server 2003 cluster:

• Shared disks must be physically attached to a shared bus.
• Disks must be accessible from all nodes in the cluster.
• Disks must be configured as basic disks, and not dynamic disks.
• All partitions on the shared disk must be formatted for NTFS file system.
• Only physical disks can be used as a cluster resource. All partitions on a physical disk will be treated as one resource.
• We recommend that you use Diskpart to align the shared storage disks at the storage level. Diskpart is part of the Windows Server 2003 Service Pack 1 tools. For more information, see “How to Align Exchange I/O with Storage Track Boundaries” in Optimizing Storage for Exchange Server 2003.

Network Configuration Requirements

Make sure that the networks used for client and cluster communications are configured correctly. This section provides links to the procedures necessary to verify that your private and public network settings are configured correctly. In addition, you must make sure that the network connection order is configured correctly for the cluster.

For detailed steps about how to configure the private network in an Exchange cluster, see How to Configure the Private Network in an Exchange Cluster.

For detailed steps about how to configure the public network in an Exchange cluster, see How to Configure the Public Network in an Exchange Cluster.

For detailed steps about how to configure the network connection order in an Exchange cluster, see How to Configure the Network Connection Order in an Exchange Cluster.

Figure 1 illustrates a network configuration for a 4-node cluster.

Figure 1 Network configuration for a four-node cluster

For more information about how to configure public and private networks on a cluster, see Microsoft Knowledge Base article 258750, “Recommended Private ‘Heartbeat’ Configuration on a Cluster Server” ( http://go.microsoft.com/fwlink/?linkid=3052&kbid=258750).

Clustering Permission Model Changes

The permissions that you need to create, delete, or modify an Exchange Virtual Server are modified in Exchange Server 2003. The best way to understand these modifications is to compare the Exchange 2000 Server permissions model with the new Exchange Server 2003 permissions model.

Deployment Scenarios

After you ensure that the Exchange organization meets the clustering requirements listed in this topic, you are ready to deploy an Exchange Server 2003 cluster. This section provides links to the procedures necessary to deploy active/passive or active/active Exchange Server 2003 clusters on Windows Server 2003. Any procedural differences with regard to deploying Exchange Server 2003 clusters on Windows 2000 are explained.

The following deployment scenarios are included in this section:

• Four-node cluster scenario
• Deploying a new Exchange Server 2003 cluster
• Upgrading an Exchange 2000 Server cluster to Exchange Server 2003
• Migrating an Exchange Server 5.5 cluster to Exchange Server 2003
• Upgrading mixed Exchange 2000 Server and Exchange Server 5.5 clusters

Four-Node Cluster Scenario

Although the deployment procedures listed in this section apply to any cluster configuration, it helps understand one of the more typical four-node cluster deployments.

The recommended configuration for a four-node Exchange Server 2003 cluster is one that contains three active nodes and one passive node, where each of the active nodes contains one Exchange Virtual Server. This configuration is helpful because it gives you the capacity of running three active Exchange servers, while maintaining the failover security provided by one passive server.

Figure 2 illustrates the four-node, active/passive Exchange Server 2003 cluster.

Figure 2 Four-node active/passive Exchange Server 2003 cluster

The following sections provide the recommended software, hardware, and storage requirements for an Exchange Server 2003 active/passive four-node cluster.

Software Recommendations

In this scenario, all four nodes in the cluster are running Windows Server 2003, Enterprise Edition and Exchange Server 2003, Enterprise Edition. Additionally, each node is connected to a DNS server configured for dynamic updates.

Hardware Recommendations

In this scenario, the following hardware configurations are recommended.

Server hardware

• Four 1 gigahertz (GHz), 1 megabyte (MB) or 2 MB L2 cache processors
• 4 gigabytes (GB) of Error Correction Code (ECC) RAM
• Two 100 megabits per second (Mbps) or 1000 Mbps network interface cards
• RAID-1 array with two internal disks for the Windows Server 2003 and Exchange Server 2003 program files
• Two redundant 64-bit fiber Host Bus Adapters (HBAs) to connect to the Storage Area Network

Local area network hardware

• Two 100 Mbps or 1000 Mbps network switches (full duplex)

Storage Area Network hardware

• Redundant fiber switches
• 106 disk spindles (Ultra Wide SCSI) with spindle speeds of 10,000 RPM or greater
• 256 MB or more read/write cache memory

Storage Configuration Recommendations

In this scenario, the following storage configurations are recommended:

Storage groups and databases

• Three storage groups per Exchange Virtual Server
• Five databases per storage group

Disk drive configuration

Table 2 lists the recommended disk drive configuration. For more information about this and other disk drive configurations, see “Drive Letter Configurations” in the guide Planning an Exchange Server 2003 Messaging System ( http://go.microsoft.com/fwlink/?LinkId=47584)

Table 2 Disk drive configuration for a four-node active/passive cluster containing three Exchange Virtual Servers

Figure 3 Exchange Virtual Server resources

Repeating Step 3 for the Next Exchange Virtual Server

For each Exchange Virtual Server you want to create, repeat all the procedures in “Step 3: Creating the Exchange Virtual Servers.” For example, if you are creating a four-node active/passive cluster with three Exchange Virtual Servers, repeat this step two more times. If you are creating a two-node active/active cluster, you would repeat this step one more time.

Supporting Multiple SMTP Domains in a Front-End and Back-End Topology

If you run Exchange Server 2003 in a front-end and back-end topology that includes multiple SMTP namespaces, you must create additional HTTP virtual servers in the Exchange Virtual Server for each domain namespace. For example, if contoso.com hosts Exchange Server 2003 for both tailspintoys.com and wingtiptoys.com, three virtual servers are necessary—the default virtual server, a virtual server for tailspintoys.com, and a virtual server for wingtiptoys.com. This configuration provides maximum flexibility in determining which resources are available to each hosted company.

For information about front-end and back-end server architecture, see “Upgrading Front-End and Back-End Servers” in Upgrading from Exchange 2000 Server to Exchange Server 2003. For information about planning a front-end server and for more conceptual information about configuring front-end and back-end servers running Exchange Server 2003, see the guide Planning an Exchange Server 2003 Messaging System ( http://go.microsoft.com/fwlink/?LinkId=47584)

To configure a clustered back-end server to support multiple SMTP domains, you must map each front-end server to the nodes of your cluster, so that any node can accept proxy requests from any front-end server in your organization.

For detailed steps, see How to Support Multiple SMTP Domains in a Front-End and Back-End Topology.

Figure 4 illustrates a front-end/back-end configuration that uses Exchange clustering.

Figure 4 Front-end and back-end configuration that uses Exchange clustering

Upgrading an Exchange 2000 Server Cluster to Exchange Server 2003

Upgrading an Exchange 2000 Server cluster to Exchange Server 2003 requires that you upgrade each of the cluster nodes and all Exchange Virtual Servers to Exchange Server 2003.

For detailed steps, see How to Upgrade an Exchange 2000 Cluster to Exchange Server 2003.

Q. What hardware do you need to build a Server cluster?

A. The most important criteria for Server cluster hardware is that it be included in a validated Cluster configuration on the Microsoft Hardware Compatibility List (HCL), indicating it has passed the Microsoft Cluster Hardware Compatibility Test. All qualified solutions appear on the Microsoft HCL ( http://go.microsoft.com/fwlink/?linkid=67738). Only cluster solutions listed on the HCL are supported by Microsoft.

In general, the criteria for building a server cluster include the following:

• Servers: Two or more PCI-based machines running one of the operating system releases that support Server clusters (see below). Server clusters can run on all hardware architectures supported by the base Windows operating system, however, you cannot mix 32-bit and 64-bit architectures in the same cluster.
• Storage: Each server needs to be attached to a shared, external storage bus(es) that is/are separate from the bus containing the system disk, the startup disk or the pagefile disk. Applications and data are stored on one or more disks attached to this bus. There must be enough storage capacity on the shared cluster bus(es) for all of the applications running in the cluster environment. This shared storage configuration allows applications to failover between servers in the cluster.
  Microsoft recommends hardware Redundant Array of Inexpensive Disks (RAID) for all cluster disks to eliminate disk drives as a potential single point of failure. This means using a RAID storage unit, a host-based RAID adapter that implements RAID across disks, etc.
  SCSI is supported for 2-node cluster configurations only. Fibre channel arbitrated loop is supported for 2-node clusters only. Microsoft recommends using fibre channel switched fabrics for clusters of more than two nodes.
• Network: Each server needs at least two network cards. Typically, one is the public network and the other is a private network between the two nodes. A static IP address is needed for each group of applications that move as a unit between nodes. Server clusters can project the identity of multiple servers from a single cluster by using multiple IP addresses and computer names: this is known as a virtual server.

Q. What is a cluster resource?

A. A cluster resource is the lowest level unit of management in a Server cluster. A resource represents a physical object or an instance of running code. For example, a physical disk, an IP address, an MSMQ queue, a COM object all of these things are considered to be resources. From a management perspective, resources can be independently started and stopped and each is monitored to ensure that it is healthy.

Server cluster can monitor any arbitrary resource type. This is possible because Server clusters define a resource plug-in model. Each resource type has an associated resource plug-in or resource dll that is used to start, stop and provide health information that is specific to the resource type. For example, starting and stopping SQL Server is different from starting and stopping a physical disk. The resource dll takes care of the differences. Application developers and system administrators can build new resource dlls for their applications that can be registered with the cluster service.

Server clusters provides some generic plug-ins that can be used to make existing applications cluster-aware very quickly, known as Generic Service and Generic Application. With Windows Server 2003, a Generic Script resource plug-in was added that allows the resource dll to be written in any scripting language supported by the Windows operating system.

Q. What is a resource dependency?

A. A complete application actually consists of multiple pieces or multiple resources, some pieces are code and others are physical resources required by the application. The resources are related in different ways; for example, an application that writes to a disk cannot come online until the disk is online. If the disk fails, then, by definition, the application cannot continue to run since it writes to the disk. Resource dependencies can be defined by the application developer or system administrator to capture these relationships. Resource dependencies define the order that resources are brought online and control how failures are propagated to the various pieces of the application.

Q. What is a resource group?

A. A resource group is a collection of one or more resources that are managed and monitored as a single unit. A resource group can be started or stopped. If a resource group is started, each resource in the group is started (taking into account any start order defined by the dependencies between resources in the group). If a resource group is stopped, all of the resources in the group are stopped. Dependencies between resources cannot span a group. In other words, the set of resources within a group is an autonomous unit that can be started and stopped independently from any other group. A group is a single, indivisible unit that is hosted on one server in a Server cluster at any point in time and it is the unit of failover.

Q. Can I have dependencies between resources in different groups?

A. No, resource dependencies are confined to a single group.

Q. What is a virtual server?

A. A virtual server is a resource group that contains an IP address resource and a network name resource. When an application is hosted in a virtual server, the application can be accessed by clients using the IP address or network name in that resource group. As the resource group fails over across the cluster, the IP address and network name remain the same, therefore the client becomes unaware of the physical location of the application and will continue to work in the event of a failure of one of the servers in the cluster.

Q. How can I take advantage of extensibility features of ISA Server?

A. A number of third-party vendors offer solutions such as virus detection, content filtering, site categorization, reporting, and administration. Customers and developers also have the ability to create their own extensions to ISA Server. ISA Server includes a comprehensive software development kit for developing tools that build on ISA Server firewall, caching, and management features.

Q. What is failover?

A. Server clusters monitor the health of the nodes in the cluster and the resources in the cluster. In the event of a server failure, the cluster software re-starts the failed server’s workload on one or more of the remaining servers. If an individual resource or application fails (but the server does not), Server clusters will typically try to re-start the application on the same server; if that fails, it moves the application’s resources and re-starts it on the other server. The process of detecting failures and restarting the application on another server in the cluster is known as failover.

The cluster administrator can set various recovery policies such as whether or not to re-start an application on the same server, and whether or not to automatically “failback” (re-balance) workloads when a failed server comes back online.

Q. Is failover transparent to users?

A. Server clusters do not require any special software on client computers, so the user experience during failover depends on the nature of the client side of their client-server application. Client reconnection can be made transparent, because the Server clusters software has restarted the applications, file shares, etc. at exactly the same IP address.

If a client is using “state-less” connections such as a standard browser connection, then the client would be unaware of a failover if it occurred between server requests. If a failure occurs while a client is connected to the failed resource, then the client will receive whatever standard notification is provided by the client side of their application when the server side becomes unavailable. This might be, for example, the standard “Abort, Retry, or Cancel?” prompt you get when using the Windows Explorer to download a file at the time a server or network goes down. In this case, client reconnection is not automatic (the user must choose “Retry”), but the user is fully informed of what is happening and has a simple, well-understood method of re-establishing contact with the server. Of course, in the meantime, the cluster service is busily re-starting the service or application so that, when the user chooses “Retry”, it re-appears as if it never went away.

Q. What is failback?

A. In the event of the failure of a server in a cluster, the applications and resources are failed over to another node in the cluster. When the failed node rejoins the cluster (after reboot for example), that node now is free to be used by applications. A cluster administrator can set policies on resources and resource groups that allow an application to automatically move back to a node if it becomes available, thus automatically taking advantage of a node rejoining the cluster. These policies are known as failback policies. You should take care when defining automatic failback policies since depending on the application, automatically moving the application (which was working just fine) may have undesirable consequences on the clients using the applications.

Q. When an application restarts after failover, does it restore the application state at the time of failure?

A. No, Server clusters provide a fast crash restart mechanism. When an application is failed over and restarted, the application is restarted from scratch. Any persistent data written out to a database or to files is available to the application, but any in-memory state that the application had before the failover is lost.

Q. At what level does failover exist?

A. At the resource group level.

Q. What is a Quorum Resource and how does it help Server clusters provide high availability?

A. Server clusters require a quorum resource to function. The quorum resource, like any other resource, is a resource which can only be owned by one server at a time, and for which servers can negotiate for ownership. Negotiating for the quorum resource allows Server clusters to avoid “split-brain” situations where the servers are active and think the other servers are down. This can happen when, for example, the cluster interconnect is lost and network response time is problematic. The quorum resource is used to store the definitive copy of the cluster configuration so that regardless of any sequence of failures, the cluster configuration will always remain consistent.

Q. What is active/active verses active/passive?

A. Active/Active and Active/Passive are terms used to describe how applications are deployed in a cluster. Unfortunately, they mean different things to different people and so the terms tend to cause confusion.

From the perspective of a single application or database:

• Active/Active means that the same application or pieces of the same service can be run concurrently on different nodes in the cluster. For example SQL Server 2000 can be configured such that the database is partitioned and each node can be running a single instance of the database. SQL Server provides the notion of views to provide a single image of the entire database.
• Active/Passive means that only one node in the cluster can be hosting the given application. For example, a single file share is active/passive. Any given file share can only be hosted on one node at a time.

From the perspective of a set of instances of an application or service:

• Active/Active means that different instances of the same application can be running concurrently on different cluster nodes. For example, each node in a cluster can be running SQL Server against a different database. A single cluster can support many file shares that are hosted on the nodes in a cluster concurrently.
• Active/Passive means that only one instance of a service can be running anywhere in the cluster. For example, there must only be a single instance of the DHCP service running in the cluster at any point in time.

From the perspective of the cluster:

• Active/Active means that all nodes in the cluster are running applications. These may be multiple instances of the same application or different applications (for example, in a 2-node cluster, WINS may be running on one node and DHCP may be running on the other node).
• Active/Passive means that one of the cluster nodes is spare and not being used to host applications.

Server clusters support all of these different combinations; the terms are really about how specific applications or sets of applications are deployed.

With the advent of more than two servers in a cluster, starting with Windows 2000 Datacenter, the term active/active is confusing because there may be four servers. When there are multiple servers, the set of options available for deployment becomes more flexible, allowing different configurations such as N+I.

Q. How do I benefit from more than two nodes in a cluster?

A. Failover is the mechanism that instance applications and the individual partitions of a partitioned application typically employ for high availability (the term Pack has been coined to describe a highly available, single instance application or partition).

In a 2-node cluster, defining failover policies is trivial. If one node fails, the only option is to failover to the remaining node. As the size of a cluster increases, different failover policies are possible and each one has different characteristics.

Failover Pairs

In a large cluster, failover policies can be defined such that each application is set to failover between two nodes. The simple example below shows two applications App1 and App2 in a 4-node cluster.

Figure 1: Failover pairs

Configuration has pros and cons:

1 A heavy-weight application is one that consumes a significant number of system resources such as CPU, memory or IO bandwidth.

Failover pairs are supported by server clusters on all versions of Windows by limiting the possible owner list for each resource to a given pair of nodes.

Hot-Standby Server

To reduce the overhead of failover pairs, the spare node for each pair may be consolidated into a single node, providing a hot standby server that is capable of picking up the work in the event of a failure.

Figure 2: Standby Server

Configuration has pros and cons:

Server clusters support standby servers today using a combination of the possible owners list and the preferred owners list. The preferred node should be set to the node that the application will run on by default and the possible owners for a given resource should be set to the preferred node and the spare node.

N+I

Standby server works well for 4-node clusters in some configurations, however, its ability to handle multiple failures is limited. N+I configurations are an extension of the standby server concept where there are N nodes hosting applications and I nodes spare.

Figure 3: N+I Spare node configuration

Configuration has pros and cons:

Server cluster supports N+I scenarios in the Windows Server 2003 release using a cluster group public property AntiAffinityClassNames. This property can contain an arbitrary string of characters. In the event of a failover, if a group being failed over has a non-empty string in the AntiAffinityClassNames property, the failover manager will check all other nodes. If there are any nodes in the possible owners list for the resource that are NOT hosting a group with the same value in AntiAffinityClassNames, then those nodes are considered a good target for failover. If all nodes in the cluster are hosting groups that contain the same value in the AntiAffinityClassNames property, then the preferred node list is used to select a failover target.

Failover Ring

Failover rings allow each node in the cluster to run an application instance. In the event of a failure, the application on the failed node is moved to the next node in sequence.

Figure 4: Failover Ring

Configuration has pros and cons:

Failover rings are supported by server clusters on the Windows Server 2003 release. This is done by defining the order of failover for a given group using the preferred owner list. A node order should be chosen and then the preferred node list should be set up with each group starting at a different node.

Random

In large clusters or even 4-node clusters that are running several applications, defining specific failover targets or policies for each application instance can be extremely cumbersome and error prone. The best policy in some cases is to allow the target to be chosen at random, with a statistical probability that this will spread the load around the cluster in the event of a failure.

Configuration has pros and cons:

The Windows Server 2003 release of server clusters randomizes the failover target in the event of node failure. Each resource group that has an empty preferred owners list will be failed over to a random node in the cluster in the event that the node currently hosting it fails.

Customized control

There are some cases where specific nodes may be preferred for a given application instance.

Configuration has pros and cons:

Server clusters provide full control over the order of failover using the preferred node list feature. The full semantics of the preferred node list can be defined as:

Q. How many resources can be hosted in a cluster?

A. The theoretical limit for the number of resources in a cluster is 1,674; however, you should be aware that the cluster service periodically polls the resources to ensure they are alive. As the number of resources increases, the overhead of this polling also increases.

Microsoft Cluster Server (MSCS) in Microsoft Windows NT Server 4.0 Enterprise Edition was the first server cluster technology offered by Microsoft. Individual servers that compose a cluster are referred to as nodes. A Cluster service is a collection of components on each node that perform cluster-specific tasks. Hardware and software components in the cluster that are managed by the Cluster service are referred to as resources. Server clusters provide the instrumentation mechanism for managing resources through resource DLLs, which define resource abstractions (in other words, they abstract a clustered resource from a specific physical node, enabling the resource to move from one node to another), communication interfaces, and management operations.

Resources are elements in a cluster that are:

• Brought online (in service) and taken offline (out of service)
• Managed in a server cluster
• Owned by only one node at a time

A resource group is a collection of resources, managed by the Cluster service as a single, logical unit. This logical unit is often referred to as a failover unit, because the entire group moves as a single unit between nodes. Resources and cluster elements are grouped logically according to the resources added to a resource group. When a Cluster service operation is performed on a resource group, the operation affects all individual resources contained in the group. Typically, a resource group is created that contains the individual resources required by the clustered program.

Cluster resources may include physical hardware devices, such as disk drives and network cards, and logical items such as IP addresses, network names, and application components.

Clusters also include common resources, such as external data storage arrays and private cluster networks. Common resources are accessible by each node in the cluster. One common resource is the quorum resource, which plays a critical role in cluster operations. The quorum resource must be accessible for all node operations, including forming, joining or modifying a cluster.

Server Clusters
Windows Server 2003 Enterprise Edition provides two types of cluster technologies for use with Exchange Server 2003 Enterprise Edition. The first is Cluster services, which provide failover support for back-end mailbox servers that require a high level of availability. The second is Network Load Balancing (NLB), which complements server clusters by supporting highly available and scalable clusters of front-end Exchange protocol virtual servers (for example, HTTP, IMAP4, and POP3).

Server clusters use a shared-nothing model. Model types define how servers in a cluster manage and use local and common cluster devices and resources. In the shared-nothing cluster, each server owns and manages its local devices. Devices common to the cluster, such as common disk arrays and connection media, are selectively owned and managed by only one node at a time.

Server clusters use standard Windows drivers to connect to local storage devices and media. Server clusters support multiple connection media for the external common devices, which must be accessible by all servers in the cluster. External storage devices support standard PCI–based SCSI connections, SCSI over Fibre Channel, and SCSI bus with multiple initiators. Fibre connections are SCSI devices that are hosted on a Fibre Channel bus, instead of on a SCSI bus.

The following figure illustrates components of a two-node server cluster, which is comprised of servers running Windows Server 2003 Enterprise Edition, with shared storage device connections using SCSI or SCSI over Fibre Channel.
Sample two-node Windows cluster

The Cluster service runs on Windows Server 2003 Enterprise Edition, using network drivers, device drivers, and resource instrumentation processes specifically designed for server clusters and their component processes. The Cluster service includes the following components:

• Checkpoint Manager This component saves application registry keys in a cluster directory stored on the quorum resource. To make sure that the Cluster service can recover from a resource failure, Checkpoint Manager checks registry keys when a resource is brought online and writes checkpoint data to the quorum resource when a resource goes offline. Checkpoint Manager also supports resources with application-specific registry trees that are instantiated at the cluster node, where the resource comes online. A resource can have one or more registry trees associated with it. When the resource is online, Checkpoint Manager monitors changes to these registry trees. If Checkpoint Manager detects changes, it transfers the registry tree to the owner node of the resource. Checkpoint Manager then transfers the file to the owner node of the quorum resource. Checkpoint Manager performs batch transfers, so that frequent changes to registry trees do not place too heavy a load on the Cluster service.
• Database Manager Database Manager maintains cluster configuration information about all physical and logical entities in a cluster. These entities include the cluster itself, cluster node membership, resource groups, resource types, and descriptions of specific resources, such as disks and IP addresses.
  Persistent and volatile information stored in the configuration database tracks the current and desired state of a cluster. Each instance of Database Manager running on each node in the cluster cooperates to maintain consistent configuration information across the cluster and to ensure consistency of the configuration database copies on all nodes.
  Database Manager also provides an interface for use by other Cluster components, such as Failover Manager and Node Manager. This interface is similar to the registry interface of Microsoft Win32 APIs. However, the Database Manager interface writes changes made to cluster entities in both the registry and in the quorum resource.
  Database Manager supports transactional updates of the cluster registry hive and only presents interfaces to internal Cluster service components. Failover Manager and Node Manager typically use this transactional support to get replicated transactions. The Cluster API presents all Database Manager functions to clients, with the exception of transactional support functions. For additional information on the Cluster API, see Cluster API on MSDN.

Failover can occur automatically because of an unplanned hardware or software failure, or it can occur as the result of manual initiation by an administrator. The algorithm and behavior in both situations is almost identical. However, in a manually initiated failover, resources are shut down in an orderly way; whereas in unplanned failovers, resources are shut down in a sudden and disruptive way (for example, the power goes out, or a crucial hardware component fails).

When an entire node in a cluster fails, its resource groups transfer to one or more available nodes in the cluster. Automatic failover is similar to planned administrative reassignment of resource ownership. However, it is more complicated, because the orderly steps of a planned shutdown might be interrupted or might not have occurred at all. Therefore, extra steps are required to evaluate the state of the cluster at the time of failure.

When your network experiences an automatic failover, it is important to determine what groups were running on the failed node and which nodes should take ownership of the various resource groups. All nodes in the cluster that are capable of hosting the resource groups negotiate for ownership. This negotiation is based on node capabilities, current load, application feedback, the node preference list, or the use of the AntiAffinityClassNames property, which is discussed in the Cluster-Specific Configurations. When negotiation of the resource group is completed, all nodes in the cluster update their databases and track which node owns the resource group.

In clusters with more than two nodes, the node preference list for each resource group can specify a preferred server, plus one or more prioritized alternatives. This enables cascading failover, in which a resource group can survive multiple server failures, each time cascading, or failing over to the next server on its node preference list.

An alternative to automatic failover, is commonly called N+I failover. This method establishes the node preference lists for all cluster groups. The node preference list identifies the standby cluster nodes, to which resources are moved at the first failover. The standby nodes are servers in the cluster that are mostly idle or that have workloads that can be easily pre-empted if a failed server’s workload must be moved to the standby node.

Cascading failover assumes that every other server in the cluster has some excess capacity and can absorb a portion of any other failed server’s workload. N+I failover assumes, that the +I standby servers are the primary recipients of excess capacity.

When a node comes back online, Failover Manager can decide to move one or more resource groups back to the recovered node. This is referred to as failback. The properties of a resource group must have a preferred owner defined to fail back to a recovered or restarted node. Resource groups for which the recovered or restarted node is the preferred owner are moved from the current owner to the recovered or restarted node.

Failback properties of a resource group can include the hours of the day during which failback is allowed and a limit on the number of times failback is attempted. This enables the Cluster service to prevent failback of resource groups during peak processing times or to nodes that have not been correctly recovered or restarted.