Before you configure your cluster, confirm that the Microsoft Cluster service and Microsoft IIS are correctly installed on both computers in the cluster. Also, confirm that the computers are connected to the same shared hard disk. You can install the Cluster service on Microsoft Windows Server-based domain controllers or member servers.

Before you install IIS server instances on a server that runs the Cluster service, make sure that the Cluster service is installed correctly and that failover works.

We only support running MSDTC on cluster nodes as a clustered resource. Running MSDTC in stand-alone mode on a cluster is not a recommended or a supported configuration. Using MSDTC in as a non-clustered resource on an MSCS cluster is a problematic configuration because transactions can be orphaned and data corruption can occur if a cluster failover occurs.

To configure an IIS clustered site, follow these steps:

Note You must follow steps 1 through 23 to create the Web resource correctly.

1. On the first node in the cluster, click Start, click Run, type Comclust.exe, and then click OK. You can ignore the message that says that component load balancing will not be installed.This step configures MSDTC on both nodes and installs the MSDTC resource group on the server that runs the Cluster service.MSDTC resource installation for IIS virtual servers is required when Web programs are using transaction mode or calling MSDTC-related programs. IIS Virtual Server Instance does not require MSDTC resource dependency if the Web sites are not using transactions.
2. Repeat step 1 on each node in the cluster.
3. On one of the nodes in the cluster, click Start, click Run, and then type the following, where drive is the drive letter for the shared drive , and folder is the name of the folder for the Web folder that you want to use:
   drive:InetpubWwwrootfolder

   By default, the MSDTC resource is always added to the default Cluster group when Comclust.exe is run. However, you can install MSDTC on another group that depends on non-quorum disks. This leaves the default Cluster group intact.

   If you remove the quorum disk resource or move the quorum disk resource from the group, Comclust.exe moves the MSDTC resource to another group. You can also modify the properties of the MSDTC resource so that the dependency can be changed from the quorum disk to another disk and then moved to another disk group.

4. In the folder that you created in step 3, create two new files that are named Default.asp and Default.htm.
5. Click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
6. Right-click the non-quorum disk group that you want to use, click New, click Resource, and then type a name and description for the resource. Under Resource Type, click IP Address, and then click Next.
7. On the Possible Owners screen, click any node that you do not want to have available to the disk resource if a failure occurs, click Remove, and then click Next.
8. On the Dependency screen, click the disk resource, click Add, and then click Next.
9. Type an Internet Protocol (IP) address for the virtual server. Use a different IP address for each virtual server. Click to clear the Enable NetBIOS check box if your situation requires this configuration. In the Network box, click Public Cluster Connection, and then click Finish.
10. Create an IP address resource for an IIS virtual server in the disk group that is using the non-quorum disk in Cluster Administrator. Use a different IP address for each virtual server. Follow steps 6 through 9 for each virtual server instance. Set this IP address resource to depend on the MSDTC resource and the shared disk resource that you have chosen to hold Web site contents.
11. Click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager.
12. Right-click your computer name, click New, click Web Site, and then click Next.
13. Type a description of the Web site, and then click Next.
14. Type the IP address that you specified in step 9, type the port settings for the site, type the host header information if you use host headers, and then click Next.
15. In the Path box, type the location of the folder that you created in step 3, and then click Next.
16. Under Allow the following, click to select the access permissions that you want, and then click Next.
17. Click Finish.
18. Click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
19. Right-click the disk group for the IP address that you created in step 9, click New, and then click Resource.
20. Type a name and a description for the virtual server instance, click IIS Server Instance, and then click Next.
21. On the Possible Owners screen, remove any servers that you do not want to host the virtual server, and then click Next.
22. Click Disk Resource, click IP Address Resource, click Add, and then click Next..
23. Click the virtual server that you created in Internet Services Manager, and then click Finish.
24. (This step is optional.) On the domain name system (DNS) server, add a host entry that maps the IIS virtual server network name to the IP address that is provided for this Web site. Now the IIS virtual server instance is ready on node A. You can manually move the group to node B and create a new Web site. To do this, use the Microsoft Management Console (MMC) on node B, and then type the same folder path and IP address. Alternatively, you can use the IISSYNC utility to synchronize the two nodes automatically.For additional information about how to run IISSYNC on Windows 2000 Advanced Server, click the following article number to view the article in the Microsoft Knowledge Base:
    249603 (http://support.microsoft.com/kb/249603/ ) Using IISSYNC to synchronize clustered Web sites on Windows 2000 Advanced Server
25. After you follow the procedure that is described in steps 1 through 23, test the IIS virtual Web server from a client browser by accessing the DNS name of the Web site. For example, if the IIS virtual server has the network name “MyWeb” and the DNS entry maps the corresponding IP to “MyWeb.Microsoft.com” for this site, type the following in a browser window to view the default page:
    http://myweb.microsoft.com

    If no DNS entry is specified in step 7, you can use the IP address to directly access the clustered Web site to test it. Before you use the browser to test the IIS virtual Web server, use the PING protocol at a command prompt to check the IP address for the cluster Web site to make sure that the IP configuration on the network is correct.

Additional information about MSDTC installation

IISSync requires MSDTC to synchronize the metabases between the cluster nodes. By default, MSDTC is installed in the Cluster group and can remain there. For additional information about how to move MSDTC to the group that owns the IIS server instance, click the following article number to view the article in the Microsoft Knowledge Base: 243204 (http://support.microsoft.com/kb/243204/ ) Microsoft Distributed Transaction Coordinator (MSDTC) recovery techniques in Windows 2000 Cluster Server.

Quality Articles for Your Blog by Genuine Writers

iWantArticle.com is a place where you can order quality and original articles for your blog. As we all know only original and quality articles are most important part of SEO and Page Rank; iWantArticle.com can be a good resource for same. You need to register for free and request an article with all details as per your requirement. Once you will place your request, registered writers at iWantArticles will start working on your request. After completing your request the writer will submit their work for your verification and validation. Now just verify the work done by writer and decide whether to accept it or deny. Also all these comes with a Money Back Guarantee.
Following are the Important Steps:

• Request Articles
• Hire Writers to write unique articles for you
• Pay only if you are satisfied
• Review results and accept good Articles. You will not be charged for articles you didn’t accept.
• Copyscape friendly
• Requesters check articles and mark them Passed/Failed Copyscape, Good/Bad grammar,...
• Money back guarantee
• If you are not satisfied with the service you will receive full refund of the funds on your account.

iWantArticle.com gives complete facility to verify the quality and uniqueness of the article submitted by the writer.

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.