MS Transaction Server 2.0 and High Availability using MS Cluster Server 1.0

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft Corporation

On This Page

Abstract
Why Clustering?
Installation
Run-time
Application Design Considerations
Administration
Optimizations
Appendix

Abstract

The intent of this article is to examine Microsoft Clustering from the perspective of the sample application Island Hopper developed by the COM Team. The practical aspects of setting up and running a Cluster can be a confusing and time consuming process. This paper will cover the entire process of setting up and running the Island Hopper application in a Clustered environment and also cover the details of what is actually going on, under the covers. This paper covers the Clustered setup of Windows NT 4.0 Server Enterprise Edition, Cluster Server (MSCS) 1.0, SQL Server 6.5 Enterprise Edition, Internet Information Server (IIS) 4.0, Transaction Server (MTS) 2.0, and Visual Studio 97 Service Pack 2.

If you have not configured a cluster before, it is recommended that you set up a cluster as soon as possible. After you have gone through the steps of setting up clusters, much of the discussion in this paper becomes clearer. Also, it is recommended that you have at least three Windows NT computers. Two computers for the Cluster and one to act as the client.

Why Clustering?

What is a Cluster

A cluster is defined as a group of independent computers working together as a single system. This allows the group of computers to be accessed and managed as a single computer. To accomplish this , all computers in the cluster are grouped under a common name, the cluster name (Virtual Server Name), which is used for accessing and managing the cluster. Currently MSCS 1.0 has the ability to combine two computers into a cluster.

Each computer that is a member of a cluster is called a node. The nodes of a cluster must have a network link between them that they can use to communicate with each other. In addition to a hard drive, each node must also have a connection to a shared Small Computer System Interface (SCSI) hard drive. This is where the shared cluster data is stored.

Some Microsoft Transaction Server 2.0 Basics

First of all, there are two types of applications which can run in a cluster. Cluster-aware applications which call MSCS 1.0 API's and know that they are running in a cluster. SQL Server 6.5 Enterprise Edition and MS DTC 2.0 are examples of such applications. MTS 2.0 is not Cluster aware, which means that the MTS executables do not realize that they are running in a cluster. Even though MTS 2.0 is not aware of the Cluster you still need to consider this when designing your application, which is covered later. In the near future, you can run any MTS application in a Clustered environment.

Cluster Terminology

Resources

Resources are physical or logical entities, such as a file share, managed by the Cluster Service. Resources provide a service to clients. They are the basic unit managed by the Cluster Service. A resource can only run on a single node in a cluster at a time.

Dependencies

A dependency is a reliance between two resources that makes it necessary for both resources to run on the same node. For example, a file share resource depends on a disk resource with a folder that can be shared.

Groups

Groups are a collection of resources for configuration and management purposes. If a resource depends on another resource, each of the resources must be a member of the same group. In the example of the file share resource, the group that the file share is part of must also contain the disk resource. All resources within a group must be online on the same node in the cluster.

Failover

Failover is the process of moving a resource or group of resources from one node to another in the case of a failure. For example, in a cluster where IIS 4.0 is running on Node A and Node A fails, IIS 4.0 will failover to Node B of the cluster.

Failback

Failback is the process of returning a resource or group of resources to the node on which it was running before a failover occurred. Extending the preceding example, when Node A comes back online, IIS can failback to Node A.

Quorum resource

A quorum resource is a resource that stores cluster management data, such as recovery logs for changes made to cluster data. It is accessible by all nodes of the cluster. Cluster Server requires a shared SCSI drive between the nodes of the cluster. A SCSI drive is the default quorum resource for a Cluster Server cluster. MS DTC 2.0maintains its logs on the shared SCSI drive.

Virtual Server

A server name which represents the cluster. A Virtual Server consists of two Cluster Resources: an IP Address and a Network Name. A fixed IP address is required to create an IP Address resource and the Network Name must be a unique NetBIOS name. You can have multiple Virtual Servers on one cluster.

Shared disks

A shared SCSI disk(s) is required for nodes in a cluster to communicate for synchronization purposes and to allow access to all data necessary for failover to occur successfully. At least one shared drive is required, but in some configurations, such as SQL Server 6.5 /EE active/active, at least two physical drives are necessary.

Installation

The order that you install the applications is very important. The following discussions are given in the order which you must follow to successfully install all the applications. You should also start with a fresh computer and install of all the applications onto fresh drives. If you have a machine which already boots to Windows NT, installing a new copy of Windows NT into a different subdirectory will work fine.

There is additional detailed information regarding clustering in the appendix.

Windows NT 4.0 Enterprise Edition (NT 4.0 /EE)

Setting up a cluster for the first time can be a time consuming process. Follow the Windows NT 4.0 /EE documentation on how to set up a cluster. See appendix C for additional detailed instructions. Some key points to remember:

• You will need a static IP address. This address will be used for the Virtual Server name. Ensure that you have a valid address before starting the installation process.

• Your first task will be to install MSCS 1.0 onto both nodes. This can be a tricky task, because you need to explicitly control when machines boot. The machine which boots first will own the shared SCSI drive. Ownership of the drive is necessary to access the shared devices. You will need to shutdown nodes in a certain order and keep nodes from booting, in order to install Cluster Server. A simple method for halting the booting sequence is to press the Space bar when the boot selection screen is given.

• After you have installed Cluster Server on the first node, bring up Cluster Admin and start the Cluster Service. Then install the second node. The installation for the second node will need to find the existing cluster, and without the first node active, it will be unable to find the cluster.

• After you have successfully installed the Cluster Server on both nodes, experiment with the Cluster Admin by moving ownership of the shared SCSI drives between the nodes. This will verify that Cluster Server is functioning properly.

• You should now be able to ping the Virtual Server name from other machines on the network. If you do not get responses from the Virtual Server name, try the individual node names. If you cannot get any response, then you likely have network or IP address problems. If only the Virtual Server name is not responding, try to ping the IP address directly. If you still get no response, run MSCS Admin and verify that the Network Name and IP address resource are up.

• As a final step, experiment with the Cluster Administration interface until you feel comfortable with what is going on. You will find that understanding groups and resources before moving onto the next application installation very helpful.

SQL Server 6.5 Enterprise Edition (SQL Server 6.5 /EE)

Installing SQL Server is fairly straight forward process. The key points to remember:

• When installing, make sure that the node you are installing from has control of the shared drives. You can determine this through the Cluster Admin utility.

• Only install SQL Server on one node. This will give you an active/passive configuration.

• Be sure and select the shared SCSI device(s) for the install and database location.

• The standard installation does not detect the Cluster or configure any Clustering options. You need to run the Cluster wizard which is located on the SQL 6.5 /EE CD, under the directory cluster.

• The documentation for clustering is in the WhatsNew.rtf. You will find it in Start/Programs/SQL 6.5/WhatsNew.rtf. You should read this before using the Cluster Wizard.

• When using the Cluster Wizard, you will be asked for another fixed IP address. If you do not desire this, then you can find the procedure in the documentation to use the Cluster IP address. It is recommended that you use a different IP address because it will allow you to statically load balance MTS components onto both machines. This will give you two Virtual Servers which will appear to the network as different machines.

• The Cluster Wizard will create a new Cluster Group and some additional resources. If you look at your resources you will now see two sets of IP Address and Network Name resources. These are your virtual servers. You should be able to ping both of these Network Names from the cluster machines, and from other machines. It is recommended that you verify that you can ping both of the virtual server names from non-cluster machines before proceeding.

• After you have completed the configuration, test it by moving the SQL Group to the other node. Verify that all the resources come back on-line on the other node.

Visual Studio 97 Service Pack 2 (SP2)

Install Visual Basic 5.0 and Visual Interdev, followed by SP3 onto the local drives of both nodes of the cluster and onto the client machine you are using.

Note: Do not install the Front Page extensions with Visual Interdev.

Windows NT 4.0 Option Pack (NTOP)

Be sure and take SQL Server Group offline through the use of Cluster Admin before starting the NTOP installation. You will need to run the NTOP setup on both nodes of the cluster and install the following components on each node. The install process for NTOP does not make distinctions between the various product components. If you want to administer MTS from your client machine, you should install MTS 2.0 on the client.

Note: Be sure and select the Node local drive for the install destination. Some details to remember when installing and a list of what to install:

• IE 4.01

• FrontPage 98 Server Extensions

• IIS 4.0

• MDAC 1.5

• MS Index Server

  Transaction Server 2.0

  • Be sure and select to show sub-components and select that the sample apps are installed.

  • You should see a dialog saying that a Cluster installation was detected. At this stage you should have two virtual servers. The original one for the Cluster, and the one created when putting SQL Server into a cluster. Be sure and read the note: The MS DTC 2.0 log file must be installed on a shared disk driver in the same resource group as the selected virtual server.

  • Select local administration.

• Windows Script Host.

Some other details to watch for:

• The first node you install onto must have ownership of the shared SCSI drives.

• Warning: After install, do not press the OK button right away. Go to the second node and install NTOP. The MTS install will detect the cluster and act accordingly. Select reboot when done.

• Go to the first node and press OK to complete installation.

• Go into cluster admin and start the sql server resource group. DTC is in this group, and it should start.

Island Hopper Installation

On both nodes of the Cluster perform the following steps:

• Copy the contents of IslandHopper to a new folder on the local drive and name it \Classifieds. Be sure and change all the permissions from read-only if necessary

You should designate one of the cluster nodes as the master. You will install packages onto the node, and then replicate the catalog from the master to the other node. Do not install the packages onto the shared SCSI drive(s). Otherwise, only one of the nodes will be able to access the components. Follow one of these methods for installing the packages onto the master node.

Installing using the VB script:

From the command prompt change directory to the classifieds directory. Run the "InstallPackages.vbs <install directory>". If you have installed Island Hopper in the C:\Classifieds directory you do need to include the install directory otherwise type the name of the directory where you have copied the Island Hopper application. Note: if you have spaces in your directory path then you should enclose the full path with double quotes.

Or

Installing using the MTS 2.0 Explorer in MMC:

Three Transaction Server packages must be installed, Accounting, Classifieds, and Utilities. Open the Transaction Server Management Console (Start/Programs/NT 4.0 Option Pack/Microsoft Transaction Server/Transaction Server Explorer) Select the Packages folder located within the console at: Console Root/Microsoft Transaction Server/Computers/My Computer/Packages Installed. Install the packages by pressing the Action button, then New/Package. Choose install pre-built packages. In the file dialog find the first .PAK file in \Classifieds\Packages\Accounting.PAK. Do this twice more, one for the Classifieds package and again for the Utilities package. Then select Next, choose Interactive User and accept the default c:\Program Files\MTS\Packages directory, then Finsh to complete the task.

Replication from master node to secondary node

Replication will delete the catalog on the destination computer and replace it with the master catalog. Consult the MTS 2.0 Help documentation for a more detailed explanation of the process. The key steps are:

• Make sure that you have installed VB 5.0 on both nodes. During the replication process, dll's are loaded and dependencies on VB runtime dll's are checked.

• Create a share point on the destination computer local drive and give everyone read privileges. This share point will be used for moving packages from the master to the secondary node.

• In MTS 2.0 explorer, edit the properties of my computer, and add the share name in the options tab.

• On the master, from a command prompt, run \\winnt\system32\inetsrv\iissync [dest node name]. This will replicate all the packages to the destination node. The utility mtxsync can only be used for replication when IIS is not installed.

• Be sure and read the MTS 2.0 documentation on replication as it will give you the details of what is going on.

Island Hopper SQL Server database setup.

Make sure the node you do these steps from has ownership of the shared SCSI drives. Use the SQL Enterprise Manager to the Classifieds database in your SQL server. To do this, right-click on the 'devices' icon, and select 'new device'. Make sure this device is at least 25 MB, and name it 'Classifieds'. Right-click on the 'databases' icon, and select 'new database'. Create the database in the device 'Classifieds', and name the database 'Classifieds'.

Now select Tools and run the SQL query tool. Make sure that the Classifieds database is selected in the right hand DB box. Click on the Load SQL script icon (second from the left) and open "classifieds.sql" in the .\classifieds\database_scripts directory. Execute this script. This should create all of the necessary tables in the classifieds database.

Now exit the Enterprise Manager and go to a command prompt. Change directory (CD) to the .\classifieds\database_scripts directory. Execute the batch file "bcp_classifieds_in.bat". This should load the tables with data.

Note: If you have trouble running SQL Server Enterprise Manager, such as an error message stating missing DLLs. MFC40D.dll & MSVCr50D.dll can be found on the Visual C++ 4.0 compact disc or in on the boneyard server.

Register the new data sources

On both of the Cluster nodes do the following:

Take the DSN files copied for the server install, \Classifieds\DSN. Copy the DSN files to the default directory for the ODBC data sources. To determine what this is on your computer look in the ODBC Control Panel in the "File DSN" tab and look at the directory hierarchy pop-down. The directory is typically (%systemroot%\data sources\). Once the files are in place then the DSNs will show in the ODBC Manager control panel.

Within the ODBC Manager control panel, configure each DSN and change the SQL Server name to the SQL Server Virtual Server name. This will allow the components running on either machine to access SQL Server as it moves between nodes.

Set the Web Virtual Root

On both of the Cluster nodes do the following:

Open Internet Service Manager located at: Start/Programs/NT 4.0 Option Pack/Internet Information Server/Internet Service Manager. In the management console, select the default web site located at Console Root/Internet Information Server/techtour_m2/Default web site. Push the Action button and select New/Virtual Root Directory. Use the alias 'IslandHopper' and a physical path = c:\classifieds\web.

Create an IIS resource in Cluster Admin.

This will allow a client to enter https://virtual_server_name, and their connection will be routed to the node which currently owns the IIS resource.

Setting the IIS Server in the Registry

On your client machine. (not a cluster node) do the following:

Change directory (CD) to the .\classifieds directory. Execute the "setIISServer <your IIS server name>". Where <your IIS server name> is the name of the Virtual Server which owns the IIS resource.

Setting MTS 2.0 Remote Server

MS DTC 2.0 is a cluster aware application. This means that the MS DTC 2.0 will call the Clustering API for various reasons. MTS 2.0 on the other hand is not Cluster aware. There is a technique for letting MTS 2.0 know that it needs to perform some special actions to support clustering and virtual servers.

Run MTS 2.0 explorer on one of the cluster nodes. Add the second node as another computer. Be sure and use the actual computer name and not a virtual server name. For each computer, edit the properties and go to the Options tab. Enter the Virtual Server name into the Remote Server Name field.

You might be wondering what this has to do with clustering. As mentioned above, MTS 2.0 is not cluster aware, which means that the concept of virtual servers must be manually administered when configuring MTS 2.0. When you create a new Remote Components entry in MTS 2.0 explorer on the client, you must use the actual server name, not the virtual server name. Since you must use the actual server name, failover would not be possible if a client was registered to access a component on a specific server. The way MTS 2.0 works around this issue is through the use of the value in the Remote Server Name field. When a client tries to register components from one of the cluster node, the MTS code on one of the cluster nodes replaces the value for the actual server name with the value in the Remote Server Name field. It works the same when creating a package installation executable.

Island hopper client install

At this point, as long as you bring the SQL Server Group online you should be able to access https://virtual_cluster_name/IslandHopper and run the application sample. In order for the VB client executable to run, you need to register all the components from one of the cluster servers. Follow the following steps:

• On the server node or client create a share visible to both machines. A good one is c:\[mts install dir]\Packages

• On the client machine (MTS 2.0 must be installed) use MTS 2.0 explorer and add one of the cluster server computers to a new computer item.

• Add all the components to the Remote Components folder

• After they are added, if you look at the property view of the components folder (toolbar button) you will see the virtual server name as the server if you did everything correctly. You can see that at this point, the actual IP address used by the client will be routed to the proper node by cluster server.

Final details

At this point you should have the Island Hopper sample up and running. You should be able to use the VB client as well as the web version. Failover will work, and you can experiment by moving groups from machine to machine and see what happens to the application. The actual details of what happens during failover and failback will be covered in the next sections

The Island Hopper application was not developed to be used in a Cluster. The logic for reinitializing the component references has not been added. You will likely have to exit the application or reload the page in order to get the application functioning after a fail-over.

Congratulations!

Run-time

Where do cluster server components run? Depends on your perspective!

From the clients perspective, the components are running on some remote machine. If you configured everything properly, then the client should only refer to Virtual Server Names. When the client makes a request to a virtual server, the actual destination of that request will be routed by the Clustering Server. Where it will actually end up can be seen from the Cluster Server Admin tool. The current owner of the Network Name Resource used by the client will be the machine which receives the request.

Server side components and ODBC

Ensure that all of your server side components connect to a DSN which is configured as a virtual server. If a components talks directly to node1, which happens to be running SQL Server 6.5 /EE, everything will work fine. However, when SQL Server is moved to node2 the server components will not longer be able to connect to the server.

Where does MS DTC 2.0 run

MS DTC 2.0 is added to the SQL Server Cluster Group by default. There will always be just one MS DTC running within a cluster. MS DTC 2.0 is cluster aware and will always query the Cluster Server to find the current location of the process.

What happens during failover

With MTS 2.0 components

Server component references on a client become invalid when the server it is connected to starts a failover. It is necessary for the client application logic to take this into account. The client app must reinitialize all the references to components after the backup server comes online. The time delay is only as long as it takes the IP Address and Network Name Resource to move to the secondary node. SQL Server takes longer, so if a server side component is dependent on SQL Server, you should determine your approximate retry window length. Then the client code can retry for that amount of time.

With MS DTC 2.0

MS DTC 2.0 maintains its log on the SCSI shared drive. When node1, which is running MS DTC 2.0 fails, node2 will detect the failure. The MSDTC resource will be brought online on node2. When it starts up on node2 it will detect the failure and rollback all the outstanding transactions node1 was handling.

What happens during failback

Failback is configurable with the Cluster Server Admin. Given the following scenario:

1. Client A creates a component C1 on VirtualServer1, which is actually running on node1. Node1 fails, VirtualServer1 is moved to node2.

2. All references to C1 by A become invalid, and invocation of any methods will return an error.

3. Client A reinitializes C1 on Virtual Server1, which ends up on node2 this time.

4. Node1 comes back on-line

5. If DTC is configured for failback, DTC will failback immediately and all pending transactions will be aborted.

6. C1 will need to retry transaction.

Application Design Considerations

The most important consideration when implementing an MTS 2.0 based application within a clustered environment is the management of state information. Every piece of persistent data that a server side component needs must reference this data through a virtual server name. You cannot use the registry to hold temporary data because the registry is not replicated. You can use temporary files as long as the components reference a file on a virtual server, and as long as your application logic can handle the inconsistencies which can develop since the file system is not transactional.

You should additionally carefully consider the amount of state that your components contain. Your component can be shutdown at any time, so if you have some activity or state which is not under a transaction, you could have inconsistencies when the component is created on the failover node and the client makes assumptions that some preexisting state is still maintained. As you can imagine, if the code on the client is written properly, you will have to take explicit steps in your code to reinitialize all of your component references. This step will make it more difficult to make logical assumptions about the state of a component because your client code will have to be architected in such a way that you can reinitialize all of your component references. For example, you will certainly be checking for error return codes when referencing components. If a reference returns an error which indicates that the Server is no longer available, you will need to jump to some code to reinitialize all of your references, and then try the failed operation again if necessary

Administration

When using the MTS 2.0 explorer always administer cluster nodes by their actual computer name. If you use the virtual server name, you will still only configure one node, but the node you actually configure is not apparent unless you use the Cluster Server Admin tool.

The task of ensuring consistent package installation between nodes in a cluster is the Administrators responsibility. You should follow the procedure used above when installing components. Install everything onto the designated master node, and then replicate the changes to the secondary node.

During replication, MTS 2.0 completely replaces the catalog on the destination with the catalog on the source with the following exceptions. The MTS 2.0 system and utilities packages and the IIS 4.0 utilities packages are not replaced. However these packages still must be configured identically on the source and destination (though file paths can differ). MTS 2.0 does not enforce this; it is the responsibility of the administrator to keep both sets of packages insync manually.

MTS 2.0 replication begins (at least conceptually since performance optimizations are possible) by deleting the list of computers on the destination and all packages (except system, utilities, and IIS 4.0 utilities) and remote components on the destination. It then replicates the list of computers known on the source to the destination. Next it replicates the packages by exporting them from the source and installing them on the destination. Next it replicates the list of remote components by installing them from their own source computers to the destination. Finally it replicates "My computer" properties except for the install, package, and remote directory paths.

Optimizations

Load balancing configuration

MTS 2.0 does not dynamically load balance components over a set of computers. This holds true in a clustered environment as well. You can however statically load balance by doing some administrative tricks. If you installed your cluster by using two fixed IP addresses, then you can do static load balancing.

Let's say our cluster nodes are node1 and node2, and our virtual server names are cluster_server and sql_server. Then follow these steps to statically load balance.

• On either node1 or node2 create a package installation executable (exec1) while the Remote Server Name is set to cluster_server.

• Create a second executable (exec2) while the Remote Server Name is set to sql_server.

• Distribute exec1 to half the users and exec2 to the other half.

• Just make sure that in the Cluster Admin tool that you keep the IP Address and Network Names on separate machines during normal operations. Also configure them to fail back to their preferred machine after a machine comes back up.

Now you have static load balancing. Depending on your application, you can partition your clients as you wish. SQL Server will always be running on one of the nodes so you might not want to evenly divide the client, but you can experiment to find the solution best for your application.

Appendix

Appendix A: Clustering Implementation Models

There are two cluster implementation models that are currently used in the computer industry—the shared device and shared nothing models.

Shared Device Model

In the shared device model, software running on any computer in the cluster can gain access to any hardware resource connected to any computer in the cluster (for example, a hard drive). If two applications require access to the same data, much like a symmetric multiprocessor (SMP) computer, access to the data must be synchronized. In most shared device cluster implementations, a component called a Distributed Lock Manager (DLM) is used to handle this synchronization.

The DLM is a service that is provided to applications running on the cluster that keeps track of references to hardware resources within the cluster. If multiple applications attempt to reference a single hardware resource, the DLM recognizes and resolves the conflict. However, using a DLM introduces a certain amount of overhead into the system in the form of additional message traffic between nodes of the cluster as well as the performance loss due to serialized access to hardware resources.

Shared Nothing Model

The shared nothing model is designed to avoid the overhead used by the DLM in the shared device model. In this model, each node of the cluster owns a subset of the hardware resources that make up the cluster. As a result, only one node can own and access a hardware resource at a time. When a failure occurs, another node takes ownership of the hardware resource so that the hardware resource can still be accessed.

In this model, requests from applications are automatically routed to the system that owns the resource. For example, if an application needs to access a database on a hard drive owned by a node other than the one it is running on, the node passes the request for the data to the other node. This allows the creation of applications that are distributed across nodes in a cluster.

Clustering Model Used by Cluster Server

It is possible for a cluster to support both the shared device model and the shared nothing model. Typically, applications that require only limited shared access to data work the best in the shared device model. Applications that require maximum scalability will benefit from the shared nothing cluster model.

Cluster Server supports the shared nothing model. However, it can support the shared device model as long as the application supplies a DLM.

Appendix B: Choosing a Cluster Server Model

There are five configurations in which Cluster Server clusters can be implemented:

• Model A: High-Availability solution with static load balancing.

• Model B: Hot Spare solution with maximum availability

• Model C: Partial cluster server solution.

• Model D: Virtual Server-Only solution (No Failover)

• Model E: Hybrid Solution

Model A

In Model A: High-Availability solution with static load balancing, each node in the cluster makes cluster resources available. This provides optimum performance by balancing the resources across both nodes in the cluster. However, in the model, each node must be able to run its own resources and the resources of both nodes in the event of a failover. Depending on the resources and the capacity of the nodes, performance may suffer when a failover occurs and a single node is running all resources.

When using the model as illustrated above, the following Network Names and IP addresses will be in use.

• A computer name and IP address for Node A.

• A computer name and IP address for Node B.

• A network name and IP address for the cluster.

• A network name and IP address for the file/print group 1.

• A network name and IP address for the file/print group 2.

Two file or print share groups could be created, one on each node. If one node fails, the other node will temporarily take on both shares. When the failed node comes back online, the group would failback to the original node, and then performance would return to the normal levels.

Model B

Model B: Hot Spare solution with maximum availability provides maximum availability and performance, but both nodes are never fully utilized. One node of the cluster makes all the resources available, while the other node is idle and waiting in case of a failover.

In this model, the idle node is a dedicated "hot spare", ready to be used if a failover occurs. If the node making the resources available fails, the hot spare node will cause the resources to failover to it, and then make the resources available with a performance level comparable to that of the original node. The performance level will depend on whether or not the hot spare node has the same specifications, such as CPU speed, as the original node.

When using the model as illustrated above, the following Network Names and IP addresses will be in use.

• A computer name and IP address for Node A.

• A computer name and IP address for Node B

• A network name and IP address for the cluster

• A network name and IP address for the Web Services group.

This model is best suited for the most critical applications and resources. For example, an organization that has a server on the World Wide Web where customers place orders may want to use this model. The expense of a second idle server can be justified by guaranteeing continuous high performance access to the organization's store on the web.

Model C

Model C: Partial Cluster Server Solution is very similar to Model B. In this model, however, what could be thought of as the primary server also runs non-cluster aware applications.

When implementing Cluster Server, it is likely that there will be applications that will not be configured for failover. Typically, an application will not be configured for failover because it:

• Does not meet the requirements for failover (using TCP/IP for network communication and being able to store data on the shared SCSI drive).

• Does not require high availability.

These applications can still be installed and used on either node in the cluster and used on either node in the cluster. However, if the node fails, the application will become unavailable.

In the diagram, the colored boxes indicate the cluster resources that will failover and failback. Node A has two non-Cluster Server aware applications that will not failover if the node fails. Therefore, if Node A fails, the applications will be unavailable until the node is brought back online.

When using the model as illustrated here, the following Network Names and IP addresses will be in use:

• A computer name and IP address for Node A

• A computer name and IP address for Node B

• A network name and IP address for the cluster

• A network name and IP address for each Cluster Server group

Model D

Model D: Virtual-Server-Only Solution (No Failover) utilizes the "virtual server" concept. There is no cluster since there is only a single node. Therefore, the failover capabilities of Cluster Server cannot be used. Instead, this model can be used to provide grouping of resources for organizational or administrative purposes, making it much easier for users to locate resources.

An advantage of this model is that in the future, when higher availability levels are desired, another node can be added to create a cluster. Since the groups of resources will have already been created, only the failover policies will need to be configured.

When using the model as illustrated here, the following Network Names and IP addresses will be in use:

• A computer name and IP address for the Node

• A network name and IP address for the cluster

• A network name and IP address for the file/print accounting group

• A network name and IP address for the file/print engineering group

• A network name and IP address for the file/print web server group

Model E

The last of the Cluster Server cluster models, Model E: Hybrid Solution, is a hybrid of the previous models, which combines the advantages of the other four models into a single cluster. As long as there is sufficient capacity, multiple failover scenarios can coexist in a single cluster.

The example shown demonstrates static load balancing for two database shares. Performance will be somewhat reduced, however, when both shares are on a single node.

The two file and print shares in Node A do not require failover ability and are therefore in logical groups, or virtual servers, for user and administrative convenience. There is also a non-Cluster Server aware application on Node B, operating as normal without any failover protection.

When using the model as illustrated here, the following Network Names and IP addresses will be in use:

• A computer name and IP address for Node A

• A computer name and IP address for Node B

• A network name and IP address for the cluster

• A network name and IP address for database group 1

• A network name and IP address for database group 2

• A network name and IP address for the file/print accounting group

• A network name and IP address for the file/print engineering group

Appendix C: Detailed Installation Instructions

Software Requirements

Cluster Server must be installed on a computer running Microsoft Windows NT® Server, Enterprise Edition. Cluster Server supports the following Windows NT Server, Enterprise Edition configurations:

• Member servers. Each node is configured as a member server running Windows NT; each node must be a member of the same domain.

• BDC and BDC. Each node is a backup domain controller (BDC) in an existing domain.

• PDC and BDC. Both nodes are configured within a self-contained domain, with one node acting as a primary domain controller (PDC), and the other as a BDC. This configuration requires trust relationships with any existing domains so that users will be able to gain access to the cluster.

Cluster Server Service Account

The Cluster Server service requires a user account under which the Cluster Server service can run when the Cluster Server service starts. This user account must be created before installing Cluster Server because the installation process requires the user name and password for the Cluster Server service user account to be supplied during setup. The setup process will not continue if a valid user name and password are not supplied.

The user account for the Cluster Server service does not require any special privileges. However, any password restrictions, such as the User must change password at next logon check box should be cleared. If password expiration is used, the Password never expires check box should be selected.

Hardware Requirements

Cluster Server requires all the hardware requirements for Windows NT Server, Enterprise Edition, in addition to the following specific Cluster Server requirements:

• Two computers, each with the following:

  • Dual bus, such as Industry Standard Architecture (ISA) and Peripheral Component Interconnect (PCI).

  • A boot disk with Windows NT Server, Enterprise Edition installed. These disks must not be on the shared SCSI bus.

  • A PCI SCSI adapter.

  • A minimum of one network adapter. Two network adapters are recommended so that the nodes of the cluster can have a private interconnect.

• An external SCSI hard disk to connect to both computers, which will be used as the shared SCSI disk.

• The necessary SCSI cables and terminators to attach the disk to both computers and properly terminate the bus.

It is recommended that all hardware used be similar, if not identical, for both nodes. This will make configuration easier and will eliminate any potential compatibility problems.

Before selecting any hardware, verify that the hardware is on the Cluster Server Hardware Compatibility List (HCL). The latest version of the Cluster Server HCL can be found on https://www.microsoft.com/ by searching on "Cluster Server Hardware Compatibility List."

Configuring the Shared SCSI Bus

The SCSI bus listed in the hardware requirements must be configured prior installation. Configuring the shared SCSI bus involves:

• Configuring the SCSI devices. The SCSI controllers and hard disks must be properly configured to work on a shared SCSI bus.

• Properly terminating the bus. The shared SCSI bus must have a terminator at each end of the bus. It is possible to have multiple shared SCSI buses between the nodes of a cluster.

After the SCSI bus has been configured, drive letters need to be assigned to the disks on the shared SCSI bus.

In addition to the information on the following pages, refer to the documentation from the manufacturer of the SCSI device or the SCSI specifications, which can be ordered from the American National Standards Institute (ANSI). The ANSI web site, https://www.ansi.org , contains a catalog that can be searched for the SCSI specifications.

Configuring the SCSI Devices

Each device on the shared SCSI bus must have a unique SCSI ID—both SCSI controllers and hard disks. Since most SCSI controllers default to SCSI ID 7, part of configuring the shared SCSI bus will be to change the SCSI ID on one controller to a different SCSI ID, such as SCSI ID 6. If there is more than one disk that will be on the shared SCSI bus, each disk must also have a unique SCSI ID.

Some SCSI controllers reset the SCSI bus when they initialize at boot time. If this occurs, the bus reset can interrupt any data transfers between the other node and disks on the shared SCSI bus. Therefore, SCSI bus resets should be disabled if possible.

Terminating the Shared SCSI Bus

There are several different methods that can be used to terminate the shared SCSI bus:

• SCSI controllers. SCSI controllers have internal termination that can be used to terminate the bus, however this method is not recommended with Cluster Server. If a node is offline with this configuration, the SCSI bus will not be properly terminated and will not operate correctly.

• Storage enclosures. Storage enclosures also have internal termination, which can be used to terminate the SCSI bus if the enclosure is at the end of the SCSI bus.

• Y cables. Y cables can be connected to devices if the device is at the end of the SCSI bus. A terminator can then be attached to one branch of the Y cable in order to terminate the SCSI bus. This method of termination requires either disabling or removing any internal terminators the device may have.

• Trilink connectors. Trilink connectors can be connected to certain devices. If the device is at the end of the bus, a trilink connector can be used to terminate the bus. This method of termination requires either disabling or removing any internal terminators the device may have.

Note: Any devices that are not at the end of the shared bus must have their internal termination disabled. Y cables and trilink connectors are the recommended termination methods because they will provide termination even when one node is not online.

Y cables and trilink connectors are the recommended termination methods because they will provide termination even when one node is not online.

Drive Letter Assignment

After the SCSI bus has been configured, drive letters must then be assigned to the disks on the shared SCSI bus. Assigning drive letters is necessary because the disks on the shared SCSI bus must have the same drive letter on both nodes for Cluster Server. Therefore, after configuring the shared SCSI bus and before installing Cluster Server, the drive letters must be configured by using Disk Administrator.

Note: Once the shared SCSI bus has been connected to both nodes, do not run Windows NT Server, Enterprise Edition on both nodes at the same time until Cluster Server has been installed on at least one node.

To assign the drive letters on both nodes:

1. Start Windows NT Server, Enterprise Edition on one node.

2. Start the second node, but do not allow Windows NT Server, Enterprise Edition to boot by pressing the SPACEBAR when the OS Loader screen appears.

3. Start Windows NT Disk Administrator, and then assign drive letters to the disks on the shared SCSI bus.

4. Shut down the first node, but do not turn off the computer.

5. Start Windows NT Server, Enterprise Edition on the second node by selecting the correct operating system, and then press ENTER.

Start Windows NT Disk Administrator, and then assign drive letters to the disks on the shared SCSI bus, using the same letter assignments that were used on the first node.

Installing Microsoft Cluster Server

Before installing Cluster Server, obtain the following:

• Appropriate permission to install Cluster Server. To run the Setup program to install Cluster Server requires a user to log on with an Administrator account.

• A Cluster Server service user account. The user name and password for the user account under which the Cluster Server service will run.

• The folder name for the Cluster Server folder. The default folder is %windir%\Cluster.

• The cluster name. This must be a unique NetBIOS name. The second node uses this name to connect to the first node to obtain the configuration information. Clients can be configured to use this name to gain access to the cluster. It can also be used in Cluster Administrator to connect to and administer the cluster.

• A static Internet protocol (IP) address and subnet mask for the cluster. Cluster Server uses the Transmission Control Protocol/Internet Protocol (TCP/IP) to communicate on the network and requires a static IP address. It is not possible to configure Cluster Server to obtain an IP address from a dynamic host configuration protocol (DHCP) server.

Installing Cluster Server is a two-phase process:

• Installing Cluster Server on the first node. The initial cluster configuration information must be supplied, and then the cluster can be created.

• Installing Cluster Server on the second node. The configuration information is obtained from the first node of the cluster.

Installing Cluster Server on the First Node

In the first phase of installation, all of the initial cluster configuration information must be supplied, and the cluster can be created. This can be completed through a Cluster Server Setup wizard. This wizard provides a guide through a number of steps, including:

• Confirming that Cluster Server is being installed on supported hardware.

• Determining whether to form a new cluster or join an existing one, or install Cluster Administrator.

• Specifying the folder and service account.

• Configuring which disk to use for the quorum resource.

• Configuring the network adapters to be used with Cluster Server.

• Configuring the network priority for node-to-node communication.

Copying the Cluster Server files and starting the Cluster Server service.

Confirming Supported Hardware

The first two screens that are displayed by the Setup wizard are the Welcome and Supported Hardware screens. The Welcome screen does not require any information to be entered.

After the Welcome screen is the Supported Hardware screen. The Supported Hardware screen makes customers aware that Cluster Server is only supported when installed on hardware configurations that have been tested and are on the Cluster Server HCL. To continue the setup process, click I Agree to accept the condition that Cluster Server is only supported on tested hardware. Clicking I Agree will enable the Next button.

Determining the Type of Installation

The next step of the setup process is specifying the type of installation to perform:

• Form a new cluster. Select this option when installing the first node of a cluster and first creating the cluster. When this option is selected, a unique network name (NetBIOS name) must be entered for the cluster.

• Join an existing cluster. Select this option when installing the second node of a cluster. When this option is selected, the name of the cluster must be entered.

• Install Cluster Administrator. Select this option when running Setup on a computer that will not be a node of a cluster, but will be used to administer a cluster.

Note: When running Cluster Server Setup on a computer that does not have Windows NT Server, Enterprise Edition installed, the above screens are not displayed. Instead, the screen indicates that Windows NT Server, Enterprise Edition is not installed and only Cluster Administrator will be installed.

Folder and Account

This part of installation requests the path for the Cluster Server files, and the user name, password, and domain name for the Cluster Server service user account.

Cluster Server File Location

This screen prompts for the path in which to place the Cluster Server files. This option defaults to the %windir%\Cluster folder.

Cluster Server Service Account

This screen prompts for the user name, password, and domain name for the user account under which the Cluster Server service will run. After entering the information for the Cluster Server service user account, and then clicking Next, the Setup wizard validates the user account and password. Therefore, for this step of the setup process to complete, this account must already exist in the domain.

Disk Configuration

This part of installation specifies the shared SCSI bus disks and designates the shared SCSI bus that will be used for the quorum resource.

Shared SCSI Disk Selection

This screen is used to specify which disks on the shared SCSI bus will be used by Cluster Server. By default, all SCSI disks on the SCSI buses other than the system bus will appear in the Shared cluster disks list. Therefore, if the node has multiple SCSI buses, some disks may be listed that are not on a shared SCSI bus. These disks should be removed from the Shared cluster disks list.

Quorum Resource Selection

This screen is used to select the disk on the shared SCSI bus that will be used for the quorum resource. The quorum resource can be any disk on the shared SCSI bus and can be changed in Cluster Administrator.

Network Adapter Installation

The next phase of the Setup wizard is the configuration of the network adapters in the node.

Scan for Network Adapters

This screen starts the scan of network adapters in the node. There is no input required on this screen, other than clicking Next to start the scanning process.

Network Adapter Configuration

This screen shows the first network adapter detected and allows configuration for the following settings:

• Network Description. This is a description that will be used in Cluster Administrator for the network adapter and the network to which the adapter is connected. For example, if the network adapter is connected to a private network that is used by the nodes to communicate, the entry for Network Description could be ClusterNet.

  Enable for cluster use. Selecting this check box allows the Cluster Server service to use the network adapter. This check box is selected by default.

  • Use for all communications. Selecting this option will cause the Cluster Server service to use the network adapter for node-to-node communication and for communication with clients. This option is selected by default.

  • Use only for internal cluster communications. Selecting this option will cause the Cluster Server service to use this network adapter for node-to-node communication.

  • Use only for client access. Selecting this option will cause the Cluster Server service to use this network adapter for communication with clients. No node-to-node communication will take place by using this network adapter.

This screen will be displayed once for each network adapter in the node. For instance, for a node with three network adapters, this screen will appear three times during Cluster Server installation, once for each network adapter.

If a node only has a single network adapter a screen will appear that recommends that multiple network adapters be used with Cluster Server in order to avoid a single point of failure with one network adapter.

Network Configuration

The next phase of the Setup wizard sets the priority of the network adapters and sets the configuration of the IP address.

Node-to-Node Adapter Prioritization

After configuring how the network adapters will be used by Cluster Server, the next screen is used to prioritize the network adapters. The priority arrows on the right side of the screen can be used to specify the order in which Cluster Server will use the network adapters for communication between nodes. Cluster Server will always attempt to use the first network adapter listed for communication between the nodes. Cluster Server uses the next network adapter in the list only if it is unable to communicate by using the first network adapter.

Cluster IP Address

This screen is used to configure the IP address and subnet mask that will be used by the cluster. In addition, the network over which clients will access the cluster must be specified.

Completing Installation on the First Node

The Cluster Server Setup wizard completes the setup process for the first node by copying the files needed to complete the installation of Cluster Server. After the files are copied, the Cluster Server registry entries are created, the log files on the quorum resource are created, and the Cluster Server service is started on the node.

Installing Cluster Server on the Second Node

Installing Cluster Server on the second node of a cluster requires very little information because most of the configuration information is obtained from the first node of the cluster. For example, there is no network configuration required when installing the second node of the cluster. Setup configures the Cluster Server network settings on the second node based on the configuration of the first node.

The Setup wizard for the second node uses the following subset of the screens that are used for installing the first node:

• Welcome.

• Supported Hardware Agreement.

• Type of installation to perform. When installing the second node, the Join an existing cluster option is selected and the name of the cluster must be entered.

• Folder for Cluster Server files.

• Cluster Server service user account password. The second node obtains the user account name and domain information from the first node of the cluster. These settings are filled in, but cannot be changed. However, the administrator installing Cluster Server must supply the password for the Cluster Server service user account.

When the configuration for the second node is complete, the Setup wizard completes the installation by copying files, creating registry entries, and then installing and starting the Cluster Server service.

Testing the Cluster Server Installation

There are several methods for testing a Cluster Server installation after the setup process has been completed:

• Cluster Administrator. If the installation was just completed on the first node of the cluster, start Cluster Administrator, and then attempt to connect to the cluster. If the second node was just installed, start Cluster Administrator on either node, connect to the cluster, and then verify that the second node is listed.

• Control Panel Services. Use the Services program in Control Panel to verify that the Cluster Server service is listed and started.

• Cluster folder. Verify that the Cluster Server installation process copied the Cluster Server files to the cluster folder that was specified during installation.

• Ping the cluster name. Open a Command Prompt window, and then attempt to ping the cluster name. This will verify that the Cluster Server service started and was able to register the cluster network name.

• Cluster Server registry entries. Verify that the Cluster Server installation process wrote the correct entries to the registry.