Microsoft Cluster Server (MSCS) is a valuable, yet misunderstood, Windows NT Server 4.0, Enterprise Edition (NTS/E) service that increases production time through sustained availability. In this article, I explain MSCS's basic functionality and walk you through how to use MSCS with Internet Information Server (IIS) to set up a high-availability Web site that gives you peace of mind.
MSCS Basics
A common misconception about MSCS is that it provides load-balanced processing of one application or service across multiple servers. The truth is that MSCS provides fault tolerance to ensure that your applications or services are still available to users when your hardware, OS, services, or applications fail. A basic MSCS system contains two physical servers, which you connect via a crossover cable for internode communications, and a shared SCSI or fibre-channel storage subsystem for arbitrated storage.
MSCS uses this setup to provide active/active or active/standby availability. Active/active availability means that both servers actively provide your users separate instances of a service or application. In addition, either server can almost seamlessly take over its cluster partner's processing load if its partner's hardware, service, application, or OS fails. Active/standby availability means that only one server is the active server in the cluster. The standby server idly sits and waits to assume all processing responsibility if its busy cluster partner experiences a failure. The services and applications you run in active/active or active/standby configurations determine whether you can run multiple instances of a service or application on either or both cluster nodes.
If you use MSCS to cluster IIS, the nodes in your IIS 4.0 cluster won't provide load-balanced processing of one Web site. Instead, MSCS offers your IIS Web site to the network in the guise of a virtual server (i.e., multiple servers that appear as one server to the OS or for network administration) and hosts your site on a preferred node. The preferred node is the node in the cluster that you designate as the primary server for your virtual server. Your preferred node performs all the processing during normal operation. If a failure occurs on the preferred node and impedes the virtual server's availability, the virtual server's processing load moves to the other cluster node. For example, if cluster node A is your virtual server's preferred node and cluster node A has a hardware, software, or OS failure, your virtual server fails over to cluster node B. After the failover completes, your virtual server is still available to your users.
Some users are disenchanted with MSCS after they realize it doesn't provide load-balanced processing. Although MSCS doesn't lighten the processing load on one server, it ensures that critical applications are available to users in case of hardware or OS failure. In addition, one MSCS implementation can host multiple high-availability Web sites. You can sleep better at night knowing that if your Web server has a system failure, your customers can still place orders via the Web.
Installing MSCS
The NTS/E manuals provide comprehensive instructions for installing MSCS. Also, you can find installation instructions and more information about MSCS in Brad Cooper's, "Installing Microsoft Cluster Server," http://www.winntmag.com, instaNT document number 3923.
Configuring your hardware for clustering is often more difficult than installing MSCS and clustering your applications. Some vendors offer cluster-ready packages that include the hardware you need to set up MSCS. However, before you buy a hardware solution, research vendors' offerings and choose a solution that requires as little assembly as possible—most vendors provide little documentation about how to configure their cluster-ready servers to work with MSCS.
You install IIS 4.0 from the NT 4.0 Option Pack CD-ROM. Before you install the Option Pack components, your MSCS system must meet the following prerequisites:
Installing and Configuring Clustered IIS
After you've installed MSCS on both nodes and followed the previous instructions to prepare your system for the Option Pack components, you're ready to install IIS 4.0 from the Option Pack CD-ROM. You must install MSCS first, so you can add IIS to your Cluster Administrator's list of available resources. Although many of the Option Pack components are optional, you must install Microsoft Transaction Server (MTS) because it handles Active Server Pages (ASP) resource usage and thread management. MTS automatically clusters and won't interfere with your system. However, MTS causes an MSCS memory leak that Service Pack 4 (SP4) fixes.
Before you install the Option Pack, ensure that the server on which you're installing the Option Pack components (I'll refer to this server as node A) is hosting your newly created IIS cluster resource group. Next, begin the Option Pack Setup program. During the installation, Setup identifies all shared drives your cluster node is hosting and prompts you for the drive on which you want Setup to install the MTS Transaction Log. Choose a drive that you configured in your IIS cluster resource group. Although no negative effects occur if you install the Option Pack components on a shared drive, you should install the components in their default locations so each server has an administrative Web site that you can use to manage your virtual IIS system.
After you finish configuring node A, Setup prompts you to install the Option Pack on the other cluster server (I'll call this server node B). Begin the Option Pack installation on node B without rebooting node A. Setup won't prompt you for a Transaction Log location because it will find this information in the Quorum logs on your MSCS Quorum drive. After installation is complete, reboot node B, and after node B is back online, reboot node A. You can then configure IIS to operate in a clustered environment.
Next, you assign the domain-based anonymous user account you previously created. Launch the IIS Microsoft Management Console (MMC) on node A, and expand the IIS tree. Identify and right-click node A, select Properties from the drop-down context menu, and select the Internet Information Server tab in the Properties dialog box. Then, select WWW Service in the Master Properties drop-down menu, select Edit, and click Edit at the top of the Directory Security tab. Select the Allow anonymous access check box in the Authenticate Methods dialog box, and click Edit. In the resulting text box, input the domain-based anonymous user account you created earlier (e.g., IUSR_Cluster or IUSR_ProjectName) and verify the password. Don't select the Password Synchronization option.
Finally, set the domain-based Windows Access Method account you previously created. This account is also known as the WWW Service account. IIS 4.0 doesn't use the Registry for most of its configuration settings; instead, it uses the IIS Metabase. This metabase doesn't have a GUI; therefore, you must use Windows Scripting Host (WSH) to manipulate it. By default, IIS doesn't associate WSH with this metabase, so you need to use Cscript to manually create an association with WSH.
To make this association and set the Windows Access Method account, go to the \%systemroot%\system32\inetsrv directory and type
This command provides the Cscript association. After the command finishes, a message pops up to tell you that the Cscript registration was successful. From the \%systemroot%\system32\inetsrv directory, type the previous command again, or press the up arrow to recall the command and press Enter. The IIS systems' configuration parameters will scroll past, so you know the Cscript association was successful and you're ready to set the WWW Service account. To set the account, go to the \%systemroot%\system32\inetsrv directory and type
In this command, domain_name is the domain in which your service account exists and IWAM_name is the name of your service account. Next, set the WWW Service account password from the \%systemroot%\system32\inetsrv directory by typing
in which IWAM_Password is your WWW service account's password.
Creating a Clustered Web Site
From NT Explorer or a command prompt, create a \www root directory in one of your IIS cluster resource group's shared drives. In the IIS MMC, select the option under node A to create a new Web site. Set your new Web site's IP address to an IP address in your IIS cluster resource group, and assign the newly created directory on the shared drive as your site's home directory.
Next, in Cluster Administrator, right-click the IIS cluster resource group and select New Resource from the drop-down menu. Name the resource (e.g., My First Web Site), and select IIS Server Instance as the resource type. Click Continue, and the system prompts you for resource dependencies. Select the IIS cluster resource group's IP address and the shared drive on which your Web site will exist. Although the IIS Server Instance isn't dependent on the shared disk resource, you set the shared drive as a dependency so users can't access your Web site if the shared drive is down. The system then asks whether the resource is a Web site or an FTP site. Select Web site, and identify the directory that you previously created.
You can return to the IIS MMC and remove any nonclustered Web sites except for the administrative site. After configuration, MSCS controls clustered Web services, so if you need to start or stop your IIS site, use the Cluster Administrator tool.
After you finish configuring node A, you've created a clustered Web site. Luckily, you don't need to repeat this process on node B to provide successful failover services. Instead, go to the \%systemroot%\system32\inetsrv directory on node A, and type
in which node B is the server's name. This command synchronizes all configuration information between node A and node B. After you complete this step, you can return to the Cluster Administrator interface, bring your Web site online, and take advantage of its increased availability.
To create additional Web or FTP sites on your cluster, repeat the steps to create a clustered Web site. You can also create resource groups for each additional Web site, or you can maintain all your Web sites in the same resource group; however, if you plan to manually load balance processing between nodes, create a resource group for each Web site. You don't need to recreate, modify, or move the distributed transaction coordinator (DTC) resource in your initial IIS cluster resource group.
You can manage your clustered Web site from your IIS MMC by adding your IIS site's virtual server name to your IIS MMC. If you use this method, you don't need to use the Iissync utility to synchronize Web site information.
Sweet Dreams
After you create an MSCS system that provides high-availability IIS 4.0 service, you can configure your Web site the same way you would configure it in a nonclustered environment. Users connect to your Web site via the network or IP address that exists in your IIS cluster resource group, rather than the cluster node name or physical node names. In addition, if your Web-based application requires middleware or client software, install the software on both cluster nodes and configure them in the same way. Then, if a failover occurs, your application will still run smoothly.
